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