17:06:47 <adamw> #startmeeting 2011-02-25 Alpha Blocker review meeting #3
17:06:47 <zodbot> Meeting started Fri Feb 25 17:06:47 2011 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:06:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:07:01 <adamw> I guess I'll steer if no-one else is around to do it
17:07:28 <adamw> so, welcome! we're here to review the F15 Alpha blockers again
17:07:43 <adamw> note that in the go/no-go meeting on Wednesday we agreed to a one-week slip, so we're now one week behind the published schedule
17:08:19 <adamw> this should be the final review before the repeated go/no-go next wednesday, if we stay on the new track.
17:08:32 <adamw> any volunteers to act as bugzilla secretary?
17:08:42 <brunowolff> I guess I will.
17:08:45 <adamw> yay
17:08:53 <adamw> we don't need no-one else in our Sekrit Club
17:09:19 <brunowolff> I don't see any open blockers or NTH bugs though.
17:09:32 <adamw> you may not be looking at the right list, because there are a few
17:09:37 <adamw> hold on, let's ping a few people
17:10:00 <brunowolff> That's because I used the wrong query.
17:10:12 <brunowolff> I was looking at closed but not verified.
17:10:12 <adamw> jsmith: ping
17:10:40 <adamw> mcepl: ping
17:10:49 <adamw> rbergeron: ping
17:10:51 <adamw> dlehman: ping
17:10:58 <dlehman> adamw: pong
17:11:00 <adamw> oh, wait, anaconda's good, cancel dlehman page :)
17:11:09 <adamw> dlehman: we're doing blocker review again, but i think anaconda's good
17:11:11 <jsmith> adamw: pong
17:11:12 <dlehman> I have a bunch of stuff on F15Beta
17:11:23 <adamw> dlehman: right, we don't need to worry about beta for now, we're still on alpha
17:11:26 <dlehman> but nothing on the alpha
17:11:31 <Viking-Ice> has anything be added since the go no go meeting
17:11:54 <adamw> Viking-Ice: one or two, plus we need to consider which if any of the bugs previously discussed should be nth for the RC2
17:12:29 <adamw> okay, so we have a few people now, let's go ahead...
17:12:48 <adamw> i'll be working off https://bugzilla.redhat.com/showdependencytree.cgi?id=657616&hide_resolved=1 first
17:12:55 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=676827
17:12:59 <buggbot> Bug 676827: high, unspecified, ---, peter.hutterer, MODIFIED, keyboard with german layout doesn't work in gdm
17:13:04 <adamw> this is the bug we decided to slip for
17:13:17 <adamw> it looks like we have a working fix now, according to initial testing, so that's good
17:13:38 <adamw> fix is in xorg-x11-server. does anyone have anything to add there?
17:13:43 * mcepl follows the meeting, but will be soon drawn away by family duties
17:13:52 <adamw> mcepl: understood, thanks
17:14:09 <jsmith> adamw: I'm glad to see what looks like a proper fix in there :-)
17:14:21 <jsmith> red_alert: So you're happy with the fix?
17:14:53 <red_alert> jsmith: works for me, but I haven't tried French or German layouts
17:15:49 <jsmith> OK, so we should probably ask for a bit more testing, just to be sure?
17:16:00 <adamw> yeah. naturally it'll happen with rc2 when it gets spun, too.
17:16:16 <red_alert> I asked in #fedora-qa this morning but it's been a quiet day there
17:16:26 <red_alert> but rc2 should do the job
17:16:47 <dgilmore> hola amigos
17:16:51 <adamw> hey dgilmore
17:17:08 <dgilmore> adamw: -1 to blocker :)
17:17:28 <adamw> dgilmore: 10 points for persistence :)
17:17:38 <adamw> alright, looks like we're good
17:17:57 <adamw> #agreed 676827 fix is in and looks good, more testing always welcome, rc2 should get the testing job done
17:18:03 <jsmith> w00t!
17:18:05 <jsmith> Next!
17:18:06 <adamw> oh, we do need karma on the fixed package, i guess. and a push from dgilmore.
17:18:28 <red_alert> it needs one +1 more :)
17:18:33 <adamw> red_alert: only for auto-push
17:18:41 <adamw> +2 with a proventester is enough for it to be manually pushed
17:18:47 <brunowolff> Should I change the status to VERIFIED?
17:18:48 <red_alert> right
17:18:54 <adamw> #action 676827 dgilmore push fixed build to stable
17:18:56 <adamw> brunowolff: go for it
17:19:04 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678720
17:19:05 <buggbot> Bug 678720: urgent, unspecified, ---, lpoetter, ASSIGNED, systemd echoes keystrokes to the screen
17:19:37 <adamw> so this is a new one added to the list shortly after the meeting by toshio
17:19:38 <abadger1999> hey
17:19:43 <adamw> i asked him to join us...ah, there he is
17:19:55 <abadger1999> I don't know if this is a blocker or not, but it seemed somewhat serious.
17:19:58 <jsmith> This one looks a bit worrisome to me
17:20:12 <abadger1999> lennart said he'd checked a patch in upstream.
17:20:24 <jsmith> My gut reaction would be to call it a blocker -- but I haven't looked at the criteria to see which criterion it would hit
17:20:25 <brunowolff> Note I filed a seperate bug for the same problem a long time ago.
17:20:27 <abadger1999> But iiuc, there's not a fedora package of that yet.
17:20:38 <Viking-Ice> brunowolff: that was not systemd related was it?
17:20:41 <adamw> brunowolff: i remember that one, but i think this is a separate instance
17:20:49 <Viking-Ice> I recall something similar in previous releases
17:20:55 <adamw> it would probably help to get more testing and see if many people hit this
17:21:01 <abadger1999> <nod>
17:21:08 <adamw> i believe we called a similar bug in f14 a blocker for alpha or beta
17:21:40 <Viking-Ice> does this happen with "normal" usages
17:21:54 <abadger1999> Viking-Ice: yes.  For me it does.
17:21:58 <brunowolff> What I am seeing only happens with systemd. At one point I tested using the other startup in F15 and prompting
17:21:58 <Viking-Ice> hehe
17:21:59 <adamw> abadger1999: so to be clear, what paths have you tested that hit this?
17:22:08 <brunowolff> for encrypted disk passwords worked fine.
17:22:12 <adamw> booting runlevel 5, hitting esc, ctrl-alt-f1 and login?
17:22:20 <abadger1999> Viking-Ice: I installed f14, upgraded to rawhide, changed the systemd symlink to multi-user
17:22:27 <abadger1999> adamw: runlevel 3 equivalent
17:22:47 * Viking-Ice boots into runlevel 3 to confirm
17:22:48 <adamw> it also occurs to me that no-one will have hit this booting live
17:22:53 <abadger1999> when I reboot, (with or without rhgb quiet; with or without hitting esc)
17:22:55 <adamw> as you don't have to type a password to login
17:23:02 <adamw> abadger1999: k, thanks
17:23:14 <abadger1999> I usually (but not 100% of the time) get the problem
17:23:36 <brunowolff> My bug for this is: https://bugzilla.redhat.com/show_bug.cgi?id=655538 and it might have more background
17:23:37 <adamw> so, my proposal here is we call out for testing on -test and possibly -devel
17:23:37 <buggbot> Bug 655538: medium, low, ---, rstrode, NEW, Passwords for non root encrypted devices print during boot.
17:23:41 <abadger1999> username and password echoed at the getty; console not working correctly
17:23:53 <brunowolff> on what is happening, since there are notes about what is happening.
17:24:11 <Viking-Ice> I've not hit this and I frequently switch to different runlevel allthou usually without rhgb quiet
17:24:19 <adamw> Viking-Ice: thanks
17:24:29 <Viking-Ice> no echo here
17:24:33 <adamw> abadger1999: what kinda system are you testing on? something beefy?
17:24:44 <adamw> (just trying to get an idea if this may be a fast or slow system race issue)
17:24:46 <abadger1999> adamw: vm on a laptop.
17:24:51 <adamw> so, not too speedy
17:24:52 * abadger1999 checks spec
17:25:18 <abadger1999> 4GB RAM; Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
17:25:26 <abadger1999> VM has one core and 512MB
17:25:46 <mcepl> BTW, I am not sure whether it somehow doesn't relate to my https://bugzilla.redhat.com/show_bug.cgi?id=678927 (which blocks https://bugzilla.redhat.com/show_bug.cgi?id=679842, which is Alpha blocker).
17:25:49 <buggbot> Bug 678927: unspecified, unspecified, ---, mgrepl, MODIFIED, SELinux denial prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition
17:25:49 <buggbot> Bug 679842: unspecified, unspecified, ---, lpoetter, ASSIGNED, Systemd udev rule prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition
17:26:09 <adamw> mcepl: this is *login* passwords, not encrypted device passwords.
17:26:18 <adamw> mcepl: at least, abadger's issue is.
17:26:21 <mcepl> oh shuut ... sorry
17:26:29 <mcepl> I've misread the bug
17:26:35 <adamw> you may be looking at bruno's bug
17:26:41 <brunowolff> Note that 678720 has been marked as a duplicate of 655538.
17:26:49 <abadger1999> <nod>  brunowolff's issue kinda straddles both mcepl's bug and my bug.
17:26:53 <adamw> ...and then de-duped.
17:26:56 <red_alert> I can't reproduce the issue either
17:27:00 <adamw> anyhoo, i think we need more data
17:27:09 <adamw> can people who can't reproduce please post in the bug, including exact steps they tried?
17:27:15 <adamw> (and people who can reproduce, of course :>)
17:27:37 <abadger1999> <nod>  I can install a new VM if someone wants me to test -- is there a preferred image/method to install at this point?
17:27:38 <mcepl> BTW, I have been able to reproduce Bruno's bug for a long time (since very very early F15)
17:27:54 <adamw> proposal: #action adamw to send out call for testers to try and replicate the issue and post their results in the bug. #action abadger1999 and lennart to try and isolate a cause
17:27:56 <adamw> ack/nack?
17:27:58 <dgilmore> i think abadger1999 issue is pretty serious
17:28:11 <adamw> abadger1999: RC1 at this point
17:28:25 * abadger1999 gets to downloading
17:28:41 <adamw> votes on the proposal?
17:28:42 * jsmith leans toward ACK barring further information
17:28:43 <mcepl> ack
17:28:53 <rbergeron> adamw: i'm at a conference
17:28:56 <adamw> rbergeron: ok
17:29:00 <red_alert> let's wait for abadger1999 to reproduce this with a fresh install and if he can reproduce let's proceed with what you proposed
17:29:21 <adamw> reasonable
17:29:59 <brunowolff> Yeah, this one is more serious than my bug, as I can clear stuff at boot. This one leaves passwords for discovery unless you know about the bug.
17:30:26 <dgilmore> i think that because this will effect a somewhat unknown  but smallish number of people it should be a beta blocker
17:30:30 <adamw> #agreed 678720 is worrying but needs more data: we need to know the root cause and need to test if it affects other installs. blocker status undetermined until more data available
17:30:48 <adamw> #action abadger1999 to try and reproduce with a clean install and investigate possible causes with lennart
17:31:00 <adamw> #action adamw to send out call for wider testing if abadger1999 can reproduce with a clean install
17:31:07 <adamw> that okay with everyone?
17:31:13 <abadger1999> <nod>
17:31:18 <dgilmore> adamw: sure
17:31:20 <red_alert> yes
17:31:23 <Viking-Ice> yup
17:31:28 <adamw> great
17:31:35 <mcepl> +1
17:31:46 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679486
17:31:48 <buggbot> Bug 679486: medium, low, ---, xgl-maint, ASSIGNED, Unable to start graphical installer on RC1 KDE live image
17:32:03 <adamw> this is still on the alpha tracker just because we didn't finish up secretary work from the go/no-go yet
17:32:18 <adamw> at the go/no-go we agreed it was not a blocker due to inability of anyone to reproduce, but we have significantly more data since then
17:32:21 <mcepl> cannot we do other password, cryptsetup stuff first ... it seems related, and I have some comment son it
17:32:32 <Viking-Ice> hehe
17:32:35 <adamw> erf, okay
17:32:39 <adamw> changing track! we'll be back on this one
17:32:55 <adamw> mcepl: 679842?
17:33:06 <adamw> 678927?
17:33:29 <mcepl> both, they are very closely related (if not duplicates) and blocking each other.
17:33:32 <adamw> okay
17:33:38 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679842
17:33:40 <buggbot> Bug 679842: unspecified, unspecified, ---, lpoetter, ASSIGNED, Systemd udev rule prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition
17:33:50 <adamw> this is again one we decided wasn't a blocker at the go/no-go but haven't cleaned up yet
17:34:12 <adamw> thanks to jlaska and dgilmore we determined it did not affect a default+encryption install (the minimal actions necessary to set up encryption)
17:34:14 <mcepl> so I was running around appropriate people around this one and it seems to be an epic struggle between LVM, Lennart and udev people ...
17:34:39 <adamw> it seems there's a fix in for the selinux denial, but it also seems the selinux denial isn't terribly important?
17:34:44 <mcepl> but no one knows for sure what's going on ... there are multiple things wrong (and maybe it is SELinux after all?), but there is nothing certain, and certianly nothing which would fix it for me.
17:35:07 <mcepl> yes, it is probably deeper than just SELinux
17:35:52 <mcepl> one possible candidate are some messed up udev rules, then there is certianly something wrong with udev database (there is different one in initrd image then in kernel), but fixing that (via mkinitrd) didn't help me either.
17:36:08 <mcepl> s/in kernel/in live system/
17:36:14 <adamw> do you have any data which would change our understanding of the *impact* of the bug?
17:37:02 <mcepl> well, the situation is that I have to start in runlevel 1, make cryptsetup runs manually, and then telinit 5 to get gdm, If that's acceptable at the Alpha level, than be it.
17:37:15 <adamw> mcepl: the issue is in what configurations you hit the bug
17:37:18 <mcepl> judge yourself
17:37:32 <mcepl> what do you mean by configurations?
17:37:37 <adamw> at present our understanding is you need to go into partitioning and do a custom setup with encryption before you'd hit this
17:37:41 <Viking-Ice> this does not affect "default install" encrypted or not
17:38:02 <adamw> if you just use the big-picture partitioning options - 'use entire disk', 'use free space' etc - and check the 'encryption' box, you don't hit this
17:38:13 <adamw> based on that we determined it was beta, not alpha
17:38:17 <Viking-Ice> yup
17:38:26 <mcepl> oh well, this isn't a clean install ... I have been running this /home encrypted since at least F10. So although I have fresh installed o ver it, the partitionining was done long long time ago
17:38:48 <adamw> right - for alpha, our requirements in terms of what partition layouts should work are pretty limited
17:38:55 <mcepl> yes, I have /home partition and swap encrypted, which kind of screws up gdm (when it doesn't have /home)
17:39:19 <adamw> although we do call out 'existing linux partitions', which might hit this, i guess?
17:39:36 <adamw> i've never been entirely clear on exactly what that option does.
17:39:57 <dgilmore> mcepl: how did you setup your disks?
17:39:59 <Viking-Ice> it does not reuse you partition layout as one would have wanted
17:40:00 <adamw> criterion is "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption enabled"
17:40:06 <mcepl> I do custom partitioning always (and leaving partitioning as it is with formatting just root, swap and similar)
17:40:07 <brunowolff> I have /home, / and swap encrypted and don't see this.
17:40:33 <mcepl> OK, then I am out of this criterion
17:40:33 <brunowolff> No LVM though.
17:40:45 <Viking-Ice> same as I would do it
17:40:46 <adamw> okay
17:40:54 <adamw> i think we haven't changed our understanding of the impact
17:40:59 <adamw> so this remains non-blocker...
17:41:11 <dgilmore> adamw: agreed
17:41:18 <adamw> given the apparent complexity here (thanks for the investigation mcepl), it doesn't seem a good candidate for nth either
17:41:18 <brunowolff> Should I move it to beta blocker?
17:41:27 <adamw> let's consider nth first
17:41:39 <adamw> anyone think this is a good nth candidate?
17:41:53 <adamw> for any who aren't clear - nth means we'd take a fix into the alpha respin if it was available
17:42:17 <adamw> the likelihood of the fix breaking something else is a clear factor when considering nth status, which is why i feel icky about this one.
17:42:29 <Viking-Ice> I say it's an blocker
17:42:33 <Viking-Ice> beta
17:42:44 <adamw> right, i think beta blocker is agreed
17:42:44 <Viking-Ice> as in beta blocker
17:42:47 <adamw> but the question is, alpha nth or no
17:42:55 * jsmith is on the fence
17:42:59 <Viking-Ice> let's not risk another delay
17:43:03 <jsmith> I guess if I had to vote, I'd say NTH
17:43:04 <adamw> a bug can be both
17:43:09 <mcepl> well, I would for nth, because while uncovering this, there were numerous things really broken dug out.
17:43:28 <mcepl> which would be nice to have in respin, if it happens.
17:43:29 <Viking-Ice> I'm - on nth
17:43:36 <red_alert> -1 nth
17:43:40 <Viking-Ice> -1 nth
17:43:42 <mcepl> + hard beta blocker
17:43:55 <brunowolff> -1 nth
17:44:07 <adamw> mcepl: see, fixing 'numerous things' in core components like udev and lvm strikes me as scary at this point =)
17:44:29 <adamw> so we have...me, viking, bruno -1 nth
17:44:34 <adamw> mcepl and jsmith +1 nth
17:44:36 <adamw> any other votes?
17:44:39 <mcepl> well, letting them broken just because of bureaucracy sounds scary to me as well, but taken being overvoted
17:44:53 <mcepl> *taking
17:45:14 <adamw> mcepl: the existing testing gives us reasonable confidence they're not 'broken' in terms of the alpha criteria - i.e. they haven't caused any other alpha blocker bugs in all the tc+rc testing
17:45:40 <Viking-Ice> adamw: seem to have forgotten red_alert's vote
17:45:46 <adamw> whoops! sorry
17:45:47 <dgilmore> adamw: -1 nth
17:45:55 <adamw> okay, so that's 5 to 2, i'm calling it =)
17:45:59 <mcepl> as I said, go ahead with lifting it, but please put it on beta blocker list.
17:46:25 <adamw> #agreed no data changes the impact of 679842, it remains not an alpha blocker. agreed by all that it is a beta blocker. voted not alpha NTH by 5 to 2.
17:46:34 <adamw> brunowolff: go ahead and secretaryize :)
17:46:46 <brunowolff> Doing...
17:46:55 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679486
17:46:57 <buggbot> Bug 679486: medium, low, ---, xgl-maint, ASSIGNED, Unable to start graphical installer on RC1 KDE live image
17:46:58 <adamw> back to this one
17:47:26 <adamw> so, as I said, at the go/no-go we agreed this was not a blocker on the basis of non-reproducibility
17:47:28 <adamw> (is that a word?)
17:47:49 <Viking-Ice> we know what's the cause is now
17:47:50 <adamw> thanks to viking and red_alert, we have a much better understanding of the issue now, which is summarized in comment #38 (I hope without errors)
17:48:12 <red_alert> actually it was called non-blocker and even closed notabug before go/nogo :/
17:48:31 <adamw> red_alert: sure, but we discussed it at go/no-go to be 'safe'
17:48:34 <adamw> anyhoo
17:48:54 <adamw> so, this is really a kind of race between desktop login and networkmanager, if dhcp is setting the system hostname
17:48:58 * red_alert reopened and reblocked the next time after reproducing ;)
17:49:14 <red_alert> s/time/morning/
17:49:15 <adamw> it's not limited to kde, but showed up more there because it uses auto-login and gnome doesn't
17:49:29 <adamw> you could probably hit it on gnome with a fast system, slightly slow network, and a quick trigger finger
17:49:37 <Viking-Ice> does this affect complete installs btw ?
17:49:42 <Viking-Ice> as in non livecd's
17:50:01 <adamw> Viking-Ice: traditional install? i don't see any reason it would
17:50:23 <Viking-Ice> It should
17:50:26 <red_alert> it's only because livecd has no fixed hostname in /etc/sysconfig/network which installed systems normally do have
17:50:36 <Viking-Ice> okay
17:50:52 <Viking-Ice> I c
17:50:55 <red_alert> (i.e. the hostname you configure in anaconda)
17:51:22 <adamw> so the key question here, i guess, becomes how many systems use DHCP hostname assignment, and how likely are you to hit the bug exactly
17:51:26 <adamw> both of which are a bit tricky to answer
17:51:48 * dgilmore thinks this is probably a beta blocker
17:51:51 <adamw> anyone have a clear feeling either way on the blockeriness of this? my gut instinct is -1 blocker, +1 nth
17:51:58 * jsmith is just the opposite
17:51:59 <adamw> given there's a reasonably easy workaround
17:52:13 <Viking-Ice> -1 -1 nth +1 betablocker
17:52:19 <jsmith> It's easy to work around, if you control your DHCP environment
17:52:24 <red_alert> I figure we don't need to block alpha with this, if we document 'xhost +' as a workaround - but it should be fixed sometime
17:52:32 <adamw> jsmith: no, the 'easy workaround' is to run 'xhost +'
17:52:37 <adamw> then re-run the installer, and it works
17:52:38 <dgilmore> jsmith: i think most people do
17:52:40 <jsmith> adamw: Ah, that workaround...
17:52:50 <dgilmore> since most people will plug into a router type device
17:52:53 <adamw> sorry, should have mentioned that :)
17:52:56 <jsmith> "xhost +" is a bit of a security issue though, right?
17:53:06 <adamw> in a live environment? meh.
17:53:06 * jsmith always learned that "xhost +" is a command of last resort
17:53:29 <red_alert> +1 alpha nth, +1 beta blocker :)
17:53:29 <adamw> we should note the cases we've identified for dhcp host assignment too
17:53:44 <jsmith> Alright, looks like I'm in the minority here
17:53:54 <jsmith> Let's go ahead and mark it as alpha NTH, and beta blocker
17:53:59 <adamw> so far we've come up with 'some corporate networks' (red_alert's case), and 'system connected directly to consumer ISP' (rather than via a router)
17:54:05 <red_alert> I figure instead of 'xhost +' there's also something that only allows the new hostname
17:54:27 <adamw> red_alert: yeah, we can probably come up with something finer-grained.
17:55:32 <brunowolff> This seems like an odd way to do things. Why not use the loopback interface for local X connections?
17:55:39 <adamw> okay, so, proposed #agreed 679486 agreed not an alpha blocker due to ease of workaround and quite limited impact, agreed beta blocker and alpha NTH
17:56:00 <adamw> brunowolff: if it's not related to the blockeriness can you comment in the bug or on a mailing list for more general stuff? thanks
17:56:09 <adamw> ack/nack/modify?
17:56:18 <jsmith> ACK
17:56:57 <adamw> brunowolff: oh, please also add the CommonBugs keywords to any bugs where we talk about documenting a workaround, like this one - thanks!
17:57:40 <red_alert> ack
17:57:41 <brunowolff> I'll add the key word for this one while updating it, but did any of the ones we already did need this?
17:57:55 <brunowolff> Iack
17:57:58 <brunowolff> ack
17:58:15 <adamw> brunowolff: possibly the encryption issue i guess
17:58:51 <adamw> okay
17:58:52 <brunowolff> OK, I'll go back to that one and look at it.
17:58:57 <adamw> #agreed 679486 agreed not an alpha blocker due to ease of workaround and quite limited impact, agreed beta blocker and alpha NTH
17:59:16 <adamw> okay, we're onto the NTH list now
17:59:40 <dgilmore> ack
17:59:50 <adamw> #topic https://bugzilla.redhat.com/showdependencytree.cgi?id=657617&hide_resolved=1
18:00:53 <adamw> just a couple here that haven't been discussed
18:00:55 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=677842
18:00:56 <buggbot> Bug 677842: unspecified, unspecified, ---, jglisse, NEW, [abrt] mutter-2.91.6-4.fc15: ureg_src: Process /usr/bin/mutter was killed by signal 11 (SIGSEGV)
18:01:06 <adamw> so, back to the ol' mutter issue
18:01:30 <adamw> i think we now have a reasonably good understanding of this: it's an issue with gcc in generating 32-bit code, and it actually does affect multiple types of card
18:01:40 <adamw> so basically if you run the 32-bit image you've got a decent chance of hitting this
18:02:01 <jsmith> +1 NTH
18:02:02 <adamw> we rejected this as a blocker at the go/no-go, but i wanted to consider it as NTH
18:02:22 <jsmith> I think this is pretty obvious as a NTH
18:02:25 <adamw> i'm definitely +1 nth, i'd really like this to get fixed
18:02:28 <Viking-Ice> +1 nth
18:02:49 <red_alert> I propose a workaround of removing 32bit from the list of primary architectures ;)
18:02:52 <adamw> red_alert: hehe
18:03:05 <Viking-Ice> agreed days of 32 are over
18:03:08 <dgilmore> adamw: i wont object to having this nth
18:03:17 <adamw> i think we need to actively get the tools folks involved too, since it's pretty clearly a compiler issue but they don't seem to be active in the bug
18:03:20 <red_alert> +1 nth
18:03:27 <jsmith> adamw: I agree
18:03:55 <adamw> does anyone want to reconsider blocker status for this, given that it apparently has impact beyond just r600+ radeons?
18:04:08 <dgilmore> nope
18:04:12 <Viking-Ice> nope
18:04:37 <jsmith> adamw: Tempting... but I'm gonna say no... NTH is probably enough
18:04:52 <red_alert> not all r600+ are affected, though
18:05:07 <adamw> red_alert: i think actually they are, but only 32-bit is affected
18:05:14 <red_alert> ah, possible
18:05:22 <red_alert> already forgot about that again :/
18:05:24 <adamw> successes with r600+ are all x86-64 afaict
18:05:50 <adamw> i think all r600+ radeons and an undetermined range of nvidia hardware is affected, that's my best read atm
18:05:54 <adamw> not sure about intel yet
18:06:24 <adamw> so if you look at the big picture, the 32-bit alpha is going to be pretty broken if we don't fix this.
18:06:38 <adamw> which makes red_alert's proposed workaround look marginally more sensible ;)
18:06:58 <adamw> still, we voted. i'll try and get X and tools folks to get together and fix this quick
18:07:12 <adamw> dgilmore: what's the current plan for spinning rc2, are we looking at monday?
18:07:47 <dgilmore> adamw: today
18:07:56 <dgilmore> assuming all blockers are fixed
18:07:59 <brunowolff> Aren't people still running i686 likely not to have r600 based video cards?
18:07:59 <adamw> ah, see, that's the thing - the ones we're marking NTH aren't going to get into rc2 unless we fix 'em fast
18:08:01 <red_alert> yey, that saves my weekend! rain AND rc3 <3
18:08:11 <adamw> brunowolff: sure - but it seems other cards are affected...
18:08:58 <adamw> brunowolff: when secretaryizing, remember to add 'AcceptedBlocker' whiteboard field to agreed blockers, 'RejectedBlocker' to rejected ones; same for NTH ('AcceptedNTH' and 'RejectedNTH')
18:09:14 <adamw> helps us keep track of what we've already made a determination on
18:09:28 <brunowolff> Thanks. I haven't had practice at this yet.
18:09:31 <adamw> npnp :)
18:09:57 <adamw> #agreed 677842 remains non-blocker, is accepted as NTH for Alpha
18:11:23 <brunowolff> adamw: For cases where waiting for more information, I shouldn't put anything in whiteboard?
18:11:30 <adamw> brunowolff: right
18:11:36 <adamw> brunowolff: that indicates status is still undetermined
18:11:38 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679171
18:11:40 <buggbot> Bug 679171: high, unspecified, ---, mgracik, POST, Hitting enter to move to Next screen crashes firstboot
18:11:42 <adamw> okay, this is the last one on the list for now
18:11:51 <adamw> this is the 'firstboot crashes if you hit enter' bug
18:12:00 <adamw> we determined it wasn't a blocker on wednesday, but i'm proposing it as NTH
18:12:02 <Viking-Ice> hum I did not notice this
18:12:06 <adamw> especially since we have a fix, i'd like to pull it in
18:12:14 <Viking-Ice> ok +1 nth
18:12:21 <jsmith> adamw: Do we yet know where the problem lies?
18:12:23 <red_alert> +1 nth
18:12:28 <jsmith> adamw: In other words, is it in firstboot itself?
18:12:33 <jsmith> adamw: Or in some other component?
18:12:44 <adamw> jsmith: the fix is in firstboot.
18:12:51 <dgilmore> adamw: +1 for nth
18:12:52 <jsmith> adamw: Then I'm definitely for NTH
18:12:57 <adamw> in its initscripts, it fact. see https://www.redhat.com/archives/anaconda-devel-list/2011-February/msg00235.html
18:13:23 <jsmith> +1 for NTH
18:14:59 <adamw> okay
18:15:07 <adamw> #agreed 679171 accepted as NTH
18:15:15 * jsmith has to run.... Sorry folks!
18:15:20 <adamw> #action adamw to try and get the fix pushed into firstboot in time for rc2
18:15:26 <adamw> thanks jsmith! we're all done now i think
18:15:30 <adamw> #topic open floor
18:15:49 <adamw> anyone have any bugs to bring forward for consideration as blocker or nth? any we dropped as blockers but missed considering as nth? I tried to catch them all, but may have missed some
18:15:51 <red_alert> I'd like to propose 673824 and 680410 as NTH
18:15:55 <adamw> cool, thanks
18:16:01 <Viking-Ice> so when are we going to stop adding bugs the list
18:16:07 <red_alert> they're probably the same issue but two bugs for tracking reasons
18:16:09 <Viking-Ice> since if we continue to do we never get alpha out
18:16:28 <adamw> Viking-Ice: nth bugs don't block alpha.
18:16:35 <adamw> Viking-Ice: they just go into the spin if a fix is available.
18:16:42 <adamw> Viking-Ice: the rc2 train leaves the station tonight regardlesss
18:16:46 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=673824
18:16:46 <Viking-Ice> I'm also talking about alpha
18:16:47 <buggbot> Bug 673824: unspecified, unspecified, ---, rvykydal, ASSIGNED, [anaconda] prompts user for network device prematurely in netinst
18:16:55 <Viking-Ice> blockers
18:16:57 <dgilmore> adamw: and if i remeber to pull the fix in
18:17:00 <adamw> Viking-Ice: we have exactly one blocker
18:17:08 <adamw> dgilmore: that's what i put the list in the trac ticket for :)
18:17:34 <dgilmore> adamw: i still forget sometimes
18:17:36 <adamw> red_alert: so, what's the impact of this?
18:17:40 <adamw> dgilmore: heh
18:18:01 <red_alert> basically it's just a premature dialog asking for network
18:18:16 <Viking-Ice> *cosmetic* bug?
18:18:25 <adamw> right
18:18:28 <red_alert> that's not a big issue on the netinst media...but can be sort of annoying on the dvd if you plan not to use network
18:18:41 <adamw> can you not configure a network connection and install will continue?
18:18:42 <Viking-Ice> just a general bug
18:18:44 * dgilmore says no
18:18:44 <red_alert> it's caused by no longer having stage 1 and 2
18:18:55 * dgilmore doesnt want any anaconda changes now
18:19:03 <Viking-Ice> agreed
18:19:10 <adamw> yeah, the fact that this is in anaconda makes me very hard to convince for a +1
18:19:53 <red_alert> okay, we'll go beta then :)
18:20:05 <Viking-Ice> I just say it's an general bug
18:20:24 <adamw> okay, i'm -1...looks like a consensus :)
18:20:30 <adamw> #agreed 673824 rejected nth
18:20:39 <Viking-Ice> could be UI design if they are using the same designers as the Gnome  hehe
18:20:43 <red_alert> no need to bring up the other one I said then
18:20:53 <adamw> 680410 looks like a dupe, so no need to discuss it...right
18:21:06 <adamw> #topic open floor
18:21:09 <adamw> any other proposals?
18:21:24 <Viking-Ice> nothing from me
18:21:59 * dgilmore has nothing
18:22:34 <adamw> okay
18:22:53 <adamw> so, for anyone trying to get an nth fix in, the rc2 train leaves the station 'tonight' - around 6-7 hours from now
18:23:08 <adamw> you need to have a package built and karma'd by then to get it in
18:23:46 <adamw> it would also be a good idea to link to the build from the trac ticket for the RCs - https://fedorahosted.org/rel-eng/ticket/4403
18:24:08 <adamw> thanks everyone for coming out
18:24:14 <dgilmore> thansk adamw
18:24:20 <dgilmore> thanks even
18:24:23 <adamw> :)
18:24:26 <adamw> #endmeeting