16:00:10 #startmeeting F24-blocker-review 16:00:10 Meeting started Tue Mar 29 16:00:10 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:10 The meeting name has been set to 'f24-blocker-review' 16:00:10 #meetingname F24-blocker-review 16:00:10 The meeting name has been set to 'f24-blocker-review' 16:00:10 #topic Roll Call 16:00:18 ahoyhoy folks, who's around for some fun blocker review 16:00:25 * garretraziel is here 16:00:27 * satellit_e listening 16:00:38 .hello lupinix 16:00:41 lupinix: lupinix 'Christian Dersch' 16:00:53 .hello dmossor 16:00:54 danofsatx: dmossor 'Dan Mossor' 16:00:57 #chair garretraziel danofsatx 16:00:57 Current chairs: adamw danofsatx garretraziel 16:01:04 * lbrabec is lurking 16:02:22 * kparal is here 16:03:09 thanks for showing up, folks 16:03:10 #topic Introduction 16:03:10 Why are we here? 16:03:10 #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:11 #info We'll be following the process outlined at: 16:03:11 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:03:13 #info The bugs up for review today are available at: 16:03:15 #link http://qa.fedoraproject.org/blockerbugs/current 16:03:17 #info The criteria for release blocking bugs can be found at: 16:03:21 #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria 16:03:23 #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria 16:03:25 #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria 16:03:27 who wants to be the secretary? 16:03:41 this is like "who wants to be a millionaire" only there are no questions and no prize money 16:04:09 * danofsatx can't, leaving for school in 1 hour 16:04:30 garretraziel: lbrabec: wanna try? 16:04:40 don't be shy! 16:04:52 it's so much fun! 16:04:54 wait...no it isn't. 16:05:09 I've never done it, I'm not sure what should I do as a secretary 16:05:21 and now it definitely isn't the time to learn it :-) 16:05:33 you would think 16:05:33 i'll probably leave earlier... so nah, but thanks 16:05:57 * kparal will do it 16:06:23 garretraziel: lbrabec: I'll give you a crash course next time before the meeting, "just in case" :) 16:06:39 #info kparal to secretarialize, thanks kparal 16:06:48 sound like fun 16:06:50 * pwhalen is here 16:06:55 wait, no it doesn't 16:06:56 so, starting with beta proposed blockers 16:06:58 =) 16:07:07 #topic (1315494) C.UTF-8 doesn't actually work as a default locale 16:07:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1315494 16:07:07 #info Proposed Blocker, anaconda, MODIFIED 16:07:11 this old friend's back! 16:07:33 i think it's reasonable to accept it as a beta blocker on the basis we're unlikely to make it to beta without another anaconda build. rawhide testing indicates the fix is working. 16:07:38 +1 16:08:44 +1 16:09:00 +1 16:09:13 +1 16:09:20 .hello raphgro 16:09:24 RaphGro: raphgro 'Raphael Groner' 16:09:39 +1 16:10:05 +1 16:10:10 proposed #agreed 1315494 - AcceptedBlocker (Beta) - this clearly violates the criteria (installer fails to run at all) and it's unlikely we can make the Beta release with the same anaconda build we used for Alpha (which did not suffer from the bug) 16:10:41 ack 16:10:47 ack 16:10:49 ack 16:10:49 ack 16:10:50 ack 16:10:57 ack 16:11:54 #agreed 1315494 - AcceptedBlocker (Beta) - this clearly violates the criteria (installer fails to run at all) and it's unlikely we can make the Beta release with the same anaconda build we used for Alpha (which did not suffer from the bug) 16:12:01 #topic (1318067) [anaconda] non-bootable system after fresh install of current F24 on bare metal 16:12:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=1318067 16:12:01 #info Proposed Blocker, grub2, NEW 16:12:11 basically it seems like recent grub2 builds don't work on some systems 16:12:23 we could probably do with some more info here but it certainly looks worrying, it's an obvious conditional blocker case 16:12:33 i pinged pjones about it this morning but no reply yet 16:12:42 what about the downgrade workaround? 16:13:38 well, i mean, yeah, you can do that. 16:13:50 +1 blocker 16:13:56 it involves finding an f23 rescue image, booting that, and knowing how to do a grub2-install without nuking your hard disk. or some other hard disk. 16:14:18 or knowing to switch to a console after install has completed and having some old grub2 bits handy on a USB stick or something and, again, knowing how to use them without blowing anything up. 16:14:20 it's not a great workaround. 16:14:47 i'd probably like to take a week to see if we can nail down any more details on this one, personally 16:14:47 as long as the hardware affected is reasonably limited, I think Final blocker would be more appropriate 16:14:50 with good documentation maybe 16:14:59 hard to say 16:15:12 +1 final 16:16:34 it's +1 final for me - it looks like only limited set of HW is affected 16:16:48 yep, +1 final 16:16:54 well, we have two thinkpads already, thinkpads being affected is usually bad news' 16:17:19 we can accept for blocker and punt for beta, i guess... 16:17:34 +1 blocker for beta 16:17:42 just punt would be ok now 16:17:58 let's wait until pjones can look at it or we gather more feedback from users 16:18:45 I'll get a thinkpad soonish, so I could test also on bare metal. 16:19:23 proposed #agreed 1318067 - punt (delay decision) - we're generally inclined to take this as a Beta or Final blocker, but we'd like to try and gather some more precise data to be sure how wide the impact is first 16:19:36 ack 16:19:38 ack 16:19:41 ack 16:19:42 ack 16:19:42 ack 16:20:10 #agreed 1318067 - punt (delay decision) - we're generally inclined to take this as a Beta or Final blocker, but we'd like to try and gather some more precise data to be sure how wide the impact is first 16:20:15 #topic (1321330) on i.mx6 systems the console does not start correctly 16:20:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=1321330 16:20:16 #info Proposed Blocker, kernel, NEW 16:20:25 i'm +1 to this, it affects some of our supported ARM platforms. 16:20:28 +1 blocker since I filed it 16:20:50 what's i.mx6 system? 16:20:52 +1 16:21:10 RaphGro: one of teh most popular arm soc'ß 16:21:14 soc's 16:21:23 ok, I'm out of that 16:21:34 +-0 16:21:54 +1 16:22:05 RaphGro: care to share why you voted that way? 16:22:18 no idea about arm 16:22:19 i think he just means he doesn't know about it 16:22:27 yes 16:22:32 +1 16:22:33 does this affect just a single board or more? 16:22:40 neutral vote from me for this bug 16:22:53 kparal: everything with a i.MX6 I have tested 16:22:55 * kparal never heard of i.mx6 16:22:59 RaphGro: you don't really need to, though: just read https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria , click "Supported ARM platforms' under "Release-blocking images must boot" 16:23:04 based on my analysis of the people who know WFT they're talking about said, I'm +1 16:23:08 kparal: wandboard and cubox-i are what I tested 16:23:17 it links to https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms , and that lists systems affected by this bug 16:23:18 those I heard of :) 16:23:38 kparal: i.MX6 is teh soc they use 16:23:39 (though that page could do with a bit of a refresh :>) 16:23:48 ok, seems real world impact, +1. but in fact I think it's the same level of conditional blocker as the grub2 bug 16:23:57 kparal: for ARM the situation is a bit different 16:24:09 kparal: we can't realistically list *every x86 system we support*, but for ARM we actually can 16:24:39 the ARM devices that we explicitly expect to have working are listed, and the rule is basically it's a blocker if one of those is broken. since the set of systems is quite small we don't really need to use the 'conditional blocker' evaluation process. 16:25:44 proposed #agreed 1321330 - AcceptedBlocker (Beta) - violates Alpha criterion "All release-blocking images must boot in their supported configurations" on several supported ARM platforms (see "Supported ARM platforms" footnote) 16:25:45 https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms lists only Fedora 21 and older :) 16:25:52 kparal: yeah, it's still pretty much valid though 16:26:02 as i just wrote, "that page could do with a bit of a refresh" 16:26:19 in that case the BananaPi bug should have been blocker as well. and was accepted just as a FE 16:26:27 the list is pretty long for arm now 16:26:35 which one was that? 16:26:36 my understanding is that is was highbank+1 other 16:26:43 list of supported hw 16:26:47 adamw: nevermind, just thinking aloud. that was in Alpha 16:26:52 ack 16:27:19 welp, anyhow...we can revise later. but we really don't want to ship with i.MX6 broken. 16:27:53 lbrabec: remember that URL and we can use it the next time our bananapi doesn't work 16:28:13 well, we shouldn't block on one board 16:28:26 but this seems to be affecting more boards 16:29:04 lbrabec: adamw just said we would 16:29:24 hi blocker reviewers 16:29:26 that's been the rule so far, anyhow 16:29:28 hi jkurik 16:29:32 vote, people, vote 16:29:38 any other acks/nacks/patches? 16:29:53 yea, i would expect that too, but "We don't block a release on individual devices" are words of pbrobinson 16:30:05 ack 16:30:21 btw: who is proposing/approving what ARM boards&devices we are supporting ? 16:30:30 ack 16:30:32 ack 16:30:41 ack 16:30:49 ack 16:30:57 * danofsatx missed the proposal 16:31:02 jkurik: it's pretty much up to the ARM team so far as I know. 16:31:07 #agreed 1321330 - AcceptedBlocker (Beta) - violates Alpha criterion "All release-blocking images must boot in their supported configurations" on several supported ARM platforms (see "Supported ARM platforms" footnote) 16:31:13 jkurik: as they work upstream we try to support them 16:31:15 jkurik, we support everything upstream 16:32:03 ok, thanks for the answers 16:32:32 so if people wanna take a closer look at the ARM 'supported platform' stuff we can do that on the mailing list or in a QA meeting maybe, but for now let's move along...this bug really ought to be a blocker anyhow, i.MX6 is one of the most important ARM platforms 16:32:34 ok, next bug :) 16:32:34 #topic (1262556) AttributeError: 'NoneType' object has no attribute 'get_data' 16:32:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=1262556 16:32:35 #info Proposed Blocker, NetworkManager, NEW 16:32:52 this seems to be related to wifi discovery in anaconda 16:33:11 * satellit_e only in netinstall? 16:33:23 i don't think so, no, but you 16:33:27 you're more likely to see it there 16:33:32 k 16:33:48 i suspect it'd also happen on DVD if you went into network settings and tried to activate the wifi. 16:33:59 it may not be present in lives because lives defer network configuration to the host desktop. 16:34:04 I've seen it even in the respun F23 lives 16:34:23 but yes, I see this often. annoyingly so. 16:34:29 satellit and atodorov say they saw it after going to the network settings spoke, but when i tested i actually hit it right on the hub (after accepting the pre-release warning) 16:34:51 so it was a complete install blocker for me, unless i plugged in ethernet somehow i guess (affected laptop has no inbuilt ethernet, though, so i'd need USB) 16:34:57 I had wired connected and tried to do wireless spoke 16:35:48 it's timing - it happens at a point in time. Doesn't matter which spoke you enter. 16:36:08 at least, in my case.... 16:36:22 danofsatx: i suspect it depends whether you also have a wired connection, but that's just a guess. 16:36:44 so it seems like a conditional blocker of basically starting the installer 16:37:05 I was hitting it in VMs with no WiFi. 16:37:19 +1 Beta 16:37:35 yeah, i'm +1 based on my experience 16:37:42 +1 Beta 16:37:47 +1 beta 16:38:15 +1 beta 16:38:19 +1 16:40:19 proposed #agreed 1262556 - AcceptedBlocker (Beta) - testing indicates that this bug violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." (and other 'complete an install' criteria) for at least some affected systems, likely wifi-only installs from netinst / DVD 16:41:23 ack 16:41:25 ack 16:41:31 ack 16:41:48 #agreed 1262556 - AcceptedBlocker (Beta) - testing indicates that this bug violates "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." (and other 'complete an install' criteria) for at least some affected systems, likely wifi-only installs from netinst / DVD 16:41:59 #topic (1320395) No 'favorites' in F24 KDE menu 16:41:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=1320395 16:41:59 #info Proposed Blocker, plasma-desktop, ON_QA 16:42:28 could argue this for beta or final, really, depends which panel criterion we want to go with 16:42:39 * satellit_e but you can add them to it 16:43:29 ah, interesting, i didn't try that 16:43:32 so just the defaults are missing 16:45:31 well, don't all rush to vote at once 16:45:34 meh, I'm iffy on this one 16:46:10 the claim of "not functioning" isn't entirely accurate, it's easy enough to fix by right clicking and selecting "add to favorites". 16:46:14 * satellit_e are they listed in .ks 16:46:28 however, being blank is, unsettling. 16:46:32 danofsatx: well, i'd say the defaults are part of the intended functionality. 16:46:42 having to add your own link to launch a web browser is kind of silly. 16:47:40 the question, though, is whether it was fixed with plasma-desktop-5.5.5-5.fc24 16:47:47 danofsatx: no, that's not the question at all. 16:47:54 we're here to decide if it's a blocker, not whether it's fixed... 16:48:15 I know. 16:48:22 I don't think it's a blocker. -1 16:48:24 you can still launch the apps from the menu, right? 16:48:26 if that update had gone stable we could say 'oh, close the bug so we don't need to decide', but the update is still in testing. 16:48:27 * satellit_e FE? 16:48:33 kparal: yeah. if you can find them. this is KDE. ;) 16:48:56 just start typing - apper will find it ;) 16:48:57 I know, I met it already 16:49:11 * adamw nearly fell into the swamp and nearly got eaten by a grue on his way to the firefox launcher, but barely made it in the end 16:49:16 -1 Beta, I think it's not "entirely non-functional" 16:49:51 but maybe we can give it a final blocker with some polish criteria? 16:50:15 or other nationality criteria, if you prefer 16:50:15 final criterion we could use would be "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " i guess 16:50:20 * satellit_e have to leave ...afk 16:50:33 beta criterion is "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional. " 16:50:37 so yeah, i guess it fits better with final... 16:50:41 final is better. it's functional, just not correctly. 16:51:32 i'm for final 16:51:44 -1 beta, +1 final 16:51:47 I'm not fully convinced about Final either, can we just give it -1 blocker and leave it be a week? 16:51:47 I am for final as well, makes more sense for me 16:51:58 * -1 beta blocker 16:52:03 -1 beta, +1 final 16:52:04 kparal: we can, sure. 16:52:11 * adamw tries to count votes 16:52:18 -1 beta, +1 final 16:52:24 well it seems final it is 16:52:32 -1 beta, +1 final 16:52:40 it would be funny if KDE people wanted the bar empty by default :) 16:52:55 but I guess that's not the case 16:53:12 * danofsatx thought it was s'posta be that way 16:53:14 kparal, it's possible in/with xfce, by the way. 16:53:25 * kparal is ok with final 16:53:31 proposed #agreed 1320395 - RejectedBlocker (Beta), AcceptedBlocker (Final) - we agreed this isn't really severe enough to constitute "entirely non-functional" (the Beta wording) but does violate the Final criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." 16:53:40 ack 16:53:44 ack 16:53:47 ack 16:53:57 ack 16:53:58 ack 16:53:59 ack 16:54:03 #agreed 1320395 - RejectedBlocker (Beta), AcceptedBlocker (Final) - we agreed this isn't really severe enough to constitute "entirely non-functional" (the Beta wording) but does violate the Final criterion "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." 16:54:29 OK, moving onto Final blockers 16:54:38 #info that's all for Beta, moving onto Final 16:54:43 #topic (1320396) [abrt] gnome-software: magazine_chain_pop_head(): gnome-software killed by SIGSEGV 16:54:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1320396 16:54:43 #info Proposed Blocker, gnome-software, NEW 16:55:35 i didn't investigate this one super thoroughly, but it certainly seems like you get a GNOME Software crash after install and first boot of F24 Alpha Workstation, and you don't get an update notification. seemed reasonable to guess they're connected. 16:55:44 +1 16:56:08 +1 16:56:09 did others see the same crash in testing? 16:56:25 I have a hard stop in 5 mins, I'm going to vote in tickets for blockers. 16:57:03 +1 16:57:10 * kparal hasn't tested this yet 16:57:16 danofsatx: thanks 16:57:26 pschindl: welcome 16:57:51 hi all. 16:58:12 +1 (what we are talking about?) 16:58:14 evening pschindl 16:58:21 just figured out how to get on wifi at the bar? 16:58:23 pschindl: see #topic 16:58:26 +1 16:58:51 +1, this seems to be a clear violation of the criterion 16:58:53 still +1 :) 16:59:14 proposed #agreed 1320396 - AcceptedBlocker (Final) - this appears to violate "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." 16:59:30 it'd be good if other folks can double-check this happens to them too, btw 16:59:35 always good to have confirmation 16:59:36 ack 16:59:53 adamw: to answer your question - I have not tested this 16:59:56 +1 16:59:58 adamw: They gave me the password after fifth beer. I tried to drink fast. I should train more. 17:00:07 argh, too late 17:00:11 ack 17:00:20 ack 17:00:26 ack 17:00:28 pschindl: make sure you put that in your compass 17:00:33 #agreed 1320396 - AcceptedBlocker (Final) - this appears to violate "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." 17:00:42 #topic (1320666) Show correct Fedora 24 background in KDE 17:00:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1320666 17:00:43 #info Proposed Blocker, kde-settings, ASSIGNED 17:00:59 I'm working on the review :) 17:01:04 so for Alpha KDE got hacked to show some upstream background, which is fine per alpha/beta criteria, but for Final we require the *correct* background 17:01:05 it looks quite trivial so far 17:01:05 thus, +1 17:01:10 +1 17:02:13 clearly +1 17:02:20 +1 17:02:26 +1 17:02:30 +1 17:02:35 +1 17:03:14 did we hire a prophet when creating those criteria? who would have thought... 17:07:13 re adamw` 17:07:52 darn IRC 17:07:56 yay 17:08:10 I missed all the votes after raphgro's +1 17:08:12 power failure? 17:08:22 no, just lost IRC connection for some mysterious reason./ 17:08:27 [19:01:10] +1 17:08:28 [19:02:13] clearly +1 17:08:28 [19:02:20] +1 17:08:28 [19:02:26] +1 17:08:28 [19:02:30] +1 17:08:28 [19:02:35] +1 17:08:30 [19:03:14] did we hire a prophet when creating those criteria? who would have thought... 17:08:33 [19:07:02] * adamw` (~adamw@happyassassin.net) has joined 17:08:34 thanks 17:09:15 proposed #agreed 1320666 - AcceptedBlocker (Final) - clear violation of "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops." 17:09:24 ack 17:09:27 ack 17:09:27 ack 17:09:33 #agreed 1320666 - AcceptedBlocker (Final) - clear violation of "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops." 17:09:36 * RaphGro runs f-r tool on the blocking bug 17:09:43 #topic (1314637) SELinux is preventing fwupd from 'write' accesses on the directory 0000:00:02.0. 17:09:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1314637 17:09:44 #info Proposed Blocker, selinux-policy, MODIFIED 17:10:20 this seems like it may be hardware dependent? 17:10:50 pschindl: what's the affected system? 17:11:31 his Thinkpad something 17:11:40 hmm, https://bugzilla.redhat.com/show_bug.cgi?id=1300456 has more info 17:11:42 and more affected people 17:11:56 i'm fine with +1 for this based on 1300456, even if it's hardware dependent, obviously lots of people hit it 17:11:57 It happened on my working laptop 17:12:20 But I think that I haven't seen it for some time. So I'm not sure if it still occures. 17:12:22 +1 17:13:01 why this should be hardware dependent? 17:13:10 I saw it during Alpha "RC" testing. 17:13:16 jkurik: fwupd is the firmware update thing 17:13:26 and "0000:00:02.0" looks like a hardware identifier 17:13:37 so i'm figuring it may only happen if you have some particular type of hardware fwupd kicks in for 17:13:41 yes, but the write access is denied by selinux, not by a HW 17:13:56 sure, but fwupd may only *try* and do the blocked thing if some supported HW is present 17:14:08 ah, ok 17:14:16 And I probably have seen it on virtual machine too (still on the same hardware). 17:14:20 still, it seems enough people run into this that it doesn't really matter 17:14:33 pschindl: i don't think i saw it in my VM testing, though some elements of VM config can be based on the host... 17:14:37 anyhoo 17:14:39 * adamw counts votes 17:14:47 then I am +1 to block on this 17:14:57 ok, that's 3/4 17:15:27 +1 too 17:15:27 proposed #agreed 1314637 - AcceptedBlocker (Final) - violates "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." It's not clear whether this is at all hardware-dependent, but even if it is, it's clear many people are hitting it, enough to take it as a blocker 17:15:29 +1 17:15:41 ack 17:15:42 ack 17:15:44 ack 17:15:55 #agreed 1314637 - AcceptedBlocker (Final) - violates "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." It's not clear whether this is at all hardware-dependent, but even if it is, it's clear many people are hitting it, enough to take it as a blocker 17:18:24 oops, sorry, next bug 17:18:34 #topic (1316514) SELinux is preventing colord from 'read' accesses on the file /etc/udev/hwdb.bin. 17:18:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=1316514 17:18:34 #info Proposed Blocker, selinux-policy, MODIFIED 17:19:34 +1 17:19:42 +1 17:19:43 +1 17:20:03 proposed #agreed 1316514 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." 17:20:12 ack 17:20:46 ack 17:21:10 ack 17:21:42 ack 17:22:39 #agreed 1316514 - AcceptedBlocker (Final) - clear violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." 17:23:03 ok, last one: 17:23:03 #topic (1318045) Incorrect keymap when decrypting encrypted partitions 17:23:04 #link https://bugzilla.redhat.com/show_bug.cgi?id=1318045 17:23:04 #info Proposed Blocker, systemd, NEW 17:24:15 +1 17:24:16 I think that this thing happens also for older releases 17:24:51 bricks obviously user system 17:24:51 we used to have a lot of trouble with this 17:24:55 it's been pretty quiet lately 17:24:56 And I can't remember that we blocked due to this in past. 17:25:18 FE? 17:25:40 no, it is clearly a blocker if it's reproducible 17:25:49 we explicitly block on this and explicitly have a test case to catch it 17:26:08 i'm just surprised it came back, i thought we'd finally squished it for good :/ 17:26:23 i trust giulio so i'm +1 on this, of course it'd be good to reproduce and investigate more 17:26:44 haven't we waived some languages as "too difficult to fix"? 17:26:58 * kparal2 remembers some asian lang issues 17:27:38 kparal: long story short, this is not that. 17:27:41 I'm +1 too. Because it really violates the criterion. 17:27:58 +1 17:28:01 there is no technical reason we cannot use the same keymap when entering the encryption passphrase as we used when setting it. 17:28:13 (I don't think.) 17:28:23 https://bugzilla.redhat.com/show_bug.cgi?id=681250 17:28:40 That's the bug I remember :) 17:28:47 the case we wouldn't be able to 'fix' is if the 'it' console layout is a switchable one that's set to US by default 17:28:50 but i don't believe it is 17:29:14 right, that's the case with one of the czech layouts 17:29:34 right 17:29:38 so i don't think this case is that case 17:29:42 lemme just have a quick look at the it layout 17:29:54 we should probably note this case in the test case instructions i guess 17:30:50 no, it doesn't look like the italian layout is a switched one, so i don't think this is a case of 681250. i'm still +1 17:31:29 +1 17:31:51 +1 17:32:02 +1 17:32:13 +1 17:33:03 I am +1 even I am not sure it is a problem of systemd, however the criterion is broken 17:33:43 +1 17:35:17 proposed #agreed 1318045 - AcceptedBlocker (Final) - as described, this is a clear violation of "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When unlocking encrypted storage volumes during boot" 17:35:29 i'm adding a footnote about 681250 to the criteria right now, for the record. 17:35:50 ack 17:35:52 ack 17:36:05 ack 17:36:47 ack 17:37:21 #agreed 1318045 - AcceptedBlocker (Final) - as described, this is a clear violation of "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When unlocking encrypted storage volumes during boot" 17:37:27 OK, that's all the proposed blockers 17:37:49 is anyone super keen to go through accepted beta blockers (I don't really see anything we urgently need to discuss) or proposed Beta FEs, or do you all wanna get out of here? 17:38:16 * kparal has quit 17:38:41 ack to get out of here :-) 17:38:52 I need to leave anyway ... 17:39:10 thanks 17:40:24 message received :) 17:40:26 thanks for coming folks 17:40:30 thanks 17:40:30 * adamw lights the fuse 17:40:40 * kparal goes afk 17:42:21 #endmeeting