15:02:00 <adamw> #startmeeting Fedora QA Meeting
15:02:00 <zodbot> Meeting started Mon Oct 24 15:02:00 2011 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:01 * pschindl is here
15:02:03 <adamw> #meetingname fedora-qa
15:02:03 <zodbot> The meeting name has been set to 'fedora-qa'
15:02:11 <pschindl> good morning Adam
15:02:14 <adamw> damnit, no talking before I set meetingname! :)
15:02:15 * jskladan lurks in
15:02:16 <adamw> hey pschindl
15:02:24 <adamw> #chair kparal
15:02:24 <zodbot> Current chairs: adamw kparal
15:02:30 <adamw> #topic roll call
15:02:31 * jsmith lurks
15:02:32 <adamw> who's around?
15:02:35 * tflink is here
15:02:47 * adamw takes out a can of ACME Jsmith Repellent
15:02:50 * pschindl still here
15:02:54 * kparal is here
15:04:04 <tflink> adamw: wow, you made jsmith go away
15:04:07 * red_alert is here
15:04:23 <adamw> hey, that stuff really works!
15:04:38 * adamw points to ACME-branded product and grins at the camera
15:05:11 * Cerlyn is here
15:05:30 <adamw> alrighty, let's get this show on the road
15:05:37 <adamw> #topic previous meeting follow-up
15:05:39 <adamw> #chair tflink
15:05:39 <zodbot> Current chairs: adamw kparal tflink
15:05:56 <adamw> this is the part of the show where we find out what adam forgot to do last week!
15:05:59 * maxamillion is here
15:06:12 <adamw> "adamw to check with dgilmore where we are with x86_64 iso generation"
15:06:16 <adamw> welp, that got done
15:06:31 <adamw> (we eventually got x64 isos for TC1, and we got 'em on day 1 for TC2)
15:07:02 <adamw> aw, man, the jsmith came back
15:07:07 <adamw> "action adamw to co-ordinate with kernel team for final release build"
15:07:13 <jsmith> adamw: You can't get rid of me that easily....
15:07:15 <adamw> i did make 'em aware of the freeze date
15:07:27 <adamw> i'll check back in with them today to see what they're planning
15:07:33 <jsmith> There were plenty of announcements regarding the change freeze
15:07:59 <jwb> adamw, Chuck submitted the 3.1 final build to updates this morning
15:08:48 <adamw> jwb: awesome
15:08:53 <adamw> jsmith: yeah, but the personal touch always helps.
15:11:04 <adamw> okay, moving on
15:11:13 <adamw> #topic Fedora 16 Final preparation
15:11:30 <adamw> so we're aiming for RC tomorrow, which means we have a busy day's blocker squashin' coming up today
15:12:08 <robatino> http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html still says the 26th
15:12:20 <robatino> 57. 	Test 'Final' RC 	Wed 2011-10-26 	Tue 2011-11-01 	6
15:13:37 <adamw> that's when we *test* it
15:14:03 <adamw> http://rbergero.fedorapeople.org/schedules/f-16/f-16-releng-tasks.html says it gets composed tomorrow
15:14:09 <brunowolff> For the past topic, release kernel builds were done this monring. Unfortunately I had to leave for work before they fimished, but I'll be rebooting my work machine in a few minutes. (Before I head to a work meeting.)
15:14:24 <adamw> ah, and 'delivered' on 26th, so either someone thought we used fedex for rcs, or releng gets a whole day to build it. =)
15:14:42 <adamw> anyhoo
15:14:48 <adamw> let's do the blocker dance...
15:15:28 <adamw> let's not spend too much of this meeting on accepted blockers, but we have 6 proposed blockers to look at
15:15:42 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=747318
15:16:09 <adamw> charles claims to see this one on boot of tc2 live desktop; it does seem like a lot of people hit it, but i haven't yet on either of my systems
15:16:57 <tflink> yeah, I haven't seen that in a week or so on my installed F16
15:17:29 <adamw> i am worried at the number of people hitting it though
15:18:33 <kparal> according to our criteria seems like a blocker
15:18:42 <kparal> the question is how hard it will be to debug
15:18:47 <red_alert> some people seem to even hit it by merely booting the livecd :/
15:19:10 <kparal> can we somehow tell whether they are using gnome shell or fallback?
15:19:54 * adamw wonders if http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a33a74840f55e2d5e844f7491c27e23ff42c36c0 is the fix
15:20:30 <adamw> well, if it happens to some people but not all on a simple 'boot / use', then it becomes a judgement call, but yeah, seems like enough people hit it to make it a +1
15:22:03 <adamw> propose #agreed 747318 is a blocker under criterion "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)"
15:22:12 <tflink> ack
15:22:15 <kparal> ack
15:22:30 <red_alert> ack
15:22:42 <jskladan> ack
15:23:29 <adamw> #agreed 747318 is a blocker under criterion "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)"
15:23:33 <adamw> i'm poking desktop about it atm
15:23:35 <adamw> meanwhile...
15:23:47 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=743273
15:25:41 <kparal> I don't know much about RAIDs. Does Jen have a different RAID than you or pjones has?
15:25:41 <tflink> so neither adamw  nor pjones can repro this?
15:26:05 <adamw> i just added a comment to thus
15:26:10 <adamw> i think jes' latest test is clearly broken
15:26:18 <pjones> He just added some more stuff to it
15:26:25 <pjones> so apparently it has to be a raid1 and it has to be dirty
15:26:54 <pjones> which... I just don't know, I'm going to look at it more this afternoon and see if there's even anything we can do there.
15:27:03 <adamw> pjones: see my comment. i don't think his test could possibly have worked. he installed the bootloader to /boot then tried to boot straight from that disk. it's not going to fly.
15:27:36 <adamw> (unless i'm misunderstanding something)
15:28:06 <adamw> wdyt?
15:29:23 <pjones> I think it's pretty ingenuous to tell him "of course that's not going to work, do this other thing" when the other thing is something it won't let him do...
15:29:58 <tflink> pjones: won't the other thing work in TC2?
15:29:59 <adamw> pjones: hum? it should
15:30:23 <pjones> is he testing with an old tree or something, then?
15:30:36 <adamw> he *said* beta tc1, which is old as the hills
15:30:42 <tflink> according to his comment, Beta-TC1
15:30:42 <adamw> even if he *meant* final tc1, it changed in tc2
15:30:47 <adamw> see https://bugzilla.redhat.com/show_bug.cgi?id=744088
15:30:54 <adamw> that was fixed in anaconda 16.22, i.e., tc2
15:31:30 <pjones> okay, so we need him to test with a newer tree.
15:31:34 <pjones> can somebody tell him where to find that tree?
15:32:40 <adamw> will update.
15:33:09 <adamw> anyhow, ideally we'd want to punt on this, but...i think pjones is thinking that even if it was valid it might not be a blocker?
15:33:51 <pjones> well, it might be that in this situation you need to go into imsm and say "hey, fix the damned disk" before you continue.
15:34:01 <pjones> but I say "might" on purpose; I'll know more this PM
15:34:06 <adamw> okay
15:34:11 <adamw> we can punt till this afternoon at least
15:34:47 <adamw> propose #agreed 743273 is looking like a corner case and/or pilot error, but pjones hopes to know more this afternoon, so leave it until then
15:35:16 <tflink> ack
15:35:20 * kparal abstains
15:35:50 * adamw gets the ACME brand abstain remover
15:36:00 <kparal> ack
15:36:07 <red_alert> ack
15:36:28 <jsmith> ack
15:36:38 <adamw> #agreed 743273 is looking like a corner case and/or pilot error, but pjones hopes to know more this afternoon, so leave it until then
15:37:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=747982
15:37:26 <adamw> seems pretty straightforward +1 to me
15:37:36 <adamw> and it has a fix already, my favourite kind of blocker!
15:37:50 <tflink> +1
15:38:48 * kparal never used KDE 4, but AFAIUI it should be a blocker
15:40:43 <adamw> propose #agreed 747982 is a blocker per criterion "All elements of the default panel configuration in all release-blocking desktops must function correctly in common use"
15:40:57 <red_alert> ack
15:41:08 <tflink> ack
15:41:15 <kparal> ack
15:41:56 <jskladan> ack
15:42:01 <adamw> #agreed 747982 is a blocker per criterion "All elements of the default panel configuration in all release-blocking desktops must function correctly in common use"
15:42:10 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=748344
15:42:24 <adamw> so...this one's clearly *wrong*, but then, it's been that way forever. we shipped f15 like this and nothing exploded.
15:42:42 <adamw> it causes the live image to do a few things it shouldn't when booted EFI, but...i'm not convinced it's a blocker.
15:43:04 <kparal> it's just minor annoyance, but nothing horrible, right?
15:43:09 <kparal> or can it cause some problems?
15:43:17 <tflink> adamw: live images on USB, right? It sounds like syslinux does this properly
15:43:19 <adamw> it can cause problems, yeah, that's why we put those parameters in boot usually
15:43:43 <adamw> what they do is stop dracut trying to mount raid arrays and encrypted volumes that it finds on the system when booting live
15:44:27 <adamw> i think it can cause anaconda a few issues, and also, you might be booting live on a system which has an encrypted partition whose password you don't know...
15:44:39 <adamw> but i don't think it's really serious enough to make a blocker, overall. efi is still a pretty niche pursuit.
15:45:26 <kparal> I don't have overall idea what can go wrong, but otherwise I agree it seems not serious enough
15:45:42 <tflink> and you can work around in many cases by using a DVD/CD
15:45:43 <kparal> on the other hand, we can't fix this post-release
15:46:00 <kparal> or actually we can
15:46:10 <kparal> by updating livecd-to-disk tool
15:46:15 <tflink> yeah
15:46:33 <kparal> ok, severity--
15:46:46 <adamw> i think i'm +1 nth, -1 blocker on this one
15:46:57 <adamw> yeah, the update scenario is a point too
15:47:00 <kparal> agreed from me
15:47:25 <tflink> -1 blocker, +.5 NTH
15:48:05 <red_alert> -1 blocker, +1 NTH
15:48:20 <adamw> oh, yeah, update scenario does affect nth
15:48:41 <adamw> so...i think i'm -1 / -1 in that case, there's nothing to fix in the images themselves here
15:49:17 <kparal> but nth can be used to have fixed livecd-iso-to-disk in the final release
15:49:40 <Southern_Gentlem> so file a bugzilla on livecd-tools now
15:49:41 <kparal> but it doesn't really that much, I agree
15:49:43 <adamw> livecd-tools isn't even installed by default i don't think
15:49:51 <tflink> kparal: I don't think that livecd-to-iso is on the DVD, is it?
15:49:53 <kparal> *help
15:49:56 <adamw> Southern_Gentlem: this bug's already against livecd-tools
15:50:50 <adamw> so...
15:51:25 <adamw> propose #agreed 748344 rejectedblocker rejectednth: the impact of this one when you combine EFI plus RAID or encrypted partitions is small, and the fix is not on the image but in the image creation tool, so can be done safely as an update
15:51:30 <kparal> tflink: it seems they are not on DVD
15:51:36 <tflink> ack
15:51:52 <kparal> ack
15:51:58 <Southern_Gentlem> wrong http://mirror.cc.vt.edu/pub/fedora/linux/development/16/i386/os/Packages/livecd-tools-16.6-1.fc16.i686.rpm
15:52:20 <kparal> I was looking into the DVD.iso itself
15:52:34 <adamw> of course it's on mirrors.
15:52:40 <adamw> *everything's* on the mirrors.
15:53:08 <adamw> point is if we fix it as a 0-day update, there's no way you'd possibly get the release version from yum.\
15:53:32 <adamw> so it doesn't matter whether the fix is in the release package set, or a 0-day update: either works equallty well.
15:54:09 <adamw> #agreed 748344 rejectedblocker rejectednth: the impact of this one when you combine EFI plus RAID or encrypted partitions is small, and the fix is not on the image but in the image creation tool, so can be done safely as an update
15:54:54 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=744217
15:54:58 <adamw> so, this seems like a mess
15:55:02 <kparal> more raid :/
15:55:26 <adamw> well it's some fix dledford wants to get in
15:55:35 <adamw> but it seems to be a double clone so i've no idea where it ultimately comes from
15:55:37 <adamw> i really, really hate cloning.
15:56:17 <adamw> it could be somehow to do with the *other* remaining proposed blocker - https://bugzilla.redhat.com/show_bug.cgi?id=743022 - but i'm really not sure
15:57:47 <adamw> https://admin.fedoraproject.org/updates/mdadm-3.2.2-12.fc16 seems to describe the bugs pretty well, anyway
15:58:02 <adamw> based on those I'm +1 blocker under the RAID criterion or the 'workable partition layout' criterion
15:58:14 <adamw> seems like if your RAID array degrades Fedora will refuse to boot, which is not good.
15:58:33 <maxamillion> adamw: +1
15:59:29 <red_alert> +1 blocker
16:00:49 * jskladan needs to leave, see you around, gang!
16:01:18 * kparal agrees with anybody when raid is concerned
16:01:20 <adamw> propose #agreed 744217 is a blocker under 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 " combined with "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases)
16:01:20 <adamw> must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied"
16:01:40 <jsmith> ACK
16:01:52 <tflink> this mostly affects unhealthy RAID arrays, no?
16:02:01 <adamw> yes. but, that's kind of the point of RAID.
16:02:18 <adamw> if your system is going to fail to boot if your RAID array degrades that rather negates the point of having a RAID array in the first darn place =)
16:02:21 <red_alert> ack
16:02:50 <tflink> oh? I thought that the point of RAID was not to lose data as easily w/ HW error
16:03:09 <adamw> tflink: well yeah. but this makes it much harder than it needs to be to actually recover your data.
16:03:46 <adamw> a 'degraded' RAID array is what you get when one of the disks actually fails. (or just hiccups).
16:03:59 <adamw> so what you usually do is swap out the failed disk and boot in the 'degraded' state, and the array then rebuilds itself.
16:04:16 <adamw> if Fedora fails to boot in the degraded state...you have to boot up some other thing just to get the array to recover.
16:04:42 <tflink> point
16:04:43 <tflink> ack
16:05:34 <adamw> #agreed 744217 is a blocker under 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 " combined with "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must bo
16:05:34 <adamw> ot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied"
16:06:31 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=743022
16:06:38 <adamw> so this one just seems stuck, and the devs don't care about it much
16:06:48 <adamw> given that, and the description is f15->f16 yum update, i think we can just reject it now
16:07:03 <adamw> if it was a more serious issue, dledford/jes would give more of a damn...
16:08:12 <tflink> if it's limited to yum upgrade, -1 blocker
16:09:10 <adamw> yeah, -1 here
16:09:20 <kparal> same from me
16:09:54 <kparal> nth +1?
16:10:12 <maxamillion> nth +1, blocker -1
16:11:10 <adamw> not sure nth makes sense for a yum upgrade issue
16:11:21 <adamw> if you're doing a yum upgrade, you're getting updates
16:11:32 <tflink> yeah, maybe if it was all systems on yum upgrade
16:11:51 <kparal> ah, that's true
16:11:53 <red_alert> IMHO there has been progress from devs and jes sure was busy with the two RAID issues from before
16:12:08 <tflink> good point, I wasn't thinking about pulling in updates
16:12:16 <red_alert> (regarding "no one gives a damn")
16:12:30 <adamw> red_alert: sure, but they were busy with the other issue because they considered it more important
16:12:38 <adamw> which is kind of the point :)
16:13:46 <adamw> propose #agreed 743022 is not a blocker, only known to affect some yum upgrades, yum upgrade is not supported by the criteria
16:13:55 <adamw> let's get blocker status out of the way first
16:14:02 <tflink> ack
16:14:05 <red_alert> I thought blockers were about technical significance and not about priorities of reporters/devs
16:14:17 <kparal> ack
16:14:24 <jsmith> blockers are about release criteria
16:14:55 <red_alert> ack (-1 blocker +1 nth)
16:15:46 <adamw> red_alert: in this case, it's a good indication the bug isn't incredibly serious
16:15:51 <adamw> or else they'd have given it a higher priority
16:16:31 <adamw> propose #agreed 743022 is rejected NTH, as it affects yum upgrade, and when doing a yum upgrade, you'd always be pulling updates: so there's no benefit to pulling a fix through the freeze
16:16:43 <tflink> ack
16:17:04 <kparal> ack
16:17:49 <adamw> #agreed 743022 is rejected NTH, as it affects yum upgrade, and when doing a yum upgrade, you'd always be pulling updates: so there's no benefit to pulling a fix through the freeze
16:18:55 <adamw> okay, that's all the proposed blockers
16:19:11 <adamw> i think it'd be a bit of a waste to go through all the proposed NTH, but people can vote on them in the bugs
16:19:20 <adamw> https://fedoraproject.org/wiki/Current_Release_Blockers#Proposed_NICE-TO-HAVE is the list
16:19:33 <adamw> it'd be good to vote on all the modified/on_qa ones at least
16:19:52 <adamw> anyone have any other concerns for f16?
16:20:00 <adamw> #topic f16 final preparation
16:21:30 <adamw> well then, guess we can move on...
16:21:37 <adamw> do we have any news on the proventester or autoqa fronts?
16:21:40 <maxamillion> adamw: I noticed over the weekend that when I updated my kernel the new one didn't take default in grub2
16:22:00 <maxamillion> I meant to follow up with that ... but was busy with homework so didn't get around to it
16:22:19 * kparal has no autoqa update
16:22:46 <adamw> maxamillion: noted...keep an eye on it
16:23:24 <maxamillion> adamw: will do, I'll go check and see if its been reported yet
16:23:32 <adamw> i haven't seen that, it always works for me
16:23:37 <adamw> #topic open floor
16:23:40 <adamw> so, any other business?
16:26:39 <adamw> in that case, thanks for coming, everyone
16:26:41 <adamw> #endmeeting