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