16:01:12 #startmeeting F23-blocker-review 16:01:12 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:13 #meetingname F23-blocker-review 16:01:13 The meeting name has been set to 'f23-blocker-review' 16:01:13 #topic Roll Call 16:01:23 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 #chair kparal satellit jkurik pschindl adamw 16:03:22 Current chairs: adamw jkurik kparal pschindl roshi satellit 16:03:33 #topic Introduction 16:03:34 Why are we here? 16:03:34 #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 #info We'll be following the process outlined at: 16:03:40 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:03:42 #info The bugs up for review today are available at: 16:03:45 #link http://qa.fedoraproject.org/blockerbugs/current 16:03:47 #info The criteria for release blocking bugs can be found at: 16:03:48 * adamw here 16:03:50 #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria 16:03:53 #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria 16:03:56 #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria 16:04:11 we've got 1/3 beta/final proposals - so should be able to sail through pretty quick 16:04:14 o/ adamw 16:04:35 * roshi moves onto the beta proposal 16:04:35 #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 #link https://bugzilla.redhat.com/show_bug.cgi?id=1256712 16:04:41 #info Proposed Blocker, xorg-x11-drv-intel, NEW 16:04:45 haha 16:04:50 nope, just 4 total 16:04:51 I already started sweating 16:05:51 I'm experiencing this bug personally on the 4.2.x series. 16:06:04 do we officially support docks? or is that a best effort kinda thing 16:06:07 ? 16:06:10 That said, I'm not (yet) certain I'd call it a blocker. It only happens on multi-monitor cases. 16:06:16 roshi: In my case, the dock is irrelevant. 16:06:19 which are frequent enough 16:06:31 With or without the dock, I get this error with external monitors 16:06:46 there's a certain company where most employees run Fedora with a docking station 16:07:12 And where this happens to have been the official model issued to employees at a certain time, yes 16:07:21 kparal: true - I just don't recall seeing it explicitly mentioned in the criteria 16:07:25 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 but I think you're using DVI, right? 16:07:48 sgallagh: what about you, which cable? 16:07:51 kparal: I hit issues on 4.2.x with either DisplayPort or HDMI 16:07:51 I use vga connected directly to laptop. And it works 16:08:03 I don't use DVI because it doesn't support this monitor's resolution, so I didn't test that 16:08:03 pschindl: I mean between the dock and the monitor 16:08:08 I haven't tried displayport 16:08:34 kparal: I've tried vga and dvi. Nothing works 16:08:44 ah, now I get it 16:08:47 directly into the laptop? 16:08:54 this would basically be a conditional violation of one of the 'desktop should work' criteria 16:08:56 roshi: I've tried both ways. 16:09:00 he means nothing works with dock 16:09:05 the condition being you're running on the brand of laptop affected with an external display attached. 16:09:12 and as always the question would be is that common enough to block on. 16:09:15 Sorry for confusion. It doesn't work only when I connect monitor to docking 16:09:23 adamw: Exactly right. 16:09:42 it seems to affect fairly recent and spread out intel chipsets 16:09:46 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 *widespread 16:09:57 if it's widespread, sure 16:10:21 Lenovo T540p 16:10:23 Which certainly has the added advantage of readily-available hardware for testing 16:10:28 let me google the intel chipset 16:10:31 I think it's haswell 16:11:22 from these reports it seems to be really common 16:11:39 +1 16:11:49 seems to be haswell. not sure if there are additional gpu families in that cpu series 16:12:08 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 16:12:23 I guess I'd also say +1 now, unless it's shows up to affect just a very limited audience 16:12:49 I'm totally +1. I want my second monitor back :) 16:12:52 sgallagh: you need to use -nn to see the pciid if you want to google up anything about it 16:12:53 it doesn't seem to be one port on one model docking station 16:13:07 k 16:13:44 sgallagh: but yours is also haswell 16:13:49 4th gen 16:13:57 More like hasillness amirite? 16:14:40 I can try tomorrow with Broadwell gpu 16:14:43 5th gen 16:14:44 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 jkurik: that's great, please test and report into the bug :) 16:16:24 kparal: I might try it tomorrow 16:16:33 I'm fine with +1 16:16:46 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 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 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 ack 16:17:31 ack 16:17:36 ack 16:17:39 ack 16:17:46 #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 ok, onto the final proposals 16:18:12 who wants to secretarialize? 16:18:20 ah, this was Beta? 16:18:25 yes 16:18:32 I'd be willing to let this slip to Final, but both works 16:18:37 said it right there in teh proposed 16:19:02 * kparal is looking into the floor 16:19:22 #topic (1255066) inst.sshd option doesn't work i. e. sshd fails to start during installation 16:19:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=1255066 16:19:27 lol 16:19:30 #info Proposed Blocker, anaconda, POST 16:19:42 fine, /me will secretarialize 16:20:36 * kparal completely overlooked the call 16:21:06 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 so, the s390x argument probably won't hold 16:21:42 and I'm not aware of any other criterion that would match this problem 16:22:56 it's fine, i got it. 16:23:27 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 +1 FE, sure, it already is for Beta anyway 16:24:57 yeah 16:25:07 it's already an FE 16:25:17 -1 blocker 16:25:19 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 *and->are 16:25:30 I would be -1 for blocker; I have not find anything in Release Criteria what is violated 16:26:07 -1, secondary arch stuff should not block. 16:26:13 but I guess anaconda devs are free to pull in fixes for secondary archs even after primary arch release 16:26:18 (those were two slightly separate notes, btw) 16:26:20 so it's not such a big deal 16:27:10 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 ack 16:28:05 the second part of the sentence sounds a bit weird, but ack :) 16:28:31 ack 16:28:34 sure, ack 16:28:37 #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 #topic (1257637) Empty f23-branch in Zanata 16:28:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1257637 16:28:49 #info Proposed Blocker, anaconda, NEW 16:29:55 +1 16:29:56 what is zanata? 16:30:03 translation software 16:30:10 +1 16:30:22 aiui, it stores strings to be translated and tracks when they are 16:30:25 +1 16:30:26 have we moved from transifex? 16:30:44 though, if those aren't there... it could be argued they're not provided :p 16:31:27 +1 16:31:46 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 ack 16:33:20 ack 16:33:44 ack 16:34:20 #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 last one... 16:34:32 #topic (1255175) useradd -R reads /etc/login.defs from outside of the chroot 16:34:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1255175 16:34:38 #info Proposed Blocker, shadow-utils, MODIFIED 16:35:27 -1, same as before 16:35:35 and looks like there's a patch already 16:35:59 the subject implies useradd escapes chroot. fortunately it's just a broken cmdline option :) 16:36:28 roshi: what 'before'? 16:36:47 -1 ; I do not see any criterion violated 16:36:59 this is just the underlying cause of the sshd bug, right? 16:37:00 so -1 16:37:11 kparal: bug 1255066 16:37:26 ah, the secondary arch 16:37:41 I thought this affects primary arches as well 16:37:49 ok, in that case -1 16:37:54 the other s390x bug 16:37:57 +1 FE for Beta 16:39:16 adamw: yeah, it is 16:39:25 -1 16:40:01 proposed #agreed - 1255175 - RejectedBlocker Final - This bug does not violate any criteria and is not considered a blocker. 16:40:18 ack 16:41:15 ack 16:41:50 ack 16:42:25 #agreed - 1255175 - RejectedBlocker Final - This bug does not violate any criteria and is not considered a blocker. 16:42:31 #topic Open Floor 16:43:02 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 it's a bit of a long messy one 16:45:48 to summarize: it's the bug about having a non-ASCII encryption passphrase 16:46:15 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 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 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 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 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 X and console keyboard engines implement this fundamentally differently, such that you can't sensibly translate one into the other 16:50:36 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 or am I misunderstanding stuff? 16:50:48 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 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 kk 16:53:04 I only grokked some of those words 16:53:09 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 nd of thing 16:53:24 I guess I'm +1 to pulling blocker status and push for the warning to become an error 16:53:31 get the string exception put in 16:53:56 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 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 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 votes for demoting and pushing for the existing warning to become an error? 16:56:04 +1 16:56:11 +1 16:56:20 +1 16:57:41 +1 even I am a bit lost here 16:58:04 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 ack 16:58:28 * kparal goes for a dinner 16:58:28 * roshi thinks he summed it up there 16:58:36 have a good night kparal 16:59:20 thanks, see you 16:59:27 ack 17:00:25 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 thanks 17:00:34 no, work fine foe me 17:00:36 for me. 17:00:39 #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 anyone have anything else? 17:01:57 * roshi sets the fuse... 17:01:59 3... 17:02:23 we could do FEs, but freeze isn't till after next monday, so probably fine./ 17:02:41 yeah, I figured we could wait on those 17:02:48 let people get back to $STUFF 17:02:52 2... 17:03:26 1... 17:03:31 thanks for coming folks! 17:03:39 roshi: thanks for running the meeting 17:03:45 np 17:03:58 the real thanks goes to adamw for the secretarializing :) 17:04:08 #endmeeting