17:00:48 <tflink> #startmeeting F17-beta-blocker-review-1
17:00:48 <zodbot> Meeting started Fri Mar  2 17:00:48 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:52 <tflink> #meetingname F17-beta-blocker-review-1
17:00:52 <zodbot> The meeting name has been set to 'f17-beta-blocker-review-1'
17:01:06 <tflink> who's ready for some blocker bug review party time?
17:01:13 * pschindl is present
17:01:19 * nirik is lurking
17:01:19 <tflink> #topic roll call
17:01:26 <adamw> morning
17:01:46 <tflink> pschindl, adamw: welcome to the party!
17:02:00 <pschindl> hi all
17:02:08 <adamw> is this partypoker.net?
17:02:17 * brunowolff is here
17:02:31 <tflink> adamw: if by poker you mean blocker review, sure :)
17:02:48 <pschindl> poker sounds better :)
17:03:15 <brunowolff> jpoker is ftbfs. I looked at it, but it didn't look simple to fix.
17:03:33 <tflink> that's an interesting thought, I wonder if we'd get more people if we started calling these meetings poker parties
17:03:33 <adamw> we use pokerth in the secret fedora poker sig.
17:03:55 <adamw> tflink: someone i think partyblockerreview.net would not be as successful a business
17:03:58 <adamw> s/someone/somehow/
17:04:23 <tflink> adamw: I don't know, blockerreviewparty.net sounds pretty tempting
17:06:03 <tflink> ok, I think we have enough people. let's get started
17:06:12 <tflink> any volunteers for secretary?
17:06:23 <tflink> #chair adamw
17:06:23 <zodbot> Current chairs: adamw tflink
17:06:41 <tflink> #topic Introduction
17:06:56 <tflink> in case this wasn't clear ...
17:07:02 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:07:10 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:07:11 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:07:11 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:07:27 <tflink> Up for review today are:
17:07:29 <tflink> #info 8 Proposed Blockers
17:07:29 <tflink> #info 1 Proposed NTH
17:07:29 <tflink> #info 1 Accepted Blocker
17:07:47 <tflink> unless there are objections, I'm going to start with the proposed blockers
17:08:34 <tflink> #topic (753421) FSError: failed to get block size for ext4 filesystem on /dev/md127
17:08:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=753421
17:08:38 <buggbot> Bug 753421: unspecified, unspecified, ---, dlehman, ASSIGNED, FSError: failed to get block size for ext4 filesystem on /dev/md127
17:08:39 <tflink> #info Proposed Blocker, ASSIGNED
17:09:18 <tflink> looks like a pretty clear blocker to me according to c#4
17:09:48 <tflink> proposed #agreed - 753421 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria.
17:10:27 <pschindl> ack
17:11:04 <adamw> sorry, reading
17:11:27 <adamw> ack
17:11:33 <adamw> sucks that it's in f16, too. le sigh
17:11:41 <pschindl> there are no constraint on hardware in the criterion
17:12:21 <tflink> sucks that we missed this for f16
17:12:37 <tflink> #agreed - 753421 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria.
17:12:45 <tflink> #topic (787893) Anaconda needs to handle /usr move preparation on upgrade for F17
17:12:49 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=787893
17:12:50 <buggbot> Bug 787893: urgent, unspecified, ---, bcl, MODIFIED, Anaconda needs to handle /usr move preparation on upgrade for F17
17:12:51 <tflink> #info Proposed Blocker, MODIFIED
17:13:04 <adamw> pschindl: it comes under the 'configuration specific issues require judgment call' thing, but i'd say it's pretty obvious that this one's significant enough to take
17:13:29 <adamw> this is an obvious blocker
17:13:39 <pschindl> adamw: it was just note, I'm not against ack :)
17:13:42 <adamw> and worries me that it's kind of been left sitting on a couple of hard to understand comments from harald
17:13:51 <adamw> pschindl: sure, i was just explaining for the record
17:13:53 <tflink> proposed #agreed - 787893 - AcceptedBlocker - #topic (787893) Anaconda needs to handle /usr move preparation on upgrade for F17
17:13:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=787893
17:13:57 <tflink> whoops
17:13:58 <buggbot> Bug 787893: urgent, unspecified, ---, bcl, MODIFIED, Anaconda needs to handle /usr move preparation on upgrade for F17
17:13:59 <tflink> #undo
17:13:59 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2704da50>
17:14:01 <tflink> #undo
17:14:01 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x240fbb10>
17:14:04 <tflink> #info Proposed Blocker, MODIFIED
17:14:06 <tflink> #undo
17:14:06 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2704da50>
17:14:44 <tflink> proposed #agreed - 787893 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:14:57 * adamw trying to get bcl to join
17:14:58 <adamw> ack
17:15:05 <brunowolff> ack
17:15:14 <tflink> crap, I think I screwed up the minutes
17:15:23 <tflink> #info Proposed Blocker, MODIFIED
17:15:27 <tflink> there we go
17:16:32 <adamw> definitely a blocker, plus we should probably ping it to try and get anaconda team to let us know where it's at
17:16:34 <tflink> #agreed - 787893 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:17:11 <tflink> adamw: you OK with taking the action item on that?
17:17:39 <adamw> sure
17:17:41 <tflink> #action adamw to ping anaconda team to make sure that 787893 gets fixed
17:17:46 <adamw> i'm going to do it now, so no need...ah well
17:18:26 <tflink> adamw: you can't stop the bureaucracy!
17:18:35 <tflink> #topic (796155) iface_ip2str returned NULL
17:18:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=796155
17:18:35 <tflink> #info Proposed Blocker, NEW
17:18:36 <buggbot> Bug 796155: unspecified, unspecified, ---, rvykydal, NEW, iface_ip2str returned NULL
17:18:50 <pschindl> criterion: The installer must be able to use all kickstart delivery methods
17:19:51 <tflink> yep, I imagine that this one is waiting for the noloader patch
17:19:52 <adamw> +1 blocker as things stand
17:20:07 <kparal> +1 blocker
17:20:09 <adamw> especially since it can also affect http
17:20:12 <pschindl> +1
17:20:21 <tflink> proposed #agreed - 796155 - AcceptedBlocker - The installer must be able to use all kickstart delivery methods
17:20:24 <kparal> adamw: the last comment says it doesn't
17:20:26 <tflink> ack/nak/patch?
17:20:30 <pschindl> ack
17:20:35 <adamw> oh, okay. but still ack.
17:20:37 <kparal> ack
17:20:46 <tflink> #agreed - 796155 - AcceptedBlocker - The installer must be able to use all kickstart delivery methods
17:20:55 <tflink> #topic (799312) @base and @base-x comp results in a broken system
17:20:55 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=799312
17:20:55 <tflink> #info Proposed Blocker, NEW
17:20:56 <buggbot> Bug 799312: unspecified, unspecified, ---, notting, CLOSED DUPLICATE, @base and @base-x comp results in a broken system
17:21:23 <kparal> ah, my bug
17:21:44 <tflink> is that supposed to work?
17:21:57 <tflink> ie is @base and @base-x enough?
17:22:10 <kparal> well it should at least give me a prompt, shouldn't it?
17:22:18 <kparal> if I use just @base, it gives me console prompt
17:22:24 <kparal> if I add @base-x, it doesn't
17:22:40 <adamw> what do you get?
17:22:44 <tflink> I wonder how firstboot-text got started, I thought that we disabled it
17:22:51 <kparal> adamw: nothing, see screenshot
17:23:00 <kparal> just ctrl+alt+del works
17:23:40 <adamw> huh. firstboot-text seems to have risen from the grave.
17:23:57 * tflink wonders if the firstboot logic was triggered by the presence of X but didn't have everything needed to actually start
17:24:45 <adamw> ah, i see a new firstboot 17 build which kills it again.
17:24:53 <adamw> tflink: no, that's just firstboot-text.service firing. they're entirely separate services.
17:24:54 <kparal> see also the dupe bug, yes
17:25:06 <adamw> the 'weird tool' in question is /usr/bin/setup, fwiw.
17:25:12 <adamw> i'm +1 blocker, anyhow.
17:25:25 <kparal> should it be reopened and rephrased then?
17:25:33 <adamw> oh, lemme see the dupe
17:25:34 <brunowolff> A few packages went backwards in the mass rebuild since they had changes in F16 that hadn't been pushed to rawhide.
17:25:58 <brunowolff> I noted a few on the devel list, but I don't know if anyone did anything about those.
17:26:10 <adamw> the dupe is fine
17:26:16 <adamw> we should re-open the dupe and mark it as a blocker
17:26:18 <tflink> proposed #agreed - 799312 - AcceptedBlocker - 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
17:26:25 <adamw> it's been 'closed nextrelease' but the update isn't actually pushed yet
17:26:26 <adamw> nack
17:26:34 <adamw> 798373 should be the blocker (the bug it's a dupe of)
17:26:34 <tflink> adamw: patch?
17:26:52 <tflink> oh, I generated this list before the dupe went through
17:27:10 <tflink> proposed #agreed - 798373 - AcceptedBlocker - 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
17:27:17 <brunowolff> ack
17:27:19 <adamw> #info 799312 is a dupe of 798373
17:27:22 <adamw> ack
17:27:25 <adamw> am i chair?
17:27:27 <pschindl> ack
17:27:30 <kparal> ack
17:27:30 <tflink> adamw: yep
17:27:34 <adamw> okay, so that should go in.
17:27:41 <tflink> #agreed - 798373 - AcceptedBlocker - 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
17:27:57 <tflink> #topic (795412) No poweroff option in greeter in VM
17:27:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=795412
17:27:57 <tflink> #info Proposed Blocker, NEW
17:28:00 <buggbot> Bug 795412: unspecified, unspecified, ---, rstrode, NEW, No poweroff option in greeter in VM
17:28:14 <kparal> and me again, yay
17:28:17 <kparal> I'm famous
17:28:53 <tflink> for me, the key question is - is poweroff/restart a supported mechanism?
17:29:07 <tflink> from GDM/KDM anyways
17:29:20 <bcl> darn well ought to be.
17:29:22 <pschindl> should be, it's in criteria :)
17:29:40 <kparal> it was a bug in F16. I believe it's again bug in F17. I don't think upstream removed that intentionally
17:29:44 <tflink> bcl: no arguments from me there
17:29:48 <tflink> pschindl: it is?
17:30:12 <pschindl> tflink: All release-blocking desktops' offered mechanisms (if any) for shutting down,
17:30:14 <pschindl> logging out and rebooting must work
17:30:22 <pschindl> I think this one could fit
17:30:35 <tflink> pschindl: yeah but that wasn't my question. is doing that from GDM a supported mechanism?
17:30:37 <kparal> it's mentioned in the bug report. but it is not "offered"
17:31:05 <kparal> I can find the same bug for F16, we discussed the same problem
17:31:15 <brunowolff> I think it meets the criteria as documented, but I seem to remember discussing a similar issue a release or two ago.
17:31:19 <tflink> the bug isn't that you _can't_ shutdown/reboot. just that you can't do so from GDM
17:31:31 <kparal> what if you can't log in?
17:31:40 <brunowolff> I thought we had discussed loosening up the requirement.
17:32:11 <tflink> kparal: VT + 3 finger salute
17:32:48 <kparal> let's ping someone from gdm upstream whether it's intentional
17:32:51 <kparal> I doubt that
17:32:52 <adamw> it doesn't meet the criteria as documented
17:33:02 <adamw> the criteria specifically says "offered mechanisms (if any)"
17:33:11 * kparal searches for F16 bug
17:33:18 <adamw> that means that whatever power management options are actually *shown* in the DM must work
17:33:22 <tflink> yeah, I'm pretty much -1 blocker on this
17:33:26 <adamw> it doesn't require any particular options to be present or not present
17:33:43 <adamw> i think it's a bug and gnome team will want to fix it, but it's not clearly a blocker
17:33:59 <pschindl> adamw: you are right. So it looks like -1 blocker
17:34:04 <adamw> of course, there's the problem that 'do it from GDM' is the gnome team's 'official' answer to the question 'how do i power off / reboot'
17:34:13 <kparal> can we discuss FinalBlocker afterwards?
17:34:32 <adamw> so if it's broken in gdm, there's really no way to shut down / reboot from GNOME except the 'sekrit' alt key workaround
17:34:44 <brunowolff> I was thinking offered meant intended to be offered rather than visible. If visible is meant, than it's not a blocker.
17:35:47 <tflink> kparal: which final criterion were you thinking of?
17:36:05 <kparal> tflink: I don't think I have one
17:36:14 <tflink> I've got -3 explicit and I'm guessing +1 implicit for blocker?
17:36:35 <kparal> if upstream says it's a bug, I would be +1 for Final blocker
17:36:35 <dgilmore> brunowolff: if its not visable its not offered
17:36:47 <kparal> -1 for Beta if you think so
17:36:49 <dgilmore> -1 blocker
17:37:33 * kparal can't find F16 dupe
17:37:46 <adamw> -1 for beta anyhow
17:37:59 <tflink> yep, it can be re-proposed for final
17:38:06 <bcl> kparal: in F16 i complained loudly about the lack of poweroff when logged in, but I don't remember a problem with GDM
17:38:24 <kparal> maybe it was F15
17:38:27 <kparal> but I do
17:38:31 <bcl> I'm -1 beta but +1 final on this
17:38:42 <tflink> proposed #agreed - 795412 - RejectedBlocker - Does not hit any of the beta release criteria since all of the visible methods work
17:38:53 <brunowolff> ack
17:39:34 <pschindl> ack
17:39:38 <dgilmore> ack
17:39:41 <kparal> ack, but I'll re-propose it for Final. ask bug rstrode about it
17:39:44 <kparal> *and
17:39:57 <tflink> #agreed - 795412 - RejectedBlocker - Does not hit any of the beta release criteria since all of the visible methods work
17:40:22 <tflink> I'm just not sure that the blocker process is right for this but we can re-visit if it isn't fixed by final
17:40:35 <tflink> #topic (736993) error install bootloader with serial interface install
17:40:38 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=736993
17:40:39 <buggbot> Bug 736993: medium, unspecified, ---, pjones, ASSIGNED, error install bootloader with serial interface install
17:40:40 <tflink> #info Proposed Blocker, ASSIGNED
17:41:07 <pschindl> this one should be final blocker
17:41:26 <tflink> did we ever get around to dealing with console install issues?
17:41:42 <tflink> or does that fall under the "all supported interfaces" criterion for final?
17:41:46 * kparal points out comment 46
17:42:20 <kparal> if it is a final blocker, we can't test any automation
17:42:25 <tflink> kparal: yeah, I think that's been the other side of the serial console argument
17:42:44 <kparal> and I don't mean just AutoQA, no one can
17:42:54 <kparal> automation can catch quite some problems
17:43:15 <brunowolff> But does that make it a blocker, rather than just important?
17:43:39 <tflink> with the criteria as they are, I think our options are: defer to final or defer to next week and propose criteria change
17:44:19 <adamw> so we're back to the 'when should serial console block release' question
17:44:22 <pschindl> when I proposed this criterion as final nobody had objection.
17:44:38 <adamw> i think we're generally agreed it should be beta or final - it shouldn't be alpha, and it shouldn't be 'not a blocker'
17:44:56 <adamw> i think i'm probably okay with final
17:45:11 <adamw> as bruno suggests, the question of 'importance to autoqa' is kind of orthogonal to the question of 'importance to the release'
17:45:25 <kparal> and I was not talking about autoqa
17:45:48 <adamw> sorry, so what do you mean?
17:45:50 <kparal> I guess there are people out there who run tests on development releases
17:45:58 <kparal> it's not *just autoqa*
17:46:02 <adamw> what *is* it?
17:46:20 <tflink> beaker would also be impacted if anyone was using it w/ fedora pre-releases
17:46:51 <tflink> wait, that's not quite right. I was mixing up some other issues from F16
17:46:53 <adamw> mmm
17:47:10 <tflink> either way, this isn't a beta blocker as is
17:47:23 <adamw> no, but don't cut off the discussion
17:47:34 <adamw> i mostly proposed it so we could discuss the serial question, as we need to settle it
17:48:02 <kparal> what is our general approach to automation/kickstart/virt stuff?
17:48:06 <kparal> it is all beta?
17:48:16 <kparal> or all final?
17:48:17 <adamw> i don't see those three as being the same thing at all...
17:48:35 <tflink> well, automation tends to rely on virt and kickstart
17:48:40 <adamw> what is it about them that makes you lump them together?
17:49:00 <kparal> I'm just trying to find some pattern
17:49:05 <adamw> but it's not the *only* thing that uses virt and kickstart
17:49:07 <kparal> that could guide us in the decision process
17:49:18 <adamw> so it doesn't follow that 'virt and kickstart are beta  in the criteria because we want automation to work at beta'
17:49:21 <brunowolff> What outside groups need this for testing? For internal testing, we are locked into using the beta release, as opposed to daily builds.
17:49:36 <brunowolff> That should be aren't, not are.
17:49:40 <tflink> I think that a sub-question is whether we consider testability via automation blocker issues
17:53:01 * adamw watches dustballs blow by
17:53:20 <adamw> i don't really have a position on this, i just want there to be a decent justification for whatever decision we come up with
17:53:54 <tflink> how much work would it be to fix serial console install?
17:53:56 <adamw> i'm fine if we decide enough valid beta usage requires serial console install, hence we should make it work
17:54:05 <adamw> that should not be a consideration at all for defining the criteria
17:54:14 <brunowolff> Unless someone outside is doing testing that is blocked by this, I am not sure why this needs to block the beta directly.
17:54:27 <adamw> the criteria are *general*, so how much work it takes to fix *one specific breach* is irrelevant to defining them
17:54:34 <tflink> adamw: I was curious, mostly
17:54:44 <tflink> since this isn't so much of a new issue
17:54:47 <brunowolff> I could see there being problems with not being able to do internal testing that results in problems that result in slipage.
17:54:53 <adamw> i'd actually prefer we didn't get an answer to avoiding improperly influencing the decision...
17:54:55 <kparal> brunowolff: I don't think it really matters whether you are inside or outside. it won't work either way
17:55:13 <tflink> adamw: fair enough, that makes sense
17:55:32 <adamw> bcl: does anaconda team have a strong position on whether this should be beta or final functionality?
17:55:37 <brunowolff> It matters, because inside we can use daily builds for testing. Outside people are going to be looking at the beta release images.
17:55:58 <bcl> hell if I know.
17:56:13 <bcl> Ask pjones :)
17:56:16 <tflink> IIRC, the discusion about serial console install on anaconda-devel was pretty quiet
17:58:03 <adamw> okay, we're not really getting any further here i don't think...
17:58:19 <adamw> how about this: pschindl, can you resurrect your proposal and specifically say that we could do it for beta or final and we need to pick which
17:58:23 <adamw> we'll punt this issue for a week
17:58:30 <adamw> and bcl, please fix it so the problem goes away ;)
17:58:38 <bcl> haha. we'll see.
17:59:21 <tflink> proposed #agreed - 736993 - Does not hit beta release criteria as currently written, will propose changge to critera and re-visit next week
17:59:31 <brunowolff> ack
17:59:32 <tflink> s/changge/change
18:00:00 <pschindl> adamw: I will ask anaconda team again and send a new proposal
18:00:10 <adamw> ack
18:00:18 <pschindl> ack
18:00:21 <tflink> #agreed - 736993 - Does not hit beta release criteria as currently written, will propose change to critera and re-visit next week
18:00:31 <tflink> #topic (754568) [abrt] gnome-shell-3.2.1-6.fc17: _int_free: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV)
18:00:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=754568
18:00:36 <buggbot> Bug 754568: unspecified, unspecified, ---, ajax, NEW, [abrt] gnome-shell-3.2.1-6.fc17: _int_free: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV)
18:00:37 <tflink> #info Proposed Blocker, NEW
18:01:17 <adamw> so yeah, my justification for this is it pretty much makes a default VM unusable as shell will crash before you can do anything substantial.
18:01:20 <tflink> does this also happen w/ VNC connection?
18:01:30 <adamw> i haven't really tested but i think not
18:01:41 <adamw> it's qxl/spice specific
18:01:47 <adamw> qxl/spice is the default for f16 and f17 VMs, though, i believe.
18:01:57 <kparal> I also have the notion that it happens just with spice/qxl
18:02:07 <kparal> adamw: yes, it is the default
18:02:32 <tflink> that would explain why I haven't hit it - I usually force VNC
18:03:45 <tflink> any votes on blockery-ness?
18:04:55 <adamw> +1. obviously.
18:05:03 <j_dulaney> Sorry I'm late
18:05:12 <kparal> definitely +1 blocker, but I'm not completely sure whether Beta or Final
18:05:24 <tflink> anyone else? I'm a little on the fence about beta since VNC works
18:05:36 <brunowolff> Given the explanation that qxl/spice is the default vm environement, I think this fits the criteria for a beta blocker.
18:06:29 <kparal> also, gnome-shell just restarts and you don't lose any data, right?
18:06:37 <kparal> that happens in my case
18:06:39 * j_dulaney is looking at bug
18:06:44 <adamw> kparal: not in mine
18:06:54 <kparal> adamw: did it crash hard for you?
18:06:55 <adamw> thanks to GNOME's 'clever' crash catcher, i always get the fail whale when it happens
18:07:03 <adamw> i think shell crashes, respawns, crashes again, and that triggers the fail whake
18:07:07 <adamw> so i'm dumped back out to gdm
18:07:22 <adamw> if it was just shell restarting every so often it'd be less of a pain.
18:07:38 <kparal> ok, that didn't happen to me
18:07:44 <tflink> yeah, that sounds like beta blocker material
18:07:46 <kparal> for me it just killed and restarted shell
18:08:05 <adamw> kparal: how often have you hit it?
18:08:11 <adamw> just want to see what the sample size is like
18:08:36 <kparal> adamw: with spice/qxl I think you can hit it during 5 minutes
18:08:39 <kparal> my estimate
18:08:42 <kparal> or 10 minutes
18:09:08 * j_dulaney is leaning beta blocker
18:09:17 <kparal> but I tried that just several times, I switched to VNC because I needed to report other bugs
18:09:46 <adamw> kparal: but each time you saw it you just got a shell respawn and could carry on, no fail whale?
18:10:24 <kparal> adamw: I don't remember any reset to gdm, just gdm respawn and you could go on. I *think*
18:10:31 <kparal> I'm not totally sure on that
18:10:47 <kparal> just gnome-shell respawns
18:10:50 <kparal> typo
18:10:56 * j_dulaney doesn't recall hitting this in Alpha tests
18:11:23 <adamw> j_dulaney: it's specific to testing in a KVM with spice/qxl
18:12:32 * kparal boots to F17, he thinks he has a reproducer
18:12:46 <tflink> it sounds like we're mostly beta blocker
18:12:47 <j_dulaney> adamw:  Explains why I didn't hit it
18:13:07 * j_dulaney doesn't use spice
18:13:18 <adamw> kparal: my reproducer is just 'run shell in a VM for about two minutes'
18:13:23 <adamw> it's not exactly a hard bug to trigger :)
18:14:13 <kparal> ok I wanted to reproduce that but my display just exploded into a mess of colors
18:14:27 <j_dulaney> Explosions in the Sky?
18:14:47 <kparal> http://imgur.com/56zZx
18:14:51 <j_dulaney> I don't want to download/install spice just try this.
18:14:56 <tflink> proposed #agreed - 754568 - AcceptedBlocker - Since spice/qxl is the default interface for F16+ KVM, this was considered a common enough configuration to hit the beta VM criterion and the usability criterion from alpha
18:15:14 <j_dulaney> +1
18:15:37 <brunowolff> ack
18:15:38 <kparal> adamw: reproduced. sad face "Oh no!"
18:15:42 <adamw> ack
18:15:46 <adamw> kparal: right, that's the one.
18:15:54 <kparal> adamw: that's the "fail whale"?
18:15:56 <kparal> ack
18:15:57 <tflink> #agreed - 754568 - AcceptedBlocker - Since spice/qxl is the default interface for F16+ KVM, this was considered a common enough configuration to hit the beta VM criterion (#15) and the usability criterion from alpha (#16)
18:15:59 <adamw> kparal: sometimes you can alt-f4 that and get back to work, but doesn't appear to fly in this case.
18:16:05 <adamw> kparal: yeah - the only button you have is 'log out', right?
18:16:09 <kparal> yes
18:16:10 <tflink> #topic (794690) PulseAudio fails to run if ConsoleKit is not present, and CK is not included currently in F17 desktop live image
18:16:14 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=794690
18:16:15 <buggbot> Bug 794690: unspecified, unspecified, ---, lpoetter, ON_QA, PulseAudio fails to run if ConsoleKit is not present, and CK is not included currently in F17 desktop live image
18:16:16 <tflink> #info Proposed Blocker, ON_QA
18:16:25 <kparal> adamw: system settings -> display causes that 100%
18:17:07 <brunowolff> If I don't get any more karma on this build, do you want me to push it to stable at three days (which will happen sometime today)?
18:17:14 <tflink> unlike the last two, this seems like a pretty clear blocker
18:17:57 <adamw> yeah, obvious +1.
18:18:12 <adamw> brunowolff: i'll +1 it today most likely, just didn't get around to it yet
18:18:24 <tflink> proposed #agreed - 794690 - AcceptedBlocker - In most cases, the installed system must be able to play back sound with gstreamer-based applications
18:18:30 <brunowolff> ack
18:18:31 <j_dulaney> +1
18:18:36 <kparal> ack
18:18:40 <tflink> #agreed - 794690 - AcceptedBlocker - In most cases, the installed system must be able to play back sound with gstreamer-based applications
18:18:54 <tflink> OK, that's all of the proposed blockers I had
18:19:30 <tflink> on to the proposed NTH
18:19:42 <tflink> #topic (794478) [abrt] kernel: BUG: soft lockup - CPU#0 stuck for 185s! [lxdm-binary:744]
18:19:44 <j_dulaney> Which is mine
18:19:45 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=794478
18:19:46 <buggbot> Bug 794478: unspecified, unspecified, ---, cwickert, ASSIGNED, [abrt] kernel: BUG: soft lockup - CPU#0 stuck for 185s! [lxdm-binary:744]
18:19:48 <tflink> #info Proposed NTH, ASSIGNED
18:19:53 <brunowolff> I could use another +1 besides Adam's, since it is currently at just 1. (Without the default of 3 needed for auto push.)
18:20:09 <j_dulaney> brunowolff:  I'll test post-meeting
18:20:20 <brunowolff> Thanks!
18:20:47 <adamw> so...this is 100% CPU use in lxdm?
18:20:53 <adamw> j_dulaney: any consequences beyond that?
18:20:53 <j_dulaney> adamw:  Indeed
18:21:03 <j_dulaney> No
18:21:05 <adamw> does the usage persist once you've logged in?
18:21:11 <j_dulaney> Indeed
18:21:21 <j_dulaney> It makes it very difficult to get things done
18:21:23 <adamw> ah, so if you have lxdm as your DM, you'll be pegged at 100% CPU all the time?
18:21:28 <adamw> okay, i'm +1 nth on that for the lxde spin
18:21:29 <j_dulaney> Indeed
18:21:57 <tflink> same here
18:22:01 <dgilmore> +1
18:22:07 <brunowolff> +1 NTH
18:22:07 * j_dulaney started hitting this way early in testing, and originally thought it was something else
18:22:26 <adamw> thanks for the report
18:22:36 <j_dulaney> The fix is supposedly upstream
18:22:59 <tflink> any suggestions on criterion?
18:23:19 <j_dulaney> Well, it makes the DE almost unusable
18:23:41 <adamw> tflink: we don't need one for NTH.
18:23:45 <tflink> proposed #agreed - 794478 - AcceptedNTH - hits the alpha criterion for usability on a non-blocking DE
18:23:49 <adamw> ack
18:23:53 <kparal> ack
18:23:57 <dgilmore> ack
18:24:05 <tflink> adamw: yeah, I was thinking of it as a blocker for LXDE, not an NTH
18:24:11 <tflink> #agreed - 794478 - AcceptedNTH - hits the alpha criterion for usability on a non-blocking DE
18:24:29 <tflink> and that's the only proposed NTH
18:24:35 <tflink> #topic (742207) No usable bootloader option during a text mode f15->f16 upgrade
18:24:39 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742207
18:24:40 <buggbot> Bug 742207: high, unspecified, ---, anaconda-maint-list, NEW, No usable bootloader option during a text mode f15->f16 upgrade
18:24:41 <tflink> #info Accepted Blocker, NEW
18:25:51 <adamw> well, we kinda need anaconda team to work on this one
18:25:51 <adamw> bcl!
18:26:28 <j_dulaney> LOL
18:27:35 <tflink> there doesn't appear to have been any movement on this in the last month
18:27:46 <bcl> hmm
18:29:56 <bcl> oh, I see, I think. it isn't setting the default in the dialog.
18:30:19 <adamw> bcl: do note the issues in comment #4 as well
18:31:05 <adamw> for f16 the fix should just have been to do the same as done in graphical install - make the default 'install new bootloader' and grey out everything else but 'skip bootloader'
18:31:06 <bcl> yeah.
18:31:15 <bcl> I guess I'll take a look at this then.
18:31:17 <adamw> for f17...it gets more complicated. ditto for the graphical path, of course.
18:31:23 <adamw> and the other thing is you shouldn't be able to cancel the dialog
18:31:39 <adamw> or cancelling it should pick the default option, not result in anaconda doing nothing at all about the bootloader
18:32:09 <adamw> er, sorry, not 'cancel the dialog', but proceed without selecting an option
18:32:20 <bcl> right, that may be similar to a bug I fixed for rhel
18:33:52 <adamw> anyhoo, yeah, as long as you're going to look at it, i have absolute confidence! *grabs whiskey bottle*
18:33:55 <tflink> is anything other than poking needed from our end?
18:34:11 <bcl> no, I should be able to reproduce it.
18:34:31 <tflink> #info 742207 is being looked into
18:34:36 <tflink> bcl: ok, thanks
18:34:51 <tflink> alrighty, that looks to be pretty much everything for today
18:34:55 <tflink> #topic open floor
18:35:06 <j_dulaney> Yay
18:35:07 <tflink> any other things to bring up?
18:35:19 <tflink> oh, there's one from me
18:35:26 <j_dulaney> Boo
18:35:32 <tflink> can I get a volunteer to run this meething next week?
18:35:38 * tflink isn't going to be around to do it
18:35:38 <adamw> just again a quick note that we should make sure we do all the Beta tests on alpha and propose any failures as blockers
18:36:01 * j_dulaney won't be sure of availability
18:36:40 * tflink can pester people about it later
18:37:10 * tflink looks at adam, kparal or pschindl for volunteers
18:37:15 <adamw> i'll do it if no-one else does
18:37:27 <adamw> i just don't want to wind up running everything :)
18:37:49 <tflink> it should be a one-week thing
18:37:55 <kparal> do we have a matrix for that? use RC4 matrix?
18:38:42 <kparal> that makes sense I suppose
18:39:04 <pschindl> I will make some upgrade test today
18:39:07 <tflink> #info next blocker meeting on 2012-03-09 @ 17:00 UTC
18:39:22 <pschindl> *tests
18:39:44 * tflink sets the fuse for 5 minutes
18:42:13 <tflink> eh, close enough
18:42:20 * tflink will send out minutes shortly
18:42:24 <tflink> #endmeeting