16:00:24 <roshi> #startmeeting F23-blocker-review
16:00:24 <zodbot> Meeting started Thu Sep 10 16:00:24 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:24 <roshi> #meetingname F23-blocker-review
16:00:24 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:00:24 <roshi> #topic Roll Call
16:00:36 <roshi> who's around for some blockery goodness?
16:00:39 * roshi is
16:01:11 <kushal> roshi, I am here
16:01:20 <kushal> will also be on a video call at the same time
16:01:54 <roshi> awesome, thanks kushal
16:01:59 <sgallagh> Hello
16:02:19 <roshi> #chair adamw sgallagh kushal kparal tflink danofsatx
16:02:19 <zodbot> Current chairs: adamw danofsatx kparal kushal roshi sgallagh tflink
16:02:20 <sgallagh> roshi: You forgot to send out an announcement, I think
16:02:27 <roshi> did it not go through?
16:02:29 * kparal is here
16:02:30 <roshi> I sent one
16:02:37 <kparal> nope
16:03:25 <roshi> where did it go?
16:03:47 <kparal> neither to test-announce nor fedocal, that's for sure :)
16:04:24 * kparal is preparing dinner, will try to pay attention
16:04:47 <roshi> my client says I sent it yesterday morning
16:04:56 <roshi> well, sorry about that
16:05:45 <roshi> #topic Introduction
16:05:45 <roshi> Why are we here?
16:05:45 <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:05:49 <roshi> #info We'll be following the process outlined at:
16:05:52 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:54 <roshi> #info The bugs up for review today are available at:
16:05:57 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:59 <roshi> #info The criteria for release blocking bugs can be found at:
16:06:02 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:06:05 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:06:08 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:06:11 <roshi> we currently have 9/3 blocker proposals for beta/final
16:06:58 <roshi> #topic (1258992) [abrt] initial-setup: __init__.py:135:prompt:TypeError: 'dict_values' object does not support indexing
16:07:01 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1258992
16:07:03 <roshi> #info Proposed Blocker, anaconda, VERIFIED
16:08:32 <kparal> I do not understand why c4 means verified
16:08:48 <kparal> adamw: where are you? we know you never sleep
16:08:58 <adamw> aw, i was just about to go play tennis
16:09:01 <adamw> why can't i have nice things
16:09:49 <kushal> adamw, play in RPI2 :)
16:10:08 <adamw> kparal: because this bug is about initial-setup-text not working, so far as i can see.
16:10:12 <adamw> and in my test, initial-setup-text worked.
16:10:39 <adamw> i seemed to hit some other issue with i-s-graphical, but that's not what this bug is for.
16:10:49 <kparal> ah, that's a mess. ok then
16:11:26 <kparal> +1 per criteria
16:12:05 <roshi> +1
16:13:36 <roshi> proposed #agreed - 1258992 - AcceptedBlocker Beta - This bug is a clear violation of the following criteria: "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles."
16:14:00 <roshi> kushal: sgallagh votes?
16:14:17 <kparal> ack
16:14:22 <sgallagh> Sorry, juggling two meetings
16:14:27 <roshi> no worries
16:15:21 <sgallagh> ack
16:15:26 <sgallagh> Also +1
16:15:42 <adamw> sorry, /me in the same meetings
16:15:57 <adamw> this would break arm minimal, i think, so +1/ack
16:16:05 <roshi> #agreed - 1258992 - AcceptedBlocker Beta - This bug is a clear violation of the following criteria: "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles."
16:16:35 <roshi> who wants to secretarialize?
16:17:09 <kparal> sorry, not me
16:17:20 * roshi can always go do it after the meeting
16:17:34 <roshi> #topic (1259506) anaconda not parsing kickstart files containing %include
16:17:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1259506
16:17:39 <roshi> #info Proposed Blocker, anaconda, POST
16:18:01 <sgallagh> Hold up
16:18:11 <sgallagh> adamw: arm minimal isn't release blocking, is it?
16:18:17 <sgallagh> Would this break ARM/XFCE?
16:18:57 <roshi> it also seems to be causing initial-setup from working right on KDE too, right?
16:19:00 <roshi> #undo
16:19:00 <zodbot> Removing item from minutes: INFO by roshi at 16:17:39 : Proposed Blocker, anaconda, POST
16:19:04 <roshi> #undo
16:19:04 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f5ae0343d10>
16:19:08 <roshi> #undo
16:19:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f5aefcbfcd0>
16:19:11 <kparal> sgallagh: this meaning 1259506 or 1258992?
16:19:26 <roshi> the last bug - 1258992
16:19:35 <roshi> #topic (1258992) [abrt] initial-setup: __init__.py:135:prompt:TypeError: 'dict_values' object does not support indexing
16:19:46 <sgallagh> The last bug.
16:19:57 <roshi> I just went back to it
16:20:04 <kparal> what does it have to do with arm?
16:20:09 <sgallagh> I just want to make sure we're blocking it on a platform that is actually blocking
16:20:12 <kparal> c0 says x86_64 KDE
16:20:16 <sgallagh> "(12:15:57 PM) adamw: this would break arm minimal, i think, so +1/ack"
16:20:16 <roshi> yeah
16:20:29 * kparal shrugs
16:20:37 <roshi> seeing it on kde, cinnamon means it's likely on arm too
16:20:47 <sgallagh> If it's broken on KDE x86_64, I guess that's enough
16:21:10 <adamw> sgallagh: no, because on KDE you get a user creation step in the installer
16:21:37 <adamw> as the criterion are currently written i-s is only required functionality in the ARM disk images (where you don't see the installer user creation step) or if user creation somehow falls out of anaconda./
16:21:47 <adamw> er, i meant 'on x86_64 you get...' up there.
16:22:39 <kushal> roshi, sorry was listening/replying in another video call :(
16:22:40 <sgallagh> oh right
16:22:44 <sgallagh> So there's a valid alternative.
16:23:01 <roshi> pwhalen: have you been seeing this on the arm builds?
16:23:04 <sgallagh> So the remaining question is whether it's broken for the XFCE-on-arm case
16:23:07 <sgallagh> If it's not, I'm -1 blocker
16:23:13 <adamw> but still, the bug certainly looks like it was simply an error in the i-s code, no reason to imagine it wouldn't happen on arm.
16:23:21 <roshi> if it's not, it's not a blocker - sure
16:23:32 <roshi> but since this was on cinnamon and kde, I'd think it's everywhere
16:23:47 <adamw> sgallagh: XFCE or minimal ARM image.
16:24:29 <sgallagh> adamw: Is the minimal ARM image a blocker? It's not listed on the new page we have on what is blocking
16:24:46 <adamw> sgallagh: it ought to be.
16:24:56 <adamw> i think i said so in my reply.
16:25:15 <sgallagh> The whole point of that page is that it should be definitive.
16:25:18 <adamw> we've always considered it as such before
16:25:26 <adamw> sgallagh: well, yes, but it's also a first draft which was sent out for review.
16:25:28 <sgallagh> If it's not...
16:25:37 <roshi> sgallagh: it's a draft point right now
16:25:53 <adamw> i think it'd be rather absurd to say 'well, this page which just showed up from a completely different process left this image out, so now we don't care about it any more!'
16:26:33 <sgallagh> It just seems rather edge-case-y for blocking on to me.
16:26:41 <sgallagh> And if we're unclear whether its actually a blocking deliverable..
16:26:52 <roshi> it's always been blocking
16:26:58 <adamw> i think the only person who's unclear is you?
16:27:05 <roshi> arm minimal and arm-kde
16:27:16 <roshi> we just moved it from kde to xfce
16:27:17 <sgallagh> roshi: arm-kde isn't blocking
16:27:20 <sgallagh> It doesn't actually work
16:27:26 <roshi> it used to be, as it was the arm default
16:27:30 <roshi> we changed the default
16:27:32 <sgallagh> Right
16:27:40 <sgallagh> OK, I'm not going to keep arguing about this.
16:27:49 <roshi> but it was minimal and the default desktop
16:27:56 <roshi> any changes to votes?
16:28:07 * roshi didn't see it as arguing, I guess
16:29:26 <kparal> let's go to the next bug
16:29:52 <roshi> #topic (1259506) anaconda not parsing kickstart files containing %include
16:29:55 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1259506
16:29:57 <roshi> #info Proposed Blocker, anaconda, POST
16:30:23 <adamw> sgallagh: for the record, https://meetbot-raw.fedoraproject.org/teams/fedora-qa/fedora-qa.2013-08-12-14.31.log.txt
16:30:32 <adamw> "14:49:21 <adamw> #agreed release blocking image set for ARM will consist of minimal and KDE images for F20"
16:30:45 <adamw> we switched KDE to Xfce this cycle. we never dropped minimal.
16:30:49 <sgallagh> ok
16:30:50 <kparal> +1 Beta FE, and I'd personally vote +1 Final blocker, even though we don't have any criteria for this. %include is pretty essential for system deployment
16:31:23 <adamw> as we *still* never got around to writing proper kickstart criteria (sigh) this is pretty much a judgement call, my call is beta FE, final blocker
16:31:39 <roshi> seems sane to me
16:31:48 <roshi> +1 beta fe
16:31:53 <roshi> +1 final blocker
16:32:30 <kparal> IIRC, creating that criterion was assigned to me, a year back or so. sorry
16:32:43 <kparal> so much stuff to do
16:33:12 <sgallagh> Yeah, +1 Beta FE
16:33:22 <sgallagh> I'm not sure how I feel about blocker at all right now
16:33:32 <sgallagh> (And it hopefully doesn't matter in this case)
16:33:55 <roshi> proposed #agreed - 1259506 - AcceptedFreezeException Beta AcceptedBlocker Final - This would be a good thing to have fixed during Beta so accepted as an FE for Beta. It was also voted as a blocker for final in case a fix doesn't surface in time.
16:34:03 * roshi wasn't sure the best way to sum that up, tbh
16:34:51 <kparal> ack
16:39:32 <roshi> any other acks?
16:41:54 <kparal> everybody left us!
16:42:08 <roshi> so it seems
16:42:30 <kparal> time to get to the pub?
16:42:54 <adamw> ack
16:42:58 <adamw> sorry, was still in the other meeting
16:43:02 <adamw> i'm back here now, promise
16:43:12 <roshi> no worries :)
16:43:20 <roshi> #agreed - 1259506 - AcceptedFreezeException Beta AcceptedBlocker Final - This would be a good thing to have fixed during Beta so accepted as an FE for Beta. It was also voted as a blocker for final in case a fix doesn't surface in time.
16:43:27 <roshi> #topic (1260318) TypeError: uid should be integer, not str
16:43:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1260318
16:43:28 <roshi> #info Proposed Blocker, anaconda, POST'
16:44:07 <kparal> adamw: we know you're actually playing tennis and just get back every time you finish a set. it's _obvious_
16:44:37 <roshi> point
16:44:48 <adamw> heh
16:45:49 <kparal> pity that dshea hasn't actually told us what was wrong and how often it occurs
16:46:18 <roshi> yeah
16:46:27 <kparal> ask him or trust his judgement?
16:46:48 <roshi> ask
16:47:12 * kparal asked
16:47:17 <adamw> looks like it's re-use of an existing /home
16:47:21 <adamw> anaconda.log is fairly informative
16:47:28 <adamw> 23:35:04,127 INFO anaconda: Home directory for the user raven already existed, fixing the owner and SELinux context.
16:47:28 <adamw> 23:35:04,433 DEBUG anaconda: running handleException
16:47:28 <adamw> 23:35:04,435 CRIT anaconda: Traceback (most recent call last):
16:48:12 <adamw> looks like it happens if you re-use an existing /home partition and create a user who has a homedir in it
16:48:25 <roshi> lot of depreciation warnings in there...
16:48:39 <kparal> if it happens every time, then sure +1. but that's the question
16:48:49 <adamw> anaconda tries to fix selinux labels and ownership UIDs in that case, and uses the wrong type for the uid.
16:48:52 <kparal> oh, you mean the home dir has to exist already?
16:49:06 <roshi> so it seems
16:49:12 <adamw> kparal: my bet would be it happens any time you re-use an existing /home and create a user who has a homedir on it already.
16:49:26 <kparal> I would be OK with +1 Final for this
16:49:30 <adamw> which isn't strictly *every* time, but seems like it'd be pretty common - why re-use an existing /home but not re-use the user accounts on it?
16:49:53 <adamw> so i'd be OK with +1 here as a conditional violation, on the basis that it seems like it'd happen pretty often when you do what the criterion says in real life
16:50:06 <kparal> I'm in a habit or renaming the homedir first, but it sounds reasonable to assume anaconda should be capable of handling this
16:50:29 <kparal> it just never occurred to me to trust anaconda in this regard :)
16:50:36 <roshi> I've reused my /home in almost all my installs - so I'd expect it to work
16:50:37 <adamw> that's why they have this special sauce code for twiddling selinux contexts and ownership, yes. :P
16:50:46 <kparal> <davidshea> kparal: I mean any time you're creating a user that was already present on the existing /home. it happens when changing the uid+gid of the existing /home to the new ids
16:50:46 <roshi> +1
16:50:58 <adamw> score one for the monkey!
16:51:04 <kparal> adamw++
16:51:04 <zodbot> kparal: Karma for adamwill changed to 11 (for the f22 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:51:57 <kparal> I'm fine with both +1 Beta and +1 Final
16:52:08 <roshi> +1 beta is my vote
16:52:13 <sgallagh> +1 beta
16:53:09 <adamw> +1 beta
16:53:20 <roshi> proposed #agreed - 1260318 - AcceptedBlocker Beta - This bug is a conditional violation of the "assign mount points to existing storage volumes" criterion, as it fails when attempting to reuse /home.
16:53:25 <adamw> ack
16:53:33 <sgallagh> patch
16:53:45 <roshi> go for it
16:53:45 <sgallagh> proposed #agreed - 1260318 - AcceptedBlocker Beta - This bug is a violation of the "assign mount points to existing storage volumes" criterion, as it fails when attempting to reuse /home.
16:53:49 <roshi> you have the chair
16:53:53 <sgallagh> Not "conditional"
16:54:15 <roshi> sure
16:54:16 <roshi> ack
16:55:49 <kparal> ack
16:55:51 <roshi> other acks
16:55:52 <roshi> ?
16:56:11 <roshi> sgallagh: you can do the #agreed
16:56:12 <adamw> still ack
16:57:18 <roshi> #agreed - 1260318 - AcceptedBlocker Beta - This bug is a violation of the "assign mount points to existing storage volumes" criterion, as it fails when attempting to reuse /home.
16:57:22 <roshi> #topic (1260875) Cannot log in as root after install of recent Fedora 23 images
16:57:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1260875
16:57:28 <roshi> #info Proposed Blocker, anaconda, MODIFIED
16:58:03 <adamw> it was actually surprisingly difficult to find a criterion this hits - one of those 'well OBVIOUSLY it should be a blocker' things
16:58:08 <adamw> especially when sudo works
16:58:19 <adamw> so i recommend we wave our hands and vote +1 without thinking about it too hard!
16:58:20 <roshi> yeah, I had noticed that :p
16:58:35 <kparal> +1
16:58:52 <roshi> +1
16:58:58 <sgallagh> adamw: The basic login criterion?
16:59:13 <sgallagh> The vast majority of Server installations only have a root user
17:00:09 <roshi> that's a fair point
17:00:28 <adamw> eh, that criterion fairly clearly implies 'user account'
17:00:36 <sgallagh> hmm
17:00:39 <adamw> but yeah, it's not worth getting too deep into it i don't think, since we have a fix let's just wave hands and move oN!
17:00:45 <sgallagh> ok
17:00:54 <sgallagh> I'd still argue that 'root' is a user account
17:00:55 <adamw> we might want to add an explicit root requirement there though, yeah. do you want to draft one up?
17:01:03 <sgallagh> I'll see what I can do
17:01:08 <roshi> sgtm
17:01:53 <roshi> proposed #agreed - 1260875 - AcceptedBlocker Beta - This bug is a violation of the following Beta criterion: "The default system init daemon (e.g. systemd) must be capable of starting, stopping, enabling and disabling correctly-defined services."
17:02:02 <sgallagh> adamw: Ooh, I've got one that already applies
17:02:09 <kparal> ack
17:02:12 <sgallagh> "It must be possible to log in to the default Cockpit instance"
17:02:59 <adamw> sgallagh: hah, neat.
17:03:14 <adamw> yeah, i guess that'd work.
17:03:45 <roshi> proposed #agreed - 1260875 - AcceptedBlocker Beta - This bug is a violation of the following Beta criterion: "It must be possible to log in to the default Cockpit instance"
17:03:55 <adamw> ack
17:04:11 <kparal> ack
17:04:22 <sgallagh> ack
17:04:23 <roshi> #agreed - 1260875 - AcceptedBlocker Beta - This bug is a violation of the following Beta criterion: "It must be possible to log in to the default Cockpit instance"
17:04:26 <roshi> #topic (1245838) Upgrade to F23 crashes early in upgrade boot
17:04:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1245838
17:04:31 <roshi> #info Proposed Blocker, fedup, NEW
17:06:23 <kparal> it would be fun if system-upgrade got reverted
17:06:33 <kparal> but as it stands now, -1, fedup is obsolete
17:07:30 <sgallagh> Right, -1, we've moved on
17:07:42 <sgallagh> (And system-upgrade works quite nicely)
17:07:52 <kparal> haha
17:07:54 <adamw> sgallagh: mmmm, arguable :P
17:08:03 <kparal> I have an opposite experience
17:08:16 <roshi> -1 then since this is just a procedural thing at this point?
17:08:24 <kparal> yes
17:08:27 <adamw> but yeah, clearly -1 for this now with the fesco decision and i've updated all the wiki stuff to point to dnf-system-upgrade so we don't have any inconsistencies in the rules here
17:08:53 <roshi> proposed #agreed - 1245838 - RejectedBlocker Beta - This is no longer a blocker because fedup is no longer the official supported means of updating a system.
17:09:03 <adamw> note - openQA testing of dnf-system-upgrade will land today, but please do run manual tests with different situations and package sets
17:09:08 <adamw> ack
17:09:21 <kparal> oh, very cool
17:09:26 <kparal> ack
17:09:34 <roshi> #agreed - 1245838 - RejectedBlocker Beta - This is no longer a blocker because fedup is no longer the official supported means of updating a system.
17:09:43 <roshi> #topic (1257131) System reboots after shutdown
17:09:43 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1257131
17:09:43 <roshi> #info Proposed Blocker, kernel, NEW
17:12:32 <roshi> -1, seems very hardware specific
17:13:03 <sgallagh> -1 Blocker, +1 FE
17:13:06 <kparal> I assume it's not really widespread
17:13:18 <kparal> but that's just a guess
17:13:46 <kparal> -1 sounds fine to me. +1 fe as well
17:13:57 <adamw> i've been kinda following this one
17:14:33 <kparal> stalker
17:14:43 <adamw> hard to guess precisely what the impact is, but it's one of those things that's been bouncing around for a while, fiddly firmwares and the kernel trying to cope
17:15:07 <adamw> it is a bit nasty since it affects laptops - you can shut down your laptop, stuff it in a bag, then two hours later realize your battery's dead and your bag's melting
17:15:36 <adamw> but yeah, i'd have to say the impact is likely not quite broad enough for blocker
17:15:43 <roshi> proposed #agreed - 1257131 - RejectedBlocker AcceptedFreezeException - This bug doesn't impact enough hardware to warrant blocker status, but getting a fix in for Beta would be great.
17:15:47 <adamw> and we can document the issue and workaround now
17:15:51 <roshi> yeah
17:15:56 <adamw> ack
17:16:54 <kparal> ack
17:16:56 <roshi> #agreed - 1257131 - RejectedBlocker AcceptedFreezeException - This bug doesn't impact enough hardware to warrant blocker status, but getting a fix in for Beta would be great.
17:17:03 <roshi> #topic (1261637) anaconda cannot create users with lorax < 23.17-1
17:17:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1261637
17:17:09 <roshi> #info Proposed Blocker, lorax, ON_QA
17:18:10 <roshi> +1 to either
17:18:12 <kparal> +1
17:18:15 <roshi> another procedural
17:18:24 <adamw> yeah, sorry about this
17:18:48 <adamw> so what happened is releng actually used lorax 23.17-1 for TC4 compose already
17:18:55 <roshi> proposed #agreed - 1261637 - AcceptedBlocker Beta - This bug is required to be fixed in order to cut the release. Accepting as a blocker for this purpose.
17:19:00 <adamw> and it *sounds* like compose wouldn't work at all with the older lorax that's in stable, but i couldn't find a clear bug  for it
17:19:17 <roshi> it happens
17:19:18 <adamw> so instead i filed a bug for an issue which was at least clearly documented in the lorax changelog
17:19:38 <adamw> this is at least an FE in its own right, i figure
17:19:43 <roshi> yeah
17:19:57 <roshi> it needs to happen, this is just a vehicle to make it so
17:20:41 <adamw> i'd prefer we pretend to accept it for what the bug actually is, for future deniability :P
17:21:18 <roshi> proposed #agreed - 1261637 - RejectedBlocker AcceptedFreezeException Beta - This bug is required to be fixed in order to cut the release. Accepting as an FE for this purpose.
17:21:21 <adamw> so proposed #agreed - 1261637 - AcceptedBlocker Beta - violates 'working mechanism to create user account' criterion in case of a minimal install
17:21:23 <roshi> that bettar?
17:21:28 <adamw> how about mine?
17:21:31 <roshi> ack to adamw
17:21:36 <roshi> you have chair, as well
17:21:37 <adamw> that avoids the i-s issue because there's no i-s in minimal, and we block on minimal
17:21:53 <adamw> so without this fix, we'd have no working user account creation for a minimal install
17:22:20 <kparal> ack
17:23:14 <sgallagh> ack
17:23:35 <adamw> #agreed - 1261637 - AcceptedBlocker Beta - violates 'working mechanism to create user account' criterion in case of a minimal install
17:23:43 <roshi> #topic (1260799) pyanaconda.bootloader.BootLoaderError: failed to set new efi boot target. This is most likely a kernel or firmware bug.
17:23:46 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1260799
17:23:48 <roshi> #info Proposed Blocker, python-blivet, POST
17:24:46 * adamw looks back at what we did with a similar bug in alpha
17:26:01 <adamw> ah, we accepted it as a beta blocker
17:26:17 <adamw> so that's good, i'm instinctively +1 beta on this and that matches with what we did before.
17:26:26 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1235323 is the bug i'm thinking of. see #c12
17:26:32 <kparal> +1
17:26:57 <adamw> as before, the system will still boot if the fallback path stuff works, but we know of cases where it won't, so this can break boot.
17:27:31 <roshi> +1
17:27:35 * roshi remembers this one
17:27:36 <sgallagh> +1
17:28:31 <roshi> proposed #agreed - 1260799 - AcceptedBlocker Beta - This bug is a clear violation of the following criterion: "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:28:37 <adamw> ack
17:28:59 <sgallagh> ack
17:29:11 <roshi> #agreed - 1260799 - AcceptedBlocker Beta - This bug is a clear violation of the following criterion: "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:29:21 <roshi> #topic (1261439) blivet.errors.DeviceError: ('cannot replace active format', 'pv00')
17:29:24 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1261439
17:29:26 <roshi> #info Proposed Blocker, python-blivet, POST
17:30:22 <roshi> +1
17:30:51 <kparal> +1
17:31:18 <adamw> sure, +1
17:31:22 <sgallagh> +1
17:31:32 <roshi> proposed #agreed - 1261439 - AcceptedBlocker Beta - This bug is a clear violation of the following criterion: "When using the guided partitioning flow, the installer must be able to:"
17:31:47 <roshi> proposed #agreed - 1261439 - AcceptedBlocker Beta - This bug is a clear violation of the following criterion: "When using the guided partitioning flow, the installer must be able to:...Remove existing storage volumes to free up space, at the user's direction"
17:31:54 <adamw> ack
17:31:55 <roshi> not sure how a newline got into that first one
17:32:14 <sgallagh> ack
17:32:30 <kparal> ack
17:32:43 <roshi> #agreed - 1261439 - AcceptedBlocker Beta - This bug is a clear violation of the following criterion: "When using the guided partitioning flow, the installer must be able to:...Remove existing storage volumes to free up space, at the user's direction"
17:33:00 <roshi> that's it for beta proposals
17:33:05 <roshi> onto the 3 for final
17:33:13 <roshi> #topic (1256531) dnf install crashes if terminal window is too small
17:33:16 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1256531
17:33:17 <danofsatx> looks like i got here just in time
17:33:18 <roshi> #info Proposed Blocker, dnf, NEW
17:34:16 <adamw> fun one
17:34:33 <roshi> yeah
17:34:56 <sgallagh> I'm -1 blocker on this.
17:35:00 <kparal> +1
17:35:02 <sgallagh> I could happily be +1 FE
17:35:09 <adamw> i'm +1, noting the important detail that it crashes *halfway through package install*
17:35:15 <kparal> this can easily destroy user's system
17:35:17 <sgallagh> But this is so obscure that I'm not willing to block while it gets fixed.
17:35:21 <adamw> that we  really, really, really never want to happen, because it completely fucks the system
17:35:24 <sgallagh> Ah, hmm
17:35:28 <roshi> yeah, it destroys things
17:35:29 <danofsatx> -1
17:35:31 <adamw> anything known to cause that to happen needs to be fixed for me.
17:35:33 <kparal> we have a data loss criterion
17:36:01 <kparal> and it's in a system critical tool
17:36:10 <sgallagh> Does it really cause data loss? That was unclear.
17:36:10 <roshi> yeah
17:36:10 <adamw> well, a package update in theory shouldn't ever touch user data, so that one doesn't feel quite right
17:36:28 <kparal> sgallagh: "This resulted in half of the rpms getting installed and half of them not "
17:36:36 <adamw> but either the cited criterion or just one of the basic 'system must work' ones - if you get unlucky with this, your system stops working.
17:36:39 <sgallagh> The error says the transaction was aborted.
17:36:50 <sgallagh> Which *should* mean that the state was restored. Is that not the case?
17:37:03 <kparal> https://bugzilla.redhat.com/attachment.cgi?id=1066623
17:37:06 <adamw> no, rpm doesn't do that.
17:37:06 <sgallagh> (Or does DNF have a non-standard definition of the word "transaction")
17:37:07 <adamw> Installing  : minizip-1.2.8-7.fc22.x86_64                                     12/58
17:37:28 <adamw> at that point, the new versions of packages 1-11 have been installed. that's done.
17:37:29 <danofsatx> How "common" is shrinking a terminal window while dnf is running? I minimize it or send it to the background - gnome is supposed to notify the user when a process finishes in a term window anyhow
17:37:41 <kparal> it would be nice if we had atomic transactions
17:37:54 <sgallagh> danofsatx: I've never heard of anyone doing it before, personally
17:38:09 <kparal> danofsatx: you have to weigh "how common" against "how severe is the outcome"
17:38:19 <roshi> I know people who do it
17:38:34 <adamw> but any %posttrans doesn't get done, and the %preun / %postun for the old versions don't get run, and the rpm database now has duplicate entries, and the whole thing is a giant pain in the ass to clean up, and if anything in 13-58 needed to go along with 1-12 you're in a mess
17:38:38 <adamw> (yes, rpm sucks).
17:38:52 <adamw> right, i'm with kparal
17:38:56 <roshi> same here
17:38:59 <adamw> *one* person hitting this bug is already too many. it needs fixed.
17:39:08 <roshi> it's corner, sure - but it's catastrophic
17:39:20 <sgallagh> I guess I'd be +1 for Final
17:39:22 <roshi> personally, this is one of my favorite bugs
17:39:26 <adamw> sgallagh: this is proposed for Final
17:39:28 <sgallagh> But I'm really not sure I'm that hard-line on beta
17:39:30 <roshi> and yeah, this is final
17:39:31 <sgallagh> Oh, I missed that
17:39:36 <roshi> we're onto the Final proposals
17:39:49 <sgallagh> +1 Final blocker :)
17:39:54 <adamw> sgallagh: have you never had to fight a system which crashed in the middle of an update before? it's just about my #1 least favourite thing to do (well, ok, maybe #2 after 'anything involving php')
17:40:23 <sgallagh> adamw: Of course, I've been working on Fedora for more than a month ;-)
17:40:42 <kparal> try to accidentally close the terminal while running dnf update ;)
17:40:42 <adamw> yeah, that's why i was surprised. :p
17:40:56 <roshi> proposed #agreed - 1256531 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "The installed system must be able to download and install updates with the default console package manager." This bug also has the potential to basically destroy a user's system.
17:41:11 <adamw> i think it's actually provably impossible to properly 'complete' the transaction - you can hack it up, but you can never get the actual scriptlets which should have run to run with the correct conditions, you just have to hope none of them were terribly important
17:41:14 <sgallagh> kparal: I have 'dnf' aliased to 'screen dnf' for a reason :-D
17:41:23 <kparal> roshi: probably not a "clear violation"
17:41:36 * adamw knows all this, and yet still upgrades his system to Rawhide using a dnf running in gnome-terminal, because he's a giant idiot
17:41:52 <adamw> yeah, 'conditional violation' would be better
17:41:52 <danofsatx> s/clear//
17:41:55 <roshi> kk
17:42:04 <adamw> and maybe 'but we're accepting it because it can cause catastrophic damage' or similar
17:42:38 <roshi> proposed #agreed - 1256531 - AcceptedBlocker Final - This bug is a conditional violation of the following criterion: "The installed system must be able to download and install updates with the default console package manager." We're accepting this because it can cause catastrophic damage to the system.
17:42:48 <adamw> ack
17:43:28 <kparal> ack
17:44:10 <danofsatx> reluctant ack, but ack nonetheless
17:44:14 <roshi> #agreed - 1256531 - AcceptedBlocker Final - This bug is a conditional violation of the following criterion: "The installed system must be able to download and install updates with the default console package manager." We're accepting this because it can cause catastrophic damage to the system.
17:44:22 <roshi> #topic (1261034) dnf doesn't handle Obsoletes (for split packages)
17:44:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1261034
17:44:27 <roshi> #info Proposed Blocker, dnf, NEW
17:45:43 <danofsatx> +1
17:46:00 <sgallagh> This sounds really familiar...
17:46:20 * roshi is looking for a criteria
17:46:39 <sgallagh> I swear I filed this same bug in like F18 era
17:46:54 <adamw> yeah, sounds oddly familiar to me too
17:46:58 <danofsatx> same criteria as last one
17:47:11 <danofsatx> "The installed system must be able to download and install updates with the default console package manager."
17:47:12 <roshi> The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops.
17:47:22 <roshi> oh, right
17:47:30 <roshi> +1
17:47:34 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1260394 seems to be the bug that's actually caused by this
17:47:37 <adamw> i don't think it's quite that clear cut
17:47:48 <adamw> dnf will run happily - it just doesn't install the packages the packager intended to get installed
17:48:13 <danofsatx> and leaves an unstable system behind
17:48:14 <sgallagh> adamw: I'd categorize that as failing to install updates, honestly
17:48:25 <adamw> personally i would be happier to vote +1 to 1260394 (the practical bug here) as violating the upgrade criterion
17:48:28 <sgallagh> The fact that the updated package has a different name is irrelevant
17:48:50 <adamw> "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ...  The upgraded system must meet all release criteria."
17:49:06 <kparal> I'd like to see a response from some dnf developer
17:49:11 <danofsatx> yeah, that sounds mo' bettah
17:49:15 <adamw> sgallagh: it's not a straightforward rename
17:49:33 <sgallagh> adamw: It kind of is.
17:49:43 <adamw> sgallagh: the intent is that when you upgrade from plasma-workspace 5.3.2-7 you get plasma-workspace 5.3.2-8 and sddm-breeze 5.3.2-8
17:49:48 <adamw> in fact you only get plasma-workspace 5.3.2-8
17:50:03 <adamw> that's not a rename, nor did a package go 'missing'. rather one that was expected to be added, wasn't.
17:50:17 <sgallagh> hmm
17:50:43 <adamw> i can go with the update criterion, i don't *hate* it, but i don't think it's totally obvious.
17:51:08 <adamw> we've usually considered that criterion to be something like 'dnf has to not explode', not 'it must behave precisely as expected in all cases'
17:51:30 <sgallagh> Give me a moment to look into the specific case.
17:51:41 <adamw> or even 'precisely as documented by the fedora wiki but perhaps not as intended by dnf developers'
17:51:50 <sgallagh> right
17:51:54 <adamw> (and pete knows what PackageKit does in this case - thinking about it, wasn't the case you found one where PK didn't DTRT?)
17:52:23 <roshi> proposed #agreed - 1261034 - AcceptedBlocker Final - This bug is a violation of the following criterion: ""For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ...  The upgraded system must meet all release criteria."
17:52:44 <adamw> nack/patch
17:52:49 <adamw> that's a more appropriate vote for 1260394
17:52:58 <roshi> ah
17:53:02 <adamw> my suggestion is to take that one instead of this
17:53:09 <roshi> works for me
17:53:10 <adamw> (that one could be set to *depend* on this)
17:53:17 <roshi> brb, call of nature
17:53:31 * kparal is ok with that
17:53:46 <kparal> blocking on the actual issue
17:54:28 <adamw> though i guess the counter-argument is there could be various other problems caused by the tools not doing what the packaging guidelines say they do.
17:55:50 <kparal> in my experience, dnf has been very broken lately (just lately?) and we're going to see much more fun yet
17:56:47 <adamw> in my experience everything is terrible and we should just go drink
17:57:41 <kparal> yes, that's what IT does to a person
17:58:00 <sgallagh> adamw: What makes you think we haven't been drinking through this whole meeting?
17:58:56 <adamw> sgallagh: saying we should 'go drink' doesn't suggest we're not drinking already, just a change of scenery...
17:59:04 <adamw> so, sounds like we want to take one or the other, which is it going to be?
17:59:13 <roshi> +1 to 1260394 blocking
17:59:24 <roshi> it already depends on the proposed bug
17:59:57 <roshi> proposed #agreed - 1260394 - AcceptedBlocker Final - This bug is a violation of the following criterion: ""For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ...  The upgraded system must meet all release criteria."
18:00:01 <adamw> ack
18:00:14 <roshi> and I'll remove the blocker status of the original proposal as well
18:00:16 <kparal> ack
18:00:19 <roshi> well, the proposal
18:00:26 <adamw> we'd better keep an eye on what the dnf team says on 1261034 so we can take appropriate action if they just go 'meh'
18:01:17 <roshi> yeah
18:03:09 <adamw> one more ack?
18:03:12 <kalev> ack
18:03:15 * kalev just looked in.
18:03:27 <roshi> #agreed - 1260394 - AcceptedBlocker Final - This bug is a violation of the following criterion: ""For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ...  The upgraded system must meet all release criteria."
18:03:32 <danofsatx> ack
18:03:40 <roshi> #topic (1261721) preexisting LUKS /home cannot be assigned as mountpoint for new installation
18:03:43 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1261721
18:03:46 <danofsatx> wtf? talk about lag....sheesh
18:03:46 <roshi> #info Proposed Blocker, python-blivet, NEW
18:03:47 <roshi> this is the last proposed blocker
18:05:04 <roshi> not 100% sure that's the best criteria for it, but +1 for this blocking
18:05:11 * roshi always reuses /home
18:05:38 <adamw> yeah, i'd more make it a conditional violation of the 'must be able to re-use' criterion we used earlier in the case of the device being encrypted
18:05:49 <roshi> yeah
18:05:50 <kparal> I suppose this is an encrypted partition, not a partition on an encrypted disk. does that make any difference?
18:05:52 <adamw> perhaps encrypted in a specific way? the bug seems to be weirdly coy about whether it was actually a typical f22 encrypted install
18:06:07 <adamw> or whether this was manually encrypted in some clever way or something
18:06:21 <adamw> so i guess i'm +1 so long as cmurf didn't do something too clever-clever and unusual
18:06:54 <sgallagh> Perhaps we should test this before voting?
18:07:00 <sgallagh> /me spins up a TC4 VM
18:07:21 <danofsatx> is this a blivet, LUKS, or btrfs error?
18:07:21 <adamw> you'll have to do an f22 install first, i guess
18:07:24 <kparal> I'd punt this, because the screenshot indicates it might be by design for some reason
18:07:55 <sgallagh> adamw: Nah, just two F23 installs
18:08:04 <kparal> let's wait for dlehman's response
18:08:42 <roshi> proposed #agreed - 1261721 - Punt - We'd like some more info on this before voting.
18:08:42 <sgallagh> Let's come back to this after the Approved Blockers
18:08:47 <sgallagh> I'll test this in the meantime
18:08:49 <roshi> i'm fine for punting
18:08:57 <roshi> we got FEs for beta to look through
18:09:01 <danofsatx> kickit
18:09:14 <kparal> ack
18:09:19 <danofsatx> ack
18:09:29 <kalev> ack
18:09:34 <roshi> #agreed - 1261721 - Punt - We'd like some more info on this before voting.
18:09:58 <roshi> move onto FE's?
18:10:06 <roshi> there are 4 proposed for beta
18:10:57 <kparal> yes
18:10:59 <adamw> yeah, we're frozen so we need to do them
18:11:17 <roshi> #topic (1239089) /etc/issue in Fedora server should contain cockpit URL
18:11:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1239089
18:11:22 <roshi> #info Proposed Freeze Exceptions, fedora-release, ON_QA
18:12:37 <kalev> makes sense to me to pull it in
18:13:04 <roshi> should already be fixed...?
18:13:10 <sgallagh> Yes and no
18:13:10 <roshi> +1
18:13:15 <roshi> it was already alpha FE
18:13:33 <sgallagh> There's a small bug in it that I'd also like to see pulled in, but no rush
18:13:48 <sgallagh> But +1
18:13:59 <kalev> +1
18:14:37 <roshi> proposed #agreed - 1239089 - AcceptedFreezeException Beta - It would be good to get this pulled in during freeze.
18:14:39 <adamw> sure
18:14:40 <adamw> ack
18:14:42 <danofsatx> ack
18:14:49 <kparal> ack
18:14:54 <roshi> #agreed - 1239089 - AcceptedFreezeException Beta - It would be good to get this pulled in during freeze.
18:14:54 <kalev> ack
18:14:57 <roshi> #topic (1254299) f23 workstation x86_64 Alpha-2 live locks up
18:15:00 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1254299
18:15:02 <roshi> #info Proposed Freeze Exceptions, kernel, NEW
18:15:12 <kalev> -1 here, looks like already fixed
18:15:53 <kalev> looks like it's an old ticket filed when Alpha was fresh out
18:16:13 <roshi> yeah, looks like it
18:16:15 <roshi> -1
18:16:41 <sgallagh> -1
18:16:48 <roshi> proposed #agreed - 1254299 - RejectedFreezeException Beta - This issue seems to be resolved and no longer requires FE status.
18:16:57 <kalev> ack
18:17:06 <sgallagh> BTW, I have feedback on the encrypted drive bug.
18:17:10 <kparal> ack
18:17:15 <sgallagh> My experience appears to be even worse than his
18:18:28 <roshi> sgallagh: ack?
18:18:34 <sgallagh> ack
18:18:39 <roshi> #agreed - 1254299 - RejectedFreezeException Beta - This issue seems to be resolved and no longer requires FE status.
18:18:50 <roshi> we've 2 more FE's
18:19:04 <roshi> go back to encrypted bug after these work?
18:19:22 <sgallagh> roshi: I'll update the BZ in the meantime
18:19:28 <roshi> kk, sweet
18:19:29 <roshi> #topic (1259630) BeagleBone black not booting from MMC
18:19:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1259630
18:19:29 <roshi> #info Proposed Freeze Exceptions, kernel, ON_QA
18:19:33 <kalev> -1, looks like another stale ticket
18:19:36 <kalev> from the ticket: "This is fixed in kernel-4.2.0-0.rc8.git1.1.fc24, latest is f-23 GA is kernel-4.2.0-0.rc8.git0.1.fc23"
18:19:44 <kalev> we have kernel-4.2.0-300.fc23 in stable
18:20:11 <roshi> seems like it
18:20:21 * adamw looks for a pbrobinson
18:20:26 <adamw> would like to double-check this
18:21:32 <roshi> sgtm
18:22:06 <kalev> there's no newer kernel available anyway; if something needs fixing I am sure he'll repropose a newer kernel as the newer build becomes available
18:23:18 <kalev> I don't think it makes much sense to evaluate FE's that have no linked builds
18:23:26 <adamw> no reply from pbrobinson...
18:23:29 <kalev> or in this case, the linked build is already in stable
18:23:32 <roshi> punt then?
18:23:35 <roshi> we revisit it monday
18:23:36 <adamw> yeah, i'd just like to be clear if there's anything else needed
18:23:40 <roshi> so it's not a long punt
18:23:52 <adamw> yeah, just punt and we'll ask ARM folks to update it
18:24:06 <roshi> proposed #agreed - 1259630 - Punt - We'd like more info from the ARM folks before we vote on this.
18:24:14 <kalev> ack
18:24:27 <adamw> ack
18:24:34 <roshi> #agreed - 1259630 - Punt - We'd like more info from the ARM folks before we vote on this.
18:24:38 <roshi> #topic (1240147) SugarExt can not be loaded properly, blocking Sugar startup
18:24:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1240147
18:24:43 <roshi> #info Proposed Freeze Exceptions, sugar-toolkit-gtk3, ON_QA
18:25:07 <kalev> sure, +1
18:25:34 <kalev> seems like a bad issue for Sugar and the fix is nice and small and self contained
18:25:56 <satellit_e> +1
18:26:25 <danofsatx> +1
18:26:39 <sgallagh> +1
18:27:31 <roshi> proposed #agreed - 1240147 - AcceptedFreezeException Beta - This is a small, self-contained fix that would be good to pull in.
18:27:46 <kalev> ack
18:27:58 <kparal> ack
18:28:03 <satellit_e> ack
18:28:04 <roshi> #agreed - 1240147 - AcceptedFreezeException Beta - This is a small, self-contained fix that would be good to pull in.
18:28:06 <danofsatx> ack
18:28:08 <sgallagh> ack
18:28:24 <roshi> back to the encryption bug?
18:28:56 <danofsatx> there's a new beta proposal, too - https://bugzilla.redhat.com/show_bug.cgi?id=1259443
18:29:43 <roshi> ok, let's do that one then
18:29:44 <roshi> #topic (1259443) Add brw_meta_fast_clear crash workaround patch
18:29:44 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1259443
18:29:44 <roshi> #info Proposed Blocker, mesa, ASSIGNED
18:29:49 <danofsatx> +1
18:29:53 <danofsatx> this one sux
18:30:08 <kalev> yes, would be nice to pull that in
18:30:09 <kalev> +1
18:30:20 <danofsatx> lock screen, walk away, come back to many, many, many drkonqi popups.
18:30:25 <kalev> if it passes testing, of course -- mesa patches are always scary
18:30:39 * danofsatx will test it soon. very soon.
18:30:51 <roshi> that sounded like a threat, danofsatx :p
18:31:07 <danofsatx> it is.....mwahahahah
18:31:12 <roshi> "...soon. Very soon..." (cue maniacal laughter)
18:31:51 <danofsatx> if it fails, I will be hunting down a mesa developer that somehow got a patch through with no karma.
18:33:29 <kparal> seems +1
18:34:17 * kparal looking at Beta criteria
18:34:35 <adamw> sure, +1
18:35:58 <roshi> kparal: you find a criterion?
18:36:20 <kparal> maybe "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional. "?
18:36:29 <kparal> since it takes down the whole session
18:36:38 <roshi> makes sense to me
18:36:55 <kparal> not sure how often that happens
18:37:16 <kparal> seems like often
18:37:25 <roshi> proposed #agreed - 1259443 - AcceptedBlocker Beta - This bug is a conditional violation of the following criterion: "No part of any release-blocking desktop's panel (or equivalent) configuration may  crash on startup or be entirely non-functional."
18:37:28 <danofsatx> very. lock screen, unlock screen, it's crashed.
18:37:42 <kparal> ack
18:37:49 <danofsatx> ack
18:37:50 <kalev> ack
18:37:59 <roshi> #agreed - 1259443 - AcceptedBlocker Beta - This bug is a conditional violation of the following criterion: "No part of any release-blocking desktop's panel (or equivalent) configuration may  crash on startup or be entirely non-functional."
18:38:19 <roshi> #topic (1261721) preexisting LUKS /home cannot be assigned as mountpoint for new installation
18:38:22 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1261721
18:38:24 <roshi> #info Proposed Blocker, python-blivet, NEW
18:40:26 <adamw> this is another new proposed beta?
18:40:33 <roshi> nah
18:40:36 <adamw> oh, back to the encryptred thing
18:40:38 <roshi> this is the one sgallagh was retesting
18:40:39 * adamw needs to stop multitasking
18:40:42 <roshi> er
18:40:48 <roshi> reproducing
18:41:05 <sgallagh> Right, so I couldn't reproduce the exact case he hit, because I couldn't get that far :(
18:41:29 <sgallagh> (I will note that cmurf's setup involves a lot of btrfs mumbo-jumbo, but my straightforward test still has issues)
18:42:17 <adamw> still, we're voting on *this* bug
18:42:19 <adamw> not a similar one
18:42:32 <roshi> while I expect it to work, is reusing an encrypted /home within the "The requirement "assign mount points to existing storage volumes" is considered to cover the common operation of re-using an existing /home partition without formatting it. For all other mount points, it is acceptable if re-use requires them to be re-formatted."
18:42:37 <roshi> ?
18:42:57 <adamw> well, it's a conditional violation - the condition being that the existing /home is encrypted.
18:43:21 <adamw> and of course it matters whether this happens with *any* encrypted /home, or only with some cmurf special layout.
18:43:21 <sgallagh> Well, I suspect that the bug is "anaconda can't handle encrypted partitions properly"
18:43:22 <roshi> I'm fine with +1 for this
18:43:31 <adamw> sgallagh: what exactly happened in your case?
18:43:37 <sgallagh> And the difference is that I have full-disk encryption vs. his partition encryption
18:43:57 <adamw> oh, is ee your comment now
18:44:23 <adamw> i'd say your bug is clearly not the same as cmurf's bug, so it should be proposed and discussed separately.
18:45:07 <sgallagh> /me shrugs
18:47:28 <adamw> in general i guess i'd like to get anaconda team's feedback here
18:47:48 <roshi> so, sgallagh to file a new bug, punt for feedback?
18:47:54 <sgallagh> whee :-/
18:49:39 <adamw> i'd be more inclined to block straight away on a straightforward 'do an anaconda default encrypted install, then try and re-use it' case like sgallagh's
18:49:49 <adamw> cmurf's reports often turn out to hinge on super magical layouts he comes up with
18:51:23 <kparal> a bit like my reports :)
18:51:29 <roshi> I think they might be the same bug, tbh
18:51:41 <roshi> anaconda not dealing with luks well
18:52:27 <adamw> roshi: cmurf's description strongly suggests that unlocking the encrypted partition succeeded in his case.
18:52:39 <adamw> whereas sgallagh states that anaconda hangs while trying to unlock.
18:52:47 <adamw> those sound an awful lot like different problems to me.
18:53:00 <adamw> cmurf says "2. Launch Fedora 23 installer, custom partitioning, click on LUKS volume and unlock. 3. Select unlocked LUKS volume..."
18:53:11 <adamw> and does not mention any hang.
18:53:29 <roshi> we're nearing the end of the timeslot - so what do we want to do for these two?
18:53:34 <roshi> true
18:53:51 <roshi> propose a second bug and punt for info?
18:54:29 <adamw> my suggestion would be a separate bug for sgallagh's case, and punt cmurf's case for info. i wouldn't be opposed to +1ing sgallagh's bug immediately, if others wanted to
18:54:41 <roshi> I'd be ok with that as well
18:55:13 <roshi> proposed #agreed - 1261721 - Punt - We'd like some more information on this bug and clearer reproduction steps before we vote.
18:55:17 <adamw> ack
18:56:47 <adamw> sgallagh: wdyt?
18:57:12 <sgallagh> sorry, got pulled away.
18:57:19 <sgallagh> I'll file a bug momentarily
18:57:39 <roshi> sounds good
18:57:43 <roshi> acks?
18:57:45 <kparal> ack
18:57:50 <sgallagh> ack
18:57:51 <roshi> #agreed - 1261721 - Punt - We'd like some more information on this bug and clearer reproduction steps before we vote.
18:57:57 <roshi> #topic Open Floor
18:58:08 <roshi> we've only a couple minutes left - anyone got anything
18:58:09 <roshi> ?
18:58:11 <kparal> there was one bug sgallagh wanted to demote...
18:58:26 <roshi> sgallagh: when you get that bug filed, just mention it in fedora-qa and we can vote in ticket
18:58:26 <kparal> or repropose?
18:58:37 * roshi has to depart at the top of the hour
18:58:49 <roshi> or someone else can take over
18:58:54 <kparal> ah, this one: https://bugzilla.redhat.com/show_bug.cgi?id=1256712
18:58:56 * adamw can take over for one demotion
18:59:05 <kparal> c7
18:59:07 * adamw will secretarialize post-meeting
18:59:28 <roshi> ah, thanks - I was going to do it when I got back
18:59:33 <kparal> I think moving it to Final sounds reasonable
18:59:37 * adamw hates un-blocking when the reason is 'the guy who can fix it is on vacation', but was never super-sold on this as a beta blocker really
18:59:45 <adamw> so i don't hate moving to final and documenting
19:00:06 <adamw> roshi: i want to co-ordinate a new anaconda build with sbueno so i'll do it next
19:00:18 <kparal> btw, it seems to affect my Broadwell as well, but more likely as a race - sometimes works, sometimes not
19:00:45 <roshi> thanks adamw
19:00:55 <adamw> so, votes for moving this to final?
19:00:56 <roshi> thanks for coming
19:01:02 <roshi> sorry about the announcement snafu
19:01:07 <roshi> +1 from me
19:01:07 <sgallagh> adamw: Mostly I feel like this is one of those that if it was the last blocker, we'd fudge it at Go/No-Go
19:01:13 <sgallagh> Which to me means it's not really a blocker
19:01:15 <kparal> #topic https://bugzilla.redhat.com/show_bug.cgi?id=1256712
19:01:24 * roshi &
19:01:25 <kparal> +1 to move
19:01:30 <kparal> +1 from pschindl as well
19:01:37 <sgallagh> +1 from me (obviously)
19:02:17 <adamw> proposed #agreed 1256712 - RejectedBlocker Beta AcceptedBlocker Final - this is moved from beta to final blocker; on re-consideration the impact isn't really severe enough to delay the beta release, documenting is sufficient for beta
19:02:29 <kparal> ack
19:02:32 <kalev> ack
19:03:19 <sgallagh> ack
19:04:44 <adamw> #agreed 1256712 - RejectedBlocker Beta AcceptedBlocker Final - this is moved from beta to final blocker; on re-consideration the impact isn't really severe enough to delay the beta release, documenting is sufficient for beta
19:04:49 <adamw> #topic Open Floor
19:04:51 <adamw> alright, anything else?
19:04:52 <sgallagh> I opened https://bugzilla.redhat.com/show_bug.cgi?id=1262086 BTW
19:04:54 * adamw sets the quantum fuse
19:05:03 <sgallagh> For the encrypted drive issue
19:05:08 <adamw> do you want to propose it as a blocker now?
19:05:18 * adamw would probably be +1
19:05:23 <sgallagh> Might as well, yes
19:05:26 * danofsatx looks for the fuse-putter-outter
19:05:29 * kparal is out, see you folks
19:05:44 <sgallagh> Actually, let's wait until Monday.
19:05:54 <sgallagh> I'm going to test it with a partitioning setup created in F22 as well
19:06:02 <sgallagh> Just to narrow down the impact.
19:07:47 <adamw> OK, sounds good
19:08:00 <adamw> we won't get a new anaconda build before then anyway most likely
19:08:04 <adamw> i will ask dlehman to look at it
19:08:14 <sgallagh> I thought sbueno was building anaconda today?
19:08:19 <sgallagh> Or do you mean one with new fixes?
19:08:26 <sgallagh> Which I suppose is more useful information...
19:10:23 <adamw> sgallagh: yeah
19:10:50 <adamw> sgallagh: i mean we clearly don't have a fix for either of these issues right now, so it's not urgent that we make them blockers so we can include a fix or something
19:10:53 <adamw> monday will be early enough
19:11:05 <adamw> alrighty, sounds like we're done here, thanks for coming out, folks
19:11:11 <adamw> #endmeeting