16:00:21 <poelcat> #startmeeting Fedora 14 Final Blocker Review
16:00:21 <zodbot> Meeting started Fri Oct 15 16:00:21 2010 UTC.  The chair is poelcat. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:30 <poelcat> #topic roll call
16:00:33 * jlaska 
16:00:36 * poelcat 
16:00:40 * nirik is lurking around if there's anything he can help with.
16:00:48 <bcl> /me waves
16:00:54 * brunowolff is present
16:01:04 * red_alert is peeking in
16:01:04 * clumens THUD
16:01:41 <poelcat> hi everyone
16:01:58 <poelcat> adamw around?
16:02:44 <poelcat> should we jump in or is there someone we should wait for?
16:03:03 <jlaska> fyi, notting will be joining after some food
16:03:12 <Oxf13> lets just get it over with
16:03:15 <poelcat> #chair jlaska nirik brunowolff
16:03:15 <zodbot> Current chairs: brunowolff jlaska nirik poelcat
16:03:36 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=583906
16:03:37 <buggbot> Bug 583906: medium, low, ---, hdegoede, ASSIGNED, Backtrace in clearpart_gui when only uninitialized disks are found
16:03:43 * jlaska clicks
16:04:11 <jlaska> an oldie
16:04:59 <jlaska> definitely looks to be hitting the original failure
16:05:36 <adamw> morning
16:05:56 <Oxf13> this only ever said fixed in master, did it ever get onto the F14 branch?
16:06:05 <Oxf13> well, n/m.  04-23
16:06:10 <Oxf13> that was a long time ago
16:06:20 <pjones> yeah.
16:06:34 <poelcat> does it meet the release criteria?
16:06:39 <Oxf13> on the surface, it looks like a blocker
16:06:43 <jlaska> Sandro's use case does
16:06:59 <jlaska> BIOS RAID fits under "#  The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above "
16:07:04 <adamw> yeah
16:07:27 <jlaska> I think getting some input from someon on the installer side to see when/where this patch went in is the next step?
16:07:47 <poelcat> installer peeps, what's your take?
16:07:49 <Oxf13> so I'd vote to mark this a blocker until further information comes in
16:07:58 <clumens> commit fa95bd6e7ef28cc968afe1c03b89debf4c198066
16:07:59 <clumens> Author: Hans de Goede <hdegoede@redhat.com>
16:07:59 <clumens> Date:   Wed Apr 21 11:18:29 2010 +0200
16:08:21 <pjones> I think this looks like "hansg didn't update the bug when he jumped departments"
16:09:00 <poelcat> so...the patch didn't get applied?
16:09:07 <Oxf13> pjones: yes, that's part of it, but I think that would have just resulted in a re-opening rather than a just a new comment on the existing bug
16:09:33 <pjones> yeah
16:09:34 <Oxf13> we've got new people hitting it on 10-06 and 10-14
16:10:08 <bcl> poelcat: patch is in f14-branch
16:10:10 <red_alert> hansg closed the bug with his last comment, I (Sandro) reopened it just yesterday
16:10:25 <Oxf13> ah
16:10:53 <red_alert> and I never had that issue on the same hardware with Alpha/Beta - but I used the dvd back then and now the livecd in case that matters
16:10:56 <Oxf13> so it either wasn't fully fixed the first time, or we "regressed" somehow.  Either way, warrants investigation and qualifies as a blocker in my book
16:10:56 <poelcat> so we'eve established it is a blocker; have we established if their is a known fix?
16:11:11 <poelcat> s/their/there
16:11:12 <Oxf13> poelcat: I'd say no, there is no known fix
16:11:20 <clumens> since it just got reopened yesterday, no.  there is no fix.
16:11:21 <poelcat> installer people?
16:11:22 <jlaska> red_alert: is the new failure live image specific
16:11:25 <clumens> nor has there been any investigation.
16:11:44 * fcami waves
16:11:45 <red_alert> jlaska: didnt have time to check that yet but will try after meeting
16:11:52 <fcami> sorry to be late.
16:11:55 <poelcat> proposed #agreed
16:12:02 <jlaska> fcami: welcome
16:12:09 <fcami> ;)
16:12:16 <jlaska> clumens: https://bugzilla.redhat.com/attachment.cgi?id=451814
16:12:19 <jlaska> anaconda 13.42 exception report
16:12:33 <jlaska> that's F13 anaconda I Guess?
16:12:38 <clumens> well, anaconda-13.x is F13.
16:13:05 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=583906 is an accepted blocker bug; anaconda team will start investigation and fix ASAP
16:13:06 <clumens> yeah we stopped all that version number silliness (in fedora).  the major number indicates which fedora it shipped in.
16:13:06 <buggbot> Bug 583906: medium, low, ---, hdegoede, ASSIGNED, Backtrace in clearpart_gui when only uninitialized disks are found
16:13:15 <poelcat> ack/nak/patch?
16:13:21 <adamw> ack
16:13:30 <Oxf13> ack
16:13:53 <poelcat> anyone else?
16:14:14 <jlaska> ask
16:14:25 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=583906 is an accepted blocker bug; anaconda team will start investigation and fix ASAP
16:14:26 <buggbot> Bug 583906: medium, low, ---, hdegoede, ASSIGNED, Backtrace in clearpart_gui when only uninitialized disks are found
16:14:28 <fcami> I'm wondering how many people use that kind of setup
16:14:29 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=637064
16:14:30 <buggbot> Bug 637064: high, low, ---, jreznik, ASSIGNED, PolicyKit-KDE crash during shutdown
16:15:48 <Oxf13> still a bug, still a blocker
16:16:01 <jlaska> rdieter: around?
16:16:15 <rdieter> jlaska: hi
16:16:25 <adamw> it seems like this got fixed
16:16:31 <adamw> but the fix broke something more significant
16:16:36 <adamw> so now it's been reverted
16:16:40 <jlaska> yeah, that's what I was hoping rdieter could help clear up
16:16:58 <rdieter> adamw just gave the cliff's notes
16:17:13 <rdieter> jreznik/rnovacek are still working on finding a better fix
16:17:29 <Oxf13> so business as usual
16:17:38 <jlaska> okay, so we know who has the ball
16:17:52 <rdieter> yep
16:18:33 <adamw> rdieter: they're aware of the timeframe right?
16:18:35 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=637064 jreznik/rnovacek are still working on finding a better fix; accepted blocker
16:18:36 <buggbot> Bug 637064: high, low, ---, jreznik, ASSIGNED, PolicyKit-KDE crash during shutdown
16:18:42 <rdieter> adamw: if not, I'll remind them
16:18:52 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=637064 jreznik/rnovacek are still working on finding a better fix--needed ASAP; accepted blocker
16:18:53 <buggbot> Bug 637064: high, low, ---, jreznik, ASSIGNED, PolicyKit-KDE crash during shutdown
16:18:56 <poelcat> ack/nak/patch?
16:18:59 <fcami> ack
16:19:08 <adamw> ack
16:20:04 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=637064 jreznik/rnovacek are still working on finding a better fix--needed ASAP; accepted blocker
16:20:06 <buggbot> Bug 637064: high, low, ---, jreznik, ASSIGNED, PolicyKit-KDE crash during shutdown
16:20:07 <jlaska> ack
16:20:09 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=584328
16:20:10 <buggbot> Bug 584328: medium, low, ---, dlehman, ASSIGNED, AttributeError: 'NoneType' object has no attribute 'name'
16:20:21 <poelcat> should we review dependent bugs first?
16:20:28 <Oxf13> this saga
16:20:39 <notting> back now, sorry about that
16:21:00 <pjones> I'm hoping to have this whole shitpile cleared up this afternoon
16:21:02 <jlaska> poelcat: yeah, I think we can note the status here and move to the deps?
16:21:18 <jlaska> pjones: anything else we need to add here, other than 'waiting'
16:21:25 <fcami> this one looks like the train of pain
16:22:07 <pjones> it's actually pretty straightforward, but some of the testing has taken a bit longer than I'd hoped for.
16:22:22 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=584328 pjones should have it cleared up this afternoon
16:22:25 <buggbot> Bug 584328: medium, low, ---, dlehman, ASSIGNED, AttributeError: 'NoneType' object has no attribute 'name'
16:22:26 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=641474
16:22:27 <buggbot> Bug 641474: medium, high, ---, agk, ASSIGNED, libdm does not present method to assign UUID after map creation
16:22:34 <pjones> poelcat: hope to, not should ;)
16:22:42 <poelcat> "will" ;-)
16:23:55 <poelcat> anyone know if the "little testing" has taken place?
16:24:27 <pjones> on this one there's a bug in the patch, but it looks pretty simple to fix, so I'll be working on it again right after this meeting.
16:24:41 <pjones> this is the big stall point here
16:25:23 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=641474 pjones working on it
16:25:24 <buggbot> Bug 641474: medium, high, ---, agk, ASSIGNED, libdm does not present method to assign UUID after map creation
16:25:27 <poelcat> anything for this bug?
16:25:52 <pjones> that's the same bug we were just talking about.
16:25:57 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=641476
16:25:58 <buggbot> Bug 641476: medium, high, ---, agk, ASSIGNED, devicemapper UUID field cannot be assigned after map creation
16:26:06 <poelcat> pjones: same thing again? :)
16:26:41 <pjones> the patch is in for this one, we just haven't marked it until we test the whole stack
16:27:36 <poelcat> proposed #agreed https://bugzilla.redhat.com/show_bug.cgi?id=641476 patch is in, needs to be integrated with whole stack
16:27:37 <buggbot> Bug 641476: medium, high, ---, agk, ASSIGNED, devicemapper UUID field cannot be assigned after map creation
16:27:39 <poelcat> ack/nak/patch?
16:28:08 <fcami> ack from me, at least.
16:28:12 <brunowolff> Is there a way to test this feature of the -43 kernel without doing an install?
16:28:27 <brunowolff> I am currently running -43 on three machines without a problem.
16:28:32 <pjones> yeah, I can test this with the libdm change and a bit of test harness from userland
16:28:32 <Oxf13> ack
16:28:41 <jlaska> ack-a-roo
16:28:42 <adamw> ack
16:28:49 <pjones> this patch is strictly additive; existing stuff shouldn't change at all
16:29:02 <Oxf13> basically ack this whole mess for "pjones hopes to clear up this whole mess this afternoon"
16:29:04 <adamw> has anyone been secretary-ing so far?
16:29:08 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=641476 patch is in, needs to be integrated with whole stack
16:29:09 <buggbot> Bug 641476: medium, high, ---, agk, ASSIGNED, devicemapper UUID field cannot be assigned after map creation
16:29:11 <fcami> *cough* everything else should work as it used to be afterwards *cough*
16:29:11 <adamw> Oxf13: yup, +1
16:29:16 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=641846
16:29:17 <buggbot> Bug 641846: medium, low, ---, adel.gadllah, ASSIGNED, Panel applets (clock, workspace switcher, window selector, ...) randomly disappear
16:29:19 <pjones> and the failure mode if I'm wrong would be that setting dm names wouldn't work.  Everybody would have noticed by now ;)
16:29:21 <poelcat> adamw: no :-/
16:29:30 <adamw> oh fun
16:29:32 <adamw> i'll go back and catch up
16:29:42 <adamw> if i'm slow, assume me to agree with the most sensible person in the room
16:29:42 <poelcat> adamw: though everything has been pretty clear cut
16:29:48 <adamw> ;)
16:31:03 <jlaska> so halfline notes in comment#17 that this seems to be specific to compiz
16:31:08 <Oxf13> compiz.
16:31:09 <Oxf13> -1 blocker
16:31:26 <poelcat> is there anyone here that believes this is a blocker bug?
16:31:44 <jlaska> certainly not the default window decorator/manager/thingie, and easy to resolve this post release should a fix come in
16:31:50 <jlaska> -1 blocker
16:32:42 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=641846 this bug is not a blocker bug because not the default window decorator/manager/thingie, and easy to resolve this post release should a fix come in
16:32:44 <buggbot> Bug 641846: medium, low, ---, adel.gadllah, ASSIGNED, Panel applets (clock, workspace switcher, window selector, ...) randomly disappear
16:32:48 <poelcat> ack/nak/patch?
16:32:55 <Oxf13> ack
16:32:59 <brunowolff> It also looks like it isn't a regression bewteen F13 and F14.
16:33:12 <fcami> ack too. the bug is in f13 and doesn't seem to be easily reproductible.
16:33:13 <brunowolff> ack
16:33:25 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=641846 this bug is not a blocker bug because it is not the default window decorator/manager/thingie, and easy to resolve this post release should a fix come in
16:33:26 <buggbot> Bug 641846: medium, low, ---, adel.gadllah, ASSIGNED, Panel applets (clock, workspace switcher, window selector, ...) randomly disappear
16:33:29 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=643395
16:33:30 <buggbot> Bug 643395: medium, low, ---, tcallawa, NEW, generic-logos is newer than fedora-logos ... resulting in wrong logos package being installed for Fedora 14
16:33:34 <fcami> we could bump prio though
16:33:37 * jlaska added this today
16:33:48 <poelcat> i can haz h0tdog
16:33:58 <fcami> that too
16:34:04 <Oxf13> haha that's a fantastic result
16:34:05 <clumens> closed->notabug
16:34:07 <jlaska> haha!
16:34:12 <Oxf13> we're just getting ahead of the F15 feature
16:34:14 <jlaska> CLOSED->WORKSASCODED
16:34:26 <jlaska> I felt horrible filing this bug
16:34:26 <Oxf13> CLOSED->DONTFEARTHEHOTDOG
16:34:30 <jlaska> :))
16:34:36 <Oxf13> +1 blocker.
16:34:48 * jlaska filed and escalated, so I'm a +1
16:35:06 * jlaska wonders what would happen if we nack'd this as a blocker :)
16:36:08 <notting> there was actually a blog post on the planet about people wanting to replace the hot dog. sad.
16:36:11 <brunowolff> If the packaging is only in testing, how is it a blocker?
16:36:20 <jlaska> brunowolff: great point ...
16:36:27 <brunowolff> Can't we just hold off the update until after the release/
16:36:29 <jlaska> technically this isn't a blocker ...
16:36:45 <jlaska> but I was worried/unclear whether this might land prior to F-14 being finalized
16:36:56 <pjones> notting: I'm definitely -1 to the taco
16:36:57 <jlaska> even then ... we don't want this in F-14
16:37:02 <jlaska> right?
16:37:11 <Oxf13> not without a matching fedora-logos
16:37:16 <jlaska> so in F-14 ... fedora-logos must match generic-logos
16:37:17 <poelcat> what is the proposed action for this bug?
16:37:19 <jlaska> Oxf13: right on
16:37:23 <Oxf13> I think it's right to have this on the blocker, so that we can pull the update and close the bug
16:37:24 * adamw is all caught up with secretarying
16:37:28 <jlaska> poelcat: I think we need spot to do a rebuild
16:37:31 <pjones> poelcat: bump the version on f-l and rebuild
16:37:37 <jlaska> adamw: THANK YOU!
16:37:38 <adamw> yeah, +1 blocker
16:38:08 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=643395 accepted blocker; need spot to bump the version and do a rebuild ASAP
16:38:09 <buggbot> Bug 643395: medium, low, ---, tcallawa, NEW, generic-logos is newer than fedora-logos ... resulting in wrong logos package being installed for Fedora 14
16:38:17 <jlaska> dumb question ...
16:38:22 <brunowolff> -1 blocker, making sure the update stays in testing until a matching fedora-logos is ready is good enough.
16:38:26 <notting> there's already a fedora-logos in updates-testing that has other issues
16:38:38 <adamw> when we say 'bump the version', we mean 'the version of fedora-logos' right? not generic-logos
16:38:40 <clumens> shouldn't the bug be something like "fedora is not fully ready for the glory of the hot dog"?
16:38:47 <jlaska> adamw: yes, good clarification
16:39:13 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=643395 accepted blocker; need Spot to bump the version of fedora-logos and do a rebuild ASAP
16:39:14 <buggbot> Bug 643395: medium, low, ---, tcallawa, NEW, generic-logos is newer than fedora-logos ... resulting in wrong logos package being installed for Fedora 14
16:39:16 <jlaska> brunowolff: I'm not sure that's enough ...
16:39:18 <Oxf13> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=643395 accepted blocker; do not allow this update to go into F14 as is.
16:39:19 <buggbot> Bug 643395: medium, low, ---, tcallawa, NEW, generic-logos is newer than fedora-logos ... resulting in wrong logos package being installed for Fedora 14
16:39:33 <jlaska> brunowolff: since just enable 'updates-testing' during install and you get a screwy un-F14 like system
16:39:39 <Oxf13> poelcat: I think that makes things more simple, and allows the maintainer to decide how best to fix the situation
16:39:45 * pjones steps out
16:39:47 <adamw> jlaska: for me it's more about making sure it doesn't somehow get in accidentally
16:40:02 <poelcat> Oxf13: how do we make sure it gets blocked?
16:40:03 <adamw> so i like oxf13's take
16:40:03 <jlaska> adamw: Oxf13: yeah, agreed on both points
16:40:08 <poelcat> pjones: thanks!
16:40:22 <adamw> poelcat: either a new fedora-logos gets submitted or this update gets un-submitted
16:40:34 <brunowolff> Should generic-logos conflict with fedora-logos with a lower version?
16:40:44 <jlaska> brunowolff: I was thinking that too
16:40:48 <adamw> yeah, seems like we should enforce this kind of thing in package deps
16:41:04 <jlaska> brunowolff: can you add that to bz?
16:41:16 <jlaska> I'm sure spot will have some thoughts as to why that might be good/bad etc...
16:41:17 <Oxf13> I've given the current update negative karma
16:41:20 <brunowolff> It might not help when composing images, but should work with installed systems.
16:41:25 <Oxf13> more of you can do it too.
16:41:42 <poelcat> okay, once and for all... proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=643395 accepted blocker; do not allow this update to go into F14 as is
16:41:43 <buggbot> Bug 643395: medium, low, ---, tcallawa, NEW, generic-logos is newer than fedora-logos ... resulting in wrong logos package being installed for Fedora 14
16:41:45 <poelcat> ack/nak/patch?
16:41:59 <adamw> ack
16:42:06 <Oxf13> ack
16:42:09 <brunowolff> Yes, I will add a note to the bugzilla with the conflicts idea.
16:42:25 <fcami> ack
16:42:30 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=643395 accepted blocker; do not allow this update to go into F14 as is + brunowolff to add a note to the bugzilla with the conflicts idea
16:42:31 <buggbot> Bug 643395: medium, low, ---, tcallawa, NEW, generic-logos is newer than fedora-logos ... resulting in wrong logos package being installed for Fedora 14
16:42:40 <jlaska> brunowolff: thx
16:42:42 <poelcat> #topic Where do we go from here?
16:42:58 <poelcat> i think we hit all the NEW/ASSIGNED/MODIFIED
16:43:04 <poelcat> but PLEASE double check me
16:43:09 <jlaska> In the previous release, we missed a few bugs since they were on the MODIFIED list and we weren't actively tracking them in this meeting
16:43:31 <poelcat> jlaska: strangely I don't see any in modified
16:43:36 <Oxf13> all are ON_QA ?
16:43:40 <jlaska> Perhaps that was more of an issue with MODIFIED bugs not being attached to bodhi
16:43:44 <jlaska> Oxf13: right, Ithink that was the problem
16:43:46 <poelcat> https://bugzilla.redhat.com/showdependencytree.cgi?id=538277&hide_resolved=1
16:44:03 <jlaska> that's looking good
16:44:18 * poelcat was going to say the same thing
16:44:22 <notting> modified would imply added to bodhi update, but not pushed yet
16:44:24 <Oxf13> ok, should we take a quick tour through the Final: Accepted bugs?
16:44:38 <Oxf13> notting: or would imply a maintainer made the change somewhere, and hasn't done a build yet
16:44:52 <poelcat> so it seems we're mostly waiting for anaconda fixes and then we are ready for Monday, unless we have new blocker additions?
16:45:07 <adamw> we can do an NTH review
16:45:11 <adamw> i'm still catching up with the last bug
16:45:15 <poelcat> and the one KDE bug
16:45:27 <poelcat> adamw: do you want to lead the NTH review?
16:45:32 <adamw> i'm looking at Bodhi; i see the update which only includes generic-logos is now listed as 'obsolete'
16:45:42 <adamw> (that's https://admin.fedoraproject.org/updates/kde-settings-4.5-8.fc14,fedora-logos-14.0.0-2.fc14,generic-logos-14.0.1-2.fc14 )
16:45:57 * mcepl would like to ask Oxf13 to ping me when you'll be free. About https://bugzilla.redhat.com/show_bug.cgi?id=638690#c19
16:45:59 <buggbot> Bug 638690: medium, low, ---, sgehwolf, MODIFIED, Canot build an example project .... freezes on download
16:46:03 <rdieter_work> adamw: I just dropped fedora-logos
16:46:04 <mcepl> sorry
16:46:25 <rdieter_work> from, https://admin.fedoraproject.org/updates/F14/FEDORA-2010-16342
16:46:25 <adamw> rdieter: ah, yup, thanks
16:46:50 <adamw> poelcat: sure, let me gin up a list for you
16:47:12 <adamw> sorry i didn't have it prepared, i was out watching noisy japanese indie until 3am last night :P
16:47:28 <jlaska> adamw: I don't even know what that is :)
16:48:09 <jlaska> while they are NTH, I'm concerned that some of those deps bugs may slip through the cracks
16:48:11 <poelcat> thanks to everyone for their help with the blocker bugs this past week... made this meeting so much easier!
16:48:28 <jlaska> AMEN!
16:48:45 <adamw> http://tinyurl.com/22sa3hb
16:49:02 <poelcat> adamw: you want me to call them out?
16:49:03 <adamw> is the not-yet-reviewed NTH bug list
16:49:16 <adamw> i figure we don't really need to look at accepted NTH issues, just review and accept/reject candidates
16:49:19 <adamw> poelcat: please!
16:49:20 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623824
16:49:21 <buggbot> Bug 623824: medium, low, ---, bnocera, NEW, Won't display on VGA-connected monitor
16:49:44 <adamw> we reviewed this before but turns out we probably got it wrong
16:49:46 <adamw> so i re-proposed it
16:50:36 <adamw> i also brought it up on the desktop ML
16:50:36 <adamw> http://lists.fedoraproject.org/pipermail/desktop/2010-October/006596.html
16:50:56 <adamw> so it seems like upstream GNOME introduced a gconf key to control the behaviour of 'external' displays and set it to default to 'don't use them'
16:51:07 <adamw> previously, GNOME's default was simply 'do whatever X does'
16:51:33 <adamw> in Fedora and recent upstream, X defaults to spanning across all connected displays; previously it defaulted to clone mode. it never defaulted to 'just turn them off'
16:52:26 <adamw> so since this isn't some kind of single bug but a change to default GNOME configuration that we may not agree with, i re-proposed it for nth
16:53:04 <adamw> ...and my little story is done
16:53:10 <jlaska> adamw: is there a proposed fix we'd need ot address the issue?
16:53:19 <adamw> yeah, we change the new gconf key's default
16:53:21 <Oxf13> I agree with NTH
16:53:29 <adamw> it's a one-worder: 'false' -> 'true'
16:53:29 <poelcat> and it's easy to test, correct?
16:53:31 <adamw> yes
16:53:49 * jlaska re-confirms upstream behavior by reading up
16:54:07 <Oxf13> but really it's a matter of "do we agree with upstream, and who is the "we" that gets to decide?"
16:54:21 <adamw> desktop team
16:54:24 <jlaska> yeah, I feel like @desktop should weigh in here
16:54:28 <jlaska> (or did they already)
16:54:30 <brunowolff> Wouldn't mirroring make more sense for the default?
16:54:31 <adamw> the upstream commit is http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-2-32&id=67958ef6faab5797d5c5ad939db36f393706984a , btw
16:54:39 <adamw> jlaska: they did, it was mclasen who pointed me to the upstream commit
16:54:49 <jlaska> adamw: oh great
16:55:06 <adamw> brunowolff: it's kind of an impossible question because clone is 'obviously' the right config in some multi-display cases and span is 'obviously' the right config in others
16:55:08 <jlaska> my only worry is that it's a visible change at the end
16:55:36 <Oxf13> adamw: what was their weigh in?  "We agree with upstream" ?
16:55:36 <jlaska> how long have we been testing with this new default gconf value
16:55:43 <adamw> the upstream commit seems to be written as if it applies only to the case of a laptop with an external display attached, not a desktop with multiple displays, but i'm not sure it can actually make the distinction in practice
16:55:45 <brunowolff> But it is easier to go from clone to span than from span to clone if something is odd.
16:56:03 <adamw> Oxf13: it was actually bastien, sorry
16:56:19 <adamw> he wrote 'To me, given the commit: it certainly doesn't look intentional. And it shouldn't be changing the already existing monitor setup, that's certain."
16:56:47 <adamw> but the discussion didn't really go past that
16:56:54 <adamw> should we try and find mclasen / hadess?
16:57:52 <Oxf13> yeah, probably just re-ping the list or find them on IRC and see if they want to "fix" this prior to RC
16:58:01 <Oxf13> or just delay it and do it as a 0(+)day update
16:58:10 <poelcat> how aobut we go onto next bug and circle back on this one?
16:58:13 <adamw> sure
16:58:20 <Oxf13> #proposal  IF they want to fix this, we would take this as NTH
16:58:28 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=641468
16:58:29 <buggbot> Bug 641468: medium, low, ---, kernel-maint, NEW, Touchpad does not work on 2010 Sony Vaio Z (upstream patch available)
16:58:30 <adamw> shall we accept it as an NTH on the basis that if desktop team wants to change it we'll take the change?
16:58:37 <adamw> sorry, poel, can you go back?
16:58:37 <poelcat> oops
16:58:43 <adamw> Oxf13: heh, same idea :)
16:58:44 <poelcat> how?
16:58:44 <Oxf13> adamw: that's what I was proposing.
16:58:48 <poelcat> #undo
16:58:48 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2b5233a27950>
16:59:01 <Oxf13> re-do the previous #topic
16:59:07 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623824
16:59:08 <buggbot> Bug 623824: medium, low, ---, bnocera, NEW, Won't display on VGA-connected monitor
16:59:09 <jlaska> poelcat: yeah, I believe you just need to redo #topic
16:59:11 <adamw> ok
16:59:21 <adamw> so i ack oxf13's proposal or mine, whichever
17:00:11 <jlaska> I'm a little uncertain for NTH
17:00:16 <adamw> i agree with jlaska that it's a late change to something visible but we're only changing it back to how it was
17:00:22 <jlaska> just a fairly visible change in behavior
17:00:32 <adamw> so whether it's a 'change' depends on your perspective :)
17:00:43 <adamw> if we don't fix it and you go from f13 to f14, you'll see a 'change'
17:00:45 <jlaska> depends on what the meaning of the word 'is' is :)
17:00:49 <adamw> exactly :P
17:01:06 <Oxf13> the change happened
17:01:09 <poelcat> proposed #action  https://bugzilla.redhat.com/show_bug.cgi?id=623824 if desktop team wants to revert behavior and fix this bug we believe it meets the criteria for NTH and would be approved
17:01:10 <buggbot> Bug 623824: medium, low, ---, bnocera, NEW, Won't display on VGA-connected monitor
17:01:12 <Oxf13> we're discussing reverting the change or living with it
17:01:19 <poelcat> ack/nak/patch?
17:01:21 <Oxf13> that decision lies with the desktop team
17:01:29 <jlaska> Oxf13: understood, we've just been testing *with* the change for most of the release now.
17:01:46 <jlaska> ack for now ... if I have any new concerns/data I'll bring it to the bz
17:01:54 <adamw> jlaska: i'm not hugely worried from a QA angle on this, randr behaviour is pretty well understood and that's all that would be changed
17:01:54 <Oxf13> ack
17:01:55 <jlaska> adamw: thanks for discussing
17:02:09 <poelcat> #action  https://bugzilla.redhat.com/show_bug.cgi?id=623824 if desktop team wants to revert behavior and fix this bug we believe it meets the criteria for NTH and would be approved
17:02:10 <buggbot> Bug 623824: medium, low, ---, bnocera, NEW, Won't display on VGA-connected monitor
17:02:10 <jlaska> adamw: okay,
17:02:13 <poelcat> next bug?
17:02:14 <jlaska> adamw: s/,$//
17:02:49 <adamw> yup
17:02:54 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=641468
17:02:55 <buggbot> Bug 641468: medium, low, ---, kernel-maint, NEW, Touchpad does not work on 2010 Sony Vaio Z (upstream patch available)
17:03:30 <Oxf13> ngghh kernel...
17:03:43 <Oxf13> but I suppose if we have some other reason to rev the kernel, we could take this.
17:03:44 <adamw> yeah, this is just me trying to get my pet patch in the damn kernel
17:04:05 <adamw> we already need a newer build than was in tc1 but i don't know if we already approved a kernel update with the blocker fixes
17:04:20 * jlaska looking at patch
17:04:50 <adamw> honestly if this was someone else's bug i'd be on the fence =) but i'd just like people with my laptop to have a trackpad that works when they boot...i've been testing the patch for months here and it's fine, though obviously that doesn't cover potential regressions
17:04:54 <adamw> on other systems
17:05:08 <adamw> hey mclasen
17:05:15 <adamw> we moved on from the desktop bug but we'll circle back in a minute
17:05:27 <mclasen> not sure I have much to add, but sure...
17:05:30 <adamw> in a way this would be safer post-release, but then it's 'broken' out of the box...
17:06:05 <jlaska> adamw: you note that even with the patch, it still fails 1/10 times?
17:06:15 <jsmith> adamw: Is it worth slipping for?  I mean, that's the definition of blocker, right?
17:06:30 <jsmith> adamw: I'm having a hard time seeing how this isn't a "nice to have patch"
17:06:50 <jlaska> jsmith: adamw's proposed this as a nice-to-have issue, so your right, this wouldn't block the release if it wasn't fixed in time
17:06:52 <adamw> jsmith: we're reviewing for NTH status
17:07:01 <adamw> jsmith: we moved on to the NTH review portion of the meeting :P
17:07:10 <Oxf13> jsmith: it's such a narrow hardware case that i don't believe it qualifies as a release blocker.
17:07:18 <adamw> again, not proposed as a blocker
17:07:39 <jsmith> Ah, sorry
17:07:46 <jsmith> I didn't realize we'd moved on to NTH issues
17:07:49 <jsmith> Sorry for the noise
17:08:01 * jsmith should multitask less, it seems
17:08:17 <jlaska> jsmith: me too!
17:08:28 <jlaska> okay, so this bug
17:08:49 <jlaska> adamw: +++ b/drivers/pnp/pnpacpi/core.c
17:08:50 <Oxf13> I'm ack NTH, should we need to rev the kernel for anything else
17:08:57 <Oxf13> I don't really want to see a kernel update just for this issue
17:09:04 <jlaska> is that a specific driver, or a range of drivers available on other hardware?
17:09:10 * jsmith agrees with Oxf13
17:09:11 <jlaska> Oxf13: yeah, agreed
17:09:30 <adamw> it's a generic bit of code that affects a lot of hardware, not just my laptop
17:09:36 <adamw> so yeah, there's theoretical regression potential
17:09:40 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=641468 accept as NTH if we pull in a new kernel for other reasons
17:09:41 <buggbot> Bug 641468: medium, low, ---, kernel-maint, NEW, Touchpad does not work on 2010 Sony Vaio Z (upstream patch available)
17:09:52 <poelcat> ack/nak/patch?
17:10:09 <adamw> what the patch does though is be *more* robust about stupid hardware, so it shouldn't make anything that already works not work
17:10:10 <jsmith> Assuming the kernel team is OK with taking the patch, I'm for ACK
17:10:26 <jlaska> adamw: ah, we like those changes
17:10:29 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=641468 accept as NTH if we pull in a new kernel for other reasons and the kernel team is willing to accept the patch
17:10:30 <buggbot> Bug 641468: medium, low, ---, kernel-maint, NEW, Touchpad does not work on 2010 Sony Vaio Z (upstream patch available)
17:10:30 <Oxf13> ack
17:10:32 <adamw> as hardware that's not dumb and hence was working before won't need to hit the 'okay, let's deal with the dumb hardware' exception paths the patch implements
17:10:35 <brunowolff> ack
17:10:38 <adamw> ack
17:10:40 <jlaska> ack
17:10:53 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=641468 accept as NTH if we pull in a new kernel for other reasons and the kernel team is willing to accept the patch
17:10:54 <buggbot> Bug 641468: medium, low, ---, kernel-maint, NEW, Touchpad does not work on 2010 Sony Vaio Z (upstream patch available)
17:11:02 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=643416
17:11:03 <buggbot> Bug 643416: medium, low, ---, mgracik, NEW, F14 TC1.1 LXDE Spin: Unable to input any character to text box in User Manager screen.
17:12:30 <Oxf13> seems reasonable NTH.
17:12:40 <Oxf13> meets release criteria
17:13:15 <adamw> yeah, it's a non-default-desktop criteria issue so pretty much automatic NTH
17:13:25 <jlaska> agreed, this meets our agreement for F-14 concerning non-default desktops
17:13:32 <jlaska> +1 NTH
17:14:34 <jsmith> +1 NTH for me as well
17:14:38 <poelcat> #action accepted as https://bugzilla.redhat.com/show_bug.cgi?id=643416
17:14:39 <buggbot> Bug 643416: medium, low, ---, mgracik, NEW, F14 TC1.1 LXDE Spin: Unable to input any character to text box in User Manager screen.
17:14:48 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=642449
17:14:49 <buggbot> Bug 642449: medium, low, ---, notting, NEW, Fedora 14 non-media repoclosure tracking bug
17:15:09 <adamw> that one's a tracking bug, ignore it
17:15:15 <jlaska> well ...
17:15:20 <jlaska> do we want to talk through each dep issue?
17:15:27 <adamw> excuse me while i get my gun
17:15:44 <jlaska> right, so is there anything to discuss in general regarding those issues
17:15:59 <adamw> are there any in particular you're worried about?
17:16:12 <jlaska> yeah ...
17:16:13 <adamw> a lot of them are in on_qa, do we need to karma them up?
17:16:16 <jlaska> one moment ...
17:16:50 <jlaska> Oxf13: I might need your input here
17:16:51 <jlaska> https://bugzilla.redhat.com/show_bug.cgi?id=640768#c9
17:16:52 <buggbot> Bug 640768: medium, medium, ---, jgarzik, ON_QA, Broken dependency: chunkd-0.6-0.8.gc49c6d38.fc14 requires libchunkdc.so.0()(64bit)
17:17:15 <jlaska> long-story short, a fix is available but it seems like multi-lib push issue?
17:17:47 <Oxf13> jlaska: actually I bet it's a mirror broken issue
17:18:34 <jlaska> anything I need to do here to ensure this gets lined up properly?
17:19:06 <Oxf13> wait, I'm wrong.
17:19:09 <Oxf13> this is quite odd...
17:19:29 <Oxf13> oh bollux
17:19:36 * jsmith will be back later
17:19:44 <jlaska> jsmith: catch you later, thanks!
17:19:55 <Oxf13> looking at the package itself for a moment
17:20:09 * poelcat is good for 10 more minutes then will need to hand the wheel to someone else
17:20:12 <jlaska> Oxf13: should we follow-up after meeting, or keep discussing?
17:20:14 <Oxf13> wtf?!
17:20:20 <Oxf13> in git, chunkd is dead.packaged
17:20:29 <Oxf13> it's now in 'hail'
17:20:41 <jlaska> Oxf13: hail now ... yeah
17:21:04 <Oxf13> the maintainer never had us block chunkd
17:21:08 <Oxf13> so we're shipping both hail and chunkd
17:21:16 <jlaska> chunky hail
17:21:21 <jlaska> that's a bad forecast
17:21:21 <Oxf13> so we need to block chunkd
17:21:35 <jlaska> Oxf13: I'll ask maintainer to submit a rel-eng ticket?
17:21:43 <Oxf13> I'll just do the blocking
17:21:47 <jlaska> k
17:21:50 <jlaska> Oxf13: thanks
17:22:02 <jlaska> Oxf13: would you mind updating the bz when you're done, just so they know too?
17:22:05 <Oxf13> k
17:22:08 <jlaska> (or I can if you gimme the goods)
17:22:55 <jlaska> I think there was 1 more issue ...
17:23:28 <Oxf13> done and done
17:23:47 <jlaska> Oxf13: thanks
17:23:51 <jlaska> well, that's the only one I had
17:24:00 <jlaska> my only thought now is to make sure these get the karma needed
17:24:03 <adamw> ok
17:24:05 <jlaska> otherwise, we'll be stuck with ... https://fedorahosted.org/pipermail/autoqa-results/2010-October/047561.html
17:24:08 <adamw> so we should all go through the list and check them
17:24:15 <jlaska> I'll go through and add karma later today
17:24:31 <adamw> btw...did we hit 639146 during the meeting?
17:24:32 <poelcat> proposed #actions ?
17:24:33 <jlaska> #action jlaska to add karma feedback to auto-filed repoclosure bugs that are no longer an issue
17:24:38 <adamw> i don't recall discussing it...but it's a f14blocker and ASSIGNED
17:25:20 <red_alert> new intellij-idea has just been pushed to stable by spot, btw
17:25:23 <jlaska> poelcat: I think w're ready to move on ... I took an #action, and Oxf13 fixed the core issue
17:25:38 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639146
17:25:39 <buggbot> Bug 639146: high, low, ---, ajax, NEW, Blank display (backlight on) after KMS initialization
17:26:08 <Oxf13> I'm going with ajax on that one
17:26:11 * poelcat appologizes for missing earlier.. thanks adamw
17:26:13 <Oxf13> not a blocker
17:26:53 <adamw> the change from previous discussion here is that even though this is a regression, it's not simple to fix
17:26:59 <notting> didn't we already state we weren't touching eDP?
17:27:15 <adamw> no, that was in re a different bug, we accepted this one as a blocker last week as it looked to be a regression
17:27:43 <adamw> which technically speaking it is, but in fact it was dumb luck that it worked with the pre-2.6.34 code, and there's no way we can simply revert some one-liner and make it work again, the codebase has totally changed
17:28:02 <adamw> i've had the reporters test a variety of edp code bases and potential small fixes and come up blank so far
17:28:17 <adamw> so given that this is a 'wiggle room' issue and it looks like we can't find a simple fix...i can see downgrading it
17:28:39 <Oxf13> yeah, this looks more dangerous to fix than to leave alone
17:28:53 <jlaska> good to have tried and have this supporting data
17:28:56 <adamw> we should probably get them to check if vesa works
17:29:06 <adamw> if it does then we at least have a documented workaround: install vesa, wait for a kernel update
17:29:17 <jlaska> good thinking
17:30:20 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=639146 no longer considered a blocker; have a documented workaround: install vesa, wait for a kernel update
17:30:21 <buggbot> Bug 639146: high, low, ---, ajax, NEW, Blank display (backlight on) after KMS initialization
17:30:23 <poelcat> ack/nak/patch?
17:30:32 <Oxf13> ack
17:30:47 <adamw> proposed #agreed: the codebase relevant to 639146 has changed completely since 2.6.33 so our previous evaluation of it no longer applies: now given that a fix would be dangerous we decided to change it to not-blocker status
17:31:19 <jlaska> ack to both
17:31:31 <adamw> ack to either
17:31:49 <poelcat> #agreed https://bugzilla.redhat.com/show_bug.cgi?id=639146 the codebase relevant to 639146 has changed completely since 2.6.33 so our previous evaluation of it no longer applies: now given that a fix would be dangerous we decided to change it to not-blocker status; have a documented workaround: install vesa, wait for a kernel update
17:31:50 <buggbot> Bug 639146: high, low, ---, ajax, NEW, Blank display (backlight on) after KMS initialization
17:31:58 <poelcat> can someone else drive?
17:32:22 <jlaska> sure ... what's the NTH list we're working from?
17:32:41 * jlaska pulls up NTH dependency list
17:33:01 <adamw> if mclasen's still around, we can come back to the desktop multihead one
17:33:14 <jlaska> adamw: sure, take it away
17:33:15 <poelcat> two left 538277 and 635779
17:33:18 <jlaska> poelcat: thx
17:33:22 <adamw> mclasen: still there?
17:33:26 <mclasen> I'm here
17:33:28 <poelcat> and the multihead one :)
17:33:41 <poelcat> i'll loop back later and pickup meetbot summary and send to lists
17:33:42 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623824
17:33:43 <buggbot> Bug 623824: medium, low, ---, bnocera, NEW, Won't display on VGA-connected monitor
17:34:02 <adamw> mclasen: so we agreed to accept a fix if you want to change this, i guess we just wanted to make sure desktop team makes a decision one way or the other
17:34:08 <adamw> mclasen: it's the one i flagged up on the ml
17:34:34 <mclasen> is there a patch ?
17:34:40 * mclasen not up to speed on f14
17:35:08 <mclasen> ok, found it
17:35:09 <adamw> well, one change would be obvious - see the commit bastien flagged up, change 'false' to 'true'
17:35:36 <adamw> though i do have a few functional questions...it's not clear to me exactly how that's supposed to work, how does it distinguish 'laptop plus external display' from any other multihead setup? is gnome capable of that?
17:36:06 <mclasen> look for a plug named LVDS or something like that
17:36:07 <mclasen> I guess
17:36:09 <adamw> and it looks like the way it's written, if we change the 'false' to 'true' it'll then default to *cloning*, not spanning as is the X default...or is that function with 'clone' in the name misleadingly named?
17:36:13 <mclasen> haven't looked at the code
17:37:07 <adamw> ok, maybe i'll just follow up to the list and we can look into it there
17:37:20 <mclasen> yeah, I'll have to find the thread first
17:37:24 <mclasen> and look at the code
17:38:28 <adamw> ok
17:38:33 <adamw> thanks...
17:38:37 <adamw> let's move on to the other two NTHs
17:38:48 <jlaska> any #action's to list?
17:39:11 <mclasen> to finish that off, my reading of the code is that indeed, changing the default will make us come up in clone mode on fresh installs
17:39:32 * jlaska wonders, does this include the dual-monitor behavior for gdm/
17:39:35 <jlaska> ?
17:39:42 <jlaska> s/include/also impact/
17:40:13 <mclasen> yes, gsd runs in the login session too
17:40:26 <jlaska> ah, so that explains an issue I was seeing
17:40:41 <jlaska> okay ... changing #topic shortly ...
17:40:42 <jlaska> mclasen: thanks!
17:40:56 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=635779
17:40:57 <buggbot> Bug 635779: medium, low, ---, gavin, ON_QA, Traceback screen doesn't properly display link to bugzilla information
17:41:14 <jlaska> This was filed a while back, but never really deemed a *blocker*
17:41:31 <jlaska> with our newly defined process for NTH, I added this to the list
17:41:37 <adamw> nice
17:41:45 <jlaska> basically ... for non-live installs, when you tracback, it shows the link to bugzilla twice
17:41:53 <jlaska> this fix, makes it show it once
17:41:56 <adamw> looks like a reasonable nth to me
17:42:05 * jlaska tested updates.img with non-live, and live ... happy with both results
17:42:05 <adamw> the fix is small?
17:42:18 <jlaska> yes
17:42:42 <jlaska> https://bugzilla.redhat.com/attachment.cgi?id=452768
17:42:56 <jlaska> basically, just changing the bugURL text
17:43:07 <adamw> looks good to me
17:43:10 <adamw> +1 nth
17:43:14 <jlaska> proposed #agreed 635779 (Meeting topic: Fedora 14 Final Blocker Review)
17:43:20 <jlaska> argh! paste buffer
17:43:24 <adamw> of course, that means it only gets fixed if we need an anaconda build for something else
17:43:37 <jlaska> I don't think anaconda needs to be rebuilt
17:43:39 <clumens> adamw: no, only if you have to do a new tree
17:43:46 <jlaska> just that this would need to be included during pungi-fication
17:44:04 <adamw> oh i see
17:44:31 <clumens> it would require a new anaconda as well if it needed changes to upd-instroot to change what files are in the images.
17:44:39 <clumens> though we are getting away from that slowly
17:45:06 <jlaska> proposed #agreed 635779 accepted as a 'nice-to-have'.  Once sufficient karma is given, it will be available for F-14-RC1 compose
17:45:56 <adamw> ack
17:45:58 <jlaska> ack
17:46:18 <Oxf13> ack
17:46:23 <jlaska> #agreed 635779 accepted as a 'nice-to-have'.  Once sufficient karma is given, it will be available for F-14-RC1 compose
17:46:27 <Oxf13> I have to step out, but looks like we're winding down anyway
17:46:37 <jlaska> okay, the other bug poelcat listed was the F14Blocker bug itself
17:46:45 * jlaska inspecting F14-accepted for anything we missed
17:46:53 <adamw> Oxf13: i did want to raise that high-system-load issue from the ml
17:46:58 <adamw> see if we're worried about that
17:47:07 <Oxf13> not as a blocker
17:47:09 <adamw> k
17:47:11 <Oxf13> NTH perhaps, but not blocker
17:47:17 <jlaska> adamw: poelcat was going to follow-up on that
17:47:25 <jlaska> s/was/is/
17:48:20 <adamw> ok
17:48:27 <jlaska> did we discuss bug#542255
17:48:28 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=542255 medium, low, ---, leigh123linux, ASSIGNED, [abrt] crash detected in gmixer-1.3-11.fc12
17:50:00 <adamw> it's already acceptednth
17:50:10 <adamw> we weren't going to go through and check the status of fixing ones we'd already reviewed, i don't think
17:50:17 <adamw> just review ones that aren't accepted or rejected yet
17:50:53 <jlaska> sorry, I missed your tinyurl lin kpreviously
17:51:09 <jlaska> Using http://tinyurl.com/22sa3hb, I think we're done
17:51:29 <adamw> yup
17:51:34 <jlaska> 2 trackers, and the LXDE bug that we've already discussed
17:51:39 <jlaska> alright, nice work gang
17:51:42 <jlaska> #topic Open discussion
17:51:50 <jlaska> anyone want to talk about the weather?
17:52:34 <fcami> why not
17:52:47 <fcami> it's cold here now.
17:52:51 <jlaska> :(
17:52:58 <jlaska> it's sloooowly getting cold here
17:52:59 <fcami> kinda expected :)
17:53:01 <pjones> it's very gray here.
17:53:13 <adamw> there's that high load bug on test list
17:53:19 <notting> pjones: and that's going to change before may?
17:53:49 * mcepl would note that it is very dark here, but that will change in the morning ;)
17:53:51 <pjones> notting: we will have sunny bright snowglare days at some point
17:54:01 <mclasen> notting: could make it an f15 blocker...
17:54:01 <poelcat> adamw: i talked to davej and am going to file a bug
17:54:14 <jlaska> load average: 1.12, 1.15, 1.14
17:54:18 <poelcat> adamw: saw some stuff in powertop http://poelstra.fedorapeople.org/paste-bin/f14-load.ogg
17:54:44 <jlaska> powertop! that's a good point
17:54:49 <poelcat> won't be able to file the bug for another hour
17:54:58 <jlaska> notting mentions that each release to see if anyone has run that recently
17:55:02 <poelcat> sooner if i'm lucky
17:55:04 <jlaska> that would be a good #action for all
17:55:23 <poelcat> yeah, i was prompted for some extra stuff i hadn't seen before
17:55:26 <adamw> i ran it on my laptop but that's not actually running an f14 kernel...
17:55:29 <poelcat> and the audio thing over and over again
17:55:50 * poelcat biab
17:56:18 <adamw> ok, so we may want to make that an nth on short notice i gues
17:56:23 <adamw> other than that...we're done here?
17:56:28 <jlaska> I think so
17:56:42 * jlaska will #endmeeting in 15 seconds
17:56:47 <jlaska> tick tock tick tock ...
17:57:04 <jlaska> thanks all!
17:57:06 <jlaska> #endmeeting