17:00:58 #startmeeting f16-final-blocker-review-3 17:00:58 Meeting started Fri Oct 14 17:00:58 2011 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:58 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:11 robatino: yeah, he's having trouble with the image generation due to grub changes 17:01:18 #meetingname f16-final-blocker-review-3 17:01:18 The meeting name has been set to 'f16-final-blocker-review-3' 17:01:19 tflink: ready as we'll ever be 17:01:24 #topic roll call 17:01:34 * jdulaney is president 17:02:02 Although rather distracted by external stimulii 17:02:28 jdulaney: welcome, mr. president 17:02:39 does that mean that you'll be running the meeting? 17:02:45 * brunowolff is here 17:02:55 brunowolff: welcome 17:03:22 tflink: I'll pass 17:03:36 A good president must delegate 17:03:36 tough luck tim 17:03:40 * adamw will secretaryize 17:03:45 unless anyone else wants to 17:04:38 * nirik is lurking. ping if I can help with anything. 17:04:47 * tflink was hoping that he could slack off :( 17:05:22 * jdulaney is going to look to see if there is a bug report already for the NM issues he is having with F16 17:05:30 ok, let's get this party started 17:05:36 #topic introduction 17:05:45 #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. 17:06:05 we'll be working off of the blocker bug list on the wiki 17:06:13 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:06:33 and roughly following the procedure listed 17:06:42 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:07:06 #info 10 proposed blockers 17:07:14 #info 4 proposed NTH 17:07:22 #info 14 accepted blockers 17:07:37 any objections to starting with the proposed blockers? 17:07:43 go for it 17:07:49 #topic (706756) No translation on Login-Page of the reboot-menu 17:07:49 #link http://bugzilla.redhat.com/show_bug.cgi?id=706756 17:07:49 #info Proposed Blocker, NEW 17:08:06 no buggbot today? 17:08:32 was it bugbot that was playing up and got kicked from a lot of channels? 17:08:48 crap, maybe we should go with criteria change voting first 17:09:15 we could decide whether to accept the current proposed criteria for the purpose of the meeting, yeah 17:09:35 since the first bug hits the proposed i18n criteria 17:09:39 #undo 17:09:39 Removing item from minutes: 17:09:41 #undo 17:09:41 Removing item from minutes: 17:09:43 #undo 17:09:43 Removing item from minutes: 17:09:59 #topic F16 Final Release Criteria Changes 17:10:23 Ugh, no bug report for my issues, so more testing to figure out *what* is going on 17:10:44 hrm, I seem to be typing faster than I'm thinking today 17:10:47 #undo 17:10:47 Removing item from minutes: 17:11:22 #topic i18n criteria for Fedora 16 Final 17:11:36 #info proposed criterion: The installer, bootup and login processes should correctly display all 17:12:14 tflink: I'm +1 for the new criterion; must run to the head 17:12:31 any proposed changes to the wording? 17:12:54 #link http://lists.fedoraproject.org/pipermail/test/2011-October/103588.html 17:13:16 you cut off the proposed criterion? 17:13:30 I did indeed 17:13:36 #undo 17:13:36 Removing item from minutes: 17:13:38 #undo 17:13:38 Removing item from minutes: 17:14:34 #info proposed criterion: The installer, bootup and login processes should correctly display all translations that are available for use 17:14:42 #link http://lists.fedoraproject.org/pipermail/test/2011-October/103588.html 17:15:15 I'm also +1 on this 17:15:40 so, any objections to accepting this criterion for final? 17:15:42 it might wind up being too loose but i think it's okay for current purposes 17:15:57 we might need to define 'vital' translations or something 17:16:04 yeah, I can see it leading to a whole bunch of new blockers 17:16:23 but we can cross that bridge if/when we get there 17:16:46 k. 17:17:06 I am returned 17:18:04 I'm assuming that by 'available for use' means complete translations? 17:18:13 proposed #agreed - "The installer, bootup and login processes should correctly display all translations available for use" is accepted as a release criterion for Fedora 16 Final 17:18:26 jdulaney: oh, right, we intentionally don't use incomplete translations, right? 17:18:32 maybe throw a 'sufficiently complete' in there 17:18:48 Indeed 17:19:03 proposed #agreed - "The installer, bootup and login processes should correctly display all sufficiently complete translations available for use" is accepted as a release criterion for Fedora 16 Final 17:19:10 ack 17:19:15 ack 17:19:24 #agreed - "The installer, bootup and login processes should correctly display all sufficiently complete translations available for use" is accepted as a release criterion for Fedora 16 Final 17:19:41 #topic Xen Criterion for Fedora 16 Final 17:20:16 #info proposed criterion: The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0. 17:20:29 #link http://lists.fedoraproject.org/pipermail/test/2011-October/103624.html 17:21:30 I don't know enought about Xen to comment on this; looks good to me, though 17:21:38 like i say my only worry with this is that a flat 'cloud providers' is something of a hostage to fortune, we might want to say 'widely used cloud providers' or smth. 17:21:48 one suggestion was to change "cloud providers" to "widely used cloud providers" 17:21:52 but other than that, yeah, i think we had good enough reasons. 17:22:18 The cloud providers clause modification makes sense to me 17:22:51 proposed #agreed - "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0." is accepted as a release criterion for Fedora 16 Final 17:23:04 +1 17:23:46 ack 17:23:53 #agreed - "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0." is accepted as a release criterion for Fedora 16 Final 17:24:16 I was going to leave the ks proposal alone since it doesn't affect final 17:24:46 yeah, not so critical 17:25:28 ok, lets get back to the bugs 17:25:43 #topic (706756) No translation on Login-Page of the reboot-menu 17:25:44 #link http://bugzilla.redhat.com/show_bug.cgi?id=706756 17:25:44 #info Proposed Blocker, NEW 17:25:55 so under our newly accepted criterion, +1 blocker. 17:26:02 +1 blocker 17:26:14 this one is pretty straight forward, the only reason it wasn't a blocker is due to pending criteria changes 17:26:42 proposed #agreed - 706756 - AcceptedBlocker - The installer, bootup and login processes should correctly display all sufficiently complete translations available for use. 17:27:07 ack 17:27:28 ack 17:27:42 #agreed - 706756 - AcceptedBlocker - The installer, bootup and login processes should correctly display all sufficiently complete translations available for use. 17:27:51 #topic (737508) grub2 cannot install when /boot is md and first partition starts at sector 63 17:27:54 #link http://bugzilla.redhat.com/show_bug.cgi?id=737508 17:27:56 #info Proposed Blocker, NEW 17:28:20 I thought you could'nt put /boot in md anyway 17:29:18 the beta RAID criterion specifically doesn't support it 17:29:46 but final criterion says "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 combination of the above" 17:30:03 which leaves this a bit of a grey area, depending whether it's considered a 'workable partition layout' 17:30:15 so is /boot on MD a workable layout? 17:30:28 In my opinion, never was 17:30:35 BIOS Raid is a different abstraction 17:30:37 Existing systems may have /boot on raid 1 md raid. 17:30:47 sgtpepper: md is linux software raid, as well as bios raid. 17:31:05 i would like to have dlehman's input here 17:31:10 but unfortunately he's off this week 17:31:43 I don't know about grub2... but grub always asked for a separate, garden variety, /boot partition 17:31:58 I might be wrong, since I never tried otherwise anyway 17:32:01 lol 17:32:08 punt, then? I'm on the fence about blockery-ness 17:32:26 ask for input from dlehman and re-visit next week? 17:32:33 I run systems with linux software raid on /boot on most of my systems and it works just fine with grub. 17:32:36 +1 for that 17:33:17 brunowolff: md raid? or BIOS Softraid? 17:33:27 md raid. 17:33:34 ok, then beats me 17:33:35 both can work. 17:33:44 i've had /boot on an intel bios raid array before. 17:33:55 but anyways - we kinda need anaconda team's call on this, so +1 punt. 17:34:02 punt 17:34:16 * jdulaney knows a punter 17:34:28 Matt Dodge, punter for the Giants 17:34:29 proposed #agreed - 737508 - We need input from the anaconda team to decide on blocker status, will ask for input and revisit next week 17:34:36 ack 17:34:37 Never been a footbal guy 17:35:00 Went to high school with him; his sisters are hot 17:35:14 lol 17:35:16 do they know much about blocker bugs? 17:35:18 ack 17:35:20 #agreed - 737508 - We need input from the anaconda team to decide on blocker status, will ask for input and revisit next week 17:35:36 #topic (742226) /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2 17:35:40 #link http://bugzilla.redhat.com/show_bug.cgi?id=742226 17:35:42 #info Proposed Blocker, NEW 17:35:43 adamw: I doubt it 17:36:08 looks like still no input from pjones 17:36:34 but we have a new report from promise raid controller 17:36:39 yeah. he's working on rhel issues atm. 17:36:46 this one does keep looking worse, though. 17:37:21 * tflink is waiting until he can test serial console install with TC1 before pestering people for HW 17:37:47 tflink: I can try that on a vm 17:38:15 sgtpepper: ok, I thought everything was pretty much fixed pending some grub changes 17:38:40 tflink: I can, haven't tried it yet 17:38:46 i'm kinda shading towards taking this one as a blocker, given that more and more people seem to be hitting it 17:38:54 same here 17:38:56 Indeed 17:39:50 proposed #agreed - 742226 - AcceptedBlocker - 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 combination of the above 17:40:10 ack/nak/patch? 17:40:30 ack 17:40:35 ack 17:40:45 #agreed - 742226 - AcceptedBlocker - 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 combination of the above 17:40:59 #topic (743273) grub2 fails to install on IMSM raid device 17:40:59 #link http://bugzilla.redhat.com/show_bug.cgi?id=743273 17:40:59 #info Proposed Blocker, NEW 17:41:26 I'm leaning blocker on this one, too 17:41:30 still missing data 17:41:30 Same criterion 17:41:55 Its affecting too many people... 17:42:04 this one? 17:42:11 I only see one reporter 17:42:41 yeah, this is only jes. 17:42:47 well, except my bug looked like a dupe of it, didn't it? 17:42:54 74226, 743273, all raid issues right? 17:43:25 well, raid/grub/grub2/grubby 17:43:48 I'm leaning towards rejecting if no new information by next week 17:43:59 https://bugzilla.redhat.com/show_bug.cgi?id=744054 17:44:07 sgtpepper: this is a different error message, different bug 17:44:14 my report has the same error as jes', however 17:44:20 checking 17:45:27 adamw: yep 17:45:41 unfortunately i can't do further testing as i needed my affected system to work so i converted it to soft raid. 17:45:59 let me do a simple test in a vm 17:46:03 with linux md 17:46:15 Fedora 16 Beta 17:46:18 we can do that later...but for now i think we should probably mark these two as dupes and punt again... 17:46:25 really need pjones to start looking at these 17:46:29 yeah, sounds good 17:46:43 +1 17:46:45 I'm really starting to hate virt-manager on F16 17:46:51 I need to file a bug for that 17:47:12 proposed #agreed - 743273 - Duplicate of 744054 17:47:42 looks like I'll ACK 17:48:14 or we could do it the other way around, I have no real preference 17:48:27 sgtpepper: when it goes all non-responsive and you have to kill and restart it? 17:48:37 yes 17:48:37 tflink: yeah 17:48:44 sgtpepper: yeah i've been meaning to file a bug on that for weeks... 17:49:04 but before that, I've to restart libvirtd a couple of times to get it to connect+ 17:50:00 ack 17:50:03 adamw: was that a "yes, duping the other is better"? 17:51:05 #agreed - 743273 - Duplicate of 744054 17:51:17 #topic (744054) Cannot install to MBR of an Intel BIOS RAID-0 array (Sony Vaio Z stock layout) 17:51:20 #link http://bugzilla.redhat.com/show_bug.cgi?id=744054 17:51:21 adamw: after trying the raid stuff... I'll file the bug 17:51:22 #info Proposed Blocker, NEW 17:51:25 tflink: i've done it anyway 17:51:42 so we can skip this one, it's now a dupe of 733273 17:51:45 er 743273 17:51:52 #agreed - 744054 - Still need more information on this, hopefully some dev input, will revisit next week 17:52:01 #topic (745246) Need automatic conversion from grub1 to grub2 for all possible cases 17:52:04 #link http://bugzilla.redhat.com/show_bug.cgi?id=745246 17:52:06 #info Proposed Blocker, NEW 17:53:00 i'm -1 on this; we only need scripts to assist yum upgrades which are unsupported, and booting still *works* after a yum update, we've tested that quite strongly now 17:53:12 I'm -1 on this, we already have criteria for upgrades 17:53:26 No LWN reader on Android market = suckage 17:54:03 proposed #agreed - 745246 - RejectedBlocker - There are already release criteria that cover grub upgrades and yum is not a supported upgrade method 17:54:15 quick question... has anyone tried triggering the raid bug... Does the partition has to be somewhere in particular? 17:54:19 I don't see the blockerness of this, anyway 17:54:36 ack 17:54:38 ack 17:55:03 sgtpepper: I haven't tried the /boot on raid part but didn't have any other problems last time I isntalled with sw raid 17:55:10 #agreed - 745246 - RejectedBlocker - There are already release criteria that cover grub upgrades and yum is not a supported upgrade method 17:55:17 #topic (676488) update showing Error message ??? instead of actual error message 17:55:21 #link http://bugzilla.redhat.com/show_bug.cgi?id=676488 17:55:23 #info Proposed Blocker, NEW 17:55:36 sgtpepper: it may be specific to certain intel bios raid setups. 17:55:59 proposed #agreed - 676488 - AcceptedBlocker - The installer, bootup and login processes should correctly display all sufficiently complete translations available for use. 17:56:14 adamw: when you create a /boot device on an MD, anaconda warns 17:56:41 yes. 17:57:02 tflink: actually, my criterion as drafted doesn't cover this. 17:57:19 Indeed 17:57:23 good point 17:57:59 we could extend it. or alternatively we could try to piggyback on the critical path definition, now i think about it 17:58:33 it would make sense to extend it to default installs on blocking DE 17:59:17 updates? 18:01:29 so for the criterion text we could say "All critical path actions should correctly display all sufficiently complete translations available for use" 18:01:31 Components included with live images and default installed systems (including installer, bootup and login processes) on release-blocking desktop environmentsshould correctly display all sufficiently complete translations available for use. 18:01:36 with a link to the critpath policy 18:02:01 that seems a bit too wide to me, we don't want to block on solitaire not displaying translations properly or something... 18:02:03 I like adamw's better 18:02:21 Indeed 18:02:41 +1 for adamw's proposal 18:02:49 "All critical path actions on release-blocking desktops should correctly display all sufficiently complete translations available for use" 18:02:59 proposed #agreed - i18n release criteria changed to "All critical path actions should correctly display all sufficiently complete translations available for use" 18:03:11 ack 18:03:27 proposed #agreed - i18n release criteria changed to "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" 18:03:35 as spanish speaker, I've to say +1 18:04:07 ack 18:04:12 ack 18:04:17 #agreed - i18n release criteria changed to "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" 18:05:04 proposed #agreed - 646488 - All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use 18:05:18 proposed #agreed - 646488 - AcceptedBlocker - All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use 18:05:35 ack 18:06:20 what is a good way to check an updated package to see if it breaks anything ? (without koji) 18:06:33 install into mock ? 18:06:34 ack 18:06:43 #agreed - 646488 - AcceptedBlocker - All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use 18:06:48 Cheshirc: or use a vm, i guess 18:06:56 er, it's 676488 18:06:57 #topic (741950) F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest 18:07:00 #link http://bugzilla.redhat.com/show_bug.cgi?id=741950 18:07:03 #info Proposed Blocker, POST 18:07:13 heck , darn ... no vm here , yet 18:07:25 this is going to be somewhat academic since it appears to have been fixed 18:07:38 Has anyone tried it since alpha? 18:07:57 * jdulaney doesn't use Xen 18:07:59 yeah, earlier this week 18:08:00 yeah, that konrad guy's been testing 18:08:05 he said it's working now i think 18:08:15 but I'm going to be -1 blocker on this, ironically 18:08:24 it doesn't hit the new criterion 18:08:27 how come? 18:08:35 since this is about installing into a DomU, not running it 18:08:55 Ooh 18:09:15 unless we were including installation issues 18:09:34 but you can build booting F16 xen guests w/ other tools like boxgrinder 18:09:39 can/could 18:10:01 although I'm splitting hairs a bit here 18:10:13 we're looking at final requirements right? 18:10:30 yep, including the 2 we accepted during this meeting 18:11:06 the criterion that this could hit is: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0." 18:11:16 well i kinda expected we would be accepting installation issues 18:11:40 tflink: are those in the wiki? I'm looking at wiki/Fedora_16_Final_Release_Criteria 18:11:40 yeah, I'm being too literal now that I'm looking at the beta release criteria for virt 18:11:47 the existing kvm criteria are worded the same way but we've taken them to cover installation issues... 18:11:53 sgtpepper: it's a new one so we didn't add it yet 18:12:03 so +1 blocker 18:12:14 we could change 'boot' to 'install and boot' i guess 18:12:24 but yeah i'm +1 given how we've interpreted kvm issues historically 18:12:25 proposed #agreed - 741950 - AcceptedBlocker - The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0. 18:12:27 ack 18:12:30 It seemds to me that install issues should be covered by default 18:12:45 ack 18:12:49 adamw: we have enough history with the kvm issues, I'm not too worried right now unless we want to clarify them 18:12:52 i do have an action item to 'clarify' the virt critera after pjones pointed out some issues in the wording anyway 18:13:15 jdulaney: well, maybe. one of the driving forces behind that criterion was EC2 and the other Xen based cloud providers 18:13:37 and the methods I'm familiar with to create cloud images don't use anaconda 18:13:39 +1 18:13:49 #agreed - 741950 - AcceptedBlocker - The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0. 18:14:02 #topic (744641) system-setup-keyboard ignored KEYTABLE 18:14:02 #link http://bugzilla.redhat.com/show_bug.cgi?id=744641 18:14:02 #info Proposed Blocker, ON_QA 18:14:02 tflink: yeah, that's worth considering. but hey, this one's fixed anyway so we can sleep sound. =) 18:14:42 we'd need some info on the practical consequences here 18:14:58 could this be the cause of the 'unlock screen with different layouts' bug? 18:15:09 I was just wondering the same thing 18:15:20 the commit identified as the culprit here is pretty old - feb 2010 18:15:28 but then, someone did say the unlock bug happened in f15 too at least... 18:16:00 Any reports in 13 or 14? 18:16:06 propose we ask for info on the consequences and specifically ask about relationship to the unlock bug 18:16:19 +1 18:16:29 proposed #agreed - 744641 - We need more information on the practical impact of this bug before making a decision on blocker status 18:16:53 the removal was committed in feb, could have made it into F15 18:17:10 and there are updates for both F15 and F16 18:17:27 so, my guess is that it did exist in F15, too 18:18:08 ack/nak/patch? 18:18:09 feb *2010* 18:18:16 oh 18:18:17 so it should have been in at least 13, 14, 15 too i believe 18:18:39 Hence my asking about 13 and 14 18:18:42 on a historical scale, 2011 and 2010 are practically the same thing :) 18:18:54 evolution 3.20 is nuts 18:19:11 but ack 18:19:22 ack 18:19:30 #agreed - 744641 - We need more information on the practical impact of this bug before making a decision on blocker status 18:19:37 #topic (743022) F15->F16 yum update fails with IMSM (BIOS) raid 18:19:37 #link http://bugzilla.redhat.com/show_bug.cgi?id=743022 18:19:37 #info Proposed Blocker, NEW 18:20:14 -1 is the same case on grub => grub2 update 18:20:43 I think that we were waiting to see if it could be reproduced w/ anaconda upgrade 18:21:20 and for dev input, which again we still don't have 18:21:29 punt 18:23:03 indeed 18:23:19 ack 18:23:58 I'm almost thinking -1 blocker on this but it looks like I'm outvoted 18:24:41 incomplete report, lack of recent response from reporter, initial circumstances around hitting this are unsupported 18:24:54 it doesn't really hurt to wait a bit longer though. 18:25:07 proposed #agreed - 743022 - We still need dev input before making a decision on this, will revisit next week 18:25:12 ack 18:25:33 tflink: I'll try to find a softraid 1 to test it... but no promises 18:26:10 ack 18:26:38 #agreed - 743022 - We still need dev input before making a decision on this, will revisit next week 18:26:55 OK, that's it for the proposed blockers 18:27:03 Yay 18:27:13 Ponies! 18:27:16 on to the proposed NTH 18:27:27 NTH? 18:27:27 #topic (741538) f16 upgrade with encrypted rootfs: "The root for the previously installed system was not found". 18:27:30 #link http://bugzilla.redhat.com/show_bug.cgi?id=741538 18:27:33 #info Proposed NTH, NEW 18:27:49 sgtpepper: Nice to have, basically we would allow fixes past freeze but won't block release for them 18:28:25 this seems like a clear nth candidate, it's a possible blocker, but we need anaconda team to decide what exactly's wrong 18:28:38 k 18:28:50 Indeed 18:29:09 +1 for NTH 18:30:09 +1 18:30:21 +1 18:31:06 proposed #agreed - 741538 - AcceptedNTH - need input from anaconda devs before considering for blocker due to failed upgrade of luks F15 system 18:31:11 ack 18:33:19 #agreed - 741538 - AcceptedNTH - need input from anaconda devs before considering for blocker due to failed upgrade of luks F15 system 18:33:30 #topic (745711) virtio cannot transfer all guest anaconda logs to host 18:33:33 #link http://bugzilla.redhat.com/show_bug.cgi?id=745711 18:33:36 #info Proposed NTH, NEW 18:33:48 this looks like a simple enough change, not sure why it has to be NTH 18:34:19 "The only way to ensure this is going 18:34:19 to make f16 is to have this accepted as a NTH" 18:34:24 ales is still on that track. sigh. 18:34:32 * tflink wonders if hongqing has been able to test this 18:34:42 so, again, anaconda's commit policies are not a reason to take bugs as nth or not. this doesn't seem to be significant enough to make nth. 18:34:59 yeah, we can make our own images if needed for autoqa 18:35:03 although there is hongqing's comment... 18:35:12 but still, yeah, that's not enough reason to poke anaconda in a freeze. 18:35:17 if this doesn't make F16 final, it isn't the end of hte world 18:35:53 I'm thinking -1 NTH on this 18:36:10 ok, I've finally sent my introductory e-mail (despite evolution 3.2.0-1.fc16.x86_64) 18:36:17 tflink: agree 18:36:22 I'd be OK with a new lorax build before freeze but not past freeze 18:36:24 not for this 18:37:14 brb (smoke break) 18:37:43 proposed #agreed - 745711 - RejectedNTH - This issue doesn't affect enough users to warrant taking a fix past freeze, the autoqa team is capable of building their own images if need be 18:37:56 ack 18:37:58 ack 18:38:06 #agreed - 745711 - RejectedNTH - This issue doesn't affect enough users to warrant taking a fix past freeze, the autoqa team is capable of building their own images if need be 18:38:18 #topic (745239) Missing/wrong menu entries 18:38:19 #link http://bugzilla.redhat.com/show_bug.cgi?id=745239 18:38:19 #info Proposed NTH, ON_QA 18:39:06 I'm OK with NTH on this 18:39:23 it can't be fixed post-release and seems to be isolated enough 18:39:55 not sure why it's being proposed since it's already on_qa and we haven't hit freeze yet, though 18:40:44 tflink: I'd leave NTH since the update is already in qa 18:41:04 sgtpepper: yeah, I'm not saying -1 NTH, just noting that it didn't need NTH status 18:41:40 proposed #agreed - 745239 - AcceptedNTH - This can't be fixed post-release and the fix looks isolated to the security spin 18:41:47 ack/nak/patch? 18:42:29 brb 18:42:36 acl 18:42:37 ack 18:43:04 #agreed - 745239 - AcceptedNTH - This can't be fixed post-release and the fix looks isolated to the security spin 18:43:13 #topic (735023) Fedora 16 live images are not EFI-capable: should use grub-efi package when available 18:43:16 #link http://bugzilla.redhat.com/show_bug.cgi?id=735023 18:43:16