17:00:46 <jlaska> #startmeeting F15 Blocker Review#2
17:00:46 <zodbot> Meeting started Thu Apr 21 17:00:46 2011 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:52 <jlaska> #topic Roll Call
17:01:02 * rbergeron is here.
17:01:03 <jlaska> #meetingname f15-blocker-review
17:01:03 <zodbot> The meeting name has been set to 'f15-blocker-review'
17:01:18 * tflink is present
17:02:46 <jlaska> adamw is doing double duty today with the test day
17:02:52 <jlaska> dgilmore are you available for the review today?
17:03:46 <jlaska> robatino: tflink: rbergeron: clumens: hello
17:03:52 <jlaska> anyone else lurking for the review today?
17:04:13 <dgilmore> im around
17:04:23 <clumens> hey
17:04:50 <adamw> yo
17:05:49 <jlaska> okay, let's get this train started
17:05:53 <jlaska> #topic Introduction
17:05:58 <jlaska> some handy links ...
17:06:02 <jlaska> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:06:07 <jlaska> #link https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria
17:06:18 <jlaska> and of course ...
17:06:21 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:06:39 <jlaska> So I'll walk through the accepted first, we'll make sure they're getting the attention they need
17:06:55 <jlaska> then the proposed blockers, and we'll review them against the release criteria
17:07:01 <jlaska> then the proposed NTH bugs
17:07:09 <jlaska> any comments/thoughts before we dive in?
17:07:11 <jlaska> prayers?
17:07:18 <rbergeron> Sounds lovely. Let's go :)
17:07:40 <jlaska> okay, a few accepted blockers up first ..
17:07:42 <jlaska> #topic https://bugzilla.redhat.com/695389
17:07:47 <rbergeron> Approved list is actually getting shorter, which is nice :)
17:07:51 <jlaska> #info anaconda-15.28-1
17:07:56 <jlaska> #undo
17:07:56 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x18b30fd0>
17:07:59 <jlaska> #info fixed in anaconda-15.28-1
17:08:14 <jlaska> clumens: did you have a rough eta for doing another build?
17:08:36 <clumens> jlaska: now that dcantrell's committed the transifex stuff so we pull in the latest translations, i can do one right now.
17:08:41 <rbergeron> jlaska: we should make the page show the full-blown bz link rather than the short link, so it adds the buginfo through the bot
17:08:42 <clumens> that was the last thing i was waiting on
17:08:55 <jlaska> rbergeron: I can
17:09:01 <jlaska> clumens: okay, cool
17:09:06 <jlaska> this bug looks like it's on it's way then
17:09:13 <jlaska> there is one last comment from Patrick regarding another bz ...
17:09:17 <jlaska> "Will you adjust 698249 so that it is marked as DUP of the correct bug or do you
17:09:18 <rbergeron> just for cut and paste purposes :)
17:09:21 <jlaska> want me to?"
17:09:21 <jlaska> rbergeron: right
17:09:38 <jlaska> rbergeron: I'll be attempting to update the escript this afternoon to follow deps, so I'll make that change also
17:09:45 <rbergeron> cool.
17:10:14 <jlaska> nm, I think we are good here, the other bug is already DUPd
17:10:35 <jlaska> rbergeron: tflink: are one of you able to assist with updating the bugs as we go?
17:10:44 <jlaska> (or anyone else who wants to volunteer)
17:10:52 <adamw> yeah, if someone could do secretarying today it'd be cool, i may not be able to keep up
17:11:26 <rbergeron> I can, though I'll probably hav eto comb through some of it afterwards
17:11:54 <tflink> either way. I'm probably not going to fight you for it :)
17:12:06 <adamw> you could alternate!
17:12:16 <jlaska> that work for you both?
17:12:42 <jlaska> #info clumens expects a new build to arrive later today (waiting on a transifex change)
17:12:56 <tflink> sure, I might have to catch up afterwards since I need to leave in ~ 2.5 hours
17:13:07 <jlaska> tflink: I'm optimistic we'll be done by then
17:13:12 <clumens> jlaska: transifex change is done.
17:13:14 <jlaska> okay, tflink can you update this one?
17:13:17 <tflink> jlaska: I'm hoping
17:13:20 <clumens> waiting on my own laziness
17:13:37 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=689260
17:13:38 <buggbot> Bug 689260: unspecified, unspecified, ---, tbzatek, NEW, [abrt] nautilus-2.91.91-1.fc15: gtk_action_group_add_action: Process /usr/bin/nautilus was killed by signal 11 (SIGSEGV)
17:13:49 <dgilmore> clumens: com'n get it together
17:14:24 <clumens> i'll wait to see if any emergencies arise out of this meeting, and then do it... unless this meeting goes on forever like the last one did, in which case i'll just do it.
17:14:48 <jlaska> #info waiting in NEEDINFO
17:15:00 <tflink> hmm, no more repros recently
17:15:03 <jlaska> this is almost a month old, I think just an update from the reporter
17:15:10 <jlaska> yeah, seems like it may have magically fixed itself?
17:15:16 <dgilmore> jlaska: yep
17:15:29 <adamw> yeah, it's odd to have to wait so long for mat
17:15:33 <adamw> i wonder if he's away or smth
17:15:39 <jlaska> could be
17:15:48 <adamw> propose we give it another week, and close next week if he hasn't replied
17:15:53 <adamw> he can always re-open if necessary
17:16:07 <tflink> works for me
17:16:27 <jlaska> #agreed 689260 - update bug with request for info, CLOSE at next meeting if no updates
17:16:43 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=682001
17:16:44 <buggbot> Bug 682001: unspecified, unspecified, ---, nphilipp, ASSIGNED, s-c-services  - all read and disabled
17:17:07 <tflink> rbergeron: if we're doing every other, did you do that anaconda one?
17:17:29 <adamw> not sure there's any action need here, we're waiting for nils to fix it
17:17:32 <rbergeron> it's on my list, yes
17:17:34 <jlaska> last update here is from Nils agreeing it's a blocker
17:18:05 <jlaska> perhaps just another tick that it was discussed during the meeting, and we are in waiting still
17:18:08 * rbergeron multitasking a moment here
17:18:18 * jlaska updates bug
17:19:09 <jlaska> okay, proposed bugs time
17:19:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=695492
17:19:19 <buggbot> Bug 695492: unspecified, unspecified, ---, mclasen, NEW, can't tell whether "Verify and Boot" on 15 Beta Live image boot menu actually does a verify
17:19:52 <jlaska> robatino: when you tested, was this using a USB image, or a CD/DVD ISO?
17:20:04 <robatino> cd/dvd iso
17:20:16 <jlaska> hmm, I would expect it to do the right thing for that
17:20:40 <robatino> is it known that live images still have a built-in mediacheck?
17:20:42 <adamw> we don't have a criterion for this, and i can be okay with it not being a blocker
17:20:43 <jlaska> As you point out in the bug, I don't think this hits any existing criteria
17:20:56 <adamw> the impact at worst is 'it just goes ahead and boots', which isn't _terrible_
17:21:29 <jlaska> and it behaves differently (when it behaves) depending on CD vs USB booting
17:21:39 <adamw> definitely +1 nth, though
17:21:41 <jlaska> so this is an annoyance for sure, but I don't think we can block for it
17:21:45 <jlaska> yeah, agreed
17:21:58 <jlaska> +1 to nth ... certainly worth taking a "fix" for if we have one
17:22:29 <adamw> right
17:22:42 <adamw> we should probably get cwickert and nirik on the bug
17:22:44 <jlaska> after we get votes, will ask who is the right person to help move this fwd
17:22:49 <jlaska> adamw: bingo :)
17:23:02 <jlaska> robatino: you always find good ones :)
17:23:14 <adamw> there's someone else too, i always forget who
17:23:18 <robatino> so i take it the mediacheck is supposed to be there?
17:23:24 <jlaska> adamw: bcl?
17:23:47 <jlaska> robatino: it was at some point ... whether it's doing what was originally intended may be up for grabs
17:23:47 <StylusEater> adamw: I wonder if someone can repeat the panel crash when adjusting sound volume through system settings ... I've now experienced two lockups when submitting the error
17:23:49 <adamw> bruno
17:23:56 <jlaska> adamw: ah!
17:24:02 <jlaska> any other votes?
17:24:08 <tflink> +1 nth
17:24:14 <adamw> StylusEater: can we discuss in test-day for now?
17:24:27 <StylusEater> adamw: oops, yes sorry
17:24:32 <jlaska> #agreed 695492 - AcceptedNTH - Seek guidance from bruno, nirik or cwickert to proceed
17:24:38 <rbergeron> /win 3
17:25:00 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696278
17:25:01 <buggbot> Bug 696278: high, unspecified, ---, dcbw, NEW, The system network services are not compatible with this version.
17:25:04 * jlaska updates previous bug
17:25:36 <rbergeron> jlaska - i'll update the bugs if you just want to stick my name in the #agreed so I know who is doing what
17:25:45 * rbergeron just went through bugs and saw you did some as well and was going to update them :(
17:25:55 <jlaska> okay
17:26:13 <adamw> this one seems confused.
17:26:57 * jlaska still reading
17:27:31 <tflink> yeah, seems to be partially a preupgrade issue?
17:27:38 <rbergeron> yeah, i think so
17:27:51 <jlaska> is this a "I rebooted while preupgrade was happening"
17:27:55 <jlaska> and my system doesn't work now?
17:28:04 <adamw> i propose asking for some more info
17:28:10 <adamw> i have a comment ready to go
17:28:31 <jlaska> this is just a need more info, imo
17:28:51 <jlaska> proposal - attempt to get to the bottom and review at next meeting?
17:29:02 <tflink> ack
17:29:06 <rbergeron> ack
17:29:28 * rbergeron wonders if it's similar to poelcat's preupgrade problem he had yesterday where the fix was in updates
17:29:43 <jlaska> yeah, we need to get a concrete list of package nvr's people are testing with
17:29:59 <jlaska> and I don't understand the missing logs ... syslogd not starting or something?
17:30:20 <jlaska> adamw: ack/nak/patch?
17:30:36 <adamw> ack
17:30:42 <jlaska> oh, wait ... you propsed already :)
17:31:24 <tflink> the part about asserting that NM was enabled via sysctl but the systemctl is-enabled NetworkManager.service &&
17:31:30 <jlaska> #agreed 696278 - NEEDINFO - unclear what cause is, request more information from reporter
17:31:34 <tflink> echo yes not echoing yes is odd
17:31:54 <jlaska> yes it is ... we might need output from systemd list-units as well?
17:32:02 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696107
17:32:03 <buggbot> Bug 696107: unspecified, unspecified, ---, dcbw, ON_QA, NetworkManager Openconnect fails in FC15 Alpha
17:32:33 <dgilmore> looks like its fixed
17:32:34 <jlaska> yeah
17:33:00 <jlaska> #info Fixed by NetworkManager-openconnect-0.8.1-9.git20110419.fc15
17:33:14 <jlaska> so as soon as that (or a newer package) goes into 'stable', this will move to CLOSED
17:33:22 <jlaska> anyway, blocker-y-ness?
17:33:33 <adamw> marginal
17:33:38 <jlaska> is NM-Openconnect at all criteria impacting?
17:34:00 <adamw> i can't think of many situations where you couldn't possibly pull down an update without an openconnect vpn connection
17:34:14 <jlaska> yeah, proposal: RejectedBlocker, RejectedNTH
17:34:25 <jlaska> just test the fix and all will be right with the world
17:34:30 <jlaska> ack/nak/patch?
17:34:33 <dgilmore> jlaska: ack
17:34:41 <rbergeron> ack.
17:34:43 <tflink> ack
17:34:56 <adamw> ack
17:35:28 <jlaska> #agreed 696107 - RejectedBlocker RejectedNTH - With testing, updated NM-openconnect package will land in 'stable'
17:35:48 <jlaska> we're all familiar with the next one ..
17:35:50 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678236
17:35:51 <buggbot> Bug 678236: medium, unspecified, ---, jmccann, NEW, User list sometimes not visible on greeter
17:36:25 <jlaska> The frequency which I've been seeing this has stopped (or gone way down) on my system
17:36:34 <adamw> yaay.
17:36:40 <adamw> someone suggested a relationship to fprint
17:36:46 <jlaska> what was our call on this last week?
17:36:55 <adamw> we wanted to know if anyone had seen it on live images
17:36:58 <adamw> a couple have
17:37:17 <jlaska> hrmmm ... real hard finding a way to make this is *blocker*
17:37:30 <tflink> yeah, there were reports for SoaS and the gnome3 test day live image
17:37:36 <tflink> doesn't seem to be very consistent, though
17:37:49 * jlaska checking for halfline presence
17:38:06 <adamw> jlaska: it's not so hard, call it a high severity bug in gdm and bob's your uncle.
17:38:10 * dgilmore hates race conditions
17:38:14 <jlaska> adamw: right
17:38:33 <jlaska> NTH could be appropriate since this can be hit on initial system bring-up
17:38:38 <dgilmore> ive seen it on one machine
17:38:43 <dgilmore> but not the other i use
17:38:45 <jlaska> anyone opposed to NTH, and we keep working it with halfline?
17:39:30 <adamw> i really would kinda hate to ship with this
17:39:31 <adamw> it's just ugly
17:39:35 <jlaska> yeah
17:39:36 <adamw> but...i can go wit hit
17:39:42 <tflink> yeah, I'm kind of on the fence on this one
17:39:45 <jlaska> adamw: you wanting to make it a Blocker?
17:40:02 <adamw> nah, we can stick with the process. it just bugs me.
17:40:04 <tflink> but I'm not too opposed to making it just NTH
17:40:07 <jlaska> agreed
17:40:10 * rbergeron nods
17:40:19 * dgilmore is with ya'll
17:40:48 <jlaska> proposed #agreed 678236 - AcceptedNTH - doesn't impact blocker criteria, but likely a visible bug.  Continue working issue with maintainer
17:41:12 * jlaska almost as worried about fixing this bug ... since gdm seems sensative
17:41:33 <jlaska> Howdy halfline
17:41:36 <halfline> hello
17:41:38 <jlaska> just finishing up on #topic bug
17:41:48 <halfline> okie dokie
17:41:49 <jlaska> currently proposal is ...
17:41:53 <jlaska> proposed #agreed 678236 - AcceptedNTH - doesn't impact blocker criteria, but likely a visible bug.  Continue working issue with maintainer
17:42:11 <adamw> ack, but it'd be nice if halfline has any info
17:42:15 <adamw> got any closer to figuring out a fix?
17:42:24 <jlaska> we want to make it a blocker, since it's likely a visible bug, but we have a good workaround, and we don't have criteria to accept this as a blocker
17:43:18 <jlaska> halfline: we don't need a solution here, just wanted to get it on your radar, and see if you needed more info to proceed
17:43:59 <jlaska> #agreed 678236 - AcceptedNTH - doesn't impact blocker criteria, but likely a visible bug.  Continue working issue with maintainer
17:44:25 <halfline> jlaska: so i started to look at that bug yesterday
17:44:34 <halfline> but i didn't get very far
17:44:52 <jlaska> halfline: okay, thanks for picking that one up
17:44:56 <halfline> i rebooted like 30 times in a row and couldn't reproduce
17:45:06 <halfline> then spontaneously later in the day it happened once but i had loggng disabled
17:45:12 <jlaska> figures! :)
17:45:17 <adamw> maybe the logging affects the race?
17:45:22 <halfline> could be
17:45:23 <dgilmore> halfline: its toying with you
17:45:38 <halfline> anyway, it's on my whiteboard/radar already
17:45:42 <adamw> cool, thanks
17:46:01 <jlaska> halfline: awesome, thanks.  you've got people standing by ready to spam you with any debug logs needed ... just shout :)
17:46:14 <jlaska> okay, moving on ...
17:46:18 <jlaska> halfline: thanks for joining
17:46:32 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697834
17:46:33 <buggbot> Bug 697834: unspecified, unspecified, ---, rstrode, NEW, Other menu appears in default installation
17:46:55 <jlaska> adamw: nice comment in this bz
17:47:18 <jlaska> this fits the existing criteria ...
17:47:27 <jlaska> "There must be no Other menu or category "
17:47:27 <adamw> yup, it's a no-brainer per what we have
17:47:35 <adamw> just needs desktop team to look at it and decide on a fix
17:47:41 <tflink> seems like a pretty clear blocker
17:47:42 * jlaska prepares agreed line
17:47:51 <adamw> hey, looky, it's assigned to halfline :P
17:48:11 <halfline> first i've seen that bug
17:48:22 <halfline> changing the .menu files to not show Other ever seems like a good fix to me
17:48:29 <jlaska> #agreed 697834 - AcceptedBlocker - impacts desktop release criteria, maintainer investigating
17:48:34 <dgilmore> +1
17:48:58 <adamw> halfline: i think when we came up with the criteria the intent wasn't to hide any other menu that might show up, but to catch apps that didn't get properly categorized
17:49:15 <adamw> halfline: so the intended way to fix it is to catch when apps wind up in Other, and adjust them to be categorized properly
17:49:48 <halfline> well
17:49:57 * jlaska waits before moving on
17:50:28 <halfline> okay there are a few issues here.  we have too many apps show up by default i think
17:50:49 <halfline> the stuff that doesn't show up by default could potentially show up in other after being installed though
17:50:56 <jlaska> halfline: agreed
17:51:06 <halfline> and maybe in those cases other is also bad and wrong but of course not a blocker
17:51:09 <adamw> halfline: we're only concerned with what's in a default install (either live or dvd) as far as criteria go
17:51:10 <jlaska> (on the too many apps in the default view)
17:51:18 <halfline> adamw: right
17:51:24 <halfline> of course fundamentally any time anything is in Other
17:51:28 <halfline> it's an app bug
17:51:32 <jlaska> okay
17:51:35 <halfline> since the app is what chooses the categories
17:51:53 <halfline> if we manifest that app bug by showing it in "other" or not showing it at all
17:52:10 <halfline> both seem valid ways to show the bug
17:52:15 <dgilmore> halfline: id rather we show it in other
17:52:32 <jlaska> sounds like the existing criteria still holds in light of GNOME3?
17:52:38 <dgilmore> because id rather it be available rather than the user saying i installed it where is it
17:52:44 <jlaska> e.g. no criteria changes needed for this issue?
17:52:48 <adamw> halfline: the stuff that seems to be in there atm mostly is stuff with Categories=System;Settings; by the looks of it
17:52:53 <halfline> dgilmore: that's a reasonable viewpoint
17:53:02 <adamw> halfline: things showing up in Other is much more discoverable
17:53:04 <halfline> i'm not sure i agree 100% but don't have a super strong preference here
17:53:15 <adamw> halfline: all we have to do is boot a test image and file a bug for every app that shows up in Other
17:53:32 <jlaska> we don't need to work the details here either, we can continue with that elsewhere on IRC, or in the bug
17:53:32 <halfline> well hang on
17:53:36 <adamw> halfline: it makes it much harder to catch if the symptom is 'app doesn't show up at all' - we'd need to figure out a list of every app that _ought_ to be there, and then find them one by one, to catch the breakages
17:54:02 <dgilmore> adamw: so we should find everything with Categories=System;Settings; and get it set to something else
17:54:09 <adamw> looks like it.
17:54:12 <halfline> well wait
17:54:17 <tflink> in addition to the annoyance from stuff not showing up, like dgilmore said
17:54:17 <adamw> (or have gnome-menus handle that properly, if it's meant to.)
17:54:24 * adamw waits
17:54:24 <halfline> System;Settings; defnitely used to be covered
17:54:25 <dgilmore> or we put a translantion in somewhere that puts that where it should go
17:54:32 <halfline> so if it was changed
17:54:37 <halfline> it was probably changed explcitly
17:54:49 <halfline> and so
17:54:57 <adamw> halfline: it's all the
17:54:58 <halfline> basically we need to do more research first
17:54:59 <dgilmore> all the apps need chainged
17:55:05 <dgilmore> yeah
17:55:05 <adamw> all the 'old' fedora config tools mostly
17:55:07 <adamw> system-config-foo
17:55:19 <halfline> right
17:55:26 <halfline> so my point is
17:55:26 <adamw> anyway, like jlaska says, let's do the detailed discussion in the bug and move on
17:55:31 <jlaska> anything else to note before moving on?
17:55:44 <halfline> if this was changed, it was probably changed for a reason, and we should be careful to not undermine that reason before knowing what it is
17:56:01 <halfline> sure, let's finish the discussion there
17:56:05 <jlaska> #info additional work needed to determine scope of changes needed to resolve System;Settings; menu items
17:56:21 <jlaska> halfline: awesome thanks ... good discussion, just hoping to not have another 4+ hour meeting :)
17:56:29 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=674799
17:56:30 <buggbot> Bug 674799: unspecified, unspecified, ---, ccecchi, ON_QA, Isn't dragged in for upgrades
17:56:56 <jlaska> oops, I skipped on, I'll come to it after this
17:57:15 <jlaska> no updates since last week, other than a new package
17:57:24 <jlaska> #link https://admin.fedoraproject.org/updates/gnome-desktop3-3.0.0-2.fc15
17:58:02 <jlaska> So, perhaps we just need to confirm that F14 -> F15 upgrades are pulling in the expected theme package
17:58:20 * jlaska agrees with the final release artwork criteria adamw commented on for this bug
17:59:01 <adamw> on the face of it it does the job, the dep is there
17:59:12 <adamw> and it has appropriate karma to be pushed stable now
17:59:22 <jlaska> well, I guess that makes life easier :)
17:59:48 <jlaska> shall we go with this impeding the final release artwork criteria?
17:59:58 <jlaska> AcceptedBlocker, and move on
18:00:03 <jlaska> ack/nak/patch?
18:00:20 <adamw> ack
18:00:26 <tflink> how does it impact the final artwork criteria?
18:00:47 <jlaska> darnit, I was hoping you wouldn't ask! :)
18:00:52 <adamw> upgrades don't get the right background
18:01:01 <jlaska> my interpretation was the wrong striped background was installed by default?
18:01:02 <adamw> and upgrades are meant to meet all criteria
18:01:08 <tflink> but this is the upstream gnome background, right?
18:01:16 <adamw> hum, lemme see
18:01:19 <tflink> not the F15 stuff?
18:01:30 <dgilmore> ack
18:01:49 <jlaska> tflink: oh, yeah good question
18:01:51 <tflink> unless I'm reading things wrong
18:02:11 <tflink> I'm -1 blocker 0 NTH
18:02:19 <adamw> the background, yes...but the package also contains the default GTK+ and icon themes, if i'm reading it correctly
18:02:26 <adamw> though that's not so clear cut for the criteria
18:02:38 <jlaska> well, the background is needed for non_GNOME, right?
18:02:45 <jlaska> wait, nm sorry :(
18:03:06 <adamw> i can go with -1 blocker +1 nth, but let's not spend too long since there's a fix already...
18:03:19 <tflink> yeah, either way
18:03:25 <tflink> +1000 to getting done :)
18:03:27 <jlaska> okay, NTH has the votes
18:03:27 <dgilmore> adamw: as long as it doesnt negatively effect other spins its ok
18:03:59 <dgilmore> if it pulls in gtk to KDE wont be good
18:04:08 <jlaska> #agreed 674799 - AcceptedNTH - appears to only provide upstream GNOME backgrounds, which are not the default in F15
18:04:17 <jlaska> dgilmore: yeah, we'll definitely have issues if that happens
18:04:36 <jlaska> #info Fix available for testing
18:04:39 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=698184
18:04:40 <buggbot> Bug 698184: high, unspecified, ---, rstrode, NEW, Enabling session saving with Gnome shell makes GUI login unusable
18:05:29 <jlaska> adamw good find
18:05:48 <adamw> wasn't me, i just saw two other people report it, heh
18:06:00 <jlaska> hmm, this certainly isn't a default setting
18:06:07 <adamw> right, i proposed it for discussion
18:06:08 <jlaska> but seems somewhat common
18:06:15 * jlaska on fence
18:06:22 <adamw> it's not clear-cut, but it's a nasty effect if you try and enable the option - and like i said, i'm worried by what happens if you upgrade with it on
18:06:36 <tflink> yeah, I'm not as worried about enabling it as upgrade
18:06:37 <dgilmore> i think it will create a bigger negative sentiment than gnome3 is going to get anyway
18:06:38 <adamw> note this only affects shell, not fallback, so it's a bit tricky to test as you'll have to use a bare metal install, not a vm
18:06:43 <jlaska> +NTH for the upgrade issue aspect
18:06:55 <dgilmore> i think we need to make sure it works, not sure it actually effects any criteria
18:07:16 <adamw> it doesn't really; for me it'd be getting in under the "high severity issue in critical path package' dodge
18:07:22 <jlaska> do we want to refrain from voting until we get upgrade feedback?
18:07:35 <adamw> i'd vote +1 nth anyway, i think
18:07:40 <tflink> same here
18:07:41 <jlaska> that's 2 NTH
18:07:43 <jlaska> 3
18:07:45 <dgilmore> ill vote +1 nth
18:07:47 <jlaska> okay
18:07:51 * jlaska works #agreed ...
18:07:56 <dgilmore> id likely vote +1 blocker also
18:07:57 <tflink> +1 nth, +1 blocker if it is a big upgrade problem
18:08:09 <tflink> but needinfo on that
18:08:28 * rbergeron +1 NTH
18:08:30 <jlaska> #agreed 698184 - AcceptedNTH - further testing of F14->F15 upgrades may elevate to AcceptedBlocker
18:08:40 <adamw> does someone want to volunteer to test it?
18:09:05 <tflink> I can, probably won't be today, though
18:09:09 <dgilmore> adamw: sorry id get lost if i tired. im not comfortable using gnome
18:09:10 <jlaska> #action jlaska - test F14->F15 upgrade 698184
18:09:45 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=695730
18:09:50 <buggbot> Bug 695730: urgent, unspecified, ---, otte, MODIFIED, PackageKit doesn't find codecs
18:10:40 <adamw> stickster says: "since it's a regression in a notable feature
18:10:40 <adamw> from previous releases."
18:10:53 <adamw> that's not really something we recognize as a blocker qualifier, though.
18:10:57 <jlaska> right
18:11:07 <adamw> i'm -1 on this, it's just a feature regression, can be fixed by an update, nothing much to do with releas.e
18:11:16 <tflink> same here
18:11:16 <jlaska> and a fix is already in it seems
18:11:32 <jlaska> this also requires coordination with rpmfusion for rebuilding affected plugins (but that's outside this meting)
18:11:42 <dgilmore> seems like we really cant fix this
18:11:48 <dgilmore> rpmfusion needs to
18:12:06 <dgilmore> im -1 to blocker
18:12:14 <jlaska> proposed #agreed 695730 - RejectedNTH and RejectedBlocker, updated fedora packages available, rpmfusion will need to rebuild -plugins
18:12:16 <adamw> well, the bits that are fedora side have been fixed by the update
18:12:22 <adamw> ack
18:12:36 <tflink> ack
18:12:36 <dgilmore> adamw: yeah still wont fix the reported bug
18:12:55 <dgilmore> the fix for the reported bug is out of our hands
18:13:19 * tflink wonders if anyone is pestering the correct people @ rpmfusion
18:13:22 <jlaska> #agreed 695730 - RejectedNTH RejectedBlocker - updated fedora packages available for testing, rpmfusion will need to rebuild -plugins
18:13:42 <jlaska> #help anyone able to reach out to rpmfusion for the needed gstreamer plugin rebuilds?
18:13:46 <adamw> tflink: i can do that.
18:14:04 <jlaska> #action adamw - notify rpmfusion about 695730 and gstreamer plugin rebuilds
18:14:06 <tflink> adamw: k, I assume that you have a better idea of who to pester than I would :)
18:14:07 <jlaska> adamw: thx
18:14:15 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696510
18:14:16 <buggbot> Bug 696510: unspecified, unspecified, ---, tfujiwar, ON_QA, need a dependency in ibus-gtk3 for imsettings-gnome
18:14:36 * jlaska reading response from last week
18:15:02 <adamw> done
18:15:22 <jlaska> as in, it's in ON_QA already?
18:15:30 <adamw> no, the Fusion thing
18:15:38 <jlaska> adamw: roger
18:15:48 <adamw> so yeah, we have an update, and an improved impact assessment
18:15:51 <adamw> which does look fairly icky
18:16:03 <tflink> yeah, I'm definitely +1 NTH on this one
18:16:07 * jlaska not parsing the impact at all
18:16:18 <tflink> my worry is that i18n would fail horribly on live media
18:16:29 <dgilmore> jlaska: this may have a negative impact for non gnome desktops
18:16:42 <tflink> dgilmore: the fix? or the bug?
18:16:49 <dgilmore> tflink: the fix
18:17:22 <dgilmore> the correct fix is probably add it to comps
18:17:35 <dgilmore> make sure that its pulled in on distro upgrades that way
18:18:18 <tflink> yeah, that makes sense
18:18:18 <dgilmore> i guess it will only effect gtk3 apps running on other dekstops
18:18:19 <adamw> dgilmore: that's a point, maybe raise it in the report
18:18:38 <jlaska> someone who understands this want to propose an #agreed ?
18:18:45 <adamw> jlaska: summary of the impact: on upgrade from f14 to f15 users who use input modules may well end up with a wrong one selected (not the one we want to give them)
18:18:48 <jlaska> its' something with upgrades and a .cache
18:19:09 <jlaska> okay, that much I got
18:19:39 <adamw> jlaska: basically we want to tell gtk+ what input methods we want it to use, and imsettings-gnome does that; but if it doesn't get installed on updates, gtk+ will try and figure out on its own what input method to use, and what it comes up with may well not be what we wanted.
18:19:51 <tflink> yeah, a file that gnome3 needs for input modules is generated by a package that is new to F15, so on upgrade, if that package isn't installed, the file doesn't get generated and "unpredictable behavior" may ensue
18:19:59 <jlaska> adamw: ah, that makes sense ... ty
18:20:33 <jlaska> now, would this be covered by any criteria if it was a default install case?
18:20:36 * jlaska looking
18:20:45 <tflink> its only upgrade
18:20:54 <adamw> it's a case for our newish wiggle clause
18:20:57 <jlaska> right, just trying to find any applicable criteria
18:20:59 <tflink> now that I think about it, live images or default install can't hit this
18:21:02 <adamw> i think it's probably not quite a blocker, but nth
18:21:32 <jlaska> 0 blocker, 1 NTH  ... anyone else?
18:21:38 <tflink> +1 nth
18:22:13 <adamw> ack
18:22:34 <jlaska> #agreed 696510 - AcceptedNTH RejectedBlocker - A fix is available for testing, a proper fix might be to adjust comps instead
18:22:47 <dgilmore> -1 nth, i think it has the potential for unneeded package bloat, upgrade methods shoule use comps to get it
18:22:59 <adamw> dgilmore: we're voting on the bug not the fix
18:23:18 <jlaska> dgilmore: we aren't voting on the solution, just that it needs to be resolved ... we can still work the comps fix in for this issue
18:23:29 <jlaska> err, what adamw said
18:23:42 <dgilmore> ok
18:23:46 * dgilmore shuts up
18:23:57 <adamw> please do add a comment about your concerns on the current fix
18:23:58 * jlaska not sure how comps works into the picture for upgrades, I'll listen in on this bug for updates
18:24:05 <jlaska> dgilmore: yeah ^^^
18:24:18 <dgilmore> adamw: i did already
18:24:40 <adamw> cool
18:24:43 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=693809
18:24:44 <buggbot> Bug 693809: unspecified, unspecified, ---, tagoh, ASSIGNED, Error message about missing input methods should be removed
18:25:05 <jlaska> this seems to be the sister of the previous issue
18:25:06 <adamw> so this was re-proposed after we rejected it last week, with an updated rationale
18:25:12 <adamw> no, it's different
18:25:27 <jlaska> oh right, I recall now
18:26:10 <adamw> i'll try and get chris to step in
18:26:21 <adamw> i can see his point with the revised 'complaint', for sure
18:26:23 <jlaska> so ... potentially hitting "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" after an upgrade
18:26:38 <jlaska> if you consider the imsettings error an AVC or crash notification
18:26:43 <jlaska> (which it isn't really, but similar)
18:26:58 * jlaska waits for caillon
18:27:49 <adamw> right, it doesn't quite technically hit that criterion but it's kinda in the spirit
18:28:07 <jlaska> Hey caillon
18:28:10 <caillon> yo
18:28:11 <adamw> hey
18:28:14 <jlaska> we're reviewing your updated comments on #topic bug
18:28:18 <adamw> so it'll cost you a beer apiece to get this made a blocker...;)
18:28:30 <jlaska> heh
18:28:49 <caillon> beer i can do
18:29:29 <jlaska> so, I'd vote blocker given that this is an error message, and aligns with the spirit of our "No AVC or abrt crashes on login" criteria
18:29:37 <jlaska> unless it's more complicated than that
18:29:53 <adamw> yeah, i can go with that
18:30:05 <jlaska> I'm assuming caillon is +1 also
18:30:07 <jlaska> anyone else?
18:30:15 <caillon> so, it's an error not a warning, as evidenced by the stop sign, not a yield sign.  and in comment 3, akira mentions that its because something is not being pulled in
18:30:21 <caillon> yeah, i'm totally +1 here
18:30:25 <dgilmore> so i still wonder how gnome specific this all is,
18:30:34 <adamw> dgilmore: it's totally gnome specific
18:30:40 <dgilmore> and how it effects other desktops, now and down the road
18:30:51 <adamw> i don't think the message will show up in anything else
18:31:11 <adamw> we could test, but i'm pretty sure that's right
18:31:24 <dgilmore> adamw: yeah, i guess im picturing a xfce ported to gtk3 and wondering how it should work then
18:31:37 <adamw> i dunno, but seems kind of out of our scope
18:31:43 * nirik notes they are not even targeting gtk3 for xfce 4.10. ;)
18:31:44 <dgilmore> or even running some gtk3  only app
18:31:57 <caillon> well...
18:32:05 <adamw> this error is part of the gnome3 input 'applet', i think.
18:32:08 <caillon> there's an imsettings-qt, imsettings-lxde, imsettings-xfce
18:32:11 <adamw> which is plumbed into the shell, right caillon?
18:32:19 <caillon> i'm not sure if those existed in F14
18:32:27 <caillon> if not, they too will be missing on an upgrade
18:32:36 <caillon> and AFAIK, the error message will be the same
18:32:39 <adamw> oh k
18:32:45 <adamw> i thought it was specific to the shell applet
18:32:52 <tflink> does this end up in the same boat as the last bug then? comps issue?
18:32:54 <adamw> well, we should ask akira to check those cases too i guess
18:33:09 <adamw> tflink: kinda, though there's the question of whether it makes sense to have the error at all
18:33:09 <caillon> looks like lxde and xfce existed
18:33:17 <caillon> so this should probably break kde too
18:33:27 <caillon> but i haven't tested that
18:33:56 <dgilmore> i guess i dont really know how all the im stuff works well enough
18:34:07 <jlaska> any additional votes, and changes?
18:34:26 <adamw> i don't think that changes our vote any
18:34:31 <adamw> just other scenarios to consider in fixing it
18:34:35 <jlaska> right
18:34:46 <jlaska> alright ... I've got +2 Blocker, +0 NTH
18:34:48 <caillon> adamw, yeah, i'm super serous that we should kill that message outright, but i also think that we need to find some way to bring in the needed packages, because without it, it will regress input methods from F14-F15
18:35:15 <adamw> okay
18:35:21 <adamw> i think for now let's just move on and we can add notes to the bug
18:35:37 <adamw> caillon: dgilmore: please do note up the concerns we just discussed in the bug
18:35:45 <caillon> k
18:35:57 <caillon> will wait for your updates so i don't midair
18:36:04 <jlaska> okay, so, we are agreeing to tally votes in the bug and continue walking the list?
18:36:24 <adamw> no, i thought we had a vote in?
18:36:36 <adamw> we had +1 from you, me and caillon
18:37:03 <jlaska> worksforme :)
18:37:23 <jlaska> #agreed 693809 - AcceptedBlocker - May also impact other desktops, continue discussion in bug
18:37:37 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=693442
18:37:38 <buggbot> Bug 693442: medium, unspecified, ---, kernel-maint, NEW, NETDEV WATCHDOG: em1 (sky2): transmit queue 0 timed out
18:38:57 * jlaska reached out to gospo on this ... I think that's his realm
18:39:33 <adamw> i don't think the impact's serious enough to be a blocker
18:39:39 <adamw> since the workaround seems to be 'wait 90 seconds'
18:39:46 <dgilmore> -1 blocker
18:39:50 <tflink> and its only for local networks
18:39:52 <jlaska> I'm -1 on this until we get more ... it's a single user on a single adapter
18:40:06 <dgilmore> I have a box that without adding kernel options to it wont work for a few releases now
18:40:06 <adamw> tflink: yup, that too
18:40:09 <tflink> -1 blocker
18:40:21 <adamw> -1 blocker, -1 nth
18:40:42 <jlaska> we can certainily continue working this issue, but not as a blocker or NTH
18:40:50 <tflink> yeah, -1 nth, too
18:40:56 <dgilmore> ftr  its kinda like https://bugzilla.redhat.com/show_bug.cgi?id=538920 thats long standing witha workaround
18:40:57 <buggbot> Bug 538920: urgent, low, ---, kmcmartin, ASSIGNED, r8169 netdev timeout when aspm is enabled
18:41:04 <dgilmore> im -1 nth also
18:41:24 <jlaska> #agreed 693442 - RejectedBlocker + RejectedNTH - impact does not affect criteria at this time
18:41:40 <jlaska> 4 more proposed blockers ...
18:41:41 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697008
18:41:43 <buggbot> Bug 697008: unspecified, unspecified, ---, tcallawa, NEW, Include the latest ntfs-3g package in the final F-15 compose
18:42:08 <jlaska> this should be RejectedNTH and RejectedBlocker from last week?
18:42:28 * jlaska updates bz
18:42:28 <adamw> oh yeah, looks like i forgot to add the flags
18:42:29 <adamw> oops
18:42:48 <dgilmore> bad adamw
18:42:50 <jlaska> adamw: it's about time!
18:42:51 <jlaska> :)
18:42:59 <clumens> jlaska: https://admin.fedoraproject.org/updates/anaconda-15.28-1.fc15
18:43:04 <jlaska> #info Previously reviewed and rejected
18:43:09 <jlaska> clumens: rockin, thanks
18:43:18 <jlaska> 3 systemd bugs ...
18:43:24 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678555
18:43:26 <buggbot> Bug 678555: unspecified, unspecified, ---, lpoetter, ON_QA, systemd should not purge application created cgroups, even if they contain no processes
18:43:37 <jlaska> already in ON_QA ...
18:44:10 * dgilmore is +1 to blocker
18:44:14 <adamw> i think this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=666130 which has been longstanding
18:44:15 <buggbot> Bug 666130: medium, low, ---, veillard, NEW, Cgroups cause libvirt to be unable to start virtual machines
18:44:16 <jlaska> ah, so that's why I hit that
18:44:19 <dgilmore> and will test and provide feedback
18:44:46 <dgilmore> adamw: i found 3 bugs for it
18:44:52 <adamw> so, working against blockeriness is the simple workaround (restart libvirtd)
18:44:55 <adamw> but i can go with +1 blocker
18:45:09 <jlaska> loosely affects "The release must boot successfully as a virtual guest in a situation where the virtual host is running the same release (using Fedora's current preferred virtualization technology) "
18:45:13 <jlaska> ?
18:45:16 <adamw> yeah.
18:45:27 <dgilmore> jlaska: thats what i used in proposing it
18:45:30 <adamw> i'd probably be more nth here, i suspect we wouldn't slip the release if this was the last bug
18:45:36 <adamw> but i wouldn't hate blocker
18:45:42 <jlaska> same boat for me
18:45:55 <jlaska> and note of course ... it's already ON_QA and a fix pending
18:46:01 <adamw> right, so it's kinda academic
18:46:02 <dgilmore> im +1 but only because i hit it all the time
18:46:20 <adamw> dgilmore: set up a two-key alias for 'systemd restart libvirtd.service' :P
18:46:26 <adamw> i recommend fs for 'fucking systemd'
18:46:49 <jlaska> would someone please think about the children
18:46:55 <dgilmore> adamw: thats not a nice workaround though :)
18:47:01 <tflink> adamw: tell us how you really feel
18:47:07 <jlaska> anyone else on this on?
18:47:12 <jlaska> 1 blocker, 2 NTH
18:47:28 <adamw> jlaska: if there were any children in a blocker review meeting we'd be up for a UN tribunal anyway
18:47:41 * jlaska just going to NTH if no more votes since it's already pending
18:47:47 <tflink> I think that I'm of the same opinion as jlaska and adamw. bad, but fixable and I'm not sure it would be worth holding up a release for
18:47:48 <jlaska> adamw: so true
18:48:20 <jlaska> #agreed 678555 - AcceptedNTH - ON_QA with a pending fix in bodhi already, testing needed
18:48:38 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=692230
18:48:39 <buggbot> Bug 692230: unspecified, unspecified, ---, lpoetter, NEW, Non-root iSCSI volumes are not mounted on boot
18:48:48 <jlaska> argh, I missed this from my #action list last week
18:49:12 <jlaska> this one is pretty easy to test, I'll re-run it and provide a summary
18:49:29 <jlaska> there's something wrong with the iscsi network drive mounting with systemd
18:49:40 <jlaska> it doesn't have the right order or dependencies with the network
18:49:49 * jlaska not 100% ... needs to better understand systemd
18:50:00 <jlaska> I'll follow-up in the bug and we can discuss out of meeting (and next week)
18:50:19 <jlaska> #action jlaska - 692230 - retest and update impact statement
18:50:36 <jlaska> not sure there's anything else to say on this one
18:50:43 <jlaska> if not ... I'll move on
18:51:01 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696320
18:51:03 <buggbot> Bug 696320: unspecified, unspecified, ---, lpoetter, NEW, After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console
18:51:31 <jlaska> so one of the criteria in question here is "The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices "
18:51:49 <jlaska> this bug manifests when doing a headless (virt) iSCSI installation
18:52:08 <jlaska> after install ... firstboot-text and gettys are running at the same time
18:52:12 <jlaska> making it impossible to login
18:52:24 <adamw> is this particular to iSCSI?
18:52:29 <adamw> seems odd that it'd be related to the storage methodf
18:52:32 <jlaska> I have no idea why, but it seems to be
18:52:41 <adamw> huh, weird.
18:52:44 <jlaska> I've hit it 3 times now doing that install
18:52:50 <jlaska> could be something else, I just haven't figured it out yet
18:52:52 <dgilmore> sounds like a systemd bug
18:53:46 <adamw> also relevant: "When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so "
18:53:47 <jlaska> so our criteria doesn't state the iSCSI installstion must complete, and work on boot-up on a serial console
18:54:51 <jlaska> but when combined with the criteria adamw noted ... I think we have a valid issue
18:54:55 <jlaska> votes ?
18:55:18 <dgilmore> +1 blocker
18:55:19 <adamw> +1 per those criteria
18:55:29 <tflink> +1 blocker
18:55:36 <jlaska> that'll do it
18:56:08 <jlaska> #agreed 696320 - AcceptedBlocker - waiting on guidance for further systemd debugging
18:56:21 <jlaska> congrats folks ... that's it for the proposed blockers
18:56:34 <jlaska> there are 16 proposed NTHs
18:56:37 <dgilmore> jlaska: thanks
18:56:38 <jlaska> ready to walk that list?
18:56:51 <dgilmore> sure
18:57:10 <jlaska> let's move quick, like the wind!
18:57:13 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=694765
18:57:15 <buggbot> Bug 694765: unspecified, unspecified, ---, dcbw, ON_QA, Can't connect to WPA2 Enterprise networks
18:57:47 <adamw> clear +1 for me
18:57:56 <adamw> i'm basically +1 to anything NM could do in F14 getting fixed
18:58:05 <dgilmore> +! nth
18:58:06 <tflink> didn't we do this last week?
18:58:07 <dgilmore> +1
18:58:26 <jlaska> tflink: it sounds familiar
18:58:28 <tflink> we == brunowolff and I
18:58:45 <jlaska> #agreed 694765 - AcceptedNTH
18:58:56 <tflink> either way, done now
18:58:58 <jlaska> #info This should be moved back to ASSIGNED based on reporter feedback
18:59:09 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=693302
18:59:10 <buggbot> Bug 693302: medium, medium, ---, rvykydal, NEW, static network kickstart configuration having --device specified with MAC tracebacks (KeyError: '00:0c:29:09:85:fa')
19:00:00 <jlaska> mm, I think this might be a blocker
19:00:07 <adamw> definitely +1 nth
19:00:12 <jlaska> per the new Beta criteria "Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention) "
19:00:15 <jlaska> but definitely NTH
19:00:58 <jlaska> anyone else?
19:01:00 <tflink> this one looks familiar, too
19:01:45 <jlaska> okay, 2 votes for NTH is enough
19:01:53 <tflink> hmm, looks like the proposed NTH were not updated from last week
19:02:01 <tflink> whoops
19:02:04 <adamw> jlaska: that one's more intended to catch cases where you can't do an unintended install at all, not specific configurations that happen to be unattended failing
19:02:13 <jlaska> #agreed 693302 - AcceptedNTH - patch out for review on anaconda-devel@
19:02:15 <adamw> tflink: i think we lost the will to live and didn't do them
19:02:23 <jlaska> adamw: right on, good reminder
19:02:34 <tflink> yep, and I only went back and checked the blockers after the meeting
19:02:57 <jlaska> shall we proceed through the remainder?
19:03:05 * jsmith is back :-)
19:03:09 <tflink> do we want to go through all these again or should I mention the ones that were decided last week?
19:03:21 <jlaska> tflink: mention the ones that sound familiar
19:03:30 <jlaska> and we'll re-use the previous votes
19:03:45 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=662800
19:03:47 <buggbot> Bug 662800: medium, low, ---, andreas.bierfert, ASSIGNED, geolocation plugin is linked against both gtk2 and gtk3
19:03:58 <tflink> 662800, 683265, 662791, 662801
19:04:12 <jlaska> tflink: okay, were these all AcceptedNTH already?
19:04:17 <jlaska> s/these/those/
19:04:28 <tflink> rejected other than 683265
19:04:52 <jlaska> #agreed 662800 - RejectedNTH - discussed at previous blocker review
19:05:10 <tflink> other rejected: 653709, 662794, 662788
19:05:29 <tflink> accepted: 681582, 694928
19:05:38 <tflink> I can go back and update these
19:05:43 <jlaska> okay
19:05:51 <jlaska> I'm going to skip ones you've mentioned
19:06:33 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697689
19:06:34 <buggbot> Bug 697689: high, urgent, ---, simon, NEW, hulahop has issues with firefox 4 / xulrunner 2
19:06:52 <jlaska> this is sugar specific
19:07:02 <adamw> this is a criteria breakage in a non-blocker desktop, so auto-NTH
19:07:12 <jlaska> bugs which constitute infringements of the desktop-related Fedora_Release_Criteria as applied to non-default desktops
19:07:15 * dgilmore is +1 nth
19:07:15 <jlaska> yup
19:07:25 <tflink> we probably want to go back and do 694928. we misunderstood last week
19:07:48 <jlaska> #agreed 697689 - AcceptedNTH - infringes desktop criteria for a non-default desktop
19:07:50 <tflink> whoops, wrong number
19:08:02 <tflink> 683265
19:08:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683265
19:08:20 <buggbot> Bug 683265: unspecified, unspecified, ---, harald, ASSIGNED, u3 device on Sandisk Cruzer 8G USB Drive hangs Fedora 15 Alpha boot
19:08:58 <jlaska> how common are  u3 smart drives ?
19:09:13 <tflink> it looks like a decent number of sandisk drives are u3
19:09:18 <adamw> moderately, i've seen various issues reported with them by multiple people
19:09:20 <tflink> I tried looking for information on that last week
19:09:36 <tflink> they are being phased out for a new generation but are still available
19:09:44 <adamw> +1 nth for this from me
19:09:50 <tflink> not sure if this affects the next generation u3
19:10:09 <dgilmore> what is u3?
19:10:09 <jlaska> sure, fits NTH then on the basis that it impacts using a live image for  "bugs which result in a system being unable to reach a graphical environment "
19:10:36 <tflink> dgilmore: its a type of usb disk that impersonates a CDROM and a HD to provide a movable application launcher on windows
19:10:50 <dgilmore> tflink: ewww
19:10:53 <tflink> dgilmore: http://en.wikipedia.org/wiki/U3
19:11:00 <jlaska> #agreed 683265 - AcceptedNTH
19:11:13 <tflink> but it's baked into the HW, so even if you're not using that functionality you still hit this bug
19:11:28 <adamw> although thinking about it...is the fix for this likely to be in anything that's part of the release?
19:11:35 <adamw> or would it be in livecd-iso-to-disk ?
19:11:46 <tflink> sounds like a dracut issue
19:11:49 <adamw> k
19:12:00 <adamw> keep the vote then :)
19:12:04 <tflink> where the problem has to do with recognizing devices properly on boot instead of creating the liveusb
19:12:34 <jlaska> We discussed this next one  but it's still on the list
19:12:36 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=688302
19:12:38 <buggbot> Bug 688302: medium, unspecified, ---, itamar, NEW, 'Credentials have expired' notification shows when you have no credentials
19:12:52 <jlaska> adamw filed this upstream already as https://bugzilla.gnome.org/show_bug.cgi?id=648242
19:12:52 <buggbot> Bug 648242: normal, Normal, ---, caillon, UNCONFIRMED, Default behaviour not as described in man page?
19:13:40 <adamw> caillon: oy, get to work =)
19:14:27 <jlaska> do we still need feedback from mclasen or owen in order to accept this as NTH?
19:14:43 <adamw> i don't think so, the impact's pretty clear
19:15:00 <jlaska> yup
19:15:14 <dgilmore> +1 nth
19:15:19 <tflink> +1 nth
19:15:28 <jlaska> #agreed 688302 - AcceptedNTH
19:15:30 <adamw> +1 obviously
19:16:23 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697649
19:16:24 <buggbot> Bug 697649: high, urgent, ---, simon, NEW, Sugar Wireless Networking broken by NetworkManager 0.9 API
19:16:36 <jlaska> automatic NTH due to non-default desktop
19:17:04 <adamw> yeah
19:17:20 <jlaska> Wasn't this included in the mix with the big NM-0.9 review
19:17:25 <jlaska> anyway, not important here
19:17:35 <jlaska> any other votes?
19:17:52 <jlaska> btw, only 1 more bug after this :)
19:17:56 <dgilmore> +!
19:17:57 <tflink> +1 NTH
19:18:00 <dgilmore> +1
19:18:09 <jlaska> #agreed 697649 - AcceptedNTH - desktop issue affecting non-default desktop
19:18:20 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=697188
19:18:22 <buggbot> Bug 697188: unspecified, unspecified, ---, lpoetter, NEW, systemadm lacks menu entry
19:19:03 <jlaska> hrmm, -1 NTH from me
19:19:20 <dgilmore> +1 for nth, its violating the packaging guidelines
19:19:23 <jlaska> we don't state that the packaging guidelines must be honored for release
19:19:39 <jlaska> and it can easily be fixed post-release
19:19:41 <adamw> well i'm +1 nth on the basis that if we decided to take this we'd want to make it nth since it's for live composes
19:19:48 <adamw> jlaska: see live compose implications
19:19:52 <jlaska> oh
19:20:08 <jlaska> but who edits runlevels "services" on a live setup :)
19:20:12 <adamw> true
19:20:14 <jlaska> I keeed, I keeed
19:20:21 <adamw> but the point is, we want it there for *post* install
19:20:28 <dgilmore> jlaska: post install of livecd yes
19:20:31 <jlaska> ah, I see
19:20:34 <adamw> though yeah, could add the app to the live image anyway
19:20:41 <adamw> and hope a post-release update added it to the menus
19:20:42 <adamw> ...meh i'm 0
19:20:44 <dgilmore> i think having the new tool should be the way
19:20:48 <adamw> heh
19:21:15 <jlaska> okay, we have a net zero on this
19:21:28 <jlaska> +1 (dgilmore)  0 (adamw)  -1 (jlaska)
19:21:40 <jlaska> I can easily move to meh :)
19:21:43 <tflink> what is systemadm?
19:21:52 <adamw> it's a GUI tool for maintaining systemd
19:21:58 <jlaska> system-config-services replacement?
19:21:59 <dgilmore> tflink: gui tool for managing systemd services
19:22:00 <adamw> much like system-config-services for the Old Busted World
19:22:10 <adamw> but lennart thinks it's not good enough to show off yet
19:22:39 <jlaska> I don't want to make him show off the tool, if he doesn't think it's ready
19:22:47 <adamw> well
19:23:02 <adamw> nth doesn't imply we require a fix
19:23:09 <jlaska> true
19:23:12 <adamw> it means *if developer chooses to fix* they can choose to push it through the freeze
19:23:22 <adamw> for me even if we take this, it's perfectly fine for lennart to say 'nope don't wanna'
19:23:22 <jlaska> yes!
19:23:28 <jlaska> okay ... I'm moving up to a +0
19:23:43 <tflink> yeah, I'm pretty much at +0, too
19:23:55 <jlaska> okay, that's 3*0 + 1 == AcceptedNTH
19:24:24 <adamw> sure
19:24:30 <dgilmore> ok
19:24:35 <jlaska> #agreed 697188 - AcceptedNTH - Will accept a tested fix if provided before release
19:24:39 <adamw> but secretary, please make it clear to lennart he can still choose not to do the change
19:25:05 <tflink> #info make it clear to lennart that NTH means that he can still choose not to do the change
19:25:09 <jlaska> ... thx
19:25:17 <tflink> #undo
19:25:26 <jlaska> #topic Open Discussion
19:25:31 <jlaska> #chair tflink
19:25:31 <zodbot> Current chairs: jlaska tflink
19:25:33 <tflink> #info in the bug update, please make it clear to lennart that NTH means that he can still choose not to do the change
19:25:50 <tflink> ah, wasn't sure if you needed to be chair to do infos
19:26:01 <jlaska> me neither
19:26:14 <jlaska> you look like you needed a chair! heyooo!
19:26:33 * tflink hopes that the power doesn't go to his head for the next 5 minutes
19:26:54 <jlaska> haha
19:27:07 <jlaska> okay, if no additional business, let's end this meeting
19:27:12 * jlaska sets fuse for 1 minute
19:27:13 <adamw> yay
19:27:17 <tflink> +1
19:27:19 <jlaska> heh
19:27:28 * jlaska makes fuse shorter
19:27:48 <tflink> rbergeron: I need to leave but assuming that I am able to read when I get back, I'll do all the NTH from this week and last week
19:28:08 <jlaska> tflink: thanks for volunteering for that
19:28:16 <tflink> np
19:28:21 <jlaska> I'll send minutes to the list, take care all!
19:28:25 <jlaska> #endmeeting