f18beta-blocker-review-6
LOGS
16:00:39 <tflink> #startmeeting f18beta-blocker-review-6
16:00:39 <zodbot> Meeting started Wed Oct 31 16:00:39 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:40 <tflink> #meetingname f18beta-blocker-review-6
16:00:40 <zodbot> The meeting name has been set to 'f18beta-blocker-review-6'
16:00:44 <tflink> #topic Roll Call
16:00:52 <tflink> Who's ready for some blocker review fun time?
16:01:03 * kparal is here
16:01:37 * jreznik is here
16:01:41 * satellit- listening
16:01:54 * Martix1 is testing
16:02:41 <tflink> testing? what is this testing thing of which you speak?
16:02:49 <tflink> adamw: around?
16:02:50 <Martix> Fedora
16:02:50 * Viking-Ice here
16:03:17 * nirik is lurking around.
16:03:39 <adamw> yo
16:03:57 <tflink> looks like we have enough people to get started
16:04:38 * tflink notes that he didn't send emails to devs yesterday due to an issue with the email generation. ask if you really want the gory details
16:04:51 <tflink> time for the always fun boilerplate!
16:04:57 <tflink> #topic Introduction
16:05:04 <tflink> Why are we here?
16:05:04 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:05:12 <tflink> #info We'll be following the process outlined at:
16:05:12 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:19 <tflink> #info The bugs up for review today are available at:
16:05:19 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:25 <tflink> #info The criteria for release blocking bugs can be found at:
16:05:25 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:05:25 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:05:25 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:05:34 <kparal> trick or treat!
16:05:40 <tflink> #info Up for review today are:
16:05:43 <tflink> #info 8 Proposed Blockers
16:05:44 <tflink> #info 4 Accepted Blockers
16:05:44 <tflink> #info 19 Proposed NTH
16:05:44 <tflink> #info 17 Accepted NTH
16:05:54 <tflink> kparal: does #action count as a trick?
16:06:13 <kparal> that's a fine trick by my standards
16:06:28 <tflink> #action kparal to fix and test all of F18
16:06:40 <adamw> woohoo project pina!
16:06:56 <tflink> anyways, objections to starting with the proposed blockers?
16:07:09 <kparal> go ahead
16:07:27 <tflink> #topic (868558) anaconda needs to tell yum what's a URL and what's a mirrorlist
16:07:30 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868558
16:07:32 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
16:09:14 <kparal> I think anaconda can't currently use mirrorlists at all
16:09:17 <tflink> does this happen with netinstall?
16:09:29 <kparal> tflink: doesn't matter, DVD or net
16:09:43 <kparal> but Closest Mirror always worked for me
16:09:53 <kparal> but specifying a mirror list manually didn't
16:10:03 <adamw> there may be a difference between starting with closest mirror selected and switching to it
16:10:12 <tflink> ah, so you have to change the default mirrorlist selection?
16:10:17 <kparal> I'm not even sure Closest Mirror uses a mirrorlist
16:10:20 <kparal> maybe it's just baseurl
16:10:31 <adamw> oh, it could just use download.fp.o, yeah...
16:10:50 <adamw> does anyone have smoke12 dvd handy? could try booting it and switching to closest mirror?
16:11:02 <kparal> tflink: yes, you need to change that. in my case. the other person seems to indicate it might crash even with default, but I haven't seen that
16:11:30 * tflink boots up a vm
16:11:45 * kparal tries with TC6
16:12:13 <kparal> hahah, crash
16:12:17 <kparal> but probably not related
16:13:28 * kparal just reported https://bugzilla.redhat.com/show_bug.cgi?id=871888
16:14:41 <tflink> smoke12 DVD doesn't crash but it is showing errors on the software selection
16:14:50 <tflink> when I go into that spoke, no details
16:15:14 <kparal> tflink: yes, I've seen that, my selecting something should help
16:15:21 <kparal> *but
16:15:36 <adamw> tflink: when you leave it should be fine
16:15:39 <adamw> that's actually intention
16:15:40 <adamw> al
16:15:51 <tflink> I entered and left the spoke several times
16:15:53 <zodbot> Ticket notification - f18betablocker: [Bug 871888] AttributeError: 'YumPayload' object has no attribute '_yum' <https://bugzilla.redhat.com/show_bug.cgi?id=871888>
16:15:56 <adamw> well, with kparal's reproducer of entering a mirrorlist i'm -1 beta blocker
16:16:07 <adamw> oh right i think you have to pick another desktop then pick gnome again.
16:16:08 <tflink> when I switched to cinnimon desktop, the error went away
16:16:11 <adamw> yeah
16:16:16 <adamw> i think i filed a bug on that.
16:16:33 <adamw> i'd like more data on nonamedotc's reproducer though...
16:16:40 <kparal> read comment 19
16:16:51 <adamw> still not complete
16:17:01 <adamw> what was he booting? what was it set to before?
16:17:10 <tflink> it could be a transient metadata issue in whichever mirror was chosen
16:17:23 <adamw> could be...the result seems a bit wacky
16:17:38 <kparal> I retried with TC6 and now it doesn't crash
16:17:51 <tflink> adamw: you mean the crashing?
16:17:52 <kparal> seems to be related to currently chosen mirror
16:18:14 <adamw> tflink: no, what the mirror served
16:18:16 <jreznik> tflink: ask to retest - to check if metadata are now ok/not?
16:18:18 <adamw> ah
16:18:28 <adamw> so in kparal's case the response from the server starts out:
16:18:33 <adamw> '<?xml version="1.0" encoding="utf-8"?>\n'
16:18:52 <adamw> in nonamedotc's case the response starts out:'<html><head></head><body><script>document.location = "http://geoadserving.coffeetree.info/?sid=146648";</script></body></html>'
16:19:04 <kparal> yes, that's weird
16:19:05 <adamw> and note the code we're in is looking for .treeinfo
16:19:27 <tflink> it almost sounds like something got screwed up - dns resolving, broken mirror etc
16:19:30 <adamw> there's obviously a link there
16:19:30 <adamw> yeah
16:19:37 <adamw> i think nonamedotc's case looks like one-time weirdness
16:20:09 <jreznik> indeed
16:20:15 <tflink> yeah, -1 blocker but repropose/reopen if it happens again
16:20:18 <kparal> I think I'm +1 Final blocker, -1 Beta blocker, +1 Beta NTH
16:20:20 <adamw> whereas kparal's is a clearer straightforward bug - it can't handle being passed a mirrorlist URL directly - but to me that's final stuff not beta
16:20:24 <adamw> agreed
16:20:26 <kparal> default netinst works fine
16:20:58 <adamw> well i agree with kparal if we hijack poor nonamedotc's case for the mirrorlist url case
16:21:11 <adamw> and maybe this code needs better sanitisation so weirdness doesn't crash anaconda
16:21:33 <tflink> it might not hurt to close and refile
16:22:25 <Viking-Ice> -1 beta +1 nth
16:23:00 <tflink> either way, it sounds like we're -1 blocker
16:23:15 <tflink> -1 beta blocker
16:23:40 <tflink> other thoughts on whether to hijack this or refile the mirrorlist issue?
16:23:48 <jreznik> -1 beta blocker, don't see it as nth (or nth should be sanitize code)
16:25:04 <adamw> i'll write it up in a comment and ask the devs if they want to split the issues
16:25:43 <tflink> proposed #agreed 868558 - RejectedBlocker (beta) - The original report seems like a one-time mirror issue and thus this bug was deemed to be not a blocker. The mirrorlist issue seems to be different but more of a final blocker - ask devs whether the issues should be split or not
16:26:19 <jreznik> ack
16:26:21 <jskladan> ack
16:26:46 <kparal> ack
16:26:51 <tflink> #agreed 868558 - RejectedBlocker (beta) - The original report seems like a one-time mirror issue and thus this bug was deemed to be not a blocker. The mirrorlist issue seems to be different but more of a final blocker - ask devs whether the issues should be split or not
16:26:55 <tflink> #topic (867593) installer must stop relying on being able to tell kpartx to use a disk/partition delimiter
16:26:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=867593
16:27:00 <Viking-Ice> ack
16:27:00 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
16:27:46 <tflink> sounds like a relatively clear blocker to me
16:28:33 <kparal> yay for long comments
16:28:38 <tflink> proposed #agreed 867593 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:29:00 <tflink> proposed #agreed 867593 - AcceptedBlocker - Violates the following F18 beta release criterion for dmraid : "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:29:14 <Viking-Ice> ack
16:29:52 <adamw> ack
16:30:12 <jskladan> ack
16:30:27 <tflink> #agreed 867593 - AcceptedBlocker - Violates the following F18 beta release criterion for dmraid : "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:30:31 <tflink> #topic (868535) AttributeError: 'NoneType' object has no attribute 'get'
16:30:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868535
16:30:36 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:32:15 <kparal> b) connect to wifi using AP without spaces or plug cable with dhcp in
16:32:16 <kparal> 1) visit network spoke from hub -> this bz
16:32:28 <tflink> it sounds like wireless won't work in pretty much any situation
16:32:30 <adamw> huh. so anaconda prompts you for a network connection even if you're installing from dvd. seems a bit bizarre, but oh well.
16:32:40 <adamw> certainly sounds like this will crop up enough that it's at least NTH, probably blocker
16:32:49 <adamw> this particular bug isn't actually wireless specific
16:32:51 * nirik is def +1 NTH...
16:33:02 <kparal> adamw: is it not?
16:33:14 <tflink> no, but if I'm reading it correctly, wireless won't work for netinstall or DVD
16:33:17 <adamw> aiui, if you start install without a working network connection, anaconda prompts you for one before displaying the hub, and when you finish that dialog, anaconda crashes
16:33:34 <adamw> kparal: comment #20 and #21
16:33:45 <kparal> I see
16:33:47 <kparal> that's pretty bad
16:33:51 <adamw> i'm pretty sure this bug basically means you can't possibly proceed with install if you start without the network up
16:33:53 <adamw> so that sounds blocker to me
16:33:54 <tflink> ok, this is only if you try to change network after starting install
16:34:25 <nonamedotc> crash with wired crashes was random in my experience. wireless - always
16:34:28 <adamw> tflink: not exactly. it concerns a specific instance of the network spoke you get at the start of install if you begin install with no network connection.
16:35:02 <adamw> oh, wait...b) 1)...yeeks.
16:35:04 <nonamedotc> adamw: i remember this crashed happening even from network spoke - back to hub situation ..
16:35:54 <tflink> proposed #agreed 868535 - AcceptedBlocker - Violates the following F18 alpha release criterion for machines without a network connection when anaconda starts (wireless, eth not plugged in etc.): "The installer must be able to use at least one of the HTTP or FTP remote package source options"
16:35:55 <adamw> okay, lemme take another cut at it...
16:35:58 <adamw> nack
16:36:12 <adamw> i think to hit this you have to hit the pre-hub network spoke _and then go into the post-hub network spoke too_
16:36:25 * satellit if you try to configure wep wireless get popup configure but does not connect (with wired conection with dhcp) will not start wireless  "not connected"
16:36:30 <adamw> basically if you run an install which hits the pre-hub network spoke, the hub network spoke becomes a landmine that explodes your install
16:36:45 <adamw> i *think* that's it.
16:36:54 <nirik> icky. if so, +1 blocker
16:37:06 <kparal> I'm also +1 blocker
16:37:21 <adamw> definite +1 nth, blocker seems slightly more questionable but i don't mind +1.
16:37:36 <tflink> yeah, I'm not so convinced this is a blocker but I'm not -1, either
16:38:08 <jreznik> well, nth then?
16:38:19 * jreznik is not sure he understood it correctly
16:38:45 <jreznik> how often the pre-hub network spoke is shown usually?
16:38:50 <tflink> thoughts on criterion?
16:38:56 * tflink isn't seeing anything off hand
16:38:59 <Viking-Ice> so what exactly is the deal here
16:39:10 <Viking-Ice> does it explode with wired or wireless or both
16:39:27 <tflink> wireless and I imagine wired w/o dhcp
16:39:33 * kparal pinging rvykydal
16:39:41 <tflink> unless network is configured via kernel boot options
16:39:44 <Viking-Ice> +1 nth
16:40:37 <adamw> jreznik: it's supposed to be shown if you start install without a working network connection
16:40:55 <adamw> jreznik: due to another bug, at present it's not shown if you have a wired connection but DHCP fails (anaconda considers that a working connection when it shouldn't)
16:41:31 <jreznik> adamw: yep but how many times do you hit this error? eg how many people start without it? probably wireless always?
16:41:44 <tflink> looks like we have +2.5 blocker +5 NTH (including me)
16:42:17 <adamw> jreznik: wireless is the obvious case
16:42:43 <adamw> i guess you're unlikely to hit this if you actually don't have a network connection as you'd have no reason to go into the network spoke post-hub
16:43:00 <adamw> the other case would be non-DHCP wired connections, i guess
16:43:06 <kparal> I think you needed to go there to configure wifi password
16:43:22 <tflink> I'm getting closer to -1 blocker unless I'm missing something
16:43:34 <adamw> shall we just vote it through as NTH and move on?
16:43:35 <tflink> kparal: can't you configure the password in the pre-start network config
16:43:37 <adamw> this is taking time
16:43:42 * nirik is ok with NTH I guess.
16:43:42 <adamw> we can revisit the blocker question if it becomes necessary
16:43:46 <kparal> tflink: I think there was a bug in it as well
16:43:48 <tflink> I can't find a criterion, anyways
16:44:45 <tflink> proposed #agreed 868535 - AcceptedNTH - While not a clear blocker, crashing when trying to configure network after initial wireless setup is bad and this can't be fixed after release with an update.
16:44:55 <tflink> or did we want to reject as a blocker?
16:45:14 <adamw> i'm fine with leaving it open
16:45:33 <jreznik> I think accept as NTH and maybe change mind in the future with better proof
16:45:34 <tflink> I'm pretty sure we're going to be no-go, anyways
16:45:47 <tflink> so ... ack/nak/patch?
16:45:48 <Viking-Ice> ack
16:45:51 <nirik> ack
16:45:52 <kparal> ack
16:45:55 <jskladan> ack
16:45:57 <adamw> ack
16:45:57 <jreznik> ack
16:46:13 <tflink> #agreed 868535 - AcceptedNTH - While not a clear blocker, crashing when trying to configure network after initial wireless setup is bad and this can't be fixed after release with an update. A tested fix would be accepted past freeze
16:46:33 * tflink assumes that nobody has issues with adding the last sentance. otherwise #undo is possible
16:46:45 <tflink> #topic (871129) Network is considered 'up' even if DHCP fails
16:46:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871129
16:46:45 <tflink> #info Proposed Blocker, anaconda, MODIFIED
16:47:50 <adamw> so this causes problems for cases where static config of wired networking is required
16:47:59 <tflink> +1 blocker
16:48:03 <adamw> -1 blocker
16:48:08 <adamw> because of comment #1
16:48:11 <adamw> but +1 NTH
16:48:32 <kparal> have someone tried that using boot options to configure network works?
16:48:39 <adamw> i dunno
16:48:42 <kparal> or GUI
16:48:55 <tflink> yeah, -1 blocker +1 NTH
16:49:19 * jskladan is also +1 NTH
16:49:21 * adamw is not taking down his entire network to test this =)
16:49:49 <tflink> I might be able to disable a specific MAC from my dhcp server
16:50:03 <kparal> it should be easy to test in a VM
16:50:04 <Viking-Ice> +1 nth
16:50:08 <jlk> -1 blocker +1 NTH
16:50:12 <jlk> (ahd hello)
16:50:19 <adamw> morning jesse
16:50:22 <kparal> anyway, if Radek's comment is valid, +1 nth -1 blocker
16:50:24 <tflink> kparal: I hear a volunteer :)
16:50:43 <zodbot> Ticket notification - f18betanicetohave: [Bug 868535] AttributeError: 'NoneType' object has no attribute 'get' <https://bugzilla.redhat.com/show_bug.cgi?id=868535>
16:51:34 <tflink> proposed #agreed 871129 - RejectedBlocker, AcceptedNTH - This doesn't prevent configuration of static networking but this shouldn't happen for non-dhcp setups. A well tested fix would be accepted after freeze.
16:51:39 <tflink> ack/nak/patch?
16:51:42 <adamw> ack
16:51:44 <jskladan> ack
16:51:57 <Viking-Ice> ack
16:51:58 <kparal> ack
16:52:01 <tflink> #agreed 871129 - RejectedBlocker, AcceptedNTH - This doesn't prevent configuration of static networking but this shouldn't happen for non-dhcp setups. A well tested fix would be accepted after freeze.
16:52:05 <tflink> #topic (870208) Logoff does not close session so if Restart or Shutdown performed from Logon screen after logoff Authentication dialog presented
16:52:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=870208
16:52:11 <tflink> #info Proposed Blocker, gnome-desktop3, NEW
16:53:30 <Viking-Ice> looks like a regular bug to me
16:53:34 <adamw> i don't think this is new, and i don't think it's a blocker
16:53:36 <Viking-Ice> -1 blocker -1 nth
16:53:44 <adamw> -1/-1
16:53:53 <adamw> can be fixed with an update, aside from anything else.
16:53:55 <nirik> -1/-1
16:53:59 <kparal> -1/-1
16:54:00 <tflink> yeah, I've been seeing this quite a bit but -1/-1, not a blocker and can be fixed w/ update
16:54:41 <jreznik> -1/-1
16:55:07 <tflink> proposed #agreed 870208 - RejectedBlocker, RejectedNTH - This doesn't violate any of the F18 beta release criteria and could easily be fixed with an update. Thus this bug is rejected as a blocker or NTH for F18 beta
16:55:11 <tflink> ack/nak/patch?
16:55:26 <kparal> ack
16:55:32 <adamw> ack
16:55:44 <Viking-Ice> ack
16:55:51 <jreznik> ack
16:55:51 <tflink> #agreed 870208 - RejectedBlocker, RejectedNTH - This doesn't violate any of the F18 beta release criteria and could easily be fixed with an update. Thus this bug is rejected as a blocker or NTH for F18 beta
16:55:55 <tflink> #topic (844167) Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64
16:55:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=844167
16:56:01 <tflink> #info Proposed Blocker, selinux-policy, MODIFIED
16:56:08 <adamw> oh god, this thing again
16:56:11 <adamw> can it please just die
16:57:11 <tflink> it could affect upgrade as I understand it
16:57:16 <adamw> yes
16:57:25 <adamw> it's been left open forever because we didn't know if it affected fedup
16:57:25 <adamw> does it?
16:57:34 <adamw> you being Mr. Fedup Tester
16:57:41 <tflink> depends on if the bug happens in permissive mode
16:57:41 <Viking-Ice> then let's punt it once more
16:57:54 <tflink> I haven't tried an upgrade with libvirt installed yet
16:58:12 <Viking-Ice> request the reporter testing with fedup once it becomes widely available
16:58:19 <tflink> the upgrades that have explodified have been due to other issues
16:58:24 <adamw> using permissive seems to be the workaround for this bug, so if fedup runs permissive, i think we're fine
16:58:25 <adamw> ah.
16:58:35 <adamw> i'm okay with -1 or punt.
16:58:50 <tflink> it runs in permissive at the moment but I think that there are plans to get it to work in enforcing
16:58:55 <tflink> wwoods added a fix that I haven'
16:59:02 <tflink> t gotten around to testing yet
16:59:07 <zodbot> Ticket notification - f18betanicetohave: [Bug 871129] Network is considered 'up' even if DHCP fails <https://bugzilla.redhat.com/show_bug.cgi?id=871129>
16:59:08 <Viking-Ice> arent selinux bugs been fixed by beta
16:59:16 <Viking-Ice> supposed to be
17:00:00 <adamw> Viking-Ice: ones in the straight through install / boot process iirc
17:00:07 <tflink> from c#60, it sounds like it might be fixed with latest f18 build of selinux-policy
17:00:21 <adamw> oh, no, that's Final - "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)"
17:00:35 <adamw> so this is only a blocker if it breaks fedup upgrades
17:00:35 <Viking-Ice> ah that's final
17:00:36 <tflink> I'm more for punt
17:00:43 <tflink> and I need to get this tested
17:00:43 <Viking-Ice> yeah let's punt it
17:00:46 <adamw> ok punt
17:01:13 <tflink> proposed #agreed 844167 - We're still not sure if this affects fedup, will re-evaluate after more testing has been done
17:01:32 <tflink> #action tflink to test fedup upgrade from 17 to 18 with libvirt installed on F17
17:01:41 <adamw> ack
17:01:46 <jskladan> ack
17:01:46 <Viking-Ice> ack btw we should match the selinux criteria with the normal install and upgrade process as they should be one and the same
17:02:06 <Martix> ack
17:02:12 <tflink> #agreed 844167 - We're still not sure if this affects fedup, will re-evaluate after more testing has been done
17:02:25 <adamw> Viking-Ice: yeah, i think that's reasonable, we should expand the criterion to cover upgrade
17:02:26 <tflink> #topic (869061) No output to journal after double-switch-root
17:02:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869061
17:02:26 <tflink> #info Proposed Blocker, systemd, NEW
17:03:19 <tflink> the short version of this is that there is no easily accessible output from fedup during upgrade
17:03:30 <Viking-Ice> yeah but the root cause has not been found
17:03:38 <tflink> true
17:03:38 <adamw> there's still no answer to the question whether it needs to be fixed in frozen packages, but
17:03:40 <Viking-Ice> so punt for wwoods responce
17:03:50 <kparal> adamw: I pinged wwoods yesterday about it
17:03:55 <tflink> it depends on how we handle upgrades for beta, to be honest
17:04:05 <tflink> and how hacky we're willing to let the upgrade process be
17:04:19 <Viking-Ice> I'm going for not so hacky
17:04:28 <adamw> that would be nice :P
17:04:34 <tflink> the systemd that's in question here is the version used to build the upgrade initramfs
17:04:55 <adamw> so if we're assuming that the idea is to build an upgrade.img that everyone gets from our servers, maybe the fix needs to be frozen
17:05:02 <tflink> so if we require systemd on the initramfs builder to be from frozen F18 then yes, it does need to be fixed in the frozen package set
17:05:08 <Viking-Ice> "That's usually an indicaiton that an old systemd tried to talk to a new journald"
17:05:11 <adamw> though actually we didn't decide on any official process for building that upgrade.img , so does it have to be built from frozen repos? who knows?
17:05:40 <tflink> I just noticed the request for a reproducer
17:05:51 <adamw> seems like the kind of thing that oh i don't know maybe should have been determined through the feature process. but le sigh. :)
17:05:56 <tflink> I'll update the bug with current upgrade process to reproduce
17:06:05 <Viking-Ice> honestly I'm a bit concern about these kind of issues
17:06:09 <adamw> i think lennart wants a reproducer that does not involve an entire f17 upgrade.
17:06:18 <tflink> good point
17:06:43 <adamw> Viking-Ice: me too, in the sense that it exposes the fact there are rather serious release engineering decisions being made up as will goes along.
17:06:44 <Viking-Ice> where it seems that the fedup is depended on specific dracut/systemd release
17:07:02 <adamw> but i guess we're a bit off-topic
17:07:03 <tflink> that's a communication issue, I think
17:07:06 <adamw> so sounds like we're punting?
17:07:19 <Viking-Ice> we need more data
17:07:21 <Viking-Ice> so yeah
17:07:25 <Viking-Ice> punt ( again )
17:07:55 <tflink> I'm +1 blocker on the 'no output during upgrade' issue but agreed that the cause isn't actually that clear
17:08:17 <Viking-Ice> you can still access those logs from a  shell
17:08:17 <Viking-Ice> right
17:08:26 <adamw> right, i'd be +1 on the issue _qua issue_, but the question that isn't answered yet is whether we actually need to fix this in the frozen package set.
17:08:47 <Viking-Ice> it's better to pull the update in I would say rather then leaving it frozen
17:08:54 <tflink> proposed #agreed 869061 - We still need more information on whether or not this actually needs to be fixed in the frozen package set and what the exact issue is
17:08:57 <adamw> ack
17:09:03 <Viking-Ice> ack
17:09:17 <jskladan> ack
17:09:19 <tflink> #agreed 869061 - We still need more information on whether or not this actually needs to be fixed in the frozen package set and what the exact issue is.
17:09:53 * Viking-Ice thinks it's not an systemd issue
17:10:01 <Viking-Ice> but wwoods issue ;)
17:10:16 <tflink> have we figured out how we're going to approach the frozen issue or are we waiting for input from will?
17:10:31 <Viking-Ice> I want to pull the release inn
17:11:10 * tflink was more interested in how the decision is being approached than actual solutions atm
17:11:30 <tflink> not that the solution isn't important, just that we still have plenty of bugs to go through
17:12:02 <tflink> anyways, on to the next bug
17:12:08 <tflink> #topic (871161) Fedora Upgrade Tool for F18 (fedup) requires systemd-195
17:12:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871161
17:12:08 <tflink> #info Proposed Blocker, systemd, NEW
17:12:31 <Viking-Ice> I think this is an clear blocker
17:12:51 <tflink> security issues aside, the short version is that fedup uses functionality from systemd that isn't present until 195
17:13:04 <Viking-Ice> yup
17:13:21 <tflink> therefore, if functioning fedup is a blocker; we need systemd-195
17:13:29 <Viking-Ice> yup again
17:13:40 <adamw> sorry to be difficult, but again there's the issue of the frozen package set. we still don't know where fedup will get its systemd.
17:13:55 <adamw> this would be a hell of a lot easier if someone would just nail down how the process is meant to work.
17:13:55 * tflink has been doing testing with 195-4 (which is different from the update in updates-testing)
17:14:01 <adamw> but i guess i don't mind taking it.
17:14:08 <tflink> I just started testing with 195-2
17:14:13 <Viking-Ice> plus it fixes "Journal leaks memory "
17:14:30 <tflink> ok, who do we need to aim our annoyance-phasers at to get the answer?
17:14:58 <Viking-Ice> the fedup package depends on systemd 195
17:15:17 <tflink> I'm aware of what the options are for handling the build issues, I just don't know what's planned
17:15:30 <adamw> i think will needs to hammer it out with releng.
17:15:33 <adamw> or infra.
17:15:36 <Viking-Ice> regardless where the update image get process from + reportes and other users might want to test fedup by creating their own update.img manually what then?
17:15:41 <adamw> or whoever would actually be in charge of building the images and mirroring them.
17:15:58 <Viking-Ice> and locally
17:16:00 <adamw> Viking-Ice: well if you're creating it locally you can always grab systemd from updates-testing, right?
17:16:18 <tflink> Viking-Ice: that's assuming you have an extra F18 box sitting around to build the initramfs
17:16:29 <Viking-Ice> adamw, looking over the update there is nothing that might cause regression I see there so I dont see why cant just pull it in
17:16:51 <tflink> my understanding is that the options are either to use a magical side repo with the upgrade.img in it or to modify lorax such that the upgrade modules are pulled in to the released initramfs in the tree
17:17:12 <adamw> Viking-Ice: i already said i don't really mind pulling it in, i'm just expressing frustration that the process is still so unclear we really can't tell for sure whether this really ought to block the beta release
17:17:29 <tflink> Viking-Ice: there is no such thing as a major version change that _cannot_ cause regressions
17:17:32 <adamw> so if we were doing this via lorax it'd pretty much have to be frozen
17:17:58 <tflink> my impression is that there are no plans to update lorax for beta
17:18:00 <Viking-Ice> adamw, no argument from me that this is to vague but I dont want it missing be an show stopper
17:18:16 <adamw> eh, let's just take it, life's too short
17:18:27 <tflink> I think there are bigger issues with fedup right now than which version of systemd is in stable
17:18:35 <adamw> since this meeting's logged i now have my 'i told you so' card up my sleeve :)
17:18:46 * tflink is +/- 0 on this
17:19:05 <tflink> in principle, I'm +1
17:19:05 <adamw> there's the point that if we're going to wind up taking this we should probably take it _now_
17:19:08 <Viking-Ice> I'm +1
17:19:18 <adamw> i guess that's better than realizing next tuesday we need to pull it in and re-test everything
17:19:20 <Viking-Ice> and now is the timne
17:19:29 <Viking-Ice> to pull it in
17:19:32 <adamw> yeah
17:19:35 <tflink> but I also agree that there is not enough information on how all the upgrade stuff is going to work
17:19:41 <jlk> I would also say to pull it in
17:19:53 <adamw> shall we call it accepted nth, blocker status uncertain, and pull it in now?
17:20:04 <Viking-Ice> yup
17:20:05 <adamw> on the basis of the reasoning above rather than the usual nth reasoning
17:20:23 <tflink> that feels a bit like a fudge to me, but I'm not really going to fight it
17:20:46 <tflink> so, punt on blocker, +1 nth?
17:20:49 <adamw> tflink: i actually kinda like it because it expresses 'this may be necessary so we should pull it right now to get it tested, but if it turns out it breaks stuff and we don't actually need it for fedup, it can be taken out again'
17:20:50 <adamw> yeah
17:21:07 <Viking-Ice> adamw, agreed
17:21:17 <Viking-Ice> if we pull it in now we can back out of it
17:21:18 <tflink> ok
17:21:49 <jreznik> makes sense
17:22:27 <jskladan> ^^
17:22:46 <tflink> proposed #agreed 871161 - AcceptedNTH - We recognize that this is likely required for upgrades but there are too many unanswered questions to take this as a blocker. However, testing of this update needs to start sooner than later and it is accepted as NTH for F18 beta. A tested fix would be taken past freeze.
17:22:56 <Viking-Ice> ack
17:23:02 <jlk> ack
17:23:02 <adamw> ack
17:23:09 * tflink needs to verify that 195-2 actually works with fedup
17:23:13 <jskladan> ack
17:23:17 <tflink> #agreed 871161 - AcceptedNTH - We recognize that this is likely required for upgrades but there are too many unanswered questions to take this as a blocker. However, testing of this update needs to start sooner than later and it is accepted as NTH for F18 beta. A tested fix would be taken past freeze.
17:23:26 <tflink> ok, that's all of the proposed blockers
17:23:41 <tflink> any preferences on going through the accepted blockers or proposed NTH first?
17:24:21 <tflink> that sounds like a no
17:24:26 <tflink> on to the proposed NTH!
17:24:28 <Viking-Ice> I'm  going out for a smoke that's my propose ;)
17:24:55 * tflink isn't sure how to word that as a proposed #agreed
17:25:00 <tflink> is there a bz for that?
17:25:03 <tflink> :-D
17:25:07 <adamw> proposed nth is good
17:25:19 <adamw> we need to evaluate them so anaconda team knows what to put in 18.22
17:25:27 <tflink> #topic (855646) custom partition setup: missing volume/device identification
17:25:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855646
17:25:27 <tflink> #info Proposed NTH, anaconda, NEW
17:26:53 <adamw> +1 NTH, this is an improvement we decided on a week back or so that is wanted by some forum testers
17:27:04 <tflink> +1 NTH
17:27:09 <adamw> makes it much easier to figure out what partitions listed in Unknown are
17:28:10 <tflink> proposed #agreed 855646 - AcceptedNTH - This alleviates some issues with custom partitioning and determining what can be deleted and what can't. Since this can't be fixed with an update, a tested fix would be taken past freeze.
17:28:11 * jskladan is a slow reader, but seems like +1 NTH to me so far
17:28:22 * kparal finished reading, +1 nth
17:28:28 <kparal> ack
17:28:30 <jskladan> ack
17:28:35 <adamw> ack
17:28:38 <tflink> #agreed 855646 - AcceptedNTH - This alleviates some issues with custom partitioning and determining what can be deleted and what can't. Since this can't be fixed with an update, a tested fix would be taken past freeze.
17:28:50 <tflink> #topic (869185) Crash when reclaiming space on disks with incomplete LVM
17:28:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869185
17:28:50 <tflink> #info Proposed NTH, anaconda, NEW
17:29:35 <tflink> isn't this a blocker?
17:29:48 <kparal> well
17:30:04 <kparal> it's kinda broken disk layout
17:30:04 <tflink> unless you're trying to reuse the partial VG?
17:30:20 <kparal> I tried to delete it
17:30:52 <tflink> it still shouldn't crash
17:30:54 <kparal> it's true this Beta could cover it:
17:30:54 <kparal> Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types
17:31:11 <tflink> or "rejecting obviously invalid operations without crashing"
17:31:18 <kparal> so it can be also discussed as Beta blocker
17:31:35 <tflink> but on the other hand, how many users are going to have a partially removed VG
17:31:35 <adamw> yeah...if we're going on the existing criteria (i'm still supposed to be revising them, remember) it may be a +1
17:31:44 <kparal> but dlehman said they don't plan to fix this in Beta. so they wouldn't be happy
17:31:59 * Viking-Ice back
17:32:18 <adamw> i think i'm ok with -1 blocker +1 nth
17:32:22 <adamw> and +1 final blocker
17:32:53 <zodbot> Ticket notification - f18betanicetohave: [Bug 871161] Fedora Upgrade Tool for F18 (fedup) requires systemd-195 <https://bugzilla.redhat.com/show_bug.cgi?id=871161>
17:32:57 <tflink> if this only happens with invalid LVM layouts, I'm ok enough with -1 betablocker, +1 nth and +1 final blocker
17:33:22 * kparal agrees
17:33:33 <Viking-Ice> +1 nth +1 final
17:33:42 <jskladan> ^^
17:34:40 <dlehman> well, the timing is perfect as usual. I'm about to step away right when you start getting to my bugs.
17:35:18 <tflink> proposed #agreed 869185 - RejectedBlocker (beta), AcceptedNTH - This doesn't seem to affect enough installs to justify taking as a blocker for F18 beta. However, crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze.
17:35:22 <kparal> dlehman: any thoughts about this one?
17:35:27 * tflink wasn't sure how to word the accepted final blocker part
17:35:48 <kparal> patch
17:35:52 <adamw> the catch-all final criterion
17:35:59 <kparal> it wasn't proposed Beta blocker, so we don't need to reject it
17:36:13 <tflink> oh, good point
17:36:28 * akshayvyas is here
17:37:38 <akshayvyas> oh i am late :)
17:37:39 <tflink> proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - This doesn't seem to affect enough installs to justify taking as a blocker for F18 beta. However, crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as a blocker for F18 final due to violation of the following F18 final criterion for invalid LVM source layouts: "The installer must be able to create and install to a
17:37:46 <tflink> which is way too long
17:38:00 <tflink> how about we just propose it as a final blocker and deal with it then?
17:38:06 <adamw> you don't need the bit about justifying it as a blocker.
17:38:16 <adamw> the whole first sentence.
17:38:23 <adamw> just start at 'Crashes in the installer are bad..."
17:38:25 <dlehman> -1 for beta blocker on the broken lvm thing, +1 final blocker
17:38:59 <tflink> proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as a blocker for F18 final due to violation of the following F18 final criterion for invalid LVM source layouts: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, L
17:39:06 <tflink> isn't that still too long?
17:39:14 <kparal> it is
17:39:23 <tflink> what's the last word?
17:39:27 <kparal> configuration
17:39:50 <Viking-Ice> ack
17:39:54 <kparal> can we just configure the IRC channel somehow? this is ridiculous
17:40:01 <adamw> heh
17:40:18 <adamw> i think you could shorten 'due to violation of the following F18 final criterion for invalid LVM source layouts'.
17:40:30 <tflink> proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as a blocker for F18 final due to violation of the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or co
17:40:31 * jreznik is back from fesco meeting, my tickets are over... back to fun
17:40:34 <adamw> kparal: we're teaching tflink concision
17:40:40 <adamw> so close!
17:40:52 <tflink> adamw: coming from you?
17:40:59 <adamw> touche
17:40:59 <kparal> touche
17:41:02 <kparal> :)
17:41:26 <adamw> i just got touche touched
17:41:37 <tflink> so close but nobody will tell me where it's cut off ...
17:41:49 <kparal> tflink: , or co
17:42:10 <tflink> proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as blocker for F18 final as it violates the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combinati
17:42:16 <kparal> combinati
17:42:18 <tflink> wait, that's just as long
17:42:19 <adamw> oh for god's sake that's close enough
17:42:34 <adamw> just put a ... on the end
17:42:41 <adamw> we know what criterion it is
17:42:49 <tflink> proposed #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as blocker for F18 final as it violates the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, ..."
17:43:01 <kparal> let's hash the criterion text and tag it with checksums
17:43:02 <Viking-Ice> or just the number of the criterion it hits..
17:43:06 <kparal> solution!
17:43:21 <tflink> the number won't work if the criteria change
17:43:21 <kparal> Viking-Ice: that changes, checksum doesn't
17:43:41 <tflink> checksum makes it hard to understand unless you know the criteria ahead of time
17:43:54 <Viking-Ice> in theory  hits beta criteria "10" should suffice
17:43:55 * tflink would prefer a url shortening scheme of some sort
17:44:12 <tflink> but we're getting way off into the weeds
17:44:12 <adamw> i've thought about this, it gets tricky.
17:44:20 <tflink> ack/nak/patch?
17:44:34 <adamw> my best plan so far was to use page anchors, but you have to be careful the anchor text will be valid if the criterion changes...
17:44:34 <adamw> ack
17:44:58 <jskladan> ack
17:45:00 <kparal> ack
17:45:05 <Viking-Ice> ack
17:45:13 <tflink> #agreed 869185 - AcceptedBlocker (final), AcceptedNTH (beta) - Crashes in the installer are bad and can't be fixed with an update. A tested fix would be considered past freeze. Accepted as blocker for F18 final as it violates the F18 final criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, ..."
17:45:26 <tflink> #topic (868509) LUKS passphrase exposed in storage.log attached to bug report
17:45:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868509
17:45:26 <tflink> #info Proposed NTH, anaconda, MODIFIED
17:45:48 <Viking-Ice> this is a politcal issue not technical one
17:45:51 <adamw> +1 nth, identified as a security issue by srt, can't be fixed with an update.
17:46:08 <akshayvyas> yep +1 nth
17:46:47 <Viking-Ice> +1 nth would like to get dlehman take on this thou ( since they are doing it deliberate )
17:46:50 <kparal> adamw: about srt, which comment?
17:47:11 <tflink> proposed #agreed 868509 - AcceptedNTH - plaintext LUKS passwords in the output kickstart file are a security issue and this can't be fixed with an update.
17:47:20 <kparal> ack
17:47:33 <adamw> kparal: oh sorry, i was confusing this with the other issue, but comment #7 effectively
17:47:49 <akshayvyas> ack
17:47:50 <adamw> this is less serious than i thought in comment #8, but still worth fixing.
17:47:51 <dlehman> the storage.log isn't deliberate, actually. code changed without regard for security of the logs
17:48:01 <dlehman> it's trivial to fix
17:48:04 <tflink> oops, patch
17:48:07 <adamw> i think viking was confusing this with the other bug too :)
17:48:48 <dlehman> the storage.log one is trivial to fix and should absolutely be fixed
17:48:54 <tflink> proposed #agreed 868509 - AcceptedNTH - plaintext LUKS passwords in the storage log are a security issue and this can't be fixed with an update. A well tested fix would be considered past beta freeze
17:49:19 <jskladan> ack
17:49:30 <dlehman> the anaconda-ks.cfg one is somewhat debatable, but leaving them out errs on the side of caution IMO which is fine in this case
17:49:40 <adamw> ack
17:50:04 <Viking-Ice> ack
17:50:12 <kparal> ack
17:50:13 <tflink> #agreed 868509 - AcceptedNTH - plaintext LUKS passwords in the storage log are a security issue and this can't be fixed with an update. A well tested fix would be considered past beta freeze
17:50:24 <tflink> #topic (866717) f18 anaconda cannot use the selected disk (continue button remains grayed out and the disks does 'not count' for anaconda) (reproduced)
17:50:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866717
17:50:29 <tflink> #info Proposed NTH, anaconda, ASSIGNED
17:51:15 <tflink> +1 nth
17:51:35 <jskladan> +1
17:51:39 <jreznik> +1
17:51:47 <akshayvyas> +1 nth
17:51:55 * dlehman goes afk for an hour or more
17:52:10 <adamw> +1 nth.
17:52:12 <tflink> dlehman: the next 4 NTH are assigned to you
17:52:43 <kparal> +1 nth
17:52:53 <dlehman> yeah, the reason I came was to argue for them if needed but oh well. I've used my blocker meeting time slot up now.
17:53:14 <tflink> proposed #agreed 866717 - AcceptedNTH - While not a blocker, being able to select additional disks is somewhat expected. A tested fix would be considered past freeze.
17:53:25 <akshayvyas> ack
17:53:39 <adamw> ack
17:53:40 <jskladan> ack
17:53:47 <tflink> #agreed 866717 - AcceptedNTH - While not a blocker, being able to select additional disks is somewhat expected. A tested fix would be considered past freeze.
17:54:03 <tflink> #topic (868468) anaconda displays previously installed Fedora systems as Unknown in Manual Partitioning
17:54:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868468
17:54:09 <tflink> #info Proposed NTH, anaconda, ASSIGNED
17:54:23 <adamw> i'd be -1 later on, but since we have a week, +1.
17:55:02 <tflink> our inconsistency on reasons for taking/rejecting NTH confuses me
17:55:25 <Viking-Ice> yup
17:55:32 <Viking-Ice> me as well
17:56:04 <tflink> eh, I'm not so convinced this is needed for beta
17:56:44 <tflink> +/- 0 nth
17:56:57 <adamw> tflink: but i thought we're sensible people with common sense! ;)
17:57:20 <Viking-Ice> +1 nth
17:57:44 <adamw> to be honest i'm in a kind of 'we have a week before go/no-go and next anaconda is going to be a huge change anyway, so let's stick in all the fixes that look really useful for now'
17:57:47 <tflink> adamw: generally yes but the lack of consistency is pretty frustrating
17:57:48 <adamw> frame of mind
17:58:07 <tflink> when stuff like https://bugzilla.redhat.com/show_bug.cgi?id=860551 is taken when no fix is even proposed
17:58:07 <adamw> we're not really at the point where we have a 99% good RC and we really don't want to change it unless we absolutely have to
17:58:17 <Viking-Ice> if you are dual booting and manual partitioning and let's say we have windows on one how would you tell them apart if they are "unknown"
17:58:20 <tflink> which isn't what NTH is, according to previous meetings
17:58:33 <adamw> sidetrack!
17:58:47 <adamw> Viking-Ice: aiui this bug is btrfs-specific so it's unlikely to affect windows installs :)
17:58:53 <tflink> for now, yes. I get dismissed with "sidetrack" again
17:58:55 <adamw> but in theory any OS you can install to btrfs could wind up as Unknown.
17:59:14 <tflink> it sounds like we're mostly +1 nth?
17:59:20 <adamw> well, where 'mostly' is 2.
17:59:23 * tflink counts +2
17:59:29 <tflink> I don't see any -1s
17:59:32 * kparal has no opinion here
17:59:37 <jskladan> ^^
17:59:48 <kparal> throw it in the basket!
17:59:52 <kparal> that means +1 nth
17:59:59 <tflink> because that's never gotten us into trouble before ...
18:00:11 <adamw> =)
18:00:45 <adamw> if you really feel strongly about it i don't mind changing to -1 on the 'tough on nth' mindset
18:00:53 * tflink is changing his vote to -1
18:00:54 <adamw> like i said i'd be -1 if we were closer to done
18:00:58 <tflink> but I'm still outvoted
18:00:59 <Viking-Ice> me too
18:01:10 <tflink> how many people are going to have btrfs subvols preexisting?
18:01:16 <adamw> i think viking and i tend to vote pretty 'conditionally' when it comes to nth
18:01:21 <adamw> that's a fair point.
18:01:26 <adamw> okay, count me -1.
18:01:38 <tflink> you couldn't do btrfs in F17 w/o doing custom partitioning
18:01:53 <adamw> wasn't btrfs entirely disabled for f17?
18:01:56 <tflink> and if you know enough to do that, you can handle the "unknown" in the installer?
18:01:56 <akshayvyas> +1 tflink
18:01:57 <Viking-Ice> if "btrfs" is supposed to be next release default desktop we should be working in advance and start identifying related bugs now
18:02:15 <tflink> adamw: by custom, I mean cli - possibly outside the installer
18:02:15 <Viking-Ice> mean default filessystem
18:02:45 <tflink> so we're +2, -2?
18:02:53 <tflink> progress :-D
18:02:54 <adamw> i count -3
18:03:00 <adamw> akshay said '+1 tflink'
18:03:08 <akshayvyas> i am -1
18:03:15 <tflink> ok, -3, +2
18:03:20 <akshayvyas> i said +1 for what tflink said
18:03:24 <Viking-Ice> mine counts as 5 so I beat you all muhaha
18:03:35 <Viking-Ice> I'm fine with -1 since it affects only btrfs
18:03:35 * adamw flips frantically through rule book
18:03:36 <adamw> :P
18:03:41 <adamw> uh, it's not +2 any more. i changed to -1.
18:03:43 <adamw> there's only +1.
18:03:51 <tflink> viking and kparal at the time
18:03:51 <adamw> oh wait, kparal was +1 too.
18:03:53 <adamw> confusion!
18:03:58 * kparal still has no opinion
18:04:03 <tflink> it only affects btrfs with subvols - not even all btrfs
18:04:04 <adamw> you're just easily swayed
18:04:11 <adamw> okay...everyone vote again
18:04:16 <tflink> -1
18:04:19 * adamw is now -1 nth, tflink convinced me
18:04:21 <akshayvyas> -1
18:04:24 <Viking-Ice> -1
18:04:27 * kparal begins to write a proposal how to handle nth bugs differently
18:04:51 <adamw> kparal: here, have some gin.
18:05:05 <adamw> that looks like -4 +0.
18:05:16 <nanonyme> tflink, root is a subvolume too
18:05:44 <tflink> proposed #agreed 868468 - RejectedNTH - While unforutnate, this appears to only affect systems with pre-existing btrfs subvols. It was deemed uncommon enough not to justify NTH status for F18 beta, especially since btrfs partitioning was not possible through anaconda for F17.
18:05:49 <adamw> ack
18:05:54 <akshayvyas> ack
18:05:56 <nanonyme> or at least that's how Fedora 18 sets it up
18:05:57 <adamw> er, patch - typo in 'unfortunate'
18:05:58 <jlk> ack
18:06:25 <Viking-Ice> ack
18:06:34 <tflink> #agreed 868468 - RejectedNTH - While unfortunate, this appears to only affect systems with pre-existing btrfs subvols. It was deemed uncommon enough not to justify NTH status for F18 beta, especially since btrfs partitioning was not possible through anaconda for F17.
18:07:06 <nanonyme> so Fedora 18 over Fedora 18 is the most likely thing to trigger that, no?
18:07:30 <tflink> nanonyme: don't you have to do that in custom partitioning?
18:07:40 <nanonyme> yeah, you do
18:07:41 <tflink> I didn't think that autopart in F18 used btrfs
18:08:38 <nanonyme> and it's just an inconvenience anyway, the significant F18 Btrfs over F18 Btrfs issues are already fixed that I know of
18:08:39 <adamw> f18 over f18 custom part install is the reproducer, by the looks of it.
18:08:40 <Viking-Ice> move along
18:08:44 <adamw> +1 viking :)
18:09:00 <tflink> #topic (870569) Custom partitioning should allow the user to specify which disk a partition should wind up on
18:09:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=870569
18:09:05 <tflink> #info Proposed NTH, anaconda, ASSIGNED
18:09:22 <adamw> +1 nth, this is a greatest hit for sure.
18:09:52 <kparal> +1 nth
18:09:52 <tflink> wasn't the RFE bug closed?
18:09:57 <nanonyme> +1 nth
18:10:20 <adamw> tflink: ?
18:10:32 <tflink> nvm, that was for the bootloader location
18:10:36 <akshayvyas> +1 nth
18:10:37 <tflink> +/- 0
18:11:42 <tflink> proposed #agreed 870569 - AcceptedNTH - While not a blocker for F18 beta, this functionality is important for final and would be good to start testing now. A tested fix would be considered past freeze.
18:11:46 <Viking-Ice> ack
18:11:52 <jskladan> ack
18:11:54 <akshayvyas> ack
18:11:56 <tflink> #agreed 870569 - AcceptedNTH - While not a blocker for F18 beta, this functionality is important for final and would be good to start testing now. A tested fix would be considered past freeze.
18:12:14 <tflink> #topic (871104) Installer allows use of preexisting root filesystem
18:12:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871104
18:12:14 <tflink> #info Proposed NTH, anaconda, NEW
18:12:53 <tflink> +1 nth
18:13:32 <kparal> actually I would be glad if this never gets fixed
18:13:38 <adamw> +1, it's a safety check so not likely to cause problems.
18:13:43 <adamw> kparal: ?
18:13:56 <jlk> it can certainly speed some things up
18:14:01 <kparal> I don't separate /home, and I use to reinstall by cleaning everything except /home
18:14:07 <jlk> but it would put a system into a really unknown state.
18:14:08 <kparal> force-formatting of / is evil
18:14:22 <adamw> that's a highly crack-addled use case that i don't think we should support.
18:14:34 <tflink> kparal: that sounds like a bad idea in the first place - why not just separate /home?
18:14:37 <adamw> if you want to act as if /home is a separate partition make it a flipping separate partition.
18:14:40 <tflink> or use ks
18:14:48 <kparal> tflink: because separating /home is so 80s
18:14:53 <kparal> I have a small disk, always
18:14:53 <jlk> Not sure he can use KS to get the desired effect
18:14:57 <kparal> no matter how large it is
18:15:18 <kparal> anyway, that's just my rant
18:15:18 * adamw still +1.
18:15:21 <tflink> so 80s? you're fine with your / filling up if you download too much?
18:15:22 <kparal> don't let me sidetrack you
18:15:32 <Viking-Ice> -1 nth
18:15:44 <kparal> tflink: sure, it still has 5% reserved for root
18:15:48 <tflink> so it sounds like +2, -2?
18:16:04 * kparal will just not vote here
18:16:09 <adamw> Viking-Ice: why -1?
18:16:13 <tflink> so +2, -1
18:16:37 <jlk> I'm +1 NTH
18:16:49 <tflink> +3, -1
18:16:51 <jlk> wait, are these existing blockers?
18:17:02 <kparal> jlk: just nth
18:17:06 <jlk> ah, ok, yeah NTH
18:17:10 <adamw> we're on proposed NTH.
18:17:12 <Viking-Ice> adamw, I dont want to risk pulling something in at this time that is fiddling with partition layout on such an fundemental level
18:17:36 <adamw> Viking-Ice: all it does is disallow a specific operation, it doesn't change any 'active' code aiui
18:17:50 <adamw> would be nice to see the patch i guess
18:17:53 <tflink> I don't think it fiddles with the partition layout much, just doesn't allow existing / to be selected w/o reformatting
18:18:03 <tflink> adamw: you have a point
18:18:31 * adamw checks patches-list
18:18:39 <Viking-Ice> if it's an minor change I'm +1
18:18:59 <nanonyme> adamw, wasn't it anyway so that we can nay later since it's just nth?
18:19:10 <nanonyme> (ie if patch sucks :p)
18:19:15 <adamw> https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-October/001824.html is the patch i believe
18:19:20 <adamw> Viking-Ice: ^^^
18:19:55 <Viking-Ice> ok +1 nth
18:20:49 <tflink> proposed #agreed 871104 - AcceptedNTH - Reusing / without reformatting is a bad idea and hasn't been allowed in anaconda for a while. A tested fix would be considered past freeze.
18:20:57 <Viking-Ice> ack
18:21:03 <jlk> the funny thing with this bug, if you have a valid rpmdb on your / filesystem, yum actually tries to do an upgrade rather than an install
18:21:12 <adamw> ack
18:21:20 <jlk> you could almost use this bug to upgrade F17 to F18
18:21:32 <akshayvyas> ack
18:21:35 <tflink> #agreed 871104 - AcceptedNTH - Reusing / without reformatting is a bad idea and hasn't been allowed in anaconda for a while. A tested fix would be considered past freeze.
18:21:41 <adamw> jlk: haha.
18:21:44 <adamw> it's a feature!
18:21:52 <tflink> #topic (871109) Confusing text in label for checkbutton to use custom partitioning
18:21:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871109
18:21:58 <tflink> #info Proposed NTH, anaconda, ASSIGNED
18:22:37 <jlk> +1 NTH.
18:22:44 <akshayvyas> +1
18:22:49 <akshayvyas> nth
18:23:21 <Viking-Ice> +1 nth
18:23:30 <adamw> +1
18:23:50 <jreznik> +1
18:23:59 <tflink> proposed #agreed 871109 - AcceptedNTH - This is a minor change to a dialog to increase the accuracy of the message. A tested fix would be considered past freeze.
18:24:11 <tflink> isn't this way past the translation deadline, though?
18:24:39 <jreznik> tflink: the question is - are anaconda translations already frozen?
18:24:59 <adamw> the translations have been screwed anyway, i believe
18:25:03 <tflink> I think they're supposed to be but I'm not sure, to be honest
18:25:05 <jreznik> as it's still under development... and I'm not sure exception was granted
18:25:08 <adamw> i think newui has been pretty much ignoring the freeze
18:25:12 <adamw> jlk?
18:25:36 <jlk> we've sortof had a blanket translation freeze break going on
18:25:44 <jreznik> tflink: it's definitely after deadline and when I talked to translators, they were thinking about exception...but nobody asked that time for one
18:26:59 <adamw> shall we say we're +1 NTH on this from a pure NTH process perspective, but that doesn't prejudice a translation freeze issue?
18:27:15 <Viking-Ice> ack
18:27:15 <adamw> i.e. if someone wants to enforce the string freeze here, that's a separate issue
18:27:36 <tflink> proposed #agreed 871109 - AcceptedNTH - This is a minor change to a dialog to increase the accuracy of the message. A tested fix would be considered past freeze if the translation freeze break is approved.
18:27:43 <adamw> sounds good, ack
18:27:44 <Viking-Ice> ack
18:27:56 <kparal> ack
18:27:59 <tflink> #agreed 871109 - AcceptedNTH - This is a minor change to a dialog to increase the accuracy of the message. A tested fix would be considered past freeze if the translation freeze break is approved.
18:28:14 <tflink> #topic (869675) RFE: Anaconda should warn user when disabling root account in certain situations
18:28:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869675
18:28:19 <tflink> #info Proposed NTH, anaconda, ASSIGNED
18:29:02 <Viking-Ice> well anaconda should not allow for root password not being set in minimal installations
18:30:04 <adamw> i think i put my opinion in comment #9
18:30:14 <Viking-Ice> +1 nth
18:30:19 <adamw> i'm kinda +1 but i could be argued out of it
18:30:34 <tflink> so the change is to always require a root password?
18:30:34 <Viking-Ice> if we do this change we do it now or we dont for the rest of the release cycle
18:30:55 <Viking-Ice> mean development cycle
18:31:50 <adamw> tflink: no, aiui
18:31:51 <Viking-Ice> i'm with comment 6 on "desired" anaconda behavior noobs dont know what root password is hence the sudo scheme fits them better
18:31:53 <jlk> wait a sec here
18:32:00 <jlk> I think this bug is already fixed, or made obsolete
18:32:01 <adamw> the change is to require a root password when firstboot isn't being installed, if i'm reading correctly
18:32:04 <adamw> i made that mistake too
18:32:16 <adamw> i think i understand this one, so let me see if i can summarize
18:32:18 <jlk> the change that's in place is that the root password is required, period.
18:32:26 <adamw> no it isn't.
18:32:31 <adamw> the root password *spoke* is required.
18:32:32 <jlk> uh, I wrote the damn code
18:32:35 <tflink> I'm not convinced that this is wise to be changing right now
18:32:39 <kparal> adamw is right
18:32:40 <adamw> you are not required to set a root password in it.
18:32:43 <jlk> you are /required/ to put in a root password.
18:32:47 <adamw> no you're not.
18:32:49 <adamw> :)
18:32:53 <adamw> at least, as of TC6.
18:33:01 * adamw runs a quick check with smoke12
18:33:01 <jlk> TC6 is old :)
18:33:02 <Viking-Ice> O_O
18:33:02 <tflink> it sounds like you guys are talking about 2 different things
18:33:10 <jlk> be5d6d0ab2d1f47151879b1b9529baf1d3e78098
18:33:11 <tflink> jlk is talking about the patch covered by the bug
18:33:15 <Viking-Ice> o_O
18:33:23 <tflink> adamw is talking about current behavior
18:33:24 <adamw> if this changed in smoke12 such that we're simply forcing the creation of a root password in all cases - back to f17 behaviour - then i agree this issue is obsolete
18:33:31 <adamw> ah.
18:33:43 <adamw> so let me see if i have this straight
18:34:08 <adamw> right now we simply force everyone through the root spoke, but don't make any attempt to conditionally force them to actually set a password
18:34:25 <adamw> the proposed 'fix' for this is simply to always force the creation of a root password, not to only do it when firstboot is not present or something
18:34:28 <adamw> is that accurate jlk?
18:34:54 <jlk> correct.  The upstream fix is that root password spoke is required, and once in the spoke you're required to set a password
18:35:19 <jlk> we've punted on any attempt to make that variable based on payload contents
18:35:22 <kparal> why is it that this stuff changes every 2 weeks?
18:35:36 <adamw> so we're effectively ditching the whole 'let's go with admin users by default' thing.
18:35:54 <jlk> adamw: we're punting that problem to the post-install tools
18:36:12 <jlk> which can disable the root account if so desired
18:36:15 <adamw> jlk: are the post-install tools aware of this?
18:36:29 <jlk> firstboot is being re-written by an anaconda dev, so I assume so
18:36:44 <adamw> anyway. if anaconda team is of the opinion that forcing root passwords for f18 is the best option, i'm +1 nth, because it makes sense to change it pre-beta not post beta.
18:36:45 <Viking-Ice> anyway this is the behaviour that is to be expected from now on if so -1 to nth and just close this bug
18:37:00 <adamw> and it would be going back to f17 behaviour and it's probably the behaviour least likely to cause problems.
18:37:11 <adamw> Viking-Ice: we have to accept it as NTH to take the change to 'always force a root password
18:37:12 <adamw> '
18:37:28 <adamw> if we don't take it as NTH, we'd be saying 'keep the current behaviour where you have to go to the spoke but you aren't forced to set a password'
18:37:39 * Viking-Ice confused
18:37:48 <Viking-Ice> +1 nth
18:38:03 <adamw> so in stable anaconda right now, we force the user to go through the spoke, but they can set the password empty, disabling root account.
18:38:05 <adamw> we're frozen.
18:38:05 * kparal notes it would be nice to have some plan in advance rather to change it all the time
18:38:13 <Viking-Ice> but this behavior should not be changed once this is in
18:38:18 <adamw> so technically, to take a change for this in the next anaconda build, we have to approve this bug as NTH.
18:38:20 <jlk> kparal: we had a plan
18:38:20 <tflink> this doesn't feel like something that should be dealt with using the blocker/nth process but I'm not -1
18:38:39 <jlk> kparal: but gave up on that plan when it came time to implement it and we discovered all sorts of problems with the plan
18:38:43 <adamw> if we reject this as NTH and anaconda team pushes an anaconda 18.22 which changes this behaviour, technically they're breaching how the freeze process is supposed to work.
18:38:44 <jlk> so the plan has changed.
18:39:07 <adamw> so i'm saying we should accept this as NTH so anaconda 18.22 can 'legally' change back to the old 'always require a root password' behaviour.
18:39:18 <tflink> adamw: so how is that different from any other bug past freeze?
18:39:19 <kparal> if anaconda has decided this is the way forward, +1 is logical
18:39:19 <Viking-Ice> the plan is for everybody make the best out of the mess we currently are in
18:39:47 <adamw> tflink: don't quite understand the context of the question. are you saying 'why should we break freeze for this'?
18:39:51 <jlk> technically we would have to revert be5d6d0ab2d1f47151879b1b9529baf1d3e78098 or make a f18-beta branch that doesn't include be5d6d0ab2d1f47151879b1b9529baf1d3e78098
18:40:20 <tflink> adamw: no, I'm asking how pushing a fix for this w/o an accepted NTH or blocker would make it differnt for any other patch?
18:40:39 <tflink> but whatever, we still have a lot of NTH left to go through
18:40:48 <adamw> tflink: eh? the policy is that anaconda doesn't change stuff post-freeze unless it's accepted as NTH or blocker
18:40:56 <tflink> exactly
18:40:59 <jlk> we're trying to stick to that
18:41:06 <adamw> tflink: so as jlk says, if we reject this as NTH, anaconda would have to revert the commit that fixes this bug
18:41:12 <jlk> which is why I'd like this to be NTH, so that we can include it in the beta.
18:41:16 <adamw> right.
18:41:30 <adamw> i feel like i understand this but i'm worried we're not explaining it well to anyone else. :)
18:41:32 <tflink> before I start, I'm not disagreeing completely with NTH
18:41:56 <tflink> I do dislike justifying NTH by "well, it's already been pushed ..."
18:42:03 <jlk> oh, I'm not using that as justification
18:42:04 <adamw> no, that's not what i'm saying.
18:42:05 <jlk> sorry
18:42:12 <jlk> I didn't mean to imply that
18:42:29 <adamw> the justification is that anaconda team believes this is how f18 should be, so we should have it this way in beta, not change it between beta and final, or not change it at all.
18:42:38 <jlk> I do genuinely think that this is something we should expose in beta if we can, but not delay the beta for it if we can't.
18:42:59 <adamw> and also i think it's the safest way to go anyway.
18:43:12 <tflink> remind me again why we entered freeze last week
18:43:14 <adamw> it's what we've done for 17 releases and what clearly works: a root account with a password.
18:43:26 <adamw> tflink: because fesco's a bunch of idiots? ;)
18:43:29 <jlk> hah
18:43:32 <jlk> my response too
18:43:39 <tflink> "here, take this unicorn I just pulled out of my ass"
18:43:55 <tflink> anyhow
18:44:11 <adamw> tflink: i'm not that happy with how this keeps changing either. which ironically is kind of why i'm in favour of *this* change
18:44:27 <adamw> because *this* change constitutes 'fine, we'll just go back to the known safe way of doing this and stop fiddling with it'. which i think is good.
18:44:41 <jlk> just please nobody suggest that the spoke goes back to the main screen, ok?
18:44:45 <adamw> heh.
18:45:02 <tflink> proposed #agreed 869675 - AcceptedNTH - While not a blocker, allowing people to install with no available users is a bad idea and if this changes, it needs to be changed now. A tested fix would be considered past freeze.
18:45:09 <adamw> ack
18:45:10 <tflink> jlk: I just started the RFE bz :-D
18:45:16 <kparal> ack
18:45:29 <Viking-Ice> ack I'm just happy if some group does not start popping up *now* asking for this or any other installer change to be changed
18:45:32 <jlk> ack
18:45:34 <tflink> #agreed 869675 - AcceptedNTH - While not a blocker, allowing people to install with no available users is a bad idea and if this changes, it needs to be changed now. A tested fix would be considered past freeze.
18:45:44 <tflink> #topic (869978) %packages --default doesn't install default system, but minimal one
18:45:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869978
18:45:49 <adamw> Viking-Ice: yeah, i have the big NO hammer ready for *any* further twiddles to this.
18:45:49 <tflink> #info Proposed NTH, anaconda, ASSIGNED
18:46:25 <jlk> yeah, this is all sorts of fun
18:46:40 * tflink notes that we have 15 minutes left until the end of our allotted 3 hours
18:46:41 <jlk> something I was hoping to look into today
18:47:03 <jlk> If I can fix it, and it's not invasive, I'd like this NTH
18:47:39 <jlk> we have run across a few cases of people with %packages --default in their kickstart files, and it's a useful bit of feature to mirror the graphical installer
18:47:50 <Viking-Ice> well arguably the default should be minimal
18:48:00 <Viking-Ice> and Bill got it wrong
18:48:05 <jlk> erm, that would make this bug only accidentally correct
18:48:34 <jlk> and it would be broken for any 3rd party setup that has a different idea as to what's default.
18:48:47 <Viking-Ice> if you think about it start with 0 ( minimal ) the alphabetically add numbers to the available DE's
18:49:08 <Viking-Ice> ( or build on top of that 0 3rd party or not )
18:49:13 <kparal> Viking-Ice: the purpose of this bug is that it is a regression. if you want to propose some changes to --default, propose them separately
18:49:24 <adamw> based on the documentation and on previous releases, the behaviour is clearly wrong.
18:49:50 <adamw> i can see the +1 nth argument; there may be people with kickstarts they've been using for a while which use %packages --default . if you were just writing a kickstart, following the documentation, it seems like the kind of thing you'd do.
18:50:01 <Viking-Ice> +1 nth
18:50:14 <adamw> and if the change only affects kickstarts, which we haven't tested heavily and only guarantee one specific working case for, it's not really hugely dangerous
18:50:28 <Viking-Ice> kparal, comps have been redesigned those documents are most likely wrong now anyhow
18:50:44 <adamw> Viking-Ice: this is the kickstart documentation, not package group docs...
18:50:44 <akshayvyas> +1 nth
18:50:54 <kparal> +1 nth
18:51:16 <Viking-Ice> on top of that we have a *new* installer so this is the time to define and get the desired behavior for future release
18:51:23 <tflink> it's interesting to me how we take NTH bugs without knowing what the fix is
18:51:35 <tflink> and we reject other NTH when we know what the fix is
18:51:58 <kparal> tflink: we don't have to take in all fixes agreed as NTH
18:52:11 <Viking-Ice> nope we dont have to
18:52:12 <jlk> tflink: NTH is about the bug, not necessarily about the fix
18:52:31 <jlk> the developer has to make a judgment call on whether the fix is too invasive or not
18:52:51 <tflink> proposed #agreed 869978 - AcceptedNTH - This is a regression in the behavior of previous versions and would be good to fix. A tested fix would be considered past freeze.
18:52:57 <Viking-Ice> ack
18:53:06 <adamw> ack
18:53:08 <kparal> ack
18:53:18 <jlk> ack
18:53:50 <tflink> #agreed 869978 - AcceptedNTH - This is a regression in the behavior of previous versions and would be good to fix. A tested fix would be considered past freeze.
18:54:38 <tflink> kparal: my issue is with our inconsistency - sometimes we say 'well, we don't have to take nth fixes' and other times we say "it's too close to X to take this; rejected nth"
18:55:00 <Viking-Ice> 8 minutes to 3 hour mark
18:55:07 <Viking-Ice> one more bug or ?
18:55:09 <kparal> is that inconsistent?
18:55:12 <adamw> how many more do we have?
18:55:22 <adamw> kparal: it's kind of fuzzy.
18:55:29 <kparal> anyway, I really want to propose some changes to NTH process, hopefully I'll write it up
18:55:33 <adamw> please do
18:55:34 <tflink> 9 proposed NTH
18:55:42 <tflink> 4 accepted blockers
18:55:42 <adamw> it's still more or less the first draft i pulled out of my ass two years ago
18:55:55 <adamw> i'm not convinced it's the best process possible :)
18:55:57 * kparal proposes to end the meeting
18:56:17 * tflink also thinks that calling them NTH is a horrible idea
18:56:22 <jlk> are any more of those NTFs anaconda?
18:56:25 <jlk> NTHs
18:56:31 <adamw> can we get through all the anaconda NTHs?
18:56:47 <adamw> we kinda need to do that so the anaconda team knows what to put in 18.22, which we want to spin today
18:56:51 <jlk> We could go with the RHEL terminology and call them "exceptions"
18:56:53 <tflink> jlk: 6 of the 9 are
18:57:03 <jlk> I'm willing to power through them if y'all are
18:57:12 <adamw> me too
18:57:21 <tflink> same here
18:57:21 <Viking-Ice> I'm gonna clock out and head home can rejoin once i'm there
18:57:29 <adamw> thanks viking, sorry for keeping you up
18:57:40 <Viking-Ice> at work more like it ;)
18:57:44 <adamw> =)
18:58:09 <kparal> I don't feel well, I think I'll just lurk
18:58:38 <tflink> I just think that it's a misnomer. we know what NTH really means but when you tell someone unfamilar with the process that a bug was rejected as NTH, doesn't that sound like "your bug isn't a big enough problem for us to care about"?
18:58:42 <tflink> but I go off in the weeds
18:59:01 <tflink> #topic (870570) Anaconda needs to retry downloading the repo medata on a network config change
18:59:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=870570
18:59:07 <tflink> #info Proposed NTH, anaconda, ASSIGNED
18:59:25 <jlk> another on my hitlist for today
18:59:38 <adamw> tflink: i think everyone pretty much agrees the NTH name is terrible, as is the -accepted alias. i'm happy if we improve 'em.
19:00:09 <adamw> this one is pretty annoying any time you're switching around network install
19:00:21 <adamw> as dennis said it can actually be pretty tough to figure out what to do to force it to 'reinit'
19:00:22 <jlk> yeah, I agree.  We should get this in if we can
19:00:47 <adamw> otoh, it's pretty fuzzy and in a sensitive area
19:00:57 <adamw> and isn't breaking anything critical for beta
19:01:13 <jlk> yup, I promise to be careful :)
19:01:16 <nirik> +1 nth here. (we don't need to take it if it blows up things?)
19:01:19 <tflink> I'm ok with NTH but I would like to see the patch as an update.img before it's pushed, if possible and reasonable
19:01:26 <adamw> yeah, i'm with tflink on that
19:01:39 <jlk> comment in the bug to that effect and it shall be done
19:01:44 <adamw> i think this will be less of a practical issue if we fix up all the network hub issues
19:01:56 <adamw> because then people should usually arrive at the hub with a working network. we hope.
19:03:04 <tflink> proposed #agreed 870570 - AcceptedNTH - This would allow for networking configuration changes during install configuration, would be useful and can't be fixed with an update. A tested fix would be considered past freeze but we request an updates.img to test before the patch is pushed.
19:03:11 <adamw> ack
19:03:26 <adamw> maybe 'eases' rather than 'would allow for'
19:03:35 <adamw> you _can_ do it at present, it's just a pain and non-obvious
19:03:37 <nirik> ack
19:04:03 <tflink> proposed #agreed 870570 - AcceptedNTH - This makes networking configuration changes during install configuration easier and more obvious, would be useful and can't be fixed with an update. A tested fix would be considered past freeze but we request an updates.img to test before the patch is pushed.
19:04:05 <jlk> ack
19:04:42 <adamw> ack
19:04:46 <nirik> sure ack
19:04:51 <tflink> #agreed 870570 - AcceptedNTH - This makes networking configuration changes during install configuration easier and more obvious, would be useful and can't be fixed with an update. A tested fix would be considered past freeze but we request an updates.img to test before the patch is pushed.
19:05:00 <tflink> #topic (871554) NFSISO installs fail to reboot: SystemError: (16, 'umount.nfs: /run/install/isodir: device is busy')
19:05:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871554
19:05:05 <tflink> #info Proposed NTH, anaconda, ASSIGNED
19:05:15 <jlk> I'm... not sure this is still a bug.
19:05:22 <jlk> I can't reproduce it with the current code I'm working on
19:05:38 <jlk> note though, nfsiso is in pretty bad shape right now
19:05:38 <nirik> punt and retest?
19:06:02 <tflink> I forget, is nfsiso required for beta?
19:06:22 <adamw> didn't we have a bug for this back in 17?
19:06:32 <adamw> tflink: either NFS or NFSISO
19:06:32 <adamw> i think was what we decided on
19:06:38 <jlk> it's an either or
19:06:42 <adamw> "The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options "
19:06:44 <jlk> both required for Final
19:06:46 <tflink> yeah, I couldn't remember what we decided for beta and if it's different for final
19:07:55 <jlk> anyway, I think this does need a punt and re-test, because I think it'll be fixed by way of fixing other nfsiso issues
19:08:15 <tflink> wait a sec, how did this get on the proposed NTH list
19:08:15 <jlk> like the fact you couldn't even select an nfsiso repo until my fix from yesterday.
19:08:21 <adamw> jlk proposed it.
19:08:24 <jlk> oops :)
19:08:25 <tflink> its RH only
19:08:26 <adamw> +1 punt
19:08:30 <adamw> it's a clone of an RH report.
19:08:38 <adamw> cloned for fedora, though not really clearly stated.
19:08:39 <jlk> oooh!
19:08:40 <jlk> right
19:08:42 <jlk> dur
19:08:56 <jlk> I think I was using this bug as a catchall for the nfsiso issues I was chasing
19:08:59 <adamw> it's also RH employee only and blocking rhel70rtt at present
19:09:08 <jlk> oh hah, forgot to clear the flag
19:09:20 <adamw> i think you need to Fedorize it a bit more :)
19:09:22 <tflink> which explains how that tracking bug got pulled in and screwed up my entire blocker list last night
19:09:22 <jlk> flag cleared.
19:09:27 <adamw> anyway, aside from that, punt till it's clearer.
19:09:28 <jlk> ah.
19:09:42 <adamw> jlk: canada's off the hook, now we're blaming you.
19:09:49 <tflink> I was wondering how that happened but it went away this morning
19:09:51 <jlk> actually I take back my earlier statements
19:10:00 <tflink> there were almost 100 proposed blockers last night :)
19:10:14 <jlk> this is the bug I'm using to track NFSISO fixes
19:10:15 <tflink> but I digress
19:10:17 <jlk> there are a few of them
19:10:27 <jlk> all sort of related to just "nfsiso is broken"
19:10:39 <adamw> it would be nice to have tighter focus on that.
19:10:51 <adamw> can you clarify the bug description and, if we take this as NTH, restrict it to critical fixes?
19:10:58 <adamw> i.e. stuff needed to make nfsiso work
19:11:07 <adamw> i'm +1 nth to 'nfsiso doesn't work', but with a tight focus.
19:11:09 <jlk> that's what I'm doing, I could split out more bugs I suppose
19:11:17 <jlk> what I know now:
19:11:18 <adamw> how bout this
19:11:24 <adamw> gimme 2 minutes and i shall transform the bug
19:11:29 <jlk> 1) inability to make use of nfsiso if chosen in gui spoke
19:12:04 <jlk> 2) inability to use nfsiso if set as a inst.repo= argument
19:12:25 <jlk> (yes, there are two separate problems there)
19:12:29 <adamw> okay
19:12:40 <adamw> as this was filed from an inst.repo attempt, make it the bug for inst.repo nfsiso doesn't work?
19:12:47 <jlk> sure
19:13:06 <jlk> there are some other bugs, where if started from nfsiso, switching to nfs  or a different nfsiso location may break
19:13:25 <jlk> or if you've ever setup an nfsiso source switching to another nfs or nfsiso related source may break
19:13:33 <jlk> but those can be punted to post-beta
19:13:45 <adamw> and with 2)..the bug isn't just if you actually literally pass repo=nfsiso:blah ,right/
19:13:46 <adamw> ?
19:14:01 <adamw> it's not that it works if you pass repo=nfs:blah , even if blah is an ISO?
19:14:12 <adamw> it's the actual nfs iso function itself that doesn't work?
19:14:16 <zodbot> Ticket notification - f18betanicetohave: [Bug 871554] NFSISO installs fail to reboot: SystemError: (16, 'umount.nfs: /run/install/isodir: device is busy') <https://bugzilla.redhat.com/show_bug.cgi?id=871554>
19:14:40 <jlk> adamw: the actual function itself isn't working.  We're failing to do the right thing with any found .iso in the mount path
19:14:44 <adamw> okay
19:14:51 <jlk> that's the easier of the fixes
19:15:09 <adamw> so if we consider this bug to be 'you can't install via NFS ISO when passing inst.repo on the cmdline' i am +1 nth to that.
19:15:19 <adamw> obviously it'd be nice to have that testable in beta.
19:15:37 <adamw> i can edit the bug to reflect that as part of the secretaryization if we're all happy with the idea.
19:16:11 <adamw> anyone else?
19:16:22 <tflink> proposed #agreed 871554 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze.
19:16:59 <jlk> ack
19:17:02 <nirik> ack
19:17:12 <adamw> ack
19:17:18 <tflink> #agreed 871554 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze.
19:17:21 <jlk> if we are splitting this though, I'd like to get an NTH on the split out bug for the second problem.
19:17:32 <jlk> oh geez
19:17:37 <jlk> I misread adamw's question
19:18:46 <jlk> adamw: your question has mostly the same answer for problem 2, except that it's a problem with how the yumpayload object is initialized that breaks things, not with what we do with the .iso file
19:18:57 <jlk> problem 1 is what we do with the iso file
19:20:39 <adamw> jlk: that's fine, i just wanted to make sure it's not as simple a case as 'the workaround is just to pass repo=nfs not repo=nfsiso'
19:20:46 <jlk> correct
19:20:49 <adamw> jlk: i'll file a split out bug and nominate that for NTH
19:20:53 <jlk> k
19:21:03 <adamw> so right now we have accepted NTH for nfsiso-via-inst.repo-fails
19:21:06 <tflink> we're still OK with the #agreed, though?
19:21:10 <jlk> yeah
19:21:19 <adamw> we do not have accepted NTH for nfsiso-via-interactive-fails, but i will split that out and propose it
19:21:31 <adamw> i wasn't planning to file/propose anything further yet, we can sort that out later
19:21:33 <adamw> is that plan ok?
19:21:52 <jlk> ok
19:22:30 <adamw> ok, i think we're good
19:22:41 <tflink> #topic (871648) Cannot use nfsiso repo through graphical source picker
19:22:41 <zodbot> Ticket notification - f18betanicetohave: [Bug 871554] Cannot use an 'NFS ISO' repository (NFS share containing a Fedora ISO image) passed as inst.repo on cmdline <https://bugzilla.redhat.com/show_bug.cgi?id=871554>
19:22:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871648
19:22:41 <tflink> #info Proposed NTH, anaconda, POST
19:23:02 <jlk> hey look at that.
19:23:18 <jlk> +1 :)
19:24:10 <jlk> I guess I did split it out
19:24:17 <jlk> clearly I was drunk last night
19:24:29 <jlk> adamw: looks like you don't need to file a separate bug
19:25:19 <adamw> er, no
19:25:25 <adamw> that's the bug we just acked :)
19:25:37 <adamw> i hacked it up as part of the secretaryization.
19:25:41 <adamw> i am secretaryizing in realtime.
19:25:57 <jlk> really?
19:26:05 <jlk> Reported: 	2012-10-30 19:52 EDT by Jesse Keating
19:26:08 <tflink> adamw: this list was generated hours ago
19:26:09 <adamw> in a few seconds we should see a notification for 871943 , which is the bug I just filed for the interactive case :)
19:26:13 <adamw> ohh, sorry
19:26:23 <adamw> i saw the 'Ticket notification' and thought we were talking about that
19:26:27 <adamw> not the next bug on the list :)
19:26:27 <jlk> oh
19:26:35 <adamw> okay, i'll close the dupe i just filed, d'oh
19:26:56 <jlk> sorry, I must have been drunk or something and couldn't remember what all I did here
19:27:07 <jlk> but looks like I was trying to be a good boy and split out the bugs to separately propose them
19:27:11 <adamw> yay you
19:27:14 <adamw> sorry for confusion
19:27:18 <tflink> pretty much the same as the last NTH?
19:27:40 <tflink> proposed #agreed 871648 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze.
19:27:44 <adamw> it kinda seems like we should take both, yeah
19:27:47 * adamw looks at the patch
19:28:05 <jlk> ack
19:28:15 <nirik> ack
19:28:21 <jlk> this bug is actually the easier fix
19:28:28 <adamw> https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-October/001845.html for anyone interested
19:28:30 <adamw> ack
19:28:42 <adamw> though whenever i see anaconda code that mounts stuff, things start itching.
19:29:26 <jlk> I will note that the patch is getting some discussion upstream, so the final version may be slightly different, but the concept is the same
19:29:59 <tflink> #agreed 871648 - AcceptedNTH - While NFSISO isn't required for beta, having it testable in beta would be helpful for final. A tested fix would be considered past freeze.
19:30:06 <tflink> #topic (869106) F18 anaconda chokes on wireless network names containing spaces
19:30:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869106
19:30:12 <tflink> #info Proposed NTH, anaconda, MODIFIED
19:31:11 <jlk> +1 NTH
19:31:20 <adamw> +1 for me, this is obviously gonna be a problem if your AP has a space in it. :)
19:31:41 <adamw> that's probably not enough APs to block release, but seems polite to fix it.
19:32:22 <jlk> would suck if hte dudes in "FBI Surveillance Van" weren't able to do an install!
19:32:34 <adamw> hehe.
19:32:38 <tflink> proposed #agreed 869106 - AcceptedNTH - While not incredibly common, there are wireless APs whose names contain spaces. Not enough to block release over but fixing prior to beta release would be preferred. A tested fix would be considered past freeze/
19:32:43 <tflink> proposed #agreed 869106 - AcceptedNTH - While not incredibly common, there are wireless APs whose names contain spaces. Not enough to block release over but fixing prior to beta release would be preferred. A tested fix would be considered past freeze.
19:32:45 * satellit that may be why my Apple Network xxxxxxx fails !
19:32:45 <jlk> ack
19:32:47 <adamw> ack
19:32:51 <adamw> satellit: probably, yeah.
19:33:31 <tflink> moar ack?
19:33:53 <jreznik> ack (back from Board meeting)
19:33:53 <tflink> #agreed 869106 - AcceptedNTH - While not incredibly common, there are wireless APs whose names contain spaces. Not enough to block release over but fixing prior to beta release would be preferred. A tested fix would be considered past freeze.
19:34:11 <tflink> #topic (871132) Protected wifi connection not enabled after secrets are set, user has to re-select it
19:34:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871132
19:34:16 <tflink> #info Proposed NTH, anaconda, NEW
19:35:12 <adamw> while we're making networking not suck, sure, i guess.
19:35:35 <jlk> yeah, +1.  We can let the anaconda dev team nack it for beta if the fix is too invasive
19:36:03 <tflink> I could go either way on this one, to be honest
19:36:35 <adamw> in strict NTHland it's obviously a pretty small fix, but for me the swaying factor is this whole area has been broken to hell anyway.
19:36:39 <adamw> so cleaning it up seems a good thing.
19:36:49 <adamw> it's not like this is known-solid code we're fiddling with.
19:37:07 <tflink> how does that decrease the risk of taking a patch?
19:38:05 <adamw> it decreases the comparative risk of taking a patch, as the risk isn't 'we could screw up this well-tested and known reliable codepath'...
19:38:23 <adamw> these are just the bugs that emerged within about ten minutes of wifi being made not-utterly-broken
19:38:38 <tflink> so it changes to 'we could screw up this codebase that might be just getting stable'
19:38:50 <adamw> i guess.
19:39:27 <tflink> proposed #agreed 871132 - AcceptedNTH - While not a big enough problem to block release, it is an annoyance and can't be fixed with an update. A tested fix would be considered past freeze.
19:39:58 <adamw> ack, with caveat that we think this isn't a really important change and it should be merged only if we're really pretty confident in it.
19:40:07 <adamw> i can note that in the bug.
19:40:07 <jlk> ack
19:40:15 <tflink> #agreed 871132 - AcceptedNTH - While not a big enough problem to block release, it is an annoyance and can't be fixed with an update. A tested fix would be considered past freeze.
19:40:23 <tflink> OK, that's all of the anaconda proposed NTH
19:40:27 <tflink> we have 4 more
19:40:34 <tflink> I'd like to do the XFCE one
19:40:38 <jlk> ok, sorry, I'm checking out.  Have to have lunch with fam.
19:40:52 * nirik perks up
19:41:05 <tflink> maybe firstboot
19:41:38 <tflink> do we have enough people to do that?
19:41:45 <tflink> after almost 4 hours?
19:42:03 * adamw is still here
19:42:05 * nirik is still around, but not sure how many others.
19:42:44 * Viking-Ice 1/3 in 1/3 cooking 1/3 watching the match against white Russia
19:42:48 <adamw> the firstboot one of course gets less important if we're gonna force root password in all cases now...
19:43:13 <tflink> so let's do the xfce one and be done for today?
19:43:26 <tflink> #topic (870781) keyboard shortcuts patch got lost during Xfce 4.10 update
19:43:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=870781
19:43:26 <tflink> #info Proposed NTH, libxfce4ui, ON_QA
19:43:29 <adamw> well we've had firstboot 18.4/18.5 in the last bunch of TCs so we should probably just go ahead and ack it
19:43:36 <adamw> 18.4/18.5 probably has more testing than 18.3 now
19:43:47 <nirik> +1 nth.
19:44:02 <adamw> +1 if cwickert wants it.
19:44:07 * adamw trusts the wickert.
19:44:13 <tflink> yeah, I'm ok with +1 since it's a regression
19:44:26 <nirik> yeah, it would be... nice to have.
19:44:28 <nirik> (ha)
19:44:38 <adamw> hey, we should call the bugs that!
19:45:08 <tflink> proposed #agreed 870781 - AcceptedNTH - This fixes a functionality regression in XFCE when compared to previous versions of Fedora. A tested fix would be considered after freeze.
19:45:54 <tflink> ack/nak/patch?
19:47:06 <nirik> ack
19:47:59 <adamw> ack
19:48:25 <tflink> #agreed 870781 - AcceptedNTH - This fixes a functionality regression in XFCE when compared to previous versions of Fedora. A tested fix would be considered after freeze.
19:48:29 <tflink> #topic (856194) firstboot has to insist the first user is admin when root account is locked
19:48:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856194
19:48:34 <tflink> #info Proposed NTH, firstboot, ON_QA
19:49:25 <tflink> proposed #agreed 856194 - AcceptedNTH - Allowing for an install with no admin or root users is not desirable and should probably be fixed. A tested fix would be considered past freeze.
19:49:29 <tflink> ack/nak/patch?
19:49:34 <Viking-Ice> ack
19:49:37 <adamw> as i said, this kinda becomes a null issue if we take the change to force root pw, but in theory we ought to cover that case and we've been testing it forever
19:49:39 <adamw> so ack
19:50:02 <nirik> ack
19:50:10 <tflink> #agreed 856194 - AcceptedNTH - Allowing for an install with no admin or root users is not desirable and should probably be fixed. A tested fix would be considered past freeze.
19:50:18 <tflink> OK, any objections with being done for now?
19:50:35 <tflink> we have 2 unreviewed proposed NTH and 4 accepted blockers
19:50:50 <tflink> I imagine that a meeting tomorrow before go/no-go wouldn't hurt, either
19:50:52 <Viking-Ice> nope
19:50:55 <adamw> i'm fine
19:50:57 * nirik doesn't care either way
19:51:08 <adamw> i'm not sure if we need a meeting before go/no-go. no-go is pretty freaking obvious.
19:51:24 <tflink> but upgrade might be done by then
19:51:29 <tflink> :-D
19:51:42 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=871888 seems to have been added to the propsoed blocker list
19:51:47 <Viking-Ice> we can just give them our answer now
19:51:55 <Viking-Ice> jreznik, what's your take?
19:52:38 <adamw> Viking-Ice: well we'll show up for the meeting of course. but i don't think we need a pre-meeting to agree our position. i can't see any position but no-go.
19:52:50 <adamw> shall we do 871888 before we wrap up?
19:54:10 * adamw is -1 as kparal said it doesn't seem reproducible
19:54:10 <jreznik> probably not, but go/no-go time could be used
19:54:17 <tflink> #topic (871888)  AttributeError: 'YumPayload' object has no attribute '_yum'
19:54:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=871888
19:54:18 <tflink> #info ProposedBlocker, anaconda, NEW
19:55:01 <Viking-Ice> -1
19:55:20 <adamw> -1, not reproducible (i actually was trying this at the same time as kparal and it didn't happen to me, so seems like a rare issue)
19:55:30 <adamw> probably timing
19:56:11 <tflink> proposed #agreed 871888 - RejectedBlocker - While severe, this doesn't seem to be happening often enough to justify blocking F18 beta. Please repropose if this starts happening more often.
19:56:14 <tflink> or a bad mirror
19:56:23 <nirik> would be nice to know what mirror/conditions.
19:56:24 <Viking-Ice> ack
19:56:24 <adamw> ack
19:56:25 <nirik> but yeah.
19:56:26 <nirik> ack
19:56:32 <tflink> #agreed 871888 - RejectedBlocker - While severe, this doesn't seem to be happening often enough to justify blocking F18 beta. Please repropose if this starts happening more often.
19:56:35 <adamw> nirik: that's probably in the logs
19:56:46 <tflink> alrighty, time for:
19:56:55 <tflink> #topic Open Floor
19:57:02 <tflink> Anything else that needs to be brought up?
19:57:22 <adamw> can't think of anything
19:57:26 <tflink> it sounds like the plan is to use go/no-go time instead of a meeting continuation tomorrow?
19:58:01 * nirik can't find it, but ok.
19:58:07 <adamw> oh, we were thinking about how to review the remaining nth? sorry, i was thinking we were talking about having a meeting to decide on whether we would vote go/no-go
19:58:25 <adamw> i don't mind a short blocker/nth review continuation tomorrow, sorry if i confused that
19:58:43 <tflink> ok, we can cover anything else  that may come up before then too
19:59:04 <tflink> #info the blocker review will continue tomorrow: 2012-11-01 @ 16:00 UTC
20:00:08 <tflink> if there's nothing else ...
20:00:24 * tflink sets the fuse for [0,eleventymillion] minutes
20:01:02 <tflink> Thanks for coming everyone!
20:01:08 * tflink will send out minutes shortly
20:01:12 <tflink> #endmeeting