17:03:38 #startmeeting F16-blocker-review-1 17:03:38 Meeting started Fri Sep 30 17:03:38 2011 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:38 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:03:53 #meetingname Fedora 16 Final Blocker Review Meeting 1 17:03:53 The meeting name has been set to 'fedora_16_final_blocker_review_meeting_1' 17:04:00 #topic roll call 17:04:09 * nirik is lurking around. 17:04:53 * brunowolff is here 17:05:16 adamw: you around? This was partially your idea 17:05:54 he may be catching up on sleep after the marathon yesterday? 17:06:04 BTW, thanks to all of the crazy people who prevented another beta slip. 17:06:26 nirik: yeah, I'm wondering the same thing 17:07:07 I'm still amazed how quickly the test for RC4 were done 17:07:40 but honestly, I consider the fact that we had to do that a kind of failure 17:08:37 yeah, would have been nice to catch the efi stuff in better time. ;( 17:08:51 no kidding 17:09:22 * tflink is really hoping for a less sanity-draining final release 17:11:01 well, let's try to get started. 17:11:52 #topic Background Information 17:12:05 #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:12:14 I'll be working from the following list: 17:12:22 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:12:45 any objections to starting with the proposed blockers? 17:13:05 no 17:14:00 #topic (736268) [abrt] GConf2-3.1.90-1.fc16: Process /usr/bin/gsettings-data-convert was killed by signal 11 (SIGSEGV) 17:14:04 #link http://bugzilla.redhat.com/show_bug.cgi?id=736268 17:14:06 Bug 736268: unspecified, unspecified, ---, rstrode, NEW, [abrt] GConf2-3.1.90-1.fc16: Process /usr/bin/gsettings-data-convert was killed by signal 11 (SIGSEGV) 17:14:10 #info Proposed Blocker, NEW 17:14:44 sounds like a pretty straight forward blocker to me 17:15:02 "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 17:15:51 proposed #agreed - 736268 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 17:15:58 ack/nak/patch? 17:16:02 +1 17:17:21 hrm, not sure if this is going to work so well with just 2 of us 17:17:28 * tflink should have thought of that 17:18:17 We can still get the noncontroversial stuff out of the way. 17:18:42 Anthing dubious can be punted to the next meeting. 17:19:05 yeah, the whole point was to get the list paired down 17:19:27 oh well 17:19:30 tflink: Too few attendees? 17:19:41 * sgallagh is around, if that helps. 17:20:02 sgallagh: yeah, having another person around would help 17:20:12 it would make for 3 people :) 17:20:23 #agreed - 736268 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 17:20:34 #topic (739836) NetworkManager makes reboot take several minutes 17:20:44 #link http://bugzilla.redhat.com/show_bug.cgi?id=739836 17:20:45 Bug 739836: unspecified, unspecified, ---, dcbw, NEW, NetworkManager makes reboot take several minutes 17:20:46 #info Proposed Blocker, NEW 17:20:54 Could someone just toss me a quick link to the blocker criteria? 17:21:00 I think this is more NTH material than blocker. 17:21:19 yeah, same here 17:21:30 we've had a similar issue with LVM on f15 since before release 17:21:35 NTH 17:22:08 FWIW, it's an improvement over my F15 box. That one won't EVER shut down if it was initiated at the console, rather than the Gnome shutdown. 17:22:45 proposed #agreed - 739836 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria since the machine does still shut down. However, delayed shutdown is an annoyance and would be nice to have fixed 17:22:49 ack/nak/patch? 17:23:17 sgallagh: yeah, my F15 box takes forever to shutdown/restart. I haven't actually timed it, though 17:23:32 well, the one that I use LVM snapshots on, anyways 17:23:37 tflink: Well, it's only if I call 'halt' or 'shutdown -r now' from the console. 17:23:45 +1 17:23:47 If I use the gnome menu, it works fine 17:23:52 #agreed - 739836 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria since the machine does still shut down. However, delayed shutdown is an annoyance and would be nice to have fixed 17:24:05 #topic (731266) TypeError: must be string, not None 17:24:05 #link http://bugzilla.redhat.com/show_bug.cgi?id=731266 17:24:05 #info Proposed Blocker, MODIFIED 17:24:07 Bug 731266: unspecified, unspecified, ---, akozumpl, MODIFIED, TypeError: must be string, not None 17:24:36 #link http://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria 17:24:43 * tflink wonders if this was fixed already 17:24:49 brunowolff: thanks, I forgot that one 17:25:04 It's marked as MODIFIED in the bug 17:26:08 proposed #agreed - 731266 - AcceptedBlocker - This bug intereferes with the final test case "NFSISO 17:26:11 install variation" 17:26:12 +1 17:26:39 #agreed - 731266 - AcceptedBlocker - This bug intereferes with the final test case "NFSISO install variation" 17:26:56 * tflink is being a bit liberal for some of the obvious ones. I can undo if anyone has objections 17:27:05 I was thinking that "The installer must be able to use all supported local and remote package source options" would be the criteria for this one. 17:27:21 Anyway I do believe it is a blocker. 17:27:22 #undo 17:27:22 Removing item from minutes: 17:27:52 #agreed - 731266 - AcceptedBlocker - This bug intereferes with the final test case "NFSISO install variation" and violates the final critera "The installer must be able to use all supported local and remote package source options" 17:28:02 +1 17:28:09 that was supposed to be proposed, oh well 17:28:24 #topic (733425) anaconda sets hostname to localhost.localdomain 17:28:24 #link http://bugzilla.redhat.com/show_bug.cgi?id=733425 17:28:24 #info Proposed Blocker, NEW 17:28:25 Bug 733425: medium, unspecified, ---, rvykydal, NEW, anaconda sets hostname to localhost.localdomain 17:29:10 this sounds like a kickstart issue, no? 17:29:57 I assume so with the reference to %post. 17:30:27 possibly related: 17:30:33 I am not sure how we tell which kickstart issues are blockers. 17:30:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=706073 17:30:36 Bug 706073: low, low, ---, dcbw, NEW, hostname no longer being set to dhcp hostname 17:30:44 I am not too excited about this one though. 17:31:09 I think this is NTH 17:31:22 Relying on DHCP to set your hostname is a recipe for disaster anyway 17:31:54 yeah NTH sounds fine to me 17:33:06 I am not sure I'd go that far. At the very least I'd want a real safe fix before pulling in a new build for this. 17:33:08 proposed #agreed - 733425 - RejectedBlocker AcceptedNTH - This is a somewhat obscure kickstart issue that doesn't hit any of the release criteria. However, it sounds like a fix is under way and it would be nice to see fixed. 17:33:23 +1 17:33:53 +1 17:33:54 #agreed - 733425 - RejectedBlocker AcceptedNTH - This is a somewhat obscure kickstart issue that doesn't hit any of the release criteria. However, it sounds like a fix is under way and it would be nice to see fixed. 17:34:13 #topic (739828) filtering screen shows loop devices 17:34:13 #link http://bugzilla.redhat.com/show_bug.cgi?id=739828 17:34:13 #info Proposed Blocker, POST 17:34:14 Bug 739828: medium, medium, ---, akozumpl, POST, filtering screen shows loop devices 17:35:08 I'm not sure I understand the bug. 17:35:23 I think this is NTH since it could cause some confusion and can't be fixed later, but see no reason to make it a blocker. 17:35:47 it sounds like loop devices are showing up as potential installation targets 17:36:00 Ah, having now looked at the screenshot it makes more sense 17:36:09 Yeah, NTH 17:37:11 we certainly don't have any criteria on unacceptable target devices 17:37:42 I think it's okay to have too many devices listed. 17:37:47 Too few would be a different story... 17:38:02 since it's only on the advanced storage part, yeah I'm not as concerned with this 17:38:12 But since it can't be fixed after the final release, I think it is a reasonable NTH candidate. 17:38:20 if it was on the normal partitioning screen, I'd definitely be +1 blocker 17:39:40 proposed #agreed - 739828 - RejectedBlocker AcceptedNTH - This doesn't hit any release criteria, only shows up with advanced storage devices and doesn't prevent installation. It can't be fixed post-release and looks bad to have in the installer. 17:40:06 +1 17:40:16 #agreed - 739828 - RejectedBlocker AcceptedNTH - This doesn't hit any release criteria, only shows up with advanced storage devices and doesn't prevent installation. It can't be fixed post-release and looks bad to have in the installer. 17:40:26 #topic (740062) fcoe.py fails to detect FCoE NIC due to extraneous newline character 17:40:29 #link http://bugzilla.redhat.com/show_bug.cgi?id=740062 17:40:31 Bug 740062: high, unspecified, ---, akozumpl, POST, fcoe.py fails to detect FCoE NIC due to extraneous newline character 17:40:32 #info Proposed Blocker, POST 17:41:06 comment 3 is odd 17:41:18 not sure I understand why this has to be a blocker in order to fix 17:41:37 I was hoping he meant that for Beta. 17:42:04 yeah, that would make sense 17:42:19 It certainly should be fixed between beta and final freezes. 17:42:28 it does hit criteria, though 17:42:32 "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" 17:43:00 Though it sounds like there is a work around, I'm leaning toward blocker. 17:43:17 +1 blocker 17:43:21 yeah, I'm +1 blocker on this 17:43:57 proposed #agreed - 740062 - Violates the fedora 16 final release criterion: "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" 17:44:00 +1 17:44:01 whoops 17:44:13 proposed #agreed - 740062 - AcceptedBlocker - Violates the fedora 16 final release criterion: "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" 17:44:20 #agreed - 740062 - Violates the fedora 16 final release criterion: "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" 17:44:20 +1 17:44:35 #topic (741199) BOOTPROTO missing in ifcfg-eth0 in minimal install 17:44:35 #link http://bugzilla.redhat.com/show_bug.cgi?id=741199 17:44:35 #info Proposed Blocker, NEW 17:44:36 Bug 741199: unspecified, unspecified, ---, rvykydal, NEW, BOOTPROTO missing in ifcfg-eth0 in minimal install 17:45:24 I don't remember having to do this for beta test installs 17:45:43 oh, nvm, I misunderstood 17:46:42 I'm at least NTH on this 17:47:02 * tflink is looking for the related beta blocker/nth about autostarting network 17:47:33 Is it using NM_CONTROLLED=no ? 17:48:11 not sure 17:48:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=498207 17:48:23 Bug 498207: low, high, ---, rvykydal, CLOSED ERRATA, DVD install defaults to ONBOOT=no leaving networking down after reboot 17:48:31 that was an NTH for beta 17:48:41 I don't think network cares about BOOTPROTO. 17:49:30 I thought that network.service was disabled by design on a minimal install 17:50:49 I'm leaning towards punting on this one until we have more info 17:51:06 It is, but the problem here is also that a simple 'service network start' doesn't work 17:51:15 I think we should punt until we know more about what is supposed to happen. 17:51:18 tflink: I'm okay with punting it, but I'm -1 blocker 17:51:47 rejected blocker and proposed NTH, then? 17:52:00 +1 17:52:10 That seems reasonable. 17:52:44 the part about service network start not working bugs me, even though I don't remember seeing it 17:52:56 eh, it can be reproposed 17:53:42 proposed #agreed - 741199 - RejectedBlocker proposed NTH - This doesn't hit any of the release criteria and there isn't quite enough information to determine NTH, will re-visit at next meeting 17:54:19 #agreed - 741199 - RejectedBlocker proposed NTH - This doesn't hit any of the release criteria and there isn't quite enough information to determine NTH, will re-visit at next meeting and ask for more info in bug. 17:54:34 #topic (741817) DispatchError: Can not reschedule step 'bootloader' from 'skipped' to 'requested' 17:54:37 #link http://bugzilla.redhat.com/show_bug.cgi?id=741817 17:54:38 Bug 741817: unspecified, unspecified, ---, akozumpl, ASSIGNED, DispatchError: Can not reschedule step 'bootloader' from 'skipped' to 'requested' 17:54:39 #info Proposed Blocker, ASSIGNED 17:54:45 I'm +1 blocker on this. 17:55:15 yeah, same here 17:55:38 the only reason it wasn't a beta blocker is that it's somewhat less common ATM 17:56:10 Yeah, EFI installs on F15 are nearly nonexistent 17:56:38 But nearly != completely. 17:56:43 So yeah, blocker 17:56:55 proposed #agreed - 741817 - AcceptedBlocker - Violates the Fedora 16 beta criteria "The installer must boot and run on systems using EFI other than Apple Macs" 17:57:01 morning 17:57:15 oh, jeez, i thought this was 11 again. sigh. 17:57:17 adamw: look who finally shows up an hour late :-D 17:57:27 for some reason i'm convinced blocker reviews are 11 17:57:31 sorry :( 17:57:43 +1 17:57:45 11 MDT until we hit DST 17:58:27 #agreed - 741817 - AcceptedBlocker - Violates the Fedora 16 beta criteria "The installer must boot and run on systems using EFI other than Apple Macs" 17:58:42 #topic (742123) DispatchError: Can not reschedule step 'group-selection' from 'requested' to 'skipped' 17:58:45 #link http://bugzilla.redhat.com/show_bug.cgi?id=742123 17:58:47 Bug 742123: unspecified, unspecified, ---, akozumpl, POST, DispatchError: Can not reschedule step 'group-selection' from 'requested' to 'skipped' 17:58:48 #info Proposed Blocker, POST 17:59:25 eh, I'm thinking -1 blocker , +1 NTH on this 17:59:26 looks pretty simple 17:59:47 isn't 'customize later' the default choice? 17:59:53 so you'd hit this with any kickstart without %packages? 18:00:12 why would you use a kickstart w/o packages? 18:00:34 tflink: minimal install? 18:00:35 is that supposed to trigger a default install? 18:01:12 no 18:01:17 it just means you do the packaging step interactively 18:01:29 anything you don't expressly specify in the kickstart gets done interactively 18:01:45 i dunno, if you want to nth it that's fine, it's gonna get fixed either way 18:01:56 I think this is at least NTH, I'm not sure about blocker. 18:02:01 +1 nth then 18:02:14 so if you do a ks w/ the intention of handling packages and select default - crash? 18:03:35 proposed #agreed - 742123 - RejectedBlocker AcceptedNTH - This doesn't clearly hit any release criteria but it would likely hit any ks installation w/ interactive package selection 18:04:51 tflink: that's what it looks like to me. 18:04:56 ack/nak/patch? 18:05:04 +1 18:05:11 ack 18:05:26 #agreed - 742123 - RejectedBlocker AcceptedNTH - This doesn't clearly hit any release criteria but it would likely hit any ks installation w/ interactive package selection 18:05:34 #topic (740625) After update to 3.1.92, can't submit password on login window 18:05:37 #link http://bugzilla.redhat.com/show_bug.cgi?id=740625 18:05:39 Bug 740625: urgent, unspecified, ---, mclasen, NEW, After update to 3.1.92, can't submit password on login window 18:05:40 #info Proposed Blocker, NEW 18:06:43 sounds fixed/dupe? 18:06:57 i wouldn't be sure yet 18:06:59 I am not seeing that. 18:07:25 reporter has the atk-spi2-atk package version that is 'fixed' 18:07:49 as described, looks like +1 blocker to me, ray seems to be doing a thorough job of investigating 18:08:17 i'd say "Following on from the previous criterion, after firstboot is completed and on subsequent boots, 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 a working graphical environment without unintended user intervention." 18:08:33 +1 blocker 18:09:18 proposed #agreed - 740625 - AcceptedBlocker - Violates the Fedora 16 alpha criteria: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, 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 a working graphical environment without unintended user intervention. This includes correctly accessing any 18:09:44 +1 18:10:08 ack 18:10:16 #agreed - 740625 - AcceptedBlocker - Violates the Fedora 16 alpha criteria: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, 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 a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted 18:10:23 #topic (706756) No translation on Login-Page of the reboot-menu 18:10:25 #link http://bugzilla.redhat.com/show_bug.cgi?id=706756 18:10:26 Bug 706756: medium, unspecified, ---, rstrode, NEW, No translation on Login-Page of the reboot-menu 18:10:28 #info Proposed Blocker, NEW 18:12:21 this is tricky, as we don't really have translation criteria 18:12:49 we probably should, at least NTH 18:12:55 i could see adding to the criterion akira cited though 18:13:14 well, no, not that one. 18:13:20 but...yeah, we probably need something. 18:13:39 we could +1 nth and table blocker status, aim to propose a translation criterion this week? 18:13:50 sounds like a plan to me 18:13:51 That sounds reasonable. 18:14:36 proposed #agreed - 705756 - AcceptedNTH - There aren't any criteria for translations at this time but there probably should be. Will propose translation criteria and re-visit next week. 18:14:43 +1 18:15:00 +1 18:15:08 #agreed - 705756 - AcceptedNTH - There aren't any criteria for translations at this time but there probably should be. Will propose translation criteria and re-visit next week. 18:15:12 #topic (738092) swell-foop blank screen 18:15:14 #link http://bugzilla.redhat.com/show_bug.cgi?id=738092 18:15:15 Bug 738092: unspecified, unspecified, ---, rstrode, NEW, swell-foop blank screen 18:15:17 #info Proposed Blocker, NEW 18:15:52 if this is included by default, +1 blocker 18:16:47 proposed #agreed - 738092 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 18:17:52 yup 18:17:53 ack 18:18:05 #agreed - 738092 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 18:18:12 (and it's still valid in 3.2.0) 18:18:17 #topic (730985) Customizing panel objects / layout with 'Alt + Right Click' not working 18:18:20 #link http://bugzilla.redhat.com/show_bug.cgi?id=730985 18:18:21 Bug 730985: unspecified, unspecified, ---, rstrode, NEW, Customizing panel objects / layout with 'Alt + Right Click' not working 18:18:22 #info Proposed Blocker, NEW 18:18:46 * adamw picks up secretary duties 18:19:04 thanks 18:19:12 I did the go/no-go stuff this morning 18:19:49 cool 18:20:30 so...couple things... 18:20:32 I can use alt rc to move stuff around on the panel in fallback mode or to set panel properties. 18:20:35 how does this interfere with that test case? 18:20:53 and interfering with test cases is usually more a reason to change the test case than consider the bug a blocker 18:21:05 I had lots of brain farts that day, this could be an error 18:21:06 If they meant to set preferences for an item and not the panel then you need to not use alt. 18:21:22 tflink: you could be thinking of one of the panel test cases 18:21:33 athmane is usually pretty on the ball 18:21:39 brunowolff: is this a clean install or an updated one? 18:21:48 Updated. 18:21:52 I was referring to me proposing it as a blocker, not athmane's testing 18:22:12 yeah, i was replying to bruno 18:22:18 the relevant criterion here would be "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use " 18:22:20 (Also updates-testing.) 18:22:33 so if the bug report is true, it would depend whether this was 'intended' or not. 18:22:40 maybe we can ask athmane to confirm with beta 18:23:04 yeah, I had the wrong test case 18:23:21 it's "Testcase_desktop_panel_basic" 18:23:30 https://fedoraproject.org/wiki/QA:Testcase_desktop_panel_basic 18:23:51 I think it would be a blocker, but I suspect the issue has been fixed. 18:24:18 yeah, same here 18:24:19 okay 18:24:24 let's accept it but ask athmane to update? 18:24:26 so +1 18:24:29 +1 18:25:57 proposed #agreed - 730985 - AcceptedBlocker - Interferes with the "Testcase_desktop_panel_basic" testcase and hits the beta criteria "No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices". Suspect that this has been fixed, ask for re-test in bug. 18:26:09 this should have been a beta blocker, not final 18:26:22 * tflink wonders if he got any of those right after beta 18:26:28 alpha 18:26:34 ... and it continues 18:26:51 heh 18:27:09 #agreed - 730985 - AcceptedBlocker - Interferes with the "Testcase_desktop_panel_basic" testcase and hits the beta criteria "No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices". Suspect that this has been fixed, ask for re-test in bug. 18:27:17 #topic (731251) SELinux is preventing /bin/bash from 'getattr' accesses on the archivo /lib/systemd/system/chronyd.service. 18:27:20 #link http://bugzilla.redhat.com/show_bug.cgi?id=731251 18:27:21 Bug 731251: unspecified, unspecified, ---, bnocera, MODIFIED, SELinux is preventing /bin/bash from 'getattr' accesses on the archivo /lib/systemd/system/chronyd.service. 18:27:23 #info Proposed Blocker, MODIFIED 18:27:23 +1 blocker 18:27:28 +1 blocker 18:28:14 well 18:28:21 that criterion really means "when you boot the system and log in" 18:28:24 not anything else 18:28:31 if we take this as a blocker, it would have to be a different criterion 18:28:53 the only real candidate is "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items " 18:30:38 oh, wait 18:30:40 is this firstboot? 18:30:44 i was thinking it's gnome's tool 18:31:05 yeah, that's what I thought, too 18:31:43 no, not firstboot 18:31:55 see comment 6 18:32:03 It happened on a live image, so not firstboot. 18:32:15 yeah..so, i'm =1 18:32:20 er, -1 18:32:49 it's dangerous to read the selinux criteria too broadly or we'd just wind up with way too many blockers 18:33:03 my bad 18:33:21 I forget about that as well. 18:33:21 this has happened before, maybe that criterion needs more clear wording somehow 18:33:32 so it doesn't get read as 'login and use' 18:33:45 Anyway there seems to be a fix, so I am not too worried about what we call it. 18:33:53 maybe put the initial boot and login at the beginning of the sentance 18:33:57 yeah, same here 18:33:58 yeah 18:34:03 +1 nth, -1 blocker 18:34:27 (nth as it's live-visible) 18:34:28 I'll change to that. +1 NTH -1 Blocker. 18:34:50 proposed #agreed - 731251 - RejectedBlocker AcceptedNTH - Doesn't hit any of the release criteria but would be nice to see fixed. There should be a fix available, needs testing 18:35:01 +1 18:35:14 #agreed - 731251 - RejectedBlocker AcceptedNTH - Doesn't hit any of the release criteria but would be nice to see fixed. There should be a fix available, needs testing 18:35:29 #topic (735273) Command finds Windows partition, adds to grub menu, but menu entry will not boot 18:35:32 #link http://bugzilla.redhat.com/show_bug.cgi?id=735273 18:35:33 Bug 735273: unspecified, unspecified, ---, pjones, NEW, Command finds Windows partition, adds to grub menu, but menu entry will not boot 18:35:34 #info Proposed Blocker, NEW 18:37:06 so, bob's had this for a while, but unfortunately, we're struggling to reproduce... 18:37:24 * tflink hasn't tried a dualboot system 18:37:56 i tested at alpha and it worked 18:38:06 jon tested with XP and 7 and it worked 18:38:09 hey bob 18:38:10 ask for more testing, re-visit next week? 18:38:13 we're playing your tune :) 18:39:02 hey adamw 18:40:02 we're on your windows dual boot bug 18:40:16 so i just had a thought: on the affected install, does windows boot if you restore the windows bootloader to the mbr? 18:40:26 (i think you can do that from windows' rescue mode or smth) 18:40:30 my waking up timing is perfect then -- can I add any input / assistance? 18:40:58 we're mostly just scratching our heads as before, wondering why it works for me and jon but is broke for you... 18:41:25 So am I 18:42:18 the other question is whether it's reproducible - if you set up a new VM from scratch and do the same thing, does it break? 18:44:00 How about ask for more testing in an attempt to reproduce, revisit next week and reject if no reproducers 18:44:07 I've hacen't setup a new vm since beta.rc2 ; been tar -zxf 18:44:35 I'm good with that ; it'll give me time to create a new windows vm from scratch 18:44:43 tflink: yeah, as things stand i'd be slightly -1 as this is a fairly permissive criterion: it's more of a 'well, it's gotta work at least sometimes' criterion than a 'it must work in every case' one 18:45:11 but obviously it'd be easier to judge with more testing, or if we manage to debug precisely what's wrong in bob's case 18:45:21 proposed #agreed - 735273 - Ask for more testing in an attempt to reproduce, revisit next week and reject if no reproducers 18:45:40 'cause we've been at this for almost 2 hours already and still have a LONG way to go 18:46:13 I count 13 proposed blockers remaining 18:46:32 ack 18:46:42 we're only about halfway through :( 18:46:56 #agreed - 735273 - Ask for more testing in an attempt to reproduce, revisit next week and reject if no reproducers 18:47:08 #topic (737339) Default timeouts are too long 18:47:09 #link http://bugzilla.redhat.com/show_bug.cgi?id=737339 18:47:09 #info Proposed Blocker, NEW 18:47:10 Bug 737339: unspecified, unspecified, ---, pjones, NEW, Default timeouts are too long 18:48:10 -1 blocker, +~.3 NTH 18:49:20 i think this was actually changed in beta, wasn't it? 18:49:27 i somehow have the feeling it got dropped to 5s 18:49:28 I think it was changed to be shorter 18:49:42 * tflink remembers a change in anaconda to do that 18:49:50 https://admin.fedoraproject.org/updates/FEDORA-2011-13118 18:49:57 Bugs Fixed 18:49:57 727831 - Default GRUB timeout is 20 seconds 18:50:06 so, i guess this bug is a dupe 18:50:27 yup. +1 dupe it and move on 18:50:48 #agreed - 737339 - DUPLICATE of 727831 18:51:05 #topic (738977) grub2 defaults to boot "saved" seems wrong 18:51:05 #link http://bugzilla.redhat.com/show_bug.cgi?id=738977 18:51:05 #info Proposed Blocker, NEW 18:51:08 Bug 738977: unspecified, unspecified, ---, pjones, NEW, grub2 defaults to boot "saved" seems wrong 18:51:52 i still don't think this is correct... 18:52:02 any time i install a vm and then install a kernel update, a reboot boots to the new kernel, not the old one 18:52:06 anyone else noticed this? 18:52:19 I haven't had any trouble with this 18:52:51 my dsl is slow - is this bug saying that updates to kernel boot old kernel not new? 18:52:57 yes 18:53:06 haven't seen that here 18:53:20 i'm probably -1 blocker anyway as this is something that could be fixed with an update 18:53:48 There is a setting that controls this behavior. Could he have set it accidentally. 18:54:09 reject and move on, or needinfo and move on, i reckon 18:54:19 proposed #agreed - 738977 - RejectedBlocker - This doesn't clearly hit any release criteria, hasn't been seen elsewhere and could be fixed with an update 18:54:29 I know I managed to do that one time and it took me a while to find what I needed to change to fix things. 18:54:37 ack! 18:54:55 +1 18:54:58 proposed #agreed - 738977 - RejectedBlocker - This doesn't clearly hit any release criteria, hasn't been seen elsewhere and could be fixed with an update 18:55:01 gah 18:55:04 heh 18:55:09 #agreed - 738977 - RejectedBlocker - This doesn't clearly hit any release criteria, hasn't been seen elsewhere and could be fixed with an update 18:55:17 #topic (742226) /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2 18:55:20 #link http://bugzilla.redhat.com/show_bug.cgi?id=742226 18:55:23 #info Proposed Blocker, NEW 18:55:25 Bug 742226: unspecified, unspecified, ---, pjones, NEW, /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2 18:56:29 this is the bios raid issue we proposed for beta and decided to punt on 18:56:43 i think we probably need to wait for more data to decide on final status, we still don't have a really clear idea of the bug 18:56:54 yeah, I was thinking the same thing 18:57:10 to be honest, I'm not sure this hits any release criteria to the letter 18:57:12 hopefully pjones may have come up with a fix or at least more details by next time 18:57:18 but I'm splitting hairs here 18:57:19 well, it clearly hits the one about RAID installs 18:57:27 it installs, doesn't it? 18:57:32 it just doesn't boot afterwards 18:57:37 heh. 18:57:43 nvm 18:57:46 i...would not agree with that interpretation =) 18:57:56 like I said ... I'm splitting hairs 18:58:04 i think the 'boot' criterion says 'any system installed in accordance with the other criteria must boot' 18:58:09 so i think we closed that loophole, sorry :) 18:58:09 * tflink isn't proposing that we sweep it under the rug 18:58:27 a system that installs but doesn't run is useless 18:58:36 We still don't support ALL hardware. 18:58:41 yeah 18:58:55 proposed #agreed - 742226 - We need information before taking action on this bug, the exact issue and resolution still aren't clear 18:58:55 so if this turned out to be very specific to james' system we'd probably make it not a blocker 18:59:08 but it may affect all dmraid RAID-0 installs or something, which would be a bigger problem 18:59:21 i did get a similar fail with my intel controller + raid-0 18:59:34 ack 18:59:45 +1 18:59:52 #agreed - 742226 - We need information before taking action on this bug, the exact issue and potential resolution still aren't clear 19:00:00 #topic (704244) Add info about BIOS boot partition on non-EFI x86 19:00:00 #link http://bugzilla.redhat.com/show_bug.cgi?id=704244 19:00:00 #info Proposed Blocker, NEW 19:00:11 Bug 704244: unspecified, unspecified, ---, david, NEW, Add info about BIOS boot partition on non-EFI x86 19:00:17 I thought this was already fixed 19:00:42 Sorry I must away so soon -- wish I had more time to help ; will read logs when I return ; keep up good work zappers. 19:01:08 dupe of https://bugzilla.redhat.com/show_bug.cgi?id=731549 ? 19:01:09 Bug 731549: unspecified, unspecified, ---, dlehman, CLOSED ERRATA, message about BIOS boot partitions and GPT disklabels is hard to understand 19:01:24 thanks bob 19:02:04 tflink: no 19:02:07 this is filed on the install guide 19:02:15 we wanted it to be documented there 19:02:24 oh, didn't see that 19:02:30 the fact that the installer warns you about this could make this bug less important, i guess 19:02:56 it's still valid - the install guide should have a clear, in-depth explanation of the issue - but as the installer mostly saves you from shooting yourself in the foot it may not be a blocker 19:03:04 the only issue is that right now the installer doesn't save you in *all* cases 19:03:14 we fudged the custom install path for beta 19:04:02 I'm at least NTH on this 19:04:07 i think this is probably -1 blocker, it's hard to argue it hits any blocker criteria 19:04:13 but +1 nth 19:05:02 proposed #agreed - 704244 - RejectedBlocker AcceptedNTH - Documentation doesn't hit any of the release criteria but this should be fixed before release. 19:06:03 ack 19:06:11 #agreed - 704244 - RejectedBlocker AcceptedNTH - Documentation doesn't hit any of the release criteria but this should be fixed before release. 19:06:21 #topic (676488) update showing Error message ??? instead of actual error message 19:06:24 #link http://bugzilla.redhat.com/show_bug.cgi?id=676488 19:06:25 Bug 676488: unspecified, unspecified, ---, smparrish, NEW, update showing Error message ??? instead of actual error message 19:06:27 #info Proposed Blocker, NEW 19:06:48 another i18n issue? 19:06:55 from february 19:07:32 same treatment as the last i18n bug? NTH and re-visit once we have i18n criteria? 19:08:16 yeah 19:08:27 this one definitely sounds like something we'd want to take...so we need that criterion :) 19:08:29 proposed #agreed - 676488 - AcceptedNTH - We don't have any i18n criteria right now, will be proposing in the next week and will re-visit then. 19:08:40 ack 19:08:43 yeah, this is a blocker as far as I'm concerned 19:08:50 #agreed - 676488 - AcceptedNTH - We don't have any i18n criteria right now, will be proposing in the next week and will re-visit then. 19:08:58 #topic (727068) System fails to boot with selinux=0 :: mount failed for selinuxfs on /sys/fs/selinux 19:09:01 #link http://bugzilla.redhat.com/show_bug.cgi?id=727068 19:09:03 Bug 727068: medium, unspecified, ---, dwalsh, MODIFIED, System fails to boot with selinux=0 :: mount failed for selinuxfs on /sys/fs/selinux 19:09:04 #info Proposed Blocker, MODIFIED 19:09:50 proposed #agreed - 727068 - AcceptedBlocker - Hits the Fedora 16 final criteria: "The installed system must run normally if the user chooses to install without SELinux" 19:10:39 well... 19:10:41 it doesn't quite hit that 19:10:51 if you install without selinux, you don't hit the configuration that triggers this bug 19:11:06 oh, good point 19:11:11 the criteria don't actually cover the case where you have selinux installed, but disable it with the kernel parametert 19:11:25 if enforcing=0 works, i'd be reluctant to take this as a blocker 19:11:57 yeah, that makes sense 19:11:57 i'm actually -1 blocker -1 nth on this 19:12:07 there's just too many workarounds / other ways to achieve, and no particular install-time sensitivity 19:12:15 doesn't really matter all that much, since it's fixed 19:12:24 supposed to be fixed anyways 19:12:41 yeah, i wonder why the bug got stuck in modified 19:12:52 so, reject and close, i guess 19:13:21 proposed #agreed - 727068 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and there are plenty of easy workaround. 19:13:24 proposed #agreed - 727068 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and there are plenty of easy workarounds 19:13:32 +1 19:13:32 oh 19:13:34 it hasn't been pushed to stable yet, I think 19:13:36 it was probably only *just* pushed 19:13:51 #agreed - 727068 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and there are plenty of easy workarounds 19:13:58 Date Released: 2011-09-30 18:27:04 19:14:00 ack 19:14:04 #topic (741950) F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest 19:14:07 #link http://bugzilla.redhat.com/show_bug.cgi?id=741950 19:14:09 Bug 741950: unspecified, unspecified, ---, mgracik, NEW, F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest 19:14:10 #info Proposed Blocker, NEW 19:14:41 ah, that's why he was asking about lorax-17.0 19:15:37 I'd be +1 NTH on this 19:15:56 from the Xen criteria discussion on test@, I'd say that blocker is unlikely 19:16:51 er, really? 19:17:00 we had only four replies to the proposal 19:17:06 konrad is clearly +1 19:17:15 i was +/-0 so far more or less 19:17:37 davej seemed quite enthusiastic, say +0.5, and so was Andy 19:17:48 okay, all the positive responses are 'interested parties', but i didn't see anyone say 'no' 19:17:57 point taken 19:18:34 i'd say we should punt and try to refresh the xen discussion 19:18:40 maybe get more info about the ec2 case for e.g. 19:19:03 if I'm really motivated, I'll take a look @ lorax 19:19:57 proposed #agreed - 741950 - We still haven't finished hashing out the Xen release requirements, will refresh that discussion and re-visit this bug later 19:20:15 6 left! 19:20:55 ack 19:21:06 #agreed - 741950 - We still haven't finished hashing out the Xen release requirements, will refresh that discussion and re-visit this bug later 19:21:15 #topic (741655) can't boot with encrypted logical volume inside encrypted volume group 19:21:18 #link http://bugzilla.redhat.com/show_bug.cgi?id=741655 19:21:19 Bug 741655: unspecified, unspecified, ---, lvm-team, NEW, can't boot with encrypted logical volume inside encrypted volume group 19:21:21 #info Proposed Blocker, NEW 19:21:34 I'm -1 blocker on this 19:23:00 it'd be nice if anaconda gave more warning, though 19:23:50 it's kinda arguable whether it meets the "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 " criterion 19:24:15 that's meant to be a broad criterion, but it doesn't specify encryption, and that is a kind of different consideration as it involves more stuff than just anaconda's partitioning logic 19:24:24 it brings plymouth and systemd and whatever else into the game 19:24:50 NTH? 19:24:57 yeah...i think so 19:25:08 for encryption we only require the installer checkbox to work, not 'any encrypted layout you can design' 19:26:36 proposed #agreed - 741655 - RejectedBlocker AcceptedNTH - This does come close to hitting the Fedora 16 final release criteria: "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" but with the encryption scheme here, it doesn't squarely hit. However, it would be nice to have this boot o 19:26:45 ooh, nice and verbose 19:26:59 +1 19:27:33 ack 19:27:37 #agreed - 741655 - RejectedBlocker AcceptedNTH - This does come close to hitting the Fedora 16 final release criteria: "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" but with the encryption scheme here, it doesn't squarely hit. However, it would be nice to have this boot or get a w 19:27:40 (actually, already updated the bug, so you BETTER ack) :) 19:27:56 * tflink contemplates #undo 19:28:05 but wants to be done with this 19:28:07 #topic (726979) kwrite crashes in "Configure editor" (under some conditions) 19:28:09 oh, move on 19:28:10 #link http://bugzilla.redhat.com/show_bug.cgi?id=726979 19:28:11 Bug 726979: unspecified, unspecified, ---, than, ASSIGNED, kwrite crashes in "Configure editor" (under some conditions) 19:28:13 #info Proposed Blocker, ASSIGNED 19:28:40 seems like a blocker 19:28:55 "All applications listed under the Applications menu or category must start successfully " 19:28:55 "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 19:29:00 yeah, either of those 19:29:11 (the 'start successfully' criterion is probably redundant, really.) 19:29:15 +1 19:29:37 proposed #agreed - 726979 - AcceptedBlocker - Hits the following Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 19:30:38 #agreed - 726979 - AcceptedBlocker - Hits the following Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 19:30:48 #topic (723709) FTBFS: qt-mobility against qt-4.8.0-beta1 19:30:48 #link http://bugzilla.redhat.com/show_bug.cgi?id=723709 19:30:48 #info Proposed Blocker, ON_QA 19:30:49 Bug 723709: unspecified, unspecified, ---, rdieter, ON_QA, FTBFS: qt-mobility against qt-4.8.0-beta1 19:31:16 I don't think FTBFS is a blocker on its own. 19:31:27 right 19:31:32 it got pulled in from a tracker 19:31:49 ah 19:31:56 oh, that KDE tracker. 19:32:00 and the tracker blocks KDE 19:32:04 meh, it's modified anyway. let's punt on it. 19:32:14 it'll go away next week and we won't have to care! 19:32:22 * adamw is willing to give KDE team a bit of a long leash, as they usually know what they're doing 19:32:31 Just say NTH? 19:32:45 nah, nth makes no real sense. 19:32:52 * adamw wants to avoid the 'whatever, call it nth' trap 19:33:16 if they put it on the tracker, it probably means it does cause some significant problem. 19:33:21 proposed #agreed - 723709 - Need more information on how this bug is a blocker before making a decision, will re-visit 19:33:28 they don't just throw any old crap on the KDE tracker. 19:33:32 ack 19:33:34 I like that. 19:33:40 it looks to be blocking the build of new qt 19:33:43 +1 19:33:51 #agreed - 723709 - Need more information on how this bug is a blocker before making a decision, will re-visit 19:33:58 #topic (728857) virtuoso-opensource: encoding error with KDE NEPOMUK. 19:33:58 #link http://bugzilla.redhat.com/show_bug.cgi?id=728857 19:33:58 #info Proposed Blocker, ON_QA 19:33:59 Bug 728857: medium, unspecified, ---, rdieter, ON_QA, virtuoso-opensource: encoding error with KDE NEPOMUK. 19:34:12 another KDE blocker 19:34:49 yeah, we're in the kde blocker deps here obviously. 19:34:50 proposed #agreed - 728857 - Need more information on how this bug is a blocker before making a decision, will re-visit 19:34:54 recycle! 19:35:24 i think this hits "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items " 19:35:43 because it means the desktop search bit of KDE doesn't work right, as indexing doesn't work right 19:35:48 i'd be okay with +1 under that criterion 19:36:01 oh, I was thinking virtuoso was something different 19:36:33 i think virtuoso is used as part of the indexing process 19:36:40 I think that would make it a blocker. 19:36:46 but the ultimate user-visible effect of the bug is 'none of my desktop search stuff works because the indexes are borked' 19:37:00 "You will reindex this file constantly" is also nasty as it'll cause increased resource use 19:37:32 proposed #agreed - 728857 - AcceptedBlocker - Hits the following Fedora 16 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 19:37:41 ack 19:37:53 +1 19:37:59 #agreed - 728857 - AcceptedBlocker - Hits the following Fedora 16 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 19:38:14 * tflink was thinking virtuoso was a virtualization tool 19:38:48 #topic (731245) KDE fails to start inside a VM , large amount of memory [@ miCopyRegion] 19:38:52 #link http://bugzilla.redhat.com/show_bug.cgi?id=731245 19:38:53 Bug 731245: high, unspecified, ---, sandmann, NEW, KDE fails to start inside a VM , large amount of memory [@ miCopyRegion] 19:38:54 #info Proposed Blocker, NEW 19:39:29 oh, god, this one. 19:39:35 been around since alpha, we never get time to look into ti. 19:40:23 isn't this more of a beta blocker, anyways? 19:40:28 "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)" 19:40:52 good thing i smuggled that one past you. =) 19:40:58 well, there's a workaround - use 'basic graphics mode' 19:41:08 or spice, I think 19:41:09 but...yeah. it kinda sucks. it would be ugly to release this way 19:41:16 nah, i'm using spice when i hit the bug 19:41:23 ok 19:41:38 dunno what oliver did 19:41:43 either way, I'm +1 blocker on this since the same bug would be a blocker for gnome 19:41:50 yeah. i think we should take it. 19:42:05 i can imagine there being pressure to fudge it if this was the last blocker on go/no-go day, but...let's be firm. :) 19:42:14 +1 19:42:28 i'll try to suck less at investigating it and helping kevin fix 19:42:29 proposed #agreed - 731245 - AcceptedBlocker - Hits the following Fedora 16 beta release criteria: "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)" 19:42:32 ack 19:42:44 +1 19:42:46 #agreed - 731245 - AcceptedBlocker - Hits the following Fedora 16 beta release criteria: "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)" 19:42:51 LAST ONE! 19:42:59 #topic (725219) anaconda should run in clone not span mode 19:42:59 #link http://bugzilla.redhat.com/show_bug.cgi?id=725219 19:42:59 #info Proposed Blocker, NEW 19:43:00 Bug 725219: low, unspecified, ---, ajax, NEW, anaconda should run in clone not span mode 19:43:51 +1 NTH, not so sure about blocker 19:44:06 workaround -> unplug one of your monitors 19:44:15 yeah 19:44:22 it's annoying, but the workaround's reasonable. 19:44:40 sounds like it got proposed so that it didn't get lost 19:45:14 yeah 19:45:19 that's not a terribly convincing blocker proposal =) 19:45:57 proposed #agreed - 725219 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria and the workaround is simple (unplug one monitor) but it would be nice to fix. 19:46:03 +1 19:46:25 #agreed - 725219 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria and the workaround is simple (unplug one monitor) but it would be nice to fix. 19:47:09 OK, done with the proposed blockers! 19:47:21 * tflink is tempted to leave the proposed NTH for next week 19:47:40 looks like there are 8 19:48:06 i could do 'em this week, but if you're really flagging, we can punt 19:48:16 it's not super important to make a call on those until freeze time 19:48:23 says the man who showed up an hour late :-P 19:48:48 alrighty, let's just get this over with 19:48:50 #topic (734967) /sbin/loader received SIGSEGV when using kickstart file. 19:48:53 #link http://bugzilla.redhat.com/show_bug.cgi?id=734967 19:48:54 Bug 734967: high, unspecified, ---, akozumpl, POST, /sbin/loader received SIGSEGV when using kickstart file. 19:48:55 #info Proposed NTH, POST 19:49:25 oh, yeah, we should do the anaconda ones at least 19:49:35 as anaconda have a strict policy of not pushing anything unless it's nth or blocker these days 19:49:40 so we want to get their fixes in for tc 19:49:52 i'm basically +1 nth for any anaconda crash, so +1. 19:50:14 yeah, I'm ok with NTH 19:50:44 proposed #agreed - 734967 - AcceptedNTH - This fixes an anaconda crash and a fix is ready. 19:50:51 ack 19:51:30 #agreed - 734967 - AcceptedNTH - This fixes an anaconda crash and a fix is ready. 19:51:43 #topic (738607) sshd doesn't work 19:51:43 #link http://bugzilla.redhat.com/show_bug.cgi?id=738607 19:51:43 #info Proposed NTH, NEW 19:51:44 Bug 738607: unspecified, unspecified, ---, mgracik, NEW, sshd doesn't work 19:52:16 hum 19:52:24 since this has been this way approximately forever, not sure if i 19:52:26 i'd NTH it 19:52:40 yeah, c10 says something similar 19:53:03 the only issue is the tight anaconda policy now, but that shouldn't mean we NTH anything that we think it's okay for anaconda to change outside of a freeze, it means we should talk to them about tweaking their policy a tad 19:53:19 Plus if it ends up being RFE, then there won't be incentive to do it soon. 19:53:22 so, by the actual intended purpose of the NTH process, -1, this isn't the kind of change i'd want to take through a freeze. 19:54:08 proposed #agreed - 738607 - RejectedNTH - This is more of an RFE than a bug and not something that really needs to be taken during code freeze 19:54:27 +1 19:54:37 #agreed - 738607 - RejectedNTH - This is more of an RFE than a bug and not something that really needs to be taken during code freeze 19:54:43 #topic (739861) move the fedora logo to the left 19:54:43 #link http://bugzilla.redhat.com/show_bug.cgi?id=739861 19:54:43 #info Proposed NTH, POST 19:54:44 Bug 739861: unspecified, unspecified, ---, anaconda-maint-list, POST, move the fedora logo to the left 19:54:54 I was wondering where this bug went 19:55:48 eh, I'm not sure this is NTH worthy but we do have the artwork criteria ... 19:55:52 Well it's something that can't be fixed in an update. It sems kind of a minor thing, but I am not a art designer. 19:56:34 (At least if they are talking about a logo displayed during install.) 19:56:58 adamw: thoughts? 19:57:17 yeah, same deal as the last bug to me. 19:57:17 I guess I'd be OK with NTH since it probably should be fixed 19:57:21 but it seems silly to me 19:57:22 well... 19:57:34 it is a visible polish issue 19:57:37 but it's still kinda pushing things 19:58:20 especially when it could just go into the next build before final freeze 19:58:20 i guess i could just about be okay with +1 for this. 19:58:29 And artwork changes have the potential to break things. 19:58:36 given that we can refuse to take nth fixes too late post-freeze; it's a discretionary thing. 19:58:40 but yeah...it's pretty borderline. 19:58:55 Last year a several images went oversize after a late artwork change. 19:59:05 true 19:59:17 this change shouldn't cause _that_ problem, but it demonstrates that 'trivial' art changes can have unintended consequences 19:59:19 all the more reason to fix it now ... 19:59:22 yeah 19:59:39 i think maybe -1 as this really should be done before freeze, and cite the note from the previous bug about tweaking anaconda's commit policies 20:00:12 That would be a better way to do it. 20:00:25 that makes sense to me. I'd rather not be doing NTH at this point for a fix that is ready and potenially disruptive later 20:00:32 yup. 20:01:27 proposed #agreed - 739861 - RejectedNTH - This is an artwork change that may not be something to take past code freeze 20:01:40 proposed #agreed - 739861 - RejectedNTH - This is an artwork change that may not be something we want to take past code freeze 20:01:47 +1 20:01:59 #agreed - 739861 - RejectedNTH - This is an artwork change that may not be something we want to take past code freeze 20:02:06 #topic (741446) Can't log in after Lock screen 20:02:06 #link http://bugzilla.redhat.com/show_bug.cgi?id=741446 20:02:06 #info Proposed NTH, NEW 20:02:07 Bug 741446: unspecified, unspecified, ---, rstrode, NEW, Can't log in after Lock screen 20:02:45 I'm +1 NTH on this, possibly blocker 20:03:04 I tried it and I'm thinking that there might be a deeper problem 20:03:18 +1 NTH 20:03:22 the keyboard layout seems to change on an arbitrary yet predictable basis 20:03:34 but once you lock the screen, you get what you get for a keyboard layout 20:03:50 the widget for changing the layout appears to change but has no affect on the layout used 20:04:07 gdm seems to be similar from my tesing, anyways 20:04:35 * tflink forgot to add info to the bug 20:04:51 but with what we know now for the bug that is described here ... 20:05:40 proposed #agreed - 741446 - AcceptedNTH - This is a huge pain for anyone who has a password in a non-english layout even though it doesn't directly hit any release criteria 20:05:51 okay, +1 indeed then, if you could reproduce issues that's good enough for me 20:06:07 #agreed - 741446 - AcceptedNTH - This is a huge pain for anyone who has a password in a non-english layout even though it doesn't directly hit any release criteria 20:06:19 #topic (741375) default ACPI behavior makes it impossible to cleanly shutdown F16 guest from the host 20:06:22 #link http://bugzilla.redhat.com/show_bug.cgi?id=741375 20:06:25 #info Proposed NTH, NEW 20:06:25 Bug 741375: unspecified, unspecified, ---, bnocera, NEW, default ACPI behavior makes it impossible to cleanly shutdown F16 guest from the host 20:06:55 eh, I'm not so enthusiastic about this one 20:07:16 I think that I'm -1 NTH on this - I don't think its something that would need to be taken through a freeze 20:07:23 it could be fixed with updates 20:07:27 yeah. 20:07:54 -1 20:08:19 proposed #agreed - 741375 - RejectedNTH - This doesn't seem like something that should be taken past code freeze and could be fixed with updates post-release 20:09:52 ack 20:10:02 #agreed - 741375 - RejectedNTH - This doesn't seem like something that should be taken past code freeze and could be fixed with updates post-release 20:10:06 #topic (678453) Grub2 Menu entries doesn't contain the name of distribution 20:10:09 #link http://bugzilla.redhat.com/show_bug.cgi?id=678453 20:10:11 #info Proposed NTH, NEW 20:10:11 Bug 678453: unspecified, unspecified, ---, pjones, NEW, Grub2 Menu entries doesn't contain the name of distribution 20:11:07 I think this one falls under the same "wouldn't take past freeze" for me 20:11:16 and could be fixed with an update 20:12:09 doesn't sound like something where a fix would have a big impact 20:12:15 i'd rather say nth 20:12:37 it shouldn't have a big impact, no 20:12:37 I'm -1 NTH -1 Blocker 20:12:47 but I'd still rather not mess with grub past freeze 20:12:57 not for something cosmetic, anyways 20:13:09 like adding a string? 20:13:34 if it's that easy of a fix, why does it need to be NTH? 20:13:37 There is time to get the fix in now. 20:13:47 sorry, was discussing the freeze issue with anaconda team 20:14:12 proposed #agreed - 678453 - RejectedNTH - This is a cosmetic RFE that we probably wouldn't take past freeze 20:14:16 But if it's not ready by final freeze, I think it should be deferred. 20:14:23 ack/nak/patch? 20:14:28 brunowolff: +1 20:14:29 +1 20:14:43 -1 20:15:07 (I'd rather say if we have a fix take if we don't se be it) 20:15:17 I'm +1 so were currently at +2/-1 => +1 20:15:21 any other votes? 20:16:17 adamw: any other votes? 20:17:36 sorry, gimme a sec 20:17:52 -1 nth 20:17:55 so ack to the proposal 20:18:20 ok, that makes 3ack/1nak 20:18:33 #agreed - 678453 - RejectedNTH - This is a cosmetic RFE that we probably wouldn't take past freeze 20:18:47 #topic (711489) atl1c: transmit queue timeout (Acer Aspire One 522) 20:18:47 #link http://bugzilla.redhat.com/show_bug.cgi?id=711489 20:18:47 #info Proposed NTH, ASSIGNED 20:18:51 Bug 711489: unspecified, unspecified, ---, kernel-maint, ASSIGNED, atl1c: transmit queue timeout (Acer Aspire One 522) 20:19:05 didn't we see this for F15? 20:19:50 sounds vaguely familiar, yeah 20:20:00 Yes. 20:20:02 yeah, initial report is f15 20:20:45 I guess I'm probably -0 at most on this 20:20:51 i'm fine with nth as it's an ugly hardware issue, the impact is severe but limited in breadth 20:21:05 it would be a blocker if it affected more hardware 20:21:15 I'm leaning toward NTH. 20:21:16 so i think nth is okay 20:21:20 ok 20:21:27 it would kinda suck to have a fix for this but not take it 20:21:43 I don't know how common the hardware is. 20:21:46 proposed #agreed - 711489 - AcceptedNTH - This bug is ugly but it affects a small subset of hardware 20:21:59 +1 20:22:03 the aspire one is a reasonably common netbook 20:22:22 there's zillions of aspire ones 20:22:26 i think this affects one specific model 20:22:34 but _any_ aspire one model will probably have sold quite a few, so yeah. 20:22:38 ack 20:22:43 #agreed - 711489 - AcceptedNTH - This bug is ugly but it affects a small subset of hardware 20:22:50 aspire one is what acer calls all their netbooks 20:22:53 #topic (739334) Adjust service disabling for systemd, and remove some dead wood 20:22:57 #link http://bugzilla.redhat.com/show_bug.cgi?id=739334 20:22:58 Bug 739334: high, unspecified, ---, kanarip, NEW, Adjust service disabling for systemd, and remove some dead wood 20:22:59 #info Proposed NTH, NEW 20:23:20 This seems like something that should go in now, not after freeze. 20:23:31 brunowolff: well sure 20:23:39 brunowolff: it's always better to fix issues earlier 20:23:59 brunowolff: but if a fix for this was found between, say, rc1 and rc2, i'd want to pull it in 20:24:05 as long as it wasn't too sketchy 20:24:24 oh wait 20:24:24 sorry 20:24:29 i thought we were still on the last bug :) 20:24:50 shouldn't this be filed against spin-kickstarts? 20:25:00 nvm, I can't read 20:25:08 I thought that it was filed against systemd for some reason 20:25:25 brunowolff: yeah...you're probably right 20:25:26 Has Brian looked at this yet? 20:25:33 we shouldn't be fiddling with it between rcs 20:25:41 He has been doing a lot of related stuff recently. 20:25:42 i haven't had any feedback on it from anyone 20:25:48 brian who? 20:25:58 bcl 20:26:05 ah 20:26:09 hadn't heard from him, no 20:26:16 he's been working on spin kickstarts? 20:26:29 Well live images. 20:27:07 I'm -1 NTH on this - if it's working once we hit freeze, lets not mess with it 20:27:19 * nirik hasn't had time to look at it too much, but if it tests out ok, I'm fine with landing it... will make things much nicer. 20:27:25 if it breaks something, re-propose this or something else as a blocker 20:27:28 it tested fine for me 20:27:29 but yeah, it should land like now... 20:27:38 okay, -1's good with me 20:27:38 Yeah I wandered a bit in trying to figure out how me might do this before freeze. 20:27:49 but bruno and nirik, if you guys could test it and commit that'd be great 20:27:52 i'm fairly confident it's correct 20:28:09 I am one of the spin-kickstarts people, but it was on the edge of what I was comfortable with reviewing. 20:28:29 proposed #agreed - 739334 - RejectedNTH - If the spin kickstarts are working at freeze, leave them alone. If an issue is found, re-propose this or the found issue as a blocker 20:28:46 I was thinking bcl might be involved, but he really does more on the livecd-tools stuff. 20:29:12 kanarip has been busy for a long time now and may not get a chance to look at it. 20:29:16 ack 20:29:23 kana: thanks for the heads-up 20:29:26 erf 20:29:29 i thought that was a /me :) 20:29:44 #agreed - 739334 - RejectedNTH - If the spin kickstarts are working at freeze, leave them alone. If an issue is found, re-propose this or the found issue as a blocker 20:29:47 I can try to look at it and do some testing. 20:29:55 brunowolff: i think maybe the best thing to do is just for you to try it yourself and build a few lives and check them out, if you're happy, we commit it asap and see if any nightly users yell 20:30:04 we certainly have people who use the nightlies, so if it breaks anything, we should hear 20:30:12 ok, that's all of the proposed NTH 20:30:15 and the earlier we commit it the longer we have to find out about breakage and revert 20:30:46 tflink: awesome 20:30:55 Yeah. I'll do at least some testing this weekend. 20:31:10 * tflink thinks that all of the currently accepted blockers were from yesterday's go/no-go 20:31:39 nvm 20:33:21 any desire to go through the accepted blockers as a group? 20:33:29 I can go through and poke people otherwise 20:33:40 some of these haven't been touched in almost a month 20:33:52 I'd like to stay under 4 hrs. 20:34:14 same here 20:34:21 but I am glad that we did this this week 20:34:35 * tflink doesn't want to think about what the list would have looked like in another week 20:36:25 * tflink makes executive decision 20:36:31 #topic open discussion 20:36:38 any other topics that should be covered? 20:37:05 * tflink sets fuse for 2 minutes 20:38:06 #info Fedora 16 final blocker bug review meeting #2 will be 2011-10-07 @ 17:00 UTC 20:38:24 sorry, got a phone call 20:38:30 yeah let's review accepted next week 20:38:48 are you going to do the rest of the bug updating or am I? 20:39:45 OK, thanks for coming everyone. This was a long one! 20:39:51 * tflink will be sending out minutes shortly 20:39:53 #endmeeting