16:04:44 <jlaska> #startmeeting F13Beta-blocker-review
16:04:45 <zodbot> Meeting started Fri Mar 19 16:04:44 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:00 <jlaska> #meetingname F13Beta-blocker-review
16:05:01 <zodbot> The meeting name has been set to 'f13beta-blocker-review'
16:05:15 <jlaska> #topic Gathering critmass
16:05:19 <jlaska> #chair adamw
16:05:20 <zodbot> Current chairs: adamw jlaska
16:05:23 <jlaska> where's my topic?
16:05:45 <adamw> hellooo
16:05:53 <jlaska> zodbot might be slow today
16:07:04 <jlaska> nirik: know if something is up with zodbot ... or did I call it incorrectly?
16:07:34 <nirik> jlaska: it needs to be oped or the +t topic lock needs removed. ;)
16:08:05 <nirik> jlaska: try topic again. ;)
16:08:35 <jlaska> #topic Gathering crit-mass
16:08:42 * jlaska bows before nirik
16:08:54 <nirik> happy to help.
16:09:44 <jlaska> so we've got adamw and clumens
16:09:52 <jlaska> anyone else?  Oxf13?
16:10:20 <jlaska> I see spot around in case we're in a pinch
16:10:47 <Oxf13> I'm here
16:10:53 <jlaska> howdy
16:10:54 <Oxf13> distracted, but here
16:11:29 <jlaska> I also put a ping out to notting in case he was interested
16:12:09 <jlaska> alright, let's set some roles ...
16:12:18 <jlaska> who wants to chair the meeting and move discussion along?
16:12:45 <jlaska> you're stuck with me if no one wants it: )
16:13:17 <adamw> i told you i can do it, i really don't mind either way
16:13:52 <jlaska> alrighty, you got it then :)
16:14:12 <clumens> i'm just along for the ride
16:14:15 <jlaska> I was thinking about asking someone to be the time keeper here
16:14:17 <clumens> you don't want me in charge.
16:14:23 <jlaska> or everyone can do it ...
16:14:37 <jlaska> if a bug takes longer than X (5?) minutes ... we punt?
16:14:37 <adamw> jlaska: do you have the list of bugs sorted by component?
16:14:56 <jlaska> adamw: yesir ...
16:15:02 <jlaska> firefox spinning ...
16:15:16 <jlaska> F13Beta blocker bugs (sorted by component): http://tinyurl.com/yljlgwt
16:15:20 <clumens> reticulating splines...
16:16:05 <jlaska> another reminder I forgot last time ...
16:16:13 <adamw> nurse! the whizzy thing!
16:16:35 <jlaska> The purpose for this meeting is to evaluate whether the list of F13Beta bugs are valid beta blockers according to https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
16:16:55 <jlaska> kicking the tires on the bugs doesn't hurt either, if we have time
16:16:55 <Oxf13> brb, grabbing my breakfast and bringing it down to the office.
16:17:56 <adamw> alrighty, let's get this party started
16:18:02 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=574748
16:18:03 <buggbot> Bug 574748: medium, low, ---, clumens, NEW, anaconda/python-meh is filing F-13 bugs with version=rawhide
16:18:25 <jlaska> #info adding this to F13Beta for discussion whether this bug affects the Alpha
16:18:29 <jlaska> criteria "The installer must be able to report failures to Bugzilla, with
16:18:31 <jlaska> appropriate information included "
16:18:32 <clumens> i haven't looked into this one at all
16:18:42 <jlaska> I wasn't sure on this bug, so I raised it for discussion here
16:19:00 <jlaska> any concerns that bugs filed by beta testers would be filed against Fedora/rawhide?
16:19:17 <notting> it would be nice to have them filed in the right place
16:19:23 <jlaska> agreed
16:19:26 <adamw> yeah
16:19:27 <clumens> it personally makes no difference to me
16:19:29 <adamw> but i don't think it's a blocker
16:19:44 <adamw> unless them getting filed on rawhide means the anaconda team utterly ignores them and wouldn't notice a really serious problem
16:19:48 <adamw> which I don't think is the case...
16:20:17 <adamw> sure it should be fixed, but i think it should be dropped from the blocker list, personally.
16:20:40 <jlaska> so we can live with bugs being filed in the wrong place for the beta?
16:21:01 * jlaska thinks of a new use for *Target* blocker bugs
16:21:12 <Oxf13> yeah, this could go target
16:21:25 <Oxf13> clumens: and I should figure out what's going on, but not block the release worthy
16:21:45 <clumens> yeah i plan on looking at it, but if it doesn't get fixed i'm not going to panic.
16:21:48 <jlaska> #idea Target bugs can be included in a crit-path package update, but at least one Blocker bug must also be present?
16:22:15 <Oxf13> um...
16:22:28 <Oxf13> I wasn't aware we had such criteria  on crit-path package updates to begin with
16:22:30 <adamw> can we discuss that outside the meeting?
16:22:32 <jlaska> Oxf13 before you jump ... it was just an idea, not an agreed :)
16:22:34 <jlaska> adamw: right
16:22:37 <adamw> =)
16:22:50 <adamw> alright, so i think we have 3 votes to drop this from the blocker list, right?
16:22:57 <Oxf13> here's my personal take on it, and how we've used it in the past
16:23:06 <jlaska> Oxf13: that was more a mental note ... I'll follow-up in the minutes and see if I can better articulate
16:23:08 <Oxf13> We'd take a fix for a Target bug, however we would not delay the release for a target bug
16:23:18 <Oxf13> and as such, I think we'd take a build that only fixes a target bug
16:23:21 <jlaska> Oxf13: right on
16:23:34 <Oxf13> but that only really works if somebody is monitoring and culling the Target
16:23:48 <adamw> okay, so, we can discuss the Target stuff later, for now let's drop this one to Target in honor of that...
16:23:58 <jlaska> I'll update the bz
16:24:02 <Oxf13> adamw: +1
16:24:05 <adamw> #agreed 574748 drops from blocker list, it's not severe enough
16:24:15 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=574743
16:24:15 <clumens> hooray
16:24:16 <buggbot> Bug 574743: medium, medium, ---, dlehman, NEW, NameError: global name 'request' is not defined
16:24:30 <adamw> it's cranes maska time!
16:24:52 <jlaska> heh, I love that guy
16:25:03 <jlaska> he's got real nice hair
16:25:39 <adamw> yeah...*giggles*...real...*snortle*...nice...*guffaw*...hair
16:25:44 <jlaska> heh
16:25:54 <jlaska> okay, so this bug surfaced while testing the TC0 acceptance drop
16:26:05 <jlaska> I think it's a typo in a previous commit for another issue
16:26:24 <adamw> clumens?
16:26:32 <jlaska> I don't understand the full impact, but it concerned editing the partitions on a previously installed system that had LVM logical volumes
16:26:44 <adamw> oh, first of all, do we agree it's a blocker? i'd say so.
16:26:44 <clumens> agreed on the typo bit
16:27:31 <jlaska> on the surface, I'd say probably not ... but I think this might be a fairly common use case
16:27:40 * jlaska reviewing criteria pages
16:27:54 * dmalcolm wonders if the anaconda specfile runs pylint during %check, it ought to be possible to detect this type of error at built time, and kill the build
16:27:56 <adamw> it's not a wildly insane partition layout
16:28:05 <jlaska> it definitly fits with Final release criteria
16:28:10 <Oxf13> dmalcolm: -> #anaconda
16:28:20 <adamw> and our criteria at this point are pretty much "any breakage in a sane partition layout = blocker"
16:28:23 <adamw> so, yeah, smells like blocker!
16:28:29 <Oxf13> whether it's a blocker or not, I feel it should be quite easy to fix for Beta
16:28:35 <jlaska> dmalcolm: there is support for that stuff ... yeah like Oxf13 said, let's continue that in #anaconda ?
16:29:01 <adamw> if it's easy to fix, not worth arguing much about, okay.
16:29:10 <dmalcolm> jlaska: agreed; sorry for heading somewhat offtopic
16:29:15 <adamw> so basically we agree this is a typo and should be a quick fix?
16:29:42 <clumens> yeah
16:29:42 <jlaska> dmalcolm: not worries ... a good topic nonetheless
16:30:14 <adamw> #agreed 574743 will be an easy fix. blocker status uncertain but not worth investing time in discussing
16:30:27 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=572489
16:30:28 <buggbot> Bug 572489: low, low, ---, rvykydal, NEW, Network is disabled on install
16:30:57 <clumens> didn't we previously decide to punt that one?
16:31:23 <adamw> er, lemme check history
16:31:49 <adamw> hum. that's odd.
16:31:54 <adamw> it was nominated as a blocker on the 11th
16:32:02 <adamw> so it should've been on the list for last week's meeting
16:32:22 <adamw> but there's nothing apparently from last week's meeting in there...
16:32:27 <adamw> lemme check last week's log, just a sec
16:32:33 <jlaska> http://lists.fedoraproject.org/pipermail/test/2010-March/089140.html
16:32:43 <jlaska> * AGREED: After discussion, agreed 572489 is not a F13 Beta blocker
16:32:50 <Oxf13> yeah
16:32:53 <Oxf13> I still feel the same way
16:32:54 <adamw> yeah, we did discuss it
16:33:01 <adamw> i think maybe we just forgot to take it out of the list
16:33:01 <Oxf13> if they can fix it, fine, if not, it's not a "regression"
16:33:02 <jlaska> I think we just didn't appoint someone to update the bz, and I didn't do it
16:33:04 <adamw> so let's do it now and move on
16:33:11 <clumens> we have it on master and rhel6-branch
16:33:27 <clumens> i believe we eventually decided it was too big for f13.
16:34:01 <adamw> changed
16:34:11 <jlaska> adamw: thanks, I'm going to grab your response as a StockResponse
16:34:22 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=570302
16:34:23 <buggbot> Bug 570302: medium, low, ---, hdegoede, MODIFIED, Anaconda crashes on Intel BIOS RAID sets with pre-existing partitions
16:34:28 <adamw> oh just a sec
16:34:29 <adamw> #undo
16:34:30 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x163b0e50>
16:34:59 <adamw> #agreed 572489 was agreed not to be a blocker last week but bugzilla was not updated; we will update bugzilla this week
16:35:04 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=570302
16:35:05 <buggbot> Bug 570302: medium, low, ---, hdegoede, MODIFIED, Anaconda crashes on Intel BIOS RAID sets with pre-existing partitions
16:35:39 <jlaska> there's a open question for notting here I think?
16:35:54 <notting> me?
16:36:05 <jlaska> well, maybe not ... looks like hans already has the fix in
16:36:29 <jlaska> notting: https://bugzilla.redhat.com/show_bug.cgi?id=570302#c5
16:36:31 <buggbot> Bug 570302: medium, low, ---, hdegoede, MODIFIED, Anaconda crashes on Intel BIOS RAID sets with pre-existing partitions
16:36:31 <adamw> yeah
16:36:32 <notting> oh, that's waiting on mdadm fixes
16:36:46 <adamw> i'm just trying to think where the original of this bug is, and who can do the testing
16:36:56 <adamw> i believe that cranes maska guy has some intel BIOS RAID configs?
16:38:01 <jlaska> adamw: I don't, no :(
16:38:10 <adamw> there's a traceback in the RHEL bug that this is a clone of, but I *thought* there was an earlier fedora bug. can't find it now though
16:38:19 <adamw> hans isn't online atm
16:38:33 <adamw> should we ask him offline for further details of the issue and who can confirm the fix?
16:40:19 <jlaska> yeah that's good ... hans is quick with feedback usually
16:40:23 <adamw> okay
16:40:33 <adamw> for now i'm not sure we can evaluate this very well since we're not sure what it's about, right?
16:40:37 <jlaska> sounds like a fix is in, but as notting notes, perhaps that's just part of it
16:41:03 <jlaska> It doesn't seem to be pervasive to all BIOS RAID, my bios raid tests are okay still
16:41:24 <jlaska> so not sure how many bios raid devices are affected (all intel?) perhaps
16:41:57 <adamw> okay
16:42:10 <jlaska> adamw: you're original estimate of target on that one holds for me ... unless the scope of the problem increases
16:42:19 <adamw> #agreed we do not have enough information to fully evaluate 570302, will ask for further information from hans on the bug
16:42:33 <adamw> jlaska: that discussion is about a different bug, https://bugzilla.redhat.com/show_bug.cgi?id=537329
16:42:34 <buggbot> Bug 537329: medium, low, ---, notting, ASSIGNED, ISW (Intel BIOS) RAID sets not discovered correctly at boot time
16:42:38 <jlaska> gotcha
16:42:54 * jlaska goes to update bz
16:43:16 <adamw> done it
16:43:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=569377
16:43:25 <buggbot> Bug 569377: medium, low, ---, pjones, ASSIGNED, CDROM install unable to eject disc - storage: error ejecting cdrom sr0: (5, 'Input/output error')
16:43:44 <jlaska> adamw: thanks
16:44:00 <adamw> cranes maska time again
16:44:20 <adamw> we've discussed this at alpha blocker meetings and agreed beta blocker is the appropriate place, as that's the point where we list multi-CD install as expected to work
16:44:23 <jlaska> so I think this problem will hit anyone who boots disc1, does a media check, and selects packages that require > 1 disc
16:44:36 <adamw> so i think we can be confident it is a beta blocker
16:44:44 <jlaska> adamw: right on
16:44:45 <jlaska> "#  The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, multi-CD, and boot.iso install media "
16:44:55 <jlaska> "#  The installer must be able to use the CD and DVD local package source options "
16:45:02 <jlaska> +1
16:45:05 <notting> jlaska: die die die split media die die die
16:45:22 <Oxf13> if only
16:45:23 <jlaska> notting: yes please!
16:45:25 <Oxf13> it'll never die
16:45:32 <jlaska> split DVD will be on us soon
16:45:37 <clumens> yeah
16:45:39 <Oxf13> by the time 700meg CDs become obsolete, we'll be onto split DVDs
16:45:45 <Oxf13> then split blurays
16:45:54 <clumens> then split ass chip.
16:46:04 <adamw> that sounds painful
16:46:18 <clumens> removal is the reverse of installation.
16:46:24 <adamw> anyway, what's the status on this, anaconda guys?
16:46:41 <clumens> if it's a bug assigned to peter, someone needs to bug him about it
16:46:45 <Oxf13> I thought bcl was looking into this, or something with media check
16:47:09 <jlaska> there's another on the list we may need pjones to look at
16:48:31 <adamw> so who wants to take the pjones-poking-stick in hand?
16:48:57 <Oxf13> I suppose I can
16:49:11 <Oxf13> although that really should fall under the anaconda release manager's role (:
16:49:20 <clumens> yeah i can do it too
16:49:27 <Oxf13> that would be better
16:49:44 <adamw> #agreed 569377 is a blocker, clumens to poke pjones about it
16:49:54 <adamw> #action clumens to poke pjones to take action on 569377
16:49:57 <jlaska> clumens is carrying the torch for dlehman today
16:50:12 <jlaska> or, wearing the dlehman mask
16:50:19 <Oxf13> we all wear.... masks
16:50:19 <adamw> oh, we know he carries a torch for dlehman EVERY day
16:50:39 <clumens> I AM A DLEHMAN.  DO WHAT I SAY.
16:50:46 * jlaska has a weird flashback to silence of the lambs
16:50:56 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=539904
16:50:58 <buggbot> Bug 539904: medium, low, ---, akozumpl, ASSIGNED, UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)
16:51:07 <adamw> jlaska: flashback? you were *there*?!
16:51:11 <clumens> i need to talk to dmalcolm about this bug before i ACK the patch.
16:51:41 <adamw> so, AGAIN non-English installs are broken, and AGAIN it takes community testing to notice because we never remember to try anything except English
16:51:41 <adamw> sigh
16:52:03 <adamw> jlaska: should we take a note to add a 'common non-English languages installation' validation test?
16:53:13 <notting> adamw: non-english *TUI* installs, to be precise
16:53:16 <jlaska> #idea non-english languages are not represented in the current installer matrix
16:53:19 <adamw> notting: yeah
16:53:31 <jlaska> #idea non-english languages are not represented in the current installer matrix (both graphical or text-mode)
16:53:46 <jlaska> #undo
16:53:47 <zodbot> Removing item from minutes: <MeetBot.items.Idea object at 0x2b03b3c78210>
16:53:56 <jlaska> no idea if that worked
16:53:57 <jlaska> #undo
16:53:58 <zodbot> Removing item from minutes: <MeetBot.items.Idea object at 0x2b03b1a1b350>
16:54:00 <jlaska> #idea non-english languages are not represented in the current installer matrix (both graphical or text-mode)
16:54:06 <jlaska> sorry, nothing to see here
16:54:36 <adamw> other than that...i think this is definitely a blocker
16:54:40 <jlaska> adamw: I'll ping Hurry to see if she has time to take a look at this
16:54:45 <adamw> so the status is that clumens is looking at the patch?
16:55:09 <clumens> yes
16:55:26 <adamw> alrighty then
16:55:46 <adamw> #agreed 539904 is a blocker, a patch is in the bug, clumens is checking it
16:56:02 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=505189
16:56:03 <buggbot> Bug 505189: medium, medium, ---, rvykydal, MODIFIED, Going back to repo UI screen and and modifying Installation Repo causes traceback
16:56:53 <adamw> this looks like it's fixed already and just waiting on the next compose?
16:56:56 <jlaska> looks like this existed in F12
16:57:07 <jlaska> adamw: yeah, I believe that's the case
16:57:25 <adamw> should this be fixed in TC1?
16:57:49 <jlaska> if we get a new anaconda build
16:58:01 <jlaska> so yeah, should it be fixed ... hmmm
16:58:13 <adamw> well i wasn't sure, there's no 'fixed in version' filled in
16:58:18 <adamw> or mention of the fixed version in the comments
16:58:24 <adamw> just that you tested an updates.img of unknown provenance :)
16:58:47 <jlaska> ...
16:59:33 <adamw> christ on a bike, NVIDIA just invented a graphics card with 295W design power consumption.
16:59:36 <jlaska> oh right
16:59:43 <adamw> so, um, for this bug - I think we just need to know what the status of the fix is
16:59:55 <jlaska> so Radek commited this to master, but was waiting for review in this meeting to commit it to anaconda/f13-branch
17:00:15 <adamw> what needs reviewing?
17:00:17 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=f8c1f662b5195805d5fbde60c6593909cd8f4395
17:00:32 <jlaska> I guess we can decide whether it's a beta blocker
17:00:45 <jlaska> it's an edge case
17:01:11 <adamw> it doesn't feel terribly blocker-y to me
17:01:15 <jlaska> I think this is a nice to have for me
17:01:17 <adamw> but if the fix is going to go in anyway...
17:01:30 <Oxf13> trying to coax the diff out of the git site
17:01:42 <Oxf13> oh yeah, that looks nice and simple.  I'd take it
17:01:50 <jlaska> Oxf13: you saw the link above?
17:01:51 <Oxf13> (provided we get a build in the next day or so)
17:01:59 <Oxf13> jlaska: yeah, it didn't automatically show me the diff
17:02:03 <jlaska> gotfcha
17:02:11 <adamw> clumens: any comment on it?
17:02:16 <jlaska> I tested it against TC0 ... and no spewage
17:02:29 <clumens> adamw: i'm fine with taking it
17:02:47 <adamw> so i think we're agreed it's not a blocker but a nice-to-have and we'll take it?
17:03:27 <adamw> #agreed 505189 is not quite a blocker, but nice to have, and the fix is simple: we will probably take it into beta
17:04:18 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=567346
17:04:19 <buggbot> Bug 567346: high, low, ---, richard, ASSIGNED, gpk-update-viewer does not install updates if there is any dependency issue, and does not correctly report this
17:04:38 <clumens> WHEW
17:05:00 <adamw> i think we're done anaconding
17:05:02 <adamw> thanks clumens
17:05:14 <clumens> sure
17:05:51 <adamw> so this issue has risen from the dead
17:06:04 <jlaska> adamw: is this still frustratingly difficult to consistently reproduce?
17:06:26 <adamw> well i could previously always reproduce it just by trying to install an update set with a dependency issue'
17:06:43 <adamw> what's odd now is that I hit it yesterday on an update set with *no* dependency issue
17:07:00 <jlaska> adamw: still hitting?
17:07:12 <adamw> the changelog for the last gnome-packagekit update claimed a fix for it, but i hit the bug with that version
17:07:14 <adamw> just checking
17:07:19 <adamw> it'll be a different package set today, so...
17:08:51 <adamw> hmm, no, i have the same 25 updates at present, still hitting the bug
17:08:51 <jlaska> Perhaps we can check w/ hughsie on this again, see if there's anything else he can think of?
17:09:02 <adamw> well, i did comment in the bug, no reply as yet
17:09:05 <jlaska> adamw: you're system is available for remote deubg right?
17:09:16 <adamw> yeah, he has a login
17:10:59 <adamw> i'm not sure there's much to say here, just that we're worried about it :/
17:11:04 <jlaska> this fits in with the intel BIOS raid bug
17:11:08 <jlaska> I think we just need more info?
17:11:31 <jlaska> I've pinged jrb to check if hughsie is out of town this week
17:12:06 <adamw> ok
17:12:18 <adamw> i'll try to catch hughsie and pump his brains about it
17:12:37 <adamw> i wonder if the fix for the broken-deps case broke the no-broken-deps case :P
17:12:42 <jlaska> I'd say keep it on the list still
17:12:45 <adamw> have you tried updating with it lately?
17:12:47 <jlaska> adamw: heh
17:13:03 * jlaska trying
17:13:18 <Oxf13> I have
17:13:22 <adamw> Oxf13: worked?
17:13:27 <Oxf13> I used PK last night to update an install I did in parallels
17:13:30 <Oxf13> and yes, it worked
17:13:37 <jlaska> no updates right now (previously applied with yum) ... will update the bz if it fails for me
17:14:07 <adamw> Oxf13: hum. what version of gnome-packagekit ?
17:14:24 <Oxf13> let me unpause it and find out
17:16:01 <Oxf13> gnome-packagekit-2.29.92-0.1.20100315git and PackageKit-0.6.2-1.fc13
17:16:51 <adamw> same as me. hrm.
17:16:55 <adamw> this bug is definitely slippery.
17:17:03 <adamw> well, as we said, not much to do about it, just a 'more info needed' case
17:17:18 <adamw> i'll update on it next week
17:17:31 <Oxf13> because it's so hit/miss I'm still leery about blocking beta for it
17:17:55 <adamw> as long as it's still hitting someone, though, it's almost certainly going to hit some people in final. we really need the update mechanism to be pretty reliable...
17:18:23 <adamw> if we test and find out of 1,000 people it's fine for 999 and only broken for me, then fine, but right now we're still at the 'not really sure what's going on' stage, i think...
17:18:48 <jlaska> right, I'd like to understand more about the conditions where failure still occurs
17:19:42 <Oxf13> adamw: I agree, to a point.  I'd be less willing to let final go out with this
17:20:16 <adamw> we can certainly bump it next week if it seems appropriate
17:20:24 <adamw> but for now i want to keep it on the list so we get updates at least...
17:20:32 <jlaska> +1
17:21:18 <Oxf13> fine by me
17:22:28 <adamw> #agreed 567346 requires more information; hughsie believed it was fixed in latest gnome-packagekit but adamw is still experiencing. blocker status unclear but leaving on list at least until next week
17:22:39 <adamw> #action adamw to talk to hughsie about 567346 and try to diagnose
17:22:47 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568106
17:22:48 <buggbot> Bug 568106: medium, low, ---, pjones, NEW, Unable to enter grub menu in F-13-Alpha with console=ttyS0
17:23:00 <adamw> cranes maska again
17:23:18 <jlaska> clumens: this is the other bug I think we'll need help from pjones on
17:24:03 * jlaska reviews our call on this last week
17:24:31 <jlaska> * No consensus reached on F13Beta criteria  (jlaska, 17:29:10)
17:24:31 <jlaska> * Needs feedback from pjones whether it is a Beta blocker or not
17:25:28 <jlaska> is it a beta blocker ... hmm
17:26:04 <Oxf13> pjones seems online, we could poke him
17:26:08 <adamw> is there a workaround?
17:26:41 <jlaska> adamw: you could install libguestfs to access the guests disk and change grub.conf that way
17:26:44 <jlaska> but ... eew
17:27:36 <adamw> so this is only a problem when you need to modify grub config in the first boot after a serial install?
17:27:44 <adamw> it seems a bit...cornery :)
17:28:04 <adamw> linville: hi - here for the meeting? or just dropping by?
17:28:06 <Oxf13> I'd be more concerned if we could reproduce this on real serial systems, since virt has a very easy workaround
17:28:15 <jlaska> I think you might be right ... it only affects anyone that does virt installs using serial
17:28:30 <adamw> Oxf13: have 'we' (by which i mean 'you') tried?
17:28:43 <linville> adamw jlaska suggested I look in re: 533746
17:28:56 <Oxf13> adamw: I have nothing here capable of serial booting
17:29:00 <Oxf13> er serial output at boot
17:29:25 <adamw> linville: ah yeah we're coming to that in a minute
17:29:33 <adamw> Oxf13: jlaska: so, who does ahve such a beast?
17:30:21 <jlaska> Oxf13: yeah, I don't know if it impacts real systems ... I'll action that.  But it would be helpful too if someone could look at it.
17:30:40 <jlaska> #action jlaska will attempt to reproduce 568106 on bare metal
17:30:51 <Oxf13> I bet pjones might
17:31:11 <adamw> shall we tentatively agree that it's probably a blocker if it affects a bare metal system, and punt it to next week?
17:31:52 <jlaska> well, I'd honestly think the virt use case is more important ... but I can live with that.  I don't want this to fall off the radar
17:32:34 <adamw> well, let's postpone and have a cheery argument next week! that'll be fun
17:32:42 <Oxf13> jlaska: why is the virt case more important when there is a really easy workaround?  (virt-viewer)
17:32:56 <adamw> #agreed 568106 blocker status uncertain, leaving on the list to discuss again next week after further testing
17:33:05 <Oxf13> do we expect that the serial case is that widely used in Fedora virt guests?
17:33:36 <jlaska> Oxf13: same could be said of bare metal (tty0)
17:33:43 <jlaska> Oxf13: I'll need to check w/ jforbes on that
17:33:50 <jlaska> I ping'd, but haven't heard back yet
17:34:03 <jlaska> I'll try to follow-up with some data for next week
17:34:05 <Oxf13> hard to virt-viewer bare metal (:
17:34:19 <jlaska> yup
17:34:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533746
17:34:20 <buggbot> Bug 533746: urgent, low, ---, linville, ASSIGNED, Fedora 12 livecd freezes at udev on Acer Aspire One D250
17:34:29 <adamw> alright, so we have linville with us for this one
17:34:33 <adamw> i've been following it too
17:34:57 <adamw> i believe the status is that they've worked out the issue and have a preliminary patch which at least avoids the hard hang, right linville?
17:36:39 <linville> correct, it will avoid the hang
17:37:00 <linville> b43 still won't work, and if any affected defice has b44 it won't work either
17:37:06 <adamw> ah
17:37:12 <adamw> but still, avoiding the hang's the big thing
17:37:13 <adamw> i think someone expressed concern in the bug that it could theoretically lead to regressions in other cases
17:37:38 <linville> michael can be a bit of a curmudgeon :-)
17:38:33 <linville> I'm refining the patch today, it will avoid executing the new checks on devices that don't have those registers
17:38:40 <adamw> nice
17:38:50 <linville> at least, provided that we actually understand which ones do and don't :-)
17:38:50 <adamw> do you think it'd be best to get this in for the beta, or post-beta?
17:39:15 <linville> probably better to have it in a beta, "just in case"
17:39:41 <adamw> okay. my read is that that's probably best too, it's much more likely to fix than break, so we can roll with it
17:40:25 <Oxf13> worksforme
17:40:28 <linville> I'll polish-up the patch and get the final version reviewed by chuck and larry...err...michael and larry :-)
17:40:57 <adamw> Oxf13: there's, what, a week or so before we start cranking release candidates?
17:41:10 <Oxf13> less than a week
17:41:14 <adamw> oh yeah
17:41:22 <adamw> so, probably best if we can get a kernel build with the patch by tuesday?
17:43:17 <adamw> Oxf13: ^^^
17:44:01 <Oxf13> yeah, that would be best, earlier would be better though to get it into -testing and get some karma on it
17:44:08 <adamw> okay
17:44:19 <adamw> linville: so that's the timetable :) sound workable?
17:45:26 <linville> yes, fine
17:46:10 <adamw> great, thanks
17:46:34 <adamw> #agreed 533746 is blocker-y due to the large amount of systems affected, a fix is in progress and linville is hopeful it can land early next week in time for beta rc1
17:46:50 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=566425
17:46:53 <buggbot> Bug 566425: medium, low, ---, crobinso, POST, qemu: could not load kernel '/var/lib/libvirt/boot/virtinst-vmlinuz.bmav1g': Permission denied
17:47:15 <adamw> come on down, cranes!
17:48:03 <jlaska> tada ... <jazz hands>
17:48:30 <jlaska> I think our previous decision still holds ...
17:48:42 <jlaska> #  The release must boot successfully as a virtual guest in a situation where
17:48:45 <jlaska> the virtual host is running the same release (using Fedora's current preferred
17:48:49 <jlaska> virtualization technology)
17:49:04 <adamw> yep sure
17:49:24 <adamw> i'm looking more at the fix status
17:49:27 <jlaska> I can check w/ cole to see when he anticipates this landing in a Fedora package
17:49:34 <jlaska> he's out right now
17:49:40 <adamw> okay
17:49:43 <Oxf13> it's upstream, so it should hit fedora soon
17:49:47 <Oxf13> but yes, needs some poking
17:49:48 <jlaska> okay
17:49:55 <adamw> if we accept it as a beta blocker we need it in a package in time for beta rc1...
17:49:56 * jlaska updates the bug
17:50:11 <jlaska> next Tuesday, going by previous discussion?
17:50:22 <adamw> that's the day i pulled out of my ass, yeah :)
17:50:45 <Oxf13> Tuesday would have marked the Freeze day, if we were stilld oing freezes
17:50:52 <Oxf13> which would mean Thursday was the RC day I thik
17:51:15 <adamw> alrighty
17:51:17 <Oxf13> release is on the 6th
17:51:17 <jlaska> okay
17:51:37 <Oxf13> which means go-nogo  is on 31st or so
17:51:37 <adamw> #agreed 566425 is a blocker, jlaska will co-ordinate with cole to get a fixed package downstream in time for beta rc period
17:51:56 <adamw> #action jlaska to co-ordinate with crobinson to get a new libvirt package in
17:52:00 <Oxf13> which means we really should have an RC to test by the 31st
17:52:09 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=559290
17:52:10 <buggbot> Bug 559290: medium, medium, ---, lvm-team, ASSIGNED, LVMError: lvcreate failed for VolGroup/lv_root - 512M insufficient for Fedora install
17:52:20 <jlaska> ah, this one
17:52:21 <Oxf13> er 24th
17:52:21 <adamw> yup
17:52:25 <adamw> the testing on this looked promising
17:52:46 <Oxf13> yeah I'd say this is "fixed"
17:53:07 <Oxf13> although it has prompted a need to re-evaluate the listed minimal requirements as well as the anaconda hardcoded requirements
17:53:12 <jlaska> yeah, robatino had some questions around what the true minimum RAM is for an install, but while valuable, I think that's outside the scope of the original reported problem
17:53:29 <jlaska> how should we prioritize that eval?
17:54:08 <Oxf13> I think best for F13 is to see if our existing values hold true
17:54:20 <Oxf13> eg can you perform what we say you can perform with the amount of ram we say you can
17:54:26 <Oxf13> if we can, great.
17:54:38 <Oxf13> for F14 we should revisit if we should adjust those values lower
17:55:04 * jlaska looks for f13 draft release notes
17:55:05 <Oxf13> Do we have matrix items to validate our minimal hardware set?
17:55:43 <jlaska> we don't touch upon validating minimal hardware requirements
17:56:06 <jlaska> wow that's low ...
17:56:06 <jlaska> #
17:56:06 <jlaska> Recommended for text-mode: 233 MHz G3 or better, 128 MiB RAM.
17:56:06 <jlaska> #
17:56:07 <jlaska> Recommended for graphical: 400 MHz G3 or better, 256 MiB RAM.
17:56:11 <jlaska> #link http://docs.fedoraproject.org/release-notes/f12/en-US/html/index.html#sect-Release_Notes-Hardware_Requirements
17:56:14 <adamw> i thought we already revised those? guh
17:56:18 <adamw> there's definitely a bug open for it
17:56:24 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=499585
17:56:25 <buggbot> Bug 499585: medium, low, ---, relnotes, ASSIGNED, clarify minimum hardware requirements
17:57:02 <nirik> uh... for f13 should G3 be mentioned?
17:57:19 <nirik> oh, thats 12, ok.
17:58:18 <jlaska> yeah, I couldn't find the latest 13 relnotes
17:58:55 <jlaska> adamw: should we move further discussion around testing the min requirements into bug 499585?
17:58:57 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=499585 medium, low, ---, relnotes, ASSIGNED, clarify minimum hardware requirements
17:59:04 <adamw> should be somewhere in https://fedoraproject.org/wiki/Category:Documentation_beats
17:59:15 <adamw> jlaska: yeah, but we need to get the docs team interested in that bug...it's been there a while
17:59:41 <Oxf13> back to the topic, I think the current bug is fixed, and the lvm2 package did make it into stable, or it will next time bodhi runs
17:59:42 <adamw> https://fedoraproject.org/wiki/Documentation_Beats_Hardware_Overview looks like the beat
17:59:43 * jlaska sets fedora_requires_release_note = ?
17:59:48 <jlaska> Oxf13: agreed
17:59:52 <adamw> i'd best check they're still using the beats for f13...
18:00:03 <jlaska> Oxf13: I'm concerned about what else will come in with the lvm2 change, but our test matrix should beat on it pretty good
18:00:07 <adamw> what lvm2 package gets used in anaconda exactly?
18:00:18 <adamw> it has to be 'baked in' somehow, right?
18:00:33 <Oxf13> jlaska: it didn't look like much more than just that patch, but I'd have to re-look
18:00:41 <jlaska> adamw: that happens during the compose process (buildinstall I think)
18:00:54 <jlaska> where two great tastes are combined into one installable juicy image
18:01:07 <adamw> hehe
18:01:27 <adamw> but we're going to get at least _one_ more installer image build before beta obviously, so that should be fine
18:01:34 <adamw> so shall we close it?
18:01:45 <jlaska> yup, I'll update the bz
18:02:00 <jlaska> #action jlaska will update 559290 given that it appears the reporter problem is resolved
18:02:02 <adamw> alright
18:02:11 <adamw> #agreed 559290 looks fixed, jlaska to update bugzilla
18:02:21 <adamw> #agreed discussion on hardware requirements documentation to move to 499585
18:02:29 <Oxf13> ahem.
18:02:35 <Oxf13> buildinstall is ran every compose
18:02:37 <adamw> 3 more to go!
18:02:40 <adamw> Oxf13: ah, okay.
18:02:45 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=572215
18:02:46 <buggbot> Bug 572215: medium, low, ---, jforbes, MODIFIED, unhandled vm exit: 0x11 - while creating a guest using virt-install
18:02:51 <Oxf13> the lvm thing is not needed at anaconda rpm build time
18:03:07 <adamw> cranes maska time
18:03:09 <Oxf13> or rather, the lvm used at rpm build time does not dictate what lvm is used on the install iamge.
18:03:41 <adamw> looks like a fix for this bug is going into f12 but having trouble at bodhi stage
18:03:56 <adamw> it's a compendium fix, and works for jlaska's issue but breaks other stuff: https://admin.fedoraproject.org/updates/qemu-0.12.3-2.fc12
18:04:05 <jlaska> #info jforbes directed jlaska to a new qemu package in f12 updates-testing (qemu-0.12) that resolved the issue
18:04:18 <jlaska> adamw: yeah, there are some mixed reports in the update
18:04:21 <Oxf13> so this is an F12 issue?
18:04:34 <adamw> Oxf13: the bug is with booting f13 vm on an f12 host
18:04:36 <Oxf13> that makes things somewhat weird for delaying F13
18:04:49 <adamw> well, we had a similar issue last time (preupgrade)
18:04:59 <adamw> we decided to handle them on a case-by-case basis i think
18:05:29 <Oxf13> right
18:05:35 <adamw> at worst, we could document the use of the dodgy package in updates-testing for this issue, i guess
18:05:48 <adamw> but shall we leave it on the list for now and re-visit next week?
18:05:51 <jlaska> yeah, it's unclear where the update goes from here
18:06:04 <jlaska> that's a general issue with updates that have similar feedback
18:06:20 <jlaska> adamw: yeah, our course of action next week will be to document or mark CLOSED hopefully
18:06:41 * jlaska locates food .. brb
18:07:06 <adamw> well i'd say the update as is certainly shouldn't be pushed
18:07:11 <adamw> as it led to a clear regression for one user
18:07:24 <adamw> one of the -1s isn't just 'it didn't fix my bug', it's 'it broke something that worked fine before'
18:07:27 <adamw> but that's off-topic i guess...
18:07:37 <jlaska> yup
18:08:00 <jlaska> #action jlaska will follow-up w/ jforbes to determine next steps for bug 572215
18:08:01 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=572215 medium, low, ---, jforbes, MODIFIED, unhandled vm exit: 0x11 - while creating a guest using virt-install
18:08:05 <adamw> #agreed 572215 is a blocker, the fact that the broken code is in f12 makes tracking tricky. a fixed package is available but has other problems. will monitor and discuss again next week
18:08:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=574596
18:08:20 <buggbot> Bug 574596: medium, medium, ---, mmcgrath, NEW, Smolt does not run at firstboot
18:08:42 <jlaska> Oxf13: oh good one ... you're right, it sure doesn't
18:08:59 <jlaska> we have this often ... it's not clear what modules *should* run during firstboot
18:08:59 <adamw> have you tested the update?
18:09:02 * jlaska notes
18:09:12 <adamw> oh, looks like it only just showed up
18:09:39 <Oxf13> I have not.
18:09:44 <Oxf13> it's on my list to test today and provide karma
18:09:54 <Oxf13> easy enough to do, install the update, run firstboot --test
18:10:37 <adamw> alrighty
18:10:47 <adamw> i'd do it too except i'm trying to leave my system as-is for the packagekit bug...
18:11:29 <adamw> i note we don't really have any criteria for firstboot
18:11:38 <adamw> though you could argue this is a high severity bug in a critpath package
18:11:48 <Oxf13> yeah, we don't, but there was clearly an error attempting to run smolt
18:11:52 <adamw> should we add some firstboot criteria?
18:11:56 <Oxf13> and smolt is fairly important for us
18:12:08 * jlaska already noted this on https://fedoraproject.org/wiki/Fedora_13_QA_Retrospective for other future steps
18:12:11 <adamw> ah cool
18:12:17 <adamw> i'm okay with this being a blocker
18:12:21 <adamw> especially since there's a fix already ;)
18:12:22 <jlaska> +1
18:12:26 <adamw> okay then
18:12:37 <adamw> #agreed 574596 is a blocker, fix is available for testing, oxf13 will test it today
18:12:48 <adamw> #action group to consider adding firstboot release criteria for f14 / f13 final
18:12:59 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=573868
18:13:00 <buggbot> Bug 573868: medium, low, ---, harald, ON_QA, dialup networking requires kudzu
18:13:01 <Oxf13> adamw: the joys of virt, I don't have to be held hostage by needing to keep a specific state
18:13:43 <adamw> Oxf13: meh. i have vm's too, it's just that i happen to be hitting this bug on the host...
18:13:46 <jlaska> I asked Jim to test this on test@ ... looks like he responded
18:13:56 <adamw> jlaska: he'd already tested on the bug report i think
18:13:58 <jlaska> but beta blocker
18:14:01 <adamw> anyway, yeah, testing looks good
18:14:21 <adamw> jlaska: well, ask yourself if configuration of *broadband* connections was somehow broken the same way, would we consider that a blocker
18:14:31 <adamw> jlaska: then consider how many people still rely on dial-up...=)
18:14:44 <jlaska> sorry, I don't know the numbers there
18:14:50 <adamw> it's easy to think of dial-up bugs as unimportant when you don't have to use dial-up yourself, heh
18:14:58 <adamw> jlaska: as discussed on -devel lately, it's surprisingly quite high
18:15:05 <jlaska> I see, okay
18:15:11 <adamw> jlaska: mainly due to a) developing countries and b) the entire midwest
18:15:39 <adamw> i'm not sure it was really a beta blocker, but i'd definitely have supported it for final blocker
18:15:39 <jlaska> adamw: yeah, looks like Jim provided feedback in the bz and bodhi ... thanks Jim :)
18:16:40 <adamw> so as long as that build gets pushed in time for an install compose should be fine
18:17:12 <adamw> i'll throw a +1 in the bodhi as jim did his feedback as 'anonymous tester'
18:18:02 <jlaska> thx
18:18:54 <adamw> #agreed 573868 may be a final rather than beta blocker, but the fix is available and tested and we will pull it into the beta if it is pushed to f13 stable in time
18:19:33 <adamw> ...aaaand that's the list
18:19:42 <adamw> any other bugs to consider?
18:21:11 <jlaska> adamw: Cranes already had his share
18:21:26 <adamw> heh
18:21:52 <dmalcolm> adamw: BTW, presumably https://fedoraproject.org/wiki/Fedora_13_QA_Retrospective#Introduction should refer to things that went well/badly with F _13_ testing, giving areas for improvement in F _14_ testing?
18:22:07 <jlaska> dmalcolm: that's right
18:22:21 * dmalcolm fixes
18:22:24 <jlaska> I'll update
18:22:35 <adamw> blame that maska guy
18:23:31 <dmalcolm> jlaska: alreayd done
18:24:07 <jlaska> dmalcolm: nice a good test of mediawiki merge
18:24:28 <jlaska> I need to focus on some other tasks this afternoon, so I'm afraid I'm not available for any F13Blocker review
18:24:38 <adamw> that's okay, we went through it last week
18:24:41 <adamw> don't really think we need to again
18:25:45 <adamw> unless anyone REALLY wants to?
18:25:51 <adamw> just haven't had enough exciting blocker meeting fun?
18:25:57 <jlaska> nope, lets close this puppy
18:26:27 <adamw> alrighty
18:26:30 <adamw> thanks for coming everyone
18:26:33 <adamw> #endmeeting