15:00:06 <adamw> #startmeeting Fedora QA meeting
15:00:06 <zodbot> Meeting started Mon Mar 26 15:00:06 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:10 <adamw> #meetingname fedora-qa
15:00:10 <zodbot> The meeting name has been set to 'fedora-qa'
15:00:14 <adamw> #topic roll call
15:00:25 * pschindl is here
15:00:27 * j_dulaney cranks the bagpipes
15:00:29 * Cerlyn is here
15:00:32 * jskladan here
15:00:36 <adamw> morning everyone, it's happy fun meeting time in happy fun qa land where the happy fun beta blockers make us all fun and happy
15:00:36 * twu twu is here
15:00:53 * kparal is all fun and happy
15:00:57 <adamw> wait, these aren't aspirin.
15:00:59 <j_dulaney> adamw:  Are you on something?
15:01:09 * tflink is here
15:01:11 * mkrizek is here
15:01:25 <Cerlyn> beta blockers can be avoided by eating more beta carotene
15:02:11 <jskladan> adamw: My Little Blocker Friendship, you say...
15:02:28 * nirik is lurking
15:02:38 * maxamillion is here
15:02:51 <adamw> #chair tflink kparal
15:02:51 <zodbot> Current chairs: adamw kparal tflink
15:03:05 * brunowolff is here for 1/2 hour, then work meeting
15:03:24 <adamw> wow, full house, huh
15:03:33 <adamw> okey dokey, let's get rolling
15:03:39 <adamw> #topic previous meeting follow-up
15:04:14 <adamw> #info "adamw to bug j_dulaney to bug Sugar test day folks" - I did that, the page got lots of nice test cases, and much fun was had by all.
15:04:30 <adamw> aaaaaand that's all i got for previous meeting follow up. anything I missed?
15:05:12 <adamw> guess not
15:05:25 <adamw> #topic Fedora 17 Beta status / blocker review
15:05:49 <adamw> so, we got RC1 done Friday and now we need to get all the testing done
15:06:06 <adamw> #info Beta RC1 was built Friday afternoon and now needs testing
15:06:16 * maxamillion is downloading now
15:06:32 <twu> yeah, we have done some tests in the day working
15:07:01 <adamw> yup, i see that
15:07:20 <twu> but still have some bugs
15:07:21 <adamw> looks like quite a few bugs have been filed, so we should probably check those for blockers
15:07:28 <brunowolff> I was able to do an install from a live image to a laptop. It went fine. (Though I had to tweak anaconda as the machine only has 512 MiB of memory.)
15:08:07 <j_dulaney> I thought that limit was supposed to be removed
15:08:14 <j_dulaney> It seems rather artificial
15:08:42 <brunowolff> I think they are waiting for testing to see what the new limit should be.
15:08:54 <brunowolff> It would be nice to lower it for final.
15:09:39 <adamw> we need to test it
15:09:53 <adamw> i think right after noloader landed, anaconda team did some tests and found they couldn't install with 512MB
15:09:57 <adamw> but now it sounds like that's changed...
15:10:30 <brunowolff> I didn't test a normal install, just the live install and that may make a difference.
15:10:42 <j_dulaney> adamw:  I never had trouble installing with 512MB
15:11:13 <rmarko> same here
15:11:16 <adamw> in F15 and F16 it was definitely unsafe.
15:11:16 <j_dulaney> BTW, for the record, I am now running F17 as my primary OS
15:11:19 <adamw> anyhoo
15:11:33 <adamw> i'm just running through the bugs that have been reported so far and nominating some as blockers, then we can do some blocker review...
15:11:53 <twu> now gnome3 can work fine on kvm :)
15:12:17 <maxamillion> twu: +1
15:12:30 <adamw> yeah, that's nice.
15:12:37 * twu have a question
15:12:44 <j_dulaney> twu:  It could for the past couple of months
15:12:55 <j_dulaney> Since early in Alpha phase
15:12:56 <tflink> j_dulaney: spice has had some issues as of late
15:13:06 <twu> j_dulaney: yeah, it is
15:13:13 * satellit_laptop fine on Virtualbox also
15:13:23 <j_dulaney> tflink:  I haven't seen any
15:13:29 * j_dulaney will test post-meeting
15:14:49 <twu> how can we see the changes made in anaconda just before we start testing
15:14:55 <adamw> nearly there...
15:15:13 <adamw> j_dulaney: until last week shell on KVM would crash regularly.
15:15:22 <adamw> twu: how do you mean?
15:15:30 <adamw> twu: something other than looking at the anaconda changelog?
15:15:50 <twu> adamw: yes
15:16:06 <j_dulaney> Do a diff?
15:16:14 <j_dulaney> It's all Python
15:16:38 <j_dulaney> adamw:  Ah, I'd forgotten about that
15:17:20 <adamw> look at the git log?
15:17:33 <pschindl> for example: it would be nice, if we know about changes in installer parameters (like repo=... -> inst.repo)
15:17:54 <twu> adamw: does it have something like "release note"?
15:18:12 * twu agree with pschindl
15:18:29 <pschindl> they haven't changed their wiki. It is hard to test, when everything is different then in the previous version
15:19:12 <adamw> whew, okay. sorry about that
15:19:24 <tflink> pschindl: yeah, dracut is like that too
15:19:39 <adamw> afaik, no, not really. all you get is the rpm changelog, git log, maybe the Bodhi update page.
15:19:42 <tflink> bad tflink for not fixing it since that's been off since at least F16
15:19:48 * adamw gets the list of proposed blockers
15:20:06 <adamw> okay, let's do our impromptu blocker review
15:20:27 <mkrizek> last update of release notes was back in 2002 :) http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=docs/anaconda-release-notes.txt;h=167411cb19791a6712bf48b76541ebf0d2eab710;hb=HEAD
15:21:17 <adamw> looks like it could do with a bit of an update :P
15:21:48 <adamw> for the record, i'm using http://ur1.ca/8t8f7 as the proposed blocker list, as the wikified one won't have caught up with my changes
15:22:09 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=804514
15:22:10 <tflink> adamw: it only gets updated ~ every hour
15:22:15 <adamw> yes.
15:22:33 <kparal> we can fix that, but I don't know who manages it
15:22:46 <adamw> jlaska, as far as anyone does. i think.
15:22:46 <kparal> zodbot is able to receive notifications in the matter of minutes
15:22:52 <tflink> kparal: the wiki page or anaconda release notes?
15:22:57 <kparal> wiki page
15:22:59 <adamw> anyhow
15:23:02 <tflink> kparal: that would be jlaska
15:23:10 <adamw> this one sounds like Shell tries to run after a vesa install, and fails.
15:23:14 <adamw> has anyone else tried that?
15:23:34 <kparal> not me
15:24:07 <adamw> so for me this is a blocker
15:24:34 <adamw> criteria: alpha "The boot menu for all installation images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer and attempting to use the generic driver" combined with "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any
15:24:34 <adamw> of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied"
15:24:38 <adamw> zoiks.
15:24:55 <adamw> it'd be nice to have confirmation from one other tester though at least
15:25:21 <tflink> I can give it a try
15:26:09 <adamw> any votes on blockerinessA?
15:26:23 <twu> when I leave the office, my 32 bit's still running, sorry for that :)
15:26:28 <tflink> if it is what it sounds like, +1 blocker
15:26:35 <brunowolff> Assuming this happens reliably, I am +1 blocker.
15:26:48 <mkrizek> seems like a blocker to me too
15:26:55 <kparal> +1 blocker
15:26:59 * brunowolff is off to another meeting
15:27:01 <j_dulaney> +1 block
15:27:04 <twu> +1 block
15:27:04 <j_dulaney> er
15:27:10 <Cerlyn> I installed with xdriver=vesa , but I don't recall seeing a menu choice to force it
15:27:29 <adamw> propose #agreed #804514 is a blocker per the criteria about a 'basic video' install option being present and the one about installs that are done according to the other criteria booting to a functional desktop
15:27:36 <adamw> Cerlyn: it's under 'advanced options' or something.
15:27:39 <kparal> ack
15:28:21 <j_dulaney> ack
15:28:29 <tflink> ack
15:28:33 <pschindl> ack
15:28:34 <adamw> #agreed #804514 is a blocker per the criterion about a 'basic video' install option being present and the one about installs that are done according to the other criteria booting to a functional desktop
15:29:04 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806749
15:29:39 <adamw> this also seems like a straightforward blocker, and has a confirmation in the matrix (failures listed from hongqing and cra)
15:30:04 <tflink> yeah, +1 blocker
15:30:06 <adamw> looks to prevent NFS install and hence break alpha "The installer must be able to use the HTTP, FTP and NFS remote package source options "
15:30:28 <kparal> interesting, I tried that right now
15:30:34 <kparal> I didn't encounter that
15:30:57 <j_dulaney> +1 blocker
15:30:57 <kparal> I'm missing more information from hongqing. which compose? which arch?
15:31:31 <bcl> kparal: I asked him to rerun with rd.debug and serial so all the details can be captured.
15:32:00 <adamw> kparal: the matrix says x86_64, but don't know if he used DVD or netinst.
15:32:22 <kparal> I used i386 netinst
15:32:25 <tflink> adamw: for a NFS install, does it matter?
15:32:40 <kparal> anyway, blocker +1
15:32:46 <bcl> +1
15:32:47 <adamw> tflink: if kparal couldn't reproduce, possibly? :)
15:32:57 <tflink> or is this just an NFS repo failure instead of nfsiso
15:33:09 <adamw> this is nfs repo failure, but there's a bug for nfsiso failing too.
15:33:21 <bcl> I think it is related to the symlink wwoods addded.
15:33:31 <bcl> not an nfs problem.
15:33:48 <adamw> propose #agreed 86749 is accepted as a blocker per alpha criterion "The installer must be able to use the HTTP, FTP and NFS remote package source options". note kparal reports a successful nfs install so we should compare notes
15:33:56 <twu> I encounter this bug on i386
15:34:19 <adamw> ah, so three fails...
15:34:24 <adamw> kparal: you're weird.
15:34:26 <adamw> :P
15:34:42 <kparal> I did not report successful install. I just didn't see *this* bug :)
15:34:43 <twu> I tested the i386 DVD
15:34:59 <adamw> kparal: ah
15:35:09 <adamw> propose #agreed 86749 is accepted as a blocker per alpha criterion "The installer must be able to use the HTTP, FTP and NFS remote package source options". note kparal reports not seeing this bug, so we should compare notes
15:35:14 <kparal> ack
15:35:18 <j_dulaney> ack
15:35:21 <twu> ack
15:35:24 <tflink> ack
15:35:35 <adamw> #agreed 86749 is accepted as a blocker per alpha criterion "The installer must be able to use the HTTP, FTP and NFS remote package source options". note kparal reports not seeing this bug, so we should compare notes
15:35:40 <adamw> you all fail.
15:35:42 <adamw> #undo
15:35:42 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x2cdbd610>
15:35:47 <adamw> #agreed 806749 is accepted as a blocker per alpha criterion "The installer must be able to use the HTTP, FTP and NFS remote package source options". note kparal reports not seeing this bug, so we should compare notes
15:35:53 <adamw> that's why we do proposed, y'all. =)
15:36:18 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806708
15:36:28 <tflink> adamw: you're the one who typo'd
15:36:28 <adamw> aaand here's the nfsiso failure.
15:36:55 <adamw> it was an intentional typo just to see if you'd notice. honest!
15:36:56 <kparal> wasn't that supposed to be fixed in anaconda 17.14?
15:37:08 <adamw> a very similar one was supposed to be fixed, yeah
15:37:21 <adamw> but cra seems pretty clear he's on beta rc1
15:37:34 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=804813 was the previous bug
15:37:37 <tflink> as written, +1 blocker
15:37:44 <adamw> the effect is the same (nfsiso borked) but it's clearly not the same bug
15:38:14 <pschindl> +1 blocker
15:38:14 <adamw> sounds like we could do with others testing this and confirming, and adding the info needed if it fails
15:38:51 <j_dulaney> +1 blocker
15:38:52 <twu> I hate this bug, so +1 blocker :)
15:39:33 <bcl> the repo=nfs* bugs are different than this one.
15:39:43 <adamw> that means extra fun times for you!
15:40:14 <adamw> propose #agreed #806708 is a blocker per alpha criterion "The installer must be able to use the HTTP, FTP and NFS remote package source options", needs more info
15:40:17 <bcl> in those cases I think it loses the network when it turns on NM. In this case he's modifying the repo entry.
15:40:47 <pschindl> ack
15:40:49 <bcl> so don't lump them all with this one.
15:40:59 <adamw> we're not proposing any dupage.
15:41:00 <tflink> ack
15:41:17 <twu> ack
15:41:22 <adamw> #agreed #806708 is a blocker per alpha criterion "The installer must be able to use the HTTP, FTP and NFS remote package source options", needs more info
15:41:55 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=806931
15:41:57 <adamw> grr
15:41:58 <adamw> #undo
15:41:58 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x21cee810>
15:42:03 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806931
15:42:18 <adamw> so this is the one you two are discussing in #anaconda right now, right?
15:42:30 <kparal> yes
15:42:36 <adamw> i'd be more comfortable taking this as a blocker if you could reproduce without using virt-install...
15:42:48 <kparal> good idea
15:43:02 <kparal> I hate manual tinkering with initrd, but I'll do that
15:43:04 <tflink> I'd be interested in seeing if the impregnated initrd test case fails
15:43:04 <adamw> the criterion wasn't really written with the scenario of using an external tool that does various other things as well as pass a kickstart in mind
15:43:17 <tflink> since that would be the same mechanism
15:43:18 <adamw> tflink: we have a test case for that one, right?
15:43:23 <tflink> yep
15:43:25 <adamw> so yeah, do that.
15:43:32 <adamw> other  votes?
15:43:47 <bcl> -1
15:43:58 <tflink> punt til' we know whether it's anaconda or virt-install
15:44:41 <adamw> bcl: -1 on what grounds? do you have sufficient info now to determine it's not a blocker
15:44:42 <adamw> ?
15:45:03 <kparal> I'd also wait a while until we know more
15:45:15 <kparal> I'm working on it right now
15:45:23 <bcl> I don't think we should block on virt-install not working.
15:45:51 <adamw> bcl: well, i said it would be good to see if this also affects non-virt-install use of initrd injection
15:46:09 <adamw> but -1 is a vote to reject it as a blocker immediately, without finding that out
15:46:56 <bcl> I don't mean that we won't try to sort it out and fix it, just that it not working shouldn't (IMHO) block Beta.
15:47:21 <bcl> note that I'm not a policy wonk. So my vote may be worthless :)
15:48:36 * kparal proposes delay until next meeting
15:48:42 <adamw> okay, well we have more votes to delay than to reject, just wanted to check if you knew something we didn;t
15:49:16 <bcl> nope
15:49:31 <adamw> propose #agreed we need to know if 806931 affects non virt-install cases to determine blocker status - punt until next meeting
15:49:49 <kparal> ack
15:50:13 <tflink> ack
15:50:15 <twu> ack
15:50:32 <adamw> #agreed we need to know if 806931 affects non virt-install cases to determine blocker status - punt until next meeting
15:50:50 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=805166
15:51:20 <adamw> this one's been hanging around as proposed since tc stage, actually. we never had a clear up/down vote on blocker status/
15:51:39 <kparal> comment #10 summarizes it
15:51:47 <adamw> so the aim here is to source the installer as well as packages via nfs, right
15:52:02 <kparal> source just the installer
15:52:11 <adamw> oh, right.
15:52:13 <kparal> the packages should be taken from default online directories
15:52:17 <kparal> that's the use case
15:52:30 <adamw> so you want to get the installer from nfs but packages from internet...right.
15:52:35 <kparal> yep
15:52:35 <bcl> I tried this last week, it is a network problem FWIW
15:52:48 <kparal> bcl: what do you mean by network problem?
15:54:01 <bcl> it downloads squashfs, switches root and when it turns on NM it stops working.
15:54:26 <adamw> and this is a new issue because previously just doing a PXE boot would pull in the installer as it was part of the anaconda initramfs.
15:54:41 <adamw> so we don't have criteria for this.\
15:54:44 * jskladan needs to go afk for 10 minutes
15:55:21 <kparal> our criteria concern package repo availability, because we never needed to deal with installer fetching from a remote place
15:55:32 <adamw> given all of that, i guess i'd vote we should add criteria to the same release level as we have PXE boot, and accept as a blocker.
15:55:42 <j_dulaney> +1
15:55:58 <kparal> adamw: which level is that?
15:56:49 <kparal> we have to make the criteria more searchable (e.g. add PXE keywords and such)
15:56:52 <kparal> anyway, +1
15:57:04 <bcl> running squashfs over NFS really isn't a good idea, even if it does sorta work.
15:57:37 <twu> +1
15:57:43 <kparal> if it's documented that it doesn't work, I have no problem with it. but there's no documentation whatsoever
15:57:43 <tflink> +1
15:58:00 <kparal> regarding root= option
15:58:04 <bcl> kparal: well then there's the answer :)
15:58:51 <adamw> yeesh. sorry guys, my laptop just blackscreened.
15:58:53 * adamw catches up
15:58:57 <kparal> I don't understand why it should work with repo= option and shouldn't work with root= option
15:59:03 <adamw> bcl: doesn't that leave us with an effective regression in capabilities between loader and noloader though?
15:59:09 <kparal> repo= just adds a definition of online repos, nothing more
15:59:12 <adamw> how are you supposed to do a PXE install but use internet package sources?
16:00:08 <bcl> adamw: nfs is way more fragile than http which pulls it all down and then runs it.
16:00:19 * Viking-Ice joins in late
16:00:32 <bcl> I don't know if we've ever supported running stage2 from nfs.
16:00:40 <twu> just add "repo=http://....." to the boot arguments?
16:00:49 * adamw notes we don't seem to have pxe criteria anyhow. sigh
16:01:58 <kparal> twu: right, http works. that's the current workaround
16:02:05 <twu> I feel like the pxe just refer to the kernel boot stage
16:02:19 <j_dulaney> Hmm
16:02:34 <kparal> this is not just about pxe. the same applies for VM boot from kernel pair
16:03:33 <adamw> so we can either require this to work via NFS, or say that if you want to direct boot anaconda via nfs you have to provide repo=http for it to pull the squashfs from...
16:04:03 <adamw> mmf. feels like we kinda need someone to step back and do an overview of what we actually expect to work here, then re-evaluate?
16:04:05 <kparal> repo= is a superset of root=. nfs works with repo=, but doesn't work with root=. seems really weird to me saying nfs is not supported for root=.
16:04:12 <bcl> how do you boot initrd via nfs? you can't, you have to pxe or local boot it.
16:04:17 <adamw> kparal: yeah, that did seem odd.
16:04:31 * rbergeron peeks in between meetings, ugh
16:04:40 <adamw> rbergeron: if i were you i'd peek right back out again
16:04:58 <j_dulaney> Ugly in here
16:05:31 * kparal votes for a blocker, until anaconda publicly documents what should work and what should not
16:05:41 <wwoods> kparal: you're wrong about repo
16:05:45 <kparal> currently it seems to me this should work
16:05:51 <rbergeron> adamw: OOK, a squirrel
16:05:56 <kparal> wwoods: welcome
16:06:05 <rbergeron> err, look, /me sighs at less funny with bad keyboard
16:06:07 <wwoods> stage2= and method= are deprecated in favor of "repo="
16:06:07 <j_dulaney> Squirrel?
16:06:36 <rbergeron> j_dulaney: it's running around with my ADD meds.
16:06:40 <wwoods> "repo=" gives the location of an *installable tree* - i.e. package repo + .treeinfo file + install.img etc
16:06:50 <kparal> and root image
16:06:59 <wwoods> kparal: that's 'install.img', yes
16:07:07 <kparal> ok
16:07:16 <kparal> it's called squashfs.img in my tree
16:07:18 <adamw> propose #agreed defer #805166 and ask anaconda team to clearly document supported methods for remote retrieval of installer in the noloader era, then update criteria to reflect this
16:07:19 <wwoods> "root=live:nfs:..." is not something we've supported in any release
16:07:31 <tflink> ack
16:07:35 <j_dulaney> ack
16:07:36 <kparal> ack
16:07:44 <twu> ack
16:07:45 <pschindl> ack
16:07:47 <wwoods> (in theory it *should* work but there seems to be some problem with the ifcfg/dhcp lease handover)
16:08:35 <wwoods> it's already documented. it's repo=
16:09:11 <kparal> wwoods: what if I don't have the whole installable tree mirrored?
16:09:18 <kparal> just boot images
16:09:26 <wwoods> that's still repo=
16:09:32 <adamw> so basically it's not considered supported to try and pass root=(someremotesource)? repo= should always be used
16:09:38 <kparal> but I want to fetch installer from LAN
16:09:40 <wwoods> correct
16:09:48 <j_dulaney> In that case
16:09:52 <j_dulaney> Maybe -1 blcoker
16:09:53 <adamw> okay, that seems clear enough. in that case, -1 blocker.
16:09:54 <wwoods> kparal: that's fine. repo={http,https,nfs,ftp}
16:10:13 <adamw> so you can pass repo= for a location which does in fact contain packages, but does contain the installer
16:10:14 <kparal> wwoods: my use case is installer from LAN and packages from Internet
16:10:18 <adamw> and anaconda should deal correctly with that?
16:10:19 <wwoods> as long as there's a .treeinfo file that points to the [stage2] mainimage it should work
16:10:23 <adamw> sigh.
16:10:26 <adamw> does NOT in fact contain packages
16:10:32 <wwoods> yes.
16:10:44 <adamw> it'll let you use remote repos. okay.
16:10:54 <kparal> wwoods: please document all of this. I'm sure it doesn't work in all cases you mentioned
16:11:09 <kparal> wwoods: here: http://fedoraproject.org/wiki/Anaconda/Options
16:11:09 <wwoods> fine, then that's a bug
16:11:15 <wwoods> but the existing documentation is the expected behavior
16:11:32 <adamw> "repo=
16:11:33 <adamw> This option tells anaconda where to find the packages for installation. This option must point to a valid yum repository. "
16:11:36 <kparal> "This option must point to a valid yum repository"
16:11:43 <kparal> adamw: you're faster
16:11:54 <kparal> so Packages/ must be present
16:11:54 <adamw> (even though later on it contradicts itself and allows you to use ISOs.)
16:12:26 <wwoods> https://fedoraproject.org/wiki/Anaconda/Options#method
16:12:28 * j_dulaney should note that he does have a package
16:13:08 <adamw> wwoods: it rather looks like the repo= section should be revised to be more accurate for noloader, and we should also get the installation guide updated.
16:13:09 <wwoods> basically, method= and stage2= used to be how you did this. now you just do repo=. we'll update the docs accordingly.
16:13:30 <wwoods> s/noloader/reality/ - noloader has not changed any of this
16:13:58 <adamw> wwoods: well, as kparal explains it, before noloader, just pxe boot would pull in the installer, because it was part of the initramfs.
16:14:12 <adamw> or was that an earlier change than noloader?
16:14:14 <wwoods> in f15 and f16, yes. in every release prior, no
16:14:20 <adamw> point.
16:14:31 <kparal> I'm 100% sure that missing yum repository in the repo= location aborts installation. I reported bug about it. I can dig it up
16:14:45 <kparal> so that would be blocker instead
16:14:48 <wwoods> kparal: if that's the case I'll make sure we have some alternate method to boot with just images
16:14:48 <twu> wwoods: thanks, and does the 'askmethod' not using any more in the future?
16:15:01 <adamw> we'd still need to revise the criteria, if we actually wanted to consider this kind of split install blocking.
16:15:10 <adamw> all the criteria have ever said is that remote package sources have to work.
16:15:12 <wwoods> twu: 'askmethod' is gone - choose your method/repo argument at the boot prompt
16:15:13 <kparal> wwoods: ok, I supposed that's what root= is for
16:15:21 <adamw> so, anyhow, this is getting messy
16:15:31 <wwoods> anyway, yes, docs will get revised
16:15:41 <adamw> propose #agreed 805166 is not a blocker per anaconda team's statement that using root= in this way is not supported or expected to work
16:15:51 <j_dulaney> ack
16:16:01 <twu> wwoods: thanks!
16:16:03 <adamw> propose #action wwoods to ensure anaconda docs are updated to reflect what repo= is supposed to be capable of
16:16:15 * kparal links 790348
16:16:17 <tflink> ack
16:16:22 <kparal> ack
16:16:24 <twu> ack
16:16:45 <adamw> propose #action kparal to propose revised criteria to cover split installs (installer sourced from one repo, packages from internet repos)
16:16:58 <adamw> and also we probably need a pxe criterion. heh.
16:17:09 <tflink> adamw: ack on the docs action
16:17:16 <j_dulaney> ack
16:17:16 <kparal> ack, but blocked on:wwoods action
16:17:18 * twu agree :)
16:18:08 <adamw> cool.
16:18:12 <adamw> #action kparal to propose revised criteria to cover split installs (installer sourced from one repo, packages from internet repos)
16:18:17 <adamw> #action wwoods to ensure anaconda docs are updated to reflect what repo= is supposed to be capable of
16:18:22 <adamw> #agreed 805166 is not a blocker per anaconda team's statement that using root= in this way is not supported or expected to work
16:18:25 <adamw> whew.
16:18:47 <j_dulaney> http://www.math.vt.edu/people/jbwillia/computer.gif
16:18:50 <j_dulaney> After that
16:19:09 <adamw> heh.
16:19:10 <twu> ha ha
16:19:23 <adamw> well, great, now i had to switch computers the proposed blocker list is in a different order. siiiigh
16:19:32 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806962
16:20:40 <adamw> so, l-i-t-d dvd.iso doesn't work
16:20:46 <adamw> tflink: right?
16:21:08 <tflink> I'm +1 on this for consistency's sake - IIRC, we tell people to use l-i-t-d instead of dd for bootable USB install media
16:21:16 <tflink> adamw: not as far as I can tell
16:21:30 * tflink use --format and --reset-mbr
16:21:33 <tflink> used
16:21:47 <bcl> yeah.
16:22:32 <adamw> criteria-wise, this is a conditional breakage of "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media" (alpha) for the case 'DVD image written to USB with l-i-t-d"
16:22:56 <j_dulaney> Is this a l-i-t-d bug, or a F17 bug?
16:22:56 <adamw> i actually should probably propose explicit criteria revisions to cover USB writing of media, but it's so common these days I'm certainly +1
16:23:09 <adamw> probably the former, right bcl?
16:23:28 <tflink> j_dulaney: I think that something changed w/ noloader such that l-i-t-d doesn't work any more
16:23:35 <bcl> adamw: yes
16:23:35 <j_dulaney> Ah
16:23:40 <tflink> so a little bit of column A, little bit of column B
16:23:49 <tflink> but the fix will be in livecd-tools
16:23:59 <tflink> I think, anyways
16:24:04 <bcl> tflink: repo seems to override root. I had to split the usb into 2 partitions for noloader.
16:24:07 <j_dulaney> Well, then, wouldn't that be -1 blocker, then?
16:24:24 <bcl> tflink: I'm leaning towards anaconda-dracut right now.
16:24:25 <j_dulaney> Since the fix is livecd-tools?
16:24:27 <adamw> j_dulaney: no, but it would mean the blocker didn't block image spins.
16:24:35 <j_dulaney> Ah
16:24:35 <adamw> j_dulaney: that's how we've usually handled these before.
16:24:56 <adamw> we take the bug as a blocker, but when it's in say livecd-tools or preupgrade, that's understood to mean that the tool has to be fixed by release time, not that we delay the image composes.
16:25:06 <tflink> j_dulaney: I can create the usb on F17 if that would make you feel better :)
16:25:39 <j_dulaney> LOL
16:25:43 <tflink> bcl: I certainly trust your judgement more than mine on where the issue is
16:25:49 * j_dulaney unwads his panties
16:25:52 <bcl> thanks ;)
16:26:12 <bcl> I'm +1, I think it demonstrates a bug with root and repo interaction.
16:26:13 <adamw> j_dulaney: i think i even put a reference to this kind of situation in the sop
16:26:16 <adamw> +1 blocker
16:26:18 <bcl> in anaconda-dracut.
16:26:42 <j_dulaney> Righteo
16:26:45 <j_dulaney> +1 blocker
16:26:54 <j_dulaney> adamw:  Who reads the SOP :)
16:27:03 <adamw> j_dulaney: yeah, docs are for wusses :)
16:28:08 <adamw> propose #agreed 806962 is a blocker per criterion "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media", in the case of DVD or boot.iso written to USB with l-i-t-d. note it's one of the blockers where we require the tool to be updated by release time rather than delaying the composes
16:28:16 <tflink> ack
16:28:29 <tflink> scratch that - nack
16:28:34 <adamw> patch?
16:28:43 <j_dulaney> Real Furry Creatures from Alpha Centaurii don't use docs at all!
16:28:45 <tflink> the bug isn't in l-i-t-d
16:28:56 <tflink> its in anaconda-dracut which would block image compose
16:29:11 <adamw> oh, right. bcl, agree?
16:29:18 <bcl> yes
16:29:21 <adamw> patch:
16:29:31 <adamw> #agreed 806962 is a blocker per criterion "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media", in the case of DVD or boot.iso written to USB with l-i-t-d
16:29:34 <adamw> simples!
16:29:40 <tflink> ack
16:30:34 <adamw> whew, i think i finally bored everyone to sleep.
16:30:45 <adamw> oh, and i missed the propose from that one, so it's in effect. whee.
16:30:56 <tflink> adamw: now you know how I feel during the blocker review meetings :)
16:31:01 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806867
16:31:09 <adamw> tflink: hey, i was doing them when you were just a pup ;)
16:31:22 <j_dulaney> LOL
16:31:32 <tflink> point taken
16:31:46 <adamw> this seems like a straightforward preupgrade fail, hence blocker per the beta preupgrade criterion
16:31:47 <adamw> +1
16:31:56 <tflink> isn'
16:31:58 <brunowolff> +1 blocker
16:32:02 <adamw> tflink: i think i was in charge of the infamous one which went on for seven hours, with a lunch break./
16:32:03 <tflink> t this a dupe?
16:32:20 <adamw> tflink: possibly, i didn't look for dupes. of what, though? it's different from the preupgrade bug we had pre-RC.
16:32:25 <adamw> that was the root= issue.
16:32:29 <j_dulaney> +1
16:32:43 <bcl> looks like preupgrade needs to be updated for noloader
16:32:48 <pschindl> +1 blocker, I have met this when I was using inst.repo=hd:.. option too
16:32:50 <adamw> at least, i think it's different.
16:32:54 <mkrizek> +1
16:33:13 <tflink> adamw: I thought the one that seems to have been closed was about handling usrmove
16:33:26 <tflink> come to think of it, that might have been upgrading w/ anaconda
16:33:36 <tflink> +1 blocker, though
16:33:40 <adamw> yeah, the pre-rc one hit the 'no or empty root= parameter' kernel panic
16:33:47 <adamw> post-rc we get a dracut error, so clearly, different.
16:34:13 <tflink> adamw: I don't think I've had the pleasure of a 7 hour review yet and hopefully it'll stay that way
16:34:25 <adamw> heh
16:34:38 <j_dulaney> I'll skip such
16:34:44 <adamw> you can never leave
16:35:08 <j_dulaney> I have class in a while
16:35:08 <adamw> propose #agreed 806931 is a blocker per 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"
16:35:12 <j_dulaney> ack
16:35:16 <pschindl> ack
16:35:17 <tflink> ack
16:35:18 <brunowolff> ack
16:35:20 <adamw> #agreed 806931 is a blocker per 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"
16:35:24 <adamw> okay, circling back briefly:
16:35:35 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806931 (redux)
16:35:42 <adamw> this is the virt-install one again
16:35:53 <kparal> see comment 5
16:35:55 <adamw> kparal just confirmed it happens with no virt-install involved, just per the initramfs-injection test case
16:36:14 <adamw> so in that case i'm +1 blocker as we still have that "The installer must be able to use all kickstart delivery methods" beta criterion.
16:36:28 <tflink> +1 blocker
16:36:35 <kparal> +1 blocker
16:36:52 <j_dulaney> +1 blocker
16:37:01 <adamw> propose #agreed 806931 is accepted as a blocker per beta criterion "The installer must be able to use all kickstart delivery methods"
16:37:05 <tflink> ack
16:37:22 <pschindl> ack
16:37:44 <adamw> #agreed 806931 is accepted as a blocker per beta criterion "The installer must be able to use all kickstart delivery methods"
16:37:56 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806784
16:37:56 <bcl> kparal: thanks.
16:38:13 <kparal> bcl: doing my best
16:38:30 <adamw> as described this is a blocker, though it'd be good to have confirmation (BIOS RAID can be temperamental)
16:38:33 <j_dulaney> +1 blocker, looks pretty clear
16:38:44 <tflink> as described +1 blocker
16:38:48 <adamw> i can confirm this locally when i have a chance (I have bios raid test config)
16:38:53 <tflink> would be nice to have more HW info, though
16:39:09 <tflink> in case this is like the NVRAID bug from F16
16:39:19 <tflink> or any of the intel raid bugs
16:39:20 <adamw> yeah, exactly
16:39:41 <adamw> pdc is triggering vague bells somewhere
16:39:52 <tflink> pdc?
16:39:54 <adamw> ahh, promise.
16:39:59 <tflink> oh, the device
16:40:04 <adamw> in the kickstart. yeah.
16:40:28 <tflink> isn't that technically HW RAID, then?
16:40:29 <adamw> mine is an intel controller, so pretty different.
16:40:30 <adamw> no
16:40:49 <tflink> then how is your setup HW RAID? Isn't it the same thing?
16:40:50 <adamw> it's just a particular brand of dumb motherboard bios raid
16:41:00 <adamw> i have both
16:41:14 <adamw> HW RAID controllers look to anaconda exactly like a SATA drive or something
16:41:14 * tflink is not completely convinced
16:41:26 <adamw> the kernel doesn't even know there's RAID involved, really. all it sees is a disk.
16:41:28 <tflink> but this doesn't need to be solved here
16:41:30 <adamw> so it shows up as /dev/sdX
16:41:37 <tflink> just like bios raid, no?
16:41:40 <adamw> no.
16:41:47 <adamw> BIOS RAID needs an OS driver.
16:42:06 <tflink> so does my fancy LSI RAID card
16:42:19 <adamw> anyhow
16:42:29 <adamw> this is definitely bios raid, not hardware raid. i'm right, just trust me. =)
16:42:34 <tflink> like I said, doesn't need to be figured out now
16:42:38 <adamw> even if it was hardware raid it'd be a blocker, so kinda academic.
16:42:51 <tflink> I'm not agreeing with your diagnosis, just tabling the discussion
16:42:56 <tflink> yep, exactly
16:42:57 <brunowolff> I think we should mark this +1 blocker and then reconsider if it turns out to be dependent on specific hardware.
16:43:01 <adamw> propose #agreed 806784 is a blocker per criterion "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:43:09 <brunowolff> ack
16:43:11 <tflink> ack
16:43:18 <adamw> even the criterion is the same =)
16:43:19 <j_dulaney> ack
16:43:23 <adamw> #agreed 806784 is a blocker per criterion "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:43:40 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=806466
16:43:47 <adamw> we're nearly done, btw.
16:44:13 <tflink> good, isn't fesco going to kick us out in a few minutes?
16:44:33 <adamw> i thought they go in like 1-2 hours, not now
16:44:49 <tflink> I thought that there was a meeting 2 hours after us
16:44:49 <adamw> oh,. no. you're right
16:44:51 <adamw> speed up!
16:45:07 <adamw> so anaconda writes an ifcfg file, but it says ONBOOT=no so the network doesn't come up after boot.
16:45:28 <kparal> history repeats itself
16:45:28 <limburgher> adaw: 15 minutes, though that's up for discussion.
16:45:38 <adamw> this combines with #806664 to be slightly icky, really.
16:46:00 <tflink> not sure this is blocker, regardless of how nice it might be to fix it
16:46:05 <adamw> but still, we're in about the same state we were with tc2, ironically, where you have to do 'dhclient' to get the network up. and we considered that nth.
16:46:14 <adamw> fixing either bug would make things better.
16:46:21 <adamw> i guess to be consistent we should probably take both as nth.
16:46:29 <tflink> yeah, I'd be OK with NTH
16:46:33 <j_dulaney> Nice to have, maybe, blocker, no
16:46:39 <adamw> okay, sounds like a consensus
16:46:44 <adamw> in the interests of time i'm gonna stop doing proposed
16:46:50 <bcl> hmm, I swear ifup eth0 working for me with a RC2 minimal install...
16:47:01 <brunowolff> NTH sounds reasonable
16:47:03 <adamw> #agreed 806466 is rejected as blocker but accepted as NTH (not serious enough to break any criteria)
16:47:10 <adamw> bcl: see, i thought so too, then i re-tested it, and it failed.
16:47:14 <adamw> bcl: try it again
16:47:34 <adamw> haha. the bugs are anagrams.
16:47:54 <adamw> #agreed 806664 is accepted as NTH while we're at it (both make ootb network behaviour somewhat icky)
16:48:12 <adamw> #topic Beta blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=804522
16:48:27 <adamw> this is a software RAID test case failure, hence seems solidly blockerish.
16:48:29 <kparal> adamw: how many more on the list?
16:48:47 <adamw> criterion "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot "
16:48:48 <tflink> +1
16:48:49 <adamw> i think this is the last.
16:49:06 <kparal> +1
16:49:08 <pschindl> +1
16:49:14 <adamw> we do have a couple more agenda items, though probably everyone's lost the will to live by now.
16:49:25 <adamw> #agreed 804522 is a blocker per beta criterion "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:49:26 <j_dulaney> +1 blocker
16:49:38 <adamw> okay, i think that's all the proposed. we don't have time to review the accepted
16:49:45 <adamw> lots for anaconda team to be getting on with :/
16:49:50 <adamw> i'll go through and secretaryize post-meeting.
16:49:58 <brunowolff> +1 blocker on 804522
16:50:14 <adamw> I propose we delay the 'project' status discussion to next week, we don't have time for it
16:50:18 <adamw> anyone object?
16:50:26 <j_dulaney> Nope
16:50:33 <brunowolff> That can wait.
16:50:45 <tflink> agreed
16:50:49 <adamw> #agreed agenda item "'Project' status" is tabled until next week due to lack of time and rapidly decreasing will to live
16:51:02 <adamw> #topic Test Day report
16:51:18 <adamw> so we had Sugar test day on 03-22 - https://fedoraproject.org/wiki/Test_Day:2012-03-22_Sugar_Desktop
16:51:45 <adamw> on the minus side only satellit_ and cerlyn showed up, on the plus side they did an incredible amount of work
16:51:57 <adamw> looks like a successful event by the 'results' yardstick
16:52:14 <j_dulaney> adamw:  I tested, too, but didn't put up my results
16:52:18 * j_dulaney needs to do so
16:52:20 <adamw> #info Sugar test day had low turnout - only satellit_ and cerlyn - but they achieved an impressive amount of testing
16:52:27 <adamw> #info j_dulaney also tested but has not yet filed results
16:52:31 <adamw> j_dulaney: thanks!
16:52:52 <adamw> oh, i see one result from Frederick Grose also.
16:53:06 <adamw> #topic upcoming QA events
16:53:20 <j_dulaney> I've got to bug out
16:53:22 <adamw> we have a couple of test days coming up this week - https://fedoraproject.org/wiki/Test_Day:2012-03-27_Kdump , https://fedoraproject.org/wiki/Test_Day:2012-03-29_Gnome_Shell_Software_Rendering
16:53:26 <j_dulaney> Time for class
16:53:38 <adamw> kdump test day needs its matrix extending but otherwise looks okay
16:53:50 <adamw> oh, they also copy/pasted 'live image' from the sugar test day and that needs fixing, heh
16:54:13 <adamw> shell test day has a note saying they'll get the test cases in by wed
16:54:24 <adamw> so those look like they're in hand, but we should get to publicity
16:54:51 <adamw> the go/no-go is set for wednesday, so lots of crazy blocker fixing and RC2 spinning needs to be done between now and then
16:54:57 <adamw> release readiness is thursday
16:55:05 <tflink> looks to be a wonderfully fun week!
16:55:19 <adamw> #info kdump and software rendering test days set for tuesday and thursday, both need some more prep but look to be broadly in hand
16:55:29 <adamw> #info go/no-go is wednesday (schedule) and release readiness is thursday
16:55:45 <adamw> okay, we have four minutes for a quick autoqa update
16:55:48 <adamw> #topic autoqa update
16:55:50 <adamw> tflink, kparal - go!
16:55:54 * mmaslano reminds FESCo meeting starts in 5 minutes
16:56:01 <kparal> for the sake of time
16:56:02 <kparal> no updates
16:56:05 <tflink> same here
16:56:06 <adamw> mmaslano: that's why i'm typing so frantically. =)
16:56:13 <adamw> kparal: what are we going to do with the other 3.5 minutes?!
16:56:20 <kparal> I can repeat it
16:56:26 * adamw lays down a beat
16:56:42 <adamw> no updates no updates. n-n-n-n-n-n-n-n-no-n-n-n-n updates-dates-dates.
16:56:50 <kparal> no. updates.
16:57:01 <adamw> #info the AutoQA news is, there is no news (for time reasons)
16:57:13 <adamw> #topic open floor
16:57:22 <adamw> and we have a whole 2.5 minutes for open floor
16:57:31 <adamw> any substantial discussions we can do in 2.5 minutes? anyone? bueller?
16:58:01 * Southern_Gentlem shoots the meeting and puts it out of its misery
16:58:09 <adamw> Southern_Gentlem: on behalf of everyone: thanks
16:58:40 * adamw sets fuse for 1 minute
16:59:00 * tflink sheds a tear for the poor QA meeting
16:59:30 <brunowolff> I was hoping for a beef miracle of no slip this release. That's going to be tough now.
16:59:38 <adamw> thanks for showing up and mostly surviving without permanent brain damage, folks
16:59:41 <adamw> brunowolff: never say die!
16:59:45 <adamw> brunowolff: also, blame wwoods.
16:59:48 <tflink> brunowolff: they don't call it a miracle for nothing :)
16:59:58 <adamw> #endmeeting