16:01:12 <roshi> #startmeeting F23-blocker-review
16:01:12 <zodbot> Meeting started Mon Aug 31 16:01:12 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:13 <roshi> #meetingname F23-blocker-review
16:01:13 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:01:13 <roshi> #topic Roll Call
16:01:23 <roshi> who's around for some blocker review fun times!?
16:01:31 * kparal is here
16:01:43 * satellit_e listening
16:02:39 * jkurik is here
16:02:51 * pschindl is here
16:03:22 <roshi> #chair kparal satellit jkurik pschindl adamw
16:03:22 <zodbot> Current chairs: adamw jkurik kparal pschindl roshi satellit
16:03:33 <roshi> #topic Introduction
16:03:34 <roshi> Why are we here?
16:03:34 <roshi> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:03:37 <roshi> #info We'll be following the process outlined at:
16:03:40 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:42 <roshi> #info The bugs up for review today are available at:
16:03:45 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:47 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:48 * adamw here
16:03:50 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:03:53 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:03:56 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:04:11 <roshi> we've got 1/3 beta/final proposals - so should be able to sail through pretty quick
16:04:14 <roshi> o/ adamw
16:04:35 * roshi moves onto the beta proposal
16:04:35 <roshi> #topic (1256712) System freezes after login when monitor is connected to docking station of laptop
16:04:37 * kparal read 13 proposals
16:04:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1256712
16:04:41 <roshi> #info Proposed Blocker, xorg-x11-drv-intel, NEW
16:04:45 <roshi> haha
16:04:50 <roshi> nope, just 4 total
16:04:51 <kparal> I already started sweating
16:05:51 <sgallagh> I'm experiencing this bug personally on the 4.2.x series.
16:06:04 <roshi> do we officially support docks? or is that a best effort kinda thing
16:06:07 <roshi> ?
16:06:10 <sgallagh> That said, I'm not (yet) certain I'd call it a blocker. It only happens on multi-monitor cases.
16:06:16 <sgallagh> roshi: In my case, the dock is irrelevant.
16:06:19 <kparal> which are frequent enough
16:06:31 <sgallagh> With or without the dock, I get this error with external monitors
16:06:46 <kparal> there's a certain company where most employees run Fedora with a docking station
16:07:12 <sgallagh> And where this happens to have been the official model issued to employees at a certain time, yes
16:07:21 <roshi> kparal: true - I just don't recall seeing it explicitly mentioned in the criteria
16:07:25 <kparal> pschindl: do you know which cable to use to connect the dock with the monitor? the issue seems to be related to displayport
16:07:32 <kparal> but I think you're using DVI, right?
16:07:48 <kparal> sgallagh: what about you, which cable?
16:07:51 <sgallagh> kparal: I hit issues on 4.2.x with either DisplayPort or HDMI
16:07:51 <pschindl> I use vga connected directly to laptop. And it works
16:08:03 <sgallagh> I don't use DVI because it doesn't support this monitor's resolution, so I didn't test that
16:08:03 <kparal> pschindl: I mean between the dock and the monitor
16:08:08 <pschindl> I haven't tried displayport
16:08:34 <pschindl> kparal: I've tried vga and dvi. Nothing works
16:08:44 <kparal> ah, now I get it
16:08:47 <roshi> directly into the laptop?
16:08:54 <adamw> this would basically be a conditional violation of one of the 'desktop should work' criteria
16:08:56 <sgallagh> roshi: I've tried both ways.
16:09:00 <kparal> he means nothing works with dock
16:09:05 <adamw> the condition being you're running on the brand of laptop affected with an external display attached.
16:09:12 <adamw> and as always the question would be is that common enough to block on.
16:09:15 <pschindl> Sorry for confusion. It doesn't work only when I connect monitor to docking
16:09:23 <sgallagh> adamw: Exactly right.
16:09:42 <kparal> it seems to affect fairly recent and spread out intel chipsets
16:09:46 <sgallagh> As noted above, this *does* happen to be a model that introduces a lot of risk, due to it having been a bulk purchase by our benevolent overlords.
16:09:49 <kparal> *widespread
16:09:57 <roshi> if it's widespread, sure
16:10:21 <kparal> Lenovo T540p
16:10:23 <sgallagh> Which certainly has the added advantage of readily-available hardware for testing
16:10:28 <kparal> let me google the intel chipset
16:10:31 <kparal> I think it's haswell
16:11:22 <roshi> from these reports it seems to be really common
16:11:39 <roshi> +1
16:11:49 <kparal> seems to be haswell. not sure if there are additional gpu families in that cpu series
16:12:08 <sgallagh> 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
16:12:23 <kparal> I guess I'd also say +1 now, unless it's shows up to affect just a very limited audience
16:12:49 <pschindl> I'm totally +1. I want my second monitor back :)
16:12:52 <kparal> sgallagh: you need to use -nn to see the pciid if you want to google up anything about it
16:12:53 <roshi> it doesn't seem to be one port on one model docking station
16:13:07 <sgallagh> k
16:13:44 <kparal> sgallagh: but yours is also haswell
16:13:49 <kparal> 4th gen
16:13:57 <sgallagh> More like hasillness amirite?
16:14:40 <kparal> I can try tomorrow with Broadwell gpu
16:14:43 <kparal> 5th gen
16:14:44 <sgallagh> OK, on that bad pun, I need to vanish for a bit. Put me down as 0. I'm a biased participant :)
16:15:32 * linux-modder late
16:15:40 * jkurik has just 3rd Gen :(
16:16:01 <kparal> jkurik: that's great, please test and report into the bug :)
16:16:24 <jkurik> kparal: I might try it tomorrow
16:16:33 <adamw> I'm fine with +1
16:16:46 <adamw> i don't think there's anything weird about '+1 because red hat has a ton of them', i mean, red hat people are part of our userbase.
16:16:59 <roshi> proposed #agreed - 1256712 - AcceptedBlocker Beta - This bug is a conditional violation of the following Beta 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."
16:17:00 <jkurik> I am +1 for now
16:17:06 * linux-modder has c2d intel on  4.2.x  and same  apparent  lag  not  a lock up tho
16:17:25 <adamw> ack
16:17:31 <linux-modder> ack
16:17:36 <kparal> ack
16:17:39 <jkurik> ack
16:17:46 <roshi> #agreed - 1256712 - AcceptedBlocker Beta - This bug is a conditional violation of the following Beta 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."
16:17:53 <roshi> ok, onto the final proposals
16:18:12 <roshi> who wants to secretarialize?
16:18:20 <kparal> ah, this was Beta?
16:18:25 <roshi> yes
16:18:32 <kparal> I'd be willing to let this slip to Final, but both works
16:18:37 <roshi> said it right there in teh proposed
16:19:02 * kparal is looking into the floor
16:19:22 <roshi> #topic (1255066) inst.sshd option doesn't work i. e. sshd fails to start during installation
16:19:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1255066
16:19:27 <roshi> lol
16:19:30 <roshi> #info Proposed Blocker, anaconda, POST
16:19:42 <adamw> fine, /me will secretarialize
16:20:36 * kparal completely overlooked the call
16:21:06 <roshi> I can do it after the meeting too, if no one wants to do it
16:21:12 * roshi doesn't mind
16:21:18 <kparal> so, the s390x argument probably won't hold
16:21:42 <kparal> and I'm not aware of any other criterion that would match this problem
16:22:56 <adamw> it's fine, i got it.
16:23:27 <kparal> I'd like to see this fixed, but at this point I guess I'd be -1 blocker, unless anaconda wants to commit to supporting this every release and help us draft a release criterion for it
16:24:07 <kparal> +1 FE, sure, it already is for Beta anyway
16:24:57 <roshi> yeah
16:25:07 <roshi> it's already an FE
16:25:17 <roshi> -1 blocker
16:25:19 <kparal> maybe we could have a criterion that says that features essential for secondary arches to install and release blockers. but it somewhat undermines the purpose of "secondary" archs
16:25:28 <kparal> *and->are
16:25:30 <jkurik> I would be -1 for blocker; I have not find anything in Release Criteria what is violated
16:26:07 <adamw> -1, secondary arch stuff should not block.
16:26:13 <kparal> but I guess anaconda devs are free to pull in fixes for secondary archs even after primary arch release
16:26:18 <adamw> (those were two slightly separate notes, btw)
16:26:20 <kparal> so it's not such a big deal
16:27:10 <roshi> proposed #agreed - 1255066 - RejectedBlocker Final - This bug doesn't violate any criterion and is already accepted as an FE for Beta so is not a blocker for Final.
16:27:44 <pschindl> ack
16:28:05 <kparal> the second part of the sentence sounds a bit weird, but ack :)
16:28:31 <jkurik> ack
16:28:34 <adamw> sure, ack
16:28:37 <roshi> #agreed - 1255066 - RejectedBlocker Final - This bug doesn't violate any criterion and is already accepted as an FE for Beta so is not a blocker for Final.
16:28:49 <roshi> #topic (1257637) Empty f23-branch in Zanata
16:28:49 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1257637
16:28:49 <roshi> #info Proposed Blocker, anaconda, NEW
16:29:55 <roshi> +1
16:29:56 <kparal> what is zanata?
16:30:03 <roshi> translation software
16:30:10 <pschindl> +1
16:30:22 <roshi> aiui, it stores strings to be translated and tracks when they are
16:30:25 <jkurik> +1
16:30:26 <kparal> have we moved from transifex?
16:30:44 <roshi> though, if those aren't there... it could be argued they're not provided :p </snark>
16:31:27 <kparal> +1
16:31:46 <roshi> proposed #agreed - 1257637 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "The installer must correctly display all sufficiently complete translations available for use."
16:31:58 <jkurik> ack
16:33:20 <kparal> ack
16:33:44 <pschindl> ack
16:34:20 <roshi> #agreed - 1257637 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "The installer must correctly display all sufficiently complete translations available for use."
16:34:32 <roshi> last one...
16:34:32 <roshi> #topic (1255175) useradd -R reads /etc/login.defs from outside of the chroot
16:34:36 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1255175
16:34:38 <roshi> #info Proposed Blocker, shadow-utils, MODIFIED
16:35:27 <roshi> -1, same as before
16:35:35 <roshi> and looks like there's a patch already
16:35:59 <kparal> the subject implies useradd escapes chroot. fortunately it's just a broken cmdline option :)
16:36:28 <kparal> roshi: what 'before'?
16:36:47 <jkurik> -1 ; I do not see any criterion violated
16:36:59 <adamw> this is just the underlying cause of the sshd bug, right?
16:37:00 <adamw> so -1
16:37:11 <jkurik> kparal: bug 1255066
16:37:26 <kparal> ah, the secondary arch
16:37:41 <kparal> I thought this affects primary arches as well
16:37:49 <kparal> ok, in that case -1
16:37:54 <roshi> the other s390x bug
16:37:57 <kparal> +1 FE for Beta
16:39:16 <roshi> adamw: yeah, it is
16:39:25 <pschindl> -1
16:40:01 <roshi> proposed #agreed - 1255175 - RejectedBlocker Final - This bug does not violate any criteria and is not considered a blocker.
16:40:18 <jkurik> ack
16:41:15 <adamw> ack
16:41:50 <pschindl> ack
16:42:25 <roshi> #agreed - 1255175 - RejectedBlocker Final - This bug does not violate any criteria and is not considered a blocker.
16:42:31 <roshi> #topic Open Floor
16:43:02 <roshi> we've been asked by the anaconda folks to reconsider the following: https://bugzilla.redhat.com/show_bug.cgi?id=681250
16:45:00 * roshi reads
16:45:26 <adamw> it's a bit of a long messy one
16:45:48 <adamw> to summarize: it's the bug about having a non-ASCII encryption passphrase
16:46:15 <adamw> sometimes when you do that, in various icky circumstances, you might have a keyboard layout when entering the passphrase on boot that cannot enter the passphrase, or that can do it but not in a way the user knows about
16:47:25 <adamw> the argument against it being a blocker, in a nutshell, is that this is a very complex area of behaviour and there is no 'simple fix' for it. to a certain extent we have to rely on user knowledge of how keyboard layouts work, given the current state of the underlying technology.
16:47:41 <adamw> i'd be in favour of anaconda just disallowing non-ASCII passphrases, but i'm not sure it should count as a blocker.
16:48:50 <adamw> to give a bit more detail: console and X keyboard code is actually entirely different and they use different layout files. We have a trick in place which tries to keep them as consistent as possible by dynamically generating console layouts from X11 layouts, but there's a big exception to that
16:49:29 <adamw> the exception is switched layouts - layouts for languages where the native alphabet is sufficiently different from the Latin alphabet that you can't fit both on one set of keys, instead you have two 'modes', one for inputting native characters, one for inputting Latin ones. Russian is the common example
16:49:50 <adamw> X and console keyboard engines implement this fundamentally differently, such that you can't sensibly translate one into the other
16:50:36 <roshi> thinking out loud here: does that mean this might be easier to fix when we've moved off X and into wayland?
16:50:45 <roshi> or am I misunderstanding stuff?
16:50:48 <adamw> so for those cases, we have to rely on the old 'legacy' console layouts: what we do is drop any X11-converted console layouts that can't input Latin characters, so for anyone who picks such an X11 layout, we can't actually know with any certainty what console layout they'll get, and whether it'll be capable of inputting the same characters at all.
16:50:56 * roshi is unfamiliar with that whole stack
16:51:40 * kparal was off for a while, sorry, reading backlog
16:51:45 <adamw> roshi: AIUI, for this case the Glorious Future is more about chaning the console side of things than the graphical side - I think Wayland basically uses xkb. the Glorious Future would be to have console input act like xkb, which is something that 'kmscon' was supposed to do, and i thought we were supposed to have that by now, but we don't. anyway, that's kinda offtopic for now
16:52:55 <roshi> kk
16:53:04 <roshi> I only grokked some of those words
16:53:09 <adamw> the only way for anaconda to do this 'properly' would be for it to be able to figure out, for any given xkb layout, what kbd layout would ultimately be used and what characters it could input, and only allow those characters in the encryption passphrase. but that would be a fairly crazy thing for anaconda to do - especially because, as it happens, the details of how all this stuff gets implemented aren't particularly well suited to doing that ki
16:53:09 <adamw> nd of thing
16:53:24 <roshi> I guess I'm +1 to pulling blocker status and push for the warning to become an error
16:53:31 <roshi> get the string exception put in
16:53:56 <adamw> roshi: xkb is the engine X uses for doing keyboard layout stuff. kmscon is a whole thing about doing consoles in userspace not the kernel, but it also happened to include making consoles basically use xkb for keyboard stuff instead of kbd (the kernel driver they currently use).
16:54:19 <adamw> which would make a lot of these kinds of problem go away because we'd be confident input would work the same in both places.
16:55:34 <kparal> ah, the warning is there, what the hell, let's demote it. but I'd be really glad if they simply forbidden non-ascii chars. string freeze exception is the smallest concern here
16:56:01 <roshi> votes for demoting and pushing for the existing warning to become an error?
16:56:04 <roshi> +1
16:56:11 <adamw> +1
16:56:20 <kparal> +1
16:57:41 <jkurik> +1 even I am a bit lost here
16:58:04 <roshi> proposed #agreed - 681250 - RejectedBlocker Final - This bug has a long and sordid history. Relying on past decisions and the arguments from #Comment 32, we're rejected this bugs status as a blocker. Please promote the existing anaconda warning to an Error and submit for a string freeze exception.
16:58:26 <kparal> ack
16:58:28 * kparal goes for a dinner
16:58:28 * roshi thinks he summed it up there
16:58:36 <roshi> have a good night kparal
16:59:20 <kparal> thanks, see you
16:59:27 <jkurik> ack
17:00:25 <roshi> adamw: you got a patch for that?
17:00:26 * adamw will try to put a vaguely-understandable summary in the comment
17:00:31 <roshi> thanks
17:00:34 <adamw> no, work fine foe me
17:00:36 <adamw> for me.
17:00:39 <roshi> #agreed - 681250 - RejectedBlocker Final - This bug has a long and sordid history. Relying on past decisions and the arguments from #Comment 32, we're rejected this bugs status as a blocker. Please promote the existing anaconda warning to an Error and submit for a string freeze exception.
17:01:52 <roshi> anyone have anything else?
17:01:57 * roshi sets the fuse...
17:01:59 <roshi> 3...
17:02:23 <adamw> we could do FEs, but freeze isn't till after next monday, so probably fine./
17:02:41 <roshi> yeah, I figured we could wait on those
17:02:48 <roshi> let people get back to $STUFF
17:02:52 <roshi> 2...
17:03:26 <roshi> 1...
17:03:31 <roshi> thanks for coming folks!
17:03:39 <jkurik> roshi: thanks for running the meeting
17:03:45 <roshi> np
17:03:58 <roshi> the real thanks goes to adamw for the secretarializing :)
17:04:08 <roshi> #endmeeting