17:00:44 <adamw> #startmeeting F26-blocker-review
17:00:44 <zodbot> Meeting started Mon Jan  9 17:00:44 2017 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:44 <zodbot> The meeting name has been set to 'f26-blocker-review'
17:00:44 <adamw> #meetingname F26-blocker-review
17:00:44 <zodbot> The meeting name has been set to 'f26-blocker-review'
17:00:44 <adamw> #topic Roll Call
17:00:58 <adamw> ahoyhoy folks
17:01:02 <adamw> who's around for some blocker review fun?
17:01:17 * coremodule is ready for fun.
17:01:18 * roshi is here
17:01:28 <roshi> I have no checked the list though
17:01:39 * kparal is here, also unprepared
17:02:15 <adamw> oh, me either, i just counted.
17:03:31 <adamw> morning folks
17:03:49 * garretraziel is lurking around, making dinner
17:03:53 <coremodule> Ready for secretary duty.
17:04:02 <adamw> thanks, coremodule
17:04:10 <coremodule> No problem!
17:04:22 <adamw> #chair coremodule roshi
17:04:22 <zodbot> Current chairs: adamw coremodule roshi
17:04:28 <adamw> #topic Introduction
17:04:28 <adamw> Why are we here?
17:04:28 <adamw> #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.
17:04:28 <adamw> #info We'll be following the process outlined at:
17:04:30 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:04:30 <adamw> #info The bugs up for review today are available at:
17:04:32 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:04:34 <adamw> #info The criteria for release blocking bugs can be found at:
17:04:36 <adamw> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
17:04:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
17:04:40 <adamw> #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria
17:04:50 <adamw> #info 4 Proposed Blockers (Alpha)
17:04:56 * pwhalen is here
17:05:10 <adamw> #info 1 Proposed Blocker (Beta)
17:05:20 <adamw> #info 1 Proposed Blocker (Final)
17:05:32 <adamw> #info 2 Accepted Blockers (Alpha)
17:05:43 <adamw> #info coremodule will secretarialize
17:05:53 <adamw> aaand diving right in...
17:05:59 <adamw> #topic (1409177) Kickstart installs fail with Python 3.6
17:05:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1409177
17:05:59 <adamw> #info Proposed Blocker, anaconda, MODIFIED
17:06:30 <pwhalen> +1
17:07:08 <adamw> fix for this should arrive in next compose, though it'll be a bit hard to tell as it seems like new systemd (or something) has completely broken rawhide for the last couple of composes
17:07:19 <adamw> seems pretty clearly a blocker to me
17:07:20 <coremodule> +1
17:07:27 <garretraziel> +1
17:07:33 <kparal> +1
17:07:59 <adamw> proposed #agreed 1409177 - AcceptedBlocker (Alpha) - clearly violates "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account." (as the 'scripted installation mechanism' is entirely broken)
17:08:20 <pwhalen> ack
17:08:28 <coremodule> ack
17:09:05 <roshi> ack
17:09:19 <adamw> #agreed 1409177 - AcceptedBlocker (Alpha) - clearly violates "The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account." (as the 'scripted installation mechanism' is entirely broken)
17:09:30 <adamw> #topic (1410523) gi.overrides.BlockDev.LVMError: Failed to call the 'LvCreate' method on the '/com/redhat/lvmdbus1/Vg/1' object: GDBus.Error:org.freedesktop.DBus.Python.dbus.exceptions.DBusException: ('com.redhat.lvmdbus1.Vg', "Exit code 3, stderr =   --size may not ...
17:09:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1410523
17:09:30 <adamw> #info Proposed Blocker, anaconda, NEW
17:10:03 <adamw> what's the deal with this one, pwhalen? are you hitting it consistently?
17:10:05 <pwhalen> +1 affects all arches, couldnt do a text install
17:10:22 <roshi> +1
17:10:31 <roshi> if it's consistent
17:10:36 <pwhalen> adamw, yes, across all arches (aarch64, x86_64, armhfp)
17:10:49 <adamw> oh, yes
17:10:59 <adamw> the openQA text install test has been hitting this since 2017-01-05, i just didn't notice...
17:11:02 <adamw> so +1
17:11:08 <coremodule> +1
17:11:14 <garretraziel> +1
17:11:48 <kparal> +1
17:12:16 <kparal> is this perhaps because of already existing disk layout?
17:12:33 <adamw> proposed #agreed 1410523 - AcceptedBlocker (Alpha) - violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
17:12:40 <adamw> the openqa test uses a blank disk, iirc
17:12:50 <pwhalen> ack
17:12:56 <roshi> ack
17:12:56 <coremodule> ack
17:13:05 <adamw> yeah, it does. so no, this isn't about existing layout
17:13:45 <adamw> #agreed 1410523 - AcceptedBlocker (Alpha) - violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
17:14:01 <adamw> #topic (1403352) FreeIPA server install fails (and existing servers probably fail to start) due to changes in 'dyndb' feature on merge to upstream BIND
17:14:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1403352
17:14:01 <adamw> #info Proposed Blocker, freeipa, ASSIGNED
17:14:06 <adamw> +1 for me
17:15:06 <roshi> +1
17:15:08 <pwhalen> +1
17:15:58 <coremodule> +1
17:16:22 <adamw> proposed #agreed 1403352 - AcceptedBlocker (Alpha) - violates "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried" (domain controller is a blocking role)
17:16:26 <kparal> ack
17:16:44 <roshi> ack
17:17:02 <garretraziel> ack
17:17:11 <coremodule> ack
17:17:42 <adamw> #agreed 1403352 - AcceptedBlocker (Alpha) - violates "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried" (domain controller is a blocking role)
17:17:52 <adamw> #topic (1408282) TypeError: can't pickle _ped.Alignment objects
17:17:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1408282
17:17:53 <adamw> #info Proposed Blocker, python-blivet, POST
17:18:09 <adamw> this one's addressed in current builds, was just leaving it open to ensure the fix got upstream properly (i patched it in the package)
17:18:13 <adamw> so we can drop the blocker status
17:18:25 <adamw> #info this is addressed in current builds, bug is left open to track fix landing upstream, so removing blocker status
17:18:53 <roshi> sgtm
17:19:14 <adamw> #info that's all the proposed Alpha blockers, moving onto proposed Beta
17:19:25 <adamw> #topic (1376638) rescue mode cannot mount a default Fedora install
17:19:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1376638
17:19:25 <adamw> #info Proposed Blocker, anaconda, ASSIGNED
17:19:43 <adamw> so this isn't failing 100% of the time any more, but it is still failing quite frequently in openQA at least
17:19:50 <adamw> I haven't checked it manually for a b it
17:20:01 <adamw> has anyone else looked into this one?
17:20:19 * roshi hasn't
17:20:48 * pwhalen hasnt but will test on aarch64 today
17:21:12 * coremodule will do the same with x86_64 later today.
17:21:30 <adamw> i guess we can punt this a bit for more investigation
17:21:47 <coremodule> +1 punt for info
17:21:55 <adamw> proposed #agreed 1376638 - punt (delay decision) - the behaviour here seems to have changed a bit in recent rawhide composes, we will investigate manually in more detail
17:22:12 <coremodule> ack
17:22:24 <garretraziel> ack
17:22:26 <roshi> ack
17:22:31 <pwhalen> ack
17:22:42 <adamw> #agreed 1376638 - punt (delay decision) - the behaviour here seems to have changed a bit in recent rawhide composes, we will investigate manually in more detail
17:22:55 <adamw> #topic (1405539) changing the default keyboard layout changes also disk decryption in plymouth, but only after kernel update, long after
17:22:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1405539
17:22:56 <adamw> #info Proposed Blocker, plymouth, NEW
17:23:02 <adamw> so this is kparal's bug from before the holidays
17:23:18 <adamw> i'll give people a bit of time to read it as it's slightly complicated
17:25:15 <kparal> I read a few complains one some forums and then one redhatter complained about something with exactly same consequences, so I investigated
17:25:43 <adamw> so my concern about taking keyboard layout bugs as blockers is, well, the more you scratch the surface, the more you realize there are dozens of the damn things
17:25:56 <kparal> I believe people hit this from time to time, but don't realize at all that a keyboard layout change caused their problems
17:26:23 <adamw> and a lot of them boil down to 'we have multiple very different config/implementation layers for input', which is not easily fixable
17:26:30 <adamw> it seems entirely plausible
17:26:58 <kparal> what I actually wanted here to "resolve" the issue is to a) make UI more informative b) regenerate initramfs immediately. which should not include any keymap rabbit holes
17:27:03 <roshi> oof, that is a doozy
17:27:21 <adamw> kparal: for sure, it just makes it harder not to take the *next* issue someone comes across, and the next, and the next
17:27:36 <mcatanzaro> Not being able to decrypt is really scary. Data loss etc.
17:27:55 <kparal> it's not exactly data loss, just unavailability :)
17:28:00 * adamw could probably spend a week filing bugs with inputting and displaying anything but ASCII / us english...
17:28:31 <adamw> mcatanzaro: while I have you here and we're talking input bugs, btw, https://bugzilla.gnome.org/show_bug.cgi?id=776189 needs fixing :P
17:28:48 <kparal> well I'm arguing here that the basic functionality of gnome-control-center (or some library below it) doesn't work properly. it's not about layouts per se
17:28:59 <mcatanzaro> (adamw: alas :p)
17:29:01 <adamw> kparal: sure
17:29:27 <roshi> while it's a bad bug, I'm not inclined to +1 it as a blocker
17:30:20 <kparal> what annoys me most is that if gnome reverted to changing just user session configuration by default even on single-user systems, most of the problems would be avoided
17:30:27 <kparal> it would still be possible, but not that many would hit it
17:30:42 <kparal> but they don't seem to respond to my requests to revert it
17:30:49 <kparal> (I tried requesting this in the past)
17:30:56 <mcatanzaro> kparal: Link to upstream bug?
17:31:14 <kparal> I could try to find it, I don't have it ready
17:32:11 <mcatanzaro> I'm kinda inclined to say +1 blocker, but maybe not for the right reasons. It's one of those tricky design issues that requires different groups of developers to agree on how a thing should work. Maybe "priority bug"? It's totally fixable after install... just so long as the fix comes before the first kernel update.
17:32:26 <mcatanzaro> (Crazy, not serious: we could say it's a kernel update blocker. ;)
17:32:44 * adamw really on a fence here
17:32:49 <roshi> it's just not an issue in the install media preventing you from installing, which is why I don't think it's a blocker
17:32:54 <adamw> the 'priority bug' thing does seem quite fitting for it
17:32:59 <roshi> yeah
17:33:12 <kparal> I'll mark it as such
17:33:19 <kparal> roshi: blockers are not just about install media
17:33:33 <roshi> right
17:33:54 <roshi> but it's an issue that *may* arise *sometime* in the future if you do steps 1-3
17:34:18 <kparal> yes
17:34:22 <roshi> and presumeably, you'd get the same issue with a FedUp system or any other form of existing install, right?
17:34:49 <roshi> or is it only off of fresh installs?
17:34:50 <kparal> sure, any encrypted fedora system in which you change the default keymap
17:35:19 <kparal> until you update kernel, it will use the old keymap, then it will use the new one
17:35:34 <roshi> +1 priority bug, -1 blocker
17:35:37 <kparal> even if you actually wanted to change just your session keymaps, not system ones
17:35:41 <roshi> is my vote
17:35:43 <roshi> yeah
17:35:52 <mcatanzaro> So I think it's relevant that the fix for this must come *before* any kernel update, and we have no way to stage updates that way.
17:35:59 <roshi> that's true
17:36:14 <mcatanzaro> So it's not really possible to fix correctly post-install.
17:37:09 <mcatanzaro> Also relevant: (a) This is a non-default configuration, most users will pick one layout and stay with it, should affect very few users. (b) It's an awful data loss bug, about as bad as could be imagined.
17:37:14 <mcatanzaro> Those are pointing different ways.
17:37:25 <kparal> if we don't fix it by the release day, we won't likely fix it even soon after that
17:37:53 <roshi> we can't stage the update that way, but it's still possible to fix - since this affects all systems (from our discusion)
17:38:11 <kparal> well, it's quite common in some countries to have multiple layouts
17:38:35 <kparal> because we can't seem to agree to use just ascii in the world :)
17:38:49 <roshi> mcatanzaro: I think it's an annoying data unavailability bug, but it's not loss
17:39:04 <roshi> boot to live, change to right keymap and mount the drive
17:39:12 <kparal> does anybody has a link to the priority bug sop?
17:39:23 <adamw> roshi: you have to actually realize what's happened, though
17:39:25 <adamw> that's the tricky part
17:39:26 <mcatanzaro> roshi: I would say it's unreasonable to expect users to figure that out.
17:39:31 <roshi> that's true
17:39:45 <kparal> if it happened directly after reboot, it would be more obvious
17:39:49 <kparal> this might happen a month later
17:39:50 <mcatanzaro> I'm on the fence too, but leaning blocker. My $0.02.
17:39:52 <adamw> if you know what's happened, working around it shouldn't be too hard, but if you don't actually know what's happened, you're basically stuck
17:40:04 <roshi> if they're using LUKS, my assumption would be they have some knowhow behind it
17:40:10 <adamw> kparal: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process?rd=Fedora_Program_Management/Important_bugs_and_issues_process
17:40:20 <adamw> roshi: that's an invalid assumption
17:40:20 <roshi> yeah, that's true, it doesn't give any real indication
17:40:27 <adamw> roshi: since you can set it up during install with a nice graphical checkbox
17:40:39 <mcatanzaro> Other non-blocker indicators: LUKs is still non-default, it's probably been broken for ages and not a new bug
17:40:43 <kparal> adamw: thanks, bookmarking now
17:41:02 <roshi> my assumption was using all GUI stuff, not fancy CLI - boot live, open Disks, click boxes
17:41:06 <adamw> all it says is 'encrypt my data', no knowledge of the encryption mechanism (or Linux's messy input configuration state) is needed
17:41:10 <roshi> but I digress
17:41:28 <adamw> you *have* to go through INSTALLATION DESTINATION when installing
17:41:34 <adamw> and the 'encrypt my data' checkbox is right there
17:41:35 <kparal> mcatanzaro: yes, but some gnome versions back you only changed sessions keymaps by default even on single-user systems
17:41:40 <adamw> it's very much intended to be prominent and 'easy'
17:42:20 <adamw> so, do we want to vote on this today? we can punt, but i'm not sure what we'd be punting for exactly
17:42:47 <roshi> I'm still -1 blocker since this isn't F26 related, exactly
17:42:58 <roshi> but priority bug status for sure
17:43:13 <roshi> since this can hit anyone who changes keymaps
17:44:11 <mcatanzaro> If I can deliberately dilute my vote to indicate indecisiveness, I'm +0.5 blocker. :P
17:44:55 <roshi> haha
17:44:59 <kparal> I'm more towards a blocker
17:44:59 <roshi> happens all the time
17:45:01 <adamw> well, if we were voting on a KDE blocker, you could vote +1, -1, 0, +0.5, +pi, or ~lightblue
17:45:28 <adamw> but since this is a GNOME blocker, you don't actually get to vote at all, we've already decided for you
17:45:36 <adamw> ;)
17:45:53 <adamw> thanks, folks, I'll be here all week. also, what's the deal with text editors?
17:46:56 <adamw> so so far we have a total vote of -0.5
17:47:07 <kparal> do we have anyone else's opinion?
17:47:08 <adamw> oh wait, let's say +0.3
17:47:16 <adamw> (counting kparal as about a +0.8 :>)
17:47:21 <kparal> :D
17:47:25 <adamw> i guess i'm about a -0.2
17:47:25 <roshi> lol
17:47:29 <adamw> since we're going all decimal
17:47:57 <Southern_Gentlem> +1
17:48:06 <adamw> what is this whole-number craziness
17:48:12 <roshi> the toothpaste is out of the tube already, so I can't see a reason to block on it
17:48:31 <adamw> so we're really kinda split on this one, hrm
17:48:33 <roshi> since it's *any* installed system
17:48:45 <adamw> maybe we need more votes
17:48:58 * roshi summons a tflink
17:49:11 <Southern_Gentlem> roshi,  because we are doing a new release, if it is happening in the past even more reason to get it fixed
17:49:12 <kparal> my reasoning is that since we can't do all simple and working, because technical issues (keymaps!), we should at least inform the user properly. that much I believe we can do. and gnome designers should understand that sometimes there's no better way and simplified gui at the expense of bad user experience is not a good idea
17:49:28 <roshi> Southern_Gentlem: right, get it fixed - but not block release
17:49:49 <Southern_Gentlem> roshi,  to me this is a blocker for release
17:49:50 <roshi> kparal: I concur
17:49:58 <roshi> under which criterion?
17:50:16 <Southern_Gentlem> crap should work
17:50:19 <adamw> right, the 'this isn't anything new' argument is a big one for me; we don't make anything better by delaying f26's release for this really
17:50:20 <roshi> lol
17:50:22 <roshi> I concur
17:50:29 <adamw> anyone who's "saved" from this by f26 not being released will just install f25 instead and...have the same bug.
17:50:43 <roshi> to both Southern_Gentlem's "crap should work" and adamw
17:50:52 <adamw> new criterion: ALL CRAP MUST WORK
17:51:12 <kparal> people will not be saved by f26 not being released, but by f26 being released with a fix
17:51:16 <kparal> hopefully
17:51:21 <roshi> but then what's the definition of crap and where the brightline denoting the limits of crap?
17:51:27 <roshi> </snark> :p
17:51:28 <adamw> footnote!
17:51:36 <roshi> lol
17:52:02 <kparal> roshi: I proposed a criterion in comment 1. I agree it's not clear-cut
17:52:14 <kparal> gnome-control-center affects a huge portion of the system
17:52:23 <roshi> I'm in complete agreement that we should fix this before release, but I don't see the benefit of blocking for it
17:53:11 <Southern_Gentlem> ok punt for now
17:53:22 <kparal> you could use the same argument for any bug that is already present in f25, regardless of its gravity
17:53:27 <adamw> welp, we've been on this for about half an hour and a clear decision doesn't seem to be in sight
17:53:43 <adamw> kparal: we usually do count it as at least a factor in any blocker where it's pointed out
17:54:08 <roshi> there's just three conditionals you have to trigger to hit this
17:54:09 <adamw> so i'm gonna propose we punt this just on practical grounds; give people a week to think it through and maybe we'll have different people next time
17:54:26 <roshi> it's severe, but not directly related to F26, so why block on it?
17:54:32 <kparal> you didn't say different opinions, you said different people
17:54:40 <roshi> I'd like to see a fix for everything still supported, not just F26
17:54:44 <adamw> proposed #agreed 1405539 - punt (delay decision) - we could not come to a clear consensus on this bug this week, and there's plenty of time before final, so we are punting for more consideration and hopefully more input from other voters
17:54:48 <kparal> I'm not paranoid, but is someone going to strangle me this week?
17:54:59 <kparal> just want to know
17:55:09 <roshi> won't be me
17:55:12 <adamw> kparal: not at all, don't worry, and certainly don't turn around and check behind you
17:55:14 <roshi> I've missed you kparal :)
17:55:18 <adamw> NOW GARRET GARRET DO IT NOW
17:55:34 <kparal> you would miss "the pita guy"
17:55:47 <kparal> ack
17:55:54 <Southern_Gentlem> ack
17:55:59 <pwhalen> ack
17:56:16 <coremodule> ack
17:56:18 <adamw> #agreed 1405539 - punt (delay decision) - we could not come to a clear consensus on this bug this week, and there's plenty of time before final, so we are punting for more consideration and hopefully more input from other voters
17:56:26 <adamw> yay, we have a consensus on not having a consensus!
17:56:26 <roshi> lol
17:56:30 <adamw> i feel a warm sense of achievement
17:56:35 <adamw> or at least a warm sense of *something*
17:56:35 <Southern_Gentlem> kparal, we pick on you, butyou find bugs thats others do not find and that is fantastic
17:56:40 <roshi> haha
17:57:02 <roshi> I was trying to have a moment right then and you all ruined it :p
17:57:17 <adamw> happy to oblige
17:57:27 <adamw> OK, that's all the proposed blockers; don't think we really need to do accepted at this early point
17:57:38 <adamw> all in favour of knocking it on the head and going for a fivebeer?
17:57:44 <roshi> wfm
17:57:47 <kparal> ack
17:57:50 <roshi> ack
17:57:55 <adamw> #topic Open floor
17:57:59 <adamw> any other blocker/f26-y business?
17:58:21 <Southern_Gentlem> ack
17:58:24 <pwhalen> adamw et al, I wasnt able to reproduce 1376638 on aarch64, worked 3/3 times
17:58:32 <adamw> interesting
17:58:36 <roshi> I have nothing at this point
17:58:40 <adamw> i'll have to try it locally too
17:58:55 <coremodule> Nothing here.
17:59:13 <adamw> alrighty, thanks for coming everyone!
17:59:26 <coremodule> Except that I'm going to head for lunch now, so bear with me for a few hours for the results to appear on the Blocker page.
17:59:33 <adamw> see you again, same bat-time, same bat-channel
17:59:35 <adamw> roger
17:59:58 <adamw> #endmeeting