16:01:42 <roshi> #startmeeting F23-blocker-review
16:01:42 <zodbot> Meeting started Mon Aug  3 16:01:42 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:42 <roshi> #meetingname F23-blocker-review
16:01:42 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:01:43 <roshi> #topic Roll Call
16:01:52 <roshi> who's around for some blocker review?
16:02:15 <jkurik> Hi roshi. I am around...
16:02:22 * satellit have to leave in 15 min...
16:02:26 * pschindl is here
16:02:30 <cmurf> i’m here
16:02:46 <roshi> thanks for coming jkurik :)
16:02:55 <roshi> I know tflink will be here as well
16:03:17 <roshi> #chair jkurik pschindl cmurf tflink adamw
16:03:17 <zodbot> Current chairs: adamw cmurf jkurik pschindl roshi tflink
16:03:23 <roshi> #topic Introduction
16:03:24 <roshi> Why are we here?
16:03:24 <roshi> #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 nice-to-have bugs.
16:03:27 <roshi> #info We'll be following the process outlined at:
16:03:30 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:33 <roshi> #info The bugs up for review today are available at:
16:03:35 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:37 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:40 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:03:43 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:03:46 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:03:49 <roshi> we currently have 1/3/2 proposed blockers
16:03:55 <roshi> and 5 proposed Alpha FEs
16:04:07 <roshi> onto the alpha proposals...
16:04:17 <roshi> #topic (1247747) Review Request: f23-backgrounds - Fedora 23 default desktop background
16:04:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1247747
16:04:23 <roshi> #info Proposed Blocker, Package Review, ON_QA
16:05:17 <cmurf> +1
16:05:26 <roshi> +1 from me as well
16:05:27 <cmurf> plus, it’s done
16:06:05 <roshi> proposed #agreed - 1247747 - AcceptedBlocker Alpha - This bug is a clear violation of the following Alpha criteria: "The default desktop background must be different from that of the two previous stable releases."
16:06:10 <tflink> +1
16:06:11 <tflink> ack
16:06:13 <roshi> I like when things are done :)
16:06:44 <pschindl> ack
16:06:55 <roshi> #agreed - 1247747 - AcceptedBlocker Alpha - This bug is a clear violation of the following Alpha criteria: "The default desktop background must be different from that of the two previous stable releases."
16:07:08 * kinokoio is here
16:07:08 <roshi> who wants to secretarialize?
16:07:13 * satellit afk
16:07:19 <pschindl> roshi: I will do it.
16:07:26 <roshi> thanks pschindl
16:07:31 <roshi> welcome kinokoio :)
16:07:44 <roshi> ok, onto the beta proposals
16:07:49 <roshi> #topic (1247622) blivet.errors.FSError: umount failed
16:07:49 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1247622
16:07:49 <roshi> #info Proposed Blocker, anaconda, NEW
16:08:03 <cmurf> satellit: that was a fast 15 minutes!
16:08:34 <pschindl> +1
16:08:38 <cmurf> seems to be a clear +1 blocker
16:09:07 <cmurf> But is this anaconda proper or is this the litd bug?
16:09:58 <cmurf> NVM anaconda crashes so it’s an anaconda bug
16:10:09 <roshi> is litd going to continue to be a supported method?
16:10:33 <roshi> it was luc that we talked about last cycle, right?
16:10:44 <cmurf> haven’t heard otherwise, i think it’s luc that’s up in the air always
16:10:55 <tflink> same here
16:10:59 <roshi> +1 per the criteria
16:11:06 * danofsatx is here, not paying attention
16:11:17 <cmurf> luc runs on Windows so it’s kinda needed; litd is part of livecd-tools which is used in live composes i think
16:11:42 <tflink> +1
16:11:47 <kinokoio> +1
16:11:50 <cmurf> is adamw chairing from dream state?
16:12:21 <roshi> proposed #agreed - 1247622 - AcceptedBlocker Beta - This bug is a violation of the following Beta criteria: "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods"
16:12:37 <roshi> he's asleep in his chair, but he won't fall over when it wakes up
16:12:41 <roshi> it was a courtesy chair :p
16:13:27 <tflink> a courtesy chair like this? http://img.bleacherreport.net/img/images/photos/001/719/636/chairshot_crop_north.jpg?w=320&h=213&q=75
16:13:47 <tflink> ack
16:13:49 <pschindl> ack
16:13:57 <cmurf> ack
16:13:58 <kinokoio> ack
16:14:07 <roshi> #agreed - 1247622 - AcceptedBlocker Beta - This bug is a violation of the following Beta criteria: "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods"
16:14:08 <danofsatx> tflink: something like that, but a little more flat on the face
16:14:13 <roshi> lol
16:14:21 <roshi> #topic (1247803) _ped.IOException: Partition(s) 1 on /dev/md/Volume0_0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now ...
16:14:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1247803
16:14:28 <roshi> #info Proposed Blocker, anaconda, NEW
16:14:51 <cmurf> +1 per the criteria cited in c13
16:15:03 <cmurf> are we talking about hitting adamw with a chair?
16:15:11 <roshi> +1
16:15:14 <jkurik> +1
16:15:24 <roshi> that seems to be what the conversation has morphed to
16:15:26 <cmurf> bc if it’s up to me it should be a stuffed chair
16:15:33 * roshi is reminded to never fall asleep around you folks
16:15:55 <kinokoio> +1
16:15:57 <cmurf> a.) i don’t want to hurt him b.) justification for multiples :-P
16:16:16 <roshi> proposed #agreed - 1247803 - AcceptedBlocker Beta - This bug is a clear violation of the following Beta criterion: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:16:19 <cmurf> ack
16:16:30 <jkurik> ack
16:16:32 <tflink> ack
16:16:34 <roshi> #agreed - 1247803 - AcceptedBlocker Beta - This bug is a clear violation of the following Beta criterion: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:16:36 <kinokoio> ack
16:16:41 <roshi> #topic (1246901) ValueError: not enough free space in volume group
16:16:44 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1246901
16:16:47 <roshi> #info Proposed Blocker, python-blivet, MODIFIED
16:17:35 <cmurf> ok what’s the criteria?
16:17:54 <roshi> looking it up now
16:18:04 <cmurf> yeah it’s not in the bug
16:18:50 <cmurf> Custom partitioning When using the custom partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing.
16:19:03 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=1249266#c13
16:19:25 <tflink> it's in the dupe
16:19:46 <cmurf> OR
16:20:04 <cmurf> Custom partitioning When using the custom partitioning flow, the installer must be able to: Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions
16:20:19 <roshi> +1
16:20:22 <tflink> yep, that one
16:20:25 <tflink> +1
16:20:26 <cmurf> +1
16:20:28 <pschindl> +1
16:20:29 <jkurik> +1
16:20:48 <kinokoio> +1
16:21:02 <roshi> proposed #agreed - AcceptedBlocker Beta - 1246901 - This bug is a clear violation of the following Beta criterion: "When using the custom partitioning flow, the installer must be able to:  ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions."
16:21:10 <cmurf> ack
16:21:16 <jkurik> ack
16:21:16 <pschindl> ack
16:21:22 <roshi> #agreed - AcceptedBlocker Beta - 1246901 - This bug is a clear violation of the following Beta criterion: "When using the custom partitioning flow, the installer must be able to:  ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions."
16:21:23 <kinokoio> we should check python-blivet-1.11-1
16:21:28 <kinokoio> ack
16:21:32 <tflink> late ack
16:21:36 <roshi> #topic (1183880) wrongly permits deletion of shared EFI System partition
16:21:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1183880
16:21:42 <roshi> #info Proposed Blocker, anaconda, NEW
16:21:47 <cmurf> controversial one
16:22:47 <kinokoio> +1
16:24:29 <tflink> note that the anaconda devs closed it as NOTABUG
16:24:42 <roshi> yeah
16:24:42 <cmurf> twice
16:25:01 <tflink> ah, didn't notice the twice
16:25:41 <cmurf> I asked myself two questions for this bug:
16:25:51 <cmurf> does the user has a reasonable expectation that Windows will still be bootable in this scenario?
16:26:06 <cmurf> does the current behavior has any upside: why break Windows boot when Windows itself is not being removed?
16:26:15 <tflink> can you un-select a partition set for deletion?
16:27:07 <cmurf> No. There is no selection UI at all when choosing “apply this to all” checkbox. You have no idea the ESP will be deleted.
16:27:07 <roshi> fwiw, i just installed F22 over an existing dual boot machine and it worked fine
16:27:25 <tflink> roshi: how many disks?
16:27:26 <pschindl> I think that this isn't really a bug. User should be able to delete EFI partition of another system. If user wants.
16:27:29 <roshi> just 1
16:27:48 <cmurf> pschindl: you’re confused, the user didn’t pick the ESP explicitly
16:28:15 <cmurf> it’s being brought it by virtue of checking “apply this to all” checkbox as if Fedora owns the ESP
16:28:23 <cmurf> But the UI doesn’t indicate it
16:28:38 <cmurf> kparal’s comment 4 is relevant
16:29:10 <kinokoio> this will be a real annoyance for unexperienced EFI users
16:29:43 <pschindl> cmurf: thanks for clarification :)
16:29:49 <cmurf> It already does, I field this confusion from users all the time.
16:29:50 <roshi> I think not breaking the boot of windows is a reasonable expectation
16:30:29 <roshi> +1 under "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora."
16:30:44 <cmurf> Another option is to punt
16:30:56 <cmurf> It’s for final not alpha
16:31:00 <roshi> sure
16:31:06 <roshi> votes for punt?
16:31:21 <cmurf> hence no urgency, and then we can wait for another perspective to maybe defend it somehow
16:31:50 <tflink> cmurf: i suspect that we may end up waiting a while for that
16:31:57 <roshi> +1 punt
16:32:05 <roshi> though I lean +1 on this as a blocker
16:32:25 <kinokoio> +1 punt
16:32:29 <roshi> I expect installing windows in free space after Fedora to break my boot loader, not the other way around though
16:32:50 <cmurf> roshi: On UEFI that does not happen, Windows will not break Fedora’s bootloader.
16:33:04 <roshi> it wasn't a UEFI install of fedora :)
16:33:11 <cmurf> Yes but this bug is.
16:33:16 <roshi> right
16:33:21 <kinokoio> +1 blocker. there are some users that have several linux on their machines
16:33:38 <roshi> I expect windows to break everything, pretty much all the time is what I was saying
16:33:40 <jkurik> I am +1 as well to consider this as a blocker
16:33:46 <roshi> just what I "expect" from windows
16:34:29 <cmurf> roshi: it’s a design flaw from the BIOS+MBR era, even Fedora breaks its previous versions and other Linux in such cases.
16:34:31 <roshi> well, we have the votes for a blocker
16:34:42 <kinokoio> sorry, but gtg :)
16:34:49 <roshi> thanks for coming kinokoio
16:34:54 <roshi> o/
16:34:58 <tflink> I'm also somewhat +1 but we'll be in for more discussion either way
16:35:06 <roshi> w/o a doubt
16:35:14 <roshi> since it's been closed twice already
16:35:19 <cmurf> right
16:35:51 <roshi> cmurf: since you're driving this bug, what do you want to do?
16:35:59 <roshi> block now or punt and discuss later
16:36:00 <roshi> ?
16:37:01 <cmurf> doesn’t matter. I’d say block because I’m biased toward the user in this case.
16:37:53 <roshi> proposed #agreed - 1183880 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora."
16:38:05 <jkurik> ack
16:38:09 <cmurf> ack
16:38:11 <tflink> ack
16:38:12 <roshi> #agreed - 1183880 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora."
16:38:20 <roshi> #topic (1240802) Can't unlock an encrypted root partition using caps lock key
16:38:23 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1240802
16:38:26 <roshi> #info Proposed Blocker, systemd, NEW
16:38:43 <cmurf> So this one is interesting, the problem is I can’t tell for sure whose fault it is, so can we block on it yet?
16:38:56 <roshi> I'm not sure about this either
16:39:08 <tflink> to whomever is secretarializing: please add a bit more detail to the last bug's explanation - it'd be nice to not make this into a qa-vs-anaconda fight right off the bat
16:39:14 <cmurf> Is it for sure systemd or could this be plymouth? I thought plymouth presented this encryption passphrase thing and handed it off to systemd?
16:40:48 <cmurf> +1 punt
16:40:52 <roshi> I haven't the foggiest
16:40:55 <cmurf> We need more information.
16:40:57 <roshi> punt is fine with me
16:41:01 <pschindl> tflink: ok. I will add something to it.
16:41:07 <tflink> pschindl: thanks
16:41:28 <roshi> proposed #agreed - 1240802 - Punt - This bug still needs some more digging done before we can determine it's status.
16:41:53 * tflink isn't sure this is alpha blocker material, anyways
16:42:02 <tflink> nvm, it's final
16:42:24 <tflink> reading the whole bug before talking is usually a good idea :)
16:42:32 <tflink> ack
16:42:36 <cmurf> pschindl: Yes I agree with diplomacy I’m not intending to PO anyone but I think it’s a design flaw that’s not OK.
16:42:37 <cmurf> ack
16:42:48 <cmurf> oh wait proposed - +1
16:43:27 <roshi> #agreed - 1240802 - Punt - This bug still needs some more digging done before we can determine it's status.
16:43:44 <cmurf> oh i was right to ack the first time… confuzzled.
16:43:50 <roshi> onto the alpha FE proposals
16:43:57 <roshi> cmurf: I knew what you were getting at :p
16:44:03 <roshi> #topic (1235323) efibootmgr fails when creating or deleting boot items randomly
16:44:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1235323
16:44:09 <roshi> #info Proposed Freeze Exceptions, efibootmgr, MODIFIED
16:44:30 <cmurf> OK this one has a  patch already and it appears to work so I’m +1 on the FE, It is already an approved blocker for beta.
16:45:35 <tflink> i parsed the title of this one as "randomly deleting entries" at first :)
16:45:46 <roshi> +1
16:45:56 <jkurik> +1
16:46:02 <tflink> +1
16:46:20 <roshi> proposed #agreed - 1235323 - AcceptedFreezeException Alpha - We would accept a fix for this during Alpha freeze.
16:46:28 <cmurf> ack
16:46:54 <jkurik> ack
16:46:57 <tflink> patch
16:47:02 <roshi> go for it
16:47:26 <tflink> proposed #agreed - 1235323 - AcceptedFreezeException Alpha - We would consider a fix for this during Alpha freeze
16:47:36 <tflink> s/accept/consider
16:47:57 <roshi> ack
16:47:59 <cmurf> ack
16:48:08 <roshi> #agreed - 1235323 - AcceptedFreezeException Alpha - We would consider a fix for this during Alpha freeze.
16:48:15 <roshi> #topic (1239089) /etc/issue in Fedora server should contain cockpit URL
16:48:18 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1239089
16:48:20 <roshi> #info Proposed Freeze Exceptions, fedora-productimg-server, ASSIGNED
16:49:19 <cmurf> +1 the devs kinda want it and it’s a safe addition
16:49:32 <roshi> fine by me
16:49:44 <roshi> don't see how this can break things and it's easy to revert
16:49:49 <roshi> looks that way, anyhow
16:50:21 <cmurf> yeah and the URL is really handy
16:50:54 <sgallagh> FWIW, it's looking unlikely that this will land in time anyway.
16:51:24 <sgallagh> There's a dependent change that probably won't make it
16:51:25 <tflink> +1 for alpha FE
16:51:37 <sgallagh> But if it happens to drop in time, I'd like to slip this in.
16:51:38 <roshi> proposed #agreed - 1239089 - AcceptedFreezeException Alpha - We would consider a fix for this during the freeze period for Alpha.
16:51:42 <cmurf> ack
16:51:49 <sgallagh> ack
16:51:56 <jkurik> ack
16:51:57 <roshi> #agreed - 1239089 - AcceptedFreezeException Alpha - We would consider a fix for this during the freeze period for Alpha.
16:52:05 <roshi> #topic (1245191) AttributeError: 'MDBiosRaidArrayDevice' object has no attribute '_currentSize'
16:52:08 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1245191
16:52:11 <roshi> #info Proposed Freeze Exceptions, python-blivet, ASSIGNED
16:52:32 <cmurf> I’m -1 FE on this because it causes a bug that’s a beta blocker
16:53:13 <roshi> the fix causes a beta blocker?
16:53:14 <cmurf> correction, the 7/28 fix caused a bug that’s a beta blocker
16:53:22 <roshi> this was accepted as a beta blocker
16:53:37 <cmurf> see comment 15
16:53:41 <roshi> ah, right
16:54:12 <roshi> -1 then
16:54:19 <tflink> did it cause it or did it just allow folks to hit the second bug
16:54:23 <cmurf> Maybe I’m wrong: the question is, if there’s a safe fix available then are we +1 FE
16:54:41 <cmurf> here might be a patch possible that doesn’t cause 1247803
16:54:47 * tflink isn't reading this as a cause-effect
16:54:48 <cmurf> s/here/there
16:54:50 <roshi> tflink: I don't know if we know that for sure
16:56:38 <cmurf> I’m changing my vote to +1 FE assuming it’s a tested fix that doesn’t cause other problems.
16:57:13 <tflink> yeah, +1 FE and assuming sanity in deciding what to pull in :)
16:57:56 <jkurik> +1 for FE if it will be considered as beta blocker
16:58:15 <roshi> proposed #agreed - 1245191 - AcceptedFreezeException Alpha - Provided the provided fix isn't the cause of other bugs, we'd consider a fix during Alpha freeze.
16:58:25 <cmurf> ack
16:59:43 <jkurik> ack
17:00:40 <pschindl> ack
17:00:48 <roshi> #agreed - 1245191 - AcceptedFreezeException Alpha - Provided the provided fix isn't the cause of other bugs, we'd consider a fix during Alpha freeze.
17:01:00 <roshi> #topic (1240354) SoaS live x86_64 20150706 does not login from live system user
17:01:03 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1240354
17:01:06 <roshi> #info Proposed Freeze Exceptions, sugar, NEW
17:01:12 <cmurf> +1FE based on comment 2 “non-blocking spin does not start; unable to install”
17:01:28 <roshi> yeah, same here
17:01:30 <roshi> +1
17:01:34 <tflink> +1 FE
17:02:10 <roshi> proposed #agreed - 1240354 - AcceptedFreezeException - Since this affects a non-blocking DE, we'd consider a fix during Alpha freeze.
17:02:15 <adamw> cmurf: the fix for #1245191 doesn't cause some new problem, it's just that you can't reach #1247803 until #1245191 is fixed. one of those 'bugs behind bugs' cases.
17:02:32 <cmurf> nested bug
17:02:37 <tflink> ack
17:02:40 <adamw> bug matroshka!
17:02:42 <cmurf> ack
17:03:03 <cmurf> haha a matroshka
17:03:13 <pschindl> ack
17:03:25 <roshi> #agreed - 1240354 - AcceptedFreezeException - Since this affects a non-blocking DE, we'd consider a fix during Alpha freeze.
17:03:34 <jkurik> ack
17:03:36 <roshi> last one
17:03:37 <roshi> #topic (1239090) Reload getty prompt when system address changes
17:03:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1239090
17:03:38 <roshi> #info Proposed Freeze Exceptions, util-linux, POST
17:04:10 <cmurf> +1 FE
17:04:44 <cmurf> devs want it, but it may not land anyway
17:05:11 <jkurik> +1 FE - it is IMO a minor issue
17:05:52 <tflink> either way - it's not going to land for alpha
17:05:57 <roshi> proposed #agreed - 1239090 - AcceptedFreezeException Alpha - We would consider a fix for this issue during ALpha freeze.
17:06:00 <sgallagh> Yeah, this is the prerequisite for the cockpit url bug
17:06:13 <pschindl> ack
17:06:29 <sgallagh> tflink: I'm still requesting it in case it ends up making it in due to slips, etc.
17:06:40 <cmurf> looks like that’s it
17:06:48 <cmurf> ack
17:06:52 <tflink> ack
17:06:54 <roshi> #agreed - 1239090 - AcceptedFreezeException Alpha - We would consider a fix for this issue during ALpha freeze.
17:07:00 <roshi> #topic Open Floor
17:07:05 <roshi> anyone have anything else?
17:07:26 <tflink> nothing from me
17:07:32 <adamw> it's a vacation for me today, but I'll do the RC1 request when the new kernel is built
17:07:53 <jkurik> adamw: thanks
17:07:55 <adamw> i'll also fire an openQA run for the latest nightly to make sure there's no showstoppers lurking
17:08:25 <roshi> sweet - thanks adamw
17:08:36 * roshi sets the fuse...
17:08:40 <roshi> 3...
17:08:46 <cmurf> kablewey
17:08:52 <roshi> 2...
17:08:57 <roshi> 1...
17:09:02 <roshi> thanks for coming folks!
17:09:06 <roshi> #endmeeting