23:08:46 <adamw> #startmeeting emergency blocker review meeting
23:08:46 <zodbot> Meeting started Tue Apr  3 23:08:46 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
23:08:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
23:08:54 <tflink> adamw: i ran my scripts for blocker bug templates unless you'd rather do this by hand
23:09:03 <adamw> tflink: go for it
23:09:08 <adamw> make sure you got the two i just filed though
23:09:13 * nirik is around, waves.
23:09:20 <adamw> #chair tflink
23:09:20 <zodbot> Current chairs: adamw tflink
23:09:21 <rbergeron> the two whaaaaaa? sniff
23:09:23 <tflink> adamw: as in within the last 5 minutes or so?
23:09:44 <adamw> tflink: pretty much. 809647, 807982.
23:10:12 <tflink> adamw: got those
23:10:18 <adamw> cool
23:10:21 <adamw> fire away
23:10:55 <adamw> hey andre
23:11:29 <tflink> here we go!
23:11:32 <tflink> #topic (807510) fail to boot from the IBM serverRAID
23:11:32 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=807510
23:11:32 <tflink> #info Proposed Blocker, MODIFIED
23:11:36 * rbergeron holds on for the ride
23:12:01 <tflink> we never did get retesting on this :-/
23:12:12 <adamw> no, but you and pjones tested it, sounded pretty good to me
23:12:26 <adamw> so we really should change the title of the bug: we're fairly sure it's nothing to do with RAID and everything to do with efi
23:12:41 <tflink> details ...
23:12:43 <rbergeron> so we didn't get retesting with different hardware?
23:13:00 <rbergeron> well
23:13:23 <tflink> I've tested on my machine, but the kms driver works for me
23:13:25 <adamw> frankly, given what we know about this bug now, i doubt it's even a blocker
23:13:36 <adamw> tflink: yeah, but you went from text to graphical grub, which is the key change.
23:13:41 <bcl> I tested it on mine and now get splash and no ascii-art grub
23:14:15 <tflink> adamw: yeah, just implying the the original issue is supposed to be related to lack of support for matrox gfx
23:14:33 <adamw> i think it's at least reasonable to treat is as 'addressed' for rc3. to our best interpretation of the issue, we have a fix in. without more testing feedback we can't do much better.
23:14:41 <tflink> I didn't see the original issue because I have a different graphics card that didn't get confused by the ASCII art
23:14:54 <adamw> tflink: well the point is that the matrox driver doesn't use kvm
23:15:07 <rbergeron> so are we proposing this as NTH?
23:15:13 <tflink> I'd be +1 NTH on this, at least
23:15:14 <rbergeron> or are you, rather :) someone
23:15:28 * nirik would be ok NTH, but -1 blocker I think.
23:15:28 <adamw> i don't really care about whether we keep it as blocker or nth, so long as we acknowledge it's not stopping rc3 compose.
23:15:41 <adamw> but if we're voting, -1 blocker, +1 nth.
23:15:58 <tflink> the fix made it into anaconda, right?
23:16:02 <bcl> yes
23:16:04 <nirik> especially given that it should be a small subset and fixable via updates.img
23:16:12 <bcl> -1, +1 here too
23:16:27 <rbergeron> -1 blocker / +1 nth from my end
23:17:08 <adamw> ok, so seems we're pretty solid there.
23:17:14 <tflink> proposed #agreed - 807510 - RejectedBlocker AcceptedNTH - After farther investigation, this is only going to affect a relatively small subset of installs and could be fixed by an update
23:17:16 <adamw> ack
23:17:47 <nirik> ackey
23:17:59 <rbergeron> ack
23:18:26 <bcl> ayup
23:18:26 <tflink> #agreed - 807510 - RejectedBlocker AcceptedNTH - After farther investigation, this is only going to affect a relatively small subset of installs and could be fixed by an update
23:18:35 <tflink> #topic (807982) anaconda can not load an updates.img from removable media
23:18:39 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=807982
23:18:41 <tflink> #info Proposed Blocker, NEW
23:18:54 <adamw> okay, this is one of the two annoying ones i just turned up...well, it was filed a few days ago, but not proposed
23:18:57 <tflink> did we come to a conclusion on whether or not this is even still supported
23:19:32 <adamw> right now, our criterion requires updates.img delivery to work via http/ftp, local media, and from an installation repo
23:19:42 <adamw> with noloader, only http/ftp is actually implemented
23:20:08 <rbergeron> yargh
23:20:16 <bcl> Since http works I say -1 blocker
23:20:18 <adamw> i'm not sure there's any reason we _really_ need updates.img delivery to work via anything but http/ftp for beta. can anyone think of one?
23:20:35 <adamw> for bureaucracy purposes, i'm proposing we adjust the criterion to only require ftp/http to work.
23:20:38 <tflink> for beta, nothing incredibly compelling
23:20:45 <adamw> it's kind of like the kickstart delivery criterion we keep thinking of tightening down.
23:20:56 <tflink> it would be nice to have it working for final, though
23:21:02 <tflink> updates w/o network
23:21:07 <adamw> the most obvious case is non-connected systems, yeah.
23:21:10 <rbergeron> yeah
23:21:29 <adamw> but that really doesn't seem critical at beta.
23:21:46 <tflink> proposed #agreed - Adjust Fedora 17 release criteria to only require updates over http/ftp for beta, removable and local media for final
23:22:31 <adamw> for historical context
23:22:36 <rbergeron> no, i suspect anyone that non-connected would be make or break for is not online downloading the beta to burn.
23:22:45 <adamw> this criterion is new - we wrote it in january as part of the concordance effort
23:22:55 <adamw> and it was really only kicked back and forward between petr and me, no one else really chipped in
23:22:56 * nirik doesn't like adjusting critera on the fly, but I think it's correct in this case.
23:23:36 <rbergeron> nirik: yeah, i don't either, but yes, in this case. and to adamw's comments that it is new / relatively "untested" still, i think leaves it a slight amount of wiggle room.
23:23:42 <adamw> petr's rationale for beta rather than final was "I think, that this should be beta for testing purposes. It will be
23:23:42 <adamw> easier to test patches, so it would be better if it worked earlier than
23:23:43 <adamw> later."
23:23:52 * nirik nods.
23:23:56 * rbergeron nods
23:24:11 <adamw> but in practice, we really always just use ftp/http when we need to use updates.img for testing purposes.
23:24:27 <tflink> other than the oddball test cases, yes
23:24:32 <adamw> right.
23:24:56 <adamw> so, ack from me
23:25:04 <adamw> actually, patch
23:25:05 <rbergeron> ack here as well
23:25:08 <rbergeron> oh?
23:25:08 <adamw> we already require http/ftp to work at alpha
23:25:13 <adamw> so:
23:25:23 <tflink> just move to final :)
23:25:38 <adamw> propose #agreed - Adjust Fedora 17 release criteria to require updates.img delivery methods other than http/ftp to work at Final stage rather than Beta stage
23:25:44 <rbergeron> ack
23:25:52 <tflink> ack
23:25:56 <bcl> ack
23:26:08 <nirik> ack
23:26:34 <adamw> #agreed - Adjust Fedora 17 release criteria to require updates.img delivery methods other than http/ftp to work at Final stage rather than Beta stage
23:26:43 <adamw> great
23:26:48 <adamw> so following on from that:
23:27:17 <rbergeron> -1 blocker :)
23:27:20 <adamw> propose #agreed #807982 is rejected as a blocker under the pending modified criterion, accepted as NTH as it clearly can't be fixed with an update
23:27:30 <tflink> ack
23:27:37 <rbergeron> ack
23:28:00 <nirik> ack
23:28:20 <adamw> #agreed #807982 is rejected as a blocker under the pending modified criterion, accepted as NTH as it clearly can't be fixed with an update
23:28:27 <adamw> whee, next one tim?
23:28:32 <tflink> #topic (809342) anaconda tries to install grub on wrong device
23:28:32 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=809342
23:28:33 <tflink> #info Proposed Blocker, NEW
23:29:10 <tflink> +1 blocker
23:29:42 * tflink waits for adamw or bcl to describe since they know more of the details
23:29:44 <adamw> yeah, this is a reanimation of an f16 bug we took as blocker. twice.
23:29:58 <adamw> anaconda doesn't filter out a USB stick you're installing from as a valid bootloader target, basically.
23:30:07 <rbergeron> it's like deja vu all over again.
23:30:28 <adamw> which means it can wind up installing the bootloader to it, in various circumstances. the only one we bothered to reproduce was doing an upgrade via an image written to USB (it writes the bootlodaer to the USB stick not to the hard disk), but we know from f16 experience there were other scenarios you'd hit it in.
23:30:34 <adamw> we've got a fix we're happy with.
23:30:36 <nirik> yeah, +1, the initial report is confusing there writing the netinstall.iso with liveusb-creator. ;)
23:30:37 <adamw> +1 blocker
23:30:52 <nirik> (my +1 was for blocker to be clear)
23:30:54 <adamw> nirik: apparently he really did. and it worked. no idea how. but it's actually irrelevant to the bug, turns out.
23:30:59 <nirik> yeah.
23:31:09 <rbergeron> +1 blocker here as well
23:31:36 <tflink> proposed #agreed - 809342 - AcceptedBlocker - Violates the F17 beta criterion "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"
23:31:44 <tflink> ack/nak/patch ... rock/paper/scissors?
23:32:02 <nirik> rock
23:32:12 <adamw> paa!
23:32:14 <tflink> my broken scissors!
23:32:16 <tflink> noo
23:32:18 <rbergeron> lobster!
23:32:27 * nirik notes it's not really interesting until you add lizard and spock to it. ;)
23:32:45 <rbergeron> ack.
23:32:51 <rbergeron> :)
23:33:05 <adamw> ack
23:33:08 * tflink assumes that those were acks, just cleverly disguised
23:33:12 <adamw> laser sword!
23:33:18 <tflink> #agreed - 809342 - AcceptedBlocker - Violates the F17 beta criterion "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"
23:33:30 <tflink> #topic (809647) sourcing updates.img from installation repository does not work
23:33:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=809647
23:33:35 <tflink> #info Proposed Blocker, NEW
23:33:51 <adamw> so, this seems clearly -1 now we modified the criterion.
23:33:57 <tflink> same boat as 807982
23:34:13 <rbergeron> yeah, same story it looks like in the 12 seconds i spent glancing
23:34:40 <adamw> it is.
23:35:04 <tflink> proposed #agreed - 809647 - RejectedBlocker AcceptedNTH - Due to the recently altered F17 beta release criteria, this is no longer a blocker but can't be fixed with an update; therefore accepted NTH and reproposed as a final blocker
23:35:16 <rbergeron> ack
23:35:17 <nirik> rock/ack
23:35:18 <bcl> ack ack.
23:35:24 <rbergeron> rack!
23:35:29 <tflink> #agreed - 809647 - RejectedBlocker AcceptedNTH - Due to the recently altered F17 beta release criteria, this is no longer a blocker but can't be fixed with an update; therefore accepted NTH and reproposed as a final blocker
23:35:33 <adamw> bwwaaaacak bwack bwack
23:35:42 <rbergeron> duck duck goose, what's next :)
23:35:54 <tflink> #topic (791130) segfault in _clutter_actor_finish_queue_redraw
23:35:54 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=791130
23:35:54 <tflink> #info Proposed Blocker, NEW
23:36:25 <adamw> we have a couple of shell crashers which everyone and their mom seems to be hitting, this is one, and someone proposed it as blocker
23:36:46 <tflink> how bad is it?
23:36:47 <adamw> but i'm -1, i hit it every so often but not frequently enough to make it a blocker. and actually, haven't had a shell crash with 3.4 yet.
23:36:52 <adamw> well, shell crashes.
23:36:58 <adamw> i think one person reported they hit it like every five minutes.
23:37:01 <adamw> but i don't think that's typical.
23:37:04 * tflink hasn't hit it yet but hasn't really had many opportunities
23:37:26 <rbergeron> "every five minutes" or "every five minutes when i spent the full five minutes trying to make it do just that"
23:37:29 <rbergeron> ?
23:37:49 <nirik> what critera would this hit?
23:37:57 <nirik> unable to apply updates before desktop crashed?
23:38:12 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=791130#c49
23:38:13 <tflink> nirik: livecd stability
23:38:23 <adamw> 'boot to a working desktop', i'd say.
23:38:33 <adamw> we have some flexibility of interpretation of 'working desktop'.
23:39:13 <rbergeron> I would say it's probably not something we want to go to final with. :)
23:39:16 <adamw> but yeah, given my experience, -1.
23:39:17 * nirik is slight -1 to blocker.
23:39:29 <adamw> oh, and worth noting, shell crashes are not actually hideous
23:39:35 <adamw> because shell auto-respawns
23:39:38 <nirik> yeah, hopefully beta would also give us more datapoints, etc.
23:39:43 <rbergeron> At least without knowing the cause.
23:39:46 <adamw> the 'user experience' is shell disappears, comes back, and you get an abrt popup.
23:40:08 <adamw> you'd only get real pain if it crashed twice in a minute; then you'd get fail whale. but i don't think anyone's reported that.
23:41:06 <tflink> proposed #agreed - 791130 - RejectedBlocker - The consequences and frequency of this crash were judged to not be severe enough to warrant blocker status for beta
23:41:12 <rbergeron> Well - I'm -1 for beta, but we might consider commonbugging it, but for final, I'd lean the other way.
23:41:12 <adamw> ack
23:41:23 <rbergeron> ack
23:41:30 <adamw> sure, we can re-propose for final
23:41:31 <tflink> rbergeron: yeah, I don't think this would be OK for final
23:42:38 <nirik> ack
23:42:47 <tflink> #agreed - 791130 - RejectedBlocker - The consequences and frequency of this crash were judged to not be severe enough to warrant blocker status for beta
23:42:58 <tflink> #topic (808152) Xorg can't use basic framebuffer (/dev/fb0) driver.
23:42:58 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=808152
23:42:58 <tflink> #info Proposed Blocker, NEW
23:43:03 <adamw> the other one that gets hit all the time is https://bugzilla.redhat.com/show_bug.cgi?id=702257 , btw.
23:43:07 <adamw> if anyone wants to propose that.
23:43:33 <adamw> (for final. propose it for beta and I will CUT you.)
23:43:33 <tflink> I'm pretty much -1 beta blocker for this
23:43:42 <adamw> yeah, -1.
23:43:47 <adamw> this is llvmpipe on fbdev. meh.
23:44:01 <adamw> the practical case that hits it is xen. so we could make it final blocker. but beta, no.
23:44:11 <tflink> unless I'm misunderstanding something, it only hits xen if you use a specific combination of virtual hw
23:44:22 <tflink> and using kdm is an acceptable workaround
23:44:41 <tflink> adamw: I think it would be a pretty big stretch to use the final xen criterion for this
23:44:49 <adamw> meh, we can kick that around later.
23:44:54 <adamw> but definitely -1 beta. it's a corner case.
23:44:59 * nirik nods.
23:45:16 <adamw> to be clear - doesn't hit vmware, doesn't hit vbox, doesn't hit either of the standard qemu/kvm configs.
23:45:23 * rbergeron agrees
23:45:55 <tflink> proposed - 808152 - RejectedBlocker - This is a corner case with xen and was judged to be too specific to accept as a blocker for F17 beta
23:46:08 <tflink> whoops, there was supposed to be an agreed in there
23:46:17 <tflink> proposed #agreed - 808152 - RejectedBlocker - This is a corner case with xen and was judged to be too specific to accept as a blocker for F17 beta
23:46:20 <tflink> better
23:46:25 <adamw> ack
23:46:52 <rbergeron> ack
23:46:57 <nirik> ack
23:47:06 <bcl> aackk
23:47:12 <tflink> #agreed - 808152 - RejectedBlocker - This is a corner case with xen and was judged to be too specific to accept as a blocker for F17 beta
23:47:41 <tflink> whee! that's all the proposed blockers
23:47:56 <tflink> unless there are objections, I don't see any proposed NTH that are worth going over at this point
23:48:11 <adamw> hold that thought
23:48:17 <adamw> couple things i want to do
23:48:21 <adamw> okay, while i'm finding a bug for one of them
23:48:28 <adamw> i think it's worth taking one more look at GNOME 3.4
23:48:34 <tflink> I didn't say we were done :-P
23:48:47 <adamw> i do have one thing that falls in proposed NTH bucket
23:49:37 <adamw> bcl: crap, do you have a link for either of the separate-/usr-is-broken bugs?
23:49:51 <adamw> bcl: want to propose one of those as nth
23:50:03 <bcl> sec
23:50:15 <tflink> want to do the gnome discussion first?
23:50:24 <bcl> 754857
23:50:27 <tflink> we also have some formality to do regarding one of the accepted blockers
23:50:37 <bcl> but it really need a new bug.
23:50:52 <adamw> bcl: no, not that one...
23:51:08 <adamw> bcl: we had two bugs which were basically 'stuff breaks if you install with a separate /usr partition'
23:51:09 <bcl> then no, don't have a #
23:51:15 <adamw> the one which was a crash at the end of live install
23:51:35 <tflink> adamw: you sure that's the wrong bug?
23:52:36 <adamw> yes.
23:52:38 <bcl> yeah, I remember it. I  can't seem to find it at the moment.
23:52:44 <adamw> that's the one for 'running out of space on upgrade'.
23:53:06 <adamw> ah, https://bugzilla.redhat.com/show_bug.cgi?id=804913 is one of 'em.
23:53:50 <tflink> #topic (804913) Fresh Install fails to boot (no init)
23:53:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=804913
23:53:50 <tflink> #info Proposed NTH, POST
23:53:53 <adamw> and https://bugzilla.redhat.com/show_bug.cgi?id=806593 is the other.
23:53:55 <adamw> damn, i'm good. :P
23:54:24 * rbergeron hands adamw a congratulatory hot dog
23:54:27 <adamw> basically, we want to stop showing /usr as a possible mount point in custom partitioning
23:54:45 <tflink> what are we doing about upgrades?
23:54:59 <adamw> because there's these two specific  bugs (at least) if you install with a separate /usr partition , and there is a convincing case at http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for why separate /usr is just a really bad idea.
23:55:17 <adamw> tflink: bcl reckons upgrades shouldn't be affected. the patch really only affects new partitioning layouts, right bcl?
23:55:22 <tflink> adamw: 806593 is already nth
23:55:26 <adamw> oh k
23:55:39 <adamw> my bad, we're ok then
23:55:49 <bcl> I've tested upgrades with /usr and they work fine.
23:56:18 <tflink> #info bz806593 is already acceptedNTH and has the same cause, skipping
23:56:24 <tflink> #undo
23:56:24 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1da11d90>
23:56:31 <tflink> #info bz806593 is already acceptedNTH and has the same fix, skipping
23:57:00 <tflink> ready for gnome 3.4?
23:57:11 <adamw> nope
23:57:14 <adamw> LENOVO
23:57:36 <tflink> so, you called this meeting together without having all the NTH you knew about ready?
23:57:39 <tflink> :-/
23:57:57 <tflink> bz#?
23:57:57 <adamw> sorry, just got reminded of that one
23:57:59 <adamw> my bad
23:58:00 <bcl> I'll git am clumens' patch for /usr
23:58:35 <adamw> feh. we don't have one. oh, let's just sneak it into anaconda and pretend no-one noticed. =)
23:58:57 <adamw> for the record, we're going to resurrect the f16 gpt blacklist of lenovos, because we know quite a lot aren't actually fixed by the thing we though made lenovos handle gpt better in f17.
23:59:20 <adamw> so lenovos will be back to msdos disk labels for 17.
23:59:28 <adamw> right bcl?
00:00:49 <bcl> right.
00:00:54 <adamw> ok, move on!
00:01:20 <tflink> adamw: any preference as to what to move on to?
00:01:45 <adamw> a bar.
00:02:09 <adamw> gnome?
00:02:14 <tflink> well, that isn't a practical option ATM ... so here's the next best thing
00:02:19 <tflink> the bar, that is
00:02:20 <adamw> a gnome bar!
00:02:21 <tflink> #topic (808378) GNOME 3.4.0 as NTH for F17 Beta
00:02:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=808378
00:02:22 <tflink> #info Accepted NTH, NEW
00:02:44 <nirik> folks have been testing a spin of this?
00:02:48 * tflink has visions of a bar full of travelocity gnomes ...
00:02:49 <nirik> any blockers fall out of that?
00:03:03 <adamw> seems fine.
00:03:19 <adamw> so...there's probably about a 98% chance that taking 3.4 for rc3 would be fine.
00:03:20 <tflink> adamw: any particular reason you wanted to revisit this?
00:03:31 * tflink was too slow
00:03:33 <adamw> dgilmore was worried about it
00:03:45 <adamw> and he wasn't around for either of the previous votes, so we didn't have his worries on record
00:03:54 <nirik> I think it would be good press and get us more beta folks... but on the other hand it's a big pile of change in the rc phase. ;)
00:03:56 <adamw> to an extent i share them now, because we're very down to the wire at this point
00:04:07 <tflink> no kidding
00:04:11 <adamw> if we'd spun friday or even yesterday, we'd have had time for a mulligan if it turned out 3.4 somehow screwed something
00:04:14 <adamw> now we really don't
00:04:25 <adamw> the chance of it screwing anything is small, but always _exists_.
00:04:48 <nirik> have most folks testing been using a 3.4 compose?
00:04:50 <adamw> i'd still kinda like to take it, because it is a lot better than 3.3.91. just really wanted to give us a chance to back out if we wanted to.
00:04:55 <tflink> true, but the same could be said about pretty much anything we're pulling in new for RC3
00:04:58 <nirik> is there a danger that the older one has had less testing now?
00:05:10 <rbergeron> as opposed to Final?
00:05:16 <rbergeron> wow, holy lag
00:05:16 <adamw> we have pretty solid testing for criteria compliance with both 3.3.91 and 3.4.
00:05:31 <adamw> the only thing i'm really worried about going wrong is it _somehow_ nerfing the DVD compose.
00:05:38 <adamw> that's the path that hasn't been exercised with 3.4 yet.
00:05:46 <adamw> so it could somehow cause dependency issues, or something.
00:05:59 <tflink> how about this: I'll build a pseudo-RC3 right after this meeting
00:06:06 <tflink> the dvd, I mean
00:06:28 <adamw> if you can do a dvd build with 3.4 included that would definitely help eliminate the breakage possibilities
00:06:52 <tflink> not a problem, thought about doing it last week but decided to sleep instead
00:07:04 <bcl> tflink: I'll have a new anaconda for you in just a few.
00:07:05 <adamw> everyone happy with that plan?
00:07:14 * nirik nods.
00:07:15 <tflink> #action tflink to build pre-RC3 test DVD with GNOME 3.4
00:07:21 <rbergeron> ack.
00:07:35 <bcl> ack
00:07:37 <adamw> coolbeans.
00:08:23 <kalev> for the record, I'm worried about including this at the very last minute as well (I was the one who submitted the GNOME 3.4 NTH bug)
00:08:24 <tflink> proposed #agreed - 808378 - Will still pull Gnome 3.4 in for F17 beta RC3, pending test build of isntaller DVD
00:09:07 <bodhi_zazen> Is there a live CD with 3.4 , if so I will test it
00:09:21 <adamw> bodhi_zazen: linked in the bug
00:09:29 <tflink> I don't think that any of us are/were thinking there was no risk in this - in my mind its a balance between the benefits of getting wider testing w/ beta and risking slip again
00:09:32 <kalev> I read adamw's document about doing the composes and in my opinion, pulling this in should have warranted a full-blown TC on friday
00:09:47 <tflink> ack/nak/patch?
00:09:52 <adamw> kalev: oh, man, that paragraph is why that SOP is still in draft =)
00:10:11 <kalev> adamw: that was my favourite paragraph :)
00:10:36 <adamw> kalev: we never have, in practice, done a TC after an RC. we've come close to it once, but that's all. but let's not re-open that can of worms, at this point in time it's irrelevant.
00:10:52 <tflink> adamw: except for F17 alpha, no?
00:10:59 <adamw> kalev: do you have any specific worries that 3.4 might break something, or just the generalized sense of murphy's law the rest of us do?
00:11:01 <tflink> which caused much fuss
00:11:09 <bodhi_zazen> Thank you adamw
00:11:09 <adamw> tflink: we didn't do it for alpha, i don't think?
00:11:23 <kalev> adamw: nothing concrete, as much as I know everything is working fine
00:11:26 <tflink> it was either that or F16 - I know we did it once
00:11:48 <tflink> either way, not very important ATM
00:11:58 <adamw> no, we considered doing it for 16, but didn't.
00:12:07 <adamw> check the test-announce archives. anyhow.
00:12:28 * satellit_ FYI netinstall just now has gnome 3.4.0
00:12:34 <rbergeron> adamw, tflink, et al: I am being obligated to eat
00:12:39 <rbergeron> so I have to depart.
00:13:06 <tflink> rbergeron: thanks for coming!
00:13:14 <rbergeron> tflink: thanks for having :)
00:13:25 <adamw> k, we're nearly done right tflink?
00:13:52 <tflink> yep, just one more that I know of and another I suspect
00:14:11 <tflink> first with the one I suspect
00:14:14 <adamw> okay, welp, next one
00:14:20 <tflink> #topic (808029) kickstart cannot be mounted on hard drive
00:14:20 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=808029
00:14:20 <tflink> #info Accepted Blocker, NEW
00:14:31 <kalev> by the way, regarding broken deps on DVD -- I checked repoclosure with F17 stable + GNOME 3.4 by hand and it also passed AutoQA depcheck
00:14:41 <tflink> 2 questions - is this still a bug? if so, is it a blocker?
00:14:45 <adamw> kalev: cool, there's some packages in a side repo but that's good.
00:15:06 <adamw> tflink: neither wwoods nor i could actually reproduce the bug as described.
00:15:20 <adamw> and wwoods thinks he's fixed up some generalized weirdness in the code which could plausibly have led to such a failure.
00:15:45 <tflink> do we want to call it good enough? or just not a blocker?
00:15:57 * tflink is thinking not a blocker
00:16:06 <adamw> i would probably vote not-a-blocker since i tried to reproduce and couldn't; for me, the test passes. wwoods had same result.
00:16:36 <adamw> oh, and twu has put a 'pass' result in the matrix.
00:16:41 <adamw> so broadly, we have three passes and one fail.
00:17:18 <tflink> proposed #agreed - 808029 - RejectedBlocker - After investigation, we have been unable to reproduce this bug and the reporter has made no comments regarding farther reproduction - judged to no longer be serious enough to stay a blocker
00:17:25 <tflink> ack/nak/patch?
00:17:45 <adamw> ack
00:18:10 <tflink> did we lose everyone else?
00:18:17 * nirik is still here. ;)
00:18:18 <nirik> ack
00:18:28 <tflink> #agreed - 808029 - RejectedBlocker - After investigation, we have been unable to reproduce this bug and the reporter has made no comments regarding farther reproduction - judged to no longer be serious enough to stay a blocker
00:18:48 <tflink> and the other one, which is more beaurocratic followthrough
00:18:51 <adamw> i guess bcl is hard at work on new anaconda build.
00:18:52 <tflink> and spelling failure
00:18:54 <adamw> whee bureaucracay
00:19:02 <bcl> yes
00:19:03 <adamw> that was definitely a joke and not more spelling fail.
00:19:06 <bcl> to both
00:19:06 <tflink> #topic (745202) gnome-shell does not display correctly with NV3x adapters - multicolor corruption of panel, Shell-style menus and text [nvfx]
00:19:09 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=745202
00:19:12 <tflink> #info Accepted Blocker, NEW
00:19:26 <adamw> i think by this point we can just drop the blocker status
00:19:35 <tflink> exactly what I was thinking
00:19:44 <adamw> we have enough feedback that the change we put in with rc1 or rc2 or whatever 'correctly addresses' it, i.e. blacklists nv3x
00:19:44 <tflink> just figured we should go through the motions
00:20:07 <adamw> okay, so: -1 blocker, the blacklist makes this bug no longer hit the criteria as affected systems get a working desktop (fallback)
00:20:16 <nirik> sounds reasonable
00:20:27 <adamw> oh, hey, I know how gnome 3.4 could break stuff!
00:20:34 <tflink> proposed #agreed - 745202 - RejectedBlocker - While this bug has not yet been properly fixed, the blacklist has addressed the problem of non-functional installs enough for beta
00:20:37 <adamw> kalev: the blacklist didn't get dropped from gnome-session at all did it ?
00:20:56 <kalev> adamw: I have no idea
00:21:08 * adamw checks
00:21:40 <adamw> carry on, i can background this
00:22:00 <nirik> ack
00:22:03 <tflink> ack/nak/patch?
00:22:04 <kalev> adamw: your fix seems to be still included in gnome-session 3.4.0-1 build
00:22:10 <adamw> kalev: okay, we're good then.
00:22:18 <adamw> kalev: don't take it out. even if ajax asks. his mesa blacklist is broken. :P
00:23:20 <adamw> ack
00:23:28 <tflink> #agreed - 745202 - RejectedBlocker - While this bug has not yet been properly fixed, the blacklist has addressed the problem of non-functional installs enough for beta
00:23:34 <tflink> OK, I do believe that is all!
00:23:48 <tflink> #topic open floor
00:23:54 <tflink> anything else or something I missed?
00:24:29 * adamw is frazzled
00:24:32 <adamw> but i think that's it
00:24:51 <adamw> if anything else comes up i'm gonna steal robyn's bugzilla login and massage it out of existence. :P
00:25:17 * tflink sets fuse for ~ 3.14159 minutes
00:25:26 <adamw> mmm. pi.
00:25:29 <dramsey> +1
00:28:12 <tflink> thanks for coming everyone!
00:28:20 * adamw will secretaryize
00:28:22 <tflink> hopefully this'll be the last blocker review for a little while
00:28:25 <tflink> adamw: thanks
00:28:28 <tflink> #endmeeting