15:01:30 <adamw> #startmeeting 2009-10-30 Fedora 12 blocker bug review meeting
15:01:30 <zodbot> Meeting started Fri Oct 30 15:01:30 2009 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:42 <adamw> show of hands?
15:01:49 * mclasen walks in
15:01:59 <adamw> hi mclasen
15:02:08 * iarlyy here in time
15:02:17 <adamw> hi
15:02:24 <adamw> Oxf13: jlaska: ping
15:02:46 <adamw> cebbert: denise: ping
15:03:02 <denise> adamw, pong
15:03:22 <adamw> hi denise, we'll count on you for anaconda :)
15:03:34 <denise> uhoh!
15:03:48 * poelcat here
15:03:52 <adamw> hi poelcat
15:04:42 <adamw> anyone know how jlaska gets a component-sorted list of the blockers?
15:04:48 <adamw> i can't find a 'sort by component' option
15:05:22 <adamw> oh hmm i think sort by component is the default, nm
15:05:24 <mclasen> go to buglist first ?
15:05:40 <adamw> yeah even from buglist it's not an option, but it seems to be the default
15:06:05 * cebbert is here
15:06:16 <adamw> hi cebb, we'll poke you for kernel issues
15:06:25 <Viking-Ice> for some odd reason i'm here..
15:06:29 <adamw> so, we're working from:
15:06:31 <adamw> #link http://tinyurl.com/ybhwgwn
15:07:00 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531347
15:07:02 <buggbot> Bug 531347: high, low, ---, jmoskovc, ASSIGNED, abrt eating 99% cpu
15:07:51 <adamw> so, this definitely feels blocker-y to me, when you ship a non-essential daemon that runs by default it's really really a good idea to make sure it never does this
15:08:46 <adamw> the patch appears to be: http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=commit;h=01057ae36d686d8202547b9ff45bd1635415d13c
15:09:49 <adamw> jiri seems to be online so i'll ping him for this one
15:09:51 <cebbert> http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=commitdiff;h=01057ae36d686d8202547b9ff45bd1635415d13c
15:10:48 <warren> Hmm, we aren't reporting to kerneloops.org anymore?  Seems like a loss of useful data.
15:10:51 * jlaska back
15:10:56 <adamw> hi jlaska
15:11:02 <jlaska> sorry, the list?
15:11:20 <adamw> jlaska: http://tinyurl.com/ybhwgwn
15:12:00 <jlaska> adamw: oh sorry, nm ... was wondering if you were still needing the component sorted view
15:12:20 <adamw> jlaska: seems to have come that way by default :)
15:12:44 <adamw> jmoskovc doesn't seem to be around, so i'd suggest we keep this on the list and try to get a fixed build ASAP
15:13:36 <Oxf13> I'm here.
15:13:38 <jlaska> something like this came up during the abrt test day ... and I think it was the abrt kernel oops scanner
15:13:40 <Oxf13> groggy but here.
15:13:40 <adamw> hi oxf13
15:13:49 <jlaska> Oxf13: howdy :)
15:13:49 <adamw> story of my life
15:14:14 <jlaska> anyhow, not sure what about mclasen's setup is triggering it ... but this seems like a no brainer to me?
15:14:26 <adamw> yeah, i think it's straightforward
15:14:54 <adamw> #agreed 531347 stays a blocker, try to get a patched build tagged ASAP
15:15:11 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=474225
15:15:11 <buggbot> Bug 474225: urgent, low, ---, anaconda-maint-list, MODIFIED, Touchpad doesn't work in installer
15:15:13 <mclasen> jlaska: I'm not really doing anything special... and this issue has happened often enough to me that I am concerned
15:15:25 <jlaska> mclasen: gotcha
15:15:26 <mclasen> if we are turning on abrt by default, it will hit a lot of people
15:15:33 <jlaska> agreed
15:15:53 <adamw> this is our first anaconda issue, front and center denise :)
15:16:32 <denise> so the question is are we agreed that this would be a blocker?
15:16:37 <denise> because there is a fix for it
15:16:42 <jlaska> an oldie
15:16:55 <denise> yes
15:16:59 <adamw> this one on its own feels pretty borderline to me - there's an obvious workaround (plug in a mouse) - but i think i'd want to take a fix for it if we do a new anaconda build for other reasons (which i'm guessing we will)
15:17:15 <denise> seems like a safe bet
15:17:28 <jlaska> why'd it take so long to diagnose ... lack of info?
15:17:43 <jlaska> seems to have just heated up last week?
15:17:47 <adamw> looks like info only arrived on 21st oct
15:18:16 * jlaska looks for patch
15:19:00 <adamw> when clumens says "This should be fixed in the next build of anaconda post-F12" i guess he means it was committed to f13 branch
15:19:08 <jlaska> yeah looking there ...
15:19:22 <denise> yes
15:19:33 <adamw> by the looks of the bug the patch should be pretty simple and safe i'm guessing, just adding a kernel module
15:19:34 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=849642902f9b821bd853785c27031b4b9d5e9b99
15:19:44 <jlaska> yeah that's safe
15:19:51 <jlaska> let's take it
15:20:00 <adamw> yeah, since it's a module there's not even the problem it may screw up other systems by being present since it won't be loaded
15:20:06 <adamw> +1
15:20:11 <adamw> any -1s?
15:20:24 <Oxf13> none here
15:20:38 <adamw> alright
15:20:52 <denise> ship it
15:20:53 <jlaska> thanks for patch review first ... a little extra comfort :)
15:21:11 <adamw> #agreed 474225 stays as a blocker, anaconda team will add the patch to f12 branch for next f12 build
15:21:25 <adamw> #action denise ensure patch for 474225 is added to f12 branch
15:22:06 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=493058
15:22:08 <buggbot> Bug 493058: high, low, ---, dlehman, ASSIGNED, Custom partitioning creation/edit causes traceback
15:22:12 <cebbert> for other problems with touchpads, people should try adding 'i8042.noloop=1' to the boot options
15:22:37 <jlaska> cebbert: is that common enough for us to document?
15:22:58 * jlaska recalls decision from last week on this bug
15:23:03 <adamw> i think this one's a bit of a non-starter
15:23:07 <adamw> we're not getting any further feedback
15:23:12 <jlaska> I think we decided we would move fwd if we hadn't heard from zootboy?
15:23:34 <cebbert> jlaska: it might be pretty common
15:23:57 <Oxf13> yeah
15:24:00 <adamw> cebbert: if there's a bug for that, can you CC me on it and stick CommonBugs in the keywords?
15:24:11 <Oxf13> I think this should be closed, with a comment for zootboy to file a new bug if he's hitting it with rawhide.
15:24:14 <jlaska> #idea cebbert suggested adding 'i8042.noloop=1' for touchpad related issues ... should we add to Common_F12_Bugs page?
15:24:24 <adamw> +1 to oxf13
15:24:25 <denise> 0xf13 +1
15:24:30 * jlaska takes aim
15:25:48 <adamw> #agreed 493058 appears to be fixed, no feedback from the one problematic reporter zootboy, bug will be closed
15:26:25 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=510545
15:26:27 <buggbot> Bug 510545: medium, low, ---, anaconda-maint-list, MODIFIED, RFE: encryption key escrow support
15:27:07 <adamw> not sure what's going on here
15:27:11 <jlaska> this is assigned to anaconda-maint still
15:27:28 <Oxf13> and MODIFIED so probably off the radar
15:27:38 <adamw> looks like Huzaifa added it as blocking 531407 which blocks f12blocker
15:27:46 <adamw> he only did that two days ago
15:27:53 <denise> and his issue is kickstart
15:27:54 <jlaska> I think we just need clarification from dlehman on the trailing comments on the patch submitter
15:28:10 <jlaska> adamw: oh I see that now
15:28:17 <adamw> if i'm reading correctly, then this is the same as 531407 essentially
15:28:22 <jlaska> yeah
15:28:26 <jlaska> close this and track the other?
15:28:36 <adamw> the fix we pulled into 12.41 for 531407 is the stuff from 510545 that was missed out
15:29:07 <adamw> well, the way it's set up right now is strictly correct, i don't mind it being set up this way, we just need a comment on 510545 the same as comment #3 on 531407...
15:29:58 <adamw> so this is really an administrative thing, no real need to discuss
15:30:09 <jlaska> yup ... so we just need test feedback
15:30:15 <jlaska> and can close both out, correct?
15:30:36 <adamw> actually, we probably can justifiably close 510545 already since the code has already been added - 510545 is for adding the code, 531407 is for making sure it works =)
15:30:48 <jlaska> as for whether key escrow is a blocker ... denise?
15:30:54 <adamw> so on further consideration i agree to close 510545 and point to 531407
15:30:55 <denise> no
15:32:19 <adamw> but we took the patch already...heh
15:32:58 <jlaska> target material then?
15:32:58 <adamw> #agreed 510545 can be closed as the requested patch has already been added, actual bug it caused is tracked at 531407
15:33:47 <adamw> i guess so, yeah
15:33:55 <adamw> feels slightly odd to accept the patch and then downgrade it, but n/m
15:34:16 <jlaska> yeah, it is odd
15:34:24 <jlaska> this falls a a nice to have, not a must have for me
15:34:30 <adamw> 531407 is coming up in its own right in a few bugs' time anyway, so let's discuss it then
15:34:35 <jlaska> okay
15:34:41 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=517260
15:34:42 <buggbot> Bug 517260: medium, low, ---, dlehman, MODIFIED, liveinst fails at partitioning screen
15:34:51 <jlaska> I was trying to retest this just now
15:35:01 <adamw> eeeexcellent
15:35:03 <jlaska> I confirmed the fix with a patch ... but need to confirm on a real live image
15:35:07 <jlaska> I'll have this closed today
15:35:08 <Oxf13> wewt.
15:35:16 * adamw channels Mr. Burns
15:35:35 <adamw> alright, doesn't seem like we need anything else there
15:35:45 <jlaska> twiddle those fingers Mr. Burns!
15:35:58 <adamw> #agreed jlaska is confirming the fix for 517260, he will confirm by end of today
15:36:10 <adamw> #action jlaska to retest 517260 with live image
15:36:18 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=517491
15:36:20 <buggbot> Bug 517491: medium, medium, ---, dcantrell, MODIFIED, Anaconda fails if filesystem should be shrunk
15:36:23 <adamw> the good old partition resizer
15:37:34 <adamw> seems like there's some movement, though
15:38:00 <jlaska> new patch out for review
15:38:03 * jlaska reading last comment
15:38:28 <jlaska> reporter indicates that bug#523610 is now occuring with the fix
15:38:30 <jlaska> see https://bugzilla.redhat.com/show_bug.cgi?id=523610#c5
15:38:30 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=523610 medium, medium, ---, anaconda-maint-list, CLOSED DUPLICATE, error occured during shrink install
15:38:31 <buggbot> Bug 523610: medium, medium, ---, anaconda-maint-list, CLOSED DUPLICATE, error occured during shrink install
15:38:51 <adamw> i'm not entirely sure how comment #24 was testing, is anaconda 12.42 actually up anywhere?
15:38:58 <Oxf13> updates.img perhaps
15:39:19 <adamw> i guess he could've rolled his own, but...i feel uncomfortable just assuming that's the case
15:39:20 <jlaska> not in rawhide yet
15:39:37 <adamw> i think we should ask him to clarify before unduping his bug
15:39:56 <jlaska> and did that patch get applied yet to 12.42?
15:40:15 <adamw> i think the 'fixed in version' field indicates that, aiui
15:40:23 <adamw> denise: you have any perspective on this one?
15:40:31 <jlaska> there's no 12.42 build yet
15:40:46 <jlaska> so I agree with waiting for an official build before accepting the updated results?
15:40:46 <adamw> yeah, but i believe they fill in that field to indicate it's been added to the appropriate branch
15:40:52 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=3eac92e97d13e4dbbbf3c21ecca2d293eba4d97e
15:40:56 <adamw> so it means _when_ there's a 12.42 build it will definitely include this fix
15:41:01 <jlaska> adamw: right, it's in ... just not built yet
15:41:09 <adamw> yes
15:41:10 <jlaska> yeah
15:41:26 <denise> adamw, so I should get it built?
15:41:38 <adamw> let's wait till we've been through all the anaconda bugs
15:41:42 <jlaska> denise: kudos to dcantrell ... including a link to the failing test case in the commit log!
15:41:46 <adamw> ideally we'd do one more mega-build with all the fixes in it, i guess
15:42:03 <Oxf13> well
15:42:03 <Oxf13> lets get one build today
15:42:11 <Oxf13> and see where we are at next week as we try to enter RC phase
15:42:18 <adamw> right, but let's wait till we've reviewed all anaconda bugs in case we can get everything in there
15:42:23 <jlaska> I have a few problems with the shrink test case
15:42:34 <jlaska> it's unclear what use cases we are targetting with this test
15:42:42 <jlaska> is it primarily shrinking ntfs and hfs volumes?
15:42:53 <adamw> i'm not sure that's a topic for the already-inevitably-long blocker bug meeting :)
15:43:00 <jlaska> or should this work for any physical volume?
15:43:01 <Oxf13> jlaska: I bet ntfs shinking would be pretty high on that list
15:43:08 <Oxf13> oh you already said ntfs.
15:43:10 <jlaska> adamw: agreed, just thinking outloud for the minutes
15:43:22 <jlaska> this case irks me ... since it rarely works
15:43:53 <adamw> i think ntfs is a more common case but i can certainly see the case for ext resizing
15:43:56 <jlaska> #info jlaska sees room for clarifying the use cases for
15:43:56 <jlaska> https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28shrink%29_install
15:43:56 <adamw> people switch around between distros a lot, they may need to create space
15:44:44 <jlaska> I'll take this as an action item for F-13 ... will need to create new cases for each specific use case
15:44:48 <denise> that seems to be where it typically breaks
15:45:15 <adamw> alright, anyway, we seem to be agreed on the action - we accept this as a blocker, take the patch and get it in today's anaconda build for testing
15:45:16 <adamw> right?
15:45:20 <jlaska> #action jlaska will investigate improving the autopart + shrink test cases for Fedora 13
15:45:47 <jlaska> hmmmm
15:46:09 <jlaska> getting nervous touching that code
15:46:17 <denise> always
15:46:45 <adamw> otoh...the argument cuts both ways
15:46:49 <jlaska> yup
15:46:51 <adamw> since afaics the patch only touches the ext code
15:47:07 <adamw> so i don't see how it could break resizing ntfs, for e.g.
15:47:43 <adamw> and since resizing ext appears almost never to work without the patch, it'd be pretty hard to introduce a regression...
15:48:11 <adamw> am I being too blase? :)
15:48:15 <jlaska> nah
15:48:49 * adamw always takes that into consideration when doing blocker review, btw...if whatever you're trying to fix is completely stuffed it's pretty hard to cause a regression =)
15:49:05 <adamw> not impossible, just hard.
15:49:10 <mclasen> you can still cause regressions elsewhere...
15:49:10 <jlaska> fair point ... shrink kind of sucks
15:49:17 <jlaska> so as long as this just affects shrink code
15:49:31 <adamw> mclasen: yeah, but see above. afaics the patch only touches code that is used when you're resizing an ext* partition
15:49:39 <adamw> denise: does that sound right?
15:49:59 <mclasen> adamw: of course, evaluation that is what this meeting is all about...
15:50:06 <adamw> yup
15:50:09 <denise> yes
15:50:25 <jlaska> alrighty
15:50:30 <adamw> i'd say we can take it on that basis, then...votes?
15:50:49 <jlaska> agreed
15:50:58 <Oxf13> sure
15:52:09 <adamw> ok. #agreed on 517491: since the patch only touches the ext* resize codepath and resizing ext is mostly broken without it, accepted on the basis it's very unlikely to cause regressions
15:52:11 <adamw> erf
15:52:14 <adamw> #agreed on 517491: since the patch only touches the ext* resize codepath and resizing ext is mostly broken without it, accepted on the basis it's very unlikely to cause regressions
15:52:34 <adamw> don't think any action's needed since the patch is committed already.
15:53:12 <adamw> #agreed on 517491: ask arenas belon to be more clear on how claimed testing wiht 12.42 was done before unlinking that report
15:54:15 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526789
15:54:15 <buggbot> Bug 526789: medium, low, ---, clumens, MODIFIED, Install didn't reboot at the end
15:54:20 <jlaska> #info I believe just waiting for the next build to test
15:55:09 <adamw> yeah, seems OK for me
15:55:12 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=9bfe661b0e69d1aa87ecbeb5b9f5a88ddb6cc931
15:55:23 <jlaska> this is one of those cosmetic issues I proposed for addition
15:55:37 <jlaska> not a high severity issue, but I'm seeing enough comments about this
15:55:38 <adamw> er, whut? that git link doesn't seem relevant
15:55:46 <jlaska> it is
15:55:49 <adamw> oh, i see
15:55:57 <jlaska> just obscure title
15:57:03 <adamw> patches look pretty safe to me
15:57:19 <adamw> (the renowned code expert, heh)
15:57:30 <jlaska> heh, you're better than I am
15:57:39 <adamw> if that's true then we're ALL in trouble
15:58:00 <thomasj> lol
15:58:16 <adamw> so, we accept this one and jlaska gets to test with next anaconda build?
15:58:47 <adamw> #agreed 526789 stays on the list, fix will be in 12.42
15:58:58 <adamw> #action jlaska to test 526789 when next anaconda build is done
15:59:05 <jlaska> thx ... beat me to the #action
15:59:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526925
15:59:11 <buggbot> Bug 526925: low, low, ---, clumens, MODIFIED, [Back] button does not have a corresponding icon (like [Next] does)
15:59:17 <jlaska> same type of issue
15:59:24 <adamw> the other jlaska polish issue
15:59:26 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=78486c9dd278632b55c004dda6534656793cfd58
15:59:43 <jlaska> I think this is related to the new icons we got in anaconda a while ago
15:59:57 <jlaska> or some other change where you need to be explicit about what icon to show on a widget?
16:00:00 <adamw> trying to think what could go horribly wrong here
16:00:03 * jlaska speaking without any knowledge
16:00:05 <Oxf13> I think mccan filed a couple anaconda polish bugs recently, not sure if they're on the list or not
16:00:15 <adamw> the code's presumably exactly the same as for the button which does have an icon?
16:00:25 <adamw> (with the obvious different icon name)
16:00:28 <jlaska> so the fall out ... you have a [Next] button with an arrow on the live install, but the [Back] button doesn't
16:01:31 <jlaska> fwd button glade - http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=ui/anaconda.glade;h=296458e6b33fc5ebdadc32efcca85c25935642a5;hb=78486c9dd278632b55c004dda6534656793cfd58#l269
16:01:47 <jlaska> back button glade - http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=ui/anaconda.glade;h=296458e6b33fc5ebdadc32efcca85c25935642a5;hb=78486c9dd278632b55c004dda6534656793cfd58#l203
16:02:10 <adamw> so yeah, what could possibly go wrong
16:02:12 <adamw> =)
16:02:16 <jlaska> one thing jumps out
16:02:27 <jlaska> 315                               <property name="label" translatable="yes">_Next</property>
16:02:33 <jlaska> vs
16:02:34 <jlaska> 240                               <property name="label">_Back</property>
16:02:58 <jlaska> denise: not sure if that matters, but can clumens comment on that?
16:03:15 <denise> will get him ...
16:03:25 <jlaska> aside from that they look the same
16:03:28 <adamw> i think it would mean the text on the bug never got translated
16:03:33 <adamw> so it'd say Back in any language
16:03:47 <adamw> er, text on the button
16:03:47 <jlaska> right
16:03:57 <adamw> probably worth fixing
16:04:15 * mclasen would use stock buttons there, to fix both the translation and the icon issue
16:04:58 <adamw> that sounds like an f13 change...
16:05:04 <jlaska> clumens: hey Chris ... looking at that glade patch for the back button
16:05:12 <clumens> jlaska: okay.
16:05:19 <jlaska> comparing the back and the forward buttons
16:05:27 <jlaska> [Oct 30 12:02:27] <      jlaska> |  315                               <property name="label" translatable="yes">_Next</property>
16:05:31 <jlaska> [Oct 30 12:02:33] <      jlaska> | vs
16:05:33 <jlaska> [Oct 30 12:02:34] <      jlaska> |  240                               <property name="label">_Back</property>
16:05:51 <jlaska> is Back one of those universally translated fields?  Or should that also have translatable="yes" ?
16:06:01 <mclasen> adamw: in F13, we'll have a much deeper look at anacondas ui issues, much earlier...
16:06:45 <clumens> jlaska: it should *probably* have translatable=yes, but i see it's in a ton of .po files so it's probably okay for now.
16:07:29 <mclasen> clumens: if it doesn'thave translatable, having the string in po files won't help...
16:07:37 <adamw> mclasen: sounds good
16:07:56 <adamw> right, translatable is what makes it go and look for the translation in the .po file, isn't it?
16:08:26 <mclasen> yes
16:08:29 <jlaska> clumens: would it have been translating the "_Back" button prior to me asking for this fix  (egg on me)
16:11:21 <adamw> well, for the purposes of the meeting, let's treat it like the other one
16:11:36 <adamw> we're taking the fix...if the translatable property should be added then add it
16:11:40 <adamw> sound good?
16:11:58 <clumens> jlaska: we didn't have translatable="yes" in there before, so only if it's some side effect of it being label=gtk-go-back or use_stock=True.
16:12:54 <jlaska> clumens: you okay with adamw's suggestion?
16:13:09 <mclasen> yes, stock buttons are translated
16:13:15 <mclasen> using trranslations from gtk
16:13:33 <mclasen> thats why I would prefer to use stock buttons there...
16:14:28 <jlaska> whatever is the least invasive change here ... I think it makes sense to at least have a matching icon on the button for RC
16:15:26 <adamw> #agreed 526925 stays on the list, same as 526789, fix should be in next anaconda build
16:15:38 <adamw> #action anaconda team to ensure fix for 526925 keeps translations for the back button
16:16:05 <adamw> #action jlaska to re-test 526925 with next anaconda build, including testing in Swedish to make sure the button is translated
16:16:12 <adamw> note ONLY SWEDISH TESTING IS ACCEPTABLE
16:16:14 <adamw> hurdy-gurdy
16:16:18 <jlaska> :)
16:16:27 <jlaska> I look forward to that
16:16:39 <adamw> there totally ought to be a Swedish Chef translation of fedora
16:16:46 <Oxf13> BORK BORK BORK
16:17:03 <Oxf13> only if we bring back the redneck translation
16:18:02 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528317
16:18:03 <buggbot> Bug 528317: high, low, ---, anaconda-maint-list, MODIFIED, anaconda traceback in getDefaultTimeZone KeyError en_AU
16:18:28 <adamw> this is the locale issue, fix already went in, kinda disappointed we didn't get testing yet...
16:19:05 <clumens> so i'm adding translatable="yes" there?  okay.
16:19:34 <adamw> the hive so directs, yes
16:19:40 <clumens> LIVE TO SERVE
16:19:41 <clumens> etc.
16:19:45 <mclasen> sounds good
16:19:50 <jlaska> clumens: danke
16:19:56 <clumens> am i needed for anything else here?
16:20:08 <jlaska> clumens: sorry, I didn't catch that earlier when looking at the patch
16:20:15 <clumens> no problem
16:20:32 <jlaska> clumens: nope, think you're good
16:20:56 <adamw> anyone want to volunteer to re-test 528317? if not i guess i'll do it since i know the procedure now
16:21:15 <jlaska> I can add to my list as well
16:21:23 <jlaska> I have a few that I need to take a pass at
16:21:39 <jlaska> so live image, and select a different lang
16:21:54 <adamw> yeah, that's the bit i missed before, pick a different language before installing (at gdm screen i guess)
16:22:03 <jlaska> okay, I can take that
16:22:13 <adamw> one of the locales known to have trouble, like australian or british english
16:22:52 <adamw> #agreed 528317 still a blocker, needs re-testing
16:22:57 <adamw> #action adamw and jlaska to re-test 528317
16:23:11 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=529267
16:23:14 <buggbot> Bug 529267: medium, low, ---, anaconda-maint-list, ASSIGNED, Better label + icon for the installer on the live cd
16:23:23 <jlaska> I believe this is the issue mccann raised on fedora-devel
16:23:37 <jlaska> and I think we can move this to MODIFIED and CLOSED really
16:23:41 <adamw> um
16:23:46 <jlaska> I'm seeing this with the latest livei mages already
16:23:51 <adamw> not necessarily
16:23:56 <jlaska> more change a'coming?
16:24:04 <adamw> it was 'fixed' one way then that was discovered to cause the problems that icons couldn't possibly cause :)
16:24:06 <adamw> so it was changed
16:24:19 <adamw> aiui it now needs a corresponding change in anaconda; i don't know if that's gone in yet
16:25:06 <adamw> at first they tried to fix it by changing the stock icon anaconda previously used. but then it turned out something else used the same icon, and the new design didn't make any sense for that use
16:25:23 <adamw> so it was decided to revert the stock icon and create the icon for anaconda as a new one named anaconda.png/svg
16:25:34 <adamw> so i believe anaconda now does need to be changed to use that icon name
16:26:03 <Oxf13> and that change hasn't been done yet IIRC
16:26:04 <jlaska> aha, thanks for the details on that
16:27:08 <adamw> so we should assign this to someone in anaconda team...denise?
16:27:58 <jlaska> there's the whole .. is this a blocker.  Was there already consensus here?
16:28:16 <adamw> well if we're taking your polish issues it's only fair to take this one =)
16:28:26 <jlaska> right ... not discounting it
16:28:35 <jlaska> just want to get the rationale for each in the minutes
16:29:02 <jlaska> I think we still need to make a case for each ... it did find additional issues for the last one
16:29:36 <adamw> the rationale is basically that the previous icon was unclear, AIUI
16:30:26 <jlaska> are we just changing the icon?  or also the text on the .desktop file
16:30:42 <Oxf13> It's not a blocker, however I'd take the change.
16:30:52 <wwoods> can I grumble about how the previous icon/wording has been unclear for at least a year now, but nobody has bothered to propose a change until now?
16:31:01 <adamw> the text would be complicated by string freeze wouldn't it?
16:31:04 <wwoods> or have we used up our curmudgeon quota for the dya
16:31:09 <adamw> wwoods: i heartily support this product and/or grumble
16:31:11 <jlaska> adamw: yeah, that's where I was thinking
16:31:24 <jlaska> wwoods: as long as it doesn't lead to foamy ...
16:31:32 * jlaska still laughing
16:31:39 <Oxf13> just because nobody complained about it doesn't mean there were dissenting opinions about it
16:32:00 <adamw> wwoods: however, i think the idea that post-beta is the _ideal_ time to do misc. polishing fixes is widespread, so we need to make it more clear that that's not what's supposed to happen in the release cycle documentation...but that's a discussion for another location i think
16:32:23 <jlaska> so .. who has the ball here, mclasen or anaconda-maint?
16:32:42 <Oxf13> well the change has to go into anaconda to fix this, so anaconda-maint
16:32:49 <wwoods> that suggestion is OK for the previous (incorrect) definition of Beta, but with our new definition of Beta the proper time for polish is post-Alpha
16:32:51 <denise> so we dont have a fix in hand for this - would you rather get a build with all the fixes we DO have, or wait for this?
16:33:11 <Oxf13> denise: it should be a 5 minute patch job no?
16:33:51 <denise> maybe
16:34:23 <jlaska> wwoods: adamw: I think mizmo has some schedule changes she was looking to address @ FUDCon w/ poelcat.  That might be a good time to get it on that radar?
16:34:37 <adamw> if it involves waiting then i'd say forget it, but i suspect you'll have time to get the fix in before we're through all the anaconda bugs...
16:36:16 <adamw> so, we accept a fix for 529267 as long as it doesn't delay the next anaconda build?
16:36:48 <jlaska> agreed
16:37:07 <adamw> #agreed 529267 can be fixed as a significant polish issue as long as the fix doesn't delay the next anaconda build
16:38:01 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531052
16:38:04 <buggbot> Bug 531052: medium, high, ---, dlehman, MODIFIED, [anaconda] Live: Error processing drive: /dev/dm-0
16:38:20 <jlaska> I tested this as a patch yesterday and confirmed the fix
16:38:30 <jlaska> of course, will need to confirm against a anaconda-12.42 based live image
16:38:40 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=080f12b6d4ee86c689d930a3705a7e277f337516
16:39:07 <adamw> but looks good so far? ok
16:39:12 <jlaska> yup
16:39:23 <jlaska> I think this patch might be related too (for the logs)
16:39:23 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=447db7bf1f6c2fbb682040bc206fe1006fb54234
16:39:28 <jlaska> could be wrong though
16:39:55 <adamw> and it's a pretty no-brainer blocker, can't have nasty errors popping up in the installer.
16:40:02 <adamw> jlaska: it is, as per comment #13
16:40:11 <jlaska> yeah, I think this is a must
16:40:17 <adamw> ok, seems straightforward
16:40:21 <jlaska> not sure how it was introduced
16:40:42 <adamw> #agreed 531052 is a blocker, fix will be in next anaconda build for testing
16:40:50 <adamw> #action jlaska to re-test 531052 with next live build
16:41:39 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=531381 is just the anaconda blocker bug itself, no need to look at it
16:41:40 <buggbot> Bug 531381: medium, low, ---, anaconda-maint-list, NEW, F12 Anaconda Blocker Bug
16:41:46 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531407
16:41:48 <buggbot> Bug 531407: high, high, ---, anaconda-maint-list, MODIFIED, --encrypted option does not work with pv in kickstart script
16:41:57 <jlaska> adamw: and this is part#2 right?
16:42:06 <adamw> last anaconda blocker, this is the other half of the one we discussed earlier
16:42:07 <adamw> yes
16:42:26 <adamw> so we were proposing to drop this to Target, essentially meaning that if the fix isn't actually a fix we won't mess with it further
16:42:33 <adamw> (and presumably if the fix causes any problems we just revert it)
16:43:17 <jlaska> yeah, I think that was the case
16:43:32 <jlaska> as I understand it ... this is a kickstart only issue
16:43:50 <adamw> denise doesn't consider this functionality blocker-worthy
16:44:12 <denise> for fedora necessarily - but would be good to have the complete fix
16:44:25 <denise> and the submitter certainly considers it blocker-worthy ;-)
16:44:40 <adamw> heh
16:44:40 <denise> jlaska, does it affect your test environment?
16:45:25 <jlaska> for fedora, we don't have any mature tests are kickstarting with key escrow
16:45:42 * jlaska reexamines patch
16:46:16 <jlaska> yeah, this would be something we could look at once we have automation in place
16:46:31 <jlaska> but we don't have anything now that would be impacted by --escrowcert
16:46:40 <jlaska> (shame ... would be nice if it did impact us)
16:47:16 <adamw> decision!
16:47:47 <jlaska> moving to target, already built and included?
16:48:00 <adamw> fine by me
16:48:06 <denise> yes
16:48:25 <adamw> #agreed 531407 drops to target, but fix stays in since it's there already
16:50:31 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530603
16:50:33 <buggbot> Bug 530603: medium, low, ---, krh, MODIFIED, Loads of "unknown actions" in GNOME keybindings
16:51:05 <adamw> looks like mclasen's in on this one
16:51:29 <adamw> mclasen: you set it to modified...
16:52:46 <adamw> i think we bored mclasen to death :)
16:53:37 <adamw> investigating where the fix is now
16:55:26 <adamw> compiz-gnome...
16:56:10 <adamw> fix is http://koji.fedoraproject.org/koji/buildinfo?buildID=139026
16:56:15 <adamw> which has been tagged for final: https://fedorahosted.org/rel-eng/ticket/2912
16:56:17 <adamw> so we can set to modified
16:56:41 <adamw> er, i mean, we can confirm
16:57:42 <jlaska> heh, yeah I guess MODIFIED it is
16:58:18 <adamw> it seems fine to me
16:58:30 <adamw> i don't see any bad-looking entries in gnome-keybinding-properties
16:58:52 <adamw> i'd say we can close it
16:59:23 <jlaska> I don't have any opinions on this one ... but seems like the wheels are well in motion
16:59:24 <adamw> even the opacity ones mentioned as problematic in comment #1 are OK here
16:59:45 <Oxf13> well, you shouldn't see Increase or Decrease when running metacity
17:00:17 <adamw> that's not really the same bug, though, i don't think
17:00:21 <adamw> and doesn't seem like a blocker
17:01:12 <Oxf13> er, I thought the whole point was to prevent seeing keybindings for the wrong desktop
17:01:33 <adamw> no...the bug describes the problem as seeing lots of 'unknown action' entries
17:01:37 <Oxf13> ah
17:01:46 <Oxf13> that's different from the conversation mclasen and I had about it
17:01:57 <Oxf13> brb, wireless module just took a shit.
17:02:12 <adamw> Oxf13: i think we'd want a separate bug for that
17:02:16 <adamw> this one seems pretty definitely fixed
17:02:48 <Oxf13> k
17:03:13 <adamw> so, i propose we close this as RAWHIDE, please open a new bug for the 'inappropriate bindings shown for the running wm' issue...any -1s?
17:03:25 <Oxf13> nope
17:03:47 <jlaska> nope
17:03:57 <adamw> alrighty
17:04:13 <adamw> #agreed 530603 can be closed, the bug is fixed (verified by adamw)
17:04:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528909
17:04:34 <buggbot> Bug 528909: medium, low, ---, davidz, NEW, DevKit 95-devkit-disks.rules should avoid scan all DM devices
17:04:53 <jlaska> so I think this is a follow-on to another anaconda issue we discussed a while back
17:05:00 <jlaska> where the udev rules needed updating
17:05:15 <adamw> yeah, but seems to be more complex than we grokked
17:05:25 <jlaska> if I understand correctly, they're trying to remove those annoying error when using a passphrase to unlock a partition?
17:05:48 <jlaska> which ideally ... you'll never see those msgs (graphical boot) ... but still
17:06:09 <jlaska> this seems a bit invasive to me at this point, others?
17:06:11 <adamw> i'm honestly not entirely sure what's going on here now
17:06:51 <adamw> it'd be nice if we could get david to explain, bits of this bug are causing me to glaze right over :)
17:07:00 <jlaska> yeah
17:07:09 <adamw> i'll ping davidz, just a tick
17:07:12 <jlaska> k
17:10:02 <adamw> hmm, no response
17:10:11 <adamw> yeah, i'm really kinda floundering on this one, not sure what the impact is or anything
17:10:45 <jlaska> if it is just trying to address those messages ... I think I'd need more info to feel comfortable mucking w/ udev rules
17:10:57 <Oxf13> this might have something to do with booting a live image and getting prompted to unlock encrypted volumes on the harddrive
17:11:06 <jlaska> but ... should we toss in a request for a 'caveman' explanation in the bz?
17:11:08 <Oxf13> at least I think that was the source of complaint recently
17:11:24 <adamw> the comments claim https://bugzilla.redhat.com/show_bug.cgi?id=520913 is related
17:11:26 <buggbot> Bug 520913: urgent, urgent, ---, mbroz, NEW, pvmove fails, leading to total loss of logical volumes
17:11:30 <adamw> that one has a real problem by the looks of it
17:11:36 <adamw> 'total loss of logical volumes' does not smell rosy
17:11:57 <adamw> Oxf13: that one's been fixed
17:12:22 <jlaska> so ... needinfo?
17:12:25 <adamw> Oxf13: it was fixed by passing appropriate parameters to dracut when building live images
17:12:43 <Oxf13> k
17:12:47 <adamw> if no-one here has a better handle on this than me, then yeah, needinfo
17:12:51 <jlaska> mbroz is around
17:12:53 <jlaska> shall I grab him?
17:12:56 <adamw> sure
17:13:38 <jlaska> okay ... joining shortly ...
17:15:19 <jlaska> nm ... mbroz is directing me to someone else ... still chasing ...
17:15:46 <jlaska> I vote we move on and work this out of meeting
17:16:02 <Oxf13> +1
17:16:05 <adamw> ok
17:16:33 <adamw> #agreed 528909 impact is unknown, need to ascertain what the consequences of the bug are to decide on its status
17:16:43 <adamw> #action jlaska to track down someone who can provide info on 528909
17:16:52 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=498968
17:16:54 <buggbot> Bug 498968: medium, low, ---, markmc, NEW, Fedora 12 Virtualization Target Blocker
17:16:54 <jlaska> I'm just going to add a comment to the bz
17:17:07 <adamw> oh, this is the virt tracker, moving on...
17:17:18 <adamw> #agreed 498968 is the virt tracker bug, no need to look at it directly
17:17:27 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528097
17:17:43 <buggbot> Bug 528097: medium, low, ---, lvm-team, MODIFIED, /sbin/dmraid needs possibly unmounted /usr/lib
17:17:59 <adamw> we agreed last week to close this as fixed if no feedback had been received
17:18:02 <adamw> so let's just go ahead and do that
17:18:14 <adamw> 1.  AGREED: 528097 is probably fixed, still waiting on feedback, close at next meeting if no feedback received by then (adamw, 18:26:52)
17:18:19 <adamw> (from last week's log)
17:18:50 <adamw> #agreed 528097 is closed as fixed as per agreement at last week's meeting to close it if no further feedback was received
17:18:53 <jlaska> yup, it's time has come
17:19:02 * jlaska rings a bell
17:19:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530320
17:19:33 <buggbot> Bug 530320: high, high, ---, clumens, NEW, firstboot errors when loading modules
17:20:01 <adamw> we were using this as a tracker and the dependent bugs have been closed, so we can close this I believe
17:20:16 <jlaska> both dependent issues are CLOSED
17:20:25 <jlaska> https://bugzilla.redhat.com/show_bug.cgi?id=530700
17:20:27 <buggbot> Bug 530700: high, high, ---, mmcgrath, CLOSED CURRENTRELEASE, firstboot errors when loading modules:  no module rhpl.iconv
17:20:32 <jlaska> https://bugzilla.redhat.com/show_bug.cgi?id=530698
17:20:33 <buggbot> Bug 530698: high, high, ---, psatpute, CLOSED NEXTRELEASE, firstboot errors when loading modules: language module
17:20:46 <adamw> any -1s to closing this?
17:21:04 <jlaska> none here
17:21:33 <adamw> #agreed 530320 can be closed, was used as a tracker for two other bugs that are closed
17:22:06 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=512944
17:22:07 <buggbot> Bug 512944: high, low, ---, jmccann, MODIFIED, fast-user-switching locks up login screen
17:22:18 <jlaska> looks like still waiting on feedback from your call to testing
17:22:24 <adamw> yeah
17:22:29 <adamw> i need a bigger whip
17:22:56 <adamw> this does seem like a bug that affected just about any setup, or at least a high proportion, so we could probably reproduce and confirm the fix if we tried
17:23:55 <adamw> and by we i mean 'somebody else' =) ok just kidding, i can give it a shot probably
17:24:06 <jlaska> heh, I was thinking the same thing :)
17:24:50 <adamw> i'll also ping the bug
17:25:04 <jlaska> if I run out of bugs to test, I'll grab this as well
17:25:38 <adamw> #agreed 512944 needs re-testing
17:25:50 <adamw> #action adamw, jlaska to test 512944, adamw to ping bug for community re-testing
17:26:03 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=527920
17:26:04 <buggbot> Bug 527920: high, low, ---, jmccann, ASSIGNED, gdm doesn't show user list and crashes - unable to login
17:26:25 <jlaska> waiting for confirmation from Dominik?
17:26:40 <adamw> yeah...we had two 'it's working!' messages and one 'it ain't working' message
17:27:14 <adamw> dominik is usually not crazy so i'd want to keep this open until we figure out what's going on
17:27:24 <jlaska> no objections
17:28:06 <adamw> will ping again for his info
17:28:28 <adamw> #agreed 527920 stays on the list as we want to clear up what's happening with Dominik who reports it as not yet being fixed
17:29:13 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531423
17:29:14 <buggbot> Bug 531423: low, low, ---, jmccann, MODIFIED, double-spacing in language and keyboard dialogs
17:29:24 <jlaska> hey, I just saw this while testing that en_GB bug
17:29:40 <jlaska> straightforward I think ... just waiting on testing the new build?
17:29:40 <adamw> there's a supposedly-fixed build but it's not tagged yet
17:30:04 <adamw> yeah
17:30:04 <jlaska> so blocker worthy?
17:30:04 <jlaska> meh
17:30:06 <adamw> i think we should be able to knock this off after the meeting (or during if someone has a spare box)
17:30:18 <adamw> it's another polish issue...personally i wouldn't consider it blocker worthy...
17:30:27 <jlaska> yeah, 'nice to have' for me
17:30:31 <adamw> but then i don't see any value in making it a 0-day update either so i'd say we could tag the fix in
17:30:35 <jlaska> so as long as the change is harmless
17:31:15 <adamw> well for this meeting's purposes let's just say we're dropping it from the blocker list
17:31:28 <jlaska> yeah I like that
17:31:30 <adamw> up to halfline and releng whether to request a tag and accept it (respectively)
17:31:44 <adamw> anyone want to argue for this as a blocker?
17:31:50 <ciupicri> is there a field for putting a link to the upstream bug (tracker) if the project is not GNOME, KDE, Apache?
17:32:03 * jlaska checking who added it
17:32:07 <jlaska> ciupicri: there is
17:32:13 <adamw> ciupicri: 'external bugs'
17:32:17 <adamw> ciupicri: it has a range of other trackers
17:32:23 <adamw> if it's not listed there you can't do it, though
17:32:33 <jlaska> adamw: maybe jens added this when it was filed from the i18n test day
17:32:36 <ciupicri> adamw, yes, that was the problem
17:32:51 <adamw> ciupicri: if you want another tracker added to the list i think you can file that as a request
17:32:51 <ciupicri> adamw, jlaska : here's the relevant upstream bug https://fedorahosted.org/cobbler/ticket/523 (it means BZ)
17:33:12 <adamw> upstream bug for what?
17:33:29 <ciupicri> adamw, the RH bugs are mentioned there
17:33:31 <adamw> oh i see
17:33:45 <jlaska> bugzilla-owner@redhat.com
17:33:45 <ciupicri> adamw, I was too lazy to copy them here :-)
17:34:14 <ciupicri> so can something be done in this case or not?
17:34:16 <adamw> #agreed 531423 is not a release blocker, downgrading to target: ray is still welcome to file a tag request to have the fix included in final, up to releng whether to accept
17:34:30 <adamw> ciupicri: as i said, contact the bugzilla maintainer and ask him to add the tracker to the available list
17:34:35 <adamw> ciupicri: jlaska just gave you the address
17:34:43 <jlaska> ciupicri: if you'd like to request changes to bugzilla.redhat.com, I believe you can file a bug against bugzilla (in bugzilla) ... or the address above I provided
17:34:43 <ciupicri> adamw, ok, just wanted to be sure
17:35:11 <ciupicri> got that; thank you
17:35:44 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531339
17:35:45 <buggbot> Bug 531339: medium, low, ---, pjones, NEW, /sbin/installkernel isn't right for dracut
17:35:58 <jlaska> this seems obvious, but wondering why no one has seen it yet
17:36:21 <adamw> well - under what circumstances is grubby used to generate initrds?
17:36:41 <jlaska> kernel %postinstall scripts
17:36:41 <cebbert> because very few people build upstream kernsl oustide of rpmbuild
17:36:56 <jlaska> # rpm -q --scripts kernel| grep mkinitrd
17:36:56 <jlaska> /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --install 2.6.31.1-56.fc12.i686 || exit $?
17:36:59 <jlaska> /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --install 2.6.31.5-96.fc12.i686 || exit $?
17:37:04 <jlaska> this seems to be fixed no?
17:37:19 <jlaska> err wait, might be looking in wrong spot
17:37:33 <adamw> that just looks like the rpm specfile uses the correct parameters explicitly
17:37:38 <jlaska> ignore me
17:37:46 <adamw> i think the bug here is that grubby defaults to mkinitrd rather than dracut?
17:37:49 <jlaska> yup
17:37:59 <cebbert> we also have a report that erasing kernels doesn't erase the initrd; hopefully that's fixed
17:38:04 <adamw> but if we're calling it explicitly with correct parameters in the most important use case, i am unconvinced that this is a blocker
17:38:24 <cebbert> true
17:38:24 <Oxf13> I wouldn't slip the release due to this issue
17:38:30 <Oxf13> I wouldn't turn down a fix for this issue
17:38:46 <adamw> notting's around, let's ask him if we're missing something...i'll ping him in -devel
17:40:44 <adamw> <notting> adamw: running 'make install' on a kernel tries to use mkinitrd to build the initramfs
17:40:44 <adamw> <notting> also, it's s trivial fix
17:41:00 * mclasen was out for lunch, sorry if I missed a question
17:41:26 <adamw> don't think you missed anything vital
17:41:32 <mclasen> ok
17:41:36 <cebbert> 'make install' calls /sbin/installkernel directly
17:41:49 <jlaska> so this affects folks testing kernel compiles?
17:42:10 <adamw> i'm still not seeing it as a blocker.
17:42:22 <adamw> cebbert: so fixing this bug wouldn't actually fix make install anyway?
17:42:53 <adamw> oh yes it would, sorry, misparsed
17:42:53 <Oxf13> (we've probably spent more time talking about this than it would take to fix it)
17:42:58 <adamw> heh.
17:42:59 <Oxf13> punt it from blocker to target.  Lets move on
17:43:03 <adamw> +1
17:43:04 <jlaska> +1
17:44:25 <adamw> #agreed 531339 drops to f12target, jesse will accept a tag request to fix it if filed
17:44:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=529982
17:44:34 <buggbot> Bug 529982: medium, low, ---, tbzatek, NEW, [abrt] crash detected in gvfs-1.4.0-6.fc12
17:44:37 <jlaska> I think we can remove this from the list
17:44:56 <jlaska> no details yet on the frequency of the problem
17:45:04 <adamw> yeah it's pretty not-enough-info'y
17:45:14 <jlaska> any objections to removing for nwo?
17:45:16 <jlaska> now
17:45:54 <adamw> i'm just looking at a couple of other abrt gvfs bugs to see if they're dupes
17:46:04 <jlaska> good thinking
17:47:25 <adamw> no, they don't look like it, they seem to be in different places, from the backtraces
17:47:37 <adamw> so +1 to dropping this
17:48:04 <adamw> #agreed 529982 does not have enough info to accept as a blocker, and there do not appear to be any other duplicate reports indicating it's not a common problem
17:50:40 <adamw> jlaska: quick note - davidz just pong'ed me on the complex bug from earlier, i told him you have the action item to follow up on it
17:50:59 <adamw> Oxf13: still want that breakfast break?
17:51:07 <Oxf13> please
17:51:12 <jlaska> adamw: I posted to the bz
17:51:17 <Oxf13> although at this point it's brunch
17:51:18 <adamw> alright
17:51:20 <jlaska> adamw: I'll ping him shortly andask to follow-up in bz
17:51:23 <adamw> 15 mins?
17:51:27 <jlaska> +1 :)
17:51:29 * jlaska needs lunch
17:51:35 <adamw> ok, back at 5 past THE TIME IN YOUR REGION
17:51:50 <adamw> (thank you craig ferguson)
18:02:58 * cebbert awaits the puppet show
18:05:25 <adamw> alright, we're back on
18:05:45 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=505100
18:05:46 <buggbot> Bug 505100: medium, medium, ---, tagoh, ASSIGNED, need xinput conf file for XIM to enable X locale compose maps
18:06:40 <jlaska> I think the last comment puts this on target?
18:07:05 <jlaska> "though it is getting rather late for f12-final...
18:07:05 <jlaska> It might be more realistic to target day-zero updates to
18:07:05 <jlaska> not risk destabilizing and further delaying the release
18:07:05 <jlaska> at this stage:"
18:07:18 <adamw> well, that's one opinion, there's quite a few people on the bug
18:08:11 <rosset> because this is a big problem for Brazilian users
18:08:18 <rosset> ' + c is very used on Brazil
18:08:29 <adamw> Marko seemed interested in joining the meeting to talk about this, i'm talking to him on internal IRC but he isn't coming in here yet though i told him where we are
18:08:37 <adamw> i think what i'd most be worried about here is what happens during install
18:08:53 <adamw> are the X or GTK+ rules used during install, does anyone know? rosset?
18:09:16 <rosset> i don't
18:09:24 <adamw> if the 'good' rules are used during install at present, then i'd be fine with a 0-day update, as you can do updates without really needing to type anything
18:09:30 <rosset> default gnome install with pt_BR and us_intl keyboard
18:09:51 <adamw> but if the 'bad' rules are currently used during install and we need to fix this bug to solve that, i'd want it fixed for release, otherwise we'll have lots of bad experiences in the installer
18:09:52 <rosset> but i don't know about rules
18:09:59 <myllynen> i mentioned finnish one affected locale as well but for that case it's definitely not a blocker material
18:10:20 <adamw> rosset: i mean, when you do an install of Beta (or a current live image), do you get the good behaviour or the bad behaviour during the install process?
18:10:24 <adamw> myllynen: can you answer that one?
18:10:39 <rosset> adamw, bad
18:10:49 <adamw> mmmff. i'm thinking about things like entering names and passwords
18:10:52 <myllynen> yep, bad one i'd presume
18:11:12 <rosset> never work ' + c without manual intervention
18:11:15 <adamw> myllynen: and most users just won't be expecting this at all, right?
18:11:46 <myllynen> brazilians no, according to comments on bz
18:12:20 <adamw> see i'm worried about, say, Brazilians who have a ç in their name or want to put one in their password or whatever
18:12:25 <adamw> this is going to throw 'em for a loop
18:12:27 <rosset> a small group of users uses this on installation
18:12:35 <adamw> hard to quantify how small
18:12:46 <adamw> if typing a 'c' during installation actually gave you a 'k' we'd probably consider that a blocker
18:12:59 <myllynen> otherwise except for password issues i'd think that zero day updates would be just fine
18:13:31 <myllynen> but i'm no brazilian :)
18:13:45 <rosset> names with ç is small
18:14:35 <rosset> i think a 0-day update is good
18:14:36 <adamw> how likely would people be to use it in a password do you think?
18:15:04 <jlaska> adamw: when we finish the list ... davidz closed the DeviceKit-disks bug, and added a new one to the list
18:15:16 <rosset> adamw, small
18:15:24 <rosset> not significant
18:15:28 <rosset> i think
18:15:36 <adamw> ok
18:15:37 <adamw> thanks
18:15:47 <adamw> based on that i can go with dropping to target and having it fixed as a 0-day update
18:16:00 <adamw> so i think we're agreed on that then...
18:16:04 <rosset> ok +1
18:16:42 <myllynen> yep +1
18:17:43 <adamw> #agreed 505100 drops to F12Target, team is aiming to fix as a 0-day update, impact during installation is not big enough to warrant it being a blocker
18:17:54 <adamw> thanks rosset and myllynen!
18:18:01 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=520480
18:18:03 <buggbot> Bug 520480: medium, low, ---, rdieter, NEW, F12 KDE blocker
18:18:14 <adamw> uff, that's the kde metabug
18:18:25 <adamw> #agreed 520480 is the kde blocker, no need to assess it directly
18:18:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=527209
18:18:34 <buggbot> Bug 527209: high, low, ---, kernel-maint, ASSIGNED, Large file transfers are killing BCM5906M tg3 Ethernet card
18:18:39 <jlaska> good news on this front
18:18:49 <jlaska> we havea workaround for now ... and broadcom is working on a patch as well
18:19:36 <adamw> so we're expecting to land it in a kernel soon?
18:19:44 <jlaska> the question for me is to keep this on awaiting an update on the patch
18:19:50 * mclasen thinks that the cedilla bug is a trainwreck
18:20:04 <adamw> if we have a working workaround in for final i would be happy to consider that enough to stop it being a blocker
18:20:12 <adamw> the 'real fix' can go in as an update
18:20:19 <adamw> mclasen: it's not our problem any more anyway =)
18:20:24 <Oxf13> right, we could keep the bug open, but drop it from the blocker.
18:20:35 <jlaska> yeah, the workaround seems fairly straightforward (ethtool)
18:20:41 <adamw> oh, iswym
18:20:41 <mclasen> adamw: there was talk about a 0-day fix in backscroll. what is that fix ?
18:20:57 <adamw> i thought you meant we were going to actually patch whatever the ethtool change does into the kernel
18:21:30 <adamw> mclasen: it looks like it's still being discussed in the bug - if you think the proposals in the last couple of comments are wrong then please say so in the bug, i think is the best thing to do
18:21:38 <jlaska> adamw: the comments I have back from broadcom aren't specific.  I take it to mean a kernel patch coming, but could be wrong
18:21:47 <mclasen> adamw: I just did
18:22:26 <adamw> jlaska: my worry is just that if a system is badly enough affected by this issue it could potentially be hard to find the workaround in the first place...that's the problem with network issues
18:22:40 <adamw> jlaska: though if the kernel we finally ship is in the state where it only happens on large transfers i guess it's okay
18:23:23 <jlaska> adamw: we can leave this on the list awaiting feedback from broadcom until next review if you prefer
18:23:43 <adamw> well, we're running down on time, especially for doing a new _kernel_ build
18:24:10 <adamw> i dunno, let's vote on it - do we drop it to target based on the workaround from comment #19? i abstain :)
18:24:15 <jlaska> stickster: did you hit this issue during install, or just during post-intsall rsync'ing ?
18:24:16 * mclasen drops off to pick up the kids
18:25:39 <jlaska> Let's go with the information we have in hand ... the workaround
18:26:04 <jlaska> is that a sufficient workaround for this issue ... I _think_ so
18:26:27 <jlaska> we can common_bug it and update if new information comes in around a patch?
18:26:28 <cebbert> yes, i'd say so
18:26:48 <cebbert> if we get a patch we can look at merging it
18:27:20 <jlaska> adamw: how do you feel?
18:27:36 <Oxf13> has anything else changed in the kernel cvs?
18:28:01 <adamw> jlaska: as I said, i abstain =)
18:28:05 <adamw> +/-0
18:28:16 <adamw> so we have two +1s for dropping it to target, that's fine
18:29:01 <jlaska> I think this might be worth adding to common_f12_bugs as well
18:29:01 <adamw> yes for sure
18:29:03 <wwoods> definitely commonbug
18:29:04 <adamw> that's the 'finding the workaround' part :)
18:29:04 <jlaska> right on
18:29:08 <adamw> #agreed 527209 drops to f12target as a tested workaround is available
18:29:17 <adamw> #action 527209 adamw to document workaround for 527209 in common_bugs
18:30:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528537
18:30:33 <buggbot> Bug 528537: medium, low, ---, kernel-maint, MODIFIED, fails to get kickstart file over nfs.
18:30:56 <jlaska> kparal confirmed this fixed his issues ... I just pinged davej to see if he's still seeing this issue
18:31:00 <adamw> i just wanted davej to confirm this one was OK for him, i figured he'd be able to check pretty soon
18:31:17 <adamw> if he can't we can probably still close it on the basis of kparal's feedback but i just felt safer to try and get davej's too
18:31:49 <jlaska> I know kparal was having several nfs related issues, so I'm happy he's made progress
18:31:59 <jlaska> but agree ... let's give davej time to respond
18:33:06 <adamw> ok, sounds good
18:33:13 <adamw> i'll ping him on the bug report also
18:33:43 <adamw> #agreed still waiting for davej confirm on 528537
18:33:50 <adamw> #action adamw to ping davej on 528537 report
18:34:06 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530393
18:34:08 <buggbot> Bug 530393: medium, low, ---, kernel-maint, NEW, tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
18:34:26 <jlaska> this is the issue raised earlier on fedora-test-list ?
18:34:30 <adamw> someone nominated this on the list today so i added it for discussion, but my feeling is it's not a blcoker
18:34:30 <adamw> yes
18:34:52 <adamw> principally because the system doesn't completely go down - it just hangs for a couple of minutes
18:34:56 <adamw> irritating yes, blocker? probably not
18:35:16 <jlaska> should we pull in eparis?
18:35:24 <adamw> can't hurt
18:35:29 <adamw> cebbert: you have any perspective on this?
18:36:35 <adamw> jlaska: do you have a line to eparis? i don't see him online, unless his nick is different
18:36:39 <jlaska> yeah
18:36:50 <cebbert> no, but eparis seems to have a fix for it
18:37:46 <cebbert> there's apparently a whole set of problems with tpm
18:39:45 <jlaska> <eparis> | I have a feeling this guy has busted hardware, but i'll try to get him the test kernel that would proove it by the end of the day
18:40:03 <adamw> thanks
18:40:14 <jlaska> I don't think we have enough to keep it on the list
18:40:17 <adamw> i'd say that's just another reason to drop it for now
18:40:18 <adamw> yeah
18:40:29 <jlaska> +1
18:40:36 <adamw> i'll drop it but ask eparis to raise it again if the test shows the guy's hardware isn't the problem
18:41:02 <adamw> sound good?
18:41:06 <adamw> oh hi :)
18:41:09 <jlaska> ssssh, he's here
18:41:19 * eparis cusses at irssi
18:41:26 <adamw> so then i said, 'yeah but what can you expect from epar'- oh hi
18:41:39 <jlaska> :))
18:41:40 <adamw> =)
18:41:44 <eparis> so I think this person actually has busted hardware, but we have a patch that might work aorund it for him (and could prove it)
18:41:55 <eparis> I keep meaning to build him a test kernel and keep getting side tracked
18:42:06 <eparis> I told jlaska I'd get one on my page tonight.
18:42:26 <adamw> eparis: sounds good - so i plan to drop it from the blocker list for now, we could possibly raise it if the tests give you the feeling there's something worse than we thought here
18:42:32 <adamw> eparis: sound ok to you?
18:42:50 <eparis> it dos
18:42:52 <eparis> does
18:42:54 <adamw> ok
18:43:05 <adamw> just put it back on the list (block F12Blocker) if you start to get a bad feeling
18:43:06 <adamw> thanks!
18:45:30 <adamw> #agreed 530393 is not serious enough (and may be caused by bad hardware): dropped from the list
18:45:46 <adamw> #action eparis to provide a test kernel for 530393 soon, and put it back on the blocker list if he decides it was more serious than we thought
18:46:01 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=524795
18:46:02 <buggbot> Bug 524795: medium, low, ---, rdieter, ON_QA, libsigsegv allocates alternate stack on the main stack
18:46:12 <jlaska> not sure how this is on our list ... it's against F-11?
18:46:18 <adamw> it's indirect
18:46:20 <adamw> tracking it down atm
18:46:31 <adamw> it blocks 511723 which was on the f12blocker list
18:46:34 <adamw> but is CLOSED RAWHIDE
18:46:49 <jlaska> ftbfs
18:47:07 <adamw> i confirm i have an fc12 build of libsigsegv showing in my repos
18:47:15 <adamw> so obviously this was indeed fixed as far as f12 is concerned
18:47:24 <jlaska> Available Packages
18:47:24 <jlaska> libsigsegv.i686                        2.6-6.fc12                        rawhide
18:47:28 <adamw> so, let's stop 524795 blocking 511723, and no more problem
18:48:31 <adamw> #agreed 524795 is an indirect blocker via 511723 which is fixed, 524795 should no longer block 511723
18:48:45 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531924
18:48:46 <buggbot> Bug 531924: medium, low, ---, mclasen, NEW, reboot hangs waiting for return on livecd
18:48:59 <Oxf13> yeah this is going to be a fun one
18:49:10 <Oxf13> and we may have to reach into the wayback machine (aka jeremy) for some help
18:49:23 <jlaska> is this the same one we had during beta?
18:49:39 <Oxf13> could be.
18:49:53 <jlaska> there he is!
18:49:54 <Oxf13> jeremy: we're talking about a LiveCD shut down thing, here users are prompted to eject the CD
18:50:04 <Oxf13> jeremy: do you recall anything about that (I may be barking up the wrong tree)
18:50:21 <adamw> jeremy: https://bugzilla.redhat.com/show_bug.cgi?id=531924
18:50:23 <buggbot> Bug 531924: medium, low, ---, mclasen, NEW, reboot hangs waiting for return on livecd
18:50:36 <cebbert> heh, with external usb cd drives it shuts down but leaves the drive door locked
18:50:54 <cebbert> (on shutdown, not reboot)
18:51:19 <jeremy> there's an eject put into halt.local
18:51:37 <jeremy> it should timeout, though -- it uses 'read -t 30'
18:52:05 <Oxf13> yeah, it does timeout, but apparently sometimes it doesn't
18:52:12 <Oxf13> or the 30 seconds seems too long
18:52:15 <jeremy> the bits to add it are in fedora-live-base.ks (which is run during the system run as halt.local)
18:52:32 <Oxf13> yeah, we found where it was, I'm trying to determine the original need for this here
18:52:34 <jeremy> less than 30 seconds and expecting someone to be able to pull out the cd is like asking for their fingers to be bitten off by an alligator ;)
18:52:37 <Oxf13> and what happens if we don't mess with halt
18:52:44 <jeremy> if you don't eject the cd and reboot, then you boot right back into it
18:52:49 <jeremy> which sucks
18:52:53 <Oxf13> jeremy: the current problem is that the user never sees the message
18:53:04 <Oxf13> it sits at a black screen, or a "rebooting" screen
18:53:17 <Oxf13> you have to switch vts to see the message
18:53:30 <jeremy> it goes where any other message shown during shutdown goes...  if there's a need to change that due to plymouth or whatnot changes, then someone can make hte right change there
18:54:15 <jeremy> https://bugzilla.redhat.com/show_bug.cgi?id=474817 was the original bug requesting it
18:54:16 <buggbot> Bug 474817: medium, low, ---, katzj, CLOSED RAWHIDE, Usability improvements in Live CD installer
18:54:25 <Oxf13> ok.
18:55:02 <Oxf13> so our options are A) try to fix plymouth so that we get our message, B) remove the messing with halt and regress 474817, C) do nothing and hope that the 30s timeout isn't too egregious
18:56:29 <adamw> looking at 474817
18:57:27 <adamw> mrrff
18:57:33 <adamw> should we pull in halfline to ask about a plymouth fix?
18:58:08 <Oxf13> seems dangerous at this point, but sure.
18:59:56 <halfline> hello
19:00:06 <adamw> halfline: hi, thanks!
19:00:07 <adamw> halfline: we're looking at https://bugzilla.redhat.com/show_bug.cgi?id=531924
19:00:09 <buggbot> Bug 531924: medium, low, ---, mclasen, NEW, reboot hangs waiting for return on livecd
19:00:44 <adamw> the problem being that a message to take out the CD and reboot the machine should be displayed when you try to reboot from the live CD, but it's not showing up probably due to plymouth
19:00:50 <adamw> oxf13 has summarized our options:
19:00:55 <adamw> so our options are A) try to fix plymouth so that we get our message, B) remove the messing with halt and regress 474817, C) do nothing and hope that the 30s timeout isn't too egregious
19:01:02 <adamw> so we just wanted your take on A)
19:01:20 <Oxf13> the message is showing up on a different TTY than the one that we see at shutdown now
19:01:20 <halfline> let me read 474817
19:01:21 <halfline> one sec
19:03:06 <halfline> so how are you printing the message?
19:05:10 <cebbert> what about powerdown, where we leave the cd door locked? :/
19:05:40 <cebbert> i guess we're assuming the cd is built in to the computer
19:06:29 <halfline> Oxf13: do you know how the message is getting printed?
19:06:36 <Oxf13> yeah, finding
19:06:50 <Oxf13> /usr/sbin/eject -p -m \$(readlink -f /dev/live) >/dev/null 2>&1
19:06:50 <Oxf13> echo "Please remove the CD from your drive and press Enter to finish restarting"
19:06:53 <Oxf13> read -t 30 < /dev/console
19:07:04 <Oxf13> that's being put in /sbin/reboot
19:07:20 <jlaska> should that read "Please remove the live image ..."
19:07:29 <jlaska> not the focus of this discussion perhaps ... nm
19:08:02 <Oxf13> god this is a bit confusing
19:08:18 <Oxf13> this all goes into /sbin/halt.local
19:08:26 <Oxf13> which then modifies /sbin/reboot
19:08:30 <halfline> eww
19:09:19 <adamw> maybe if we turn the question around - how _ought_ such a message to be printed, in your opinion, halfline?
19:09:32 <halfline> right, that's what i'm thinking about
19:09:44 <halfline> so we really probably want a graphical shut down...
19:09:53 <halfline> it's an open question why that isn't happening
19:10:09 <adamw> well for f12 we want very small changes at this point :)
19:10:17 <halfline> right
19:10:45 <Oxf13> the shutdown case may be different on systems with KMS
19:10:51 <Oxf13> I've been testing in KVM which doesn't have that
19:11:18 <halfline> hmm, we should probably figure that out too
19:11:44 <jlaska> should we break off on this and report back in the bz?
19:11:54 <jlaska> or are folks more comfortable working it here with all the right folks invovled?
19:12:09 <halfline> well if you guys have other blockers to go through
19:12:09 <Oxf13> yeah, I think its pretty clear that this is a bad user interaction, seemingly stuck for at least 30 seconds
19:12:16 <halfline> i'll write a comment on the bug report
19:12:22 <Oxf13> and it doesn't accomplish the original intent of having the message there if hte user never gets themessage
19:12:49 <halfline> so the thing is...
19:12:59 <halfline> you'd expect the message to be gettng redirected to plymouth
19:13:12 <halfline> if it's not getting redirected to plymouth ...
19:13:15 <halfline> oh hang on
19:13:17 <halfline> let me check something
19:13:25 <halfline> ah ha
19:13:51 <halfline> /etc/event.d/plymouth-shutdown doesn't have --attach-to-session
19:14:00 <halfline> which means /dev/console messages aren't getting redirected
19:14:00 <adamw> that sounds simple. /me likes simple
19:14:19 <halfline> that may be why the message isn't showing up
19:14:40 <halfline> i feel like there is probably more to it than that though
19:14:52 <Oxf13> well, is that something we could quickly try and see?
19:14:56 <Oxf13> that's just a text file right?
19:15:02 <halfline> yea it's just a text file
19:15:13 <adamw> i guess it should be possible to boot live, edit that text file, then see what happens on shutdown/reboot
19:15:18 <halfline> right
19:15:22 <Oxf13> I'm already on step 2
19:15:25 <adamw> =)
19:15:37 <halfline> read < /dev/console isn't really right either though
19:15:40 <adamw> alright, i think we can move on in the meeting anyway, we need more data to evaluation what's the best solution
19:15:45 <Oxf13> halfline: where would I put that flag?
19:15:57 <adamw> i'll summarize the discussion so far on the bug report
19:15:59 <halfline> Oxf13: where t says /sbin/plymouthd
19:16:02 <Oxf13> k
19:16:04 <adamw> and we can sort it out there
19:16:07 <adamw> sounds ok for everyone?
19:16:08 <halfline> put /sbin/plymouthd --attach-to-sessoin
19:16:09 <jlaska> adamw: word
19:16:20 <halfline> sounds good
19:16:32 <halfline> i feel like we'll be revisiting this bug, but can do on the bug report
19:18:05 <adamw> ok
19:18:14 <adamw> #agreed 531924 needs more evaluation which is taking place via bug report
19:18:25 <adamw> #action adamw to summarize current state of debate on 531924 on the report
19:18:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526549
19:18:41 <buggbot> Bug 526549: medium, high, ---, chellwig, NEW, rawhide/i386 kvm guest install on rawhide/i386 host fails due to swap device prompt
19:19:42 <adamw> jlaska?
19:19:55 <jlaska> sorry
19:19:57 <jlaska> working this right now
19:20:01 <jlaska> definitely a bug
19:20:11 <jlaska> rawhide/i386 kvm guest installs on rawhide/i386 host
19:20:18 <jlaska> thanks to wwoods for narrowing this down further
19:20:34 <jlaska> I think it constitutes a blocker, but I'm surprised that no one else is seeing this
19:20:46 <Oxf13> ah
19:21:06 * Oxf13 wonders how common it is to run a 32bit os on a VT capable system
19:21:29 <adamw> i feel like i've seen that message somewhere
19:21:34 <adamw> not in my tests but someone else talking about it
19:21:35 <jlaska> i386 guest on x86_64 host is fine
19:21:39 <adamw> jiggered if i can remember where though
19:21:44 <jlaska> where this comes into play is rats_install is failing
19:21:56 <jlaska> so ... it'd be a nice win to have green for all i386 and x86_64 rats
19:22:02 <adamw> oh, maybe just prior discussion of the same bug
19:22:07 <jlaska> but that's not as important I think as having native arch i386 guest installs working
19:22:39 <adamw> does it work if you answer the prompt?
19:22:44 <Oxf13> wait
19:22:59 <jlaska> nope
19:22:59 <Oxf13> how is rats_install failing, we're doing up a i386 host with VT to run an i386 guest?
19:23:17 <jlaska> the lvm guys think there is some directio issue lurking in the kernel here
19:23:44 <jlaska> Oxf13: yes, all the autoqa tests run on a host with the native arch
19:23:57 <Oxf13> interesting.
19:24:08 <Oxf13> do we have a rats sanity test for i386 guest on x86_64 host?
19:24:18 <jlaska> btw ... this isn't related to rats
19:24:21 <Oxf13> (which IMHO would be the /far/ more likely case)
19:24:25 <jlaska> it's really just i386 kvm guest install on an i386 host
19:24:30 <jlaska> rats just found it
19:24:50 <adamw> so at present our judgment is that installing an i386 kvm guest on an i386 host is borked?
19:25:02 <Oxf13> seems that way
19:25:15 <jlaska> yeah, which I'm amazed about
19:25:26 <adamw> given how loudly we're tootling the virtualization horn for this release it seems blockerish to me
19:25:39 <Oxf13> jlaska: what are you amazed at?
19:25:41 <adamw> jlaska: well, as oxf13 says, it may be that most people who actually use virt are on x86-064
19:25:43 <adamw> x86-64
19:25:51 <jlaska> yeah could be
19:25:52 <Oxf13> running an i386 OS on a VT box is really not a common thing to do
19:26:01 <Oxf13> it severely limits what kind of guests you can run
19:26:03 <adamw> i think the set of 'virtualization capable machines' is a subset of 'x86-64 machines', right?
19:26:07 <jlaska> once we have a workaround for this ... I'd be fine noting it
19:26:14 <Oxf13> adamw: I'm almost 100% certain of that.
19:26:34 <adamw> if we're pretty sure of that then i'd probably be okay with a note to say 'run it on an x86-64 host ya idiot'
19:26:36 <Oxf13> jlaska: the work around is to use an x86_64 OS on your VT box
19:27:08 <jlaska> that's kind of lame
19:27:25 <jlaska> hrmm, maybe not ... but it sucks
19:27:26 <Oxf13> so is running a 32bit os on a virt box
19:27:28 <cebbert> yeah... anyone running a 32-bit os on the host is an idiot
19:27:36 <jlaska> cebbert: heh, thanks
19:27:36 <adamw> mmmph. only if there's any kind of legitimate reason for your virt host to be running i686 rather than x86-64 fedora. and nothing springs to mind.
19:27:56 <Oxf13> I'm prefectly fine with saying that Fedora 12 does not support i386 VT hosts
19:28:02 <adamw> it's not like you need to run wine on the frickin' thing
19:28:05 <cebbert> you can't really give resources to the guests when the host is 32-bit
19:28:36 <jlaska> Oxf13: that's a pretty big stmt ... I'd want some fesco on that before we moved on
19:28:46 <adamw> cebbert: thank you, now i can call jlaska an idiot with expert back-up :)
19:29:03 <Oxf13> jlaska: sure we can get fesco involved, but as cebbert states, it's a really limiting move
19:29:10 <Oxf13> it's just a bad idea
19:29:29 <adamw> jlaska: well, from a blocker perspective it's our job to judge the likely impact of potential blocker bugs, and i think this discussion rather indicates that the likely impact of this bug is small
19:29:37 <Oxf13> and I'm not at all surprised if the code isn't well working
19:29:49 <adamw> whether we make an outright statement to that effect may be up to fesco but from the blocker bug perspective i'm -1 on this being a blocker given the above
19:29:51 <cebbert> all machines that can do virt can also do 64-bit
19:29:55 <Oxf13> even when doing "i386" installs on a x86_64 virt box, your guests are x86_64, but just running the i386 os
19:30:09 <Oxf13> KVM doesn't create real "i386" guests
19:30:09 <jlaska> keep in mind, we have no one from virt space here right now
19:30:29 <adamw> is there anyone we can pull in?
19:30:43 <jlaska> markmc is gone at the moment
19:31:06 <jlaska> I'll see if I can get his input on the bz
19:31:07 <Oxf13> I propose we bounce it from the blocker list.  I'd really struggle with slipping the release for this issue
19:31:23 <adamw> i'm +1 to that
19:31:25 <jlaska> I'll agree, once we have a subject matter expert from virt to confirm
19:32:07 <adamw> i can live with that
19:32:17 <adamw> just ask mark or chellwig to confirm in the bug?
19:32:29 <jlaska> we have confirmation of hte bug by others
19:32:42 <jlaska> but I'll ask for their sense on the practicality of i386 guets on i386 hosts
19:32:46 <Southern_Gentlem> unblock and document in the release notes
19:32:46 <adamw> i mean to confirm our assessment of the sanity of using an i386 virt host
19:32:58 <jlaska> and then we can put a stmt in the release notes about non-support
19:32:58 <adamw> thanks
19:33:15 <adamw> it may be too late for release notes, they have a pretty deep freeze for translations
19:33:26 <adamw> can always put in common bugs though
19:33:26 <jlaska> k .. common_bugs would be fine for me there
19:33:29 <jlaska> roger
19:34:10 <adamw> #agreed 526549 pending drop from blocker status if virt team confirms that there is no reason to run 32-bit fedora on a kvm host machine as we believe
19:34:30 <adamw> #action jlaska to confirm our evaluation of 526549 with the virt team and drop from blocker list if they agree
19:34:40 <adamw> i'll leave this bug to you to update, jlaska
19:34:50 <jlaska> adamw: got thanks
19:35:02 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523815
19:35:04 <buggbot> Bug 523815: medium, low, ---, tbzatek, ASSIGNED, nautilus hoses vino
19:35:16 <jlaska> sorry to be a stickler on this one ... I'm fine dropping it, just want to make sure we have all the right folks in the loop ... sounds like a big decision
19:35:22 <adamw> sure
19:35:27 <adamw> i am unconvinced about this one
19:35:32 <adamw> vino ain't in any critical path i know of
19:36:13 <adamw> not to mention tomas bzatek's comment
19:36:28 <Oxf13> yeah, I'm not going to slip for this
19:36:59 <Southern_Gentlem> wsnt vino replaced with gnome-remote-desktop?
19:37:36 <stickster> That's just a viewer.
19:37:49 <stickster> vino-server is running on a system that shares its desktop.
19:37:53 <adamw> anyway...no-one wants to defend this as a blocker?
19:38:06 <adamw> alright, droppity drop drop
19:38:06 <Southern_Gentlem> no
19:38:24 <stickster> No one from Desktop here?
19:38:31 <adamw> mclasen stepped out
19:38:34 <stickster> halfline?
19:39:21 <Southern_Gentlem> going to test that one
19:39:43 <adamw> ok, going going gone
19:39:44 <adamw> #agreed 523815 is not a blocker, vino is not a significant enough component, can be fixed as an upgrade
19:40:00 <halfline> stickster: hey
19:40:22 <stickster> halfline: Had been looking for someone to weigh in on .bug 523815
19:40:24 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=523815 medium, low, ---, tbzatek, ASSIGNED, nautilus hoses vino
19:40:37 <stickster> My name's Paul, and that's 'tween y'all
19:40:45 <adamw> halfline: so far we're agreed it's not a blocker, but stickster wanted an input from desktop team
19:40:51 <adamw> halfline: do you feel it's a blocker?
19:41:53 * halfline reads
19:42:49 <halfline> yea clearly not a blocker
19:43:22 <halfline> vino works off the damage extension
19:43:47 <halfline> paints rectangles every time the x server finds out a client just repainted part of its app
19:43:55 <Oxf13> weird
19:43:58 <adamw> clearly not a blocker is enough for me!
19:44:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531425
19:44:11 <buggbot> Bug 531425: medium, low, ---, steved, ASSIGNED, newly installed system,NFS daemon start failed after  boot
19:44:39 <halfline> heh, okay.
19:45:24 <adamw> halfline: i'm hoping to finish this meeting some time before I have grandchildren =)
19:45:28 <jlaska> this is an odd timing issue
19:45:34 <jlaska> steved was looking into this yesterday
19:45:45 <jlaska> but it made us wonder ... why is nfs being chkconfig'd on after a fresh install
19:45:50 <jlaska> and I couldn't remember why
19:45:52 <jlaska> anyone?
19:45:56 <adamw> that would seem to be a bad idea
19:46:01 <jlaska> agreed
19:46:24 <jlaska> the timing issue is ... start NM (wait for networking asynchronously) ... later start nfsd (networking hasn't completed yet)
19:46:33 <adamw> do we have a policy on whether network-accessible services should be enabled by default?
19:46:34 <jlaska> I'm not so worried aobut that
19:46:51 <jlaska> adamw: maybe a spot or Oxf13 question?
19:47:38 <Oxf13> without nfs on, people can't mount remote nfs shares
19:47:50 <Oxf13> probably not all that obvious that a user has to start the nfs service in order to mount
19:48:14 <adamw> is there a separate nfs-server service? or is client and server together?
19:48:28 <jlaska> I believe it's combined with that rpc.* stuff
19:49:22 <adamw> still, i'm not convinced anything much has changed here
19:49:22 <jlaska> Oxf13: adamw: jforbes provided feedback confirming your thoughts on the virt issue, I've moved 526549 to F12Target and will chat w/ wwoods on adjusting autotest to accomodate
19:49:38 <jlaska> adamw: apparently steved keeps moving the initscript order around to make more room for networking to start
19:49:42 <adamw> presumably this was the case with previous releases? i don't see why this wouldn't be happening in any case where there's a race with networkmanager for any reason (i.e. any case where network comes up a bit slowly)
19:49:42 <jlaska> but it's all timing really
19:49:58 <jlaska> sometimes network activiation is slow ... and it'll fail on boot (and need a service nfs restart)
19:50:03 <adamw> right, it's not something that's possible to solve with serial initscripts afaics
19:50:06 <jlaska> right
19:50:14 <jlaska> well ...
19:50:26 <adamw> you could have the networkmanager service hold everything up until it's sure a connection is up or will never BE up, but that's just as bad in many ways
19:50:27 <jlaska> some of the initscripts have network nm-online checks
19:50:32 <jlaska> but ... that's silly
19:50:34 <jlaska> for now
19:50:54 <adamw> wouldn't really be appropriate for this initscript anyway, given that you need it to ever be able to mount an nfs share during the session
19:51:22 <adamw> although...hmm. still thinking
19:51:40 <jlaska> not sure why this is showing up now
19:51:46 <adamw> if it fails if there's no network connection available, it would seem to make sense for it to check for a network connection? dunno, i don't know this bit of fedora architecture well enough, twas all different on mdv
19:52:14 <jlaska> # Required-Start: $local_fs $network $syslog
19:52:20 <jlaska> is that upstart?
19:52:30 <wwoods> jlaska: so, long story short: virt on i386 host is unsupported?
19:52:31 <adamw> it's LSB in fact
19:52:38 <adamw> i don't think our initscripts parse those dependencies, though imbw
19:52:38 <jlaska> wwoods: yeah ... poo :(
19:52:47 <wwoods> that's kind of shocking
19:52:54 <jlaska> wwoods: I agree
19:52:55 <Oxf13> this is not a good area to be touching on near release either
19:53:08 <jlaska> Oxf13: agreed ... just thinking about options
19:53:11 <adamw> there's a standard format for initscripts dependencies and that's it. mandriva's parallel init thing parses them. i guess upstart does too. i don't think good old-fashioned sysv-style serial init like ours does, though.
19:53:14 <Oxf13> because you're almost 100% sure to break nfs mounted /
19:53:17 <Oxf13> or other shit like that
19:53:30 <Oxf13> adamw: we use upstart
19:53:36 <notting> adamw: they're parsed at the time the scripts are installed
19:53:41 <adamw> oh, d'oh. having a slow moment
19:53:50 <jlaska> notting: and it tickles with the order based on that?
19:53:52 <adamw> notting: and used to order the scripts?
19:53:57 <notting> yes
19:54:00 <jlaska> ^^ what adam said :)
19:54:13 <notting> of course, depending on NM to start,  does not necesarily mean there's an interface configured
19:54:22 <jlaska> right, I think that's what's happening here
19:54:24 <adamw> ah. then the network dependency won't really do what it's intended to in optimal circumstances...ideally it's parsed during the actual boot and means 'don't start this service till the network's running'
19:54:49 <notting> NM can be configured to start up synchronously if you want
19:55:03 <jlaska> do I smell a workaround coming?
19:55:09 <adamw> i'm thinking the practical upshot here is there's really not a lot we can safely do, and this is likely a race condition that not everyone is going to see
19:55:29 <adamw> does that feel right?
19:55:36 <notting> jlaska: it's the same one that's been there for a while
19:55:58 <notting> jlaska: set NETWORKWAIT in /etc/sysconfig/network
19:57:47 <jlaska> notting: gotcha, didn't know about that
19:58:03 <Oxf13> that's the "make my machine boot slow" option
19:58:08 <adamw> erm. i do have one question actually
19:58:25 <adamw> nfs service is not enabled on my machine, and is not running (service nfs status shows everything stopped)
19:58:34 <adamw> yet i have an nfs mount working fine:
19:58:36 <jlaska> adamw: ah right ... that's the other issue
19:58:38 <adamw> htpc.local.net:/media/NAS on /share/data type nfs (rw,nosuid,rsize=8192,wsize=8192,soft,addr=192.168.1.6)
19:58:55 <adamw> so i question the assertion that nfs service needs to be running in order for you to be able to mount an NFS partitino
19:58:57 <adamw> partition
19:59:08 <jlaska> hrmm, same here (however I'm using autofs)
19:59:26 <adamw> Oxf13: ?
19:59:44 <Oxf13> adamw: do you have rpc.whatever services running?
20:00:05 <adamw> i have rpcbind , rpc.statd and rpc.idmapd running
20:00:31 <adamw> perhaps this works via the netfs service, which is how i get the share mounted? i don't call mount directly, it's listed in my /etc/fstab and i do 'service netfs start' to bring it up
20:00:49 <adamw> afaik that's the 'supported method', though
20:01:24 <poelcat> i can't recall ever having to run nfs to mount a share
20:01:39 <Oxf13> adamw: I think that's one way to get those services running
20:02:01 <adamw> i'm going to go poking through nfs-utils in cvs to see if the default state of the nfs service was changed lately
20:02:42 <poelcat> in fact I know i had an f12 client mounting a share on a f11 server
20:02:51 <adamw> hmm - the entire LFS-style init info block was added 4 months ago (i.e. during f12 cycle)
20:02:51 <adamw> http://cvs.fedoraproject.org/viewvc/rpms/nfs-utils/F-12/nfs.init?r1=1.33&r2=1.34
20:03:05 <jlaska> smithers?
20:03:17 * jlaska removes that block and retests
20:03:23 <adamw> that may have changed the behaviour; before that it may not have been enabled by default
20:03:49 <adamw> i would assume that for an initscript that doesn't have such a block at all the default would be for it to be off?
20:04:50 <jlaska> should we summarize?
20:05:15 <adamw> i'm inclined to the belief the nfs service used to default to off and probably still should; but it's possible this would be a dangerous change
20:05:28 * tk009 notices the marathon continues
20:05:36 <jlaska> let's get that into the bz ... and see if steved can comment?
20:05:47 <adamw> tk009: still running =)
20:05:53 <jlaska> tk009: got any energy bars?
20:06:07 <adamw> ok, i'll put a summary in the bug report
20:06:13 <tk009> snickers =)
20:06:13 <adamw> i propose we leave it on the blocker list for now
20:06:16 <tk009> dark chocolate
20:06:38 <adamw> tk009: heh heh, good one
20:06:40 <jlaska> adamw: perhaps just getting a response on that point ... and either a discussion around rolling back that change ... or common_bug'ifying this issue?
20:06:45 <cebbert> ghirardelli pecan pie squares here
20:07:07 <Oxf13> can't stop the pain train!
20:07:14 <Oxf13> chugga chugga WOO WOOO!
20:14:09 <Oxf13> there were PackageKit tag requests recently
20:14:17 <Oxf13> I haven't gotten around to testing them yet
20:14:18 <adamw> this is yum by the looks, not pk
20:14:25 <skvidal> I didn't realize there were any yum blockers remaining
20:14:25 <adamw> skvidal: we're on https://bugzilla.redhat.com/show_bug.cgi?id=529349 at present
20:14:25 <Oxf13> it's not yum
20:14:26 <Oxf13> it's PK
20:14:27 <buggbot> Bug 529349: medium, low, ---, richard, ASSIGNED, Can't use yum with outdated or no repo data
20:14:29 <adamw> oh sorry
20:14:30 <adamw> noise!
20:14:36 <adamw> skvidal: humble apologies :)
20:14:40 <skvidal> whew
20:14:43 * adamw edits summary
20:14:45 <skvidal> you just scared me a bit
20:15:09 <adamw> very sorry, was looking at the bug summary not the assigned component
20:15:26 <skvidal> not a problem - I was more worried I had let something fall on the floor
20:15:29 <rjune_> cebbert, the pecan pie squares
20:15:32 <adamw> nope, you're good afaik
20:16:00 <adamw> looks like http://koji.fedoraproject.org/koji/buildinfo?buildID=138834 is the fix
20:16:06 <adamw> it pulls in rather a lot of changes :/
20:16:21 <adamw> https://fedorahosted.org/rel-eng/ticket/2936 is the tag request
20:16:53 <Oxf13> yeah, It's on my list of things to test today
20:16:58 <adamw> it seems to be a bogus version for a start
20:17:03 <adamw> you can't go 0.5.4-1 to 0.5.4-0.1
20:17:10 <adamw> presumably was intended to be 0.5.5-0.1
20:17:30 <adamw> oh wait
20:17:39 <adamw> i think it's the last changelog message that is bogus not the package version :)
20:17:44 <adamw> so that's ok
20:17:59 <adamw> (though confusing)
20:18:07 <adamw> so let's stick this in MODIFIED i guess
20:19:18 <adamw> MODIFIED and ask bastien to re-test, ok for everyone?
20:19:37 <Oxf13> yep
20:20:01 <adamw> ok
20:20:11 <jlaska> here here
20:20:23 <cebbert> rjune_: http://www.amazon.com/Ghirardelli-Chocolate-Squares-8-63-Ounce-Packages/dp/B001G0MG3C
20:20:24 <adamw> #agreed 529349 a patched build and associated tag request are in, requires re-testing from bastien, stays on the blocker list
20:20:36 <adamw> #action adamw to note fixed build for 529349 and ask bastien to re-test
20:20:51 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531581
20:20:52 <buggbot> Bug 531581: medium, low, ---, rstrode, MODIFIED, Encrypted autopart install on IBM Power5 ppc fails to find root device on boot
20:21:08 <Oxf13> I just saw a tag request for this too
20:21:08 <adamw> looks closeable
20:21:30 <adamw> per comment #8, if the tag request is accepted
20:21:40 <jlaska> tested and everything ... thanks halfline
20:21:53 <jlaska> do not pass go, we can move it right to CLOSED once tagged imo
20:22:00 <Oxf13> yep
20:22:01 <adamw> OK
20:22:23 <adamw> #agreed 531581 is tested to be fixed, wait until updated plymouth is tagged to close it
20:22:34 <adamw> #action jlaska, adamw or oxf13 to close 531581 once updated plymouth is tagged
20:23:07 <adamw> the next bug is locked as a 'security issue', though one of the comments indicates it isn't really one
20:23:16 <adamw> OK to #topic it?
20:23:59 <notting> wait. (just coming back)
20:24:18 <notting> the nfs service shouldn't default to on (and from looking at it, it doesn't)
20:24:22 <notting> unless it changed in the past week
20:25:19 <jlaska> notting: I don't think it should either ... reconfirming ... but when looking yesterday, a default install left it enabled
20:25:28 <adamw> notting: did you look at the cvs diff i put in the bug?
20:25:29 <jlaska> making sure it wasn't kickstart %post interference ...
20:25:33 <adamw> notting: http://cvs.fedoraproject.org/viewvc/rpms/nfs-utils/F-12/nfs.init?r1=1.33&r2=1.34
20:25:43 <notting> oh crap
20:25:48 <adamw> notting: that specifies 'Default-Start: 2 3 4 5"
20:25:54 <notting> the Default-Start: overrides the chkconfig: line
20:26:00 <notting> so yeah, that changed, and that's a bug
20:26:04 <adamw> yay, i win
20:26:10 * adamw got one right for once =)
20:26:13 <jlaska> yay adamw and liam!
20:26:22 <cebbert> if someone has it enabled and upgrades, it fails anyway
20:26:27 <jlaska> "for once" - whatever ;)
20:27:04 <adamw> anyway, can we keep further discussion of that in the report or for the 'open floor' at the end, we're on 526044 now
20:27:08 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526044
20:27:09 <buggbot> Bug 526044: is not accessible.
20:27:23 <adamw> as i said, it's flagged as security, but i don't think it really is, per comment #4
20:27:26 <adamw> mclas: around?
20:27:30 <adamw> erf. obivously not
20:28:27 <adamw> seems like polkit hasn't had a major change since sept 14th so the fix for this isn't in yet
20:28:35 <Oxf13> I sent out a ping on 10-21, never got a response
20:28:49 <adamw> yeah...i think we need a hi-nrg ping to matthias
20:29:12 <Oxf13> davidz is online so I'm pinging him directly
20:29:57 <Oxf13> <@davidz> Oxf13: I don't think it's a blocker. I was planning to fix it next week.
20:31:14 <Oxf13> with that I support dropping it from blocker
20:31:36 <adamw> i'm +1 on whatever davidz says when it comes to polkit, yeah
20:31:59 <adamw> since this is stated not to be a security or DoS issue i'm comfortable
20:33:14 <adamw> #agreed 526044 is stated not to be a security or DoS issue, will just lead to polkitd getting restarted if it's crashed this way: not a blocker (per davidz)
20:33:41 * jlaska notes 2 additions to the blocker list for later review
20:33:53 <jlaska> wwoods reopened 530945
20:34:10 <jlaska> davidz added 528874
20:34:35 <adamw> thanks, please remind me at the end if i forget
20:34:41 <jlaska> we can hop on those once through the first pass of course
20:34:59 <adamw> ok, onto the x.org bugs, this'll be fun
20:35:02 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=517625
20:35:03 <buggbot> Bug 517625: high, low, ---, airlied, ASSIGNED, Xorg stops responding and consumes 93%+ CPU time (radeon driver pcie_aspm issue)
20:35:36 <jlaska> adamw: want some xorg devel support for these issues?
20:35:42 <Oxf13> airlied is online right now
20:35:48 <adamw> would be nice to grab airlied and jglisse if poss
20:36:16 <jlaska> not seeing jerome just yet
20:36:17 <jlaska> ...
20:36:18 <adamw> i'll ping glisse
20:36:25 <adamw> he's glisse not jglisse, /whois shows him
20:36:35 <jlaska> yup there he is
20:36:40 <jlaska> all yours then
20:36:45 <adamw> pinged him
20:36:56 <adamw> did you ping airlied?
20:37:08 <Oxf13> I did
20:37:12 <adamw> excellent
20:37:14 <adamw> hi jerome
20:37:21 <glisse> hi
20:37:33 <adamw> jerome doesn't have much time so let's make this bit quick (hah)
20:38:22 <Oxf13> airlied won't be joining us actively.  He's got to run
20:38:22 <adamw> we're looking at 517625 right now but you thought there may be a common cause for all the r600+ hang issues?
20:38:32 <adamw> thanks for trying oxf13
20:38:42 <Oxf13> his client is just here to log
20:38:48 <adamw> glisse: so where are you with that right now, got anything concrete?
20:39:12 <glisse> adamw: so far we think it's related to intel motherboard only
20:39:23 <glisse> ICH9 & ICH10 might be the biggest contender
20:39:28 <adamw> the other bugs we're currently tracking for r600+ hangs are https://bugzilla.redhat.com/show_bug.cgi?id=528593 and https://bugzilla.redhat.com/show_bug.cgi?id=531147 , for everyone playing along at home
20:39:30 <buggbot> Bug 528593: high, low, ---, airlied, ASSIGNED, Near total lockup shortly after logging in [kms, r600, radeon hd 3650, radeon hd 3670]
20:39:30 <buggbot> Bug 531147: high, low, ---, jglisse, ASSIGNED, X.org with ATI Radeon locks up during Fedora installation
20:39:31 <cebbert> i think the original bug is fixed
20:39:49 <glisse> i spend last 2 days trying to locky my r6xx/r7xx hw with no lockup
20:39:52 <adamw> cebbert: we did get some people to try a live CD with the -104 kernel build on it, it still failed
20:39:53 <airlied> btw I got an ICH10 SDV before I left the office, so Monday I'll set it up
20:40:07 <airlied> also I've been running the 3650 card in my nvidia machine for 2-3 wks with no issues
20:40:12 <glisse> sadly fixing lockup is hardly doable without having the guilty configuration in front of you
20:40:13 <adamw> OK
20:40:34 <adamw> glisse: yeah, that's what I feared - even remote access is not necessarily enough right?
20:40:58 <adamw> airlied: wednesday is pretty much the hard deadline for f12 final unless we slip, just in case you didn't know
20:41:02 <glisse> well if i can reboot the computer remotely too it might be doable
20:41:18 <glisse> by reboot i mean pushing the powerbutton ;)
20:41:35 <adamw> i guess in the worst case we can have an intern stand next to it =)
20:41:40 <airlied> even remote reboot/video slows you down a lot, remote debug is much worse
20:41:53 <airlied> I think that thinkpad s/r bug took 2 days to irc to just find out what was broken
20:42:03 <cebbert> i have an ich9 machine and an rv635, just need to move the card over
20:42:07 <adamw> jlaska: can we check if there's any systems within redhat with those specs (a radeon r600+ graphics card on Intel ICH9/ICH10 motherboard)?
20:42:24 <airlied> the w500 laptop also appears to have the issue
20:42:30 <adamw> hum, actually, this system's ICH10 by the looks of it
20:42:39 <adamw> and i've got a Radeon 4770 in my partner's machine
20:42:41 <adamw> i could do some swapping
20:42:45 <airlied> however it hangs for another reason in initrd if the r600 is enabled
20:43:33 <glisse> sadly we got quite few hangs on r6xx/r7xx hw
20:43:58 <glisse> (putting aside the usual gpu lockup that our 3d driver can trigger time to time on some hw)
20:44:09 <jlaska> adamw: I can take that
20:44:19 <adamw> so at the overview level - do we feel that the various reports in 517625, 531383 and and 528593 are probably the same underlying issue, and pcie_aspm=off is just a workaround that works in some cases and not others?
20:44:31 <adamw> jlaska: thanks, it may turn out to be useful anyway
20:44:48 <airlied> adamw: seems sane
20:44:54 <airlied> aspm is off for the r600 now
20:44:56 <glisse> yeah seems the same
20:44:58 <jlaska> adamw: are there any handy smolt links I can reference, or just go with that description?
20:44:59 <airlied> at least with the later kernels
20:45:10 <adamw> and should i be picking through all the reports to make sure everyone who's having trouble has the r600+ and ich9+ combo we suspect?
20:45:10 <airlied> and it still seems it can hang
20:45:38 <adamw> ok, i'll try and do some bug sanitizing on that basis, and catch if we have any reporters who don't fit the profile
20:45:52 <cebbert> we could just disabled aspm in the kernel :/
20:46:01 <adamw> cebbert: that apparently doesn't work for all reporters
20:46:12 <glisse> 531383 is different
20:46:39 <adamw> cebbert: so far i've been splitting the reports up on the basis of whether pcie_aspm=off fixes it or not, but glisse and airlied think the underlying cause may be the same whether that helps or not
20:46:44 <glisse> right to sumup we have issues on Xpress200, R600/R700+Intel motherboard, X1400 in T60
20:47:00 <adamw> the r600+ issues are the most bothering frankly
20:47:04 <cebbert> i'll move my rv635 over this weekend and see if it fails
20:47:08 <adamw> the xpress200 remaining issue is only vt switch, right?
20:47:11 <airlied> so if we tag -105, agp should be fixed
20:47:11 <glisse> most of the others issue are configuration or kms dealing badly with old monitor
20:47:19 <adamw> that's obviously a pretty big bug, but not as bad as this r600 stuff
20:47:43 <airlied> adamw: that vt switch is wierd my rc410 (rs480 equiv) doesn't do it
20:47:55 <glisse> i think my rs480 doesn't either
20:48:08 <adamw> airlied: a different guy on test-list mentioned this morning he's planning to test on an xpress200 so i asked him to check it
20:48:15 <glisse> i will go through xpress200 bug again see which one i can reproduce
20:48:16 <adamw> hopefully he'll let us know
20:48:33 <airlied> well its a lot etter than rs480 was in F11, where it didn't work at all no matter what ;-)
20:48:39 <adamw> yay progress :)
20:49:17 <glisse> good thing with kms is that i got the feeling that once we got it working there is no more reason for it to break in the future :)
20:49:23 <adamw> so i think we have a plan at least - let's prioritize this r600 stuff, i'll pick through the reports to try and make sure we've accurately guessed the hardware profile that causes it. i think this is something we may want to slip the release for, frankly, if we can't fix it in time
20:49:33 <adamw> glisse: yaaaay
20:49:34 <glisse> unlike with UMS where it's lot less predictable
20:49:56 <cebbert> my rs480 works just fine in f-11
20:50:09 <airlied> if I can reproduce it locally on Monday (my time) I'll let you know
20:50:33 <airlied> if we can't reproduce it, slipping for it is probbably not worth it
20:50:38 <airlied> cebbert: you see thats why I hate those gpus
20:51:12 <adamw> airlied: the reason it worries me is just the amount of reports, there's multiple bugs with multiple reports in each, there were reports on the forums, on phoronix forums...it seems like a lot of people getting hit
20:51:21 <glisse> yeah, beside fixing lockup can takes quite a bit of time
20:51:30 <adamw> although the fact that either pcie_aspm=off or nomodeset helps most reporters is a good point
20:51:39 <glisse> sadly intel motherboard are widespread ;)
20:51:44 <adamw> yeah, imagine that =)
20:51:52 <airlied> not widespread enough
20:51:58 <adamw> ok anyway we've got a plan, we can re-evaluate next week
20:52:04 <adamw> thanks for your help guys
20:53:05 <glisse> i will try to grab an ich10 motherboard too, i will keep you posted if i find one
20:53:11 <adamw> oh, there's one bug we didn't cover
20:53:12 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=522970
20:53:13 <buggbot> Bug 522970: high, low, ---, jglisse, ASSIGNED, popup messages unreadable
20:53:38 <adamw> glisse: you could probably just expense one, frankly, ben's done that for nouveau for a couple of bits of hardware
20:54:05 <adamw> is 522970 the one that should hopefully be fixed with kernel 105?
20:55:09 <adamw> if so i can throw together a live CD for him to test
20:55:19 <adamw> or just ask him to try the newer kernel
20:55:48 <cebbert__> rs482
20:55:52 <glisse> ok i will try to reproduce 522970
20:55:54 <adamw> cebbert: is 522970 one that should be fixed by the kernel 105 AGP change?
20:56:04 <glisse> i think i saw it on some of my hw but didn't pay attention
20:56:10 <airlied> god radeon 7200, stab me in the face. hopefully fixed by 105
20:56:17 <adamw> i'll ask him to check that
20:56:25 <adamw> airlied: even weirder, radeon 7200 *on x86-64* :)
20:56:27 <cebbert> even desktop effects work for me on rs482
20:56:33 <adamw> (though I don't think it's arch-dependent)
20:57:00 <adamw> ok i'll ask him to test with kernel 105 and glisse will try to reproduce. that's all the ati bugs covered then
20:57:24 <glisse> well there is others bugs too but mostly about multi screen or strange setup
20:57:36 <glisse> some also about non working x700 iirc
20:57:36 <adamw> well, all the ones on the blocker list we're walking today, i mean
20:57:52 <adamw> admittedly the blocker list is a bit random as we haven't been triaging perfectly for f12 cycle
20:57:56 <glisse> yeah i think we discussed about the most important one :)
20:58:00 <adamw> but we have enough shit to work on before wednesday :)
20:58:16 <glisse> okay now i go before i am late
20:58:20 <adamw> ok thanks!
20:58:33 <adamw> alright, now to impose some meeting order on the prior discussion...
20:58:37 <glisse> i will keep you posted, note that i don't have RSA token yet so i won't be able to read my mail on monday
20:58:47 <glisse> you can reach me at glisse@freedesktop.org
20:58:53 <adamw> OK
20:58:56 <cebbert> adamw: i have no clue whther the update fixes r7200
20:58:58 <glisse> otherwise i will be monitoring the bug anyway
20:59:07 <adamw> right, mostly i work through the bug reports
21:00:05 <notting> 29 bugs, 12 in modified. not bad.
21:00:32 <notting> actually, 25 bugs if you remove the ones that are just trackers
21:00:56 <adamw> #agreed 517625 is probably the same as 531147 and 528593, a big issue with recent chips we are trying to pin down. we suspect it occurs on combination of r600+ chipset graphics card and ICH9/ICH10 Intel motherboard. it is accepted as blocker, airlied + glisse + adamw are investigating
21:00:56 <adamw> notting: we're not done yet either
21:01:05 <jlaska> chugga chugga ...
21:01:30 <adamw> #action glisse and airlied and adamw to investigate and try to get appropriate hardware to reproduce 517625, adamw to triage all three reports to try and confirm all reporters have the suspected hardware combination
21:01:51 <cebbert> what is this, the bataan death march?
21:01:56 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522970
21:01:57 <buggbot> Bug 522970: high, low, ---, jglisse, ASSIGNED, popup messages unreadable
21:02:21 <notting> adamw: has this really been a  6 hour meeting?
21:02:24 <adamw> #agreed 522970 can stay on list for now, may be fixed by kernel -105. glisse has appropriate hardware and will try to reproduce
21:02:25 <Oxf13> notting: yes :/
21:02:30 <adamw> notting: still shorter than last week's!
21:02:50 <adamw> #action adamw to request reporter test kernel -105 for 522970
21:03:23 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531383
21:03:24 <buggbot> Bug 531383: high, high, ---, jglisse, ASSIGNED, KMS: VT Switch Problem with Radeon XPRESS 200M
21:03:59 <adamw> #agreed 531383 may be idiosyncratic hardware, others with similar hardware report no such problem. status pending further investigation
21:04:20 <adamw> #action 531383 glisse to try and reproduce, adamw to follow up with test-list tester with Xpress 200m to see if he reproduces
21:06:30 <adamw> alright
21:06:33 <adamw> back to normal service...
21:06:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522929
21:06:44 <buggbot> Bug 522929: medium, low, ---, airlied, ASSIGNED, Occasional system hang when KMS kicks in (RV770)
21:06:47 <adamw> owch, one more ati bug we missed
21:07:44 <adamw> mmmfff...this seems to be quite idiosyncratic, i haven't seen any other report of an erratic KMS failure like this
21:07:50 <adamw> so it's probably a single-system bug
21:09:24 <adamw> anyone else seen anything like this?
21:09:46 <Oxf13> nope
21:10:17 <adamw> i think we can demote it on that basis
21:10:39 <jlaska> haven't seen this
21:11:00 <adamw> ok, let's bump it to target
21:11:22 <adamw> #agreed 522929 seems to be a single-system bug and there's a known workaround (nomodeset): not a blocker
21:12:26 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=514600
21:12:27 <buggbot> Bug 514600: high, low, ---, krh, ASSIGNED, Intel 82G965 requires 'nomodeset' workaround to get working text-mode
21:12:34 <adamw> this is a jlaska special i believe
21:12:54 <jlaska> yeah ... egg on me, I've not been able to grab the information this week
21:12:58 <adamw> egg indeed
21:13:09 <jlaska> I've queued this up for monday morning
21:13:14 <adamw> alright
21:13:22 <adamw> not much to discuss, then, since it hasn't changed status from last week's meeting
21:13:24 <jlaska> I could get it ... but I think the cdc would prefer I didn't
21:13:37 <adamw> cdc?
21:13:45 <jlaska> _might_ be on the list of things magically fixed with recent updates ... here's to hoping ...
21:14:24 <adamw> hey, i believe in unicorns
21:14:26 <adamw> ok
21:14:33 <adamw> #agreed 514600 still waiting on info from jlaska
21:14:43 <adamw> #action jlaska to get his sorry ass in gear and provide info on 514600
21:14:55 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531395
21:14:56 <jlaska> that guy is a real jerk!
21:14:56 <buggbot> Bug 531395: high, low, ---, ajax, ASSIGNED, 945GM: X crashes easy to trigger
21:15:01 <adamw> =)
21:15:26 <adamw> maybe we should ask lennart to disable pulseaudio and try again ;)
21:15:29 * wwoods has been unable to crash his 945GM thus far
21:15:54 <adamw> intel issues seem to depend on more than just the raw chip family...i think video BIOS matters too, and possibly gnomes
21:16:01 <adamw> shall we see if we can corral an intel maintainer?
21:16:17 <wwoods> and things like available display outputs / connected devices
21:16:37 <adamw> yes. and gnomes.
21:17:13 <adamw> in lennart's favour, the bug has a nice juicy backtrace.
21:18:25 <adamw> still waiting on my ajax/krh ping, give 'em another couple of minutes
21:19:40 <adamw> guess not...let's leave this on the list for now then, and ping them on the bug for an urgent response
21:19:42 <adamw> sound good?
21:19:58 <adamw> we could probably drop if push comes to shove, but they only have two bugs on the blocker list anyway, so...
21:20:19 <wwoods> sounds reasonable - it being after 5pm friday in ajax/krh's timezone I have some high expected latency figures
21:20:25 <adamw> =)\
21:20:55 <adamw> #agreed 531395 stays on blocker list, ping ajax/krh for an urgent evaluation
21:21:43 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528005
21:21:45 <buggbot> Bug 528005: medium, low, ---, bskeggs, MODIFIED, X server crash
21:22:05 <adamw> ben claims this is fixed, just need to ping the reporter to test
21:22:13 <adamw> oh, that build's not tagged...
21:23:43 <adamw> so propose to ask reporter to test that build, i'll file a tag request if the fix is confirmed so it's as fast as poss
21:24:28 <adamw> #agreed 528005 is probably fixed, ask reporter to re-test and ensure fixed build gets tagged if confirmed
21:24:46 <adamw> alright - on to the last bug on the initial list! we have two more to add after this though
21:24:51 * jlaska needs to step away ... back soon
21:24:52 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530169
21:24:54 <buggbot> Bug 530169: high, low, ---, bskeggs, ASSIGNED, nouveau + gdm crashes
21:25:33 <adamw> i think we're a bit early for ben to be up :/
21:25:41 <adamw> looks like we're waiting on him for this one
21:27:23 <notting> (also, saturday)
21:27:32 <adamw> pfah, driver developers don't have weekends
21:27:42 <adamw> or if they do this is an inexplicable oversight that should be rectified
21:28:01 <adamw> alright, i think all we can do on this is poke ben with the urgent stick
21:28:19 <adamw> we seem to have enough info in the report, it's on him atm
21:28:25 <Oxf13> how much more of the list do we have?
21:28:30 <adamw> that was the last bug
21:28:31 <wwoods> hrm. maybe these meetings need to be a day earlier to avoid this sort of problem.
21:28:39 <adamw> except for the two additions jlaska suggested
21:28:50 <Oxf13> wwoods: to be fair, they're not supposed to last 6+ hours
21:29:18 <adamw> Oxf13: friday's not super ideal either way
21:29:30 <wwoods> also true, but it means that the turnaround for requested actions is either a couple hours.. or 3+ days
21:30:22 <adamw> #agreed 530169 is waiting on bskeggs, no action but poke him to remind him of the urgency
21:30:48 <adamw> ok, let's cover the new bugs then end this freaking thing
21:30:50 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528874
21:30:52 <buggbot> Bug 528874: medium, low, ---, davidz, NEW, please update Devicekit-disks to master because 7 bugs were fixed
21:31:11 <wwoods> (is the next bug the PackageKit / key import bug? because otherwise I have one more bug to add)
21:31:21 <adamw> that's on the list, yeah
21:31:24 <wwoods> whew
21:31:25 <adamw> there's actually 3 new ones it seems
21:31:50 <adamw> looks like davidz is on 528874, it's more or less a reminder to himself and a justification for the tag request
21:31:57 <adamw> so i don't think we have anything to do there
21:32:02 <Oxf13> probably not
21:32:27 <adamw> #action 528874 no action required, davidz is using it as a reminder-to-self and to justify a tag request
21:32:39 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=530945
21:32:41 <buggbot> Bug 530945: high, low, ---, richard, ASSIGNED, Package-kit ask for key but does not import
21:32:47 <adamw> here's yer bug wwoods :)
21:33:22 <wwoods> so yeah if everything still works like I remember.. we need to be able to import a key during the first (day-0) system update, correct?
21:33:35 <adamw> looks like this is covered under  the tag request mentioned when we discussed the other PK bug
21:33:39 <adamw> https://fedorahosted.org/rel-eng/ticket/2936
21:33:44 <adamw> the ticket mentions this bug explicitly
21:33:50 <wwoods> oh right on then
21:34:22 <wwoods> hah
21:34:25 <adamw> so we can set to MODIFIED and note the tag  request in a comment
21:34:54 <adamw> #agreed 530945 is a blocker, tag request is already filed, bug set to MODIFIED and tag request noted
21:35:27 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=531675
21:35:28 <buggbot> Bug 531675: medium, low, ---, overholt, ASSIGNED, Content of update site needs refresh to be displayed
21:35:36 <adamw> this is really the last bug!
21:35:38 <wwoods> *during this meeting* the bug was prematurely closed, then reopened in order to ensure a tag request was filed, then the request was filed
21:35:58 <wwoods> epic
21:36:30 <adamw> as i mentioned, at the start of this meeting i didn't have grandchildren
21:36:54 <Oxf13> is that still true?
21:36:57 <wwoods> and now you are bouncing one upon your knee
21:37:07 <adamw> wwoods: actually, my first one just died of old age
21:37:11 <wwoods> ha.
21:37:28 <Oxf13> ok, I'm taking a break.
21:37:31 <wwoods> but so yeah, I'm confused about why an eclipse subpackage bug constitutes a release-blocker
21:37:44 <adamw> Oxf13: this is the last bug, so there'll be no more meeting to come back to finally :)
21:37:54 <adamw> yeah, i am not grokking this much
21:38:01 <adamw> eclipse folks seem to have a rather inflated view of its importance =)
21:38:21 <adamw> i think they view fedora as this annoying thing they have to install before they get to running their real operating environment...eclipse
21:38:30 <wwoods> that or it's the greatest thing since sliced bread and none of us graybearded vim/emacs users have realized it yet
21:38:40 <Oxf13> I use eclipse
21:38:59 <wwoods> I suggest we ask the maintainer if this can be fixed in a day-0 update
21:39:06 <adamw> well, to be fair comment #2 suggests it's a gtk+ issue
21:39:08 <adamw> which might be worse
21:39:18 <adamw> still, i don't think there's any indication this hits any other apps
21:39:56 <adamw> anyone know andrew's IRC nick?
21:40:14 <Oxf13> 'overholt'
21:40:16 <adamw> i think it's overholt
21:40:18 <adamw> right
21:40:21 <adamw> in which case he's not around
21:40:21 <Oxf13> but he's eastcoast time
21:41:11 <adamw> i don't think we'd object to them tagging the fixed build into final, but i don't see how it's a blocker
21:41:21 <adamw> agreed?
21:42:32 <wwoods> yeah, unless someone can better explain it - move it to Target or equiv.
21:43:03 <Oxf13> yeah
21:43:14 <adamw> #agreed 531675 is not serious enough to be a release blocker, but releng will accept a tag request if they want to put it in final. drop to target
21:43:28 <adamw> aaaaaand that IS the end of the list
21:43:48 <adamw> and our blocker list now actually fits on one 1050 high screen
21:44:05 <adamw> #topic open floor
21:44:15 <adamw> does anyone have any other bugs to add to the list? please GOD say no
21:44:22 <wwoods> very no!
21:44:49 <adamw> ending the Meeting from Hell in ~3 minutes if nothing is raised
21:45:03 <adamw> if anyone has proposals to shorten these meetings they would be extremely welcome - please send to test-list
21:45:06 <Oxf13> I raise a toaast
21:45:33 <adamw> to whom?
21:45:37 <adamw> (or what)
21:46:01 <Oxf13> to getting 'faced
21:46:07 <adamw> heheh
21:46:21 <wwoods> "let's drink to drinkin'" is a dangerously recursive toast
21:46:29 <adamw> the best kind
21:46:44 <Oxf13> we're all about self recursion.  I mean, we're linux geeks
21:46:48 <adamw> next time let's do it before the meeting
21:46:54 <adamw> i'm sure that'll help
21:46:57 <wwoods> here's to the blissful release of death
21:46:59 <Oxf13> "Fuck it, lets just ship it"
21:47:10 <wwoods> I mean blissful impending birth of the release
21:47:11 <adamw> (quick, someone say 'what do you mean NEXT time? hic')
21:47:36 <adamw> alright
21:47:38 <adamw> our torment is ended
21:47:43 <adamw> thanks a lot to everyone for sticking it out
21:47:48 <wwoods> here's to the "save it for f13" hammer
21:47:50 <adamw> it was long but at least PRODUCTIVE
21:48:04 <adamw> #endmeeting