17:03:17 <rbergeron> #startmeeting F17 Final Go No Go Meeting
17:03:17 <zodbot> Meeting started Thu May 17 17:03:17 2012 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:25 <rbergeron> #meetingname F17 Final Go No Go Meeting
17:03:25 <zodbot> The meeting name has been set to 'f17_final_go_no_go_meeting'
17:03:30 <rbergeron> #chair tflink
17:03:30 <zodbot> Current chairs: rbergeron tflink
17:03:39 <rbergeron> #chair dgilmore nirik
17:03:39 <zodbot> Current chairs: dgilmore nirik rbergeron tflink
17:03:43 <rbergeron> #topic Gathering the Peeps
17:03:53 <rbergeron> tflink: is adamw joining or is he passed out
17:04:08 <rbergeron> spot: hellooooo
17:04:09 <tflink> I haven't heard from him this morning
17:04:13 * nirik waves
17:04:21 * rbergeron hasn't heard from spot this morning either
17:04:25 <rbergeron> hey nirik.
17:04:50 <rbergeron> #topic Purpose of this meeting
17:05:21 <rbergeron> #info Purpose of this meeting is to see whether or not F17 Final is ready for shipment, according to the release criteria.
17:05:29 <rbergeron> (to put it very briefly)
17:05:37 <rbergeron> #info This is determined in a few ways:
17:05:46 <rbergeron> #info No remaining blocker bugs
17:06:01 <rbergeron> #info Test matrices are fully completed
17:06:26 <rbergeron> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:06:57 <tflink> the wiki page doesn't seem to be updated properly
17:07:01 <rbergeron> #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
17:07:04 <rbergeron> even with a refresh?
17:07:41 <tflink> wait, maybe I'm just getting my bugs mixed up
17:08:26 <nirik> I think it's not up to date.
17:08:28 <rbergeron> #link https://fedoraproject.org/wiki/Category:Fedora_17_Final_RC_Test_Results
17:09:05 <rbergeron> Okay. tflink: do you ant to take us through what you know to be the right blockers?
17:09:06 <tflink> it was last updated about an hour ago
17:09:22 <rbergeron> or are you implying that perhaps we have none now? :)
17:09:31 <rbergeron> #topic Blocker Bugs
17:09:37 * spot is here now, sorry
17:09:45 <tflink> #info 5 proposed blockers
17:09:45 <tflink> #info 2 accepted blockers
17:10:05 <tflink> any preferences on proposed or accepted first?
17:10:29 <rbergeron> meh... accepted?
17:10:38 <tflink> works for me
17:10:41 <rbergeron> :)
17:10:47 <tflink> #topic (821077) Firstboot window does not fit the screen after install from F17 TC4 Final KDE Live
17:10:50 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=821077
17:10:53 <tflink> #info Accepted Blocker, NEW
17:11:20 <tflink> there is some disagreement on how to fix this
17:11:58 <tflink> but the issue is that firstboot is creating screens before kwin is up and running
17:12:11 <tflink> so that when kwin starts up, it messes with the layout of the existing screen
17:13:04 <nirik> yeah, sleep seems nasty, but easy to do to just work around it for now.
17:13:22 <rbergeron> but will it ever actually get fixed instead of just worked around :)
17:13:38 <nirik> it's unclear to me if anyone is working on the thing in c...
17:13:41 <rbergeron> i can see clumens' point about how that varies from hardware to hardware
17:13:45 <rbergeron> nirik: i agree
17:13:49 <spot> nirik: there is a working C program on that bug
17:13:54 * nirik looks again.
17:14:08 <tflink> nirik: https://bugzilla.redhat.com/attachment.cgi?id=585074
17:14:13 <nirik> ok.
17:14:32 <spot> https://bugzilla.redhat.com/attachment.cgi?id=585074
17:14:36 <rbergeron> working as in "has a heartbeat" or is it actually functional
17:14:37 <nirik> so then the question is where that should live.
17:14:42 * rbergeron looks at bug
17:14:55 <spot> the firstboot maintainer wants it to be in its own package
17:14:58 <rbergeron> err, attachment
17:15:02 <spot> so i'm inclined to simply package it
17:15:21 <nirik> yeah, might be generically useful for other things too.
17:15:38 <nirik> then firstboot can try and call it if it's installed, or ignore if it's not or something.
17:15:45 <rbergeron> spot: how well is it tested?
17:16:30 * spot has no idea
17:16:46 <tflink> rbergeron: the c code? not much AFAIK? kamil has tested with a wait() in firstboot but I'm not sure if many people have been testing the c code
17:16:51 <spot> the code is rather simple and sane though.
17:17:24 <tflink> it would be nice to have someone who knows more about X review the code, though
17:18:16 * nirik is happy to help review, etc... it sounds like thats going to be the best way forward since the sleep is hacky and firstboot doesn't want to carry the c
17:19:08 <tflink> well, is it a better solution than c59?
17:19:24 <tflink> nvm, that's not packaged in fedora
17:19:24 <spot> tflink: yes.
17:19:30 <nirik> "There's XFixes support in Python XLib but only in trunk, not packaged in
17:19:30 <nirik> Fedora..."
17:19:40 <nirik> yeah, that seems worse to me  (more complex, less tested)
17:19:47 <tflink> yep
17:19:53 <spot> not to mention ajax's comment about not mixing the two
17:20:00 <nirik> and ... that yeah
17:20:29 <rbergeron> so: solution is... probably to have spot package said attachment, hopefully have people test it in the interim, and hope it works and move to a new RC?
17:20:41 * rbergeron doesn't want to override maintainer here but ...
17:20:48 <tflink> yeah, that sounds about right
17:21:12 <rbergeron> spot: do you know of anyone else who could sanity check that patch offhand before you run off and do it
17:21:19 <tflink> #info packaging the C code outside of firstboot seems like the best solution for now
17:21:23 <spot> rbergeron: ajax should be able to help
17:21:46 <nirik> we also need changes in firstboot too, right? to call it?
17:22:07 <nirik> and it needs to be on media, etc.
17:22:19 <spot> nirik: yep.
17:22:30 <tflink> firstboot doesn't need to be on media to test it
17:22:40 <tflink> but before we call it solved, yes
17:22:44 <nirik> true.
17:23:02 <rbergeron> #action spot to get patch packaged, get ajax to sanity check patch
17:23:13 <rbergeron> re: changes in firstboot - plans?
17:24:00 <tflink> not sure how all that would work - do python bindings need to be written for the C code?
17:24:33 * rbergeron wonders if jreznik is around
17:24:42 <nirik> it should be able to just look for the executable, if it's there call it... if not ignore and drive on...
17:24:57 <rbergeron> he's not, fooey
17:25:24 <tflink> mgracik is probably the better person for firstboot changes
17:25:57 * rbergeron nods
17:26:23 <rbergeron> tflink or spot or nirik: does one of you want to tackle asking him in bz and maybe also reaching out via email/irc
17:26:43 * tflink just attempted to ping him in IRC
17:26:52 <tflink> but I doubt that he's still around
17:27:11 <rbergeron> yeah, me too
17:27:23 * tflink can coordinate
17:27:27 <rbergeron> tflink: thank you
17:27:40 <rbergeron> #action tflink to coordinate with mgracik re: firstboot changes
17:27:44 <nirik> yeah, sorry, happy to help too
17:27:48 <tflink> you beat me to it :)
17:27:54 <rbergeron> so this remains blockery :)
17:27:59 <tflink> yep
17:28:01 <rbergeron> tflink: i guess we can move on to next bug
17:28:11 <tflink> #topic (822123) Graphical grub is unusable slow
17:28:11 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=822123
17:28:11 <tflink> #info Accepted Blocker, MODIFIED
17:28:15 <rbergeron> unless there's something else you wanted to cover
17:28:18 <rbergeron> but i guess not :)
17:28:26 * rbergeron shuts up and lets tflink do his excellent driving as usual
17:28:31 <tflink> nope, there isn't a whole lot more to say on that one
17:28:58 <tflink> this one should be fixed, just waiting new compose
17:29:17 <spot> not fixed, workedaround
17:29:27 <spot> but same difference from a go-nogo perspective
17:29:31 <tflink> true, I'm not being careful with my words
17:29:46 <tflink> commenting out theme != fixed
17:30:12 <tflink> but it works in the testing so far
17:30:22 * nirik nods.
17:30:24 <tflink> so I don't think there is much to say/do on this other than wait for RC2
17:30:34 * rbergeron nods
17:30:50 <rbergeron> okay
17:31:00 <rbergeron> #info workedaround, just need to wait for RC2
17:31:01 <tflink> #info anaconda-17.28-1 should workaround this to the point where it's no longer a blocker
17:31:16 <tflink> that's all of the accepted blockers right now
17:31:18 <rbergeron> your version sounds far superior :)
17:31:21 <rbergeron> okay!
17:31:37 <tflink> but we have a proposed blocker that is a problem
17:31:42 <tflink> well, at least one
17:31:47 <rbergeron> let's take a look at them
17:31:54 <tflink> #topic (794927) PackageKit cannot import GPG keys - Fatal error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code14: Invalid input passed to daemon: char '<' in text!
17:31:58 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=794927
17:32:01 <tflink> #info Proposed Blocker, MODIFIED
17:32:31 <tflink> this is a rather nasty one that is a consequence of a PK fix that we pulled in for TC5
17:32:58 <tflink> the build does fix the exact issue that is reported but it goes back to requiring an admin password for key importing
17:34:06 <nirik> which leads to bug 748320
17:34:36 <nirik> which was not a blocker in the past.
17:34:51 <rbergeron> it was NTH
17:34:53 <rbergeron> it looks like
17:34:58 <nirik> yep
17:35:15 <tflink> for F16
17:35:16 <spot> mclasen: 794927 is fixed, but it re-exposed 748320
17:35:18 <rbergeron> have we heard anything from dgilmore on this?
17:35:50 <tflink> I don't think so, no
17:35:53 * mclasen reads up on those bugs
17:35:55 <nirik> which also leads back to bug 998. ;)
17:36:09 <tflink> 998?
17:36:17 <rbergeron> that is exactly what i was about to type
17:36:26 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=998
17:36:31 <drago01> tflink: the anaconda does not check signatures bug
17:36:50 <drago01> tflink: has been opne like ... forever ;)
17:37:02 <tflink> wow - open since 1999
17:37:04 <nirik> I think it's likely the oldest open fedora bug.
17:37:28 <nirik> anyhow...
17:37:34 <rbergeron> MEMORIES
17:37:47 * bcl waves
17:37:58 <nirik> should we vote on 748320 being a blocker here? or ?
17:38:38 <tflink> we can, but let's do 794927 first
17:38:41 <rbergeron> yep
17:38:49 * tflink and kamil are already +1 blocker
17:38:52 <spot> +1
17:38:53 <rbergeron> to 794927
17:38:57 * nirik missed that was only proposed.
17:39:07 <nirik> +1 blocker on 794927
17:39:23 <drago01> which part of the bug
17:39:26 <drago01> the error message
17:39:32 <rbergeron> +1 blocker to 794927 as well
17:39:32 <drago01> or the "it requires admin password"
17:39:33 <drago01> ?
17:39:40 <mclasen> spot: not sure I understand how 748320 was 're-exposed' - it was never fixed, was it ? just worked around in the livecd kickstart ...
17:39:41 <tflink> proposed #agreed - 794927 - AcceptedBlocker - Violates the Fedora 17 alpha release criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
17:39:55 <spot> mclasen: yeah, thats what i mean.
17:39:59 * adamw cites whoever scheduled this meeting at 10am for cruel and unusual punishment
17:40:16 <tflink> drago01: this bug is the error that PK gives when it tries to import a key
17:40:43 <drago01> tflink: ah ok ... this is clearly a blocker
17:41:00 <tflink> ack/nak/patch on the proposal?
17:41:08 <nirik> ack
17:41:10 <drago01> a
17:41:19 <rbergeron> adamw: well we need to get it in before release readiness
17:41:43 * adamw catches up on logs
17:42:13 <rbergeron> "it's big, it's heavy, it's wood"
17:42:18 <rbergeron> ack
17:42:27 <tflink> #agreed - 794927 - AcceptedBlocker - Violates the Fedora 17 alpha release criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
17:42:37 <tflink> #topic (748320) automatically import default GPG keys
17:42:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=748320
17:42:39 <tflink> #info Proposed Blocker, NEW
17:43:03 * adamw is -1 blocker because we've been shipping this way for ages. we already explicitly rejected it as an f16 blocker (on the basis we shipped f15 this way.)
17:43:07 <drago01> -1
17:43:07 <nirik> -1 blocker, +1 NTH
17:43:24 <adamw> but really, we should fix it like next week so we don't wind up back here for f18.
17:43:29 * nirik nods
17:43:31 <tflink> probably -1 blocker unless this is the only way we can fix the PK issue
17:43:47 <tflink> other NTH votes?
17:43:57 * rbergeron is +1 NTH, -1 blocker
17:44:28 <adamw> tflink: i think you messed up a bit there
17:44:46 <adamw> this bug isn't really related to 794927 at all. kamil just got reminded of it once that bug was fixed.
17:45:16 <tflink> adamw: if the keys are already imported, we don't need to worry about PK handling it, though
17:45:24 <adamw> the relationship is that 794927 was either caused or exposed by the fix to 821015
17:45:39 <adamw> you seem to have inadvertently transposed that relationship onto 794927/748320 instead
17:45:46 <adamw> at least, by my reading of the log
17:46:18 <tflink> proposed #agreed - 748320 - RejectedBlocker, AcceptedNTH - This doesn't directly hit any of the Fedora 17 release criteria and we've been shipping like this for a while now - rejected as blocker. However, this would improve the user experience and a tested fix would be considered for inclusion past code freeze
17:46:27 <mclasen> in any case, the fix for 794927 is really obvious, and makes importing work
17:46:57 <rbergeron> ack.
17:46:59 <adamw> yeah. point is, 748320 and 794927 aren't at all related. 748320 is just the same bug we've had for years, with the stupid security discussion in 998. nothing at all has changed about it for 17.
17:47:03 <adamw> ack
17:47:05 <nirik> ack
17:47:12 <tflink> #agreed - 748320 - RejectedBlocker, AcceptedNTH - This doesn't directly hit any of the Fedora 17 release criteria and we've been shipping like this for a while now - rejected as blocker. However, this would improve the user experience and a tested fix would be considered for inclusion past code freeze
17:47:20 <tflink> #topic (822430) PK is stuck after installing a single update
17:47:20 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=822430
17:47:20 <tflink> #info Proposed Blocker, NEW
17:47:48 <tflink> I was hoping to try reproducing this before the meeting but ran out of time
17:48:13 <adamw> hughsie told me he'd look at it but i guess he got no time either. :/
17:48:26 * tflink doesn't really want to accept this without repros and more info
17:49:00 <adamw> as described it's obviously crappy behaviour but only really borderline blocker
17:49:08 <adamw> the most common case - just install all the updates and proceed - apparently works...
17:49:13 <rbergeron> has anyone else had this happen?
17:49:25 <tflink> it was just reported earlier today
17:49:26 <adamw> no, but i don't think i tried the repro steps lately
17:49:46 * adamw installing
17:50:38 * rbergeron wonders how many people just cherry-pick one update
17:50:57 <adamw> and if it happens when you just cherry-pick *two* updates...
17:51:01 <tflink> through PK? not sure
17:51:22 <tflink> either way, I'd say punt or reject as a blocker
17:51:51 <nirik> I suspect it's not too common, but not sure.
17:52:04 <rbergeron> adamw: yeah
17:52:44 <rbergeron> i don't think this prevents according to the criteria
17:53:10 <rbergeron> it just makes it suck pretty bad :)
17:53:32 <tflink> proposed #agreed - 822430 - RejectedBlocker - This doesn't directly hit any of the Fedora 17 release criteria and has a simple workaround - install all of the updates. Thus it can be fixed by an update and does not need to block release
17:53:34 <nirik> yeah, it's nasty, but -1 blocker I think.
17:53:42 <nirik> ack
17:54:01 <rbergeron> i think it would be different if it was stuck while installing but it seems that it gets stuck after the install
17:54:07 <rbergeron> makes for a crappy experience
17:54:32 <adamw> are we nth? we do need an rc2
17:54:35 <rbergeron> for those who only do one package of cherry picking which I suspect is not the average user :)
17:54:53 <rbergeron> i would be NTH on this, yes
17:55:00 <tflink> I'm wary of taking PK NTH this late when we already have PK issues
17:56:17 <tflink> if we're clear that it isn't a guaranteed freeze break, I'd be OK with NTH though
17:56:52 <nirik> I'd be ok with NTH, making sure tho that this is commited/produced seperately from the blockers so we don't have to take it if it's too invasive.
17:57:18 <adamw> good plan.
17:57:43 * rbergeron agrees with that
17:58:01 <rbergeron> separate patches plz
17:58:05 <adamw> wow. we have no de-select all button in update? that seems silly.
17:58:12 <adamw> excuse me while i de-select 107 packages...
17:58:34 <tflink> proposed #agreed - 822430 - RejectedBlocker, AcceptedNTH - This doesn't completely hit any of the Fedora 17 release criteria and has a simple workaround - install all of the updates. Thus it can be fixed by an update and does not need to block release. However, it does cause problems with certain update use cases and would be considered for freeze break. Separate patches for the different PK issues are requested so that they can be evaluated individ
17:58:40 <tflink> nice and short
17:58:42 <rbergeron> adamw: well, i guess at least it's even more unlikely people will do that :)
17:58:49 * tflink should write a novel ... in IRC :)
17:59:06 <drago01> adamw: why? it is not like deselecting updates is a common case ...
17:59:11 <tflink> ack/nak/patch?
17:59:13 <nirik> might be 's/patches/patches and builds, updates/'
17:59:15 <mclasen> adamw: context menu ? I thought there was one...
17:59:20 <adamw> oh, didn't try that.
17:59:30 <tflink> proposed #agreed - 822430 - RejectedBlocker, AcceptedNTH - This doesn't completely hit any of the Fedora 17 release criteria and has a simple workaround - install all of the updates. Thus it can be fixed by an update and does not need to block release. However, it does cause problems with certain update use cases and would be considered for freeze break. Separate patches and/or builds for the different PK issues are requested so that they can be eva
17:59:36 <adamw> hey, he's right. reproduced exactly as described.
18:00:14 <adamw> squish it!
18:01:04 <rbergeron> eva ... ?
18:01:16 <rbergeron> evaluated
18:01:29 <nirik> ack
18:01:30 <rbergeron> ... /me doesn't know if that's the end of your statement, tflink?
18:01:44 * rbergeron acks it otherwise, unless the end says "evaluated and then we shall eat kittens"
18:02:09 <tflink> evaluated individually
18:02:13 <adamw> mmmm....kittens
18:02:19 <tflink> ... and then we shall eat chili made of kittens
18:03:13 <tflink> any more ack/nak/patch? I see 2
18:03:40 <rbergeron> everyone else is already devouring kittens.
18:03:56 <bcl> akk
18:03:59 <tflink> #info no kittens will be harmed during the triage and fix for this bug ... if all goes according to plan
18:04:06 <rbergeron> a kute kitten!
18:04:12 <tflink> #agreed - 822430 - RejectedBlocker, AcceptedNTH - This doesn't completely hit any of the Fedora 17 release criteria and has a simple workaround - install all of the updates. Thus it can be fixed by an update and does not need to block release. However, it does cause problems with certain update use cases and would be considered for freeze break. Separate patches and/or builds for the different PK issues are requested so that they can be evaluated in
18:04:28 <tflink> #topic (820478) [ta_IN] Without autohinting tamil strings rendering is badly broken.
18:04:31 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820478
18:04:34 <tflink> #info Proposed Blocker, MODIFIED
18:04:44 <tflink> this one seems kind of borderline to me
18:05:30 <adamw> well, the proposer is okay with not a blocker. looking at the screenshots i have to say not a blocker. it's not unreadable, just a bit fuzzy.
18:05:35 <tflink> huh, I thought it looked worse when I looked at the pictures last nice
18:05:37 <tflink> night
18:05:43 <adamw> (with my long years of experience in reading tamil, etc etc)
18:05:45 <rbergeron> do we have an answer as to whether or not this affects install?
18:05:55 <adamw> you can install in tamil, so, i would say yes.
18:05:56 <rbergeron> or is it just after things are up and running and installed
18:06:41 <adamw> i kinda go with kamil's take on it, really.
18:06:44 <adamw> if we slip, we can pull it in.
18:06:55 <nirik> yeah, +1 NTH, -1 blocker
18:07:00 * adamw running an install in Tamil. it is a little ugly.
18:07:15 <adamw> tiny font size, for some reason.
18:07:35 <rbergeron> I am +1 NTH ... -1 blocker
18:07:42 <adamw> +1 NTH but not if we're going to do some kind of crazy hero rc2 run today.
18:08:37 <tflink> proposed #agreed - 820478 - RejectedBlocker, AcceptedNTH - This doesn't directly hit any of the Fedora 17 release criteria but it does impact readability and user experience for installations in Tamil. The fix is built and tested, will accept if more composes are done.
18:08:43 <tflink> ack/nak/patch?
18:09:03 <nirik> ack
18:09:05 <adamw> ack
18:09:07 * rbergeron would really rather not do a crazy run - there are multiple folks who need to know when things are happening to get them prepped for tuesday or not, but...
18:09:13 <rbergeron> ack
18:09:16 <tflink> #agreed - 820478 - RejectedBlocker, AcceptedNTH - This doesn't directly hit any of the Fedora 17 release criteria but it does impact readability and user experience for installations in Tamil. The fix is built and tested, will accept if more composes are done.
18:09:16 <adamw> we can figure that later
18:09:20 <rbergeron> adamw: yeah
18:09:32 <tflink> #topic (815473) Preugprade from F16 to F17 Beta doesn't successfully set the boot menu default
18:09:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815473
18:09:37 <tflink> #info Proposed Blocker, NEW
18:09:57 <tflink> note that preupgrade issues are not spin-blocking issues
18:10:08 <tflink> so this does not affect our ability to spin a new RC
18:10:56 <adamw> uh...bad freenode.
18:11:05 <tflink> huh?
18:11:11 <adamw> "--- card.freenode.net has changed the topic to: (820478) [ta_IN] Without autohinting tamil strings rendering is badly broken. (Meeting topic: F17 Final Go No Go Meeting)"
18:11:27 <sgallagh> hubbard.freenode.net did the same
18:11:34 <tflink> freenode is running the meeing now? sweet! I can take the day off!
18:11:37 <adamw> ghosts in the machine!@
18:11:40 * tflink saw verne
18:11:51 <adamw> they're stealing our damn release names now? the bastards.
18:11:55 <adamw> beefymiracle.freenode.net....
18:11:58 <bcl> hopefully they don't decide to split
18:12:45 <rbergeron> adamw: what?
18:13:19 <rbergeron> okay, back to 815473?
18:13:22 <tflink> ok, so thoughts on blockeryness?
18:13:30 * rbergeron notes we have release readiness in 45 minutes in here
18:13:31 <tflink> supposedly this is fixed in git
18:13:44 <tflink> we need a build in F16, though
18:14:40 <tflink> and have been waiting for a build for a month and a half?
18:15:03 * tflink looks for a sharp, pointy stick
18:15:08 <rbergeron> why so long?
18:15:18 <sgallagh> tflink: If we think it's a blocker issue, we can have a provenpackager push the upstream patch and rebuild
18:15:42 <adamw> this does hit the criteria as written.
18:15:49 <adamw> since we say the reboot direct to anaconda should work.
18:15:53 <adamw> so i guess, by the process, +1/
18:16:01 <tflink> it does? which criterion?
18:16:23 <adamw> oh. hum. i think i misremembered.
18:16:44 <adamw> uh, the topic in my client is still 820478. you might want to re-do #topic just to be sure.
18:17:06 <tflink> #topic (815473) Preugprade from F16 to F17 Beta doesn't successfully set the boot menu default
18:17:09 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815473
18:17:10 * rbergeron grins
18:17:11 <tflink> #info Proposed Blocker, NEW
18:17:11 <rbergeron> win 40
18:17:22 <adamw> ohh, josef quoted the _test case_, not the criterion.
18:17:35 <tflink> the criteria in question is "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"
18:17:51 <adamw> d'oh. yeah, the criterion doesn't specify, it just says preupgrade ought to be viable. soo...since this is easy to workaround and missing the boot option doesn't really hurt anything, probably -1. it's kinda academic anyhow, really.
18:18:23 <tflink> yeah, I'm probably -1 blocker, +1 sharp pointy stick to "encourage" a new build
18:18:36 <sgallagh> -1 blocker, +1 NTH
18:18:54 <tflink> nth doesn't really make sense for this since preupgrade doesn't go into the compose
18:19:07 <sgallagh> ah, true. I wasn't thinking
18:19:12 <sgallagh> Strike that NTH vote
18:19:21 * rbergeron is with tim on the sharp pointy stick
18:19:34 <nirik> ditto what tflink said.
18:20:15 <tflink> proposed #agreed - 815473 - RejectedBlocker - This doesn't affect the ability of preupgrade to actually work and thus, doesn't violate the Fedora 17 release criteria. The workaround is relatively painless but a new preupgrade build is very much desired as the issue has been fixed in git
18:20:20 <tflink> ack/nak/patch?
18:20:44 <rbergeron> ack
18:20:51 <adamw> ack
18:21:02 <tflink> #agreed - 815473 - RejectedBlocker - This doesn't affect the ability of preupgrade to actually work and thus, doesn't violate the Fedora 17 release criteria. The workaround is relatively painless but a new preupgrade build is very much desired as the issue has been fixed in git
18:21:03 <adamw> mads pointed out that just the preupgrade fix isn't enough, apparently grub2-reboot needs fixing too...
18:21:15 <sgallagh> I'm unclear on the process. Does only nirik get to vote on dev's behalf?
18:21:19 <sgallagh> If not, ack :)
18:21:33 <nirik> sgallagh: anyone can vote I think, we seek consensus. ;)
18:21:39 <nirik> and ack
18:21:56 <tflink> sgallagh: anyone can vote - does it seem like I'm ignoring you?
18:22:11 <sgallagh> tflink: Oh no, I just wasn't sure if we only had one "official" rep
18:22:32 <tflink> yeah, it took me a minute to figure out what you were asking
18:22:42 <adamw> yeah, tflink and i use a highly sophisticated neural networking based algorithm for weighting and sorting the votes
18:22:44 <tflink> on to the last one
18:22:48 <tflink> #topic (822495) Fedora 17 DVD build does not contain device-mapper-multipath
18:22:48 <adamw> by which i mean we pull it out of our ass
18:22:51 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=822495
18:22:53 <tflink> #info Proposed Blocker, NEW
18:23:27 <adamw> well, d'oh.
18:23:32 <tflink> I think this is a pretty clear blocker
18:23:41 <tflink> "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
18:23:52 <adamw> but..but..that doesn't say multipath. :P
18:24:04 <adamw> still, probably +1. you could cite the 'valid partition layout' criterion too i guess.
18:24:04 <tflink> imho, anyone running FCoE or FC w/o multipath is a moron
18:24:11 <adamw> strong words!
18:24:32 <sgallagh> I agree with tflink here. (On both the blocker and moron comments)
18:25:51 <tflink> proposed #agreed - 822495 - AcceptedBlocker - Violates the Fedora 17 final release criterion "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" and multipath is very much the norm for higer end networked storage
18:26:01 <adamw> ack
18:26:04 <rbergeron> ack
18:26:09 <sgallagh> ack
18:26:15 <adamw> so for this we just need to put it in spin-kickstarts or something, right?
18:26:20 <tflink> #agreed - 822495 - AcceptedBlocker - Violates the Fedora 17 final release criterion "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" and multipath is very much the norm for higer end networked storage
18:26:22 <adamw> anaconda has code to install it when needed, but it needs to be available
18:26:26 <nirik> acl
18:26:29 <nirik> ack even
18:26:33 <tflink> adamw: wouldn't comps be a better place for it?
18:26:59 <tflink> it sounds like anaconda has dm-multipath in the installer but it isn't installed to the target system
18:27:59 <adamw> well i think we put stuff that needs to be on the DVD but not in any package group into spin-kickstarts
18:28:11 <adamw> that's what we did with the last thing. crap, what was it. mactel-boot.
18:28:29 <adamw> if you put it in comps it has to go in some package group. well, there was the idea of creating an 'advanced storage tools' comps group or something.
18:28:40 <tflink> where are the rest of the DM pkgs?
18:28:59 <sgallagh> adamw: I'm not sure I'm comfortable adding a new comps group this late in the process
18:29:07 <adamw> nowhere i can see. nothing with 'device-mapper' is in comps since f15.
18:29:10 * tflink notes that this was found on ppc but is likely to exist on x86* too
18:29:17 <adamw> i think the last comment confirms that.
18:29:36 <adamw> anyhow, we're short on time i guess, so we can figure out how to fix it later...
18:29:43 <tflink> yep
18:29:53 <tflink> that's all of the blocker bugs unless another was proposed since we started
18:29:58 <rbergeron> please god no
18:30:03 <tflink> doesn't look like it
18:30:21 <adamw> last one i see was 2.5 hours ago, so no.
18:31:18 <rbergeron> okay, shall we switch gears into the Go/No-Go portion
18:31:45 * rbergeron doesn't know if it's worth covering test matrices at this point, though it would be helpful to know how far we got
18:31:55 <adamw> pretty close to covered.
18:32:03 <tflink> I don't see any holes that concern me much
18:32:23 <rbergeron> #topic Go or No Go?
18:32:24 <adamw> we're missing...SCSI, which we're always missing. and might want to drop.
18:32:29 <adamw> Xen, which is bad.
18:32:34 <adamw> i should've got konrad on that.
18:32:45 <sgallagh> adamw: Is that Xen Dom0 or DomU?
18:32:46 <tflink> it sounds like there has been some testing in the xen community
18:32:47 <adamw> one updates source...eh, we probably covered that in a TC.
18:32:51 <rbergeron> #info Test matrices are pretty much covered, except SCSI, which we are always missing.
18:32:56 <tflink> they don't seem to want to update the matrix, though
18:32:59 <tflink> sgallagh: DomU
18:33:15 <adamw> and "QA:Testcase_install_repository_NFS_graphical", which i can only assume is cos no-one saw it.
18:33:16 <tflink> Dom0 issues are explicitly excluded from being a blocker
18:33:32 <adamw> we're missing a few desktop tests, included all of KDE.
18:33:38 <adamw> so...we're probably not really there on matrix coverage, tbh.
18:33:46 <rbergeron> So basically at this point we have... three approved blockers. yes?
18:33:54 <rbergeron> including the one we just approved?
18:34:04 <adamw> yeah.
18:34:09 <adamw> i think we're looking pretty no-go.
18:34:20 <tflink> 4 approved blockers, no?
18:34:24 <adamw> matrices aren't quite there, and we clearly need an RC2 spin that isn't ready and isn't likely to be in the next 20 minutes.
18:34:28 <tflink> the currrent 2 and the 2 we just took
18:35:12 <rbergeron> oh, we took two? i thought the others were NTH
18:35:22 <tflink> the PK one and the dm-multipath one
18:35:55 <nirik> yeah, sadly no go looking. ;(
18:36:12 <rbergeron> #info 4 blockers - 2 previously accepted, 2 new
18:36:52 <rbergeron> #info some desktop tests, including KDE, are missing, we need an RC2 spin.
18:37:07 <rbergeron> Is everyone in agreement that we are a no-go?
18:37:14 * spot agrees
18:37:36 <nirik> yep.
18:37:38 <tflink> yep, no-go
18:37:45 <sgallagh> Yes, no-go
18:38:10 <rbergeron> #agreed F17 Final (from RC1) is a no-go; we slip one week, for a GA of May 29.
18:38:33 <tflink> and we hit the rhbz upgrade :( I was hoping not to have to deal with that
18:38:40 <rbergeron> crap
18:38:46 <tflink> not the same day
18:39:03 <tflink> it's just the QA scripts that are affected
18:39:05 <rbergeron> okay, any further comments?
18:39:29 * rbergeron nods
18:39:38 <rbergeron> #info Release readiness meeting in this channel in 20 minutes
18:39:51 <rbergeron> #info rbergeron to send out slip mail with a sad, unbeefy face
18:39:55 <rbergeron> #undo
18:39:55 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x25a31050>
18:40:02 <rbergeron> #action rbergeron to send out slip mail with a sad, unbeefy face
18:40:15 <adamw> tflink: and bodhi, right?
18:40:18 <adamw> or is that fixed?
18:40:23 <rbergeron> spot: how long do you think it will take to get that package up and going?
18:40:30 <tflink> it sounds like lmacken has that under control
18:40:37 <spot> rbergeron: bcl actually thinks he found a native python fix
18:40:46 <spot> rbergeron: so it may not be needed at all
18:40:56 <tflink> a fix for python-bugzilla was posted yesterday
18:41:14 <adamw> yeah, we're testing bcl's fix at the moment.
18:41:23 <adamw> by which i mean bcl is testing it and i'm holding the whiskey bottle.
18:41:55 <rbergeron> spot: orly
18:42:17 <bcl> so far it is looking good.
18:42:30 <bcl> Desktop, KDE, LXDE all work fine.
18:42:32 <rbergeron> okay. so we just need to basically ping dgilmore when we think we've got everything
18:42:40 <rbergeron> bcl: you are awesome
18:42:40 <adamw> bcl: i'll see if i can reproduce your Xfce install fail
18:43:29 <adamw> just to let everyone know, since we've got some time now, i'll probably screw off golfing this afternoon.
18:43:45 <nirik> so, when is the next go/no-go? a week from today?
18:43:53 <rbergeron> nirik: yes
18:44:01 <rbergeron> nirik: per evilbob's email - is this really a huge conflict with the irc meeting
18:44:05 <rbergeron> i mean it's in a different channel
18:44:08 <rbergeron> and ... yeah.
18:44:17 <nirik> not really, IMHO
18:44:35 <rbergeron> yeah, MHO2
18:45:10 <bcl> I like thursdays much better.
18:45:40 <rbergeron> #info Next Go/No-Go will be 2012-05-24, same bat time, same bat channel (17:00 UTC, 13:00 eastern, 10:00 pacific)
18:45:41 <nirik> I can propose moving those later or eariler...
18:46:16 <rbergeron> nirik: i don't think it's a big deal, it's not that often, and i don't think there is a huge overlap in attendees
18:46:33 <rbergeron> Okay, anything else?
18:46:46 * rbergeron puts a bottle of something yum in adamw's golf bag thingy
18:47:18 <adamw> christ, i'm bad enough without that
18:47:49 <rbergeron> it's supposed to improve things
18:48:06 <rbergeron> Okay, going once, going twice....
18:48:13 * rbergeron thanks everyone for coming today
18:48:34 <rbergeron> #endmeeting