17:00:22 <tflink> #startmeeting F17-alpha-blocker-review-4 17:00:22 <zodbot> Meeting started Fri Feb 17 17:00:22 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:26 <tflink> #meetingname F17-alpha-blocker-review-4 17:00:27 <zodbot> The meeting name has been set to 'f17-alpha-blocker-review-4' 17:00:35 <tflink> #topic roll call 17:00:45 <tflink> who's ready for some blocker review fun? 17:01:07 <tflink> #chair adamw 17:01:07 <zodbot> Current chairs: adamw tflink 17:03:13 * adamw will lie back and think of fedora 17:04:18 <tflink> adamw: it sounds like you're leaving 17:05:05 <adamw> i was referencing james bond... 17:05:07 <adamw> think it was bond, anyway. 17:05:32 * nirik is lurking around if he can assist with any bugs. 17:05:50 <tflink> might be, just because I'm not familiar with the reference doesn't mean much 17:06:16 <adamw> oh, nope, not bond. https://en.wikipedia.org/wiki/Lie_back_and_think_of_England 17:06:30 * tflink waits a few more minutes in the hope that another person or two might join 17:07:09 <adamw> they're all too sensible. 17:07:31 <brunowolff> I am sort of here. 17:07:52 <Viking-Ice> here 17:08:13 <tflink> well, that makes 3 full people and 2 somewhat-less-than-full people :) 17:08:19 <tflink> let's get this party started 17:08:37 <tflink> #topic Introduction 17:08:54 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 17:09:08 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:09:08 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:09:18 <tflink> #info 3 proposed blockers 17:09:18 <tflink> #info 3 accepted blockers 17:09:18 <tflink> #info 1 Proposed NTH 17:09:39 <tflink> unless there are objections, I'm going to start with the proposed blockers 17:10:08 <tflink> #topic (771484) ldap_result does not succeed for sssd 17:10:08 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=771484 17:10:08 <tflink> #info Proposed Blocker, NEW 17:10:10 <buggbot> Bug 771484: urgent, unspecified, ---, jvcelak, NEW, ldap_result does not succeed for sssd 17:10:59 <Viking-Ice> so adamw how did this one end up there? 17:11:30 <tflink> I'm not so sure this is blocker or nth material for alpha 17:11:48 <adamw> Viking-Ice: it was requested by sgallagh 17:11:55 <Viking-Ice> I dont think his one is a blocker either 17:12:03 <tflink> this only hits users that auth against an external system, no? 17:12:03 <adamw> the bug could have pretty serious implications for ldap / sssd configs 17:12:05 <adamw> yes 17:12:14 <adamw> the question is, how common / important do we think that is 17:12:29 <tflink> do we even have test cases for this? 17:12:36 <adamw> tflink: well, it could possibly also affect people who use LDAP for things other than auth, but we aren't sure of that yet. 17:12:54 <adamw> no, we don't. but someone always goes and tests it anyway. =) 17:12:56 <Viking-Ice> for alpha not so much 17:13:16 <Viking-Ice> as in importance of this 17:13:19 <tflink> if we aren't sure yet, that makes me think that there are either not many people using it yet or its OK 17:13:20 <adamw> yeah, i'm -1 blocker too 17:13:37 <Viking-Ice> looks more like a beta material to me 17:13:48 <adamw> probably +1 nth though, as the fix ought to be isolated 17:13:53 <tflink> I'd probably be OK with NTH if there was a tested fix 17:14:26 <Viking-Ice> that's 3 NTH brunowolff? 17:14:57 <brunowolff> I am mildly +1 nth. It seems safe. 17:15:11 <adamw> let's roll with nth then, as long as the fix remains isolated in the ldap packages 17:15:20 <adamw> if it winds up needing a kernel patch or something, we can revisit =) 17:15:26 <Viking-Ice> =) 17:15:43 <tflink> proposed #agreed - 771484 - RejectedBlocker, AcceptedNTH - This doesn't clearly violate any release criteria but it does prevent login on systems that use external auth - a tested fix would be OK for alpha NTH. If the bug ends up being more serious than it seems right now, will re-visit 17:16:26 <adamw> ack 17:16:40 <Viking-Ice> ack 17:16:51 <brunowolff> ack 17:17:09 <tflink> #agreed - 771484 - RejectedBlocker, AcceptedNTH - This doesn't clearly violate any release criteria but it does prevent login on systems that use external auth - a tested fix would be OK for alpha NTH. If the bug ends up being more serious than it seems right now, will re-visit 17:17:21 <tflink> #topic (790522) Private /tmp are broken 17:17:21 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=790522 17:17:21 <tflink> #info Proposed Blocker, VERIFIED 17:17:25 <buggbot> Bug 790522: unspecified, unspecified, ---, systemd-maint, VERIFIED, Private /tmp are broken 17:19:21 <Viking-Ice> this one should just be fixed via regular update 17:19:26 <tflink> it sounds like this could be fixed easily with an update 17:19:40 <adamw> well, i'm not so sure 17:20:01 <adamw> it looks to me like private /tmps created before the update don't have their permissions fixed 17:20:19 <tflink> how badly is dhcpd affected? 17:20:26 <adamw> but it's kinda academic since we stuck the fix in rc2 anyway =) 17:20:28 <adamw> tflink: it isn't. 17:21:04 <tflink> adamw: we did? 17:21:09 <adamw> i did. 17:21:16 <adamw> since SOMEONE wasn't around ;) 17:21:24 <tflink> if its already there then there's no harm in NTH 17:21:32 <tflink> adamw: who might that be? 17:21:37 <tflink> :-D 17:21:40 <adamw> John Cleese, of course 17:21:44 <adamw> I basically agree with comment #12 17:22:03 <brunowolff> +1 to tflink's suggestion 17:22:07 <adamw> we're not aware of any huge breakage caused by this at the moment, but it's obviously the kind of thing which potentially _could_ cause huge breakage so it's probably safer to just fix it than cross fingers 17:22:42 <Viking-Ice> yeah sure but a blocker no =) 17:22:51 <adamw> right, we can't call it a blocker on current info, only nth. 17:23:07 <tflink> proposed #agreed - 790522 - RejectedBlocker, AcceptedNTH - This has already been pulled in to F17 Alpha RC2 and has the potential to cause other problems 17:23:13 <Viking-Ice> ack 17:23:50 <adamw> ack 17:23:56 <tflink> #agreed - 790522 - RejectedBlocker, AcceptedNTH - This has already been pulled in to F17 Alpha RC2 and has the potential to cause other problems 17:24:00 <tflink> #topic (789271) firstboot-text prevents system from booting 17:24:00 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=789271 17:24:00 <tflink> #info Proposed Blocker, VERIFIED 17:24:02 <buggbot> Bug 789271: unspecified, unspecified, ---, xgl-maint, VERIFIED, firstboot-text prevents system from booting 17:24:09 <tflink> I still don 17:24:16 <tflink> t understand how this impacted firstboot 17:24:24 <Viking-Ice> plymouth 17:24:26 <tflink> but hongqing claims that its been fixed 17:24:59 <tflink> Viking-Ice: but there is no firstboot-text any more 17:25:16 <Viking-Ice> right got bugs mixed 17:25:33 <tflink> either way, it's reported to be fixed 17:25:40 <adamw> yeah, whatever he was hitting, it wasn't in firstboot. but hey, if it went away, let's not bother about it any more. 17:25:48 <Viking-Ice> =) 17:26:17 <tflink> proposed #agreed - RejectedBlocker - This is reported to be fixed, blocker status is not needed. Ask reporter to close the bug 17:26:19 <adamw> oh - this might actually be the shell-in-KVM crash? possibly. 17:26:31 <adamw> oh, no, it was vesa. 17:27:27 <tflink> #agreed - RejectedBlocker - This is reported to be fixed, blocker status is not needed. Ask reporter to close the bug 17:27:48 <tflink> OK, that's it for the proposed blockers. Now for the one proposed NTH 17:27:55 <tflink> #topic (790537) [abrt] kernel: WARNING: at arch/x86/kernel/traps.c:729 do_device_not_available+0x33/0x40() 17:27:59 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=790537 17:28:00 <buggbot> Bug 790537: unspecified, unspecified, ---, kernel-maint, MODIFIED, [abrt] kernel: WARNING: at arch/x86/kernel/traps.c:729 do_device_not_available+0x33/0x40() 17:28:01 <tflink> #info Proposed NTH, MODIFIED 17:28:35 <jwb> so Linus has gone and rewritten a bunch of the code in that area yesterday 17:28:46 <adamw> this was requested by jwb (kernel team) 17:28:57 <Viking-Ice> I'm +1 on NTH on the ground of keeping the kernel teams sanity 17:28:59 <tflink> based on c#5, I'm not against NTH on this 17:29:16 <jwb> we're expecting the current kernel in RC2 to get quite a number of these reports, but no real issues that i'm aware of 17:29:31 <jwb> i should have a kernel with all of Linus' changes built later today and into updates-testing 17:29:42 <adamw> how vital is the code in question? 17:29:53 <jwb> vital in what way? 17:29:56 <adamw> well 17:30:01 <adamw> let me expand 17:30:13 <adamw> a fix which is just disabling the WARN_ON is obviously very unlikely to break anything 17:30:28 <adamw> a fix which involves disabling the WARN_ON *and rewriting all the code* seems...more likely to break stuff :) 17:30:48 <adamw> so what code are we actually looking at here? if linus screwed it up, do we wind up with non-booting machines? horrendous crashes? eaten babies? 17:31:01 <jwb> i booted it this morning on two machines without issue 17:31:10 <jwb> however, that is not an extensive testing 17:31:40 <jwb> if he really hosed it up, i'd say we'd get some odd crashes in userspace due to incorrect handling of FPU states 17:31:46 <davej> this is code that if wrong, would blow up pretty quickly. anything that uses floating point/sse gets into this codepath 17:32:19 <adamw> okay. well, personally...i guess i'm okay with +1 nth for this case since we still have a while before release and we're not drowning in other bugs 17:32:21 <jforbes> I can go grab my daughter and boot with it here to see if it eats babies, but I dont expect it to 17:32:29 <tflink> proposed #agreed - 790537 - This isn't a major functional issue but it is visable and will likely generate a lot of bug reports against alpha - a well tested fix would be accepted 17:32:36 <Viking-Ice> ack 17:32:43 <adamw> but *in general* i don't want to set a precedent that we're happy to stick giant rewrites into the kernel post-freeze to fix cosmetic problems 17:32:49 <adamw> ack 17:32:51 <tflink> proposed #agreed - 790537 - AcceptedNTH - This isn't a major functional issue but it is visable and will likely generate a lot of bug reports against alpha - a well tested fix would be accepted 17:33:01 <tflink> forgot the resolution :) 17:33:12 <jwb> define well tested 17:33:12 <tflink> #agreed - 790537 - AcceptedNTH - This isn't a major functional issue but it is visable and will likely generate a lot of bug reports against alpha - a well tested fix would be accepted 17:33:22 <adamw> jwb: this is fedora, so booting it on two machines counts. ;) 17:33:39 <jwb> huh. our definitions differ greatly. i'll try to do better than that 17:33:40 <tflink> jwb: let's see how it does in updates-testing 17:33:47 <jwb> tflink, quite fair 17:34:11 <adamw> yeah, it'd be good to get an updates-testing push done today so we get results over the weekend. 17:34:16 <brunowolff> Is there a policy on whether or not alpha and beta get debug kernels? 17:34:26 <adamw> brunowolff: alpha gets debug, beta gets release, apparently. 17:35:16 <Viking-Ice> yup sound correct 17:35:20 <tflink> ok, that's all of the proposed bugs for this week - on to the accepted blockers 17:35:28 <tflink> #topic (787744) RuntimeError: device is already mapped (F17 Alpha TC1) 17:35:32 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=787744 17:35:33 <buggbot> Bug 787744: unspecified, unspecified, ---, anaconda-maint-list, ASSIGNED, RuntimeError: device is already mapped (F17 Alpha TC1) 17:35:34 <tflink> #info Accepted Blocker, ASSIGNED 17:36:10 <tflink> sounds like this is still an issue, waiting on info from reporter 17:36:44 <tflink> not sure that there is anything that still needs to be done on our end 17:37:47 <Viking-Ice> if lorax has been pulled in I would not think so 17:38:00 <Viking-Ice> as in the lorax update 17:38:03 <adamw> well, jskladan is on our team so we should probably bug him to provide the requested info. 17:38:08 <adamw> and of course we could all check our cmdlines. 17:38:19 <tflink> RC2 wouldn't have built if the new lorax wasn't pulled in 17:38:45 <adamw> i guess it's most likely josef messed up, or the fix for this in lorax was broken. 17:39:09 <tflink> that seems to cover it 17:40:19 <tflink> #info information needed from reporter, it's possible that this wasn't fixed but also possible that there was an error in testing 17:41:00 <tflink> anything I missed on this? 17:41:06 <adamw> #action adamw to poke jskladan to update 787744 17:41:20 <tflink> that works 17:41:31 <tflink> ok, on to the next one 17:41:34 <tflink> #topic (787261) Fedora 17 Alpha TC1 still has all F16 artwork 17:41:34 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=787261 17:41:34 <tflink> #info Accepted Blocker, VERIFIED 17:41:35 <buggbot> Bug 787261: unspecified, unspecified, ---, tcallawa, VERIFIED, Fedora 17 Alpha TC1 still has all F16 artwork 17:41:45 <tflink> I think this can be closed, no? 17:42:00 <tflink> or is it still lacking in karma? 17:42:04 <Viking-Ice> that one should not have been there to begin with 17:42:16 <adamw> tflink: doesn't get closed till the update is pushed stable. 17:42:24 <adamw> but yeah, as far as composes go, it's fixed, we don't need to worry about it. 17:42:37 <Viking-Ice> blocking there released because of cosmetic issues <sigh> 17:42:49 <tflink> OK, other than more karma, it sounds like this is on track 17:42:50 <adamw> tflink: we use VERIFIED status for bugs in this situation (the fix is already in a compose, but has not been pushed stable through the updates process yet) 17:42:55 <Viking-Ice> s/there/the 17:43:25 <tflink> Viking-Ice: yeah, it does seem trivial but it also confuses people to see Fn-1 artwork when they think they're installing Fn 17:43:32 <adamw> let's not discuss this here *please* 17:43:39 <tflink> either way, it's fixed and shouldn't cause slippage 17:43:45 <adamw> on-list for criteria change proposals 17:44:16 <tflink> #info Package has been fixed, need karma for fedora-logos-17.0.0-1.fc17 17:44:24 * adamw just karma'ed 17:44:33 <tflink> #topic (791032) repoclosure failure in 17-Alpha.RC2 DVDs (ceph-0.37-2.fc17) 17:44:36 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=791032 17:44:37 <buggbot> Bug 791032: unspecified, unspecified, ---, tcallawa, NEW, repoclosure failure in 17-Alpha.RC2 DVDs (ceph-0.37-2.fc17) 17:44:39 <tflink> #info Accepted Blocker, NEW 17:44:46 <adamw> spot fixed up the ceph build for us cos he's a hero 17:44:51 <tflink> sounds like this is in a similar boat 17:44:53 <adamw> so now we just need to test and karma it 17:45:00 <adamw> well, slightly different - the fix isn't in rc2 17:45:12 <tflink> #info packages are fixed, will be pulled into the next RC 17:45:36 <adamw> karma https://admin.fedoraproject.org/updates/FEDORA-2012-1771/ceph-0.41-1.fc17,gperftools-2.0-4.fc17 17:45:47 <tflink> adamw: thanks, I was just looking for that 17:46:16 <tflink> #info karma is needed for ceph-0.4101.fc17 and gperftools-2.0-4.fc17 17:46:33 <tflink> That's it for all of the bugs that were on my list 17:46:46 <tflink> Anything I missed? 17:46:47 <adamw> yay short blocker meetings 17:47:06 <Viking-Ice> =)+ 17:47:10 * tflink is starting to get worried - these blocker meetings have been really short for F17 17:47:15 <tflink> #topic open floor 17:47:39 <brunowolff> Things seem MUCH better this release than I remember for releases in the not too distant past. 17:47:53 <Viking-Ice> adamw, did the dracut update for that intel bios raid bug get pulled? 17:47:57 * adamw is wondering why https://bugzilla.redhat.com/show_bug.cgi?id=787461 isn't proposed as a blocker 17:47:59 <adamw> Viking-Ice: yeah, it did 17:48:00 <buggbot> Bug 787461: unspecified, unspecified, ---, anaconda-maint-list, NEW, system halts at first reboot after install 17:49:00 <tflink> adamw: yeah, that sounds like blocker material to me 17:49:06 * satellit_ https://bugzilla.redhat.com/show_bug.cgi?id=783712 no wireless AP's in sugar f17 17:49:08 <buggbot> Bug 783712: unspecified, unspecified, ---, dcbw, ASSIGNED, No wireless Access points - Fedora-17-Nightly-20120120.10-i686-Live-soas.iso 17:49:08 <adamw> seems that text install is broken 17:49:21 <tflink> adamw: vnc was reported, too 17:50:18 <robatino> i was doing minimal GUI install 17:50:36 <tflink> #topic (787461) system halts at first reboot after install 17:50:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=787461 17:50:37 <tflink> #info Proposed Bliocker, NEW 17:50:38 <buggbot> Bug 787461: unspecified, unspecified, ---, anaconda-maint-list, NEW, system halts at first reboot after install 17:50:39 <robatino> the bootloader corruption seems to happen sporadically 17:50:55 <Viking-Ice> that traceback is what get's me worried 17:51:02 <tflink> this seems like a clear blocker to me 17:51:20 <Viking-Ice> yeah it should be 17:51:40 <adamw> yeah, i'd like to reproduce locally but i'm happy considering it a blocker 17:51:49 <adamw> well, not happy, but...y'know :) 17:52:06 <tflink> proposed #agreed - 787461 - AcceptedBlocker - The installer must be able to complete an installation using the text, graphical and VNC installation interfaces 17:52:11 <adamw> it's not just the thing that systemd spams messages after painting the login prompt, but the login prompt still works, is it? 17:52:16 <adamw> ack 17:52:45 <tflink> adamw: doesn't sound like it to me 17:53:03 <tflink> but then again, I've been having trouble getting F17 anything to even install completely 17:53:21 * tflink thinks it's issues outside fedora 17:53:52 <Viking-Ice> ack btw 17:54:13 <tflink> #agreed - 787461 - AcceptedBlocker - The installer must be able to complete an installation using the text, graphical and VNC installation interfaces 17:54:18 <adamw> my couple of rc2 install tests both went fine. 17:54:39 <Viking-Ice> where those text installs ? 17:55:46 <tflink> adamw: my main machine seems to be having virt issues @ bootloader install (it just hangs). Tests on another machine went finer 17:56:33 <adamw> Viking-Ice: no, so i'll check that 17:56:47 <Viking-Ice> if this is some hw specific bug I dont think we can do much about it 17:56:53 <adamw> tflink: virt-manager is about as stable as a matchstick empire state building right now 17:57:06 <adamw> tflink: so i usually try using spicec to access the vm instead 17:57:07 <tflink> adamw: one of the reasons that I regret moving that machine to F16 17:57:35 <tflink> actually, the main reason. I can't think of others 17:57:44 <jforbes> adamw: virt-manager versions are synched across releases :( 17:58:09 <robatino> i see it on VirtualBox as well 17:58:12 <tflink> jforbes: they are? It seems so much more stable and less broken in F15 than F16 17:58:22 <adamw> hah. speaking of, i just hit https://bugzilla.redhat.com/show_bug.cgi?id=747464 *twice* doing a test install. 17:58:23 <buggbot> Bug 747464: high, unspecified, ---, alevy, NEW, VMs occasionally become unresponsive and it is impossible to type into other applications until virt-manager is killed 17:58:34 <jforbes> tflink: it just got updated across the board I think 17:58:47 <Viking-Ice> robatino, if the virtual solution used is not in fedora we dont care about it 17:58:50 <tflink> adamw: that ... might explain what I'm seeing 17:59:15 <adamw> tflink: if the vm 'hangs' and you find you can't type into any other app, then yeah, it's that bug 17:59:24 <adamw> tflink: switch to a VT, kill virt-manager, switch back and you'll find your desktop works again 17:59:28 <tflink> I'll try it again 17:59:34 <adamw> then you can either re-run virt-manager and reconnect to the VM, or use spicec instead 17:59:37 <robatino> well, it does suggest that it's not hw specific 17:59:56 <Viking-Ice> could also be a different bug 18:00:23 <tflink> either way, methinks we're getting out into the weeds here :) 18:00:31 <adamw> uh. we're talking about the post-install no-booty bug here, right? 18:00:35 <adamw> not the virt-manager hang bug? 18:00:44 <adamw> (in the robatino/viking-ice conversation) 18:01:37 <robatino> i was referring to the no boot bug 18:02:06 <adamw> right. so if you see that in vbox i'd say it's useful info. 18:02:24 * tflink is looking at the bug that satellit_ mentioned and is wondering about blockery-ness 18:02:40 <robatino> i could easily test it in virt-manager too, of course 18:03:15 * satellit_ I am unable to set wep wireless in gnome also....? it sees AP but does not set it 18:03:33 <Viking-Ice> how much do we care about vm's not working enough to block? 18:04:08 <tflink> Viking-Ice: for alpha, probably not much if it's only VMs 18:04:20 <adamw> VMs are specifically beta per the criteria 18:04:29 <adamw> so we should check on bare metal too 18:04:43 <robatino> doesn't hongqing usually test with bare metal? he doesn't say what he used 18:04:58 <adamw> yeah, i wish he'd include more info :/ 18:05:38 <tflink> it's virt 18:05:52 <tflink> at least the syslog he posted came from a VM 18:06:14 <tflink> CPU0: Intel QEMU Virtual CPU version 0.14.0 stepping 03 18:06:34 <Viking-Ice> more info is definitely needed there 18:07:11 <Viking-Ice> and if stuck on boot or shutdown users will need to wait atleast 5 minutes before performing hard poweroff/reboot 18:07:30 <robatino> might be good to look at https://bugzilla.redhat.com/show_bug.cgi?id=787539 as well (mentioned in 787461) - might be related 18:07:33 <buggbot> Bug 787539: unspecified, unspecified, ---, anaconda-maint-list, NEW, text mode traceback from reinstall: KeyError: 'FinishedWindow' 18:08:27 <Viking-Ice> is this happening when users reboot in anaconda or the first reboot after anaconda has installed and user has logged in? 18:08:56 <adamw> yeah, my test minimal install is currently stuck at post-install shutdown 18:09:15 <adamw> Viking-Ice: my reading is that reboot at the end of install 'fails', then when they force power off and boot up again, they can't log in 18:09:36 <Viking-Ice> adamw, that it can well be that anacondas own systemd voodoo is messed up 18:09:47 <satellit_> +1 saw this with RC2 DVD install to HD last nite 18:10:05 <robatino> adamw: usually you can log in after hard powering off - i see the bootloader corruption less than half the time 18:10:59 <tflink> either way, it sounds like this needs more testing and information 18:11:16 <Viking-Ice> agreed 18:11:17 <adamw> yup 18:11:34 <tflink> #info more testing is needed, preferrably a run on bare-metal 18:12:27 <tflink> ok, thoughts on bug 783712? 18:12:29 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=783712 unspecified, unspecified, ---, dcbw, ASSIGNED, No wireless Access points - Fedora-17-Nightly-20120120.10-i686-Live-soas.iso 18:12:56 <tflink> it sounds like wireless is broken in gnome and sugar 18:13:16 <tflink> in the sense that you can't connect to a WPA secured AP, even though you can see it 18:13:18 <Viking-Ice> hum dont we only block if wired does not work 18:13:25 <Viking-Ice> for alpha 18:13:30 * tflink can't remember how we handle wireless, though 18:13:40 <adamw> well, if it's sugar only, it's kind of a moot point. 18:13:44 <adamw> it'd be NTH for any release. 18:13:49 <tflink> adamw: it's not just sugar 18:13:54 <satellit_> gnome also 18:14:27 <Viking-Ice> does the obvious workaround ( plugin in cable ) work ? 18:14:39 <adamw> oh 18:14:46 <satellit_> wired is fine 18:14:50 <Viking-Ice> there is plethora of reasons why wireless might not work 18:14:58 <adamw> i think we'd consider wireless-entirely-broken to be a blocker. but yeah, are we sure it's actually entirely broken? 18:15:14 <adamw> moar testing required 18:15:30 <tflink> wait, there's been no movement on this bug for almost 2 weeks 18:15:32 <Viking-Ice> not a blocker since wired works NTH at best 18:15:39 * tflink wonders if it's still an issue 18:15:52 <tflink> satellit_: have you tested w/ RC2? 18:16:07 <satellit_> I see it in a netinstall RC2 of gnome and sugar 18:16:28 <tflink> satellit_: can you update the bug with that info? 18:16:30 <satellit_> and latest working soas live nightly 18:16:37 <satellit_> ok 18:16:51 <satellit_> try a live desktop 18:17:06 <tflink> any thoughts on NTH? 18:17:14 <adamw> satellit_: can you test with a live, not a net install? 18:17:26 <tflink> for the sake of record ... 18:17:29 <tflink> #topic (783712) No wireless Access points - Fedora-17-Nightly-20120120.10-i686-Live-soas.iso 18:17:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=783712 18:17:33 <satellit_> ok doing todays soas DL now 18:17:34 <buggbot> Bug 783712: unspecified, unspecified, ---, dcbw, ASSIGNED, No wireless Access points - Fedora-17-Nightly-20120120.10-i686-Live-soas.iso 18:17:35 <tflink> #info Proposed NTH, ASSIGNED 18:17:41 <satellit_> will dl desktop 18:18:05 <tflink> it sounds like the conclusion was: wait for more info, possible NTH? 18:18:54 <satellit_> Fedora-17-Nightly-20120217.09-i686-Live-desktop.iso DL for test 18:19:02 <tflink> proposed #agreed - 783712 - It's not 100% clear how many DEs are affected by this - more testing is needed to determine impact and to make a decision on NTH for F17 Alpha 18:19:32 <adamw> ack 18:19:47 <tflink> #agreed - 783712 - It's not 100% clear how many DEs are affected by this - more testing is needed to determine impact and to make a decision on NTH for F17 Alpha 18:19:52 * tflink marks as NTH 18:20:10 <tflink> nvm, getting ahead of myself 18:20:30 <tflink> ok, I think that's really all of them this time :) 18:20:34 <tflink> any others? 18:21:39 <tflink> #topic open floor 18:21:40 * adamw poking at 787461 now, kinda distracted. 18:22:15 <tflink> adamw: not acceptable! We demand your FULL attention :) 18:22:37 * tflink sets the fuse for 5 minutes 18:23:31 <tflink> #info No blocker meeting scheduled for next week unless F17 Alpha slips 18:23:50 <tflink> #info Will announce meeting if we end up having one 18:26:46 <tflink> eh, close enough to 5 minutes 18:27:03 <tflink> Thanks for coming everyone! 18:27:09 * tflink will send out minutes shortly 18:27:12 <tflink> #endmeeting