Created attachment 1151842 [details]
Using Fedora-Workstation-Live-x86_64-24_Alpha-1.1.iso and trying to install with the Arabic locale anaconda fails to switch the keyboard layout between ara and us.
Created attachment 1151848 [details]
As per request on #fedora-qa, this is a screenshot showing the change kb layout icon, it's in the top left.
FWIW, the same issue happens with other locales, e.g. italian, so it seems it's not specific to the Arabic layout.
The same issue still happens with Fedora-Workstation-Live-x86_64-24_Beta-1.2.iso , I'll attach the new anaconda.log
Created attachment 1152139 [details]
I tested with the workstation netinstall iso, and I can switch the keyboard layout from Arabic to English us without any problems.
can you switch layouts using the normal desktop method for switching? when running live, anaconda usually defers various things like network configuration to the desktop environment. though the UI probably doesn't make this clear for the case of keyboard layout switching.
This worked with the 20160424.n.0 compose but is broken with beta 1.2 and 1.4.
There's nothing to switch in the Live session, since it's just one input source, English us, there's no kb indicator... etc.
5:01:54,324 ERR anaconda: Failed to get the value for the systemd-localed's X11Layout property
15:01:54,324 ERR anaconda: Failed to get the value for the systemd-localed's X11Options property
15:01:54,325 ERR anaconda: Failed to set layouts: ('Unable to connect to system bus: %s', GLib.Error('Could not connect: No such file or directory', 'g-io-error-quark', 1))
15:01:54,326 ERR anaconda: Failed to set layouts: ('Unable to connect to system bus: %s', GLib.Error('Could not connect: No such file or directory', 'g-io-error-quark', 1))
OK, I tested this myself and can reproduce and provide more details.
If you select an installation language with a default 'switched' config (two layouts) - e.g. Russian - or manually add two layouts in the Keyboard spoke, when running live:
* anaconda will show its layout switcher
* the cursor will change to the 'finger' icon when moved over it
* clicking the indicator will not switch the layout. you may momentarily see the name of the other layout appear, but then it will immediately flip back to the original layout. the other layout never actually appears to be *active* even for a split second
* if you go into GNOME's Input Sources and add both the layouts, GNOME will display a switcher and you will be able to switch using that, and anaconda's indicator will correctly reflect the current setting, but you still cannot switch using anaconda's switcher
* in F23 Workstation live, this works fine, anaconda's switcher correctly switches the layout
so this definitely smells like a bug, not a case of anaconda deferring to the host desktop when run live: for one thing it worked fine in F23, for another thing we can't be expecting the user to go and duplicate the config in the GNOME settings just to get a switcher.
I can't confirm the bit about 20160424.n.0 working, though. I tested with an 20160421.n.0 nightly and it was broken, and there *was* no 20160424.n.0 Workstation live AFAICS. I'll try with a few other images later today.
Ahmad confirmed he tested 20160424.n.0 netinst (not live), so it looks like this has been broken for lives at least since Alpha.
Using the keyboard shortcut (Alt+Shift) to switch the kb layouts also fails.
I've just tested with the KDE Live beta 1.6, and switching the keyboard layout in Anaconda works as expected; so far the problem seems specific to the WS Live iso.
I tested the XFCE live beta 1.4 Live iso and the kb layout switch works as expected.
I have played with this with Fedora-Workstation-Live-x86_64-24-20160529.n.0.iso. It's still present. The keymap seems to be switched for a split second and immediately returns to the previous value. Moreover, I believe we should definitely discuss whether this is a blocker or not. For some languages, this has serious consequences:
* If you pick a non-ascii keyboard (or a language which pre-selects such), you can't create a user during installation, because login has to be ascii-only and you can't input ascii characters (the keymap switcher doesn't work). That in itself violates " A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system. ".
* A similar problem happens for the both user and root password - there's a warning that you should provide an ascii-only password, but you can't. Non-ascii values are accepted, but you might have a problem inputting them in various parts of the system (as the installer says).
If you want to work around the two problems mentioned above (and know about it in advance, because you can't adjust keymaps after installation begins), you have to go to keymap switcher and set US keyboard as the first one. However, that precludes you from inputting non-ascii characters e.g. to the user name field.
You can work around the problem with the *GNOME* layout config tool (in the control center), at least in my experience. But yeah, it is quite bad.
for me is: -1 blocker
An anaconda team assessment of the bug, and how soon and invasive/risky a fix would be, would be useful in determining if this is blocker or FE worthy. The work around off hand is ugly Ux but it's a one time thing just for installation, so...not the best first experience for users doing an installation, but blocking? Eek. Maybe? If there's a documented work around that's straight forward I'm very weakly inclined to say -1 blocker.
it's not actually clear that this is an anaconda bug at all, since it doesn't happen on other desktops. we haven't determined that yet.
Reproduced this bug on F24_nightly_20160531n0 with Arabic language install.
According to the F24 Final Blocker Criteria , this bug does not appear to break the criteria, as the criteria all appear to have to do with keyboard layouts post install. Because of this, I vote -1 blocker. See  for the keyboard layout configuration blocker information.
I'm -1 blocker this doesn't seem to violate any criterion.
This bug was discussed at the 2016-06-06 blocker review meeting  and determined to be a RejectedBlocker and an AcceptedFreezeException due to the fact that, while this is an unfortunate bug, it does not violate any of the release blocking criteria found here . The bug here is limited to switched keyboard layouts on the Workstation Live image, and does not inhibit installation of F24 onto the host system.
For the record this also happens on current Rawhide. I'm gonna try and figure it out today.
OK, interestingly: in Rawhide testing if I hammer the 'q' key while clicking the indicator to switch between 'us' and 'fr', I get an 'a' very occasionally. This means that the layout *is* being changed very briefly then almost instantaneously being changed back. So the question is not "why does the layout not change?" but "what decides to change it back right away?" (and presumably, since this doesn't appear to happen on any other desktop, it's something in GNOME).
Created attachment 1166729 [details]
So I have a somewhat small reproducer for this now, kinda distilled from the relevant anaconda code. Here it is.
It initializes things much as anaconda does - all the way down to 'rec.activate(engine)' - with two layouts, 'us' and 'fr(oss)'. Then it tries to switch to the second (group 1) using the xkl 'lock_group' function - this is what anaconda does when you click the layout indicator:
If you run this script in an F24 or Rawhide Workstation live, nothing seems to 'happen' (you wind up with the us layout - after running the script, pressing 'q' will still give you a 'q'). But if you run it on a short delay then switch to another console and hold down the 'q' key while it runs, you'll get a bunch of q's, then a few a's, then a few q's - illustrating the same behaviour we see in anaconda (the layout is switched briefly to fr, then somehow gets bounced back to us).
If you run the same script on a Rawhide KDE live, after it completes, the layout is set to fr - pressing 'q' gets you an 'a'.
If you run the same script on the F23 Workstation live, for some insane reason, Python segfaults. `display = GdkX11.x11_get_default_xdisplay()` seems to be the line that crashes it. I have no idea why (nor why this doesn't cause anaconda to crash, since it does the same thing).
I can't get much of a delta on this, unfortunately. It's been broken at least since the 2015-12-04 Rawhide nightly (which was after F23 branched, before F24 branched). The last nightly I have before that was the 2015-09-03 nightly, which segfaults like F23. So all we know for now is it broke somewhere between F23 and 2015-09-03...
sorry, I mean somewhere between F23 and 2015-12-04.
welp I'm really not getting very far with figuring out the cause of this, but as a final note for now, I've very definitely isolated it to GNOME. As well as KDE I tested today's F24 nightlies for Xfce, Cinnamon and MATE. The bug does not manifest (either in anaconda, or using the reproducer script) in any of those: switching layouts in anaconda works fine, and the layout is french after running the reproducer script.
So I think it's reasonable to kick this over to gnome-shell for now, given that anaconda's setting the layout the same way it has done for years, and it works fine in every other desktop, and there's nothing obviously wrong with what it's doing (though libxklavier is quite poorly documented so it's hard to be sure).
rtcm did ask me if 'setxkbmap' works, and it does (if you run 'setxbmap fr' from the Workstation live session, it sets the 'fr' layout and it doesn't get changed back), but what setxkbmap does is kind of different from what anaconda's doing. 'setxkbmap fr' says 'configure xkb such that fr is the only configured layout'. anaconda doesn't want to do that, it just wants to select one of the two configured layouts. It's easy to see the difference with 'setxkbmap -query'.
If you configure us and fr layouts in anaconda and then switch between them (in a desktop where that works OK), then run 'setxkbmap -query', the 'layout' line will say 'us,fr' no matter which is currently set active. If you run 'setxkbmap fr' then run 'setxkbmap -query' again, the 'layout' line will just say 'fr'. So I don't think the fact that setxkbmap 'works' lets GNOME put the blame back on anaconda, because what setxkbmap does is something different and not what anaconda actually wants/needs to do.
One more thing, I played around a bit with adding input sources in GNOME and comparing the behaviour of the anaconda and GNOME indicator/switchers.
In F23, if you add English and French layouts in 'input sources' so the GNOME indicator shows up, you can successfully change layouts with both GNOME and anaconda indicators. If you change with the GNOME indicator, the anaconda indicator notices the change and updates itself also; if you change with the anaconda indicator, the GNOME indicator does not notice the change and so shows the wrong layout. In F24, you can change only with the GNOME indicator, and the anaconda indicator notices the change and updates itself.
(For fun, you can confuse the GNOME indicator by using 'setxkbmap' to change the configuration; if you switch the order of the layouts around, the GNOME indicator gets confused (so if you tell it to switch to en it actually switches to fr, but it displays 'en', and vice versa). The anaconda indicator is not fooled in this way and continues to both display the correct layout and switch correctly. If you use 'setxkbmap' to load a completely different pair of layouts, say 'cz,de', anaconda's indicator again keeps up with the change and works fine; GNOME's continues to believe it's dealing with en and fr. Basically, anaconda seems a lot better at staying coupled to the actual X configuration than GNOME is).
The problem is a patch that we added to mutter to work around an issue with ubuntu's patched X server *sigh*
I still stand by my words on that bug:
"Third-party keyboard switchers are not supported in GNOME. Plenty of other XKB knobs/behaviors were already impossible or at least impractical when set from outside mutter's control. That's a conscious design decision that's not going to change unless there's a very good case for it."
but I'm leaning more towards reverting that patch upstream and let ubuntu carry it on their mutter package.
 that's what I get for trying to help everyone
Thanks for digging into that. Would it be possible to do a mutter package build with the patch reverted? For the longer term I can look at trying to teach anaconda how to configure the GNOME 'input methods' stuff properly, but I don't think it's reasonable to do that for F24, but we may still have time to fix it by reverting the mutter change if you think it's safe and reasonable.
Of course, while GNOME has decent reasons for doing its own thing in this regard, it *is* a pain for other components to deal with. Imagine if *every* desktop decided to just come up with its own design for configuring input...
mutter-3.20.2-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-743d2f9c4c
(In reply to Adam Williamson from comment #31)
> Of course, while GNOME has decent reasons for doing its own thing in this
> regard, it *is* a pain for other components to deal with. Imagine if *every*
> desktop decided to just come up with its own design for configuring input...
Guess what will happen when we switch to wayland by default. That's right, there's no systemwide settings configuration for this kind of thing so IMO anaconda should pick the environments where it wants to work on and integrate with them.
or there should be a sensible cross-desktop effort to co-ordinate a design, but we're kinda off-topic now. :P
mutter-3.20.2-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-743d2f9c4c
mutter-3.20.2-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
This looks a lot like it's back in F25; I suspect the reversion we did for F24 either never made it to F25, or got un-reverted later.
You can reproduce what looks like the same behaviour by booting an F25 Workstation live, switching to X11 (by setting a password for liveuser and logging out and back in again), running the installer, and picking Russian or some other multi-layout language, then trying to switch layouts. It doesn't work, neither by clicking the switcher nor with the key combo.
I'm proposing this as a blocker for F25 Final just for discussion, but I don't really think it makes the grade, since Wayland is the default now. But I believe at least some hardware is supposed to automatically fall back to X rather than Wayland, so we should probably discuss it.
Note switching is problematic on Wayland too (switching by clicking the switcher works, but not the key combo), but I'll file that separately. That bug will also be proposed as a blocker.
On second thought, we rejected this as a blocker for F24, so no point re-litigating as the criteria haven't changed. Changing to proposed FE.
mutter-3.22.1-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-081b0eb9f1
Discussed during the 2016-10-31 blocker review meeting: 
The decision to classify this bug as an AcceptedFreezeException was made as, while Wayland will supersede X in F25, there are still enough cases of X being used as the default window manager that a fix is worth implementing.
mutter-3.22.1-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-081b0eb9f1
mutter-3.22.1-6.fc25 fixes this
mutter-3.22.1-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.