15:00:52 <jlaska> #startmeeting Fedora Release Blocker Bug Review - http://tinyurl.com/ygmge7c
15:00:52 <zodbot> Meeting started Fri Oct 23 15:00:52 2009 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:11 <jlaska> #topic gathering participants
15:01:22 <jlaska> #chair adamw
15:01:22 <zodbot> Current chairs: adamw jlaska
15:02:11 <jlaska> #link http://tinyurl.com/ygmge7c
15:02:29 <jlaska> #info 56 bugs on the F12Blocker list for review today
15:04:01 <jlaska> this might be a quick meeting :)
15:04:14 <jlaska> I think notting and denise are lurking
15:04:22 <jlaska> adamw and Oxf13 around?
15:04:35 <jlaska> anyone else interested in helping review the F12Blockers?
15:04:37 <denise> yes, lurking - in another mtg
15:04:42 <Bouska> yeah, a meeting with no participants
15:04:49 <jlaska> Bouska: love those!
15:06:32 <adamw> here here
15:06:50 <jlaska> howdy
15:07:06 <jlaska> so ... any changes in how we run this today?
15:07:19 <jlaska> who will update the bz's ... or should we use # action for that
15:07:35 <jlaska> anyone interested in leading us through the list of bugs?
15:07:55 <adamw> jlaska: was just going to give oxf13 a minute to show
15:08:02 <adamw> i can run things if you like
15:08:06 <Bouska> I'm new to bugzapping, so you know :-)
15:08:12 <jlaska> adamw: definitely
15:08:14 <adamw> that's alright, the more heads the merrier :)
15:08:42 <jlaska> Bouska: this follows the principle ... 'with more eyes, every bug is shallow'
15:08:52 <jlaska> adamw: no objections here, didn't know if you wanted a break :)
15:09:32 <adamw> or my favourite, 'with more eyes, every bug report is a freaking mess'
15:10:30 <adamw> alright, i guess we're short one jesse
15:10:58 <adamw> on that note, just want to say big thanks to him for going through the rest of the list after wednesday's pre-meeting
15:11:50 <jlaska> the list is smaller today ... so that extra meeting (and post-meeting walk through) seems to have helped
15:11:53 <adamw> also thanks to mcepl for re-arranging X blockers with their own blocker bug
15:12:05 <adamw> yeah, we cut it down by ~25 i think
15:12:09 <adamw> alright, let's go
15:12:10 <jlaska> #info thanks to mcepl for re-arranging X blockers with their own blocker bug
15:12:17 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=493058
15:12:18 <buggbot> Bug 493058: high, low, ---, dlehman, ASSIGNED, Custom partitioning creation/edit causes traceback
15:12:19 <jlaska> #info thanks to [jkeating] for going through the rest of the list after wednesday's pre-meeting
15:12:30 <adamw> oh, jlaska: i'll make bug changes unless otherwise decided/noted
15:12:41 <jlaska> adamw: what order are you using?
15:12:46 <jlaska> the link posted above ... or another link?
15:12:59 <adamw> oh, i'm just on the tree view
15:13:05 <adamw> https://bugzilla.redhat.com/showdependencytree.cgi?id=473303&hide_resolved=1
15:13:35 <adamw> alright, 493058, we're actually fairly sure this particular bug is closable, dave thinks zootboy's bug is different
15:13:51 <adamw> going to give zootboy a bit of time to post updated logs just in case, but if he hasn't by, say, next meeting we can probably close this
15:14:20 <adamw> anyone have anything else on it?
15:14:37 <jlaska> nope, I'm already leaning on closing it and we can file something new when response comes back
15:14:55 <jlaska> but either way works fine
15:14:55 <jlaska> we have time to wait
15:15:06 <adamw> ok
15:15:09 <adamw> now we have a block of four virtualization bugs
15:15:27 * jlaska wonders why that bz didn't show up in my needinfo? query
15:15:37 <jlaska> #info waiting on retest
15:15:54 <adamw> #agreed 493058 waiting on further info from zootboy, likely will be closed
15:16:01 <adamw> jforbes: around to comment on virt bugs?
15:16:20 <jforbes> adamw: I am
15:16:24 <adamw> excellent
15:16:29 <adamw> four of 'em upcoming
15:16:34 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523941
15:16:36 <buggbot> Bug 523941: medium, high, ---, drjones, ASSIGNED, kernel 2.6.31-1[24].fc12 doesn't boot in xen PV guest on 64b host
15:17:11 <adamw> looks like discussion on this is pretty active but it hasn't been pinned down yet
15:17:40 <adamw> is there anything anyone can do here, or just a case of us hoping you guys figure out a fix? :)
15:17:42 <jforbes> adamw: Right, we should have an answer today...
15:18:37 <jforbes> adamw: As markmc said, it should remain on the blocker list, being a boot issue, but if push comes to shove it might be removed
15:18:44 <adamw> OK
15:19:02 <adamw> think we'll just monitor this one for now...anything from anyone else on this bug?
15:19:02 <jforbes> adamw: honestly we have a workaround which is suboptimal, but can be applied at the last minute
15:19:09 <adamw> ah, an ace in the hole :)
15:20:14 <adamw> #agreed no action possible on 523941, waiting for virt team to pin down the problem
15:20:48 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=524229
15:20:49 <buggbot> Bug 524229: high, high, ---, gcosta, ASSIGNED, Local migration of kvm guest fails in Fedora12 Alpha
15:21:27 * jlaska puts his hands in the air for markmc updating each of these bugs with a note about 2 weeks until GA
15:21:53 <adamw> yay markmc
15:22:03 <adamw> looks like glauber has this one under control, the issue seems identified and understood
15:22:15 * jlaska nods
15:22:17 <jforbes> Yeah, I expect this will have a fix soon.
15:23:02 <adamw> excellent
15:23:19 <adamw> #agreed 524229 is under control, fix expected soon
15:23:30 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528754
15:23:32 <buggbot> Bug 528754: high, high, ---, jforbes, ASSIGNED, qemu-kvm segfault caused by -soundhw es1370
15:24:23 <jforbes> adamw: I am working this one now. Not sure on root cause yet, but also not sure it would really be holding up the release for.
15:25:13 <jforbes> It is certainly a high priority to fix, nothing here is related to critical path, it isn't really an install bug.
15:25:57 <adamw> well, what would worry me is the impact of the bug and the default configuration
15:26:14 <adamw> is it the case that _any_ guest with sound enabled could plausibly suffer from this? i.e. crash unexpectedly?
15:26:20 <adamw> and is sound enabled the default configuration?
15:26:58 <adamw> even if sound isn't that important a feature, if it's in the default configuration, the idea of people's virtual guests crashing randomly does not fill me with joy =)
15:27:07 <jforbes> adamw: it is for local, and it could be any guest, but not every guest, it was not easy for me to reproduce
15:28:07 <adamw> still feels to me like something we should definitely address one way or the other before release
15:28:09 <jforbes> adamw: though with this bug, it is qemu-kvm crashing, so all running guests crash.  Like I said, it is a high priority bug, but could just as easily be fixed with a zero day since it is the host that needs the fix
15:28:25 <jlaska> adamw: where address means code, workaround or documentation?
15:28:41 <adamw> if sound in guests isn't really working anyway, if we can't fix it before release, why not just disable the sound device in guests by default?
15:28:55 <adamw> jlaska: yeah
15:28:59 <jforbes> adamw: that is certainly possible as a last resort
15:29:17 <adamw> ideal: fix the bug, second best: disable sound by default, third best: document and tell people to disable sound manually
15:30:11 <jforbes> adamw: I can agree to that
15:30:17 <adamw> ok, i'll comment on the bug to that effect
15:30:51 <adamw> #action adamw to update 528754 with agreed recommended approach
15:32:22 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=529363
15:32:24 <buggbot> Bug 529363: high, high, ---, berrange, ASSIGNED, virsh restore fails - failing to re-label the save file ?
15:32:25 <adamw> last virt bug
15:32:48 <jforbes> adamw: I haven't followed up on this, but the issue looks simple enough
15:33:02 <jforbes> adamw: meaning we know what the issue is, and the fix would not be difficult.
15:33:06 <adamw> right, i'd be slightly worried mark hasn't touched it in a week but he obviously knows ga is coming
15:34:05 <adamw> so i think we can just monitor this one and get worried if it's not fixed in a week's time :)
15:34:41 <adamw> alright, i think that covers virt bugs
15:34:46 <adamw> thanks a lot for your help jforbes
15:34:55 <adamw> #info thanks to jforbes for helping review virtualization issues
15:35:05 <jforbes> adamw: np
15:35:17 <adamw> #agreed 529363 no action needed, issue appears to be quite simple and clear
15:35:37 <Oxf13> sorry, I'm on kid patrol today so I'm going to be in/out
15:35:51 <adamw> Oxf13: hiya...what, you let them out of their cages? :)
15:36:04 <Oxf13> only one, but wife has class today
15:36:23 <adamw> ah
15:36:32 <adamw> ok, onwards ever onwards!
15:36:34 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=501769
15:36:35 <buggbot> Bug 501769: medium, low, ---, jkysela, NEW, intel hda: snd_pcm_avail/snd_pcm_delay overflows
15:37:25 <adamw> this is a lovely icky kernel sound bug
15:38:55 <adamw> unfortunately it can be somewhat hardware-dependent so it's a bit hard to know when to stick a CLOSED fork in it
15:39:04 <adamw> i'd have wanted more separate reports here but jaroslav likes to bundle them up
15:39:44 <adamw> also, the report is mixing up f11 and f12, which makes for super happy fun times
15:40:36 <adamw> i will take an action item to try and draw some sense from the chaos
15:41:07 <adamw> i.e. since lennart added it to the blocker list after experiencing it on rawhide i'll ask him to file a separate report if he's still hitting it, and ask anyone else having trouble on f12 to comment there
15:42:32 <adamw> any other comments?
15:42:51 <jlaska> I've got nothing to add for that bug
15:43:11 <adamw> ok
15:43:24 <adamw> #action adamw to try to produce clean information on actual f12-blocking issues from messy 501769
15:43:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=506013
15:43:49 <buggbot> Bug 506013: medium, low, ---, rvykydal, ASSIGNED, liveinst crash - DBusException ... No such property HwAddress
15:43:50 <jlaska> some good updates on this one
15:44:07 <jlaska> looks like waiting on a new anaconda build, but testing against a new NM and the updates.img is positive
15:44:19 <adamw> yeah
15:44:37 <Oxf13> yeah, can moved to MODIFIED I guess
15:44:37 <adamw> i'd like to confirm with a 'real' image before closing, better safe than sorry
15:44:39 <adamw> but looks good
15:44:43 <jlaska> I think waiting for feedback against anaconda-12.39
15:44:44 <adamw> yeah MODIFIED seems reasonable
15:44:54 <jlaska> so ... yeah, agree with adamw :)
15:45:09 <adamw> yeah basically it's waiting on a build with anaconda-12.39 and NetworkManager-0.7.996-5.git20091021.fc12
15:45:16 <adamw> Oxf13: such a build should show up soon?
15:45:22 <jlaska> I do'nt see it yet
15:45:24 <adamw> NM is already tagged in, I know that, dunno about anaconda
15:45:28 <jlaska> http://koji.fedoraproject.org/koji/packageinfo?packageID=2
15:46:16 <Oxf13> adamw: if they ask for a tag it'll show up
15:46:23 <adamw> ok
15:46:42 <adamw> denise: are you planning to request a tag for 12.38 soon?
15:47:09 <jlaska> we need anaconda-12.39 built and tagged iirc
15:47:17 <adamw> er sorry yes, 12.39 :)
15:47:19 <denise> yes, we shoul dbe up to 39 now
15:48:05 <denise> will ask pjones (only victim around today) to request tag
15:48:08 <adamw> excellent
15:48:17 <denise> because I dont know how
15:48:25 <denise> unless I can just ask Jesse here ;-)
15:48:44 <adamw> #agreed 506013 looks fixed, needs anaconda team to request a tag for anaconda 12.39 then confirmation from reporter
15:48:49 <Oxf13> 'make tag-request'
15:48:53 <adamw> denise: 'make tag-request' will do it, AIUI
15:48:57 <Oxf13> from the CVS dir
15:49:03 <adamw> or you can do it 'manually' by filing a ticket of the correct form in releng trac
15:49:26 <Oxf13> testing anaconda since it's critpath is... fun
15:49:47 <jlaska> we've got a date for that coming on the qa schedule
15:50:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=506075
15:50:12 <buggbot> Bug 506075: medium, low, ---, jkysela, ASSIGNED, snd_intel8x0: snd_pcm_avail()/ snd_pcm_delay() overflow
15:51:09 <Oxf13> jlaska: we have to test anaconda before tagging it.
15:51:11 <Oxf13> it's crit path
15:51:38 <jlaska> are you planning a private compose?
15:51:44 <Oxf13> not sure
15:51:51 <adamw> 506075 is the other general-purpose alsa overflow bug (this one for intel8x0), again it's actually an f11 bug that lennart's added to f12blocker
15:52:03 <Oxf13> that's probably the most through, but could just update anaconda on a live CD and do a live install
15:52:24 <adamw> can we discuss that outside the meeting? we're already gonna be going all day just reviewing bugs...
15:52:40 <jlaska> yup
15:53:50 <adamw> i'd say we should drop 506075 from the list actually
15:54:01 <adamw> as no tester actually seems to be testing with f12, and none of the dupes are f12 reports
15:54:09 <Oxf13> worksforme
15:54:13 <notting> put on target?
15:54:18 <adamw> it doesn't mean no-one's hit this problem in f12, but it does mean we can't usefully track the bug for f12 using this report
15:54:43 <adamw> notting: that doesn't make much sense - the problem _would_ be an f12 blocker (not target) if many f12 testers hit it, the thing is this bug isn't the right place to track that
15:54:54 <notting> ok
15:54:56 <adamw> i plan to request anyone hitting the bug in f12 to file a separate bug for f12
15:55:16 <adamw> since f11 and f12 are on separate kernel tracks, trying to track the issue in both releases on one bug is just painful.
15:55:39 <adamw> if anyone is hitting it in f12, we can definitely consider the f12 bug for blocker.
15:56:06 <adamw> jlaska: ok for you?
15:56:38 <jlaska> no objections ... I'd like to see more F12 reports to move fwd on that one
15:56:48 <adamw> #agreed drop 506075 from the list due to lack of any f12 reporters, ask for new bug report from anyone suffering in f12
15:57:07 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=512944
15:57:08 <buggbot> Bug 512944: high, low, ---, jmccann, ASSIGNED, fast-user-switching locks up login screen
15:57:42 <adamw> this is the icky fast-user-switch bug oxf13 and I caught up with on wednesday
15:57:59 <adamw> it rang a bell with me when i saw the report and i realized what's probably the same bug had been reported multiple times on all three X test days
15:58:06 <adamw> as you can see I went through those reports and pulled in all the dupes
15:58:39 <adamw> this _could_ be considered a non-blocker as it's not really critical functionality and could be fixed with an update, but it's a pretty icky bug
15:58:52 <jlaska> cute, nice job adding the DUPS
15:58:53 <adamw> and not hardware-dependent, it seems to affect just about any system if you use the function
15:59:40 <Oxf13> Would be nice to get the maintainer to look/comment on it
15:59:41 <jlaska> we'd need mclasen probably to assess the liklihood of a fix for this issue in the next 2 weeks?
15:59:58 * mclasen perks up
16:00:01 <adamw> what does everyone think about blocker status? the impact is basically 'if you switch users a few times, one of the X servers will essentially lock up and become useless'
16:00:24 <jlaska> can you get back to the original?
16:00:58 <jlaska> I'd vote for fixing, or disabling this functionality
16:01:01 <mclasen> jlaska: I would be lying if I said that anybody has looked into issues with repeated user switching yet
16:01:01 <adamw> yeah, the exact resulting situation seems to vary slightly between reporters but i've never seen a case where the entire system becomes useless, just one X server and the console it's running on become useless
16:01:29 <jlaska> okay, that's less painful
16:01:34 <adamw> mclasen: to be fair the amount of dupes that showed up only showed up because i have this as a test case for the X test days; it's likely not a reflection of the level of real-world use of the feature
16:02:02 <adamw> but given the reports i'm pretty sure it happens to either all or a large majority of people who do actually try to use the feature
16:02:43 <adamw> if you look down the user switch test columns on the test days, half or more of the reports are failures, and the passes may be people who just didn't switch enough times to trigger the bug.
16:02:45 <mclasen> I vote for keeping it on the blocker list for now; I'll ask halfline to look into it
16:03:04 <mclasen> is the test about 'switch until it fails' ?
16:03:08 * adamw KNEW the ability to quickly assess how many reporters failed a given test would be useful sometime =)
16:03:11 <adamw> yup, that seems to be the case
16:03:56 <adamw> anyone disagree with mclasen? i'd agree...i think if push comes to shove we may drop this frm the list, but it'd be good to keep it around for now
16:05:05 <jlaska> I agree with that stmt
16:05:14 <adamw> worth noting that the keyboard layout bug (which we'll come to later) is probably more important, so mclasen, if you can't fix both in time i'd say the keyboard layout bug gets priority and this one gets punted
16:05:26 <jlaska> plus, it's very documentable
16:05:56 <adamw> #agreed 512944 is borderline but stays on the list for now, mclasen will have halfline look into the bug
16:06:17 <adamw> we've been going an hour, anyone mind if we take a short break for refreshments etc? :)
16:06:23 <adamw> since this one's going to be a long haul
16:06:30 <jlaska> go for it
16:06:38 <Oxf13> biobrak
16:06:41 <Oxf13> biobreak
16:06:43 <adamw> #topic BREAK FOR DELECTATIONS
16:07:07 <adamw> everyone take 5 or so
16:14:54 <adamw> everyone back?
16:16:08 <Oxf13> yeah.
16:16:18 <Oxf13> although I think my kid just coredumped so I may have to go clean that up
16:16:31 <notting> t.m.i.!
16:16:49 * jlaska 
16:18:59 <adamw> #action oxf13 receives a TMI yellow card
16:19:12 <adamw> i'm sorry, where's my canuckiness
16:19:19 <adamw> #action oxf13 receives a TMI bench minor
16:19:29 <jlaska> :)
16:19:37 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=513864
16:19:38 <buggbot> Bug 513864: medium, low, ---, gecko-bugs-nobody, NEW, Firefox crashes
16:19:55 <Oxf13> adamw: hah.  I grok yellow card, not bench minor
16:20:10 <adamw> actually it wouldn't be a bench minor. just a minor penalty. /me clearly not awake yet
16:20:19 <adamw> alright!
16:20:33 <adamw> i am very dubious on this bug as it's single-reporter, no dupes, i couldn't confirm it
16:20:37 <adamw> anyone else seen any bug like this?
16:21:21 <adamw> not to mention that it was probably Flash screwing up, which we can do zip all about
16:21:28 <jlaska> and reported some time ago as well
16:21:32 <notting> i've had firefox crash a couple of times over the past few weeks. nothing i can pinpoint, though
16:21:41 <jlaska> notting: abrt help?
16:21:51 <notting> not so far
16:22:13 <Oxf13> sadly I've been using chromium so I can't comment on firefox stability
16:22:15 <jlaska> this bug stinks
16:22:16 <jlaska> it makes me want to book a flight to paris
16:22:24 <Oxf13> when I use it every now and again with my mortgage site it doesn't crash
16:22:26 * adamw highly recommends either flashblock or noscript (which has much the same effect) for disabling all flash stuff until you explicitly enable it
16:23:14 <adamw> anyway, my feeling is to drop this from the list unless we find confirmation
16:23:15 <jlaska> not reproducing the provided website either
16:23:24 <jlaska> +1
16:23:32 <Oxf13> +1
16:24:02 <adamw> #agreed drop 513864, single-reporter Firefox bug, likely Flash-related, no-one could reproduce
16:24:48 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=514000
16:25:01 <buggbot> Bug 514000: medium, low, ---, jkysela, ASSIGNED, Aureon 5.1 MkII can't do 5.1 anymore
16:25:20 <jlaska> no updates since last meeting
16:25:34 <adamw> and it frankly seems kinda borderline
16:26:08 <adamw> hard to see why a non-critical sound bug in a single USB sound card (regression, granted) should block the release
16:26:26 <jlaska> good point
16:26:46 <adamw> as there's no record in the history, it was seemingly set as a blocker by bastien when he reported it
16:26:47 <notting> if it's a known regression we're not fixing, it should be relnoted/common-bug-ed
16:27:06 <adamw> yep, i could certainly add a commonbug.
16:27:41 <adamw> should we bother grabbing bastien from GIMPnet and interrogating him, or just drop it and tell him he can put it back if he feels passionately?
16:28:21 <notting> adamw: would this be more suitable for target?
16:28:40 <adamw> yeah, that'd be my feeling. although F12Target ~= nobody cares
16:28:58 <adamw> i don't think anyone really treats any bug on the target list much differently from bugs that _aren't_ on the target list
16:29:02 <jlaska> F12Wasteland
16:29:57 <notting> ideally, that wouldn't be the case
16:30:29 <adamw> ideally i'd have a golden pony =)
16:31:07 <adamw> #agreed 514000 to be dropped to F12Target, not serious / widespread enough to qualify as a blocker
16:31:36 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=514760
16:31:37 <buggbot> Bug 514760: medium, low, ---, llim, NEW, cleanup script segfaults during yum upgrade
16:31:49 <adamw> ah, the infamous lsb/glibc bug
16:32:57 <jlaska> so what's the story here ... not clear why it's a blocker
16:33:26 <adamw> well you get a pretty icky failure in yum whenever updating glibc, if redhat-lsb is installed
16:34:05 <adamw> segmentation fault on the glibc package cleanup isn't a great thing
16:34:21 <jlaska> /emul/ia32-linux/lib
16:34:27 <adamw> it smells like it'd probably be something quite trivial to fix...does anyone know lawrence lim?
16:34:45 <jlaska> yes, I can reach out to him
16:34:59 <jlaska> does /emul/ia32-linux come into play on x86_64?
16:35:06 * jlaska familiar with ia64 emul layer
16:35:09 <adamw> i'd vote we leave it on the list for now and poke llim to see whether he's aware / planning to do something
16:35:31 <mclasen> jlaska: thats ia64 horrible stuff
16:35:42 <jlaska> right
16:35:47 <jlaska> is that what tom london was seeing here too?
16:35:50 * jlaska hopes not
16:35:59 <jlaska> anyway ... I'll ping llim
16:36:06 <adamw> ok
16:36:45 <adamw> #agreed 514760 stays on the list for now, jlaska will reach out to llim
16:36:53 <adamw> #action jlaska to talk to llim about 514760
16:37:02 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=516057
16:37:03 <buggbot> Bug 516057: high, low, ---, peter, ASSIGNED, gets whacked by selinux execmem check
16:37:30 <Oxf13> execmem is getting turned off I thought
16:37:58 <Oxf13> in which case this bug won't block F12 release, but should stay open
16:38:09 <adamw> you mean the execmem check in selinux will be disabled for ga?
16:38:13 <Oxf13> yes
16:38:20 <Oxf13> I think it was already disabled
16:38:28 <adamw> ah...yeah, now you mention it i think i remember that too
16:39:16 <adamw> i don't see any mention in selinux-policy changelog that it's been done already, though
16:39:17 <notting> might want to clarify that with dwalsh just to make sure
16:39:24 <adamw> yeah that's what I was thinking
16:39:48 <Oxf13> see https://bugzilla.redhat.com/show_bug.cgi?id=512845
16:39:49 <buggbot> Bug 512845: high, high, ---, stransky, ASSIGNED, setroubleshoot:      SELinux is preventing firefox from changing a writable memory segment executable.
16:40:22 <Oxf13> Yes it is on as of -27.
16:41:08 <adamw> ah. so he turned it on without changelogging it. yay :)
16:41:21 <adamw> ok, drop it from the list then, thanks for the catch oxf13
16:42:14 <adamw> #agreed 512845 to be dropped from list, execmem checks are disabled for GA
16:42:20 <adamw> uh
16:42:33 <adamw> #agreed previous note should say 516057 not 512845
16:42:44 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=517260
16:42:46 <buggbot> Bug 517260: medium, low, ---, dlehman, MODIFIED, liveinst fails at partitioning screen
16:42:51 <jlaska> #info no updates from last meeting ... recommend it stay on the list.  Awaiting testing against official build anaconda-12.39-1
16:43:09 <adamw> another one waiting on a tag for 12.39
16:43:53 <adamw> any other comments?
16:44:48 <adamw> #agreed 517260 is waiting for anaconda 12.39 to be tagged so it can be confirmed fixed
16:45:00 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=517491
16:45:01 <buggbot> Bug 517491: medium, medium, ---, dcantrell, ASSIGNED, Anaconda fails if filesystem should be shrunk
16:45:52 <adamw> this one is getting somewhat messy; it seems to be covering several errors encountered when shrinking filesystems, but we're not entirely clear on all of them
16:46:02 <Oxf13> fantastic
16:46:14 <adamw> yup :/
16:46:29 * jlaska reading updates
16:46:56 <adamw> especially note comments from liam li, he rui and arenas belon
16:47:28 <jlaska> yeah, I think in the general feeling is that file system shrink is a bit fragile
16:49:17 <jlaska> arenas's reproducer seems to be missing a step
16:49:21 <adamw> in fact, i think dcantrell is the one who's wrong here :)
16:51:29 <adamw> i'm planning to post this:
16:51:34 <adamw> "Liam and He, can you re-run https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28shrink%29_install with the current F12 tree and verify what happens - whether it works, or you hit this bug, or you hit a different bug? Thanks."
16:51:37 <adamw> does that look good?
16:51:58 <jlaska> should we also validate fsck output before testing?
16:52:01 <jlaska> to confirm the filesystem is clean
16:52:15 <adamw> good point, if possible
16:52:41 <adamw> agreed with that plan?
16:52:42 <jlaska> that should address dcantrell's first point
16:52:52 <jlaska> yay test cases
16:53:03 <jlaska> yup, good plan adamw
16:53:45 <adamw> #agreed 517491 stays a blocker, group is sceptical that reporters were actually running into the problem dcantrell thinks they were. Comment to ask Liam and He to re-run the test case with current code.
16:53:56 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=517839
16:53:58 <buggbot> Bug 517839: medium, low, ---, dbhole, MODIFIED, bitxor and bitor both mapped to single bitor function
16:54:49 <adamw> looks like it's already been justified in the report (thanks jesse), waiting on testing
16:55:04 <adamw> i don't see any action needed
16:55:56 <adamw> agreed?
16:55:58 <Oxf13> I just did the builds, they have to be tested and tagged
16:56:05 <jlaska> agreed
16:56:07 <Oxf13> so it should stay on the list, yeah, agreed, no action needed
16:56:13 <adamw> #agreed 517839 is in hand, waiting on testing, thanks to oxf13 for handling it
16:56:25 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528662
16:56:27 <buggbot> Bug 528662: medium, low, ---, than, MODIFIED, "invalid symbolic color" when starting GTK apps
16:56:36 <adamw> this is our sole KDE blocker
16:56:43 <mclasen> I fixed that yesterday
16:56:55 <adamw> tag requested?
16:57:27 <mclasen> yes, I think so
16:57:27 <notting> tagged as of ~2 minutes ago
16:57:55 <adamw> ok, do you want to close already or wait for initial reporter to confirm the fix?
16:58:07 <jlaska> I think we'll get quick feedback on testing this issue
16:58:09 <Oxf13> just close it and ask them to re-open if it is still broken
16:58:12 <adamw> ok
16:58:16 <jlaska> Rex and Kevin were fast to respond
16:58:28 <notting> rex tested the tag request, too
16:58:44 <jlaska> ah cool, let's go with Oxf13's suggestion then
16:59:19 <adamw> #agreed 528662 fix is confirmed by mclasen and rdieter, bug to be closed, with a note to re-open if still finding problems
16:59:27 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=520750
16:59:28 <buggbot> Bug 520750: medium, low, ---, richard, ASSIGNED, Software Update windows checks for update does not stop ..
17:00:22 <adamw> i'm in agreement with richard (comment #9) here, have not seen any other report of this bug
17:00:32 <adamw> and reporter is now unable to reproduce
17:00:38 <adamw> seems like a no-brainer to close the bug
17:00:42 * mclasen is going to drop off in a bit, testing screensaver/multihead/suspend issues
17:00:48 <jlaska> ah this is Richards f-d-list one
17:00:51 <jlaska> agreed
17:00:55 <adamw> mclasen: thanks for all your help!
17:01:29 <adamw> #agreed 520750 appears to have been a one-off reporter-side problem, no other reports and reporter cannot now reproduce: CLOSED WORKSFORME
17:01:48 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522187
17:01:49 <buggbot> Bug 522187: high, low, ---, besfahbo, ASSIGNED, Java (so Eclipse too) crashes
17:03:03 <adamw> it's a nasty bug, but i'm not entirely convinced that eclipse sucking is a valid reason to delay f12 release
17:03:26 <adamw> i think it may have been added to blocker list on the theory that the bug was in Java, but that seems quite clearly not to be the case
17:04:09 <adamw> anyone think this should be a blocker?
17:05:26 <jlaska> are all the right eclipse ppl plugged in on this issue
17:05:34 <Oxf13> I'd say Target it
17:05:34 <adamw> yeah, and it's been worked on quite hard
17:05:37 <jlaska> it doesn't seem to be widespread doea it?
17:05:47 <adamw> it looks like there were actually multiple causes of this issue and several have been fixed already
17:05:48 <Oxf13> it'd be embarrassing if it went out broken, but...
17:05:50 <jlaska> one person still having the issue, while others are doing good
17:06:00 <adamw> so obviously the right people are plugged in and working on it
17:06:30 <adamw> so, agreed we drop to target?
17:06:50 <jlaska> yeah ...
17:07:04 <jlaska> think it's worth putting out a request for eclipse test feedback?
17:07:22 <jlaska> to up the confidence level ... or are folks happy with the positive reports in the bz
17:07:32 <adamw> Oxf13: i guess you'd happily accept a tag request before the cutoff date, to fix these problems?
17:07:46 <adamw> i dunno, couldn't hurt.
17:08:13 * jlaska reaches out to previous feature owners of eclipse features for feedback
17:08:46 <adamw> #agreed 522187 drops to target, not a bug in critical path and can be fixed as an update
17:08:47 <Oxf13> adamw: eclipse isn't crit-path so yeah
17:08:49 <Oxf13> it gets a free pass
17:08:51 <adamw> #action jlaska to reach out for further testing
17:09:29 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522970
17:09:31 <buggbot> Bug 522970: high, low, ---, airlied, ASSIGNED, popup messages unreadable
17:09:48 <adamw> hmm, this should just block fedora-x-blocker, not F12Blocker. anyway...
17:10:33 <adamw> mcepl_: around?
17:10:51 <adamw> fcami: around?
17:11:34 <adamw> this is a somewhat nasty bug, but it seems to be single-chipset: now I look closely, Tom and G. Wolfe have the exact same chipset
17:13:14 <adamw> i think on balance i'll leave it on for now and see what jerome has to say, but in the end would probably get dropped from the list if it's not fixed
17:16:02 <adamw> #agreed 522970 to stay on list for now, adamw will investigate
17:16:12 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523110
17:16:13 <buggbot> Bug 523110: medium, low, ---, dbhole, MODIFIED, autoincrement bustage on column redefinition
17:16:55 <adamw> another OO.o bug v. similar to the earlier one, again waiting for confirmation
17:17:01 <Oxf13> yep
17:17:03 <Oxf13> same deal
17:17:14 <adamw> nothing much to add
17:17:32 <adamw> #agreed 523110 another OO.o bug in-hand thanks to Jesse, waiting on confirmation
17:17:51 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523768
17:17:52 <buggbot> Bug 523768: medium, low, ---, jkysela, ASSIGNED, [abrt] crash detected in alsa-utils-1.0.21-2.fc12
17:18:04 <jlaska> no change on this one since last time
17:18:24 <adamw> right
17:18:42 <adamw> not much we can do here, though it looks like you may need an invalid configuration to reproduce the bug
17:19:42 <adamw> it would be nice if mcepl can confirm that with a valid config, the crash doesn't happen
17:20:08 <adamw> i vote we ask mcepl to clarify if jaroslav's comment #10 is accurate, if he fixes his config file he no longer hits the crash
17:20:12 <adamw> if that's true i'd say it goes off the list
17:20:58 <jlaska> that's sound
17:20:59 <adamw> (it looks like mcepl tried to disable PA in a rather odd way)
17:22:18 <adamw> leaving it on the list for now, but if mcepl doesn't confirm either way by next week i say we drop it
17:22:42 <adamw> #agreed 523768 probably should not be a blocker as it seems to only happen if the user manually messes up ALSA config files, waiting for mcepl to confirm
17:23:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=524168
17:23:20 <buggbot> Bug 524168: high, low, ---, hdegoede, MODIFIED, Wrong RAID10 recognition in anaconda while dmraid shows correct values
17:23:58 <adamw> i think this isanother one fixed in anaconda 12.39
17:24:46 <adamw> oh wait, actually, it's dmraid
17:25:22 <adamw> looks like it's been tagged
17:25:23 <adamw> https://fedorahosted.org/rel-eng/ticket/2579
17:25:47 <adamw> went in 20091021
17:26:29 <jlaska> I've got a dmraided system now, but wouldn't have seen this issue.  I plan to test dmraid on our next test run anyhow
17:26:35 <adamw> yeah, it's hardware-specific
17:26:43 <adamw> i'll add a note asking the reporter to re-test now
17:26:46 <adamw> sound good?
17:26:49 <jlaska> yes
17:26:56 <Oxf13> if it's tagged, I'd say close and ask to re-open if it's not fixed
17:27:08 <adamw> #agreed 524168: fixed dmraid went into rawhide on 20091021, ask for re-testing
17:27:26 <adamw> Oxf13: it's quite a serious issue and I think the fix was 'blind' so for peace of mind i'd prefer to keep it open
17:27:40 <Oxf13> *shrug*
17:27:48 <adamw> jlaska: tiebreaker? :)
17:28:10 <jlaska> let's do both
17:28:11 <adamw> note that hans did want the reporter to test, see comment #40
17:28:13 <jlaska> keep it open today
17:28:18 <jlaska> and close it out next week if no feedback
17:28:22 <adamw> fair enough
17:28:44 <adamw> #agreed 524168 wait for testing for a week before closing, but close next week if no feedback received
17:29:21 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526044
17:29:22 <buggbot> Bug 526044: is not accessible.
17:29:48 <Oxf13> *blink*
17:30:03 <Oxf13> marked as security
17:30:08 <adamw> ooh, it's a security issue
17:30:17 <Oxf13> I poked yesterday, haven't seen a response
17:30:34 <adamw> do we discuss security issues in an open channel? interesting procedure question =)
17:30:41 <adamw> i guess it's ok if we keep it vague
17:30:45 <Oxf13> well, Fedora doesn't have embargo...
17:31:01 <Oxf13> anyway I'll try to catch up with the maintainer and/or manager on IRC today
17:31:14 <adamw> yeah, seems like there's not really any action here anyway
17:31:23 <adamw> #agreed 526044 still waiting on developers
17:31:31 <adamw> #action oxf13 to try and catch up with developers for 526044
17:31:41 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526154
17:31:42 <buggbot> Bug 526154: high, high, ---, gecko-bugs-nobody, ASSIGNED, localisation breaks sending mail
17:32:27 <adamw> oh look, thunderbird sucks
17:32:50 <adamw> it does seem like a nasty bug for czech users, though, and the fix has been pretty well isolated
17:33:47 <adamw> i'd say we just poke Martin and ask him to do a build with the fix milos identified
17:34:44 <adamw> anyone have strong feelings either way about keeping it on the blocker list?
17:35:10 <Oxf13> I'd rather not slip the release due to it
17:35:21 <adamw> i'd say it's worth keeping it for now just to monitor it, but probably drop it if it somehow doesn't get fixed
17:35:25 <adamw> i.e. a 'fake blocker' :)
17:35:32 <Oxf13> *grumble*
17:35:34 <Oxf13> I hate those
17:35:40 <adamw> yeah...ikwym
17:35:42 <Oxf13> it cheapens the entire thing
17:36:00 <adamw> if you'd prefer to take a hard line on those i'm happy to drop it
17:36:18 <Oxf13> if we wouldn't slip the release for it, it doesn't belong on the blocker list
17:36:23 <adamw> fair enough
17:36:26 <adamw> dropping to target then
17:37:40 <adamw> #agreed 526154 drops to target, impact is not wide enough for it to block release
17:37:59 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526699
17:38:00 <buggbot> Bug 526699: medium, medium, ---, dlehman, ASSIGNED, CryptoError: luks_format failed for '/dev/mapper/VolGroup-LogVol00'
17:38:39 <adamw> looks like Peter confirmed that the 'fix' was incorrect
17:39:11 <adamw> looks like the fixed fix went into 12.39
17:39:42 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=d04d7f33f58bc8d1f21db4f48958166f0f46bf27
17:39:45 <adamw> i vote we set to MODIFIED and ask Peter to confirm it's correct in 12.39
17:39:54 <jlaska> agreed
17:40:11 <Oxf13> +1
17:40:35 <adamw> #agreed 526699 should be fixed in 12.39, set to MODIFIED and ask Peter to confirm
17:41:11 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526881
17:41:13 <buggbot> Bug 526881: medium, low, ---, tfujiwar, MODIFIED, ibus-anthy backtrace is reported by the latest abrt
17:42:06 <adamw> this looks to be fixed and tagged
17:42:20 <adamw> i'd say we close it and ask Alex to re-open if he still encounters problems
17:43:19 <jlaska> yeah, no objections here
17:43:35 <jlaska> although, it's murky when to close and suggest reopen ... versus leaving in MODIFIED
17:44:27 <adamw> basically i go on whether the fix has actually been fully tested...if the maintainer could exactly reproduce the problem and says it's definitely fixed with the updated version, i'm OK to close
17:44:36 <adamw> which seems to be the case here
17:44:47 <jlaska> ah, so as long as someone who could hit the bug, confirmed the fix
17:44:50 <adamw> for the previous one where I advocated leaving it open, the maintainer hadn't entirely tested the fix as he wanted it to be tested
17:44:54 <jlaska> whether it's reporter, maintainer or cc list
17:45:01 <adamw> yeah, especially if it's a pretty simple bug like this
17:45:03 <jlaska> yeah, that's sensible
17:45:08 <adamw> where it's something...ickier, it's nice to have two confirmations
17:45:10 <Oxf13> note that we let maintianers close->rawhide all the time
17:45:12 <jlaska> thanks for clarifying
17:45:16 <Oxf13> and many do as soon as the build is tagged
17:45:17 <jlaska> Oxf13: right
17:45:49 <adamw> Oxf13: yeah, that's appropriate most of the time, for blockers i think it's good to be somewhat careful, though.
17:46:24 <adamw> there's more potential harm in closing prematurely than closing a bit later than was strictly necessary, i reckon.
17:47:21 <adamw> #agreed 526881 is a straightforward issue which was reproduced, fixed and tagged: closing
17:48:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=527089
17:48:25 <buggbot> Bug 527089: medium, low, ---, rstrode, NEW, repaire console is not accessible
17:48:43 <adamw> gah, someone closed an f12 bug as a dupe of this bug, which is f11...still, same issue in both cases, we can probably live with it
17:49:15 <adamw> this one's slightly borderline as there's a fairly simple and document-able workaround: disable plymouth
17:49:55 <adamw> shall we drag halfline in for his take?
17:51:12 <jlaska> definitely
17:51:20 <jlaska> want me to grab him?
17:51:35 <adamw> sure, if it's convenient
17:52:35 <jlaska> just a sec ...
17:52:50 <notting> irc grabs are always convenient. jlaska's arms aren't that long :)
17:53:03 <jlaska> go go gadget arms!
17:53:22 <jlaska> halfline: thanks for joining, adamw is walking us through the bug list and some questions came up on /topic bug
17:53:42 <adamw> well, really, just what's your take on it - have you looked at it, is it trivially fixable etc
17:54:23 <halfline> this is an issue that i thought i fixed before the beta
17:54:31 <halfline> but there have been a few reports of it since the beta
17:54:37 <halfline> so i clearly botched the fix
17:54:46 <halfline> i haven't investigated recently
17:54:54 <halfline> because i've got my nose in gdm atm
17:54:59 <halfline> but it's on my todo list to fix soon
17:55:05 <adamw> i'd say the gdm keyboard bug takes precedence over this
17:55:12 <adamw> this vs. gdm multi-user-switch bug is a bit of a toss-up
17:55:26 <adamw> would you think of this one as a release blocker?
17:56:03 <halfline> yea people need single user mode...
17:56:08 <halfline> this is a release blocker
17:56:28 <adamw> ah, i noted this before you came in, but the mitigating factor is there's a workaround: disable plymouth and it works fine
17:56:48 <adamw> not that anyone would ever want to live without plymouth, obviously ;)
17:56:54 <halfline> plymouth can't be disabled
17:57:03 <halfline> what do you mean by "disable plymouth" ?
17:57:08 <halfline> take rhgb off kernel command line?
17:57:11 <adamw> ah, yeah, i may be explaining wrong
17:57:11 <adamw> yes
17:57:26 <halfline> right, makes sense
17:57:30 <adamw> the reporter of the dupe said that taking rhgb off the command line makes it work
17:57:39 <notting> ... which would narrow down where the problem is :)
17:58:18 <halfline> hmm i wonder if i just didn't get the right version of plymouth tagged for the beta
17:58:19 * halfline looks
17:59:03 <adamw> i did get a plymouth update on Oct 19th
17:59:15 <adamw> suggesting that maybe the beta's version was an old one
17:59:24 <adamw> I got plymouth-0.8.0-0.2009.29.09.11.fc12 on the 19th
17:59:44 <Oxf13> plymouth-0.8.0-0.2009.29.09.9.fc12 was in the beta
18:00:02 <halfline> ah that's the problem then
18:00:06 <adamw> so it misses two fixes noted as being for 528683
18:00:26 <halfline> okay so i'll just move to modified
18:00:37 <halfline> it was probably too late for the beta train or something
18:00:51 <halfline> Oxf13: is there an open tag request for plymouth right now?
18:00:57 <adamw> should 528683 be closed as FIXED? since harald confirmed the fix
18:01:05 <adamw> halfline: 11 is already tagged, if i got it as an update
18:01:12 <adamw> i'm not pulling from anywhere but rawhide (which is the f12 train)
18:01:21 <Oxf13> plymouth-0.8.0-0.2009.29.09.11.fc12 was the last tag request
18:01:24 <Oxf13> and it's tagged for final
18:01:31 <halfline> alright so we're set
18:01:34 <halfline> just need to close the bugs then
18:01:39 <adamw> ok
18:02:09 <adamw> 527089 was reported against f11 originally, actually
18:02:16 <adamw> so we can't really close that until you ship an f11 update
18:02:24 <adamw> but we can take it off the f12 blocker list
18:02:35 <halfline> woops
18:02:38 <halfline> just closed it
18:02:44 <adamw> i'll re-open :)
18:03:33 <adamw> (this is why i don't like single reports covering multiple releases...)
18:03:47 <adamw> alright, looks like we're set there
18:03:49 <adamw> thanks halfline!
18:03:55 <halfline> yup
18:04:16 <adamw> #agreed 527089 can be dropped from blocker list as it is fixed in f12 now, thanks halfline for explanations
18:04:26 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=527426
18:04:27 <buggbot> Bug 527426: medium, low, ---, rstrode, ASSIGNED, (plymouth) No text prompt for encryption password (but keyboard input is accepted)
18:04:35 <halfline> whee more fun
18:04:38 <adamw> oh look, it's another plymouth one :)
18:04:58 <jlaska> I think this is a strong candidate for blocker
18:05:00 <halfline> this one i pushed an untested fix for to get warren to try
18:05:03 <halfline> but it didn't fix it
18:05:11 <halfline> i need to dive into more
18:05:14 <adamw> alright
18:05:17 <adamw> i'd agree it's a blocker
18:05:24 <halfline> this bug affects users who get the text plugin
18:05:37 <adamw> ideally everyone should be using kms, but hey, not an ideal world
18:05:40 <halfline> users of the big three (intel, nouveau, radeon) aren't affected
18:05:45 <halfline> right
18:06:02 <adamw> well, some people have to disable KMS with those drivers
18:06:05 <halfline> right
18:06:19 <halfline> most users aren't affected by this bug
18:06:21 <halfline> but some will be
18:06:24 <adamw> yeah
18:06:28 <adamw> and it's pretty icky for those who are
18:06:42 <adamw> well, i dunno, most people would arrive at pressing Esc eventually. but let's fix it. :)
18:06:56 <halfline> yup, shouldn't be hard to fix
18:07:03 <halfline> i'm just not on plymouth at the moment
18:07:04 <adamw> no action needed on qa's side though, this one's all on halfline ;)
18:07:08 <halfline> will be going back to it soon
18:07:15 <adamw> #agreed 527426 remains a blocker, halfline is aware and will work on it
18:07:27 <jlaska> halfline: I'm a radeon user ... and was having this bug
18:07:43 <halfline> jlaska: that means you're also hitting some other bug
18:07:43 <jlaska> but that's more of a radeon problem I believe
18:07:44 <adamw> jlaska: you had to disable KMS, right?
18:07:44 <jlaska> right
18:07:46 <halfline> jlaska: where you're not getting modesetting
18:07:56 <jlaska> yeah
18:08:13 <jlaska> different issue, but I get modesetting with dual monitor setup ... and no modesetting with just my laptop
18:08:25 <adamw> while we've got halfline around, i'm going to jump to the last issue in the list, as it's the only other one that involves him: https://bugzilla.redhat.com/show_bug.cgi?id=530452
18:08:26 <buggbot> Bug 530452: high, low, ---, jmccann, ASSIGNED, Gnome sets the keyboard layout to USA after every log in
18:08:29 <jlaska> anyhow ... I'll take to bugzilla where it belongs
18:08:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530452
18:08:34 <buggbot> Bug 530452: high, low, ---, jmccann, ASSIGNED, Gnome sets the keyboard layout to USA after every log in
18:08:52 <halfline> yea there have been like 3 or 4 reports of that in the last couple of days
18:09:04 <adamw> yep, and more on the list and in the forum
18:09:07 <halfline> it must be a regression from a change upstream
18:09:18 <halfline> it's on my todo list next
18:09:22 <halfline> (before the plymouth stuff)
18:10:03 <adamw> basically the expectation is the keyboard layout set in gdm should be inherited in the session, right? and that if you set it from a live boot before installing, the installation should use that layout also
18:10:42 <adamw> comment #5 seems to lay the expectations out quite nicely
18:11:06 <adamw> oh, and the one i missed is that users expect the keyboard layout they chose during install to be the one gdm defaults to
18:11:10 <halfline> right, gdm apparently isn't picking up the installer default anymore
18:11:21 <halfline> which means the users are getting US the first time they log in
18:11:28 <adamw> basically i think if you make it work per comment #5 everyone will be happy =)
18:12:05 <adamw> jlaska: do you think we should discuss testing around this issue, btw? it seems like one we might have picked up in the beta validation tests
18:12:14 <adamw> jlaska: viking even suggested having it as an autoqa test
18:12:20 <adamw> not sure how feasible that is
18:12:20 <jlaska> there were a few users reporting this yesterday in fac
18:12:25 <halfline> i don't know that we're going to get all of comment #5 before f12
18:12:42 <adamw> i guess as close as you can get =)
18:12:49 <halfline> we will definitely fix the recent regression where USA is getting used despite what the user picks
18:13:06 <adamw> that seems to be the big one, yeah
18:13:15 <halfline> the language chooser has a number of deeper issues comment 5 lightly touches on
18:13:25 <halfline> but addressing them is probably too big of a can of worms for GA
18:13:29 <adamw> fair enough
18:14:06 <jlaska> adamw: yeah, it's something we can improve on ... we don't call out any i18n testing in the current matrix.  Certainly open to test case submissions to cover this for next time
18:14:11 <adamw> #agreed 530452 is a blocker and halfline has it in hand: the major bug (gdm not picking up the system-wide default layout set during installation) will be fixed
18:14:28 <adamw> jlaska: shall we throw it on the next qa meeting agenda?
18:14:46 <jlaska> you betcha
18:14:56 * jlaska pencils it in on the wiki
18:16:28 <adamw> ok, onwards!
18:16:28 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=527520
18:16:29 <buggbot> Bug 527520: medium, urgent, ---, anaconda-maint-list, MODIFIED, post-install lxde system boots in text mode
18:16:44 <adamw> another one fixed in anaconda 12.39, awaits testing
18:17:07 * jlaska started a proposed QA meeting agenda list at  https://fedoraproject.org/wiki/QA/Meetings/20091026
18:17:30 <jlaska> adamw: yeah, I don't think there is any other action needed there
18:17:36 <adamw> i vote we just add a note asking christoph to test with the new anaconda when possible
18:17:54 <tk009> i will try that right now myself
18:18:56 <adamw> tk009: can't be tested right now, 12.39 has not been tagged
18:19:11 <adamw> well, not unless you build your own live image and roll 12.39 into it i guess
18:19:47 <adamw> #agreed 527520 another fixed in anaconda 12.39, ask christoph wickert to confirm the fix
18:20:16 <adamw> @topic https://bugzilla.redhat.com/show_bug.cgi?id=527920
18:20:18 <buggbot> Bug 527920: high, low, ---, jmccann, ASSIGNED, gdm doesn't show user list and crashes - unable to login
18:20:18 <adamw> erf
18:20:20 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=527920
18:20:21 <buggbot> Bug 527920: high, low, ---, jmccann, ASSIGNED, gdm doesn't show user list and crashes - unable to login
18:21:27 <adamw> oh look i was lying, it's another gdm issue :)
18:21:29 <jlaska> I vote to keep this on the list ... I'm seeing decent chatter on this issue (irc)
18:21:50 <adamw> halfline: where are you on this one?
18:21:52 <halfline> also on my before plymouth todo list
18:21:59 <mdomsch> this could also be root cause on my bug, 530169
18:22:07 * halfline looks
18:22:36 <halfline> no
18:22:45 <halfline> not related
18:23:06 <halfline> 527920 is soley about the "Other..." user not showing up in the list when you have no local users
18:23:22 <adamw> is there any more input you need for 527920? anything anyone can do to help?
18:23:27 <halfline> no Other user + no local users = no users at all
18:23:35 <halfline> nope, i just need to fix the issue
18:23:54 <adamw> ok
18:24:07 <adamw> #agreed 527920 is a blocker and on halfline's priority list, no action needed
18:24:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=527952
18:24:21 <buggbot> Bug 527952: medium, medium, ---, dlehman, MODIFIED, AttributeError: 'NoneType' object has no attribute 'disk'
18:24:49 <adamw> another 12.39 retest needed, jan is waiting to do the retest
18:24:51 <adamw> no action needed
18:24:55 <jlaska> same deal
18:25:50 <adamw> #agreed 527952 is another anaconda 12.39 retest issue, no action needed
18:25:56 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528097
18:25:57 <buggbot> Bug 528097: medium, low, ---, lvm-team, MODIFIED, /sbin/dmraid needs possibly unmounted /usr/lib
18:26:13 <adamw> still waiting for testing (asked on wed)
18:26:31 <jlaska> close this out next friday if we haven't heard back?
18:26:35 <adamw> yup
18:26:52 <adamw> #agreed 528097 is probably fixed, still waiting on feedback, close at next meeting if no feedback received by then
18:27:01 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528317
18:27:02 <buggbot> Bug 528317: high, low, ---, anaconda-maint-list, MODIFIED, anaconda traceback in getDefaultTimeZone KeyError en_AU
18:27:22 <adamw> this is the one we were trying to make a judgment call on
18:27:32 <adamw> the problem is that it's a significant problem but the fix is quite invasive
18:27:34 <adamw> clumens: around?
18:27:40 <adamw> oh he's not here...
18:27:42 <jlaska> I don't think he's in today
18:27:48 <adamw> denise_akf: do you know?
18:27:55 <adamw> darn, everyone's gone :)
18:28:07 <denise_akf> clumens is moving into his new house today ;-)
18:28:07 <adamw> well, my feeling on this one is the impact is sufficiently wide that we need the fix even if it's invasive
18:28:25 <jlaska> Enough people seem to be hitting this
18:28:30 <adamw> it basically affects anyone who's doing an install or upgrade with locale set to anything in the list at http://git.fedoraproject.org/git/?p=anaconda.git;a=blob;f=lang-table
18:28:38 <adamw> which includes rather common things like non-US English locales
18:28:53 <jlaska> is a patch in the bz?
18:28:54 * jlaska looking
18:29:06 <adamw> uh sorry NOT in that list
18:29:22 <denise_akf> although it is very easy to workaround - "just" install in english
18:29:36 <adamw> right, but the workaround's not too obvious from the error, and the error's a hard fail
18:29:42 <denise_akf> agreed
18:30:11 <adamw> jlaska: it's fixed in the F-13 branch of anaconda
18:30:18 <adamw> per comment #4
18:30:28 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=2525dda439357f0d169d8eca6e47a8d154ce8097
18:30:32 <jlaska> yeah, it is a big one
18:30:56 <adamw> so we think we're agreed we need this patch, but we need to do some good testing of it
18:31:27 <adamw> sound like a consensus?
18:31:38 <denise> does anyone have time? clumens did sanity-checking but nothing exhaustive
18:31:49 <jlaska> #info testing required - text and gui language, keyboard and timezone steps
18:31:52 <adamw> qa will be doing another couple of rounds of installer testing
18:31:59 <adamw> right jlaska?
18:32:04 <denise> my fear would not be that it didnt fix the problem, but that there was some unintended sideeffect
18:32:05 <jlaska> yes
18:32:13 <adamw> yeah, that's the obvious worry
18:32:22 <jlaska> there's a commenting out of udevadm ... not sure what that's about
18:32:38 <denise> ok, I'm good if yoiu guys are comfy with this
18:32:48 <adamw> denise: are any regressions most likely to occur in non en-US locale installations?
18:32:53 <denise> udevadm - maybe working around the lvm change?
18:32:55 <adamw> denise: it doesn't fill us with joy but we'll do our best :)
18:33:05 <denise> adamw, damned if i know - sorry
18:33:05 <jlaska> I'd like to sync-up with clumens to develop a good plan to attack this
18:33:31 <jlaska> the patch isn't too scary, just touches a lot of files
18:33:36 <adamw> ok, so...the plan: we want the fix in f12, jlaska to sync up with clumens to devise a plan of attack and try to make sure sufficient testing is done
18:33:54 <denise> jlaska he should be in on Monday
18:33:59 <jlaska> #action jlaska to catch up with clumens to identify test impact for 528317
18:34:03 <jlaska> denise: thx
18:34:11 <denise> a new homeowner ;-)
18:34:19 <jlaska> god help him
18:34:25 <denise> ;-))
18:34:30 <jlaska> just in time to cleanup the leaves?
18:34:37 <adamw> #agreed 528317 needs to be a blocker, but the fix is invasive: jlaska will sync up with clumens to make sure fix is implemented as cleanly as possible and to arrange sufficient testing
18:34:50 <jlaska> #link http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=2525dda439357f0d169d8eca6e47a8d154ce8097;hp=fbd2e28131d2bf834df883961c7eedb844bb3ebe
18:34:53 * adamw is quite happy with his externally-managed box in the sky
18:36:14 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528497
18:36:16 <buggbot> Bug 528497: medium, low, ---, msivak, MODIFIED, FirstAidKit does not start when using F-12-Beta rescue mode from disc1.iso
18:36:30 <jlaska> I just added a needinfo? jlaska on this
18:36:36 <jlaska> trying to find out what build it's fixed in
18:37:47 <adamw> i don't see anything in the changelog about this bug
18:38:01 <jlaska> neither do I ... or in koji (anaconda or firstaidkit)
18:38:09 <jlaska> I'm going to put a comment asking for the build nvr
18:38:13 <adamw> ok
18:38:14 <jlaska> and will test at the same time
18:38:29 <adamw> #agreed 528497 jlaska to test this and clarify what package / version it should be fixed in
18:38:36 <adamw> #action jlaska to re-test 528497
18:38:48 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528537
18:38:49 <buggbot> Bug 528537: medium, low, ---, kernel-maint, ASSIGNED, fails to get kickstart file over nfs.
18:39:17 <denise> jlaska, the fix is in rescue.py for 528497
18:39:46 <denise> New commits:
18:39:46 <denise> commit 40039ddec4fa25a224f95e4805a1ee89f95a0ebf
18:39:46 <denise> Author: Martin Sivak <msivak@redhat.com>
18:39:46 <denise> Date:   Mon Oct 12 16:33:23 2009 +0200
18:39:46 <denise> We moved from dialog to newt.. (#528497)
18:39:46 <adamw> i think i was correct in assigning 528537 to the kernel, that appears to be where a fix is needed
18:40:13 <adamw> do we need to alert a kernel maintainer to apply this fix?
18:40:17 <adamw> cebbert: ping
18:40:49 <jlaska> denise: I see that on the master branch, but not in f12-branch
18:40:55 <jlaska> denise: http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=40039ddec4fa25a224f95e4805a1ee89f95a0ebf
18:41:21 <denise> ok - will ask him to get it to f12-branch
18:41:56 <adamw> trying to raise a kernel developer in kernel channel
18:43:38 <adamw> it appears the land of kernel development is a wasteland
18:43:50 <adamw> jlaska: are there any within grabbin' range of you?
18:44:10 <jlaska> they're all eating 'stuff on a stick' at the state fair :)
18:44:20 <adamw> aha
18:44:27 <adamw> sounds like kernel developers alright
18:44:36 <jlaska> this is steved's bug?
18:44:38 <adamw> shall we cc cebbert on the bug and stick a fork in it?
18:45:19 <adamw> hmm, steve's a kernel guy anyway, he should be able to commit his fix
18:45:43 <jlaska> for some reason I thoguht he owned it
18:45:50 <jlaska> notting: you guys spoke about this one last week?
18:45:52 <adamw> comment #7 / #8 indicate he identified a fix and it was blessed by upstream
18:46:07 <notting> wha?
18:46:09 <adamw> jlaska: it would've got reassigned to the general kernel owner when i switched component to kernel
18:46:11 <jlaska> so we just need it packaged and build?
18:46:26 <adamw> lemme check the kernel changelog on koji and see if it's been thrown in
18:46:35 <adamw> koji kernel is quite badly past the current rawhide kernel atm
18:46:59 <adamw> are we planning to ship with kernel 56? if not we really should get a newer build tagged in asap
18:47:19 <adamw> and, yeah, steve checked the fix in on oct 13, just didn't note it in the bug
18:47:23 <adamw> * Tue Oct 13 2009 Steve Dickson <steved@redhat.com> 2.6.31.4-81 - Fixed hang during NFS installs (bz 528537)
18:47:42 <jlaska> cool, good find
18:48:42 <adamw> i've posted a comment pointing that out and saying we should get a newer kernel tagged
18:49:00 <adamw> anything else needed?
18:49:04 <jlaska> notting: sorry for disturbance ... adamw was on it
18:49:23 <jlaska> nothing from me, that'll be a good one to have resolve
18:49:24 <jlaska> d
18:49:59 <adamw> alright
18:50:07 <jforbes> adamw: no, we are planning to ship with a different kernel
18:50:21 <jforbes> adamw: We have to turn off debugging for the release kernel anyway
18:50:23 <adamw> #agreed 528537 is fixed in a later koji kernel build, ask if we can have a newer build tagged soon
18:50:43 <adamw> jforbes: ok. as I said, from a testing POV, the sooner you tag an updated build the better, there's a lot of changes accumulating with little to no testing happening on 'em
18:51:36 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528909
18:51:37 <buggbot> Bug 528909: medium, low, ---, davidz, NEW, DevKit 95-devkit-disks.rules should avoid scan all DM devices
18:51:47 <jforbes> adamw: at the very least, we wanted the .5 update that committed this morning, not sure what else is pending.  My xen fix will be kernel as well, but I expect there will be more than one kernel tagged before release
18:52:13 <jlaska> adamw: update from davidz ... ACK and it's on the todo list
18:53:04 <adamw> jforbes: the last one that got tagged was 2.6.31.1-56, the latest build is 2.6.31.5-91.rc1 , so there's 35 revisions piled up including a bump of 4 upstream patchlevels, which is kinda significant...i'd like us to be testing all that stuff :)
18:53:09 <jlaska> is there anything other than wait and check in on this next Friday?
18:53:28 <adamw> jlaska: can't think of anything
18:53:47 <jforbes> adamw: Yeah, I think the original plan was to tag -88, but then 31.5 was close.  I expect it will be tagged once it is built
18:53:55 <adamw> jforbes: cool, thanks
18:54:26 <adamw> #agreed 528909 is a blocker and on davidz's todo list, no action needed
18:54:34 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530320
18:54:35 <buggbot> Bug 530320: high, high, ---, clumens, NEW, firstboot errors when loading modules
18:54:39 <jlaska> not sure on this one
18:54:52 <adamw> this looks like a dupe to me
18:55:00 <jlaska> oh yeah?
18:55:07 <adamw> we already have a bug for smolt being missing from firstboot
18:55:08 <adamw> yeah
18:55:09 <Oxf13> well there are multiple firstboot stuff
18:55:12 <Oxf13> there was smolt
18:55:12 <adamw> i think this is that same issue
18:55:19 <jlaska> there's a few things going on here, but the error loading smolt module was one I'd like to see
18:55:19 <Oxf13> and then there was system-config-date things I think
18:55:24 <jlaska> yeah
18:55:30 <jlaska> and system-config-lang too iirc?
18:55:31 <Oxf13> smolt is fixed and tagged
18:55:40 <adamw> actually, this may be the only bug report of it, but the smolt issue was known and is fixed
18:55:50 <jlaska> yeah, I recall mmcgrath posting about that somewhere
18:56:01 <Oxf13> I think we need to have somebody do a fresh install and document any/all current firstboot issues
18:56:02 <adamw> yeah, on -devel-list, i have it in common bugs
18:56:19 <adamw> should we ask michal to re-test and file any remaining observed issues separately?
18:56:42 <adamw> smolt change landed today
18:57:00 <jlaska> so we'll use this to track the smolt issue only
18:57:05 <jlaska> the other ones get different bz's ?
18:57:47 <jlaska> I don't expect to see traction on the window mgr warnings
18:57:49 <adamw> yeah
18:57:56 <adamw> i'd like a clearer description of what practical problems he's seeing
18:58:00 <adamw> 'some modules are missing' is rather vague
18:58:21 <jlaska> s-c-language was complained about elsewhere, but I've not yet seen any updates on it
18:58:49 <Oxf13> could make this bug a firstboot tracking bug, and make other bugs block this one
18:58:57 <adamw> i do remember not ever being asked to set a locale when i was trying to test that 'install fails with certain locale settings' bug
18:59:48 <adamw> Oxf13: maybe...wdyt jlaska?
19:00:10 <jlaska> I like Oxf13's idea
19:00:19 <adamw> OK
19:00:26 <jlaska> iirc, you have to do firstboot --reconfig to get the language module
19:00:29 <jlaska> so it's not common, but still
19:01:40 <adamw> i'll post a comment asking reporter to file a separate bug for each issue observed and set it to block this bug
19:01:52 <jlaska> we've just made clumens monday morning!
19:01:58 <adamw> =)
19:02:28 <adamw> #agreed 530320 covers multiple issues, ask reporter to file separate bugs for each and use 530320 as a tracker. smolt issue should be fixed as of today's rawhide
19:02:54 <adamw> alright, gonna skip over the X blocker for now and go to the last non-X bug: https://bugzilla.redhat.com/show_bug.cgi?id=530343
19:02:56 <buggbot> Bug 530343: high, high, ---, dcantrell, NEW, Anaconda should not add the FQDN as 127.0.0.1
19:02:56 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530343
19:02:57 <buggbot> Bug 530343: high, high, ---, dcantrell, NEW, Anaconda should not add the FQDN as 127.0.0.1
19:03:39 <jlaska> hmm, interseting
19:03:41 <adamw> i think either 529898 should depend on this one or there should be no relationship - doesn't seem to make sense for a fedora bug to depend on a RHEL one
19:03:53 <adamw> i think bugzilla automatically makes bugs filed as clones depend on their parent bugs, which seems silly, but ohwell
19:04:15 <jlaska> I'm more thinking about fallout of changing that /etc/hosts entry now
19:04:42 <adamw> c'mon, /etc/hosts is completely unimportant, it can't cause any trouble =)
19:05:44 <adamw> denise: any comments on this one?
19:05:59 <jlaska> adamw: heh
19:06:12 <denise> looking ..
19:06:50 <jforbes> adamw: well, obviously it can break virt
19:07:04 <jlaska> is this anything new though?
19:07:07 <notting> ... but i don't think this change is anything that new, is it?
19:07:10 <notting> jlaska: JINX!
19:07:15 <denise> not afaik
19:07:17 * jlaska cannot speak
19:07:48 <adamw> so, i vote we lower jlaska's salary by 95% and distribute it among the others active in this meeting
19:07:53 <adamw> motion can be denied by one anti vote
19:07:57 <denise> -100
19:07:57 <adamw> all those against the motion, speak :)
19:08:05 <denise> -1000 even
19:08:25 <adamw> aw, foo!
19:08:28 <notting> adamw: error: reporting heirachy inversion.
19:08:30 <denise> nice try!
19:08:48 <adamw> notting: that's only a warning in adamwcode
19:08:50 <jlaska> ROTFL! :)
19:09:33 <adamw> alright, anyway :) i don't really know much about this change, my systems never have fqdns anyway
19:10:07 <adamw> should we ask the report to clarify if they think this is actually a behaviour change from previous releases or not?
19:10:08 <notting> jforbes: was there a time that live migration did work?
19:10:17 <Oxf13> my silly meter has gone through the roof.  Is it time for another break?
19:10:18 <denise> doenst seem very invasive, but what else might care?
19:10:28 <jforbes> notting: Out of the box? I doubt it
19:10:38 <Oxf13> denise: every time we make changes to how /etc/hosts is populated, something falls over
19:10:48 <jlaska> I think it's down to the Universal X blocker list?
19:10:58 <Oxf13> I mean, the really simple solution here is to keep F12 the way it is, change it in RHEL6 and let them deal with the fallout
19:11:19 <jforbes> Oxf13: I think that is a valid solution
19:11:19 <Oxf13> (bonus points for changing it for F13)
19:11:23 <adamw> denise: the change to anaconda wouldn't be invasive, but screwing with /etc/hosts is usually a Very Bad Idea
19:11:29 <adamw> i'm with oxf13 on this one
19:11:41 <jforbes> I would have been more inclined to push for this if it were 2 months ago
19:11:42 <denise> yeah - ok, so we change anaconda for f13?
19:11:53 <adamw> if someone wants to change this for RHEL then they can go right ahead but for fedora we know where we're at for our release and it doesn't seem like a sensible change
19:12:24 <adamw> jlaska: after this bug, yes, we're down to the X blockers
19:12:43 <jlaska> without a full understanding of the issue, I wouldn't touch /etc/hosts either
19:12:50 <Oxf13> I think we're in agreement here
19:13:00 <denise> jforbes, we plan to rebase anaconda from f13 anyway - god help us
19:13:16 <adamw> you crazy fools
19:13:18 <adamw> =)
19:13:26 <denise> cheap thrills ;-)
19:13:29 <Oxf13> WHAT COULD GO WRONG‽
19:13:50 * jlaska cries
19:14:22 <adamw> ok, #agreed 530343 should not be 'fixed' for f12, changing /etc/hosts has unpredictable results and we have five months of experience invested in the current f12 behaviour, bug to be closed as WONTFIX for fedora 12
19:14:37 <adamw> actually, maybe just make it clear it's for f13 not f12
19:15:08 <jforbes> Yeah, I wouldn't close, just change target to F13
19:16:02 <Oxf13> worksforme
19:16:19 <adamw> ok! home stretch: X.org blockers coming up
19:16:24 <Oxf13> I request a break
19:16:27 <adamw> anyone want another break before we go onto those, or should we dive right in?
19:16:31 <adamw> ah, you pre-empt me :)
19:16:35 <Oxf13> I'm going to need an hour or so
19:16:48 <adamw> there's 11 X blockers
19:16:54 <adamw> will take us about an hour at our current pace.
19:17:05 <adamw> should we leave the meeting open or close it and open a new one in an hour?
19:17:33 <Oxf13> Well, I may have to run and make an emergency appliance purchase before the sell out, so I can't guarantee my return
19:17:36 <Oxf13> don't block on me though
19:17:56 <adamw> ok...meeting adjourned till 1:15pm PST (that's in 1 hour)
19:18:02 <adamw> will resume at that time whether oxf13's back or not :)
19:18:25 <adamw> anyone who wants to familiarize themselves with the upcoming bugs before we get there, look at https://bugzilla.redhat.com/show_bug.cgi?id=530341
19:18:27 <buggbot> Bug 530341: medium, low, ---, xgl-maint, NEW, Fedora Universal X Blocker
19:19:15 * mcepl_ is back
19:20:30 <notting> adamw: i'm going to have to leave before then.
19:20:48 <notting> on the one i filed, 528048 is still an issue
19:22:37 <tk009> I am interested in that bug as well, I want to understand how that is a blocker
19:23:31 <notting> you resume. the display is completely black. if you don't know what's going on, you have no recovery method other than reboot
19:23:43 <notting> it also triggers occasionally on user switch, for some reason
19:24:44 <adamw> sounds like a problem with console switching, i guess
19:25:12 <adamw> notting: note that unfortunately we have to set the bar pretty high for X release blocker bugs, but i'll do my best to keep as many as possible on here
19:25:12 <tk009> black screen on resume has been an issue for my desktop for many releases, maybe not the same thing
19:25:20 <notting> if you know what's going on, you can unlock the display and blindly try and run xgamma. this is tricky :)
19:25:35 <adamw> ah, it's one of the gamma ones...we may already have a report for that
19:25:37 <adamw> i'll poke at it
20:17:02 <adamw> alright, time to get started up again
20:17:09 <adamw> jlaska: here?
20:17:57 <jlaska> adamw: here, but need to run an errand before 5 here ... so won't be around for long
20:18:17 <adamw> ooch, ok, let's get through what we can then
20:18:24 <adamw> Oxf13: just yell when you're back
20:18:31 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=514415
20:18:32 <buggbot> Bug 514415: medium, low, ---, ajax, ASSIGNED, X server locks up every time notification is about to be displayed
20:19:43 <adamw> this is a bit icky
20:20:03 <adamw> i suspect this particular issue is actually openchrome-only
20:20:13 <Oxf13> I'm sortof back, but still taking care of some house stuff
20:20:38 <adamw> i think we need to split up the issues of jonathan and richard
20:20:43 <adamw> since they actually seem to be different
20:20:58 <jlaska> what's richard using?
20:21:01 <adamw> intel
20:21:06 <adamw> his symptoms seem different
20:21:31 <adamw> see comments 10/11
20:22:33 <adamw> if this is two separate issues, i'd probably drop this one from the critical list
20:22:39 <jlaska> yeah
20:22:49 <adamw> since it's in openchrome, which is not one of our Three True Drivers
20:23:04 <adamw> sucks, but...we can't really hold release for it, there's a workaround (kill notification-daemon), and can be fixed in an update
20:23:19 <adamw> agreed?
20:23:21 * Bouska love the end-less meetings, it's a cool entertainment
20:23:30 <jlaska> the thinking is that we only have data to say this affects 1 person
20:23:30 <adamw> Bouska: oh, it'll end. it's just *long* :)
20:23:42 <adamw> Bouska: i'm not entirely sure why we do these meetings here, but never mind
20:23:54 <adamw> jlaska: yes, we have one sufferer of the openchrome-related bug and one of the intel
20:24:01 <adamw> i've not seen anyone else report a similar intel issue, have you?
20:24:28 <jlaska> I'd have to pull up the open xorg-x11-drv-intel bugs ... don't know off hand
20:24:48 <adamw> i'm pretty sure there aren't any other reports like that
20:24:54 <adamw> anyway, this is the openchrome bug, so let's downgrade it
20:25:03 <jlaska> no objections
20:25:09 <adamw> #agreed 514415 seems to be openchrome-related and single reporter, downgrading from blocker
20:26:52 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=514600
20:26:53 <buggbot> Bug 514600: high, low, ---, krh, ASSIGNED, Intel 82G965 requires 'nomodeset' workaround to get working text-mode
20:27:23 <adamw> this is jlaska's I Have An Awkward Intel bug :)
20:27:53 <jlaska> hehe
20:28:15 <adamw> lemme see if kristian's around
20:28:19 <jlaska> If I'm the only one ... well, that about explains it
20:29:10 <adamw> meh, X bugs are a pain in the ass to spot dupes of
20:29:17 <adamw> when the symptoms are more or less 'it doesn't work!'
20:30:05 <adamw> seems like we don't have a krh
20:30:45 <adamw> i think for now we'd best just ping krh/ajax and see what happens
20:31:10 <jlaska> yeah, I'm by no means an expert on these .. as I think you know already ;)
20:32:00 <adamw> hum, one question occurs
20:32:05 <adamw> what mode should the attached monitor be using?
20:32:20 <jlaska> how would I find out?
20:32:31 <adamw> well, what mode does it use when you boot nomodeset?
20:32:45 <adamw> actually i really ought to have looked at the logs on this one more carefully
20:32:55 <adamw> from the Xorg.0.log you posted, it looks like it fails to get the monitor EDID data
20:33:04 <adamw> which would make it fall back on defaults, which are quite conservative
20:33:18 <adamw> so it rejects most possible modes and only tries 800x600 and 640x480
20:33:22 <adamw> which may be too crappy for the monitor to deal with
20:33:43 <jlaska> ah possibly
20:33:50 <adamw> i bet if you constructed an xorg.conf which specified the appropriate monitor parameters and resolution, it'd work
20:34:42 <adamw> uff. wait. what situation was that Xorg.0.log from, exactly?
20:34:56 <adamw> it's attached in comment #9, but i can't quite tell whether you meant it was from a *working* case or a broken case
20:35:37 <jlaska> this bug appeared, fixed itself, and reappeared
20:35:53 <adamw> frankly...it'd be nice to get a 'reboot', just give us the Xorg.0.log from right now, from both working and failure cases
20:36:01 <adamw> you know how to get the log from a failure case, right?
20:36:04 <jlaska> I should have posted to current Xorg.0
20:36:05 <jlaska> yeah ... that
20:36:11 <jlaska> yup
20:36:11 <adamw> ok
20:36:16 <adamw> i'll throw a needinfo on there for you
20:36:24 <jlaska> adamw: cool, thanks
20:36:37 <jlaska> adamw: I'm sorry, I have to step out for a bit
20:36:48 <adamw> ok
20:36:49 <jlaska> wanna call it for now?
20:37:05 <adamw> meh...i'll just run through the remaining ones myself so my actions are recorded
20:37:21 <Oxf13> I'm here
20:37:25 <Oxf13> so I'll chat with you
20:37:28 <jlaska> well, it's X ... the only thing I'd do is point to the 'debug guide' anyway :)
20:37:33 <adamw> #agreed on 514600 need more info from jlaska
20:37:34 <jlaska> Oxf13: cool, thanks
20:37:41 <adamw> Oxf13: ok, cool
20:37:42 <jlaska> adamw needs company
20:37:50 <adamw> i expect a lot of 'let's ask for info and see what happens next week' anyway
20:37:57 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=521322
20:37:59 <buggbot> Bug 521322: medium, low, ---, airlied, ASSIGNED, no graphics and no console for F12-Snap1-x86_64-Live
20:38:09 <Oxf13> Snap1 was a while ago...
20:38:14 <adamw> reading through now
20:38:14 * Oxf13 reads bug
20:39:42 <adamw> seems like he only has a problem now when specifying a vga= parameter on kernel command line
20:39:45 <adamw> that's not the default, afaik
20:40:02 <adamw> i don't have on my kernel command line
20:40:21 <adamw> i think he must've stuck that in there himself at some point...it's from a pre-kms era, i think
20:41:29 <adamw> i reckon we can downgrade this one
20:42:25 <Oxf13> yeah, I agree
20:44:41 <adamw> #agreed 521322 is downgraded as it only happens with non-standard and unnecessary kernel command line parameter
20:45:14 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=521512
20:45:16 <buggbot> Bug 521512: high, high, ---, airlied, ASSIGNED, KMS: X Window Frozen with Radeon XPRESS 200M
20:45:49 <adamw> this one i'm inclined to agree with as a blocker, it's a single chipset bug but it's a pretty popular chipset, in my experience
20:46:27 <adamw> note that comment #12 suggests there's a fix in upstream kernel drm-testing tree
20:47:19 <adamw> i don't think there's much we can do on this but poke the maintainers to look at it
20:49:13 <Oxf13> k
20:49:52 <adamw> #agreed 521512 accepted as a blocker, common chipset. No action besides poking maintainers to look at bug
20:50:05 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522929
20:50:07 <buggbot> Bug 522929: medium, low, ---, airlied, ASSIGNED, repeated system crashes
20:51:25 <adamw> this is a bit icky. i'd guess at it being the pcie_aspm issue except the card it's still happening on is too old to be PCI-E
20:51:56 <adamw> i think I can ask for some more info on this one, and try to see whether the other guy has the same bug or something different
20:52:05 <Oxf13> yeah I have no clue there
20:52:12 <Oxf13> (as with most graphics bugs)
20:52:16 <adamw> =)
20:52:18 <adamw> they're nasty.
20:54:59 <adamw> #agreed 522929 hard to assess without more info and split, adamw will triage
20:55:21 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522970
20:55:23 <buggbot> Bug 522970: high, low, ---, jglisse, ASSIGNED, popup messages unreadable
20:56:08 <Oxf13> saw some more traffic on this one today
20:56:12 <adamw> i followed up on it
20:56:29 <adamw> just asking him to test with latest post-rawhide kernel build, in case any of the changes there may address it
20:56:41 <Oxf13> k
20:57:13 <adamw> this is probably droppable as it's a single-chipset bug anyway, and it's not particularly common hardware I don't think
20:57:34 <Oxf13> worksforme
20:58:10 <adamw> hum, actually...there are quite a few in smolt
20:58:11 <adamw> http://www.smolts.org/reports/view_device/Radeon%20R100%20QD%20%5BRadeon%207200%5D
20:58:22 <adamw> more than i'd have guessed
20:58:35 <adamw> a few hundred by the looks of it
20:59:17 <adamw> jlaska somehow manages to give percentages, not sure how to do that
20:59:42 <adamw> it may be good to keep it on the list for now, anyway, given that result
21:01:01 <adamw> #agreed 522970 stays on the list for now due to apparently popular hardware, adamw has posted a needinfo request
21:01:13 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523800
21:01:14 <buggbot> Bug 523800: high, low, ---, xgl-maint, ASSIGNED, X.org doesn't work on ThinkPad 600X (NeoMagic MagicGraph256ZX)
21:01:47 <adamw> the problem here is that the entire driver is broken
21:01:58 <adamw> even though it's a pretty frickin' obscure driver, that stinks to me
21:02:20 <Oxf13> meh, I don't think we should hold up the release for a really obscure card
21:02:25 <mcepl_> moreover it is pretty rare, IMHO
21:02:39 <adamw> i don't think it is a good idea to ship a release with a completely broken graphics driver, that's just dumb
21:02:51 <adamw> i would be perfectly happy if we just say 'we don't care about neomagic any more' and drop the driver
21:03:06 <adamw> which would cause systems to use VESA, but at least *work*
21:03:09 <mcepl_> can we make it use vesa or something?
21:03:16 <adamw> yes, all we'd have to do is not ship the driver
21:03:28 <adamw> Xorg auto-detection logic always falls back on vesa if no other driver is available
21:03:40 <mcepl_> I know, but that's probably not on us to decide
21:03:48 <adamw> not on who?
21:03:53 <Oxf13> it's on the X maintainer
21:04:03 <mcepl_> yeah, that's what I meant
21:04:09 <adamw> i'd say the decision of whether to fix or drop the driver is on the X maintainers
21:04:27 <adamw> but we're (partly) responsible for the quality of the release and it's certainly in our domain to say 'you've got to do one or the other'
21:04:56 <adamw> and, frankly, if they don't make a choice, to block the driver from f12
21:06:20 <adamw> wdyt, oxf13?
21:06:33 <Oxf13> I bet ajax wouldn't mind killing it
21:06:39 <adamw> no, i don't think he would :)
21:06:52 <adamw> i did own a system with a neomagic chip, once.
21:07:11 <adamw> sony vaio c1xd. it was nice. like a netbook from the year 2000. cost a freaking arm and a leg.
21:07:26 <adamw> don't think anything's been released with a neomagic in it since 2001 or 2002 at the latest
21:07:40 <adamw> anyway, are we agreed to require the X maintainers to choose to either fix or drop before release?
21:09:54 <mcepl_> or leave a driver in, but make it not default
21:10:15 <adamw> that would be somewhat more complex, but yeah, also a choice if they want to do it
21:10:23 <adamw> (it would involve a patch to the X server's auto-detection logic)
21:10:35 <Oxf13> yeah, lets leave it on the blocker tracker for that reason
21:11:28 <mcepl_> adamw: I think there are some hooks for it (I believe we had some nvidia cards forced to vesa when nouveau didn't make it with them)
21:11:58 <adamw> yes, we know how to do it, it's not a complex patch
21:12:02 <adamw> actually I could write it
21:12:08 <adamw> just _more_ complex than the other two options :)
21:12:42 <mcepl_> yeah, ask ajax/krh/airlied/whomever what they think about it.
21:12:51 <adamw> right, that's what i'll do, in a bug comment
21:13:20 <adamw> going to assign directly to ajax
21:13:25 <mcepl_> #fedora-desktop or #x
21:13:29 <mcepl_> ?
21:13:40 <adamw> this meeting's gone on for ages already, let's just get it over with :)
21:13:49 <adamw> if they don't follow up by next week we can drag them into that meeting
21:15:01 <adamw> #agreed for 523800, either driver must be fixed, dropped or made non-default for release: explain the options in bug comment and ask X team to pick one
21:15:03 <mcepl_> (as a threat?)
21:15:11 <adamw> by their hair!
21:15:18 <adamw> in chains!
21:15:23 <adamw> =)
21:15:40 <mcepl_> (that would be a tough job to drag Dave over the ocean by his hair)
21:15:43 <adamw> hee
21:15:52 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528005
21:15:53 <buggbot> Bug 528005: medium, low, ---, bskeggs, ASSIGNED, X server crash
21:16:15 <adamw> bloody macs
21:16:40 <adamw> does look like a nasty bug, i'm ok to keep it on the list
21:17:07 <adamw> btw, mcepl, it'd be awesome if you could run your clever hardware-detector over all the blocker bugs. in fact, over all bugs ever =)
21:18:45 <adamw> it looks like pretty good info is in the bug, all we can do is ping ben to work on it
21:19:55 <adamw> anything else to add?
21:20:44 <mcepl_> clever hardware detector is unfortunately completely broken for ATI bugs, because ATI's Xorg.0.log is just a pure mess
21:20:56 <adamw> ah lovely
21:21:27 <mcepl_> and it doesn't work for this bug because we don't have Xorg.0.log at all... (why? let me check)
21:21:27 <adamw> #agreed 528005 stays on the list, no action needed but pinging maintainer
21:21:39 <adamw> because it's a driver crash and the backtrace is included
21:21:53 <adamw> hence i didn't really need to ask for xorg.0.log
21:22:09 <adamw> i'd guess this one may not even be card-dependent
21:22:25 <adamw> i could test but i am unwilling to crash my X right now :)
21:22:40 <tk009> chicken
21:23:03 <mcepl_> it has in the description GeForce 8600M GT
21:24:13 <adamw> #agreed 528005 stays on the list, ping maintainer to look at it
21:24:21 <adamw> whew, only 3 left
21:24:25 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528048
21:24:26 <buggbot> Bug 528048: medium, low, ---, krh, ASSIGNED, display black after resume
21:24:41 <adamw> this is notting's, that he left a comment on - it still happens
21:24:52 <adamw> i thought we had other reports of similar issues fixed by xgamma but couldn't find any when i looked
21:25:38 <adamw> it does look worrying, especially since we seem to have a genuine reproducer on a different system ( comment #2)
21:26:28 <adamw> i think we could ask notting to pin down the 'working' and 'not working' difference a little tighter than 'with the prior week's packages it worked'
21:27:01 <adamw> anyone have anything to add?
21:28:31 <tk009> not offically, just an answer to my how this is a blocker?
21:29:10 <adamw> it's a bit on the edge
21:29:25 <tk009> resume doesnt work
21:29:30 <tk009> dont suspend?
21:29:30 <adamw> i'm mostly worried by the fact that there's a reproducer, makes me worry this could be affecting a wide range of people
21:29:41 <adamw> yeah, uh, 'don't suspend' is the same as 'my laptop is useless' for many people
21:29:44 <mcepl_> well, some of these "everything is suddenly black" should be on the list for all others
21:29:48 <adamw> i'd never take mine anywhere if it couldn't suspend
21:30:10 <adamw> may be interesting to ask if they get the same problem on a VT switch, actually...
21:30:11 <mcepl_> OTOH, we said loudly and clearly that suspend is not blocker-worthy issue
21:30:23 <tk009> yes that was my understanding
21:30:26 * adamw has always been comfortable with being a raging hypocrite :)
21:30:48 <adamw> if a few people who have intel systems chime in and say it's not happening for them i'd feel a lot more comfortable
21:31:09 <mcepl_> it is not happening to me
21:31:15 * adamw feels more comfortable
21:31:30 <adamw> Oxf13: what's your feeling?
21:31:41 <Oxf13> suspend is pretty damn important
21:31:51 <mcepl_> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
21:32:06 <Oxf13> I think I have a newer intel, 965 and it isn't broken there
21:32:06 <tk009> here is my issue, is that only on laptops?
21:32:14 <tk009> none of my machines suspend
21:32:18 <adamw> tk009: yeah, suspend is only super-important on laptops.
21:32:19 <tk009> and have not since f8
21:32:31 <mcepl_> yes, I am kind on the edge ... I would love to have suspend working (well, I have it working, most of the time and when I don't play with gnome-shell), but I understand we just don't have resources to make it so
21:32:37 <adamw> 'mobile 4 series' is newer than 965
21:33:01 <mcepl_> yes, it is bloody recent
21:33:18 <adamw> mcepl_: well, last year or so, isn't it?
21:33:22 <mcepl_> all the stuff in this computer is having pretty fresh PCI IDs ;)
21:33:24 <adamw> oh, you mean your system is recent :)
21:33:44 <adamw> notting looks to be on a 945GM
21:34:05 <adamw> so we have reports that it works on 965 and 4 series
21:34:05 <adamw> hmm
21:34:13 <Oxf13> I meant newer than notting
21:34:21 <adamw> ah
21:34:37 <adamw> i think on balance i can agree with downgrading it, given the above...
21:35:25 <adamw> tk009: a laptop with no suspend support is a real pain because you're either stuck with approx. 3 hours of life from when you turn it on, or waiting for 1 minute to turn off when you're done with it and 1.5 mins to start up when you want to use it again
21:35:36 <tk009> I have a laptop
21:35:46 <tk009> I gave up long ago on this issue
21:35:49 <Oxf13> and then another 5 minutes to get your session back where you want it
21:35:52 <adamw> you're more patient than me :/
21:35:57 <tk009> I just needed to unstand better
21:36:06 <Oxf13> Every laptop I've owned has had working suspend/resume with Fedora
21:36:12 <adamw> anyway, looks like we have a consensus to reluctantly downgrade
21:36:16 <Oxf13> then again, that's like 4 laptops
21:36:19 <tk009> if this is a valid blaocker I dont want to derail it
21:36:24 <adamw> i'll stick it on fedora-x-target
21:37:04 <adamw> no, you're right that it's not consistent to consider suspend issues blockers, as we've always released with lots of suspend bugs before. i was just a bit worried if we were breaking suspend on, like, every intel in the world.
21:38:19 <Oxf13> that would suck
21:38:27 <adamw> but appears not to be the case
21:41:32 <adamw> #agreed 528048 is downgraded to target as it's a non-universal suspend issue, ask for more details from notting
21:41:35 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528312
21:41:36 <buggbot> Bug 528312: medium, low, ---, ajax, ASSIGNED, udev takes almost 100% CPU on resume from suspend (and Xorg are to be blamed)
21:41:37 <adamw> second to last bug!
21:41:58 <adamw> oh look, it's another suspend issue
21:42:05 <adamw> filed by mcepl, you raging hypocrite ;)
21:42:34 <adamw> how's this one looking for you? it's not magically gone away like mary's, has it?
21:42:51 <mcepl_> well, I think this doesn't have to be issue -- just having computer useless for a minute or so after resume
21:42:56 <mcepl_> let it be downgraded
21:43:09 <adamw> yeah, if that's the impact, doesn't sound like a blocker
21:43:14 <mcepl_> unfortuantely no, it is alive and kicking
21:44:20 <adamw> alright, that sucks, but i think we have to downgrade it
21:45:04 <mcepl_> keep it on the target please
21:45:17 <adamw> will do
21:45:20 <mcepl_> (actually keep all downgraded Xorg blockers on target)
21:45:32 <adamw> yes, am doing
21:45:46 <adamw> alright, it's...the last bug!
21:45:55 <adamw> #agreed 528312 is downgraded as impact is not serious enough to be blocker
21:46:06 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530169
21:46:07 <buggbot> Bug 530169: high, low, ---, bskeggs, ASSIGNED, nouveau + gdm crashes
21:46:52 <mcepl_> OK, reporter asks for downgrading
21:47:03 <adamw> well, yeah, but only on the basis it can be worked around with nomodeset
21:47:11 <adamw> we haven't always downgraded on that basis
21:47:46 <adamw> i wouldn't hate keeping this, given the X list is actually quite small and ben should have time to look at it
21:47:56 <mcepl_> OK, and the analysis seems to be so good, that hopefully Ben should be able to do something about it
21:47:56 <adamw> he only has two blocker bugs at,m
21:48:01 <adamw> yep, that's my feeling
21:48:07 <adamw> three cheers for matt domsch
21:48:18 <mcepl_> he has always excellent bug reports
21:48:22 <adamw> yup
21:48:42 <adamw> and hey, it's always good to keep the hardware vendors happy :)
21:49:06 <adamw> #agreed 530169 can stay on list; borderline decision but ben's blocker workload is light and provided information is excellent so chances are high this can be fixed
21:50:01 <adamw> aaaaaand we've made it
21:50:10 <adamw> that's the whole list
21:50:13 <Oxf13> wowow
21:50:13 <tk009> well done
21:50:20 <tk009> to all of you
21:50:20 <adamw> does anyone have other business? extra bugs to propose?
21:50:43 <Oxf13> good god no
21:51:10 <adamw> =)
21:51:13 <adamw> my feelings exactly
21:51:38 <adamw> hopefully future meetings will be somewhat shorter; we've got a base for every bug now, and a lot are in MODIFIED and should hopefully be fixed by next week
21:52:57 <Oxf13> hopefully
21:53:01 <mcepl_> just a comment to  514415 (openchrome freezing on display of notification) ... I am quite sure I have never seen this before
21:53:18 <adamw> mcepl_: you have an openchrome test system?
21:53:29 * adamw doesn't
21:53:50 <mcepl_> G*d NO!
21:54:06 <mcepl_> (besides, ugly comment ... openchrome is not supported by RH engineers at all)
21:54:26 <adamw> ah i see what you mean - you haven't seen it on anything else
21:54:28 <adamw> yeah, me either
21:54:45 <adamw> well the good thing is that the fedora maintainer (xavier bachelot) is quite active so we do have a shot at getting fixes
21:55:52 <adamw> anyway
21:55:55 <adamw> let's end this hellting
21:55:59 <adamw> #endmeeting