15:02:00 #startmeeting Fedora QA Meeting 15:02:00 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:01 * pschindl is here 15:02:03 #meetingname fedora-qa 15:02:03 The meeting name has been set to 'fedora-qa' 15:02:11 good morning Adam 15:02:14 damnit, no talking before I set meetingname! :) 15:02:15 * jskladan lurks in 15:02:16 hey pschindl 15:02:24 #chair kparal 15:02:24 Current chairs: adamw kparal 15:02:30 #topic roll call 15:02:31 * jsmith lurks 15:02:32 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 adamw: wow, you made jsmith go away 15:04:07 * red_alert is here 15:04:23 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 alrighty, let's get this show on the road 15:05:37 #topic previous meeting follow-up 15:05:39 #chair tflink 15:05:39 Current chairs: adamw kparal tflink 15:05:56 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 to check with dgilmore where we are with x86_64 iso generation" 15:06:16 welp, that got done 15:06:31 (we eventually got x64 isos for TC1, and we got 'em on day 1 for TC2) 15:07:02 aw, man, the jsmith came back 15:07:07 "action adamw to co-ordinate with kernel team for final release build" 15:07:13 adamw: You can't get rid of me that easily.... 15:07:15 i did make 'em aware of the freeze date 15:07:27 i'll check back in with them today to see what they're planning 15:07:33 There were plenty of announcements regarding the change freeze 15:07:59 adamw, Chuck submitted the 3.1 final build to updates this morning 15:08:48 jwb: awesome 15:08:53 jsmith: yeah, but the personal touch always helps. 15:11:04 okay, moving on 15:11:13 #topic Fedora 16 Final preparation 15:11:30 so we're aiming for RC tomorrow, which means we have a busy day's blocker squashin' coming up today 15:12:08 http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html still says the 26th 15:12:20 57. Test 'Final' RC Wed 2011-10-26 Tue 2011-11-01 6 15:13:37 that's when we *test* it 15:14:03 http://rbergero.fedorapeople.org/schedules/f-16/f-16-releng-tasks.html says it gets composed tomorrow 15:14:09 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 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 anyhoo 15:14:48 let's do the blocker dance... 15:15:28 let's not spend too much of this meeting on accepted blockers, but we have 6 proposed blockers to look at 15:15:42 #topic https://bugzilla.redhat.com/show_bug.cgi?id=747318 15:16:09 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 yeah, I haven't seen that in a week or so on my installed F16 15:17:29 i am worried at the number of people hitting it though 15:18:33 according to our criteria seems like a blocker 15:18:42 the question is how hard it will be to debug 15:18:47 some people seem to even hit it by merely booting the livecd :/ 15:19:10 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 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 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 ack 15:22:15 ack 15:22:30 ack 15:22:42 ack 15:23:29 #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 i'm poking desktop about it atm 15:23:35 meanwhile... 15:23:47 #topic https://bugzilla.redhat.com/show_bug.cgi?id=743273 15:25:41 I don't know much about RAIDs. Does Jen have a different RAID than you or pjones has? 15:25:41 so neither adamw nor pjones can repro this? 15:26:05 i just added a comment to thus 15:26:10 i think jes' latest test is clearly broken 15:26:18 He just added some more stuff to it 15:26:25 so apparently it has to be a raid1 and it has to be dirty 15:26:54 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 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 (unless i'm misunderstanding something) 15:28:06 wdyt? 15:29:23 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 pjones: won't the other thing work in TC2? 15:29:59 pjones: hum? it should 15:30:23 is he testing with an old tree or something, then? 15:30:36 he *said* beta tc1, which is old as the hills 15:30:42 according to his comment, Beta-TC1 15:30:42 even if he *meant* final tc1, it changed in tc2 15:30:47 see https://bugzilla.redhat.com/show_bug.cgi?id=744088 15:30:54 that was fixed in anaconda 16.22, i.e., tc2 15:31:30 okay, so we need him to test with a newer tree. 15:31:34 can somebody tell him where to find that tree? 15:32:40 will update. 15:33:09 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 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 but I say "might" on purpose; I'll know more this PM 15:34:06 okay 15:34:11 we can punt till this afternoon at least 15:34:47 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 ack 15:35:20 * kparal abstains 15:35:50 * adamw gets the ACME brand abstain remover 15:36:00 ack 15:36:07 ack 15:36:28 ack 15:36:38 #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 #topic https://bugzilla.redhat.com/show_bug.cgi?id=747982 15:37:26 seems pretty straightforward +1 to me 15:37:36 and it has a fix already, my favourite kind of blocker! 15:37:50 +1 15:38:48 * kparal never used KDE 4, but AFAIUI it should be a blocker 15:40:43 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 ack 15:41:08 ack 15:41:15 ack 15:41:56 ack 15:42:01 #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 #topic https://bugzilla.redhat.com/show_bug.cgi?id=748344 15:42:24 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 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 it's just minor annoyance, but nothing horrible, right? 15:43:09 or can it cause some problems? 15:43:17 adamw: live images on USB, right? It sounds like syslinux does this properly 15:43:19 it can cause problems, yeah, that's why we put those parameters in boot usually 15:43:43 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 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 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 I don't have overall idea what can go wrong, but otherwise I agree it seems not serious enough 15:45:42 and you can work around in many cases by using a DVD/CD 15:45:43 on the other hand, we can't fix this post-release 15:46:00 or actually we can 15:46:10 by updating livecd-to-disk tool 15:46:15 yeah 15:46:33 ok, severity-- 15:46:46 i think i'm +1 nth, -1 blocker on this one 15:46:57 yeah, the update scenario is a point too 15:47:00 agreed from me 15:47:25 -1 blocker, +.5 NTH 15:48:05 -1 blocker, +1 NTH 15:48:20 oh, yeah, update scenario does affect nth 15:48:41 so...i think i'm -1 / -1 in that case, there's nothing to fix in the images themselves here 15:49:17 but nth can be used to have fixed livecd-iso-to-disk in the final release 15:49:40 so file a bugzilla on livecd-tools now 15:49:41 but it doesn't really that much, I agree 15:49:43 livecd-tools isn't even installed by default i don't think 15:49:51 kparal: I don't think that livecd-to-iso is on the DVD, is it? 15:49:53 *help 15:49:56 Southern_Gentlem: this bug's already against livecd-tools 15:50:50 so... 15:51:25 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 tflink: it seems they are not on DVD 15:51:36 ack 15:51:52 ack 15:51:58 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 I was looking into the DVD.iso itself 15:52:34 of course it's on mirrors. 15:52:40 *everything's* on the mirrors. 15:53:08 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 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 #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 #topic https://bugzilla.redhat.com/show_bug.cgi?id=744217 15:54:58 so, this seems like a mess 15:55:02 more raid :/ 15:55:26 well it's some fix dledford wants to get in 15:55:35 but it seems to be a double clone so i've no idea where it ultimately comes from 15:55:37 i really, really hate cloning. 15:56:17 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 https://admin.fedoraproject.org/updates/mdadm-3.2.2-12.fc16 seems to describe the bugs pretty well, anyway 15:58:02 based on those I'm +1 blocker under the RAID criterion or the 'workable partition layout' criterion 15:58:14 seems like if your RAID array degrades Fedora will refuse to boot, which is not good. 15:58:33 adamw: +1 15:59:29 +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 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 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 ACK 16:01:52 this mostly affects unhealthy RAID arrays, no? 16:02:01 yes. but, that's kind of the point of RAID. 16:02:18 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 ack 16:02:50 oh? I thought that the point of RAID was not to lose data as easily w/ HW error 16:03:09 tflink: well yeah. but this makes it much harder than it needs to be to actually recover your data. 16:03:46 a 'degraded' RAID array is what you get when one of the disks actually fails. (or just hiccups). 16:03:59 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 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 point 16:04:43 ack 16:05:34 #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 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 #topic https://bugzilla.redhat.com/show_bug.cgi?id=743022 16:06:38 so this one just seems stuck, and the devs don't care about it much 16:06:48 given that, and the description is f15->f16 yum update, i think we can just reject it now 16:07:03 if it was a more serious issue, dledford/jes would give more of a damn... 16:08:12 if it's limited to yum upgrade, -1 blocker 16:09:10 yeah, -1 here 16:09:20 same from me 16:09:54 nth +1? 16:10:12 nth +1, blocker -1 16:11:10 not sure nth makes sense for a yum upgrade issue 16:11:21 if you're doing a yum upgrade, you're getting updates 16:11:32 yeah, maybe if it was all systems on yum upgrade 16:11:51 ah, that's true 16:11:53 IMHO there has been progress from devs and jes sure was busy with the two RAID issues from before 16:12:08 good point, I wasn't thinking about pulling in updates 16:12:16 (regarding "no one gives a damn") 16:12:30 red_alert: sure, but they were busy with the other issue because they considered it more important 16:12:38 which is kind of the point :) 16:13:46 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 let's get blocker status out of the way first 16:14:02 ack 16:14:05 I thought blockers were about technical significance and not about priorities of reporters/devs 16:14:17 ack 16:14:24 blockers are about release criteria 16:14:55 ack (-1 blocker +1 nth) 16:15:46 red_alert: in this case, it's a good indication the bug isn't incredibly serious 16:15:51 or else they'd have given it a higher priority 16:16:31 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 ack 16:17:04 ack 16:17:49 #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 okay, that's all the proposed blockers 16:19:11 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 https://fedoraproject.org/wiki/Current_Release_Blockers#Proposed_NICE-TO-HAVE is the list 16:19:33 it'd be good to vote on all the modified/on_qa ones at least 16:19:52 anyone have any other concerns for f16? 16:20:00 #topic f16 final preparation 16:21:30 well then, guess we can move on... 16:21:37 do we have any news on the proventester or autoqa fronts? 16:21:40 adamw: I noticed over the weekend that when I updated my kernel the new one didn't take default in grub2 16:22:00 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 maxamillion: noted...keep an eye on it 16:23:24 adamw: will do, I'll go check and see if its been reported yet 16:23:32 i haven't seen that, it always works for me 16:23:37 #topic open floor 16:23:40 so, any other business? 16:26:39 in that case, thanks for coming, everyone 16:26:41 #endmeeting