16:00:07 <jlaska> #startmeeting F14 Blocker Bug Review
16:00:07 <zodbot> Meeting started Fri Oct  1 16:00:07 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:15 <jlaska> #meetingname f-14-blocker-review
16:00:15 <zodbot> The meeting name has been set to 'f-14-blocker-review'
16:00:27 <jlaska> #topic Gathering critical mass
16:00:39 <adamw> yo
16:00:47 <jlaska> okay, show of nicks ... who likes blocker bugs?
16:01:03 <jlaska> adamw: happy friday sir!
16:01:17 * adamw eats blockers for breakfast
16:01:18 <adamw> om nom nom
16:01:19 * stickster loves blockers, especially strawberry
16:01:34 * jsmith adds to the critical mass
16:01:34 * stickster will be lurking here even though concentrating elsewhere
16:01:39 * jsmith is good at being "mass"
16:01:40 <jlaska> adamw: those bugs never saw it coming
16:01:43 * nirik is also lurking around.
16:02:23 <jlaska> welcome hannes|
16:02:30 <stickster> FWIW, on Wednesdsay I sent some notifications around internally to Red Hat engineering, reminding people of this meeting.
16:02:37 <jlaska> oh great, thanks
16:02:38 <stickster> er, Wednesday.
16:02:49 * jlaska checks for any anaconda-devel folks, as that will be our first target
16:03:04 <hannes|> jlaska, thanks
16:03:06 <jlaska> I see bcl lurking ... checking for dlehman
16:03:12 * bcl waves
16:03:27 * rdieter lurks, w/ bag o' popcorn
16:03:43 <jlaska> hi gang
16:04:10 <jlaska> dlehman arrives in a storm of partitions and drives
16:04:25 <jlaska> not sure if Oxf13 is around
16:04:35 <jlaska> will get started in 30 seconds
16:04:37 <Oxf13> I'm here
16:04:44 <jlaska> Oxf13: perfect, hey there
16:04:48 <jlaska> okay let's roll
16:04:55 <jlaska> #topic The basics ...
16:04:56 <Oxf13> I'm also completely unprepared :)
16:05:10 <jlaska> Just some ground rules ...
16:05:28 <jlaska> I'll be following the blocker meeting process to the best of my abilities
16:05:31 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:52 <jlaska> I'll be working from the following list of F14Blocker bugs (sorted by component):
16:05:55 <adamw> if we could do the nth bugs later (as outlined in my draft modification of that page) it'd be great
16:06:10 <jlaska> #link http://tinyurl.com/2fqpazy
16:06:35 <jlaska> adamw: certainly
16:06:55 <jlaska> dlehman: bcl: being _a_ naconda, you guys are up first
16:07:05 <jlaska> queue the fireworks ... here we go
16:07:35 <jlaska> before we go ... anyone want to volunteer to be the bug secretary?
16:07:43 <adamw> i'll do it
16:08:05 <jlaska> adamw: thanks! as always, much appreciated
16:08:18 <jlaska> another handy reference ...
16:08:20 <jlaska> #link https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria
16:08:33 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=584328
16:08:35 <buggbot> Bug 584328: medium, low, ---, bcl, NEW, AttributeError: 'NoneType' object has no attribute 'name'
16:09:10 <dlehman> this is looking like a pyblock bug
16:09:11 <adamw> so the last comment is interesting
16:09:22 <adamw> i guess we should treat this bug as being for jlaska's issue?
16:09:32 <Oxf13> confused
16:09:36 <dlehman> yes -- 639138 is the livecd one
16:09:44 <Oxf13> is this a F13 bug that was never fixed, or is this a new bug that looks like an old bug?
16:09:52 <dlehman> the latter
16:10:24 <jlaska> so first question, is it a release blocker?  Have we established that?
16:10:25 <dlehman> it's all about dm uuids, which anaconda now uses to differentiate various types of device-mapper devices
16:10:31 <adamw> seems like perhaps anaconda's dupe-detection could do with some refining
16:10:50 <dlehman> yes it could, but it's not easy
16:10:51 <adamw> jlaska: what's the exact circumstance of the bug for you?
16:11:14 <dlehman> I think the non-live bug is specific to some hardware jlaska has
16:11:44 <jlaska> yeah, I'm able to hit this consistently when attempting an install on a dmraid system I have locally
16:12:02 <jlaska> I was hitting it during beta as well, but I hadn't pin pointed  the reproducer at that time
16:12:11 <Oxf13> if it's widespread on DM systems, I'd say yes, a blocker.
16:12:15 <adamw> this comes 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:12:21 <dlehman> it's the only reports of it that I've seen, and I go out on a limb to presume that there are other people testing dmraid
16:12:31 <Oxf13> I haven't been testing much recently but I do have a dm system here I could throw at it
16:12:39 <dlehman> that would be great
16:12:46 <adamw> so i'd say blocker, given that we intentionally phrased that criterion quite widely
16:12:49 <Oxf13> forgive me, but is there anything specific to test?
16:13:22 <dlehman> if you can get to the custom partitioning screen with preexisting partitions on a dmraid array you didn't hit it
16:13:34 <Oxf13> ok.
16:13:45 <jlaska> Oxf13: for me, it was zap anydmraid config on my system, reconfigure dmraid, then install using custom partition screen
16:14:23 <adamw> ok, so votes on blockeriness
16:14:30 <jlaska> +1 from me
16:14:31 * adamw is +1
16:15:07 <dlehman> can I vote +/-0 ?
16:15:15 <jlaska> sure
16:15:24 <Oxf13> +1 until we know any better
16:15:30 <dlehman> if it's at all widespread I say +1, but if only jlaska's test box, maybe not
16:15:49 <jlaska> dlehman: there are 4 other recent reporters on that bug .. are they seeing the same issue?
16:16:19 <dlehman> they're all doing live installs, hitting the parted bug on >1 runs w/o rebooting
16:16:30 <jlaska> ah I see
16:16:48 <jlaska> so if it's only my system hitting this ... that's odd
16:17:33 <adamw> dlehman: in any case, how hard should it be to fix?
16:19:00 <jlaska> proposed #agreed 584328 - tentatively accepted as a valid release blocker.  Impacts dmraid installation using custom partitioning on at least 1 system (unknown if more)
16:19:24 <adamw> ack
16:19:57 <jlaska> anyone else?
16:20:02 <jlaska> going once ...
16:20:08 <jlaska> twice
16:20:15 <jlaska> #agreed 584328 - tentatively accepted as a valid release blocker.  Impacts dmraid installation using custom partitioning on at least 1 system (unknown if more)
16:20:26 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636621
16:20:28 <buggbot> Bug 636621: medium, low, ---, clumens, NEW, Anaconda netinstall fails with missing 'storage' module
16:20:41 <adamw> wait wait wait
16:20:49 <jlaska> ?
16:20:50 <adamw> we didn't do the bit where we make sure the bug's getting fixed
16:21:00 <jlaska> ah ... okay
16:21:01 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=584328
16:21:03 <buggbot> Bug 584328: medium, low, ---, bcl, NEW, AttributeError: 'NoneType' object has no attribute 'name'
16:21:18 <jlaska> dlehman: anything we need to discuss/consider to ensure this issue is resolved in an upcoming anaconda build?
16:21:46 <Oxf13> well obviously we need more testing on it
16:21:55 <Oxf13> to see if it happens outside of jlaska's system
16:22:12 <jlaska> we put a call out for dmraid testing during Beta, but it's not always clear to testers if they have it, and/or how to enable it in the bios
16:22:20 <bcl> we have a patch for parted that fixes it for dlehman.
16:22:34 <adamw> why 'obviously'? that might be interesting from an impact-assessment POV but it doesn't seem necessary to fix it, unless we need more data.
16:22:53 <jlaska> I can certainly run that through my local reproducer
16:22:55 <adamw> bcl: dlehman: I thought from the comments that the parted patch is for the other case, the live case
16:23:09 <adamw> bcl: dlehman: and jlaska's case is a bug in pyblock...that's what the last comment says
16:23:18 <jlaska> robatino: welcome
16:23:19 <bcl> oh, I may have them crossed up
16:23:44 <adamw> "the one jlaska is seeing is a pyblock bug (it isn't setting the
16:23:44 <adamw> uuids on the dmraid devices at all)"
16:24:20 <jlaska> 15 minutes for first bug, we need to pick things up
16:24:37 <adamw> sure, but we really ought to ensure we have a plan in place for fixing the bugs as we go
16:24:42 <bcl> adamw: you are correct
16:24:44 <adamw> did dlehman step out?
16:24:58 <jlaska> adamw: agreed, a few more seconds and I'll just do #action for dlehman to follow-up
16:25:04 <jlaska> #action 584328 (Meeting topic: F14 Blocker Bug Review)                                                                                                                     hardware or BIOS RAID, or combina
16:25:04 <dlehman> adamw: you are correct
16:25:09 <jlaska> #undo
16:25:09 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b7d3179ee90>
16:25:26 <jlaska> dlehman: can you summarize the next steps?
16:25:30 <dlehman> the nfs case jlaska is seeing is a pyblock problem as it currently stands
16:25:32 <bcl> heh. that needs a str method
16:25:36 <adamw> dlehman: okay, so is this something you already have all the necessary info to fix, regardless of how many systems it impacts or whatever?
16:26:03 <dlehman> adamw: it may need access to the system for experimentation, but generally yes
16:26:06 <adamw> okay
16:26:31 <jlaska> #action 584328 - dlehman has a fix inprogress, may require additional access to the affected system to test, will follow-up in bug
16:26:39 <adamw> awesome
16:26:43 <jlaska> adamw: thanks for reminder: )
16:26:47 <jlaska> alright ... next
16:26:52 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636621
16:26:54 <buggbot> Bug 636621: medium, low, ---, clumens, NEW, Anaconda netinstall fails with missing 'storage' module
16:27:08 <jlaska> I saw this patch on anaconda-devel-list, but wasn't sure about how the tester hit the bug
16:27:44 <adamw> um...isn't 627388 next?
16:27:51 <jlaska> adamw: no
16:27:53 <jlaska> follow the link earlier
16:27:56 <adamw> i did
16:28:09 <dlehman> the patch is simple but the reproducer is unclear
16:28:36 <adamw> jlaska: that's exactly the list I have open, 627388 is before 636621 in it
16:28:51 <jlaska> adamw: not on my list, sorry
16:29:00 <jlaska> adamw: let's continue please
16:29:21 <jlaska> it's clearly a missing import
16:29:24 <adamw> okay, but i don't want to miss a bug
16:29:33 <jlaska> adamw: I understand
16:29:51 <jlaska> different bz permissions or default sorting .. dunnoa
16:30:11 <dlehman> it's fallout from turning anaconda into a proper python package/module
16:30:21 <jlaska> okay
16:30:50 <jlaska> I'd like to accept it since it's clearly a bug ... but we should ask for more feedback on the reproducer
16:30:55 <dlehman> we changed an import from 'import storage.blah' to 'import pyanaconda.storage.blah' but didn't change the later statement that use storage.blah to use pyanaconda.storage.blah
16:31:07 <dlehman> +1
16:31:47 <jlaska> I do'nt have objections, from a test perspective,I'd like to understand more about it so we know what we missed
16:32:37 <adamw> right, seems there's no info about how you actually hit this bug in the report
16:32:46 <jlaska> howabout ...
16:33:02 <adamw> of course anaconda team can go ahead and fix it and then we don't have to care :P
16:33:18 <adamw> but from a blocker pov i think it needs more info
16:33:37 <Oxf13> need info + NTH  +1 from me
16:34:30 <dlehman> looks like you just need to pass loglevel to anaconda
16:34:31 <jlaska> proposed #agreed 636621 - Unclear how this impacts the release criteria.  Request more info and move to nice-to-have list
16:34:39 <jlaska> dlehman: ahh
16:34:46 <jlaska> which yeah, we're not testing
16:34:50 <jlaska> at least not explicitly
16:35:02 <dlehman> don't think pxe really has anything to do with it
16:35:10 <jlaska> okay
16:35:27 <jlaska> does this understanding change the proposal?
16:35:27 <adamw> ok, so that's not in the release criteria; do we want to add it or are we fine with loglevel= being an nth thing?
16:35:50 <jlaska> ack for NTH
16:36:08 <dlehman> patch is in hand, so may as well make it nth
16:36:13 <jlaska> okay
16:36:16 <jsmith> +1 to NTH
16:36:38 <jlaska> #agreed 636621 - No criteria for loglevel= boot parameter, agreed to move to nice-to-have list
16:36:44 <jlaska> who has the ball?
16:36:49 <adamw> ok, just wanted to cover the wider point; is this functionality we reckon is critical for release or not
16:36:58 <jlaska> dlehman: you said, patch in hand ... likely in next build?
16:37:05 <dlehman> yes
16:37:22 <jlaska> adamw: I don't have any input on that right now ... would need to investigate
16:37:34 <adamw> ok
16:37:37 <jlaska> #action dlehman - patch in hand for 636621, expected to land in next build
16:37:52 <dlehman> it's already on master, just needs cherry-picked over before build
16:38:09 <jlaska> #undo
16:38:09 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b7d31890950>
16:38:20 <jlaska> #action dlehman - patch in hand for 636621, will cherry-pick from master before next build
16:38:38 <jlaska> adamw: I'd want to understand more about the use cases for loglevel=
16:38:42 <adamw> ok
16:38:44 <adamw> we can do that later then
16:38:55 <jlaska> perhaps related to gathering more debugging info to assist with problem determination
16:39:17 <jlaska> #idea think about installer boot option loglevel= and if criteria need adjustment
16:39:32 <jlaska> okay ... think we're done with this bz
16:39:55 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=627388
16:39:57 <buggbot> Bug 627388: high, low, ---, msivak, NEW, VNC install ignores password
16:40:37 <jlaska> I'm still uncertain whether this is a valid bug, the reporter isn't able to confirm due to another issue
16:40:54 <jlaska> 'another issue' - I've requested feedback from msivak to determine if a new bug is needed
16:41:12 <adamw> yeah, i think we can't determine much about this yet
16:41:43 <jlaska> we normally keep these types of issues on the list for at least a week, then remove them
16:41:46 <jlaska> stick with that plan
16:41:52 <adamw> yeah, let's check status next week
16:41:54 <jlaska> or should we be more aggressive about removing them this time
16:42:28 <adamw> no, review later is appropriate
16:42:35 <jlaska> proposed #agreed 627388 - unclear whether the reported problem still exists, awaiting feedback from reporter.  May remove from list next meeting if no changes
16:42:41 <adamw> ack
16:43:20 <jlaska> #agreed 627388 - unclear whether the reported problem still exists, awaiting feedback from reporter.  May remove from list next meeting if no changes
16:43:40 <jlaska> #info Leave in needinfo? requesting feedback from reporter
16:44:11 <jlaska> #info Outstanding question for msivak in bug to address a new issue related to VNC prompt on text-mode installs
16:44:18 <jlaska> alright, moving on ...
16:44:47 <jlaska> Please note ... adamw found out that my original query might not sort properly on your end
16:44:51 <jlaska> I've updated the query for those following along
16:44:53 <jlaska> #link http://tinyurl.com/2drr5rs
16:45:03 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=635778
16:45:05 <buggbot> Bug 635778: medium, medium, ---, bcl, MODIFIED, IndexError: list index out of range
16:45:27 <adamw> are we doing the modifieds / verifieds?
16:45:42 <jlaska> adamw: sadly, I hadn'y filtered them
16:45:48 <adamw> ok
16:45:55 <jlaska> c'mon fingers, don't fail me now
16:46:10 <jlaska> we can fast track the MODIFIED's in the interest of time
16:46:13 <adamw> so, this one's supposedly fixed in 14.18, i guess the only action is to retest when we have an image
16:46:16 <jlaska> just make sure they're ready for next build
16:46:39 <jlaska> great, this is fairly straight forward to retest ... hopefully my instructions in comment#0 are clear
16:47:13 <jlaska> #info 635778 - currently in MODIFIED, fix available in 14.18, awaiting anaconda build to test
16:47:18 <jlaska> dlehman: bcl: that look good?
16:47:34 <dlehman> yep
16:47:51 <bcl> yup
16:47:55 <jlaska> okay, don't think we need anything else here then
16:48:05 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=627789
16:48:07 <buggbot> Bug 627789: medium, low, ---, bcl, MODIFIED, Error setting up repository - 16, Device busy
16:48:13 <jlaska> I'm having nightmares about this bug
16:48:34 <jlaska> good news ... everyone but me can hit this bug, and many folks have confirmed the updates.img resolves the issue
16:48:49 <dlehman> patch is in git, just waiting for a build
16:48:57 <jlaska> again, this is in MODIFIED, and expected in the next build (anaconda-14.18)
16:48:57 <adamw> basically the same as the last one
16:49:06 <jlaska> #info 627789 - currently in MODIFIED, fix available in 14.18, awaiting anaconda build to test
16:49:26 <jlaska> Please note ... I may move quick on some of these ... no ill will intended, just trying to push through
16:49:33 <jlaska> feel free to request I slow down at any time
16:49:36 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=621685
16:49:39 <buggbot> Bug 621685: medium, medium, ---, bcl, CLOSED ERRATA, TypeError: sequence item 0: expected string, NoneType found
16:49:45 <jlaska> yay, thanks adamw :)
16:49:50 <adamw> =)
16:50:06 <jlaska> #info 621685 included and tested in F-14-Beta, moved to CLOSED ERRATA
16:50:26 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=621469
16:50:29 <buggbot> Bug 621469: medium, low, ---, anaconda-maint-list, CLOSED ERRATA, Fail to retrieve repo info using 'repo=nfsiso:'
16:50:43 <jlaska> same thing here, yay
16:50:59 <jlaska> #info 621469 included and tested in F-14-Beta, moved to CLOSED ERRATA
16:51:05 <Oxf13> hrm.
16:51:06 * adamw has been reading ahead of the class :P
16:51:12 <Oxf13> closed errata means it would have been fixed in beta?
16:51:21 <jlaska> Oxf13: it was, but iirc, just not linked in the bodhi update
16:51:57 <jlaska> that's it for the 'anaconda' bugs on my list
16:52:00 <adamw> Oxf13: it was...hurry still has trouble but it turns out to be a case of 627789, the initial problem tracked in this bug is fixed
16:52:23 <jlaska> thanks dlehman and bcl ... although I suspect there may be other install-related issue down the line, may we ping you if needed
16:52:46 <jlaska> okay ... next up brasero ...
16:52:51 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=631987
16:52:53 <buggbot> Bug 631987: medium, low, ---, lxtnow, NEW, [abrt] brasero-2.31.91-1.fc14: g_variant_is_trusted: Process /usr/bin/brasero was killed by signal 11 (SIGSEGV)
16:53:08 <adamw> simple one: brasero doesn't work at all. this hits criterion "All applications listed under the Applications menu must start successfully "
16:53:26 <adamw> oh, wait - it does start, but it hits "#  All applications listed under the Applications menu must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items "
16:53:38 <adamw> 'actually burn a disc' seems like a reasonable 'basic functionality test' for a disc burning application :P
16:53:46 <jlaska> since this is the purpose for brasero, yeah that seems basic
16:53:59 <Oxf13> agreed
16:54:17 <adamw> so i'm +1 to blocker
16:54:45 <Oxf13> +1
16:55:03 <jlaska> proposed #agreed 631987 is a valid release blocker per criteria that all applications listed under the Applications menu must withstand a basic functionality test and not crash after [...] normal use
16:55:37 <jlaska> #agreed 631987 is a valid release blocker per criteria that all applications listed under the Applications menu must withstand a basic functionality test and not crash after [...] normal use
16:55:46 <jlaska> okay, seems like the ball is in the maintainers court?
16:55:57 <jlaska> laxathom
16:55:58 <jlaska> ?
16:56:07 <adamw> well yeah
16:56:15 <adamw> but i asked mclasen about it too since it's a key part of gnome desktop
16:56:15 <jlaska> oh, Isee your last comment adamw
16:56:25 <adamw> he says there's a fix upstream which should get pulled in when brasero is bumped to 2.32
16:56:53 * jlaska needs to understand the post-F14-Beta 2.31 -> 2.32 GNOME release bumps
16:57:15 <jlaska> #info mclasen notes a fix is available upstream and should be included when brasero is bumped to 2.32
16:57:47 <adamw> jlaska: 2.31 is the development version for 2.32
16:57:57 <adamw> jlaska: 2.31.91 would be 2.32 RC1, for e.g.
16:58:07 <adamw> so it's not really a version bump so much as going from a pre-release to final
16:58:09 <jlaska> right, for some reason I would have expected that prior to F-14-Beta
16:58:16 <jlaska> but maybe upstream and downstream schedules didn't line up
16:58:19 <adamw> they don't
16:58:22 <jlaska> okay
16:58:30 <jlaska> adamw: thanks for the details
16:58:42 <jlaska> alright, I'm skipping the Virtualization TRACKING bug and going to ...
16:58:43 <Oxf13> there was the "go with gnome3, oh wait, go with gnome 2.32" thing as well
16:58:44 <adamw> gnome and fedora are both on 6 month cycles, our releases line up quite nicely but that means the upstream final release comes after our beta
16:59:00 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=637339
16:59:03 <buggbot> Bug 637339: medium, low, ---, bdpepple, MODIFIED, empathy 2.31.90-2 blocked by SELinux
16:59:38 <adamw> this is another 'basic functionality' one
16:59:53 <jlaska> if it's completely preventing connecting to im.yahoo.com, yeah seems so
17:00:13 <adamw> it may well affect all IM providers actually
17:00:34 <jlaska> even better :)
17:00:37 <jlaska> #info All applications listed under the Applications menu must withstand a basic functionality test
17:01:18 <jlaska> proposed #agreed 637339 - accepted as release blocker, appears to affect basic empathy functionality (connecting to yahoo) and is covered by final release criteria
17:01:20 <adamw> so i'm +1 to blocker. the fix is just waiting to be submitted stable, btw, selinux-policy -7 has passed critpath requirements
17:01:21 <jlaska> ack/nak ?
17:01:22 <adamw> ack
17:01:33 <jlaska> awesome
17:01:43 <jlaska> anyone else ... 20 seconds ...
17:02:10 <jlaska> #agreed 637339 - accepted as release blocker, appears to affect basic empathy functionality (connecting to yahoo) and is covered by final release criteria
17:02:18 <jlaska> #info  (Meeting topic: F14 Blocker Bug Review)
17:02:27 <jlaska> ugh ... cut'n'paste is acting screwy
17:02:57 <jlaska> #info 637339 - a fix is pending submissino to stable, selinux-policy -7 has passed critpath requirements
17:03:13 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636118
17:03:15 <buggbot> Bug 636118: high, low, ---, rstrode, NEW, Swell Foop fails to run in F14 Beta RC3 Desktop live install
17:03:38 <jlaska> what the heck is swell-foop :)
17:03:45 <adamw> it used to be called same GNOME
17:03:48 <adamw> it's the Go game
17:03:49 <jlaska> oh oh
17:04:07 <adamw> so yeah, it's pretty straightforward: it's an app on the default desktop which fails to launch at all
17:04:14 <jlaska> heh, I agree with your assessment in the bz
17:04:54 <jlaska> proposed #agreed 636118 - accepted as release blocker, affects basic functionality of swell-foop (included on Live image) and is covered by final release criteria
17:05:17 <adamw> ack
17:05:26 <jlaska> we need a tie-breaker voting ... not that this is a contentious issue
17:05:42 <jlaska> anyone else want to weigh in?
17:05:46 * adamw just pinged halfline
17:05:52 <jlaska> adamw: ooh, good thinking, thanks
17:06:34 * jlaska waits a short while ...
17:07:02 <adamw> if he's not around, we'll just mark it as #action for him and move on
17:07:09 <jlaska> alright ..
17:07:14 <jlaska> #agreed 636118 - accepted as release blocker, affects basic functionality of swell-foop (included on Live image) and is covered by final release criteria
17:07:21 <jlaska> #action 636118 (Meeting topic: F14 Blocker Bug Review)
17:07:25 <jlaska> 12:55:57   jlaska:  laxathom
17:07:27 <jlaska> this is getting old
17:07:29 <jlaska> #undo
17:07:29 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b7d2fec3110>
17:07:50 * adamw shoots jlaska's mouse
17:08:14 <jlaska> so ray will do the build for this?
17:08:35 <adamw> well, it's assigned to him
17:08:43 <adamw> if we don't get any movement we can escalate to desktop team i guess
17:08:51 <jlaska> #action 636118 - halfline (or someone from desktop) needed to investigate problem
17:09:11 <jlaska> thanks for joining notting
17:09:14 <jlaska> alright, next bug ...
17:09:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639130
17:09:20 <buggbot> Bug 639130: medium, low, ---, rstrode, NEW, missing dependency in gnome-games-extra
17:09:29 <jlaska> good timing notting :)
17:09:41 <Oxf13> fwiw I agree the previous bug, 636118 was a blocker.
17:09:54 <jlaska> Oxf13: thanks!
17:10:09 <Oxf13> ditto this one, and it seems like we could just fix this now.
17:10:14 <jlaska> is gnome-games-extra included on media
17:10:18 <notting> this bug is presumably trivial, i just haven't looked up what provides that
17:10:44 <adamw> yeah, i don't think -extra is on the media/default install, so it wouldn't count as a blocker...
17:10:52 <jlaska> certainly a NTH
17:11:12 <adamw> well, if it's not on the media, i'm not sure about that - nth status is almost irrelevant to something that's not on media
17:11:18 <robatino> jlaska: not on the Beta DVD
17:11:22 <adamw> if you're always going to have to install it from the repos anyway...
17:11:32 <jlaska> I do not see it on the nightly live image (http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/logs/20100930.15-x86_64.log)
17:11:37 <jlaska> robatino: thanks
17:11:39 <Oxf13> -1 on blocker then.
17:11:54 <adamw> yeah, -1. i'm -1 on nth also, fwiw
17:12:00 <jlaska> adamw: okay
17:12:35 <jlaska> where does that leave this bug ... if it's fixed in time, it will be included ... otherwise it goes to 'updates' after F14 is released?
17:12:45 <adamw> yep
17:13:18 <adamw> quick sidetrack, but nth isn't really just meant to be a 'this should be fixed quickly' ranking, priority/severity are supposed to do that
17:13:18 <jlaska> proposed #agreed 639130 - not a release blocker or nice-to-have.  gnome-games-extra is not provided on the Live image or DVD, does not meet release criteria
17:13:53 <adamw> nth bugs should be ones for which there's some specific relationship to the actual release - some reason they need to be fixed on the package set that gets frozen as opposed to being fixed in updates
17:14:07 <adamw> ack
17:14:19 <adamw> or, not 'need', but 'would benefit from'
17:14:25 * jlaska still absorbing the definition ... thanks for clarifying
17:14:47 <jlaska> I'm including Oxf13's previous -1 for blocker ... I think we're good then
17:14:54 <jlaska> #agreed 639130 - not a release blocker or nice-to-have.  gnome-games-extra is not provided on the Live image or DVD, does not meet release criteria
17:15:15 <jlaska> next ...
17:15:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623824
17:15:20 <buggbot> Bug 623824: medium, low, ---, bnocera, NEW, Won't display on VGA-connected monitor
17:16:36 <jlaska> so downgrading gnome-settings-daemon to the F13 version resolves this issue for the reporter
17:16:59 <jlaska> are issues with external monitors considered release blockers
17:17:35 <jlaska> I don't _think_ they are, unless this was something widespread affecting most/all users
17:18:14 * adamw on phone so may be intermittent for a bit
17:18:23 <jlaska> adamw: okay
17:18:24 <Oxf13> my f14 laptop worked with external monitors while at fudcon and brno
17:18:28 <adamw> yeha, this doesn't smell like a blocker, but may be nth
17:18:34 <Oxf13> it was a bit flakey with gnome-shell, but seemed OK with metacity
17:19:03 <adamw> yeah, my f14 systems are fine with dual
17:19:13 <jlaska> mine are close to fine
17:19:48 <jlaska> proposed #agreed 623824 - not a release blocker, no criteria exist to cover display to external monitors
17:20:08 <adamw> more or less intentionally
17:20:20 <adamw> ack
17:20:28 <jlaska> without knowing the core problem, I don't know if I'd say NTH yet either
17:20:42 <jlaska> meaning, if it's a code change specific to this monitor, or all monitors etc...
17:20:47 <jlaska> taking that after the test week ... eeew
17:21:07 <jlaska> Oxf13: any objections/concerns?
17:21:33 <Oxf13> I agree with the proposal
17:21:49 <jlaska> #agreed 623824 - not a release blocker, no criteria exist to cover display to external monitors
17:22:07 <jlaska> #action ajax and reporter continue to triage the issue with F14 test results
17:22:27 <notting> Oxf13: are you handling the bodhi update and f15 build of gnome-games?
17:22:38 <jlaska> Skipping the KDE TRACKING bugs ...
17:22:48 <Oxf13> notting: yeah, waiting for the build on f14 to finish
17:22:48 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636585
17:23:39 <Oxf13> looks like its still NEEDINFO
17:23:54 <jlaska> according to rdieter "I wouldn't consider this a blocker, without more information."
17:24:34 <jlaska> so, sticking with our normal process ... we'd leave this on the list until next week
17:24:43 <jlaska> and if no feedback then, we'd remove it from the list
17:25:04 <adamw> brb wshroom
17:25:21 <jlaska> proposed #agreed 636585 - not enough information to determine impacted release criteria.  Recommend keeping on list until next meeting.  Will remove if no feedback then.
17:26:44 <rdieter> that works.
17:27:08 <jlaska> rdieter: thanks ... any other votes?
17:27:50 <adamw> well i'm +1 obviously
17:28:00 <jlaska> #agreed 636585 - not enough information to determine impacted release criteria.  Recommend keeping on list until next meeting.  Will remove if no feedback then.
17:28:01 <adamw> i don't think it needs any more information. the criteria say there shouldn't be any alerts on boot.
17:28:25 <jlaska> was this on boot, or from basic functionality etc... ?
17:28:34 <jlaska> guess that's why we need feedback
17:28:35 <adamw> that criterion is a polish criterion; it's not about the bugs behind the alerts, exactly, just that it's poor polish to ship a desktop which pops up selinux alerts or crash notifications
17:29:01 <jlaska> alrighty ... moving on
17:29:04 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=632814
17:29:19 <adamw> i hit it on a reboot after install from live iirc
17:29:23 <jlaska> already in ON_QA, so I guess not much to talk about here
17:29:26 <adamw> with rc3
17:29:32 <jlaska> adamw: previous or this one?
17:29:37 <adamw> previous
17:29:40 <jlaska> adamw: gotcha
17:29:42 <adamw> you didn't really give me much time to reply :)
17:30:20 <jlaska> adamw: c'mon, you have the fastest phalanges in the west!
17:30:29 <adamw> heh
17:30:41 <jlaska> not sure what else to add for this bz ...
17:30:47 <jlaska> in ON_QA and pending karma feedback
17:30:59 <jlaska> Score another for Orion
17:31:41 <jlaska> I gather this fits the same polish criteria previous mentioned, "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login"
17:32:29 <jlaska> proposed #agreed 632814 - a valid release blocker.  Fixed and awaiting bodhi karma
17:32:34 <adamw> yeah
17:32:36 <adamw> ack
17:33:09 <jlaska> rdieter: any thoughts/concerns?
17:33:47 <rdieter> ack , that's a nasty.
17:33:58 <rdieter> (but we got it nailed I think)
17:34:04 <jlaska> roger, thanks
17:34:06 <jlaska> #agreed 632814 - a valid release blocker.  Fixed and awaiting bodhi karma
17:34:41 <jlaska> #action 632814 - needs bodhi karma feedback from KDE users
17:34:59 <jlaska> howdy halfline
17:35:01 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=634182
17:35:06 <buggbot> Bug 634182: medium, low, ---, lpoetter, NEW, libcanberra-gtk2 Requires libcanberra-gtk3 ?
17:35:30 <jlaska> rdieter: looks like you filed this to reduce the size of the KDE image to < 700M
17:35:37 * halfline looks
17:35:42 <rdieter> yeah
17:36:11 <jlaska> interesting, we have installer test cases to ensure that media is of the appropriate size, but I don't think we have criteria for it
17:36:15 <jlaska> unless I'm missing it
17:36:15 <rdieter> but I honestly don't have a personal intersted anymore, now that metacity is gone (fixed elsewhere)
17:36:17 <adamw> i don't think this strictly counts as a blocker under the current process, though i'd agree it should be fixed to make life easier for spin sizing
17:36:43 <adamw> i'd probably make it an nth
17:36:43 <jlaska> any recommendations?
17:37:02 <jlaska> halfline: no worries for this bug, if you don't mind lurking, we can give you a holler when your input is needed
17:37:15 <halfline> okay
17:37:17 <rdieter> I'll remove it as a blocker, as far as I'm concerned
17:37:22 <jlaska> halfline: otherwise, feel free to contibute
17:37:40 <adamw> halfline: as i mentioned in -devel we were just gonna ask for a fix status on https://bugzilla.redhat.com/show_bug.cgi?id=636118 when I pinged you earlier
17:37:43 <adamw> but we moved on from that now
17:37:45 <buggbot> Bug 636118: high, low, ---, rstrode, NEW, Swell Foop fails to run in F14 Beta RC3 Desktop live install
17:37:57 <adamw> for 634182 i'd propose nth
17:37:57 * halfline looks
17:38:28 <jlaska> proposed #agreed 634182 - not a release blocker, no longer impacting KDE spin size
17:38:34 <rdieter> ack
17:38:44 <notting> huh. 636118 now dies entirely differently
17:38:55 <Oxf13> jlaska: ack
17:38:56 <adamw> notting: yeah, i added a comment
17:39:02 <notting> adamw: even different from that for me
17:39:03 <halfline> adamw: i think for 636118 there was a discussion on ddl
17:39:04 <jlaska> #agreed 634182 - not a release blocker, no longer impacting KDE spin size
17:39:04 <adamw> heh
17:39:05 <halfline> let me look
17:39:07 <jlaska> rdieter: Oxf13 thanks
17:39:12 <adamw> jlaska: are we voting on nth-ness?
17:39:15 <halfline> but i don't want to derail your meeting if you've moved on
17:39:24 <Oxf13> notting: https://admin.fedoraproject.org/updates/gnome-games-2.32.0-2.fc14
17:39:30 <adamw> halfline: if you can just follow up on the bug report that'd be great
17:39:42 <jlaska> adamw: certainly ... anyone want to propose this for NTH?
17:39:44 <Oxf13> oh you would have gotten the email.  sorry for the spam
17:39:48 <adamw> jlaska: i just did, twice =)
17:40:08 <jlaska> adamw: I was under the impression from rdieter that the ISO size wasn't a concern anymore
17:40:14 <adamw> for KDE spin
17:40:16 <jlaska> wasn't sure if he still wanted to persue
17:40:24 <adamw> should check if it's on other spins
17:40:28 <jlaska> oh I see
17:40:41 <adamw> do we have package lists of the other spins?
17:40:48 <jlaska> in the logs online ...
17:40:56 * nirik has the Xfce spin back under size now.
17:41:00 <adamw> oh right
17:41:10 <jlaska> http://alt.fedoraproject.org/pub/alt/nightly-composes/lxde/logs/20100930.15-x86_64.log
17:41:12 <nirik> http://alt.fedoraproject.org/pub/alt/nightly-composes/ has logs for each
17:41:22 <notting> adamw: halfline: seed appears to be mixed 2&3
17:41:30 <adamw> desktop spin has it
17:42:24 <adamw> hum - xfce spin has libcanberra-gtk2 but not libcanberra-gtk3
17:42:27 <adamw> so this may actually be fixed?
17:42:38 <jlaska> same for lxde
17:42:41 <halfline> notting,adamw: http://mail.gnome.org/archives/desktop-devel-list/2010-September/msg00077.html
17:42:47 <halfline> i'll post it to the bug
17:42:58 <adamw> xfce does have 3 gtk3 packages in it, but not sure what's pulling them in
17:43:33 <jlaska> ibus-gtk3-1.3.7-5.fc14.x86_64
17:43:33 <jlaska> gtk3-immodule-xim-2.90.5-1.fc14.x86_64
17:43:33 <jlaska> gtk3-2.90.5-1.fc14.x86_64
17:43:38 <adamw> [adamw@adam Download]$ rpm -q --requires libcanberra-gtk2 | grep 3
17:43:38 <adamw> libc.so.6(GLIBC_2.3.4)(64bit)
17:43:38 <adamw> libvorbisfile.so.3()(64bit)
17:43:38 <adamw> rpmlib(CompressedFileNames) <= 3.0.4-1
17:43:43 <adamw> so i'm going to take a guess that this is fixed
17:43:54 <Oxf13> CLOSED->CURRENTVERSION
17:44:32 <adamw> yup
17:44:39 <jlaska> #info after inspection of nightly spin logs, appears 634182 may be resolved already
17:44:43 <notting> halfline: surely outside of any gir issues there's seed-linked-against-gtk3-importing-clutter-linked-against-gtk2?
17:44:45 <jlaska> what else?
17:44:48 <jlaska> NTH?
17:45:11 <adamw> no point making it nth if it's fixed
17:45:14 <adamw> i closed it
17:45:15 <adamw> move on :)
17:45:20 <jlaska> even better!
17:45:22 * jsmith smiles
17:45:30 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=630226
17:45:34 <buggbot> Bug 630226: medium, low, ---, dledford, MODIFIED, SELinux AVCs for mdadm
17:45:42 <jlaska> another MODIFIED, and I suspects pending in a policy update
17:45:52 <jlaska> According to Bruno, "It looks like this is fixed by selinux-policy-3.9.3-1.fc14.
17:46:20 <jsmith> FWIW, I filed 639066 yesterday, which is another SELinux AVC (this one for abrt)
17:46:23 <adamw> we're well past that now
17:46:36 <adamw> current stable is 3.9.5-3
17:46:44 <adamw> so we can probably close this and ask bruno to re-open if he's still seeing it
17:46:55 <jlaska> sounds like a plan
17:47:23 <adamw> proposed bug note "current stable selinux-policy is 3.9.5-3, so this should be well fixed by now: closing. Bruno, please re-open if you're still seeing this. Thanks!"
17:47:24 <adamw> ack/nack?
17:47:38 <Oxf13> ack
17:47:44 <jlaska> ack
17:47:50 <jsmith> ACK
17:47:53 <jlaska> adamw feel free to #action
17:48:12 <halfline> notting: i don't know
17:48:19 <halfline> notting:  i haven't looked into the issue in detail
17:48:23 <adamw> #agreed 630226 is probably fixed already, can be closed
17:48:29 <adamw> #action adamw to close 630226
17:48:31 <notting> halfline: ok, will let walters handle it
17:48:39 <jlaska> heads up bcl ... parted coming next
17:49:09 <jlaska> adamw: thanks
17:49:12 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639138
17:49:13 <buggbot> Bug 639138: medium, low, ---, bcl, NEW, parted unsets device-mapper partitions' uuids when doing a commit to a device-mapper disk
17:49:31 <adamw> this is the live case of the bug we discussed earlier
17:49:35 <jlaska> well, bcl and dlehman ... I think this is the Live version of the previous issue
17:49:38 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=584328
17:49:39 <buggbot> Bug 584328: medium, low, ---, bcl, NEW, AttributeError: 'NoneType' object has no attribute 'name'
17:50:09 <jlaska> yeah ... this came out of testing we did against F-14-Beta and it highlighted a failure to install the Live image on dmraid systems
17:50:17 * jlaska tries to recall the scope and impact
17:50:29 <jlaska> "This is causing anaconda to fail to discover existing storage after the first
17:50:32 <jlaska> run of the live installer since it relies on the DM_UUID of the partitions
17:50:35 <jlaska> being set to something sane.
17:50:37 <jlaska> "
17:50:39 <jlaska> according to the good, dlehman
17:51:11 <adamw> seems pretty blocker-y to me
17:51:26 <jlaska> yeah, and it's a independent of the partitions selected
17:51:42 <jlaska> meaning, not a funky unsupported partition scheme or anything
17:51:49 <dlehman> right -- anyone who does multiple runs including partitioning on dmraid systems will hit this
17:52:05 <dlehman> workaround is to reboot in between
17:52:14 <jlaska> dlehman: only happens on subsequent runs of the live image installer on dmraid systems?
17:52:43 <dlehman> or even run dmraid -an ; dmraid -ay ; dmraid -an in a shell between runs
17:52:53 <Oxf13> that seems pretty borderline to me
17:52:56 <dlehman> correct
17:53:02 <Oxf13> not sure if I'd agree to slip the release for something like that.
17:53:03 <dlehman> agreed re: borderline
17:53:27 <adamw> well, when we say multiple runs
17:53:28 <dlehman> unfortunately that's the one we already have solved
17:53:34 <adamw> are we talking multiple f14 runs?
17:53:45 <adamw> or would you hit this just installing on a system you installed f13 to before, for e.g.?
17:53:49 <adamw> that would seem pretty normal
17:53:50 <jlaska> adamw: running liveinst twice (without rebooiting the live installer between)
17:53:51 <Oxf13> boot, try to install, cancel, try to install again
17:53:56 <Oxf13> as opposed to
17:54:02 <Oxf13> boot, try to install, reboot, try to install again
17:54:04 <adamw> oh, i see
17:54:10 <dlehman> jlaska is correct
17:54:14 <adamw> then yeah, borderline. but not worth arguing too much about if there's already a fix
17:54:33 <Oxf13> proposed make it NTH
17:54:35 <jlaska> don't know if the patch has been proposed, reviewed, accepted yet
17:54:45 <jlaska> yeah, I think that might be more appropriate
17:54:53 <jlaska> NTH ack/nak?
17:55:25 <Oxf13> this way if it gets fixed, great.  If the fix doesn't stick, we aren't discussing it again in a week or three
17:55:27 <dlehman> +1 NTH
17:55:30 <Oxf13> I'm ack obviously
17:55:58 <adamw> +1 nth
17:56:02 <jlaska> #agreed 639138 - does not impact release criteria, but agreed to move to nice-to-have
17:56:09 <jlaska> any action needed here ...
17:56:13 <jlaska> patch review/accept/build etc...
17:56:14 <zodbot> Announcement from my owner (jsmith): Fedora Board Meeting (Q&A regarding Vision Statement) starting in #fedora-board-meeting in the next few minutes.
17:56:24 <jlaska> dlehman: I gather that's your realm?
17:57:21 <jlaska> #action 639138 - dlehman responsible for commiting fix for pending anaconda build
17:57:57 <dlehman> it's a parted patch, so it's out of my hands
17:58:08 <jlaska> #undo
17:58:08 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b7d2f93a1d0>
17:58:19 <jlaska> bcl has been blessed with parted now
17:58:39 <bcl> aye
17:58:41 <Oxf13> poor brian
17:58:45 <jlaska> #action 639138 - bcl owns parted, will review and potentially commiting fix+build
17:58:50 <jlaska> bcl: sound goodly?
17:58:59 <bcl> yep
17:59:03 <jlaska> aside from the poor wording :)
17:59:10 <jlaska> bcl: thx
17:59:14 <jlaska> next up ...
17:59:16 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=629192
17:59:18 <buggbot> Bug 629192: medium, low, ---, rosset.filipe, NEW, Twitter isn't functioning
18:00:17 <Oxf13> is pino a default?
18:00:25 <adamw> i believe it is yeah
18:00:29 <jlaska> I think it's on the live image
18:00:33 <stickster> IIRC yes, ships in desktop live image.
18:00:39 * stickster is redundantly redundant
18:00:41 * jlaska confirmed
18:00:42 <adamw> it was picked for f13 over gwibber due to gwibber's deps
18:00:47 <Oxf13> ah yeah, darn
18:01:00 <Oxf13> so newer pino fixes it, but has .... isues
18:01:01 <Oxf13> issues
18:01:05 <adamw> so this is another "#  All applications listed under the Applications menu must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items " case
18:01:27 <adamw> so we need to either fix pino for release, pick another tweetybook client, or not have one
18:01:28 <jlaska> yeah, seems so
18:01:36 <adamw> on that basis, +1 blocker
18:01:45 <jlaska> +1
18:02:40 <notting> gwibber's not as huge as it used to be, fwiw
18:02:44 <jlaska> any other votes?
18:03:01 <adamw> notting: i think we can ask desktop team to fix it one way or another - we don't care how, it's their call
18:03:07 <jlaska> for now, just focusing on whether this meets the criteria or not
18:03:14 <notting> adamw: heh. they own neither of the packages, but sure!
18:03:31 <adamw> notting: they do control the spin / comps, though
18:04:32 <adamw> the issue here is 'don't have a busted app on the desktop', not necessarily 'fix pino'
18:05:28 <Oxf13> +1 on blocker
18:05:55 <Oxf13> basically what we're saying is that being able to twitter is critical path
18:06:05 <adamw> nope
18:06:20 <adamw> because 'don't have a twitter client on the desktop spin / default install' would be an acceptable resolution
18:06:29 <adamw> from the blocker process POV
18:06:47 <Oxf13> hrm.
18:06:49 <adamw> the point isn't that we should ship certain functionality, but that the functionality we choose to ship ought to *work* :)
18:07:01 <Oxf13> so if pidgin is in the default spin, every possible network pidgin could connect to is critical?
18:07:17 <Oxf13> maybe I'm asking this wrong.
18:07:22 <Oxf13> does pino do anything other than twitter?
18:07:23 <adamw> not necessarily, the criterion is somewhat fuzzy - it just says 'basic functionality test', we can argue about what that means when appropriate
18:07:37 <adamw> identi.ca
18:07:39 <Oxf13> or is pino's basic functionality twitter?
18:07:47 <adamw> but that's about it. and it was explicitly added to be 'our twitter client'.
18:07:50 <stickster> pino's basic functionality is twitter and identi.ca.
18:07:56 <adamw> so i'd say in this case, the definition of 'basic functionality' is pretty clear
18:08:06 <Oxf13> ok, works for me
18:08:34 <jlaska> so I count +3
18:08:50 <adamw> okey dokey
18:09:12 <jlaska> proposed #agreed 629192 - accepted as a release blocker because affects basic functionality for pino which is included on Live image
18:09:34 <jlaska> the #action will probably be more interesting
18:09:49 <jlaska> #agreed 629192 - accepted as a release blocker because affects basic functionality for pino which is included on Live image
18:09:58 <jlaska> anyone want to propose next steps?
18:10:42 <adamw> i've added mclasen to the bug and outlined the options there
18:10:49 <adamw> fix pino, ship something else, ship nothing
18:11:00 <adamw> i don't think it's really our job to decide that, at least at this point
18:11:02 <stickster> I was going to suggest roping in mclasen, so adamw is ahead of the game as usual.
18:11:16 <adamw> if we get to a few days before release and nothing's happened we might need to start laying down the law =)
18:11:26 <jsmith> adamw: You have my permission to lay down the law.
18:11:29 <adamw> hehe
18:11:33 <jsmith> So let it be written, so let it be done!
18:11:37 <jlaska> adamw: right, I didn't mean to decide here, just to agree on what/who needed to make the call
18:11:48 <adamw> for now i guess mclasen is best placed
18:11:53 <adamw> i'll also mail the desktop list to flag up the issue
18:12:27 <jlaska> #action 629192 - adamw cc'd mclasen on the bz and plans to email desktop@l.fh.org to raise awareness of the issue
18:12:30 <jlaska> adamw: thanks
18:12:35 <jlaska> okay, before jumping to our next bz ...
18:12:42 <jlaska> I have to step away for a bit
18:12:57 <jlaska> there are 11 bugs remaining on the list
18:13:13 <jlaska> I anticipate that taking another hour
18:13:18 <jlaska> How do folks want to proceed?
18:13:27 * adamw can drive if you like
18:13:39 <jlaska> continue on, take a break and return here in 1 hour?
18:14:06 <jlaska> adamw's willing to drive, so I don't have a preference ... but wanted to give folks a chance for a break if desired
18:14:09 * jsmith wouldn't mind a break, as he's running the Fedora Board meeting
18:14:17 <Oxf13> I need to take a break
18:14:20 <jsmith> but you folks feel free to continue on without me
18:14:24 <adamw> ok, break is fine then
18:14:33 <jlaska> alright, so when should we meet back?
18:14:44 <jlaska> top of the next hour, in 45 minutes?
18:14:48 <jsmith> WORKSFORME
18:15:33 <jlaska> okay, so meeting back here @ 19:00 UTC (15:00 EDT, 12:00 PDT)
18:15:38 <adamw> roger
18:15:42 <jlaska> if for some reason I'm not back yet ...
18:15:44 <jlaska> #chair adamw
18:15:44 <zodbot> Current chairs: adamw jlaska
18:15:44 <jlaska> :)
18:16:02 <jlaska> #topic Intermission ... will return @ 19:00 UTC
18:16:09 <jlaska> see everyone shortly
19:00:10 <jlaska> hey folks ... ready to start back up
19:00:54 <jsmith> jlaska: Hit me with your best shot!
19:01:03 <jlaska> bold :)
19:01:32 <adamw> yo
19:02:01 <jlaska> Oxf13: lurking?
19:02:23 <jlaska> I believe we are now on ...
19:02:24 <Oxf13> sortof
19:02:28 <Oxf13> need to reload my bowl.
19:02:35 <Oxf13> um.  of mac-n-cheese.
19:02:39 <jlaska> haha
19:02:39 <adamw> suuuure
19:02:51 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=631591
19:02:52 <buggbot> Bug 631591: high, low, ---, jforbes, NEW, raw img fails on XP install; qcow2 works
19:03:03 <Oxf13> alright..
19:03:10 <Oxf13> it's mac-n-cheese with chorizo.  You got me.
19:03:52 <jlaska> okay, so we have Fedora 14, Fedora 13 and xen guest noted in our release criteria
19:03:57 <adamw> chorizo? is that what the kids are calling it these days?
19:04:17 <jlaska> but no other operating systems as virt guests
19:04:26 <Oxf13> adamw: good mexican stuff.
19:04:36 <Oxf13> jlaska: that seems fair to me
19:04:50 <Oxf13> jlaska: we have influence over those to some extent and aren't quite held hostage.
19:04:55 <adamw> yeah, i don't think we do cover windows guests as critical functionality, or intend to
19:05:40 <adamw> i don't see this as blocker or nth to be honest
19:05:46 <Oxf13> er
19:05:51 <jlaska> that was my next q ... about nth
19:06:01 <Oxf13> I'd like to see it fixed, if it's not invasive
19:06:07 <Oxf13> what's the criteria for NTH?
19:06:10 <jlaska> hey jforbes, we're talking about the blocker worthy-ness of #topic bug
19:06:11 <adamw> well, sure, i'd like to see it fixed too
19:06:16 <adamw> but i don't see any relationship between the fix and the release
19:06:28 <adamw> i don't see that we gain anything shipping this fix in images as opposed to updates
19:06:32 <jforbes> Yeah, not sure who set this as a blocker, I certainly dont see it as one
19:06:32 <jlaska> meaning the fix isn't required on the media?
19:06:35 <adamw> yep
19:06:39 <Oxf13> ok, fair enough
19:06:40 <jforbes> qemu isnt in images
19:06:54 <adamw> Oxf13: i don't have nth criteria, but 'principles', in the draft - https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft
19:06:54 <jlaska> it's on the DVD iirc
19:07:06 <jforbes> jlaska: I didn't think it was for F13
19:07:07 <adamw> sure, but there's no particular need for this to be fixed in the version on the images that i can see
19:07:22 <adamw> i'm trying to imagine a use case where it's important that you be able to run a windows xp guest before you can install updates, i can't really see one
19:07:55 <adamw> the basic principle i put in the draft page is "In general, nice-to-have bugs are usually bugs for which an update is not an optimal solution, and for which the fix is reasonably small and testable"
19:08:05 <adamw> key point 'update is not an optimal solution'
19:08:37 <Oxf13> k
19:08:43 <jlaska> jforbes: thanks, so seems like this is quite cut'n'dry.   I also wanted your input to determine whether we need to adjust release criteria to include running other operating systems as guests
19:08:51 <jlaska> but seems like consensus on both points is .... -1
19:09:21 <jforbes> either way, this fix should be in final qemu released, and make the ISO, I just didn't think of it as a blocker
19:09:30 <jlaska> proposed #agreed 631591 - not accepted as blocker.  No criteria exist for running XP as a guest.
19:09:43 <jlaska> jforbes: oh I see, you expect it will likely be resolved in time
19:09:53 <jforbes> jlaska: I do
19:10:01 <jlaska> jforbes: roger, thanks for the update
19:10:21 <jlaska> #info jforbes anticipates 631591 will be resolved in the final qemu release for F-14, but shouldn't block release
19:10:40 <jlaska> I think we have enough ACKs to proceed here
19:11:02 <jlaska> #agreed 631591 - not accepted as blocker.  No criteria exist for running XP as a guest.
19:11:10 <Oxf13> note that if it's not NTH, the final qemu build needs to be done soonish
19:11:21 <Oxf13> by 10/18
19:11:37 <adamw> thanks for that deadline
19:11:43 <jlaska> #info if not blocker or nice-to-have, final build must be completed by 10/18
19:11:52 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639393
19:11:54 <buggbot> Bug 639393: medium, low, ---, fabian, NEW, Broken dependency: qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
19:12:06 <jlaska> okay, notting are you just making up package names now? :)
19:12:10 <adamw> =)
19:12:15 <Oxf13> jlaska: further note, "completed" means through bodhi and marked as stable.
19:12:23 <adamw> proposal: 'rejected, fictional package'
19:12:46 <adamw> aiui, only broken deps on the release media are considered blocking, right?
19:12:48 <jlaska> Oxf13: that was something adamw needed to circle back with you on anyway, thanks for clarification
19:12:57 <jlaska> adamw: right on ... per Alpha criteria
19:13:15 <Oxf13> yeah, but awfully lame to ship a repo with broken deps in it as a "release"
19:13:21 <jsmith> No kidding :-/
19:13:29 <Oxf13> for final, I'm willing to say no broken deps
19:13:34 <adamw> we can adjust that if we want to shoot for no broken deps at all, but i think we initially decided that was a bit ambitious
19:13:46 <Oxf13> for alpha/beta I agree
19:13:51 <adamw> and that it was a bit of a tough sell in the final blocker meeting to say we're delaying the release a week to fix a broken dep in some obscure package no-one cares about
19:13:58 <Oxf13> but for final, that just seems like laziness to not fix it
19:14:18 <jlaska> I'd love this too, but in practice, we've settled on the approach adamw mentioned
19:14:22 <Oxf13> adamw: that'd be our fault for getting all the way to the final blocker meeting without identifying it and fixing it earlier
19:14:37 <adamw> Oxf13: sure, but we have to imagine the situation if we're going to define it as a blocker
19:14:57 <jlaska> https://fedorahosted.org/pipermail/autoqa-results/2010-October/042369.html
19:15:02 <jlaska> so all of those would be blockers
19:15:02 <adamw> i can go either way, just want to make sure we make a considered decision :)
19:15:06 <notting> i would at least like broken deps to be *tracked* as an item
19:15:17 <notting> as opposed to just 'things someone has to notice and file'
19:15:25 <Oxf13> yeah, I'm still for making them release blockers
19:15:31 <jlaska> note, broken deps, while ugly, are no longer installation blockers as you can --skip-broken in anaconda
19:15:55 <Oxf13> I can't in good conscious mark a release as GOLD knowing that there are broken deps in the repo.
19:16:01 <adamw> Oxf13: i think we'd need to have some kind of 'task force' to fix them in that case
19:16:07 <jlaska> even if it's not on the media?
19:16:07 <notting> adamw: FES!
19:16:16 <jlaska> notting: ?
19:16:16 <Oxf13> FES and proven packagers
19:16:17 <notting> jlaska: anaconda's always ignored deps if necessary
19:16:18 <Oxf13> jlaska: even if.
19:16:20 <adamw> because we can't really rely on Joe Volunteer Maintainer Of One Small Package to make or break the release
19:16:29 <adamw> notting: okay
19:16:51 <Oxf13> adamw: right, it's up to us to continue pointing out that this would be a blcoker
19:16:53 <adamw> notting: is FES aware of this plan? :P
19:16:59 <jlaska> I don't object, but this is a change (tightening) in our messaging on this topic
19:17:01 <Oxf13> and to gather the troops around fixing it
19:17:15 <adamw> we do have an automated broken dep report every day already
19:17:26 <adamw> if we're declaring all broken deps as blockers, that actually becomes simple
19:17:28 <jlaska> and autoqa results for this as well
19:17:30 <Oxf13> what we don't have is the broad communication that those are blockers.
19:17:31 <adamw> right
19:18:27 <jlaska> tossing this out there ... is it too late to begin enforcing this change?
19:18:31 <Oxf13> proposal: accept this bug as blocker specifically, and in general accept any broken dep in the Everything repo as a release blocker.
19:18:37 <Oxf13> jlaska: I don't think so
19:18:46 <adamw> well, if we want to agree in principle we're going to accept all broken deps as blockers we can proceed with this meeting on that basis, but then someone's going to have to draw up procedures and so forth afte the meeting
19:18:50 <jlaska> Oxf13: not just accept, hunt down and report all broken deps and then accept them
19:19:10 <adamw> can autoqa file reports for the broken deps it finds?
19:19:17 <jlaska> could it yes, does it, no
19:19:33 <Oxf13> looking at the last branched report, there isn't a terrible amount of brokenness
19:19:36 <jlaska> maintainers get emails about broken deps now, right?
19:19:37 <notting> does it have a mechanism to track bugs it's already filed for issue <foo> so it doesn't keep spamming people?
19:19:40 <Oxf13> jlaska: yes
19:19:41 <jlaska> can we update the text of that mail?
19:19:49 <Oxf13> ... yes
19:20:19 <jlaska> perhaps we adjust the mail to note that for F-14 issues, they are now considered release blockers (link to criteria), please resolve these by MM/DD
19:20:22 <jlaska> dunno
19:20:31 <Oxf13> we can do that sure
19:20:32 <jlaska> oh another data point
19:21:17 <jlaska> we adjusted our policy in F-14-Beta to accept intentional package conflicts (upstart + systemd)
19:21:49 <jlaska> do the proposed changes only hold for repoclosure, or are package and file conflicts included?
19:22:25 <Oxf13> well, we can start with just broken deps
19:22:32 <jlaska> during that discussion, the topic came up that some packages aren't in comps.xml ... and are not installable except via kickstart
19:22:36 <Oxf13> I'd like to see it extend to unintentional conflicts
19:22:44 <notting> 'packages should be installable'
19:22:47 <jlaska> that influenced our decision to allow the upstart/systemd package conflict continue
19:22:50 <jlaska> notting: YES
19:23:11 <Oxf13> side note, if it weren't for systemd/upstart would we still allow conflicts?
19:23:25 <jlaska> I don't see why
19:23:29 <jlaska> ... we would allow them
19:23:29 <Oxf13> because I'm not sure if systemd being in f14 going forward is something somebody is going to work on
19:24:04 <Oxf13> and if it's just for systemd, then i"d rather see that as the exception, instead of a broad "explicit conflicts is OK"
19:24:26 <adamw> i think we're losing track here
19:24:35 <adamw> i'm not sure this meeting is the best place to thrash out a high-level policy for this
19:24:37 <jlaska> yeah, sorry ... details I think we can work out of meeting
19:24:57 <adamw> if we're generally agreed that we're accepting broken deps as blockers we can proceed with the meeting on that basis and do the rest on ml
19:25:24 <adamw> so on that basis...propose we accept this as a blocker conditional upon someone drawing up a new criterion which requires no broken deps in any package at final stage
19:25:32 <adamw> who wants that action item? :)
19:25:34 <jlaska> and this is repoclosure in 'stable' right?
19:25:43 <jlaska> since anyone can toss crap into updates-testing
19:27:01 <adamw> right
19:27:08 <adamw> that's what gets frozen as final
19:27:38 <jlaska> I'm happy to take this up next week
19:27:45 <jlaska> I won't be able to start this topic today
19:28:04 <adamw> i can do it but i was hoping oxf13 or notting would :)
19:28:23 <jlaska> pretty please ... since you guys want it? :) :) :)
19:28:30 * jlaska adds an extra smiley for emphasis
19:28:34 <notting> if we're not fully comfortable as blockers, at least mark them all as NTH and track them there?
19:28:42 <notting> blocker iff on media?
19:28:51 <Oxf13> what do you want somebody to do?
19:29:07 <adamw> write up a release criterion
19:29:10 <Oxf13> just propose on list somewhere ?
19:29:19 <Oxf13> I'm not so good with that kind of wordsmithing
19:29:19 <adamw> right, just write up a criterion and send it to test list
19:29:28 <jlaska> to start discussion on the details etc...
19:29:50 <adamw> well, i guess i can do it then. actually i could have done it in the time we've spent kicking it around, so yeah, i'll do it. =)
19:30:48 <jlaska> proposed #agreed 639393 - conditionally accepted as a release blocker pending adjustment to release criteria to accept all installable package dependency/conflicts
19:31:44 <jlaska> #action 639393 - adamw will propose release criteria to test@ list to prevent package dependency/conflicts in F-14-Final
19:31:50 <adamw> mail sent
19:31:53 <jlaska> adamw: thank you
19:32:10 <jlaska> #agreed 639393 - conditionally accepted as a release blocker pending adjustment to release criteria to accept all installable package dependency/conflicts
19:32:25 <jlaska> silence was consent ... jk, any objections/concerns?
19:33:00 <Oxf13> finebyme
19:33:10 <adamw> ack
19:33:21 <adamw> Oxf13: nott: would be good for one of you to follow up with proposals for co-ordinating FES etc on this
19:33:54 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=635821
19:33:56 <buggbot> Bug 635821: medium, low, ---, gavin, NEW, Attempting to submit (scp or bugzilla) an exception report fails if networking not active
19:34:40 <jlaska> this is related to the Alpha release criteria that the installer must be able to report bugs to bugzilla
19:34:47 <adamw> alpha criterion "The installer must be able to report failures to Bugzilla, with appropriate information included "
19:34:58 <jlaska> I believe this is related to some networking changes in the F-14 installer, and the move to using 'report'
19:35:01 <adamw> i'm +1, seems like a big enough problem in the functionality to constitute breaking the criterion
19:35:14 <Oxf13> yep
19:35:17 <Oxf13> +1 blocker
19:35:22 <jlaska> I *think* it's as simple as install from a non-network install source, and hit a traceback
19:35:28 <jlaska> which is easy to test (and we have a test case for)
19:35:41 <adamw> seems like this has been assigned to the guy who maintains report, does anyone know him?
19:36:27 <jlaska> I know him, I can reach out to him
19:36:41 <jlaska> or did you want him here?
19:37:11 <adamw> if he's not around now it's fine
19:37:21 <adamw> i just don't know an irc nick to poke or anything
19:37:41 <jlaska> I don't see him in the usual places
19:37:43 <jlaska> I'll ping him after
19:37:58 <adamw> so, accept this as a blocker, action item for jlaska to follow up
19:38:01 <jlaska> #action 635821 - jlaska will ping gavin to make sure he knows this is a release blocker
19:38:23 <jlaska> #agreed 635821 - accepted as a release blocker per Alpha criteria that installer must be able to submit bugs to bugzilla
19:38:38 <jlaska> #topic
19:38:42 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590883
19:38:45 <buggbot> Bug 590883: medium, low, ---, dwalsh, MODIFIED, SELinux is preventing ... "write" access on ...
19:40:05 <jlaska> I suspect this is like previous selinux-policy issues ...
19:40:07 <jlaska> in MODIFIED
19:40:15 <adamw> not quite - it's fixed in -8
19:40:19 <jlaska> "Fixed in selinux-policy-3.9.5-8.fc14"
19:40:20 <adamw> which afaics isn't submitted as an update yet
19:40:30 <jlaska> so #action on dwalsh here
19:40:39 <adamw> yup
19:40:50 <jlaska> #action dwalsh - submit bodhi update for newer selinux-policy to fix 590883
19:40:59 <jlaska> now in reverse order ... is it a blocker
19:41:01 <adamw> btw, i propose this as a blocker due to the dupe 625367, which is a case of this you often see when booting KDE in f14
19:41:12 <jlaska> kdm greeter
19:41:16 <adamw> three of us have reported it
19:41:38 <Oxf13> +1 blocker
19:41:47 <jlaska> seems like a case of "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login"
19:41:49 <adamw> so this is the '#  In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ) ' criterion
19:41:54 <adamw> d'oh :)
19:42:12 <jlaska> let's consider that 2 additional +1's :)
19:42:13 <adamw> so +1 obviously
19:43:15 <jlaska> #agreed 590883 - accepted as a release blocker, fixed but not yet available for testing
19:43:38 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639391
19:43:40 <buggbot> Bug 639391: medium, low, ---, msuchy, NEW, Broken dependency: spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs >= 0:0.8.28
19:43:53 <jlaska> notting: has been busy
19:44:20 <jlaska> so using the working criteria proposal for dependencies in F-14-Final ...
19:44:24 <Oxf13> +1 blocker
19:44:40 <adamw> yup, +1
19:44:54 <jlaska> dumb question, but spacewalk-certs-tools is installable right?
19:45:17 * jlaska still hung up on what 'installable' means
19:45:21 <notting> no, because it cant resolve the dep
19:45:23 * notting tests
19:46:22 <Oxf13> it is not installable
19:46:37 <jlaska> how come?
19:46:53 <Oxf13> because yum can't satisfy the dep on spacewalk-backend-libs >= 0:0.8.28
19:47:00 * adamw isn't sure we're all on the same wavelength
19:47:09 <adamw> jlaska: do you mean if the broken dep was fixed, would it be usable?
19:47:29 <Oxf13> looks like that was a dep manually added, but there is no package providing spacewalk-backend-libs right now it seems
19:48:28 <jlaska> I'm not 100% I know what I mean, but previously we had talked about saome packages are not actually 'selectable' during install (not listed in comps)
19:48:37 <adamw> oh
19:48:39 <jlaska> I don't know if that makes a difference here
19:48:46 <jlaska> since with kickstart, everything is 'selectable'
19:48:48 <adamw> well, i think oxf13/notting's proposal is simply that we don't accept any broken deps in the repo
19:48:53 <adamw> doesn't matter if they show up in anaconda or not
19:49:01 <adamw> right?
19:49:16 <jlaska> okay ... I don't want to push us through that again here, I just needed a quick clarification
19:49:17 <Oxf13> correct
19:49:22 <jlaska> thanks all
19:49:44 <Oxf13> looks like it is hung up in review: https://bugzilla.redhat.com/show_bug.cgi?id=612581
19:49:45 <buggbot> Bug 612581: medium, low, ---, sochotni, ASSIGNED, Review Request: spacewalk-backend - Common programs needed to be installed on the Spacewalk servers/proxies
19:50:44 <Oxf13> grr collision
19:50:47 <jlaska> alright, so, how to handle this one?
19:51:04 <Oxf13> still a blocker
19:51:05 <jlaska> tentatively accept as a blocker based on working criteria update?
19:51:13 <Oxf13> revert to old build, finish review, drop dep, do something.
19:51:24 <jlaska> good, plenty of options for "resolving" the issue
19:53:31 <adamw> i already wrote in the bug report that it's a blocker, as we agreed it earlier =)
19:53:34 <jlaska> proposed #agreed 639391 - tentatively accepted as a release blocker based on proposed criteria update to include all package dependency problems
19:53:51 <adamw> ack
19:54:21 <jlaska> Oxf13: notting: ?
19:54:31 <notting> sure
19:55:23 <jlaska> #agreed 639391 - tentatively accepted as a release blocker based on proposed criteria update to include all package dependency problems
19:55:25 <Oxf13> thought I already said it was a blocker.
19:55:36 <jlaska> who has the ball here?
19:55:43 <Oxf13> (boy do I love git log -p !)
19:56:03 <Oxf13> I think the ball belongs in the hands of the package owner and the review requestee
19:56:52 <jlaska> #action 639391 - msuchy needed to resolve conflict
19:57:21 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=626205
19:57:23 <buggbot> Bug 626205: medium, low, ---, sgallagh, ASSIGNED, Unable to unlock screen
19:58:09 <adamw> so this seems more significant than the summary
19:58:10 <jlaska> hmm, interesting, this might explain a funky situation I've seen
19:58:16 <adamw> apparently a problem with long term LDAP auth connections
19:58:50 <Oxf13> hrm, ldap
19:58:57 <Oxf13> is that part of our release criteria?
19:59:07 <adamw> "Here's a session where I tried to log in via kdm but was rejected."
19:59:19 <adamw> not explicitly, but we're not particularly clear on what we cover and what we don't for auth
19:59:25 <adamw> if you couldn't log in to a desktop
19:59:33 <adamw> 'normally' we'd consider that breaching one of the criteria
19:59:45 <adamw> so you could argue the same for ldap, ultimately the result is you can't get into the system...
19:59:57 <Oxf13> just a tad bit harder for us to test :/
20:00:01 <adamw> yeah
20:00:06 * jlaska uses this setup daily
20:00:11 <jlaska> just trying to see if it's something I should be hitting
20:00:24 <jlaska> darn, sgallagh logged off
20:00:41 <adamw> jlaska: sounds from the bug like you have problems if you're away from the server a long time, or generally if the server's passing an odd result
20:00:52 <adamw> but yeah it'd be nice to get more info on the impact of this
20:01:18 <jlaska> yeah, I'd like to hear from sgallagh, he's good about escalating blocker bugs
20:01:22 <adamw> the relevant criterion here is alpha "In most cases, the installed system must boot to a functional graphical environment without user intervention"
20:01:43 <adamw> and we argue whether this qualifies with 'most cases' or not
20:02:16 <jlaska> shall we refrain from adding this to -accepted until we hear back from sgallagh
20:02:22 <jlaska> or add it, and adjust if needed
20:02:31 <jlaska> +1 to the latter
20:02:41 <Oxf13> or toss it on NTH and escalate it later if necessary
20:03:07 <jlaska> hmm, brings up interesting discussion about local vs remote login criteria
20:03:17 <jlaska> not sure we're ready to take that on yet
20:03:47 <jlaska> proposed #agreed 626205 - no action taken, reach out to sgallagh for help determining impact
20:04:00 <jlaska> this would leave it on the list for next week, if we haven't already adjusted it by then
20:04:09 <adamw> i think we should leave it a week
20:04:10 <adamw> yep
20:04:12 <jsmith> ACK
20:04:12 <adamw> so +1
20:04:15 <jlaska> okay
20:04:16 <Oxf13> ACK
20:04:28 <jlaska> #agreed 626205 - no action taken, need to reach out to sgallagh for help determining impact
20:04:47 <jlaska> #action jlaska to discuss impact of 626205 with sgallagh
20:04:58 <jlaska> (or he'll probably have posted it there in bz by the time I ping him)
20:05:14 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=637405
20:05:16 <buggbot> Bug 637405: medium, low, ---, peter, NEW, [abrt] telepathy-haze-0.4.0-1.fc14: media_channel_request_streams: Process /usr/libexec/telepathy-haze was killed by signal 11 (SIGSEGV)
20:05:36 <jlaska> "Trying to do an audio chat over yahoo crashes telepathy-haze.  Perhaps this
20:05:39 <jlaska> isn't available yet but
20:05:41 <jlaska> "
20:05:55 <jlaska> is that a plugin that's enabled by default
20:06:04 <adamw> doesn't feel blocker-y to me, i wouldn't call that 'basic functionality'
20:06:24 <jsmith> Hmmmmn...
20:06:34 <jsmith> Is telepathy-haze installed on the livecd?
20:06:38 <jsmith> (just curious)
20:06:53 <jlaska> yes
20:07:06 <adamw> yes
20:07:20 <Oxf13> yeah, not sure about basic functionality there
20:07:22 <jsmith> I'm of two minds on that one... yes, it's not super-common
20:07:43 <jsmith> (and dependent on a proprietary sevice on the intarwebs)
20:08:05 <jlaska> I
20:08:35 <jsmith> I guess I'm leaning slightly towards it not being "basic functionality"... but only slightly
20:09:02 <jlaska> I'd love it if we considered this kind of stuff basic functionality, but it's certainly not something I'd consider "basic" given experiences there
20:09:37 <jlaska> alright, so I'm seeing a -2 and a -0.2
20:09:58 <jlaska> any other action needed here?
20:10:12 <jlaska> something to consider for NTH since it's on the live image?
20:10:42 <adamw> i don't mind putting it nth for now
20:10:47 <jsmith> NTH for now is fine
20:10:53 <jsmith> +1 to NTH
20:10:53 <Oxf13> +1 NTH
20:11:17 <jlaska> #agreed 637405 - not accepted as release blocker, accepted as nice-to-have.  Will take if fix is available
20:12:00 <jlaska> #action Peter_Gordon - investigate and recommend solution for bug 637405
20:12:01 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=637405 medium, low, ---, peter, NEW, [abrt] telepathy-haze-0.4.0-1.fc14: media_channel_request_streams: Process /usr/libexec/telepathy-haze was killed by signal 11 (SIGSEGV)
20:12:19 <jlaska> 4 left
20:12:21 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528022
20:12:23 <buggbot> Bug 528022: medium, low, ---, ajax, ON_QA, setroubleshoot:      SELinux is preventing /usr/sbin/vbetool "mmap_zero" access on &lt;Unknown&gt;.
20:12:38 <jlaska> "Added to selinux-policy-3.7.19-62.fc13"
20:12:47 <Oxf13> same song and dance as the last one
20:12:51 <jlaska> fixed available and awaiting testing
20:12:52 <jlaska> yup
20:13:34 <adamw> i don't think it's that simple
20:13:43 <jlaska> adamw: what'd we miss?
20:13:46 <Oxf13> do tell
20:13:49 <adamw> that's f13, for a start
20:13:57 <adamw> and i don't think it's a fix for the avc exactly
20:14:09 <adamw> i think this is the case where vbetool wants to do something that selinux really does consider 'bad'
20:14:27 <adamw> selinux pops up a custom alert which says 'there's a variable you can set to let vbetool do this, but we really recommend you don't unless suspend isn't working right'
20:14:34 <adamw> i _think_ the f13 change is simply to add that to f13
20:15:03 <jlaska> see 636586
20:15:06 <notting> i thought the change is 'gaaah, vbetool, don't do that'?
20:15:09 <jlaska> looks like it was resported against f14 too
20:15:18 <jlaska> but dup'd against the f13 version
20:16:14 <adamw> but yeah, the point is that there's no change yet which stops these messages appearing by default; the f13 change referred in this bug is just to add the variable so you have the potential to set it there
20:16:23 <adamw> notting: that would probably be it, but i'm not sure if that's practical
20:16:36 <jlaska> oh I see
20:16:42 <adamw> dwalsh would probably be the best person to talk to here, but he doesn't seem to be around :/
20:17:03 <jlaska> yeah, I'd want to know if this is the only proposed change for the issue
20:17:06 <adamw> so i think from an selinux-policy perspective the default is not going to change, intentionally
20:17:14 <jlaska> to offer a boolean to quiesce the avc
20:17:21 <adamw> dan thinks the thing vbetool does is bad and it shouldn't be allowed to do it unless you _really really_ need it to
20:17:34 <adamw> so the only option here is to make vbetool not do that, if it's practical
20:18:00 <adamw> otherwise i think we should have this as an exception to the criterion given the circumstances.
20:18:19 <adamw> jlaska: the boolean is already in f14, it's 'proposed' for f13
20:19:24 <jlaska> Can you run the #action #agreed #info for this
20:19:36 <jlaska> I'm not sure what's needed for us to decide w/ f14 for this issue
20:20:22 <adamw> well, i think we need to find out if it's possible to modify vbetool to do what it needs to do without hitting the selinux policy
20:20:43 <adamw> if that's possible, it should be done; if it's not, we're just going to have to have an exception for this alert, because it's necessary
20:21:12 <notting> i think the point is to make sure kms cards don't need vbetool, and move everything to kms eventually
20:21:18 <jlaska> exception, since it's already in f14, right?
20:21:34 <adamw> propose #agreed 528022 is technically a blocker under criterion 'In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login', but the alert on vbetool's behaviour is explicitly desired; if vbetool cannot be adjusted we should except this alert from the criteria
20:21:53 <adamw> jlaska: exception because we *want* this alert to happen; we don't want to adjust selinux-policy to not complain about this behaviour
20:22:13 <jlaska> adamw: k
20:22:18 <adamw> but we do need to make it possible for people to enable the bad behaviour if they really need it to suspend
20:22:38 <adamw> so if we can't fix it vbetool side, there's no real way out of it besides the current one (pop up an alert and educate the user about the issue)
20:22:48 <jlaska> ack
20:23:10 <adamw> propose #action adamw to follow up with dwalsh and vbetool maintainer to discover if there's any practical way to fix this
20:23:17 <Oxf13> for a lot of users that's just going to be gibberish though :/
20:24:08 <adamw> Oxf13: i've seen the alert on my systems, it does a pretty good job of laying out the alternatives clearly (if your system suspends okay, leave things alone; if it's not, you can click this button to turn off the check if you like)
20:25:32 <jlaska> any other ack/nak thoughts
20:25:51 <jlaska> 3 left after this folks
20:26:17 <Oxf13> adamw: just saying that if we're going to keep this popup in, we should run it through the Desktop team, or some UX designer
20:26:22 <Oxf13> (if it hasn't been already)
20:26:33 <adamw> good point
20:27:13 <adamw> ok, i updated the bug
20:28:14 <jlaska> adamw: want to note the #agreed/#action before moving on?
20:28:41 <adamw> oh yeah
20:28:46 <adamw> #agreed 528022 is technically a blocker under criterion 'In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login', but the alert on vbetool's behaviour is explicitly desired; if vbetool cannot be adjusted we should except this alert from the criteria
20:28:49 <adamw> #action adamw to follow up with dwalsh and vbetool maintainer to discover if there's any practical way to fix this
20:28:57 <jlaska> adamw: thanks
20:29:02 <jlaska> alright, moving on
20:29:08 <jlaska> 3 xorg* issues
20:29:10 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=603386
20:29:12 <buggbot> Bug 603386: low, low, ---, ajax, NEW, Login screen no longer cross-fades from final plymouth screen on Intel graphics
20:30:00 <adamw> doesn't smell blockery.
20:30:05 <jlaska> We don't have criteria to guaruntee a smooth display transition from boot to login
20:30:22 <adamw> yup.
20:30:24 <adamw> -1 blocker.
20:30:37 <adamw> (we have a Test Day test for this, but those don't constitute blockers at all.)
20:30:39 <Oxf13> -1 blocker unless the desktop team really raises a stink on it
20:30:40 <jlaska> the intended behavior is still supposed to be a smooth transition right?
20:30:45 <adamw> yes
20:30:48 <Oxf13> NIH I suppose?
20:30:51 <adamw> although not with dual-head
20:30:52 <Oxf13> well, not even that
20:31:48 <adamw> rh doesn't have anyone employed to hack on intel really atm, no (only ajax, but he's more of a generalist)
20:31:56 <adamw> intel kept hiring the people we had =)
20:32:11 <adamw> but yeah, this just ain't a blocker, it's a minor cosmetic.
20:32:20 <jlaska> we've passed on bugs that are hardware specific and only impact a small range of system(s)
20:32:27 <jlaska> so I agree with -1 here
20:33:03 <jlaska> #agreed 603386 - not accepted as a blocker bug, no criteria exist to guaruntee a smooth display transition during boot/login on all hardware
20:33:14 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623956
20:33:16 <buggbot> Bug 623956: medium, low, ---, ajax, NEW, VESA driver fails in qemu/kvm machines, system hangs at X init
20:33:28 <jlaska> ah, one of adamw's favorites
20:33:49 <adamw> i don't see this as a blocker
20:33:54 <adamw> there's no particular reason to use vesa in kvm
20:34:06 <adamw> i mean, it's quite nice for us to be able to test 'basic graphics mode', but meh.
20:34:11 <jlaska> I agree, but note here that we dangle it in front of users
20:34:38 <jlaska> I'd like to keep this on CommonBugs for the final release if possible?
20:34:44 <jlaska> or is there a release note appropriate?
20:34:51 <jlaska> (it's not an intentional change really)
20:35:00 <jlaska> just not supported
20:35:05 <adamw> commonbugs seems fine
20:35:12 <Oxf13> WORKSFORME
20:35:15 <Oxf13> is there no chance of a NIH?
20:35:16 <jlaska> alrighty
20:35:27 <adamw> oh
20:35:31 <adamw> you mean nth?
20:35:32 <jlaska> national inst. of health?
20:35:37 * adamw was thinking 'not invented here' and getting confused :P
20:35:57 <adamw> we can make it nth, i guess, sure, on the basis that a small fix for it can't hurt much
20:36:10 <Oxf13> ugh, NTH that is.
20:36:33 <adamw> i wouldn't want to make the last issue (intel transition) nth as poking X drivers late in release cycles for non-blocker reasons is scary
20:36:35 <adamw> but this one, sure
20:36:51 <adamw> as long as the proposed fix (if we get one) isn't too messy
20:36:55 <jlaska> #agreed 623956 - not accepted as release blocker, acceptable for nice-to-have.  VESA is not expected to work in KVM (cirrus)
20:37:15 <jlaska> #info willing to accept as a nice-to-have issue, if the fix is low-risk
20:37:23 <adamw> note that as part of the draft nth process i explicitly call out that we can re-evaluate nth issues very fluidly, we may take something as an nth initially but then decide not to take the fix if it's a big messy fix late in the process
20:37:31 <Oxf13> nod
20:37:34 <adamw> so we have that flexibility
20:37:37 <jlaska> okay
20:37:39 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=628528
20:37:41 <buggbot> Bug 628528: medium, low, ---, peter.hutterer, NEW, Emulating middle button doesn't work anymore.
20:37:43 <Oxf13> but I'd hate to set a goalpost for a developer, then decide "nope, sorry you worked on that!"
20:37:44 <jlaska> last one from my list
20:38:47 <jlaska> hmm, another hardware dependent issue
20:38:59 <jlaska> just depends on how many systems are affected
20:39:07 <adamw> Oxf13: well it's not as if the fix would be useless, it could go in an update or rawhide or whatever
20:39:10 <jlaska> I can retest on my T43 in the office
20:39:13 <adamw> Oxf13: so we're not going to be throwing the code away
20:39:52 <Oxf13> adamw: yeah, I just don't want to set an expectation that midnight oil should be burnt for NTH
20:40:21 <adamw> Oxf13: i kind of envisage us keeping in touch with the devs on active nth issues quite closely so they know roughly where they are
20:40:40 <Oxf13> k
20:40:48 <adamw> but i just don't want us to get in the position of having to take a fix because we accepted a bug as nth even if we're really scared of the 1,000 line change to anaconda :P
20:41:17 <jlaska> I don't think we have enough info for #topic bug ... reach out to hutterer?
20:41:19 <adamw> anyway, /topic bug - yeah, depends on the extent i think
20:41:22 <adamw> but definitely nth
20:41:41 <jlaska> so needinfo? on the maintainer
20:41:49 <jlaska> move to NTH for now?
20:42:12 <adamw> well i'd say leave it on F14Blocker but add AcceptedNTH keyword but no AcceptedBlocker or RejectedBlocker
20:42:19 <adamw> so its status as a blocker is undecided but it's definitely an nth
20:42:26 <jlaska> okay
20:42:29 <jlaska> ack/nak's?
20:43:58 <jsmith> ACK on NTH
20:44:09 <Oxf13> ACK on NTH
20:44:11 <Oxf13> FTW
20:44:16 <Oxf13> ASAP
20:44:18 <jlaska> #agreed 628528 - need more information from maintainer+reporter to determine impact.  Accepted as nice-to-have in interim
20:44:50 <jlaska> alright ladies and gentlemen
20:44:53 <jlaska> that's it for my list
20:44:55 <adamw> okay
20:45:02 <adamw> can we do a quick run through NTH bugs we didn't touch yet?
20:45:06 <adamw> shouldn't take as long as blockers
20:45:21 * adamw has the list queued
20:45:30 <jlaska> adamw: you're welcome to, but I need to drop off :(
20:45:33 <adamw> ok
20:45:47 <jlaska> we can reschedule the NTH review for Tuesday if you want?
20:45:55 <jlaska> or I'll leave you to power through it in 5 mins :)
20:46:00 <adamw> i'd rather get it done while we have everyone here
20:46:09 <adamw> all we really need is a quick yay/nay vote on each one
20:46:14 <adamw> should be a couple of minutes a bug
20:46:15 <jlaska> alrighty, take it away
20:46:22 <jlaska> I'll handle sending the minutes later this evening
20:46:24 <adamw> #info NTH review process start!
20:46:26 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=627073
20:46:27 <buggbot> Bug 627073: high, low, ---, ajax, NEW, VESA driver does not work with X700 Pro (1002:5e4b)
20:46:31 <jlaska> thanks folks!
20:47:03 <adamw> so this is a vesa-doesn't-work case, i think it's generally worth taking these as NTH on the basis we want as wide as possible support for some kind of graphics capability
20:47:26 * adamw +1 for nth
20:48:03 <Oxf13> +1
20:48:32 <adamw> #agreed 627073 acceptednth
20:48:35 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=632805
20:48:36 <buggbot> Bug 632805: medium, low, ---, ajax, ON_QA, basic video driver fails in bare metal install (goes into text mode)
20:48:44 <adamw> same type of issue - vesa fail
20:49:19 <adamw> +1 from me
20:50:54 <robatino> i tested a F13 build that claimed to fix this and it didn't work (see comment 39)
20:51:05 <Oxf13> _1
20:51:06 <adamw> robatino: sure, for now we just want to establish if it's nth or not
20:51:09 <Oxf13> +1 that is
20:51:13 <adamw> #agreed 632805 acceptednth
20:51:25 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=634556
20:51:26 <buggbot> Bug 634556: medium, low, ---, nkumar, ASSIGNED, language support is not installed by selecting few languages.
20:51:51 <adamw> this is one of the 'greatest hits' from the i18n test day - if you use s-c-language to enable support for a language it ought to install all the necessary packages for that language, for some it apparently doesn't
20:52:40 <adamw> this can probably be handled with an update, but it's probably a good thing to have working in images
20:52:51 <adamw> so i'm +1 for it
20:53:09 <Oxf13> yeah, +1
20:54:03 <adamw> #agreed 634556 acceptednth
20:54:13 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=634777
20:54:14 <buggbot> Bug 634777: medium, low, ---, mgracik, NEW, Firstboot does not show translations in hardware profile screen
20:54:24 <adamw> exactly as described =) for me this is almost a blocker actually
20:54:35 <adamw> it's probably not good to show people a whole screen not in their chosen language right during install
20:54:36 <Oxf13> is there supposed to be translations there?
20:54:56 <adamw> i guess we should check if this is everything on that screen, or just the actual smolt profile
20:55:11 <adamw> the profile itself presumably can't be translated as it's dynamically generated
20:55:17 <Oxf13> right, a screenshot might be helpful
20:55:26 <adamw> k
20:55:43 <adamw> shall we say +1 if it's the 'chrome' (the fedora stuff)?
20:58:15 <adamw> #agreed 634777 need more info on exactly what strings are affected; if things that are part of the fedora 'chrome' on the page are affected, than we accept
20:58:22 <adamw> silence is agreement!
20:58:44 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=635239
20:58:45 <buggbot> Bug 635239: high, low, ---, rvykydal, NEW, Install gets stuck in repo config stage if you specify an non-functional network configuration
20:59:01 <adamw> this is one i proposed, actually its status seems a bit uncertain and i should do more testing of f13 / f14 to see if i'm right on this one
20:59:24 <adamw> so i'm going to drop the proposal for now
20:59:36 <adamw> #agreed 635239 adamw drops proposal as nth bug pending further testing
21:00:10 * notting keeps reading that as a continuation of 1st, 2nd, ... 5th, 6th, ... nth
21:00:15 <adamw> =)
21:00:17 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636170
21:00:18 <buggbot> Bug 636170: medium, low, ---, atkac, ON_QA, tigervnc-server does not actually need xorg-x11-fonts-misc
21:00:33 <adamw> this is an unnecessary dep -> live spin size issue aiui
21:00:52 <adamw> so i'm +1, it's always worth pruning deps to help with live image size
21:01:49 <Oxf13> +1 too, looks like it should be in QA?
21:02:27 <adamw> it is, and has +1 karma, just needs to be pushed stable now really
21:02:40 <adamw> #agreed 636170 acceptednth
21:02:49 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=636227
21:02:50 <buggbot> Bug 636227: medium, low, ---, kevin, NEW, RFE: No mixer applet on XFCE desktop (F14 Beta RC3)
21:03:12 <adamw> so this is the 'non-default desktop breaks desktop criteria' case which we agreed last week we'd take as nth instead of blockers
21:03:24 <adamw> so, obvious +1 for me
21:03:42 * nirik will fix that one soon. Just want to see what the sig feels is the best way to do so.
21:04:49 <adamw> cool
21:06:04 <adamw> silence is acceptance!
21:06:05 <adamw> #agreed 636227 acceptednth
21:06:39 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=638656
21:06:40 <buggbot> Bug 638656: high, low, ---, ajax, NEW, undefined symbol: bgNoneRoot trying to run any app that uses pyxf86config
21:07:14 <adamw> this is the current state-of-the-art in system-config-display (and related tools in rpmfusion, and apparently sometimes system-config-keyboard ) being broken
21:07:38 <Oxf13> hrm
21:07:48 <Oxf13> I know those were words, but...
21:07:51 <adamw> =)
21:08:11 <adamw> so, just try and run system-config-display and it'll fail, with bug #623742
21:08:12 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=623742 high, low, ---, ajax, NEW, xstrtokenize not properly provided by X server (breaks anything that uses it or libxf86config)
21:08:28 <adamw> after you get the fix for that (which is available in that bug), and try running it again, you run into this bug instead
21:09:06 <adamw> there's this little python library called pyxf86config which s-c-d and other s-c tools which try to write xorg.conf use
21:09:17 <adamw> the tools in rpmfusion to enable nvidia, ati, psb etc also use it
21:09:23 <adamw> so it being broken causes quite a lot of grief.
21:10:40 <Oxf13> yeah, is there a hold up on the fix?
21:10:50 <adamw> ajax hates fixing these =)
21:10:55 <adamw> that's basically the hold up.
21:11:19 <adamw> he gave a clue to a fix in irc but i'm too dumb to figure out how to do it.
21:12:09 <Oxf13> *shrug* NTH
21:12:28 <adamw> yeah. it's not super critical which is why i didn't propose as a blocker, but definitely if a fix shows up during freeze i'd want to take it.
21:12:37 <adamw> #agreed 638656 acceptednth
21:13:18 * nirik has another bug to note at some point here. Might be a blocker...
21:13:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=542255
21:13:25 <buggbot> Bug 542255: medium, low, ---, leigh123linux, ASSIGNED, [abrt] crash detected in gmixer-1.3-11.fc12
21:13:28 <adamw> nirik: ok, we'll do open floor when we're done with nth
21:13:35 <adamw> which should be very soon, this is the second-to-last
21:13:46 <adamw> this one's another 'non-default desktop spin breaks desktop criteria' case
21:13:48 <adamw> so, obvious +1
21:13:55 <adamw> (it's the broken mixer applet in LXDE spin)
21:14:54 <Oxf13> +1
21:14:56 <adamw> #agreed 542255 acceptednth
21:15:05 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623742
21:15:06 <buggbot> Bug 623742: high, low, ---, ajax, NEW, xstrtokenize not properly provided by X server (breaks anything that uses it or libxf86config)
21:15:25 <adamw> this is just the other pyxf86config breakage issue (which actually turns out to be x server not providing something it claims to)
21:15:36 <adamw> so, if 638656 is nth, this is too.
21:15:42 <adamw> +1
21:17:31 <adamw> silence is compliance!
21:17:31 <adamw> #agreed 623742 acceptednth
21:17:39 <adamw> okay, so we're done with nth
21:17:42 <adamw> #topic open floor
21:17:47 <adamw> nirik, you had a bug to highlight?
21:18:09 <nirik> yeah. https://bugzilla.redhat.com/show_bug.cgi?id=639280 which seems to be http://bugzilla.gnome.org/show_bug.cgi?id=630861
21:18:10 <buggbot> Bug 639280: medium, low, ---, kevin, ASSIGNED, Terminal - Your terminal lacks the ability to clear the screen or position the cursor
21:18:11 <buggbot> Bug 630861: normal, Normal, ---, vte-maint, UNCONFIRMED, Embedded Terminal Emulator isn't giving a TERM variable
21:18:30 <fenris02> anyone else tried to network boot f14?  it failed to bring up eth0 here, but i dont know if that is already a known bug or not.
21:18:31 <nirik> this seems to affect Xfce's Terminal, roxterm, lxterminal, etc...
21:19:11 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=639280
21:19:12 <buggbot> Bug 639280: medium, low, ---, kevin, ASSIGNED, Terminal - Your terminal lacks the ability to clear the screen or position the cursor
21:19:27 <adamw> so, if we're sticking strict to criteria, since this doesn't break GNOME or KDE's terminals, it's not a blocker...but definitely nth
21:19:30 <adamw> and it's a nasty bug
21:19:53 <nirik> yeah, reverting that one commit seemed to fix it here, but I haven't rebooted yet, so perhaps I did something else to fix it.
21:19:57 <nirik> more testers very welcome.
21:21:00 <adamw> i'd +1 this as nth and i'd like to try and make sure we get it fixed...i'd like to +1 it for blocker but i think it's not quite with our current arrangements :/
21:21:05 <adamw> Oxf13: wdyt?
21:21:18 <nirik> yeah, could be.
21:21:27 * nirik notes it should probibly also move to 'vte' component...
21:21:34 <adamw> yeah
21:21:43 <adamw> i will do that as part of secretary-ing
21:24:24 <Oxf13> +1
21:24:29 <adamw> ok
21:24:42 <adamw> #agreed 639280 accepted as nice-to-have, and would definitely like to see it fixed
21:25:00 <adamw> any other bugs for open floor?
21:27:32 <adamw> okay then, i think we're done :)
21:27:34 <adamw> thanks all!
21:27:56 <adamw> #endmeeting