17:00:14 <jlaska> #startmeeting F16-Alpha-blocker-review 17:00:14 <zodbot> Meeting started Fri Jul 29 17:00:14 2011 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:18 <jlaska> #meetingname F16-Alpha-blocker-review 17:00:18 <zodbot> The meeting name has been set to 'f16-alpha-blocker-review' 17:00:22 <jlaska> #topic Roll Call 17:00:48 <adamw> yo 17:00:50 <athmane> hello everyone 17:00:53 * tflink is here 17:00:54 <jlaska> okay ... who is ready to beat these bugs into submission this week? 17:00:57 * brunowolff is here 17:01:25 <clumens> THUD 17:01:34 <jlaska> greetings all! 17:01:37 * tflink gets out the newspaper for bug squashing 17:01:41 <jlaska> heh 17:01:49 <jlaska> another minute or so for others to join 17:02:00 <jlaska> please choose appropriate musak to pass the time 17:02:38 * jlaska hears the soothing sounds of Kenny G 17:02:50 * adamw turns up the atari teenage riot 17:03:14 <jlaska> alright ... times up ... let's get this party started 17:03:21 <jlaska> #topic Why are we here? 17:03:22 * nirik is lurking 17:03:29 <jlaska> Only the FPL knows why we are here 17:03:33 * dgilmore is listing to a little Don Omar 17:03:45 <jlaska> but some links for those who want to try the home-version of the game ... 17:03:48 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:03:49 * dgilmore just added 2 blocker bugs 17:04:01 <jlaska> I'll be working off of the list of blockers at ... 17:04:02 <jlaska> #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:04:08 * jlaska updates list now 17:04:28 <jlaska> and of course, we're all familiar with the release criteria ... 17:04:29 <jlaska> #link https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria 17:04:52 <jlaska> any preference to start with accepted or proposed blockers? 17:05:06 <dgilmore> jlaska: proposed 17:05:14 <jlaska> alright ... 1-0 ... proposed has it 17:05:31 <jlaska> any volunteers to "process" the bugs as we proceed through the meeting? 17:05:40 <tflink> I can do that 17:05:47 <jlaska> thank you tflink! 17:06:02 <jlaska> starting with proposed blockers ... 17:06:04 <jlaska> #link http://bugzilla.redhat.com/show_bug.cgi?id=723475 17:06:05 <buggbot> Bug 723475: unspecified, unspecified, ---, rvykydal, NEW, anaconda-16.12 - Unable to activate networking in anaconda (stage2) 17:06:09 <jlaska> #info anaconda-16.12 - Unable to activate networking in anaconda (stage2) 17:06:22 <jlaska> we discussed this last week, but were unable to come to a decision 17:07:00 <jlaska> I've done some additional testing on this issue since then 17:07:08 <tflink> I'm a little confused on whether the original issue has been fixed or not 17:07:14 <jlaska> from what I can tell, the original problem is no longer happening 17:07:17 <tflink> it sound like we're waiting for a branched compose before going forward 17:07:20 <jlaska> but there are remaining issues 17:07:34 <jlaska> tflink: yeah, I'd feel comfortable waiting until we have a TC1 to play with before closing this out 17:07:56 <jlaska> but from what I can tell, the original problem may have magically fixed itself 17:08:28 <adamw> yay magic fixes 17:08:30 <jlaska> aside from that, I don't think we have any new information on the impact of the problem 17:08:32 <tflink> do we want to wait for the branched compose before spliting off the other issues described in that bug? 17:08:36 <clumens> that'd be nice 17:08:38 <jlaska> yeah 17:08:41 <clumens> if disconcerting. 17:08:55 <jlaska> those other issues I highlighted aren't horrible ... I don't think 17:09:05 <jlaska> but we'll likely discuss in the $future 17:09:13 <jlaska> ... while in our flying cars 17:09:22 <dgilmore> jlaska: at the least its nice to have and ill pull it in 17:09:24 <jlaska> so ... what to do with this bug 17:09:35 <dgilmore> having to do manual steops for working networking sucks 17:10:09 <jlaska> proposed #agreed 723475 - pending updated testing from TC1, issue may have magically fixed itself 17:10:13 <jlaska> ack/nak/patch? 17:10:44 <clumens> ack 17:10:52 <tflink> what about the other issues described? 17:11:04 <jlaska> I mentioned above ... we'll deal with them when they get filed 17:11:09 <dgilmore> ack 17:11:24 <tflink> ack 17:11:25 <adamw> ack 17:11:29 <jlaska> #agreed 723475 - pending updated testing from TC1, issue may have magically fixed itself 17:11:44 <jlaska> #info will address additional possible bugs when TC1 arrives 17:11:59 <jlaska> tflink: I don't have enough information/debugging on them yet for us to decide anything 17:12:17 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=726744 17:12:19 <buggbot> Bug 726744: unspecified, unspecified, ---, mclasen, NEW, at-spi-python has broken deps 17:12:22 <jlaska> #info at-spi-python has broken deps 17:12:29 <dgilmore> +1 to being a blocker 17:12:35 <jlaska> I assume this impacts "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install " 17:12:39 <dgilmore> we have no images without it fixes 17:12:42 <dgilmore> fixed 17:12:44 <adamw> i believe this would also break live compose, right? 17:12:56 <dgilmore> adamw: not sure about live compose 17:13:02 <jlaska> this seems like a no-brainer, +1 blocker 17:13:03 <dgilmore> but it breaks dvd compose 17:13:39 <jlaska> proposed #agreed 726744 - AcceptedBlocker for Alpha - impacts Alpha repoclosure criteria and preventing ISO compose 17:13:42 <jlaska> ack/nak/patch? 17:13:43 <brunowolff> +1 17:13:45 <tflink> ack 17:14:27 <dgilmore> +1 17:14:34 <jlaska> that's 3 votes for agreed ... good'nuff 17:14:39 <jlaska> #agreed 726744 - AcceptedBlocker for Alpha - impacts Alpha repoclosure criteria and preventing ISO compose 17:14:46 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723526 17:14:47 <buggbot> Bug 723526: high, unspecified, ---, mgracik, MODIFIED, firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot 17:14:51 <jlaska> #info firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot 17:15:15 <jlaska> robatino: where does this issue stand ... you were able to confirm it is fixed? 17:15:38 <robatino> jlaska: the originally reported issue was fixed with the earlier firstboot 17:15:52 <tflink> time to close it out, then? 17:16:09 <robatino> haven't tried the newer firstboot 17:16:26 <jlaska> dgilmore: what version of firstboot is in f16 and ready for the branch compose? 17:16:49 <jlaska> howabout ... 17:17:04 <dgilmore> koji latest-pkg f16 firstboot 17:17:04 <dgilmore> Build Tag Built by 17:17:08 <dgilmore> ---------------------------------------- -------------------- ---------------- 17:17:11 <dgilmore> firstboot-16.1-2.fc16 f16 mgracik 17:17:15 <jlaska> proposed #agreed 723526 - Move to VERIFIED, leave open pending TC1 branch compose 17:17:18 <jlaska> ack/nak/patch? 17:17:19 <jlaska> dgilmore: thanks! 17:17:29 <adamw> ack 17:17:30 <jlaska> all signs indicate this will land in TC1 17:17:31 <dgilmore> ack 17:17:37 <brunowolff> +1 17:17:40 <tflink> ack 17:17:41 <jlaska> note ... I'm making no determination as to whether it's a blocker 17:17:46 <jlaska> kind of a cop-out, but meh 17:18:09 <jlaska> #info firstboot-16.1-2.fc16 destined for TC1 compose ... should resolve this issue 17:18:14 <jlaska> #agreed 723526 - Move to VERIFIED, leave open pending TC1 branch compose 17:18:21 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=725566 17:18:22 <buggbot> Bug 725566: unspecified, unspecified, ---, mgracik, MODIFIED, firstboot doesn't default to enabled after rawhide/F16 install 17:18:25 <jlaska> #info firstboot doesn't default to enabled after rawhide/F16 install 17:18:38 <jlaska> kind of the same status as the previous bug 17:18:50 <jlaska> confirmed the fix, I'll move to VERIFIED and we can just close it once we get TC1 17:19:36 <jlaska> as far as blocker worthiness ... it's a blocker ... 17:19:37 <dgilmore> ok 17:19:47 <dgilmore> ack +1 blocker 17:19:53 <jlaska> well, it means no firstboot without manual intervention 17:20:07 <jlaska> #info impacts alpha criteria - "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The 17:20:08 <adamw> yeah, seems to hit the criteria. 17:20:15 * jlaska works up proposed ... 17:20:45 <jlaska> proposed #agreed 725566 - AcceptedBlocker for Alpha - impacts Alpha firstboot criteria, fix VERIFIED, will move to CLOSED when TC1 arrives 17:20:49 <jlaska> ack/nak/patch? 17:20:59 <adamw> ack 17:21:15 <tflink> ack 17:21:27 <jlaska> that's 3 (including dgilmore's vote) 17:21:33 <jlaska> #agreed 725566 - AcceptedBlocker for Alpha - impacts Alpha firstboot criteria, fix VERIFIED, will move to CLOSED when TC1 arrives 17:21:39 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=725040 17:21:40 <buggbot> Bug 725040: unspecified, unspecified, ---, tcallawa, MODIFIED, rawhide installs generic-release package, instead of fedora-release 17:21:44 <jlaska> #info rawhide installs generic-release package, instead of fedora-release 17:21:57 <jlaska> I believe this resolved itself with the updated generic-release package 17:22:10 <jlaska> what an oddball lesson in dependency handling 17:22:26 <dgilmore> jlaska: indeed 17:22:43 <jlaska> I think this needs the same treatment ... 17:22:59 <dgilmore> ill gladly ack it as a blocker 17:22:59 <adamw> i did check a live image post-new-generic-release and it included fedora-release 17:23:04 <adamw> so it looks like it's fixed now, yup 17:23:15 <jlaska> yeah, I confirmed with a custom boot.iso install as well 17:23:39 <jlaska> proposed #agreed 725040 - move to VERIFIED, will move to CLOSED pending TC1 17:23:47 <brunowolff> +1 17:23:48 <jlaska> I'm still unclear whether this needs to be accepted as a blocker 17:24:04 <adamw> let's not worry about it. 17:24:08 <tflink> did we ever figure out what the effects were? 17:24:19 <tflink> +1 on what adamw said, though 17:24:33 <dgilmore> tflink: it really should only effect an install if you point it at the rawhide repos 17:24:36 <jlaska> tflink: yeah, fedora-release wouldn't get installed, and therefore no fedora-release-rawhide 17:24:41 <jlaska> so no valid repos avilable post install 17:24:44 <dgilmore> though maybe the Everything one also 17:25:09 <jlaska> #agreed 725040 - move to VERIFIED, will move to CLOSED pending TC1. Unclear impact on Alpha, but a valid rawhide fix 17:26:17 <jlaska> #info while the impact to the Alpha isn't fully understood ... since the issue is resolved the group decided acceptance as a blocker isn't required 17:26:22 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=726743 17:26:23 <buggbot> Bug 726743: unspecified, unspecified, ---, walters, NEW, gnome-python2-bonobo has missing deps 17:26:26 <jlaska> #info gnome-python2-bonobo has missing deps 17:26:34 <jlaska> dgilmore, looks like another you found? 17:26:43 <adamw> what needs gnome-python2-bonobo? 17:26:47 <adamw> that should be a fairly dead letter 17:26:57 <jlaska> the poor bonobo 17:27:14 <adamw> oh, a couple of s-c-* tools and at-spi-python...hm 17:27:16 <dgilmore> jlaska: yeah same deal as at-spi 17:27:29 <jlaska> #info Alpha criteria affected - "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install " 17:27:30 <adamw> so, if it affects compose, it's a no-brainer...and we should probably get the desktop team on it 17:27:32 <adamw> +1 17:27:48 <dgilmore> +1 obviously 17:27:49 <jlaska> adamw: do you mind bringing this up over there? 17:28:00 <jlaska> (or anyone else that wants to volunteer) 17:28:20 <jlaska> #agreed 726743 - AcceptedBlocker for Alpha - preventing ISO creation 17:28:31 <adamw> sure, i will 17:28:36 <jlaska> adamw: thank you 17:28:57 <jlaska> #action adamw [was] volunteered to contact desktop@ regarding 726743 17:29:01 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723160 17:29:02 <buggbot> Bug 723160: unspecified, unspecified, ---, rstrode, NEW, Gnome-shell presents enormous warning dialog 17:29:06 <jlaska> #info Gnome-shell presents enormous warning dialog 17:29:24 <jlaska> I'm still not able to reproduce this issue in my KVM guest testing ... I see the expected dialog - http://jlaska.fedorapeople.org/screenshots/Screenshot2.png 17:29:58 <tflink> is it a difference in setups, then? 17:30:00 <jlaska> oh wait ... adamw and kparal are discussing fallback mode 17:30:27 <jlaska> tflink: yeah, could be 17:30:46 * jlaska watching the .ogv kparal attached 17:30:48 <jlaska> that's wild 17:31:18 <jlaska> "You 17:31:21 <jlaska> have to force failsafe mode to trigger this behavior" 17:31:25 <jlaska> that I did not try 17:31:35 <adamw> i'm guessing it's vesa driver specific 17:32:00 <jlaska> I don't see any Alpha criteria about fallback, unless I'm missing them 17:32:35 <jlaska> so logging into GNOME when using fallback presents an ugly dialog ... any proposals? 17:32:40 <adamw> we don't split it out in the criteria 17:32:48 <jlaska> adamw: oh true 17:32:58 <jlaska> which means both are expected to work then? 17:33:02 <adamw> i just consider it part of the 'boot successfully to a graphical desktop' criterion 17:33:07 <jlaska> okay 17:33:11 <adamw> yeah, with consideration made of proportions 17:33:12 <dgilmore> -1 to alpha blocker 17:33:21 <dgilmore> i would say at best nice to have 17:33:49 <adamw> hum 17:33:50 <adamw> "In VMs I tried cirrus and wmvga video drivers, for both the same issue occurs." 17:33:57 <adamw> jlaska: what video adapter does your VM have? 17:33:57 <tflink> I wonder if this still happens if you force fallback in other ways 17:33:58 <dgilmore> adamw: gettinga warning dialog is still booting successfully to a graphical desktop 17:34:06 <adamw> dgilmore: read the initial description 17:34:11 <adamw> it's not the fact that there's a dialog that's the problem 17:34:15 <jlaska> cirrus 17:34:37 <jlaska> It is possible to close the dialog with Enter. Xorg then restart into GDM. The 17:34:40 <jlaska> login is no longer possible, you just see error message "Gnome 3 encountered 17:34:43 <jlaska> some problems." (or similar) and button "Log out". 17:34:50 <adamw> dgilmore: you see the very top corner of an unreasonably gigantic dialog that you can't interact with at all, and X is using 1.3GB of RAM. 17:35:18 <jlaska> remind an old man ... how do you force fallback when booting an installed system? 17:35:54 <dgilmore> adamw: its still a graphical desktop :) 17:36:00 <dgilmore> not a useable one 17:36:32 <jlaska> if this bug means that fallback mode is completely useless ... I'd at least recommend getting some extra eyes on it so we can narrow down the cause? 17:36:34 <adamw> according to the initial report, if you force the dialog to close with esc, it goes back to gdm which refuses to let you log in 17:36:41 * jlaska nods 17:36:46 <adamw> jlaska: from gnome control panel, but the thing is, that doesn't display the warning dialog... 17:36:56 <jlaska> adamw: oh sorry, I meant as a boot option 17:37:05 <tflink> jlaska: IIRC, symlink /usr/share/gnome-session/sessions/gnome-fallback.session to gnome.session 17:37:06 <jlaska> like 'nomodeset' or something ... but there's more to it than that, right? 17:37:11 <dgilmore> i think we need some more info, definete reproducer 17:37:13 <adamw> jlaska: 'nomodeset' would do the trick 17:37:16 <jlaska> adamw: okay 17:37:20 <adamw> dgilmore: well, kamil clearly has reproducers 17:37:20 <brunowolff> If this is going to break vm testing, I think that is a significant subset of systems that we would like to have work for the alpha. 17:37:34 <adamw> brunowolff: we specifically make VMs a beta issue, but kamil has this happening on bare metal 17:37:39 <tflink> kamil mentions booting with the "save video" option 17:37:43 <dgilmore> adamw: jlaska cant reproduce it though 17:37:48 <adamw> tflink: that's on live images and the installer 17:37:49 <adamw> dgilmore: yeah 17:37:50 <jlaska> dgilmore: I haven't tried yet 17:37:59 <dgilmore> maybe its effected by the host hardware 17:38:00 <dgilmore> ? 17:38:03 <jlaska> dgilmore: testing now with 'nomodeset' which should mimic kparal's test 17:38:04 <adamw> dgilmore: could be 17:38:11 <tflink> adamw: the symlink method or the boot option? 17:38:16 <adamw> proposal: let's all test it as best we can 17:38:21 <adamw> tflink: the bootloader option 17:38:29 <adamw> tflink: you don't get it on installed systems, only on live images and installer images 17:38:41 * jlaska not able to reproduce while booting installed system with 'nomodeset' 17:38:47 * adamw will test his system too 17:38:50 <adamw> and a vm 17:39:00 <adamw> shall we all test it and post our results in the report? 17:39:07 <adamw> then evaluate async? 17:39:08 <jlaska> so ... shall we agree to leave this as is, and try to get testing and some devel input? 17:39:11 <jlaska> adamw: jynx 17:39:15 <tflink> maybe we punt on this one and ask kamil which boot option he was using 17:39:31 <tflink> in addition to more testing 17:39:59 <jlaska> proposed #agreed 723160 - Unable to determine full impact, leave in proposed pending additional testing to isolate failure scenario 17:40:44 <jlaska> I have 2 implicit votes for this from adamw+tflink 17:40:47 <jlaska> anyone else? 17:41:17 <brunowolff> I think the proposal is reasonable. 17:41:26 <adamw> with the understanding that if we can't get a reliable reproducer of some kind, we nack it as a blocker 17:41:46 <jlaska> because the scope (as we understand it now) is limited and documentable? 17:41:50 <jlaska> or $other 17:42:06 <jlaska> err duh ... unreliable reproducer 17:42:14 <jlaska> #info if we can't get a reliable reproducer of some kind, we nack it as a blocker 17:42:21 <jlaska> #agreed 723160 - Unable to determine full impact, leave in proposed pending additional testing to isolate failure scenario 17:42:29 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=711489 17:42:30 <buggbot> Bug 711489: unspecified, unspecified, ---, kernel-maint, ASSIGNED, atl1c: transmit queue timeout (ASUS 522) 17:42:33 <jlaska> #info atl1c: transmit queue timeout (ASUS 522) 17:43:02 <adamw> waiting for input from the proposer, but this looks quite non-blocker-y to me 17:43:46 <tflink> yeah, too HW specific 17:43:51 <adamw> it's an icky bug, but quite hardware specific 17:44:06 <jlaska> adamw: did you hear back on possible workarounds? 17:44:43 <adamw> jlaska: he has a workaround in comment #2 17:45:11 <jlaska> proposed #agreed 711489 - RejectedBlocker - nasty, but impacts limited hardware and has a workaround 17:45:14 <adamw> it looks like an interrupt issue. 17:45:24 <brunowolff> +1 17:45:40 <adamw> i'm okay to nak for now, if further investigation looks icky, we can re-evaluate 17:45:46 <tflink> +1 and rejected NTH 17:45:51 <adamw> nth is questionable 17:46:12 <jlaska> I was leaving that out for now ... in case someone wanted to repropose it for NTH 17:47:14 * dgilmore thinks fixing hardware specific bugs should be a nth 17:47:16 <jlaska> any other ack/nak/patch? 17:47:42 <adamw> ack 17:47:46 <jlaska> dgilmore: if the fix is *very* specific to that hardware ... that'd be fine with me 17:47:48 <adamw> i'll re-propose for nth or blocker or neither depending on more info 17:47:50 <jlaska> okay 17:47:53 <dgilmore> +1 to rejected blocker 17:47:55 <adamw> jlaska: right, the issue is the safety of teh fix 17:48:14 <jlaska> #agreed 711489 - RejectedBlocker - nasty, but impacts limited hardware and has a workaround. May re-evaluate if new information surfaces 17:48:24 <dgilmore> jlaska: yeah, likely it would mean lots of other kernel changes though, and im not of s strong opinion either way 17:48:30 <jlaska> okay 17:48:34 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723901 17:48:35 <buggbot> Bug 723901: unspecified, unspecified, ---, mgracik, MODIFIED, pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install 17:48:38 <jlaska> #info pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install 17:48:52 <clumens> hey i guess i should pay attention again 17:48:58 <dgilmore> jlaska: that was actually a pungi bug 17:49:08 <adamw> this isn't an issue post-branching, i guess 17:49:12 <jlaska> yeah, I think you've got this fixed now with pungi + lorax changes? 17:49:17 <dgilmore> i have a fix but cant fully test it due to the 2 bblockers i put up today 17:49:18 <jlaska> adamw: well, it might have been 17:49:25 <jlaska> but should be fixed now 17:49:37 <jlaska> howabout we move to MODIFIED ... pending TC1 testing? 17:49:46 <adamw> ack 17:49:52 <dgilmore> ack 17:49:55 <adamw> no repos available for install does look like a blocker 17:50:00 <jlaska> this would be a blocker, but it's hard to really determine the impact without the branch'd repos ... 17:50:07 <jlaska> adamw: right 17:50:17 <adamw> so we accept it as a blocker in principle, re-test with tc1 to see if it's valid 17:50:19 <jlaska> should we ignore that for now ... or do we want to go ahead and accept 17:50:25 <jlaska> I'm fine with that 17:50:32 <dgilmore> adamw: right the issue was that anaconda was thinking it was finala nd disabling betanag and rawhide repo 17:51:00 <dgilmore> which because we were on rawhide meant no other repos were enabled 17:51:07 <jlaska> proposed #agreed 723901 - AcceptedBlocker for Alpha based on perceived impact to branched composes - fix available, pending TC1 testing 17:51:24 <brunowolff> +1 17:51:35 <dgilmore> +! 17:51:37 <dgilmore> 1 17:52:20 <jlaska> #agreed 723901 - AcceptedBlocker for Alpha based on perceived impact to branched composes - fix available, pending TC1 testing 17:52:28 <jlaska> last one ... 17:52:30 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=724928 17:52:31 <buggbot> Bug 724928: unspecified, unspecified, ---, lpoetter, POST, Reboot ends with kernel panic on systemd abort() 17:52:35 <jlaska> #info Reboot ends with kernel panic on systemd abort() 17:52:53 <jlaska> brunowolff: you're most familiar with this issue iirc? 17:53:59 <brunowolff> I have seen crashes on reboot regularly. Since I'm rebooting anyway I haven't made that a high priority problem to look at. 17:54:30 <jlaska> let's see how this stacks up to our newly minted shutdown criteria ... 17:54:35 <jlaska> "It must be possible to trigger a system shutdown using standard console commands, and the system must shut down in such a way that storage volumes (e.g. simple partitions, LVs and PVs, RAID arrays) are taken offline safely and the system's BIOS or EFI is correctly requested to power down the system " 17:54:37 <tflink> its still not clear whether this affects storage integrity or not 17:54:47 <jlaska> tflink: you saw were I was going with that 17:54:52 <brunowolff> Also on one machine I can run the latest few kernels, because of a boot problem in initramfs, so I am not sure if the latest kernel is showing the problem. 17:55:00 <tflink> it looks like the storage is halted prior to the crash 17:55:28 <brunowolff> The crash is very late in the boot process. 17:55:28 <adamw> well 17:55:37 <adamw> i see "Detaching DM devices." 17:55:46 <adamw> i don't see "Completed detaching DM devices.", or anything like that 17:56:05 <adamw> the last message before the crash - "Successfully changed into root pivot." - reads like it's part of taking down storage, to me... 17:56:47 <brunowolff> I meant in the shutdown process. 17:57:22 <adamw> good news is clyde says it's fixed 17:57:47 <jlaska> he's back ... Clyde to the rescue :) 17:57:49 <adamw> oh, and there's "and the system's BIOS or EFI is correctly requested to power down the system", remember. 17:57:51 <adamw> that bit doesn't happen. 17:58:04 <adamw> so i'm +1 blocker according to the criterion we wrote. and since the criterion was supposed to make this a blocker...=) 17:58:17 <jlaska> right on ... almost like the criteria were tailor made for this problem :) 17:58:24 <adamw> hehe 17:58:50 <j_dulaney> Sorry I'm late 17:58:52 <brunowolff> I just tried it on a machine in the other room. 17:58:53 <adamw> heya 17:58:54 <j_dulaney> What bug we on? 17:58:58 <adamw> see topic 17:58:59 <jlaska> proposed #agreed 724928 - AcceptedBlocker for Alpha - impacts new Alpha shutdown criteria, likely fixed with systemd-31-2.fc16 17:59:03 <j_dulaney> Doh 17:59:04 <jlaska> ack/nak/patch? 17:59:12 <tflink> ack 17:59:25 <brunowolff> It said the md devices were in safe mode. though not completely shutdown (as / was on one of these I presume.) 17:59:45 <brunowolff> The root pivot was successful before the crash. 18:00:16 * j_dulaney is tentativ ack after glancing through 18:00:21 <adamw> ack 18:00:26 <j_dulaney> c/tentativ/tentative 18:00:28 <adamw> we should ask reporter to confirm fix 18:00:30 <brunowolff> -1 blocker 18:00:34 <jlaska> brunowolff: I think what got me was the final bit on the new criteria ... "the system's BIOS or EFI is correctly requested to power down the system " 18:01:03 <brunowolff> I see. Given that I am +1. 18:01:19 <adamw> the criterion as it stands is basically 'the shutdown process should more or less work, definitely including storage takedown, but if some not-particularly-important service fails to shutdown properly, that's no biggie' 18:01:21 <brunowolff> The machine doesn't power off. 18:01:22 <jlaska> we can of course debate that point in the criteria out of meeting if we like 18:01:38 <adamw> i did suggest that we could drop the 'poweroff' criterion if we just wanted to ensure storage was taken down, but there wasn't any clear agreement on that point 18:01:56 <j_dulaney> Righteo, I'm going to say full +1 at this point; it looks to be blocking the power off clause 18:01:57 <jlaska> yeah ... I have no opinion on that 18:02:30 <jlaska> #agreed 724928 - AcceptedBlocker for Alpha - impacts new Alpha shutdown criteria, likely fixed with systemd-31-2.fc16 18:03:04 <jlaska> #info Some discussion over the scope of the new shutdown criteria and whether it should only ensure that storage was safely umounted 18:03:16 <jlaska> #info Ask reporter to confirm fix 18:03:45 <jlaska> valid points raised on the criteria ... let's bring this up on test@ for further debate 18:03:48 <j_dulaney> shall we discuss that post meeting in #fedora-qa? 18:03:51 <jlaska> okay ... that's it for proposed 18:03:59 <jlaska> j_dulaney: yeah, that or the existing thread on test@ 18:04:14 <jlaska> === APPROVED F16 Alpha blockers === 18:04:18 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723144 18:04:19 <buggbot> Bug 723144: unspecified, unspecified, ---, dlehman, ASSIGNED, anaconda 16.12 crashed after the partition process 18:04:22 <jlaska> #info anaconda 16.12 crashed after the partition process 18:04:33 <jlaska> new info from dlehman on this bug 18:04:57 <jlaska> moved to NEEDINFO pending information from prajnoha 18:05:08 <jlaska> does anyone know prajnoha? 18:05:28 <jlaska> this just now got moved to NEEDINFO, but we may want to reach out to prajnoha early next week 18:05:39 <jlaska> I can keep an eye on this one 18:05:45 <jlaska> and nudge if needed 18:05:52 <jlaska> any other concerns on this? 18:06:23 <jlaska> alright .. 18:06:24 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723345 18:06:25 <buggbot> Bug 723345: unspecified, unspecified, ---, clumens, MODIFIED, Rescue mode fails - TypeError: progressWindow() takes exactly 4 arguments (6 given) 18:06:28 <jlaska> #info Rescue mode fails - TypeError: progressWindow() takes exactly 4 arguments (6 given) 18:06:38 <jlaska> I've confirmed this is fixed earlier today 18:06:48 <adamw> cool 18:07:02 * jlaska moves to VERIFIED 18:07:10 <j_dulaney> Sweet 18:07:10 <jlaska> "I'll move to VERIFIED, and we can CLOSE once a TC1 branch compose 18:07:10 <jlaska> is available" 18:07:24 <jlaska> NEXT!!! 18:07:26 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=690930 18:07:27 <buggbot> Bug 690930: unspecified, unspecified, ---, anton, ASSIGNED, microcode_ctl loops, impossible to boot 18:07:31 <jlaska> #info microcode_ctl loops, impossible to boot 18:07:40 * jlaska has no idea 18:07:54 * jlaska reading update from djones 18:07:54 <tflink> it looks like progress is being made 18:07:57 <j_dulaney> Did the patch get into the kernel? 18:07:57 <jlaska> err davej 18:08:28 <tflink> j_dulaney: I don't think that a kernel patch was proposed 18:08:56 <j_dulaney> Sorry, I was thinking of a different bug 18:09:14 <tflink> it sounds like kernel patches may be required for this, though 18:09:24 <jlaska> waiting for feedback from kay@ 18:09:37 <tflink> since the converted firmware files for intel still aren't working 18:09:49 <j_dulaney> Indeed 18:09:58 <jlaska> any additional action needed on this ... or does it seem to be progressing? 18:10:25 <tflink> I think it's definitely worth keeping an eye on but it does look like progress is being made 18:10:35 <jlaska> okay 18:10:41 * j_dulaney can't do too much with it. he's AMD only 18:10:42 <jlaska> #info definitely worth keeping an eye on but it does look like progress is being made 18:11:04 <jlaska> #topic Open discussion - <your bug here> 18:11:17 <jlaska> okay gang ... that's it for proposed and approved blockers 18:11:18 <tflink> j_dulaney: I thought that they un-backed out the udev changes so that AMD was booting again 18:11:20 <jlaska> there are no proposed NTH 18:11:34 <j_dulaney> tflink: I never had trouble with booting 18:11:46 <adamw> for the microcode_ctl we're now in the 'non-blocker' state, if i'm following it corectly 18:11:51 <tflink> j_dulaney: oh, I misunderstood. my bad 18:12:07 <j_dulaney> I must have missed the bug, because I didn't try out every nightly compose 18:12:09 <adamw> we've re-applied the questionable 'fix', which means now we're in the state where all CPUs boot but no-one's getting any microcode updates. 18:12:20 <j_dulaney> Ah 18:12:39 <jlaska> which seemed like a perfectly fine interim solution for Alpha, right? 18:12:43 <j_dulaney> That explains why I haven't seen the bug, but also explains some other things 18:12:47 <tflink> I thought that the microcode updates were working for AMD 18:12:51 <j_dulaney> jlaska +1 18:13:07 <j_dulaney> tflink: I'm not sure if they are 18:13:22 <jlaska> Okay gang ... nominate any bugs not previously discussed 18:13:27 <jlaska> otherwise, let's get back to finding more bugs 18:13:40 <clumens> no, wrong direction. 18:13:43 <tflink> are we removing the microcode as an alpha blocker? 18:13:45 <jlaska> clumens: haha 18:13:56 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=690930 18:13:57 <buggbot> Bug 690930: unspecified, unspecified, ---, anton, ASSIGNED, microcode_ctl loops, impossible to boot 18:14:03 <adamw> tflink: i think we'd best leave it on the list for tracking 18:14:09 <adamw> in case they screw it up again 18:14:14 <tflink> good point 18:14:25 <tflink> we can remove it prior to go/no-go if need be 18:14:27 <adamw> once we hit freeze and can control changes to it, we can make sure it's locked in a state where it's not a blocker, and take it off the list 18:14:28 <j_dulaney> I wonder if it would be a blocker for final 18:14:28 <adamw> yup 18:14:35 <brunowolff> Since it has already changed back and forth, I'd rather see it still stay on the list until it is really fixed. 18:14:51 <j_dulaney> brunowolff +1 18:15:31 * tflink wonders if anyone has tried this on PPC 18:15:33 <jlaska> #info no changes required, leave on the list and can revisit at prior to GO/NO_GO 18:16:04 <jlaska> #topic Open discussion - <your bugs here> 18:16:04 <tflink> are we supposed to be tracking the PPC and s390x blockers? 18:16:08 <jlaska> tflink: nope 18:16:09 <adamw> while everybody's here, can you take a look at https://fedorahosted.org/fedora-qa/ticket/227#comment:15 ? i have a thought that needs comments. thanks. 18:16:30 <jlaska> tflink: the architecture teams themselves are responsible for that 18:16:40 <jlaska> #topic Document SOP for acceptance test event 18:16:43 <tflink> jlaska: ok, just making sure 18:16:45 <jlaska> #link https://fedorahosted.org/fedora-qa/ticket/227#comment:15 18:18:05 <jlaska> adamw: my response ... I don't care ... but we need more testing prior to TC1 :) 18:18:29 <jlaska> so your suggestion of starting TC earlier sits well with me ... that was one of the suggestions on the retrospective 18:18:43 <j_dulaney> +1 for earlier TCs 18:18:59 * j_dulaney grabs nightlys and tests them, but they don't always build 18:19:12 <adamw> cool, we can discuss on -qa or the ticket, i was just abusing this meeting to grab your attention since everyone's here =) 18:19:17 <jlaska> adamw: anything you want to highlight here ... or just point folks to it for later discussion? 18:19:30 <jlaska> yup good ... let's continue discussion in the ticket 18:19:35 <brunowolff> If it is practical to run RATs after every compose, that seems like a reasonable thing to do. 18:19:48 <jlaska> the good news, that happens automatically :) 18:19:51 <jlaska> right now 18:20:11 <jlaska> (or at least used to) ... so we'll ask twu to stay on top of that 18:20:12 <adamw> to -qa! 18:20:23 <jlaska> to the bat-cave! 18:20:26 <jlaska> okay ... no more bugs 18:20:28 <jlaska> no more meeting 18:20:30 <jlaska> thanks for your time folks 18:20:32 <jlaska> #endmeeting