18:01:13 #startmeeting F26-blocker-review 18:01:13 Meeting started Mon Feb 13 18:01:13 2017 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:13 The meeting name has been set to 'f26-blocker-review' 18:01:13 #meetingname F26-blocker-review 18:01:13 The meeting name has been set to 'f26-blocker-review' 18:01:13 #topic Roll Call 18:01:25 Hi 18:01:30 .fas lailah 18:01:31 Kohane: lailah 'Sylvia Sánchez' 18:01:37 who's around for exciting blocker meeting fun? :) 18:01:39 hi sylvia! 18:01:40 * kparal is here 18:01:49 Hi Adam! 18:02:02 * coremodule is here, ready for secretarialization duties. 18:03:38 #info coremodule will secretarialize 18:03:41 #chair coremodule 18:03:41 Current chairs: adamw coremodule 18:03:54 * pschindl_ is here 18:04:27 .hello 18:04:27 roshi: (hello ) -- Alias for "hellomynameis $1". 18:04:30 .hello roshi 18:04:31 roshi: roshi 'Mike Ruckman' 18:04:33 hi roshi, pschindl 18:04:38 #chair pschindl_ roshi 18:04:38 Current chairs: adamw coremodule pschindl_ roshi 18:06:10 looks like we've got a decent turnout 18:06:19 let's have some exciting boilerplate! 18:06:30 everyone loves boilerplate. 18:06:30 #topic Introduction 18:06:30 Why are we here? 18:06:31 #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. 18:06:32 #info We'll be following the process outlined at: 18:06:34 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 18:06:36 #info The bugs up for review today are available at: 18:06:38 #link http://qa.fedoraproject.org/blockerbugs/current 18:06:40 #info The criteria for release blocking bugs can be found at: 18:06:42 #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria 18:06:44 #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria 18:06:46 #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria 18:07:12 we have: 18:07:16 #info 3 Proposed Blockers (Alpha) 18:07:26 #info 2 Proposed Blockers (Beta) 18:07:35 #info 3 Proposed Blockers (Final) 18:07:41 so let's start right in on the Alpha proposals 18:07:49 #topic (1412750) Multiple services in recent Rawhide fail to start with: Failed at step USER spawning (executable): Permission denied 18:07:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=1412750 18:07:50 #info Proposed Blocker, selinux-policy, MODIFIED 18:08:41 * satellit listening 18:09:09 * Kohane reading 18:09:53 * pwhalen is here 18:09:53 Does this just break cockpit or does it break other things as well? 18:09:55 +1 18:09:59 +1 18:10:09 coremodule: several other services too 18:10:18 i'm still +1 on this one, for the record 18:10:22 +1 18:10:27 haven't really been able to tell if the fix works yet what with all the other breakage 18:10:51 +1 18:10:53 +1 18:10:54 +1 18:10:59 (sorry I'm late) 18:11:31 +1 18:11:41 +1 18:12:17 +1 18:13:20 sorry, phone call 18:13:39 proposed #agreed 1412750 - AcceptedBlocker (Alpha) - violates "Unless explicitly specified otherwise, after system installation the Cockpit web management interface must be running and accessible on its default port (9090)" and probably other criteria 18:13:52 ack 18:13:53 ack 18:13:55 ack 18:14:21 #agreed 1412750 - AcceptedBlocker (Alpha) - violates "Unless explicitly specified otherwise, after system installation the Cockpit web management interface must be running and accessible on its default port (9090)" and probably other criteria 18:14:29 #topic (1419946) "agetty: can not connect on UNIX socket" on tty1 after boot, have to use tty2 to log in after 3.13.1-236 update 18:14:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1419946 18:14:29 #info Proposed Blocker, selinux-policy, MODIFIED 18:15:04 I'm +1 18:15:08 +1 18:15:15 +1 18:15:25 +1 18:15:36 +1 18:15:37 It says fixed on the bottom...? 18:15:39 +1 18:15:49 +1 anyway 18:15:53 Kohane: it's modified 18:15:58 +1 18:15:59 Ah 18:16:00 we haven't had a compose with the fix yet so can't be sure if it's fixed 18:16:02 would tty1 be where x is in fedora? 18:16:08 adamw: thanks 18:16:13 Southern_Gentlem: well, yeah, but this doesn't actually stop X (or Wayland) starting 18:16:16 Kohane: MODIFIED means that a fix went to the upstream policy, but hasn't made it to Fedora ytet 18:16:17 Southern_Gentlem: it's specific to agetty 18:16:32 Southern_Gentlem: but the 'no serial logins' case seems blockerish 18:16:58 updating to selinux-policy-3.13.1-239 fixes it, serial console works 18:17:04 you know...i don't think this actually strictly violates the alpha criteria 18:17:05 +1 18:17:08 but i dunno how hard i want to argue it. 18:17:34 adamw: What about pwhalen's criterion? 18:17:57 sgallagh: i wrote that, it means "you have to be able to login on at least one VT". 18:18:03 it wasn't really supposed to be about serial console logins. 18:18:04 It specifically refers to non-graphical logins 18:18:06 I grabbed what looked reasonable. its a remote system so the default login is serial console 18:19:05 for Beta we have "The installer must be able to complete an installation using the serial console interface.", which you could argue should also mean you can log in that way 18:19:05 If there's a fix on the way, shouldn't we wait until it reaches Fedora and then see if it's a blocker or not? 18:19:08 but i don't think there's anything for alpha 18:19:17 Kohane: no, that's the exact opposite way to how the process works :) 18:19:30 Oh, sorry 18:19:50 keep moving before we talk ourselves into a hole 18:20:06 i can just go with the vote, i guess, though it seems to be establishing new policy. 18:20:42 adamw: Can you still log in with a local keyboard and screen? 18:20:42 proposed #agreed 1419946 - AcceptedBlocker (Alpha) - this was considered a violation of the criterion "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", apparently in relation to serial console login. 18:20:45 sgallagh: yes. 18:20:47 I didn't get that from the ticket 18:21:05 sgallagh: the description says "have to use tty2 to log in after 3.13.1-236 update" 18:21:16 which pretty clearly implies that one *can* login on tty2. :) 18:21:30 Ah, hmm. 18:21:35 Sorry, I misunderstood the problem. 18:21:35 yeah, I suppose that's true 18:21:50 If you can login on tty2, I'm actually switching to -1 18:21:59 (at least for Alpha) 18:22:22 i think it's worth considering whether we should block on serial console login for alpha, but i don't think it's easy to argue we currently *do*. :) 18:22:33 lol, true 18:22:38 So you can't login on tty1 but you're still able to login on tty2. Is this right? 18:22:45 Kohane: yes. 18:22:49 (or 3, 4, 5 or 6, i think). 18:22:54 -1 18:22:55 on a remote system, you can't login. you cant change tty's 18:23:01 Then I don't think is a blocker really 18:23:08 You're still able to login 18:23:14 -1 18:23:29 pwhalen: I' 18:23:30 I understood something different, I guess I missed something. 18:23:34 I'm comfortable with Beta Blocker 18:23:39 yes 18:23:39 On the installer criterion 18:23:45 yeah, i'll go +1 beta 18:23:55 and i'm open to a proposal that alpha should cover remote login 18:24:17 adamw: That's specifically serial console, or ssh as well? 18:24:24 undecided 18:24:27 let's paint the bikeshed later :P 18:24:31 agreed 18:24:38 works for me 18:24:53 (Reminder: if anyone wants this to be a blocker REALLY badly, feel free to petition FESCo for their override) 18:24:53 so, new proposal 18:24:58 -1 Alpha +1 beta 18:25:01 (Alpha blocker, I mean) 18:25:29 I wont be able to do a large portion of arm testing without serial logins 18:25:49 proposed #agreed 1419946 - AcceptedBlocker (Beta) - this is agreed to be a violation of "The installer must be able to complete an installation using the serial console interface." combined with "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention" 18:25:54 pwhalen: Not marking it a blocker doesn't prevent anyone from fixing it. 18:25:58 pwhalen: in practice it's being fixed anyhow 18:26:03 its fixed 18:26:06 right 18:26:07 we're not in freeze, it doesn't need blocker/fe status to get in 18:26:19 so there's no urgent need to rewrite alpha rules on the fly 18:26:24 sure. 18:26:28 but please do go ahead and make a proposal to change them if you think it makes sense 18:26:28 ack 18:26:37 ack 18:26:38 ack 18:26:44 as things stand, though, they're quite clearly written to only require serial console to work at beta 18:26:53 #agreed 1419946 - AcceptedBlocker (Beta) - this is agreed to be a violation of "The installer must be able to complete an installation using the serial console interface." combined with "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention" 18:27:02 #undo 18:27:02 Removing item from minutes: AGREED by adamw at 18:26:53 : 1419946 - AcceptedBlocker (Beta) - this is agreed to be a violation of "The installer must be able to complete an installation using the serial console interface." combined with "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention" 18:27:15 #agreed 1419946 - RejectedBlocker (Alpha) AcceptedBlocker (Beta) - this is agreed to be a violation of "The installer must be able to complete an installation using the serial console interface." combined with "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention" 18:27:36 adamw: Also, it may be a moot point to revise the criterion, as Alpha is supposedly going away in F27 :) 18:27:41 well, true =) 18:27:50 though we may have 'rawhide acceptance criteria' or something, i guess. 18:27:50 #topic (1420753) "systemd-udevd.service: Failed at step ADDRESS_FAMILIES spawning" for PowerPC 18:27:51 #link https://bugzilla.redhat.com/show_bug.cgi?id=1420753 18:27:51 #info Proposed Blocker, systemd, NEW 18:28:08 ppc isn't a release blocking arch, is it? 18:28:20 -1 18:28:33 nope 18:28:41 -1 18:28:54 -1 since it's PowerPC 18:28:58 We're sure this only affects PPC64? 18:29:04 we can convert this to FE if it makes sense 18:29:20 sgallagh: seems pretty clear from the discussion. 18:29:31 Zbigniew's reply suggests "non-AMD64 arches"... 18:29:45 the openQA tests before compose started failing had lots of problems, but not this one. 18:29:47 hmm, point. 18:30:47 do we know if it affects armhpf? pwhalen? 18:31:09 i think we punt for more info 18:31:49 i'd be more inclined to -1 with option to revote if it affects armhpf 18:31:57 afaik, only x86_64 and armhfp are current release blocking arches 18:32:17 Okay, then -1 18:32:28 thats why lets punt for now 18:33:06 adamw, I havent seen it 18:33:23 meh, i just don't want the work of voting on it again later. :P disregarding gentlem's earlier -1, i count -4 18:33:28 anyone else want to change to punt? or else we'll go with -1 18:33:30 -1 18:33:55 Can we suggest that they propose it as a Prioritized Bug? 18:34:04 (Because obviously it's a real issue) 18:34:08 sure 18:34:22 oh, i can be +1 FE too 18:34:25 any other FE votes? 18:34:54 +fe 18:34:56 +1 fe 18:35:11 +1 fe 18:35:44 -1 +fe 18:35:44 +1 FE 18:35:49 I'm -1 FE for anything having to do with systemd, honestly 18:35:52 Too much risk 18:35:53 +1 fe rather 18:36:14 proposed #agreed 1420753 - RejectedBlocker AcceptedFreezeException (Alpha) - on current information this doesn't affect either release-blocking arch (x86_64 or armhfp) so cannot block Alpha, but it is accepted as a freeze exception issue as a major bug for non-blocking arches. we also suggest it could go to the PrioritizedBug process. 18:36:44 sgallagh: hmm, point. i'm +1 on the basis we request a backport of the fix, not a new systemd release build. 18:36:51 (if it goes in after freeze) 18:37:06 ack 18:37:12 ack 18:37:14 ack 18:38:21 #agreed 1420753 - RejectedBlocker AcceptedFreezeException (Alpha) - on current information this doesn't affect either release-blocking arch (x86_64 or armhfp) so cannot block Alpha, but it is accepted as a freeze exception issue as a major bug for non-blocking arches. we also suggest it could go to the PrioritizedBug process. 18:38:33 coremodule: can you note the 'backport not new systemd release' thing in the comment? 18:38:45 Sure! Got it. 18:38:48 #info that's it for Alpha blockers 18:38:50 going onto Beta 18:38:58 #topic (1376638) rescue mode cannot mount a default Fedora install 18:38:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=1376638 18:38:58 #info Proposed Blocker, anaconda, ASSIGNED 18:39:30 * Kohane has to rush a moment, BRB sorry 18:39:36 the last status i had on this was it would *sometimes* work but still most often fail 18:39:39 might be a race 18:39:42 Kohane: npnp 18:39:48 don't know status lately with all the other breakage 18:40:04 +1, seems clear 18:40:36 +1 18:40:40 +1 18:40:43 +1 18:42:11 proposed #agreed 1376638 - AcceptedBlocker (Beta) - since latest known status is this still frequently fails, it's accepted as a Beta blocker as a violation of "The rescue mode of the installer must start successfully and be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations." 18:42:18 +1 18:42:26 ack 18:42:32 ack 18:42:33 ack 18:42:36 ack 18:43:15 #agreed 1376638 - AcceptedBlocker (Beta) - since latest known status is this still frequently fails, it's accepted as a Beta blocker as a violation of "The rescue mode of the installer must start successfully and be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations." 18:43:21 #topic (1414391) single partition disks not visible in custom partitioning dialog 18:43:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=1414391 18:43:22 #info Proposed Blocker, anaconda, NEW 18:44:50 seems to hit the criterion 18:44:51 so +1 18:45:12 +1 18:45:14 +1 18:45:24 +1 18:45:25 * Kohane still reading 18:45:30 +1 18:45:39 +1 18:46:21 +1 18:46:48 proposed #agreed 1414391 - AcceptedBlocker (Beta) - seems like a clear violation of "When using the custom partitioning flow, the installer must be able to: ... Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions ..." 18:47:01 ack 18:47:06 ack 18:47:19 ack 18:47:26 ack 18:48:05 ack 18:48:26 #agreed 1414391 - AcceptedBlocker (Beta) - seems like a clear violation of "When using the custom partitioning flow, the installer must be able to: ... Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions ..." 18:48:38 #info that's all for Beta, onto Final! 18:48:47 #topic (1340203) goa-daemon not stopped on logout, and gnome-keyring unusable on next log in 18:48:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1340203 18:48:47 #info Proposed Blocker, gnome-online-accounts, NEW 18:50:42 hum, not sure about this. 18:51:28 +1 final 18:51:29 i think i'd be -1 blocker on this. the mechanism basically works. i don't think a possibility of it stopping working on a logout/login cycle is enough to block release, particularly since the bug exists in current releases. 18:51:49 * adamw narrows eyes 18:51:53 if keyring breaks on logging out, I think it violates our criteria 18:52:11 i don't think it's that straightforward. 18:52:13 adamw: it doesn't happen to me 18:52:19 yeah, doesn't happen to me either. 18:52:31 from a quick scan, it sounds like it's a race-y / ordering-y systemd thing. 18:52:38 and it seems to have been around for a while. 18:52:40 I've seen it few times (on rawhide). 18:53:06 i may have seen it happen once or twice and dismissed it as some weird passing thing, in fact. but it clearly doesn't happen to everyone every time they log out, i don't think. 18:53:14 I think we should not distinguish "clean" login and repeated login, that doesn't make sense to me 18:53:15 I'm -.5 on this 18:53:22 i can see as the crit is written that it could be a blocker 18:53:24 however, if this is a race, I can see -1 here 18:53:42 kparal: that's why i said 'a possibility of it stopping working'. 18:53:46 i.e., it doesn't always happen. 18:53:59 alright 18:54:16 do read it yourself and confirm, though, i just scanned the report 18:54:19 * adamw reads more closely 18:54:20 I didn't manage to read it all 18:54:22 I'm -1 as it doesn't happen allways. But I'm +1 because when it happens it is really annoying 18:54:27 +1 FE 18:54:37 I think it's serious bug but I'm not sure if it's *that* serious to mark it as blocker. I can't decide.... 18:54:40 pschindl_: do you have an estimate how often it happens? 18:55:33 * Southern_Gentlem is going to go test real fast 18:55:42 I'm not sure. I doen't reboot or logout too much so I can't estimate it 18:56:18 It's not everytime. 18:56:26 * Kohane does a quick test and comes back, just to check it still doesn't happen in her laptop 18:56:48 the upstream bug does have quite a few dupes 18:56:57 ok then, if it is not every time, I guess I'm not +1 18:56:59 hum. i think i might change my vote to 'punt and ask devs for a clear summary of how bad this is' 18:57:20 sounds good 18:58:41 Okay, I just checked. It doesn't happen to me. 18:59:04 Kohane, and you are running gnome correct 18:59:19 yes, 18:59:30 It's Workstation, with no other desktops installed. 19:00:16 i am agreeing with adamw i think punt till we can get more info 19:00:22 +1 punt 19:00:34 wfm 19:00:53 pschindl, punt OK for you? 19:01:03 adamw: yes 19:01:07 +1 punt 19:01:13 yes, +1 punt 19:01:35 +1 punt 19:01:43 proposed #agreed 1340203 - punt (delay decision) - it's a bit difficult to get a feel from the bug report for exactly how common this problem is. we'd like to ask the devs for a concise summary of how big a problem it is before we vote 19:01:52 ack 19:01:55 ack 19:02:07 ack 19:02:43 ack 19:02:48 #agreed 1340203 - punt (delay decision) - it's a bit difficult to get a feel from the bug report for exactly how common this problem is. we'd like to ask the devs for a concise summary of how big a problem it is before we vote 19:03:03 #topic (1405539) changing the default keyboard layout changes also disk decryption in plymouth, but only after kernel update, long after 19:03:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=1405539 19:03:03 #info Proposed Blocker, plymouth, NEW 19:03:28 so we kinda argued about this one a bit and punted it last time 19:03:32 one would hope this fixes itself during the past 3 weeks, right? :) 19:03:33 did anyone get any significant new info? 19:04:29 no new info. but I guess I'm tired of fighting serious gnome bugs when gnome devs don't really care 19:04:56 so, when thinking about this, I guess we should split this into two parts. how serious it is and how many users it affects, and decide based on that 19:04:59 i know we found lots of problems with fixing it. like plymouth can't really draw a keyboard layout indicator on the screen because it has no concept of glyphs. and also, knowing which 'console layout' is active for 'switched console layouts' is either difficult or outright impossible, because of how they really work. 19:05:54 well I wasn't really talking about "the ultimate fix", but about minimizing the likelihood that this happens to a user (without being warned) 19:06:00 that's not that difficult 19:06:12 that's all this bug was about 19:06:34 so when a new kernel is installed so dracut is ran correct 19:06:59 so, about seriousness, I think this is very serious, because it is basically "device bricked" for ordinary users 19:07:14 which is nt correct because it happens long time afterwards 19:07:32 well, even just running dracut right away doesn't really 'fix the problem' 19:07:35 how many users this affects: those with encrypted disks & multiple user accounts & changing their default keyboard layout 19:07:36 they might still not reboot for a long time 19:08:14 adamw: I don't follow 19:08:24 say you change the layout, then don't reboot for two weeks 19:08:33 maybe you forget about it then too 19:08:36 i dunno, i guess it's not as bad. 19:08:49 you don't have the gap where it keeps being the old layout then, i guess. 19:08:53 ok, yeah, it might not be obvious if you don't reboot for a long time 19:09:46 so I guess I'd decide this based on the number of affected users, see above 19:09:56 which we might only guesstimate, of course 19:10:05 you know, i start to think the only valid 'solution' for this is something like android where you can only use numbers. and you get an onscreen keyboard. :P 19:10:26 but yeah, there's definitely stuff that could be done to make it less bad. 19:10:40 I think saying "this might break your disk encryption password" in a dialog is also a valid "solution" 19:11:40 +1 to the warning, in any case 19:11:45 if we could make that happen 19:11:53 having a warning, and running dracut right away, might both help 19:11:57 damn, I was wrong. not multiple accounts, not a single account 19:12:07 argh 19:12:10 so, once again: 19:12:19 how many users this affects: those with encrypted disks & single user account & changing their default keyboard layout 19:12:39 that drops the number of people affected down by a bunch 19:12:42 IMo at elast 19:12:44 least 19:12:50 I guess it's mostly corporate users 19:12:54 * roshi swears he could type at one time in his life 19:12:55 roshi: hum? i'd kinda guess it'd be the other way 19:12:58 kparal: so it affects to those who have only one account as well? 19:13:00 not sure how many ordinary users encrypt their disks 19:13:03 single user account seems like a more common case than multiple 19:13:06 is there a button to apply the settings systemwide, when there are multiple accounts? 19:13:12 but not changing keyboard layouts 19:13:16 Kohane: it's more likely to affect them 19:13:17 adamw: yes 19:13:20 oh, and the account has to be an admin 19:13:23 if anything is a "set and forget" I'd think it'd be the layout 19:13:24 Kohane: the difference is this: 19:13:25 Oh... 19:13:31 if you have a single user account, it's usually admin :) 19:13:38 Yes, I know 19:13:47 I have my laptop that way, haha 19:13:49 when there are multiple accounts, and a single user changes a setting like this in GNOME, the change is only applied to that user's account by default 19:13:57 if you have multiple accounts, you need to use "login screen" button first to indicate it's a system-wide change 19:14:05 if you have a single user account and that user is an admin, then when you make a change like this in GNOME, GNOME automatically applies the change systemwide 19:14:38 kparal: right, but then of course the label on that button is a lie...so you *could* still hit this and not know what's going on if there are multiple accounts, it just requires an extra step... 19:14:56 yes, just decreases the likelihood 19:15:02 but you can still hit it, sure 19:15:53 so i guess i'm pulled a few different ways here. i suspect this still doesn't ultimately hit *that* many people. but on the other hand, if you do hit it and not know what's going on, it's really bad. but on the gripping hand, i'm always kinda reluctant to take bugs without clear solutions as blockers 19:16:31 * adamw dreams of the day someone acknowledges his 'gripping hand' references 19:16:46 sorry, not me 19:16:49 =) 19:16:50 adamw: LOL 19:17:35 so, how frequent is "encrypted & single user & change layout" use case, what do you think? 19:17:59 i'd be guessing as much as you, quite honestly 19:18:26 it's already a prioritized bug, which might not mean much 19:18:46 it means top men are on it 19:18:48 TOP. MEN. 19:19:16 Well... changing keyboard layout isn't weird, isn't it? But I'm guessing as well. 19:19:25 honestly I'm pretty pissed that there seems to be no will to add at least a warning label. but if people think it does not affect too large audience, I'm not going to fight for this 19:19:39 Kohane: it's not that weird, but i mean, there isn't a *lot* of call for doing it. you don't usually just suddenly go get a keyboard with a different layout. 19:19:55 keyboard layouts are very frequent in non-us countries 19:19:58 I've only changed my layout after install to test something, but have no idea if others change layouts for funzies 19:20:01 non english speaking, rather 19:20:01 kparal: i really honestly don't know. i don't follow the forums as much as i used to 19:20:17 kparal: well sure, but usually, you pick the right one at install time. 19:20:23 I have 3 different layouts and permanently switch between them, Am I rare then? 19:20:25 i think? 19:20:42 Kohane: i'd say you're in a minority, but more importantly, do you change which one is the *default*? 19:20:46 adamw: not really, because on some layouts some characters are either missing or very hard to type 19:20:50 just switching layout at run time doesn't cause this bug to happen 19:20:59 you have to go into the GNOME preferences and change the order of the layouts there 19:21:03 yeah, it's a changing the default 19:21:22 right, but having multiple layouts makes it more likely that you go and change the default 19:21:26 kparal: i'd figure the normal case there would be just to add another layout and do switching, not change the default. but i'm entirely guessing at that point 19:21:30 sure, it does make it more likely 19:21:45 adamw: I don't know which one is the default, they are too many. I just looked and it's 4 not 3 (0_0) 19:22:27 Kohane: the one at the top of the list in the GNOME preferences is 'the default' so far as GNOME is concerned, IIRC. if you change which one is at the top of the order, GNOME will make an effort to make that layout your console layout (the one used on VTs and during boot) 19:22:38 as I say, I'm not going to fight this :) it's true that having multiple layouts doesn't mean you go and adjust the default one 19:23:15 kparal: i kinda feel like ultimately it comes down to just making a flat out guess about how common this is. because i really have no good evidence 19:23:22 I agree with kparal that there should be a warning 19:23:57 anybody wants to guess if this affects a reasonable portion of our userbase? 19:24:09 i'd really rather not, but if it comes down to it, we'll have to :P 19:24:25 I think it's a reasonable portion of the userbase but I don't know how large is. 19:25:05 sigh. let's do automation. it's easier 19:25:06 I did change the default a couple of time because my laptop has a weird US keyboard. But I gave up in the process. 19:25:25 a couple of times * 19:25:52 we could ask i18n / l10n groups i guess? 19:25:59 they might have a better chance at making a reasonable guess 19:26:09