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