16:00:25 <tflink> #startmeeting f20beta-blocker-review-2 16:00:25 <zodbot> Meeting started Wed Oct 2 16:00:25 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:25 <tflink> #meetingname f20beta-blocker-review-2 16:00:25 <zodbot> The meeting name has been set to 'f20beta-blocker-review-2' 16:00:25 <tflink> #topic Roll Call 16:00:32 * dan408 waves 16:00:36 * roshi is here 16:00:44 * kparal prepares dinner 16:00:45 <tflink> kparal: we're not a SMTP server :-/ 16:00:58 <dan408> you had me at ehlo 16:01:00 * cmurf is present 16:01:09 * Viking-Ice sharpens his ax now let's slice down those blockers ;) 16:01:14 <kparal> tflink: sorry, sometimes I get confused who I'm talking to 16:01:18 * mkrizek is here 16:01:21 <tflink> kparal: ouch 16:01:27 * pschindl is here 16:01:33 <tflink> any volunteers for secretary duty? 16:01:46 * pwhalen is here 16:01:52 * kparal points at... someone else :) 16:02:03 <tflink> kparal: I hear a volunteer 16:02:39 <roshi> I got it :) 16:02:49 <roshi> unless kparal really wants it :p 16:03:02 <kparal> phew, no thanks :) 16:03:52 <tflink> looks like we have enough people, time for some boilerplate! 16:03:59 <tflink> adamw: you around for blocker meeting fun time? 16:04:09 <tflink> #topic Introduction 16:04:14 <tflink> Why are we here? 16:04:14 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and freeze exception bugs. 16:04:18 <cmurf> it's cocktail hour where adam is 16:04:19 <tflink> #info We'll be following the process outlined at: 16:04:19 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:04:29 <tflink> #info The bugs up for review today are available at: 16:04:29 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current 16:04:30 <dan408> 9am 16:04:35 <tflink> #info The criteria for release blocking bugs can be found at: 16:04:35 <tflink> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria 16:04:40 <kparal> Beta 16:04:41 <tflink> #info Up for review today, we have: 16:04:45 <tflink> bah 16:04:47 <tflink> #undo 16:04:47 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x50462f10> 16:04:49 <tflink> #undo 16:04:49 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x249f4950> 16:05:01 <tflink> link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria 16:05:06 <tflink> #info Up for review today, we have: 16:05:13 <tflink> #chair kparal adamw roshi 16:05:13 <zodbot> Current chairs: adamw kparal roshi tflink 16:05:25 * handsome_pirate waves 16:05:34 <tflink> #info 9 Proposed Blockers 16:05:34 <tflink> #info 7 Accepted Blockers 16:05:34 <tflink> #info 1 Proposed Freeze Exceptions 16:05:35 <tflink> #info 4 Accepted Freeze Exceptions 16:05:50 <tflink> if there are no objections, we'll start with the proposed blockers 16:06:35 <cmurf> noobjections go 16:06:44 <tflink> #topic (1009809) KeyError: 'name' 16:06:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009809 16:06:44 <tflink> #info Proposed Blocker, anaconda, ON_QA 16:07:22 <handsome_pirate> Wow 16:07:42 <handsome_pirate> No DNS for bugzilla 16:08:05 <kparal> I guess I should have tested this one with repo=nfs:, right? 16:08:16 <cmurf> OK so I think the question for this bug is whether or not there is at least one NFS method that's working. 16:08:22 <kparal> feel free to needinfo me next time 16:08:39 <handsome_pirate> Ah, there it goes 16:08:45 <tflink> yeah, punt I think unless someone's tried it for beta 16:09:04 <kparal> I didn't. so punt and maybe it will get closed once TC1 is out 16:09:07 <cmurf> And maybe it needs retesting with anaconda 20.21-1 as it might have been a bug in there 16:09:08 * handsome_pirate is +1 punt 16:09:09 <kparal> and anaconda is stable 16:09:10 <cmurf> so yea punt 16:09:43 <dan408> +1 16:09:44 <tflink> proposed #agreed 1009809 - This still needs testing to see if at least 1 of nfs/nfsiso works - will revisit once that testing has been done 16:10:03 <roshi> ack 16:10:06 <dan408> ack 16:10:06 <kparal> ack 16:10:07 <cmurf> ack 16:10:10 <tflink> #agreed 1009809 - This still needs testing to see if at least 1 of nfs/nfsiso works - will revisit once that testing has been done 16:10:10 <Viking-Ice> ack 16:10:16 <tflink> topic (1012504) FSError: filesystem already exists 16:10:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012504 16:10:16 <tflink> #info Proposed Blocker, anaconda, ASSIGNED 16:10:42 <cmurf> The bottom line here is that the installer sometimes creates a btrfs file system and then later tries to reformat it ext4 and then crashes. 16:10:43 <tflink> another reason to get the new blockerbugs version put in production - this damn sort order bug :-/ 16:11:02 <cmurf> +1 blocker 16:11:13 <handsome_pirate> +1 blocker 16:11:13 <dan408> odd. I havent had any issues with partitioning since custom partitioning was fixed 16:11:46 <dan408> can you provide some more steps to reproduce? 16:11:51 <cmurf> it is transient but dlehman knows were the problem is 16:11:55 <dan408> this happens on dvd and netinst? 16:12:26 <dan408> and how did you get back to partition screen after install started? 16:12:36 <tflink> yeah, +1 16:12:45 <Viking-Ice> +1 16:13:01 <roshi> +1 16:13:09 <tflink> proposed #agreed 1009809 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs autopart: "Complete an installation using any combination of disk configuration options it allows the user to select" 16:13:12 <cmurf> testing has been done with desktop; i did not get back to partition screen after i started the install, the installer itself for some reason decides to spuriousy reformat a btrfs volume as ext4 16:13:14 <handsome_pirate> ack 16:13:15 <dan408> ack 16:13:17 <cmurf> ack 16:13:17 <Viking-Ice> ack 16:13:24 <roshi> ack 16:13:29 <dan408> cmurf: oh ok 16:13:39 <tflink> cmurf: this was with autopart, no? 16:13:47 <dan408> manual 16:13:54 <adamw> sorry, folks, just got here 16:13:55 <cmurf> it has happened with autopart and with custom but the bug as reported is manual 16:14:02 <adamw> f20 exploded messily today 16:14:16 <dan408> so this is after going through the parititoning a few times 16:14:21 <dan408> which I can see crashing 16:14:36 <tflink> bah, i got the criterion wrong, then 16:14:59 <dan408> im sure if you go through it 3 or 4 times it might crash 16:15:07 <cmurf> yes, in the orginal description the user was behaving erratically, but that's not required to trigger this bug 16:15:34 <dan408> you can trigger it on 1 time partitioning? 16:15:43 <cmurf> yes 16:15:52 <cmurf> again it's transient it doesn't always happen 16:15:59 <tflink> proposed #agreed 1009809 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes ..." 16:16:13 * Viking-Ice throws ack in there 16:16:19 <cmurf> ack 16:16:26 <tflink> roshi: you'll probably want to quote more of the criterion than I did - there are length restrictions to lines in irc 16:16:36 * roshi nods 16:16:38 <roshi> ack 16:16:45 <dan408> ack 16:16:57 <tflink> #agreed 1009809 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes ..." 16:17:01 <roshi> that's the wrong bug number 16:17:07 <roshi> 1012504 16:17:32 <tflink> huh, did I not change topic or is zodbot being slow 16:17:33 <tflink> ? 16:17:35 <tflink> #undo 16:17:35 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x29fc7590> 16:17:54 <tflink> #agreed 1012504 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes ..." 16:18:07 <tflink> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device 16:18:08 <roshi> you were missing "#" methinks when you set the topic 16:18:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495 16:18:13 <tflink> #info Proposed Blocker, anaconda, POST 16:18:20 <tflink> meetbot fail! 16:19:05 <tflink> huh, I didn't think this one would be fixed 16:19:12 <cmurf> Mac EFI bug has a fix that works for me. I'd say making this blocking is a precident setting thing. So it's legit to punt on this. 16:19:16 <adamw> i think it turned out not to be the bug bcl thought it was 16:19:18 <Viking-Ice> no neither did I 16:19:36 <adamw> cmurf: it's not really a precedent setting thing, we were supposed to be blocking on macs now, at least that was my understanding 16:19:45 <cmurf> OK I didn't know that. 16:19:46 <adamw> we used to have wording that explicitly excepted them from the criteria and then we took it out 16:19:48 <tflink> yeah, same here 16:19:48 <Viking-Ice> but let's accept it and pull the fix in 16:19:50 <cmurf> So in that case it's a clear +1 bocker. 16:19:54 <tflink> +1 16:19:57 <Viking-Ice> +1 16:19:58 <cmurf> bLocker 16:19:59 <adamw> Viking-Ice: we're not frozen anyhow, so it's kinda academic 16:19:59 <handsome_pirate> +1 blocker 16:20:11 <adamw> i'm +1 blocker for now, though, we can always fight about it in future if it becomes necessary 16:20:15 <roshi> +1 16:20:35 <dan408> +1 16:20:55 <cmurf> adamw: have you experinced fighting with a fellow word fountain? like watching two water buffalo drown. 16:21:24 <tflink> bah, criterion? 16:21:40 <adamw> haha. 16:21:57 <kparal> ESP stands for? 16:22:05 <cmurf> EFI System Partition 16:22:06 <adamw> EFI system partition 16:22:09 <kparal> thx 16:22:21 <cmurf> we don't have any EFI/UEFI related beta criteria.... 16:22:25 <cmurf> ? 16:22:32 <cmurf> or are they just implied 16:22:44 <kparal> implied 16:23:01 <tflink> implied, IIRC we only explicitly require the images to boot 16:23:16 <adamw> we can call it a conditional violation of "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation " 16:23:20 <adamw> (for guided partitioning) 16:23:31 <cmurf> yes 16:23:46 <dan408> ms dos?? 16:23:48 <adamw> cmurf: we don't have any BIOS criteria either. ;) 16:23:53 <adamw> dan408: it's a disk label format. 16:23:57 <tflink> that's better than what I was coming up with :) 16:24:19 <cmurf> for custom partitioning, i think it's the 2nd bullet 16:24:20 <dan408> is that the same as MBR? 16:24:23 <tflink> proposed #agreed 1010495 - AcceptedBlocker - Violates the following F20 beta release criterion for EFI system partitions on apple hardware: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation" 16:24:24 <Viking-Ice> ack 16:24:26 <adamw> dan408: it's a more accurate term. 16:24:28 <dan408> ack 16:24:32 <dan408> adamw: 16:24:33 <dan408> k 16:24:46 <adamw> dan408: an MBR is something that usually (but not always) exists on an msdos-labelled disk. 16:24:47 <kparal> ack 16:24:48 <cmurf> ack 16:25:01 <cmurf> MBR = MSDOS disklabel 16:25:03 <tflink> #agreed 1010495 - AcceptedBlocker - Violates the following F20 beta release criterion for EFI system partitions on apple hardware: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation" 16:25:15 <tflink> #topic (1013800) devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool 16:25:18 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013800 16:25:21 <tflink> #info Proposed Blocker, anaconda, NEW 16:25:34 <cmurf> The MBR bootstrap region is a 440 byte section of the MBR. 16:25:40 <adamw> cmurf: if you look at the Alpha 'images must boot' criterion's notes, there's a 'supported firmware types' one which says 'Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures.' - that's what makes UEFI covered. 16:25:53 <cmurf> adamw got it thanks 16:25:54 <Viking-Ice> do we have any criteria that covers thinp? 16:26:10 <tflink> no, but we do have on ethat covers all offered partition types 16:26:12 <adamw> it probably comes in the 'no errors' bit of the partitioning criteria 16:26:19 <tflink> and lvm thinp is offered for autopart 16:26:39 <adamw> or better, "Complete an installation using any combination of disk configuration options it allows the user to select " 16:26:41 <cmurf> yeah if it's offered, it has to work, or the offer needs to be removed - is my view 16:26:42 <Viking-Ice> autoblocker then 16:26:42 <tflink> "Complete an installation using any combination of disk configuration options it allows the user to select " 16:26:46 <adamw> (referring to Guided Partitioning" 16:26:48 <adamw> yup, that one. 16:26:48 <tflink> bah, not fast enough 16:26:59 <adamw> i.e. if one of the paths guided offers is just busted, we're blocking. so, if that's what this bug is, +1 16:27:18 <Viking-Ice> +1 16:27:21 <roshi> +1 16:27:23 <kparal> +1 16:27:25 <tflink> proposed #agreed 1013800 - AcceptedBlocker - Violates the following F20 beta release criterion for LVM thinp: "Complete an installation using any combination of disk configuration options it allows the user to select" 16:27:28 <cmurf> ack 16:27:30 <roshi> ack 16:27:38 <adamw> tflink: maybe add the first half of the criterion, but sure 16:27:51 <kparal> ack 16:28:01 <Viking-Ice> ack 16:28:06 <handsome_pirate> ack 16:28:07 <tflink> proposed++ #agreed 1013800 - AcceptedBlocker - Violates the following F20 beta release criterion for LVM thinp: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select" 16:28:14 <tflink> #agreed 1013800 - AcceptedBlocker - Violates the following F20 beta release criterion for LVM thinp: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select" 16:28:24 * tflink can undo if there are objections to the change 16:28:39 <tflink> #topic (1013586) SizeNotPositiveError: spec= param must be >=0 16:28:39 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013586 16:28:39 <tflink> #info Proposed Blocker, anaconda, NEW 16:28:57 <cmurf> I've added a needinfo here 16:29:36 <kparal> cmurf: what is "for OP"? 16:29:49 <tflink> original poster 16:29:55 <kparal> ah, that's me! 16:29:56 <tflink> poster, using forum speak :) 16:30:03 <tflink> poster/reporter 16:30:09 <cmurf> my juvenile forum vernacular 16:30:10 <tflink> me use words good 16:30:22 <Viking-Ice> me uses words that resemble english 16:30:23 <kparal> cmurf: right, I haven't seen the error with a disk layout created by windows installer 16:30:31 <kparal> it might be a good idea to try more partitioning tools 16:30:50 <Viking-Ice> punt for testing and more data ? 16:30:58 <roshi> +1 punt 16:31:02 <cmurf> it might be that it's just inducing an existing bug that needs to be fixed 16:31:03 <cmurf> +1 punt 16:31:15 <cmurf> so it may still be a blocker 16:31:16 <tflink> I'm not against the idea but I'd be suprised if it was a gnome-disks issue 16:31:21 <kparal> so, if it turns out to be a gnome-disks problem, is it not a blocker? 16:31:37 <tflink> more borderline 16:31:38 <Viking-Ice> I would not think so 16:31:41 <kparal> gnome-disks is likely to be used by people to adjust the disk layout before installation 16:31:46 <Viking-Ice> ? 16:31:56 <kparal> well, I do it sometimes 16:32:05 <kparal> it's much easier in gnome-disks than in anaconda 16:32:05 <cmurf> kparal: exactly so the exact nature of the problem needs to be better understood 16:32:13 * jreznik is finally around 16:32:14 <tflink> creation != modification, though 16:32:35 <Viking-Ice> kparal, we could pull it in as an fe if it's DE app breakage but not a blocker 16:32:38 <tflink> i can't really think of a situation where someone would create a ntfs partition pre-install with gnome-disks 16:32:51 <cmurf> i think it depends on the problem 16:32:53 <kparal> tflink: it happens with ext4 as well 16:33:01 <Viking-Ice> anywho we all agree to punt 16:33:05 <tflink> ah ... details 16:33:06 <tflink> yeah 16:33:14 <kparal> give me a minute, I'll try gparted 16:33:17 <cmurf> if we find out that gnome-disks calls ntfs-3g and it's making a bad NTFS volume, I'd say that ought to be blocking, it's a forum of corruption 16:33:30 <cmurf> anyway more testing is needed 16:33:32 <Viking-Ice> if not used by the installer not blocked 16:33:44 <tflink> proposed #agreed 1013586 - We need more information and testing to figure out how common this failure mode is. will re-visit once more testing has been done. 16:33:47 <Viking-Ice> ack 16:33:50 <kparal> cmurf: it happens with ext4 as well 16:33:56 <cmurf> interesting 16:34:11 * kparal installing gparted on live 16:34:14 <roshi> ack 16:34:25 <cmurf> it might be triggered due to the fact the volume has no files on it 16:34:26 <tflink> ack/nak/patchk? 16:34:47 <cmurf> we need to hear from dlehman what he thinks triggers this 16:34:51 <kparal> a sec 16:34:54 <cmurf> ack 16:35:03 <tflink> #agreed 1013586 - We need more information and testing to figure out how common this failure mode is. will re-visit once more testing has been done. 16:35:17 <kparal> interesting, with gparted-created partition it didn't crash 16:35:22 <cmurf> hmmm 16:35:38 <kparal> already agreed, let's move on 16:35:42 <tflink> #topic (1012646) anaconda creates grub.cfg lacking an initrd entry, kernel panics on reboot 16:35:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012646 16:35:47 <tflink> #info Proposed Blocker, anaconda, ASSIGNED 16:35:53 <cmurf> ok hold on this on for a sec 16:36:16 <cmurf> 1012646 and 864198 are related; it's either one or the other that's the blocker 16:36:35 <adamw> reading 16:36:37 <cmurf> anaconda creates a grub.cfg before the initrd is made 16:36:51 <cmurf> then grubby fixes the grub.cfg after the initrd is made 16:36:54 <Viking-Ice> anaconda should just install and use gummiboot instead of grub on efi ;) 16:36:57 <cmurf> so i think 1012646 is NOT a blocker 16:37:01 <cmurf> and probably not a bug 16:37:01 <adamw> UEFI specific? 16:37:04 <cmurf> no 16:37:15 <cmurf> i think the ultimate bug and blocker is 864198 16:37:20 <tflink> btrfs specific, though? 16:37:25 <cmurf> yes 16:37:31 <cmurf> specifically boot on btrfs 16:37:40 <tflink> do we want to do 864198 first, then? 16:37:42 <cmurf> which is only possible through Manual Partitioning 16:37:46 <cmurf> that's reasonable 16:38:08 <tflink> or reject this one? 16:38:12 <adamw> reject this, i think 16:38:15 <cmurf> 1012646 was filed before i thought of the ancient 864198 bug 16:38:19 <Viking-Ice> is not btrfs still flag experimental ? 16:38:22 <adamw> anaconda isn't running grub2-mkconfig to create a live config file 16:38:24 <Viking-Ice> yeah reject 16:38:31 <adamw> it's running grub2-mkconfig to make grub2-install work 16:38:53 <adamw> or, hmm. maybe i'm misremembering... 16:38:54 <cmurf> adamw: it appears to run it because grubby can't make the whole grub.cfg 16:39:10 <Viking-Ice> <shrug> grubby is so utterly broken 16:39:17 <cmurf> and grubby would puke if there wasn't a basic grub.cfg in place 16:39:18 <tflink> proposed #agreed 1012646 - RejectedBlocker - This is a problem but the actual bug is in grubby, not anaconda and in this case, anaconda is behaving as expected 16:39:22 <Viking-Ice> ack 16:39:27 <adamw> i think that's close enough for now 16:39:28 <cmurf> ack 16:40:11 <roshi> ack 16:40:26 <tflink> #agreed 1012646 - RejectedBlocker - This is a problem but the actual bug is in grubby, not anaconda and in this case, anaconda is behaving as expected 16:40:43 <tflink> #topic (1013087) selection of rescue kernel causes kernel panic, due to lack of initramfs 16:40:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013087 16:40:48 <tflink> #info Proposed Blocker, anaconda, NEW 16:41:42 <dan408> +1 16:41:44 <cmurf> ok so weirdly this problem is masked for most people because when they reboot the primary (non-rescue) kernel and do a yum update, new-kernel-pkg for an updated kernel also somehow calls dracut to write out an initramfs for the rescue kernel 16:42:07 <cmurf> but if you use the rescue kernel grub menu option before a yum update, you get a kp 16:42:14 <cmurf> so yeah +1 16:42:26 <dan408> so this wouldnt affect netinstall would it? just live media and dvd? 16:42:44 <cmurf> i don't know, does netinstal install a rescue kernel? 16:42:45 <kparal> I thought that anaconda was calling dracut --regenerate-all at the end of the installation 16:42:59 <kparal> dan408: all media install a rescue kernel, just cloud media don't contain it afaik 16:43:03 <Viking-Ice> is the dracut-config-rescue package installed ? 16:43:06 <cmurf> kaparl: no it appears anaconda calls new-kernel-pkg and it calls dracut 16:43:19 <adamw> do we actually require the rescue kernel to work for any reason? 16:43:25 <tflink> what criteria does this violate? 16:43:26 <cmurf> viking: oh that's a good point this could be a dracut bug not anaconda 16:43:38 <dan408> kparal: i was just wondering because netinstall is an updated installation, so after finishing a netinstall a yum update wouldnt do anything 16:43:40 <Viking-Ice> tflink, none I think 16:43:43 <adamw> i don't think this clearly does violate one 16:43:57 * roshi doesn't see one 16:43:57 <adamw> the rescue kernel is basically a non-system-specific kernel, right? 16:44:00 <tflink> if you're really in trouble, you can use the rescue mode on iso 16:44:01 <cmurf> seems like a problem for the rescue kernel to crash haha 16:44:04 <adamw> so it's for if you change the system hardware drastically 16:44:04 <Viking-Ice> -1 reject that sucker 16:44:17 <kparal> adamw: yes 16:44:22 <cmurf> well wait 16:44:22 <adamw> nice feature, i guess, but i don't see that it violates the criteria (though it does obviously look bad if you try it out) 16:44:27 <kparal> I'd say this should be a final blocker. not sure about beta 16:44:28 <tflink> cmurf: I'm not saying it isn't a bug; just that it isn't a release blocking issue :) 16:44:29 <cmurf> it crashes unti you can update 16:44:32 <adamw> still, i'm happy with -1 for beta unless i missed something 16:44:44 <Viking-Ice> adamw, when you need it your system is screwed anyway ;) 16:44:46 <tflink> cmurf: you can work around it, though 16:44:55 <kparal> anaconda rescue mode has to work, I see no reason why we should not require rescue kernel to work as well 16:44:58 <kparal> it's just a new thing 16:44:58 <dan408> -1 for beta then, I think it should be fixed by final though 16:45:07 <kparal> what milestone is anaconda rescue mode in? 16:45:15 <tflink> alpha 16:45:20 <cmurf> hmm seems reasonable that it works for final and not beta 16:45:29 <kparal> I think this should be alpha as well then 16:45:39 <Viking-Ice> does not anaconda rescue mode work ( which most likely is then due to that missing dracut config rescue stuff ) 16:45:44 <tflink> proposed #agreed 1013087 - RejectedBlocker - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a release blocking issue for f20 beta 16:45:45 <kparal> but we might want to reconsider rescue mode in general 16:45:48 <Viking-Ice> ack 16:45:52 <cmurf> but the thing is, it prevents testing for beta to be unable to boot the rescue kernel just due to a lack of an initramfs 16:45:57 <dan408> ack 16:46:06 <Viking-Ice> kparal, we need to reconsider the entire concept of rescue mode 16:46:14 <dan408> +1 Viking-Ice 16:46:24 <kparal> I see several examples where only the rescue kernel worked, because there were some modules missing in normal initrd due to hostonly mode 16:46:31 <kparal> *I saw 16:46:46 * Viking-Ice does not use initrd 16:46:48 <cmurf> if anything the rescue kernel should be the sure fire one that works in case dracut made the smaller initramfs for the system wrong and it can't boot 16:46:59 * dan408 doesnt bother with rescue mode 16:47:01 <kparal> so if we reject this, I believe we should add a note that we will adjust the criteria before final 16:47:07 <Viking-Ice> why 16:47:11 <tflink> we will? 16:47:17 <kparal> I would 16:47:27 <kparal> I just propose it, of course 16:47:33 <tflink> what does the rescue mode solve that can't be solved w/ anaconda rescue mode? 16:47:44 <dan408> nothing 16:47:47 <kparal> hmm, it actually boots a working system 16:47:51 <cmurf> i have one computer and no install disk because i travel with a laptop? 16:47:55 <tflink> sure, it looks really bad if rescue mode crashes if initial boot fails 16:48:01 <cmurf> and i can't make an install disk because i can't boot? 16:48:15 <cmurf> there's a simple fix here 16:48:20 <tflink> cmurf: how did you install, then? 16:48:31 <cmurf> i'm proposing a scenario not reality 16:48:32 <dan408> chicken, meet egg 16:48:36 <cmurf> no 16:48:39 <cmurf> not at all 16:48:43 <tflink> if I'm understanding correctly, the rescue initramfs will be generated on first kernel upgrade 16:48:43 <adamw> note, all current references to the 'rescue mode' in the criteria are talking about the one on the install media 16:48:46 <kparal> I believe rescue mode should be in our criteria, both anaconda and system rescue 16:48:56 <adamw> this 'rescue kernel' is something new since, iirc, f19, the criteria do not consider it explicitly at all 16:49:02 <Viking-Ice> kparal, not system rescue 16:49:03 <kparal> adamw: because the rescue kernel is a new thing 16:49:06 <adamw> yes 16:49:08 <cmurf> yes 16:49:14 <kparal> so, let's add it 16:49:14 <Viking-Ice> installer yes local no 16:49:29 <tflink> I still don't see why this should be a release blocking issue 16:49:42 <cmurf> whether the rescue kernel criteria says it should work by final or beta isn't a hill i'll die on 16:49:43 <tflink> if you haven't upgraded kernel since install, you probably have the image around 16:49:48 <cmurf> but it should work by final or it's just silly 16:49:50 <cmurf> remove it 16:49:58 <adamw> yeah, i'm still with tflink on this one 16:50:02 <Viking-Ice> as am I 16:50:06 <kparal> ok 16:50:11 <dan408> I see his view 16:50:31 <adamw> i haven't seen the cases he's seen, where hostonly has really tripped people up in 'normal use' 16:50:31 <dan408> but im -1 16:50:32 <tflink> I agree that it should be fixed and would consider FE 16:50:38 <cmurf> i install the system, i walk out the door for a flight, i have no media, and i'm stuck on a plan for 8 hour without a bootable computer 16:50:39 <adamw> dan408: er. tflink is -1. 16:50:45 <dan408> yeah 16:50:48 <dan408> as am i 16:50:57 <dan408> I have learned not to rely on rescue mode 16:50:59 <cmurf> i don't think we get involved in people's install workflows. the rescue kernel should work the question is when, beta or final. 16:51:05 <adamw> cmurf: if you install the system and the hostonly initrd doesn't work, then that is the blocking bug, not this. 16:51:20 <kparal> there are better reasons. you don't know what is wrong, the system doesn't boot, but with rescue mode it boots. that helps you _a lot_. you can't have this with anaconda rescue 16:51:21 <adamw> hostonly initrd should only ever be a problem if you change the hardware in the system. 16:51:22 <tflink> cmurf: I'm not sure you would be much better off with rescue mode in the airplane situation 16:51:48 <adamw> tflink: the rescue kernel does not put you in a 'rescue mode'. it puts you in a regular system. aiui, anyhow. 16:52:14 <cmurf> the rescue kernel and initramfs ought to be essentially the same thing as on the install media 16:52:20 <Viking-Ice> let's move on 16:52:28 <cmurf> all the more reason why i'm not sure why ther isn't an initramfs already present 16:52:29 <tflink> how about this: we reject for beta and if kparal/cmurf want to propose criteria changes - that can be discussed on the list 16:52:31 <kparal> adamw: I have seen several examples where hostonly was a problem without changing hardware. benl was one of the "victims". unfortunately it could not be reproduced 16:52:41 <cmurf> yes fine, move on 16:52:45 <adamw> we should probably thrash this out and have the discussion about whether we should explicitly or implicitly require the rescue kernel to work at any point, but maybe in this meeting isn't the time... 16:52:52 <kparal> cmurf: please repropose for Final blocker 16:52:58 <adamw> kparal: well, i think we'd want some solid data for that. at least, bug #s. 16:53:03 <Viking-Ice> adamw, qa meetign 16:53:06 <adamw> Viking-Ice: or list 16:53:10 <tflink> #agreed 1013087 - RejectedBlocker - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a release blocking issue for f20 beta 16:53:17 <Viking-Ice> ack 16:53:29 <cmurf> ack 16:53:35 <tflink> #topic (1013767) rootfs on thinp not found, startup failure 16:53:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013767 16:53:35 <tflink> #info Proposed Blocker, dracut, NEW 16:54:44 <tflink> so we have bugs on thinp failing during install and post-install? 16:54:50 <cmurf> yes 16:55:03 <tflink> nice to see new features working well :) 16:55:05 <cmurf> altough the thinp install bug is probably fixed by new blivet which is how i was able to get it to install to triggerthis bug 16:55:21 <Viking-Ice> which in turn might fix this ( the detection script in dracut ) 16:55:30 <Viking-Ice> so I say punt for now 16:55:39 <cmurf> no i have applied the new blivet and it still crashes 16:55:45 <Viking-Ice> we need haralds input on this before deciding anything anyway 16:56:28 <adamw> well, at least some confirmation would be nice i guess 16:56:33 <cmurf> yeah this bug is that the LV's aren't active 16:56:54 <adamw> note that "post-install requirements" says "Except where otherwise specified, each of these requirements applies to all supported configurations described above." 16:57:21 <Viking-Ice> adamw, sounds awfully like this bug filed against the downstream distro against us rhbz#921235 16:57:25 <adamw> one implication of that is, basically, that any installation scenario considered 'blocking' by the criteria - which we've already decided includes thinp autopart - is also required to actually boot. 16:57:25 <cmurf> presumably since it's offered in guided partitioning it should boot 16:57:35 <adamw> right. 16:57:46 <cmurf> i'm not sure if it's a dracut thing 16:57:50 <cmurf> or systemd thing though 16:57:58 <cmurf> thing=bug 16:57:58 <Viking-Ice> it's not systemd 16:58:15 <Viking-Ice> but hey let's always blame systemd for all the worlds problem 16:58:27 <tflink> Viking-Ice: sounds like a plan. either that or PA :) 16:58:33 <adamw> i would be +1 on this if it's confirmed to be affecting a typical guided thinp deployment 16:58:35 * tflink votes for blaming canada, though :) 16:58:49 <adamw> blame canada for systemd, that should cover everything! 16:59:03 <tflink> sweet, I think we're done here then 16:59:21 <cmurf> so is this a punt or what 16:59:27 <tflink> getting back to reality ... votes? 16:59:29 <Viking-Ice> I would say so 16:59:32 <tflink> punt or +1? 16:59:37 <adamw> eh. either punt or +1 with the option to withdraw, i guess 16:59:38 <cmurf> i think it's a +1 but we also need info 16:59:40 <adamw> i can go for either 16:59:55 <tflink> yeah, I'm ok with either. not -1. 16:59:55 <cmurf> it's reproducible in a VM and on baremetal 17:00:07 <cmurf> and it's guided partitioning 17:00:19 <cmurf> and the initramfs was built with a dracut that should support thinp 17:00:22 <Viking-Ice> we need to know from harald if it's dracut or something else 17:00:25 <cmurf> right 17:00:38 <Viking-Ice> but most likely this is a fallout from the other bug 17:00:41 <cmurf> but on principle the vote is whether thinp installs should boot 17:00:43 <adamw> Viking-Ice: we don't need to know that in order to decide if it's a blocker bug though, really 17:01:04 <cmurf> viking-ice: well the other bug though is an installer problem that's fixed in blivet 17:01:14 <cmurf> when i boot the desktop media, the thinp volumes are all active and fine 17:01:19 <cmurf> thinp metadata is fine 17:01:20 <Viking-Ice> and has this been tested afterwords 17:01:25 <cmurf> the file systems on the thinp LV's are fine 17:01:27 <adamw> Viking-Ice: that doesn't seem right. the other bug prevents you getting an install done at all if you hit it. but cmurf managed to work around that bug, and _then_ ran into this one. 17:02:04 <Viking-Ice> adamw, true I'm +1 for blocker just wanted more data 17:02:36 <tflink> I don't see any -1s - in the interest of not having to review this again, lets just accept it 17:02:37 <adamw> sure, we need more data to FIX it, just not to vote :) 17:02:41 <adamw> yeah, that seems fine 17:02:51 <tflink> if it turns out to be something obscure, we can revisit 17:02:58 <cmurf> agreed 17:04:07 <tflink> huh, we don't seem to have a generic "it should boot" criteria 17:04:16 <tflink> just the graphical and non/graphical cases 17:04:52 <Viking-Ice> well techincally you dont require initrd 17:04:53 * Viking-Ice hides 17:05:05 <tflink> proposed #agreed 1013767 - AcceptedBlocker - Violates the following F20 alpha release criterion for LVM thinp autopart installs: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:05:06 <cmurf> yes but that requires user intervention 17:05:12 <Viking-Ice> ack 17:05:15 <cmurf> ack 17:05:38 <tflink> ack/nak/pak? 17:06:26 <tflink> roshi, kparal, pschindl: ack/nak/patch? 17:06:41 <roshi> ack 17:06:49 <tflink> #agreed 1013767 - AcceptedBlocker - Violates the following F20 alpha release criterion for LVM thinp autopart installs: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:06:59 <tflink> #topic (864198) grubby fatal error updating grub.cfg when /boot is btrfs 17:06:59 * kparal wakes up 17:07:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864198 17:07:05 <tflink> #info Proposed Blocker, grubby, ASSIGNED 17:07:59 <cmurf> summary is; Installer allows user to create a legitimate layout, boot on Btrfs, which GRUB2 can boot. Yet grubby doesn't properly update the grub.cfg, and therefore requires intentional user intervention for the system to boot to a working login prompt/desktop. 17:08:21 <adamw> tflink: what scenarios are not covered as either a) graphical or b) non-graphical? semi-graphical? :P 17:08:49 <Viking-Ice> this one has been following us for 2 releases now 17:08:51 <cmurf> FWIW: this bug also breaks subsequent kernel updates, which means without user intervention you don't boot the newly installed kernel 17:08:52 <tflink> adamw: situations that are both? 17:08:55 <Viking-Ice> based on comments 17:08:59 <adamw> cmurf: is this the config you get if you use the btrfs filesystem option for guided partitioning? or only if you do a specific custom layout? 17:09:00 <Viking-Ice> let's put it to rest +1 17:09:08 <cmurf> adamw: custom only 17:09:11 <adamw> tflink: if a bug affects both, then it's DOUBLE blocker. 17:09:16 <cmurf> adamw: guided uses ext4 for boot 17:09:33 <tflink> adamw: does that mean the affected software goes on double secret probation? 17:09:50 <cmurf> or secret double probation 17:09:53 <adamw> the custom partitioning criteria are sort of focused on the functionality of the partitioner itself, not the consequences... 17:09:57 <adamw> so we're in a bit of a grey area 17:10:16 <adamw> it'd be a conditional violation of the 'it must boot' criteria, i guess: violates them in the case you configure the specific layout that causes the bug. 17:10:23 <cmurf> adamw: post-install requirements don't propose an exception for custom producing unbootable systems 17:10:53 <Viking-Ice> this is a violation of the criteria and we have let it slide for two long 17:10:57 <Viking-Ice> mean too 17:10:59 <tflink> yeah, it seems a bit silly to say that "it installs, therefore not a blocker" 17:11:08 <tflink> when it doesn't install _and_ boot 17:11:18 <cmurf> we need to hear from pjones 17:11:19 <adamw> cmurf: i refer you to https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F 17:11:39 <adamw> "When a bug causes a criterion not to be met in some but not all cases, the teams involved in the release process will make a judgement as to whether the impact of the bug is severe enough to consider the release as a whole not to meet the release criteria" 17:11:41 <adamw> that's us. :P 17:12:19 <cmurf> wait what 17:12:25 <tflink> but at the same time, this doesn't really pass the "last blocker @ go/no-go" test 17:12:26 <cmurf> there's a double negative in there 17:12:39 <adamw> cmurf: i don't think there is. 17:12:48 <cmurf> a criterion not met in some, but not all cases 17:12:49 <cmurf> ? 17:13:02 <cmurf> "not to be met in some but not all cases" 17:13:03 <adamw> that's not a double negative. 17:13:18 <adamw> the first 'not' is talking about the criterion, the second 'not' is talking about the cases. 17:13:27 <tflink> we're getting off in the weeds here 17:13:27 <roshi> it could be worded better, but there's no double negative 17:13:33 * tflink bangs gavel 17:13:40 <adamw> it ain't not only a double negative when both the negatives are dealing with one noun clause ;) 17:13:46 <cmurf> okok 17:13:49 <roshi> we have a gavel? 17:13:54 <adamw> .fire roshi could NOT 17:13:54 <zodbot> adamw fires roshi could NOT 17:13:55 <tflink> I do :) 17:14:12 <adamw> roshi: my legalese is flawless, damnit. 17:14:20 <roshi> haha 17:14:27 <Viking-Ice> I have stunner that zaps people much more effective then an gavel 17:14:31 <cmurf> that's really confusing 17:14:33 <cmurf> i'm still confused 17:14:37 <Viking-Ice> +1 blocker 17:14:43 <adamw> +1 viking 17:14:45 <adamw> =1 blocker 17:14:50 <tflink> Viking-Ice: unless you're looking to get the attention of several people at the same time 17:14:50 <adamw> sigh. 17:14:51 <cmurf> +1 blocker 17:14:54 <adamw> I mean, +1 getting back to the voting 17:14:59 <cmurf> it should work or we need to be told why it can't be made to work 17:15:03 <tflink> but I'm not planning to bring a gavel to a tazer fight 17:15:18 <Viking-Ice> tflink, that's what lightnings are for It's not without reason I carry the hammer of Þór 17:15:22 <adamw> i'm probably -1 blocker for beta, though. i don't * think* a lot of people are going to stick /boot on a btrfs subvol. probably doesn't pass the 'last blocker' smell test. 17:15:25 <cmurf> grub2-mkconfig produces a working booting system grubby does not 17:15:34 <adamw> cmurf: *everything* should work, but not everything can be a blocker. 17:15:39 * tflink makes note not to make Viking-Ice too mad, he has the lightnings 17:15:40 <roshi> basically, a bug that causes specific exceptions to the criteria - not a complete failure to meet the criteria cmurf 17:15:54 <roshi> I thought all vikings had lightnings... 17:15:56 <cmurf> post-install criteria 17:15:59 <cmurf> it should boot 17:15:59 <roshi> +1 17:16:01 <tflink> hammer and lightning in one 17:16:07 <tflink> yeah +1 17:16:12 <Viking-Ice> smash and strike ;) 17:16:13 <tflink> well, +.5 17:16:17 <adamw> cmurf: the point is that this bug does not violate that criterion in all cases, or anywhere *close* to all cases 17:16:28 <cmurf> ummm yes it does 17:16:34 <adamw> cmurf: ummmm no 17:16:36 <cmurf> if you put btrfs on boot it does not boot 17:16:37 <tflink> cmurf: not for btrfs autopart 17:16:44 <adamw> cmurf: right, and that's what, 0.1% of installs? 17:16:46 <Viking-Ice> we have enough votes let's move on 17:16:52 * adamw pulls number wildly out of ass, but you get the point 17:17:13 <cmurf> ok well that's a vague way to decide what is a blocker 17:17:33 <adamw> cmurf: unfortunately no-one's figured out how to take all the subjectivity out of it. 17:17:41 <tflink> cmurf: the process, by definition, is somewhat subjective 17:17:44 <adamw> it's pretty hard to write deterministic rules to cover ALL POSSIBLE BUGS EVER 17:17:53 <adamw> i'd like it if we could, but it'd take a smarter monkey 17:17:57 <cmurf> well it's not even about the bug details 17:17:59 <cmurf> it's about the result 17:18:07 <adamw> not really 17:18:24 <adamw> it's about how commonly an issue can be encountered before we decide it's unacceptable 17:18:40 <adamw> or how important it is to us that the specific broken configuration be fixed 17:18:54 <cmurf> ok well i think it's more ideological. you want the installer installing things that work, not things that don't work. 17:19:01 <adamw> do we have some particularly pressing reason why we really want people to be able to put /boot on a btrfs subvol in f20 beta, for instance? 17:19:29 <cmurf> so it can be tested 17:19:33 <adamw> cmurf: that's all well and good, but it's a pretty impossible standard to set. i doubt we've ever done a single release where you couldn't somehow persuade the installer to deploy something non-bootable. 17:19:38 * Viking-Ice acks to the proposed blocker critera and shrughs of time wasting, puts on intermission https://www.youtube.com/watch?feature=player_embedded&v=AGF5ROpjRAU and goes out for a smoke 17:19:44 <cmurf> better to have it working for beta and blow up than final and blow up 17:19:56 <adamw> sure. 17:20:03 <adamw> but we're not in an ideal world =) 17:20:25 <adamw> i just don't think this passes the 'smell test' - if we got to a go/no-go meeting and this was the last bug, do you think folks would generally favour pushing the release out a week to fix this? 17:20:48 <cmurf> ha 17:20:57 <cmurf> ok you and i know full well that that would certainly get this bug a lot of attention 17:21:02 <adamw> there is a bit of a tension between the 'system-specific bugs' clause and the 'each of these requirements applies to all supported configurations described above' bit of the criteria, which we should probably resolve more clearly. 17:21:06 <cmurf> and then we'd see whether or not people expect it to work and when 17:21:15 <cmurf> clarity would come 17:21:27 <adamw> cmurf: well, i don't like to push things too far there 17:21:37 <adamw> there is a question of credibility 17:21:42 <cmurf> i don't think it's pushing that far 17:21:51 <cmurf> I think the policy needs to be that if it's offered in the installer it needs to result in a working system; or the offer needs to be removed from the installer. Otherwise you're handing out razor blades to users and telling them to go play on the freeway. 17:21:52 <tflink> the more I think about it, I'm -1 for beta 17:22:04 <adamw> the more 'we' (the folks in blocker review meetings, which ought to be a broad base of people but practically speaking is usually QA people) accept bugs as blockers that don't hold up at go/no-go meetings, the less of it we have 17:22:23 <adamw> cmurf: it's a beta. we explicitly tell you not to install it in any kind of critical situation. 17:22:26 <tflink> testers are responsible for finding the important bugs and knowing which ones those are 17:22:39 <adamw> we are releasing it to be tested, not for you to give all your important files to. 17:22:40 <tflink> finding bugs and raising important ones, rather 17:22:43 <adamw> (types he, from his f20 laptop) 17:23:15 <adamw> the bar you're trying to set is not one we have, generally speaking, ever aspired to 17:23:21 <tflink> I agree that it doesn't pass the "last blocker at go/no-go" test 17:23:43 <adamw> if you look at the delta between beta and final, or just look at the betas we've shipped in the past, it is not a principle i think we're capable of accepting 17:24:25 <tflink> adamw: I disagree on the capable but it certainly is a different standard than the one set in the past 17:24:30 <adamw> hell, look at the OS X bootloader bug: we shipped a *final release* which will give you a non-bootable system last time out. i would love it if we could plausibly say we weren't going to do that, but the fact of the matter is fedora does that. 17:24:53 <adamw> oh, wait, that's an install showstopper isn't it? still, you get the idea. 17:25:01 <adamw> i'm pretty sure we've shipped bugs like this before. 17:25:05 <tflink> adamw: that's a dangerous line to walk 17:25:07 * adamw is the realist 17:25:11 <cmurf> adamw: we both know that when it comes down to the wire a LOT of individual blocking bugs, if they had not been fixed, would not have passed the go/no-go smell test 17:25:23 <cmurf> that didn't happen because they were fixed before the wire 17:25:30 <adamw> cmurf: i'm not sure i agree with that. at least, i try not to vote +1 on bugs like that. 17:25:37 <adamw> anyhoo 17:25:43 <cmurf> there is a significant emotional effect of go/no-go on bugs holding up releases 17:25:43 <adamw> maybe we should just count votes and move on 17:25:46 <tflink> I see +3/-1 17:25:57 <adamw> i thought you said -1? 17:26:07 <cmurf> i count a draw 17:26:07 <tflink> I did, I didn't see you explicitly say -1 17:26:14 <tflink> +3/-2 17:26:20 <tflink> did I miss another one? 17:26:24 <cmurf> so punt the thing, and tell the submitter to propose it for final 17:26:42 * jreznik is blocked by other meetings, tries to follow it here and is more -1 blocker for beta for this 17:27:04 <tflink> +3/-3 17:27:06 <cmurf> definitely a draw 17:27:17 <cmurf> ok so punt it, let's get info from pjones 17:27:26 <cmurf> vote on it in a week 17:27:38 <Viking-Ice> ? 17:27:39 <tflink> I'd rather make a decision so we don't have this same argument again in a week :) 17:27:39 <cmurf> we'd have +6 for that 17:27:45 <Viking-Ice> what it was +5 just a minute ago 17:27:51 <cmurf> tflink i will promise not to argue next week 17:28:13 <kparal> I'm OK with -1 for Beta 17:28:22 <tflink> +3/-4 17:28:34 <Viking-Ice> <tflink> well, +.5 17:28:42 <tflink> Viking-Ice: later changed to -1 17:28:42 <cmurf> reject blocker, get info from pjones, revist for final 17:29:04 <Viking-Ice> nonsensce we have been carrying this for 2 GA release now let's put this to rest 17:29:15 <adamw> that seems like wonky logic 17:29:15 <Viking-Ice> peter can just fix grubby 17:29:24 <cmurf> viking_ice i agree however there is a vote here and it's +3/-4 17:29:27 <Viking-Ice> adamw, it's a clear violation on top of that 17:29:32 <adamw> the fact that we have shipped stable releases with the bug and there has not been any significant complaint supports -1, not +1 17:29:48 <adamw> Viking-Ice: i disagree. to me it's a conditional violation, which means it's a subjective call based on severity and broadness of impact. 17:30:02 <Viking-Ice> adamw, yeah yeah we all know how you judge that 17:30:05 <cmurf> adamw: fair point, HOWEVER if there is ever a day in this century when btrfs ships as default fs, this needs to be fixed 17:30:14 <cmurf> and we shouldn't wait until the last minute to be fixing every btrfs related bug 17:30:18 <tflink> cmurf: sure, but that's not f20 17:30:19 <cmurf> bit by bit is a good idea 17:30:26 <cmurf> baby steps 17:30:31 <cmurf> this is a baby step for f20 17:30:34 <adamw> i mean, strictly speaking lots of bugs are conditional, but it's pretty obvious if it affects like 20% of all installs, that's bad. but when it's much smaller than that, like here, it's not clear. 17:30:39 <tflink> proposed #agreed 864198 - RejectedBlocker - This does not clearly violate any F20 beta criteria as it's a corner case. Therefore, it does not qualify as a release blocking bug for f20 beta. 17:30:46 <Viking-Ice> nack 17:31:00 <tflink> Viking-Ice: patch? 17:31:01 <adamw> you shouldn't nack the agreement because you disagree with the vote 17:31:07 <cmurf> right 17:31:08 <Viking-Ice> tflink, you could have proposed the blocker when we had clear +5 yet you did not but now you do 17:31:22 <adamw> only if there's something wrong with the text as it represents the discussion/vote we had 17:31:26 <cmurf> i'd patch it to include the fact it's a long standing bug that has other consequences and needs to be fixed, what's the hold up? 17:31:34 <tflink> Viking-Ice: I usually wait until the discussion slows down a bit 17:31:41 <Viking-Ice> adamw, so the lesson to learn here is to stall until tflink changes his mind 17:32:32 <adamw> well, no, i'd say the lesson is that when a bug seems to be particularly contentious and discussion clearly isn't settled yet, don't hold a vote in the middle of things. 17:32:43 * tflink apologizes for speaking too quickly before 17:32:49 <adamw> i'm not sure about that +5, anyway. if you were counting me as +1 at any point, that's wrong (my fault for doing joke votes) 17:32:51 <tflink> I think, anyways 17:32:52 <adamw> i was never +! 17:32:54 <adamw> +1 17:33:12 <Viking-Ice> still does not change the fact that this is a violates the criteria 17:33:24 <adamw> Viking-Ice: let's not go over that again. 17:33:26 <Viking-Ice> regardless of your thoughts of how many are affected 17:33:28 <tflink> so do many bugs 17:33:53 <adamw> the thing about 'conditional blockers' is pretty accepted practice, by now. it's not like this is the first time we have considered or rejected a bug on that basis. 17:33:53 <tflink> I don't think there's ever been a fedora release without some bugs that are conditional violations of criteria 17:34:16 <adamw> i'm confused as to why people are acting like we're doing something shockingly new, when this seems like business as usual to me. 17:34:31 <Viking-Ice> no problem reject this and I get more reporters to comment on it and re propose it as a blockers so adam can up his count 17:34:33 <tflink> f20a was released with a bug that has hit more people than have commented on this one 17:34:37 <adamw> i may have made a bad job of explaining/interpreting certain bits of the criteria, in which case sorry, i should look at making that clearer. 17:34:41 <cmurf> ok well punting a bug that prevents a system from booting forever doesn't seem like good policy 17:34:50 <cmurf> either remove the capability or fix the bug 17:34:59 <cmurf> i'm fine with it being rejected as a blocker for beta 17:35:18 <cmurf> i think the proposal needs to ask pjones what the hold up is, maybe he needs something grub2 folks don't 17:35:24 <adamw> cmurf: that's the purpose of this meeting, remember. we're not really here to decide whether someone should be admonished for not fixing the bug for two releases. 17:35:24 <cmurf> it's a long standing bug 17:35:26 <tflink> you could also apply the argument to pokemon systems 17:35:54 <cmurf> i'm not saying admonished 17:36:24 <cmurf> i'm saying to recognize it's a problem that might very well be a blocker in the (near) future, a fix is eventually going to be very necessary 17:36:44 * adamw has mislaid his crystal ball 17:36:45 <tflink> and at that point, I'll be a blocker 17:36:51 <cmurf> the opensuse folks have this working by the way 17:36:54 <cmurf> in their beta 17:36:58 <adamw> ...okay? 17:37:08 <cmurf> offered in the installer, and it boots 17:37:11 <Viking-Ice> adamw, we need to start testing btrfs as cmurf has pointed out and this is a clear criteria violator and I rather like we sort this out in beta but sure let's revisit as a final if you so much desire dealing with boot/fs related issues at that time 17:37:12 <adamw> not really sure what relevance that has to anything. 17:37:21 <tflink> proposed #agreed 864198 - RejectedBlocker - This does not clearly violate any F20 beta criteria and is a corner case. Therefore, it does not qualify as a release blocking bug for f20 beta. 17:37:34 <adamw> Viking-Ice: i would prefer the bug be fixed for beta. i would prefer the bug be fixed in the next five minutes. that doesn't make it a release blocker. 17:37:47 <Viking-Ice> adamw, it violates the critera which makes it a blocker 17:37:48 <tflink> agreed, I'd love to see this fixed 17:38:06 <tflink> I'd be willing to wager that patches would be considered 17:38:06 <cmurf> adamw is correct on principle, i think the beta criteria support a stronger position however 17:38:09 <cmurf> so let's move on 17:38:09 <Viking-Ice> but based on your whim count which is totally irrelevant you decide to ignore it 17:38:15 <adamw> Viking-Ice: you keep just saying that, and completely disregarding the objection which has been made to the statement. 17:38:20 <tflink> ack/nak/patch? 17:38:32 <adamw> Viking-Ice: it is not a whim and it is not totally irrelevant. it is something we have been doing, consistently, for multiple releases. it's a standard part of blocker voting. 17:38:35 <cmurf> ack 17:38:40 <adamw> ack 17:38:44 * cmurf is going for coffee 17:38:58 <adamw> Viking-Ice: seriously, just go look back through the logs... 17:39:15 <kparal> ack 17:39:25 <tflink> #agreed 864198 - RejectedBlocker - This does not clearly violate any F20 beta criteria and is a corner case. Therefore, it does not qualify as a release blocking bug for f20 beta. 17:39:35 <tflink> on the bright side, that was the last proposed blocker on my list 17:40:17 <Viking-Ice> we got the mei mei bug proposed as well but I removed it since it looked like no one tested it on f20 or kernel 3.11 for that matter 17:40:18 <tflink> on to proposed FE 17:40:35 <tflink> mei mei? 17:40:38 <Viking-Ice> 917081 17:40:39 <adamw> Viking-Ice: oh, the intel mei stuff? 17:40:47 <Viking-Ice> adamw, yeah 17:41:01 <adamw> i was hitting that somewhere. erf. can't remember if it was on my dell laptop or what. 17:41:12 <Viking-Ice> it came with the 3.10 kernel 17:41:14 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=980221 17:41:40 <adamw> oh, looks like I figured it was fixed in 3.11rc1? 17:41:47 <Viking-Ice> it went ( for me with ) 3.11 as well as 3.9 awhere not affected 17:41:58 <adamw> sounds like it matches my experiences 17:42:08 <Viking-Ice> yeah but the GA release are using 3.10.x 17:42:18 <adamw> yeah, not an issue for this meeting, though 17:42:32 <Viking-Ice> it got proposes hence I warranted it should be mentioned 17:42:54 <Viking-Ice> atleast ( even thou I removed it ) 17:43:03 <tflink> Viking-Ice: you do realize that if I had done that, you would be reading me the riot act right now, right? 17:43:35 <Viking-Ice> tflink, no I would not there was no indication in the bug that people actually tried this on F20 17:44:05 <tflink> #topic (1007590) Black screen after F20 graphical install on PPC64 17:44:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1007590 17:44:10 <tflink> #info Proposed Freeze Exceptions, glibc, ASSIGNED 17:44:21 <adamw> Viking-Ice: sure, i should've said, sounds like we don't need to accept it, good idea to bring it up though 17:45:20 <adamw> ppc64 is not a primary arch. 17:45:32 <adamw> are we on to FE? 17:45:36 <adamw> oh yeah 17:45:39 <Viking-Ice> I think so yes 17:45:43 <Viking-Ice> so +1 FE 17:45:47 <adamw> sounds like +1 FE then, showstopper issue for a secondary arch 17:46:12 <jreznik> do FEs makes sense before freeze? 17:46:28 <Viking-Ice> not really 17:46:32 <adamw> jreznik: sure, it means we will take a fix once freeze kicks in 17:46:41 <Viking-Ice> but we can just as well cut them down now 17:46:44 <adamw> the status has no impact *right now*, it just gets us out front of the voting process. 17:46:59 * roshi was going to ask that jreznik 17:47:02 <tflink> proposed #agreed 1007590 - AcceptedFreezeException - This is a showstopper for PPC64 and while not PA, a tested fix would be considered past freeze. 17:47:11 <adamw> ack 17:47:19 <jreznik> ack 17:47:23 <roshi> ack 17:47:29 <tflink> #agreed 1007590 - AcceptedFreezeException - This is a showstopper for PPC64 and while not PA, a tested fix would be considered past freeze. 17:47:47 <tflink> ok, that's all the proposed FE 17:47:59 <tflink> moving on to the accepted blockers not already ON_QA/VERIFIED 17:48:07 <tflink> #topic (986575) installer fails to apply lower bound to resize requests in custom spoke 17:48:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=986575 17:48:12 <tflink> #info Accepted Blocker, anaconda, ASSIGNED 17:48:53 <adamw> eh, this is one i'm not sure makes sense for an FE... 17:49:00 <adamw> kinda thing it's better to poke pre-freeze. 17:49:06 <Viking-Ice> this is accepted blocker 17:49:15 <adamw> hum, right 17:49:22 <adamw> was about to say "or as a blocker" :P 17:49:33 <Viking-Ice> I'm not sure we need to go through those now 17:49:34 <adamw> are you clicking the wrong list, tflink? 17:49:41 <adamw> oh no, i missed a line again 17:49:42 <tflink> ? 17:49:45 <adamw> sigh 17:49:48 <adamw> goddamn tiny letters 17:49:51 <Viking-Ice> unless of course we want to drag teh anaconda maintainers in for status updates? 17:50:13 <adamw> tflink: maybe only bring up ones that look like we could do something useful? 17:50:24 <adamw> i agree with viking it's a bit early to go through all of them and just agree that they need fixin' :) 17:50:24 <tflink> k, give me a sec to read through them 17:50:29 <Viking-Ice> lol 17:50:41 <Viking-Ice> what's the status on the usual over size crap 17:50:52 <adamw> dunno if anyone's doing anything about it yet 17:50:56 <adamw> i'll ask desktop team 17:51:06 <adamw> desktop is only juuust barely oversize though 17:51:09 * jreznik promised to take a look but... :( 17:51:26 <adamw> the test image I built yesterday was 1007681536 17:51:33 <adamw> hmm, that's 7MB, thought it was 0.7MB. darn. 17:51:47 <tflink> pschindl: have you done any more poking at 1009132? 17:53:16 <tflink> yeah, the size ones are the bugs that seem to need some annoyance-giving 17:53:24 <tflink> #undo 17:53:24 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1dc79e10> 17:53:25 <tflink> #undo 17:53:25 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x8443ad0> 17:53:26 <tflink> #undo 17:53:26 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1dc79650> 17:53:34 <Viking-Ice> yep and they seem to be on status quo 17:53:34 <tflink> #topic (1000891) DVD is oversized (larger than 4.7 GB) 17:53:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891 17:53:35 <tflink> #info Accepted Blocker, distribution, NEW 17:53:45 <tflink> has anything even changed on these? 17:53:52 * adamw just poked desktop team 17:54:03 <Viking-Ice> hopefully hard with a stick 17:54:19 <tflink> says the man with a hammer full of lightning :) 17:54:42 <adamw> hehe 17:55:00 <Viking-Ice> tflink, metal stick for better connectivity 17:55:08 <roshi> so, we're not doing anything with 986575 at the moment, right? 17:55:17 <tflink> roshi: correct 17:55:27 <tflink> who do we need to pester about this? notting? 17:55:31 <roshi> ok, just checking before I removed it from my memory 17:55:34 <roshi> :D 17:55:37 <adamw> dvd size, notting would be a good suspect, and jreznik 17:55:43 <adamw> for desktop, the desktop team 17:55:44 <adamw> is KDE oversize? 17:55:59 <tflink> not sure - its not filed as a blocker if so 17:56:14 <jreznik> I think it was ok 17:56:43 <Viking-Ice> pester bill harder about thsi 17:56:45 <Viking-Ice> mean this 17:57:12 <Viking-Ice> adamw, hand him a metal stick tell him to hold it for a minute and I will raise the hammer of lightning 17:57:13 <jreznik> yeah, sure 17:57:35 <Viking-Ice> give him a light jolt to get things moving.... 17:57:38 <tflink> Viking-Ice: not too much lightning, that'll delay any fixes even more ;) 17:57:57 <Viking-Ice> not to crispy noted 17:58:35 <tflink> I just have a feeling that this is going to produce another flamewar on devel like f19 17:58:55 <tflink> so, anyone want the #action? 17:58:55 <jreznik> it is... 17:58:59 <Viking-Ice> tflink, it will and always will as long as we keep shipping the dvd 17:59:03 <adamw> hand it to jreznik 17:59:06 <jreznik> yep 17:59:38 <tflink> #action jreznik to start investigating ways to trim down the dvd size or find someone to do it 18:00:04 <tflink> #info DVD still oversize, needs discussion/changes to get it back under 4.7 GB 18:00:27 <tflink> anything else here? 18:00:32 <jreznik> or stop shipping DVDs :) 18:00:55 <tflink> #action jreznik to start campaign to stop shipping dvds 18:01:06 <Viking-Ice> +1 to that 18:01:42 <tflink> anyhow, I'm not sure that any other blockers need attention right now 18:01:48 <adamw> hey, looks like we're not the only ones who half-ass things 18:02:01 <tflink> the desktop team seems aware of the isssue and is working to rebuild stuff 18:02:07 <adamw> the FAA panel on electronic devices on airplanes says wifi should be fine because "The vast majority" of aircraft "are going to be just fine," 18:02:24 <adamw> y'know, if there's ONE time when I worry that 'vast majority' might be a bit too loose a criterion... 18:02:32 <adamw> it's when it comes to giant flying machines. 18:02:51 <roshi> I like how the FAA wants me to turn off a GPS because it'll cause interference... o.O 18:03:03 <roshi> damn receivers - always interfering with things 18:03:11 <roshi> </sarcasm> 18:03:13 <tflink> any other accepted blockers that people want to review 18:03:17 <adamw> nope 18:03:40 <tflink> roshi: you expect people to be able to tell the difference between a transmitter and a receiver by just looking at it? 18:03:48 <tflink> then it's time for #topic Open Floor 18:03:53 <roshi> well, it's a GPS 18:03:56 <tflink> fail 18:04:00 <roshi> what else is it supposed to be? 18:04:01 <tflink> #topic Open Floor 18:04:04 <roshi> :p 18:04:26 <tflink> roshi: not sure, but you had better turn it off or the plane might crash 18:04:49 <tflink> any other topics that should be brought up today? 18:05:17 <tflink> or do we all meander over to the fesco meeting that just started? 18:05:40 * tflink sets quantum magic fuse made from unicors to (0,5] minutes 18:05:57 <roshi> unicors - those are rare 18:06:00 <tflink> #info next blocker review meeting will be 2013-10-09 @ 16:00 UTC 18:06:04 <adamw> i've got to go make dinner 18:06:13 <tflink> roshi: even more rare now that I'm making fuses out of them :) 18:06:14 <adamw> so if someone can go and be Very Alarmed at the fesco meeting that'd be great 18:06:26 * tflink is getting the panic button out 18:06:42 <adamw> ah, the trusty old standby 18:06:49 <adamw> bbl 18:07:43 <tflink> boom! 18:07:48 <tflink> thanks for coming everyone! 18:07:54 * tflink will send out minutes shortly 18:07:58 <tflink> #endmeeting