Bug 2231085

I think this is expected. The setting is set to its default value, an empty array. @a(ss) is the type of the value (array of tuples, each tuple containing two strings) and [] indicates the value is an empty array. When the setting is empty, anaconda can simply skip copying the input sources configuration, and then the installed system with no configuration would wind up with English (US).

--------------

BTW, there are two relevant settings in org.gnome.desktop.input-sources:

 * sources: this is the authoritative source for which input sources are configured. It may be empty.
 * mru-sources: this one is for tracking which sources are most recently used. It may be empty.

I think you should probably use 'sources' instead of 'mru-sources', so that the the list on the installed system is in the same order as the list on the live system?

Hi based on my testing that is not possible.

I need information about currently used source to properly set virtual console keymap, which is used for LUKS unlocking during boot. So, defaulting to English might result in not being able to unlock your system on the first boot after the installation. I can't use `sources` for that because it doesn't give me information about the currently used.

Example of wrong input:
1. After boot go to settings (default is EN)
2. Add at least one more layout (let's use CZ in this example)
3. Change the newly added layout to the top of the list (so the new order is [("xkb", "cz"), ("xkb", "en")] )


The ordering change would result in this output:
'sources' output: "cz", "en"
'mru' output    : "@a(ss) []"
current layout  : "en"


In other words, the list of sources is reordered based on the user preference but the current layout is still "en", however, the first in the list is "cz". In this situation Anaconda don't know, what is layout used during the installation to set passwords.

We can quess that it's always English, however, if you remove English layout from the list and keep others, we are still getting empty value for 'mru'. In this case, it's completely wrong configuration because the layout is not even available to user during installation.

I'm going to investigate this more closely before replying again. :)

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

(In reply to Jiri Konecny from comment #2)
> Hi based on my testing that is not possible.
> 
> I need information about currently used source to properly set virtual
> console keymap, which is used for LUKS unlocking during boot. So, defaulting
> to English might result in not being able to unlock your system on the first
> boot after the installation. I can't use `sources` for that because it
> doesn't give me information about the currently used.
> 
> Example of wrong input:
> 1. After boot go to settings (default is EN)
> 2. Add at least one more layout (let's use CZ in this example)
> 3. Change the newly added layout to the top of the list (so the new order is
> [("xkb", "cz"), ("xkb", "en")] )
> 
> 
> The ordering change would result in this output:
> 'sources' output: "cz", "en"
> 'mru' output    : "@a(ss) []"
> current layout  : "en"
> 
> 
> In other words, the list of sources is reordered based on the user
> preference but the current layout is still "en", however, the first in the
> list is "cz". In this situation Anaconda don't know, what is layout used
> during the installation to set passwords.

So in org.gnome.desktop.input-sources, the 'current' setting is deprecated and ignored. So don't look at that at all.

Use the 'mru-sources' setting to determine the current input source (and decide how to configure the vconsole keymap). The first source listed there is the one that is currently selected. If this setting is empty, then the user has never switched from the first input source to any other input source, so in that case the current source would be the first source from 'sources' instead. And if 'sources' is also empty, then it's English (US).

Use 'sources' to decide what locale to install into localed. Since localed only supports configuring a single locale, I suppose you can just take the first one from the list, and the user will have to manually add back any other configured input sources after installation. (Ray, do you agree?)

> Use 'sources' to decide what locale to install into localed. Since localed only supports configuring a single locale, I suppose you can just take the first one from the list, and the user will have to manually add back any other configured input sources after installation. (Ray, do you agree?)

I meant: "use 'sources' to decide what X11 Layout and X11 Variant to install into localed"

(The VC Keymap would have to come from mru-sources because otherwise the user would be unable to enter the LUKS passphrase prompt.)

As described at comment 2, your suggestion will not work.

The issue is that in Gnome Settings you can change ordering of the keyboard layouts. Which breaks your suggested logic.

Example:
layouts: [cz, us, es]
current: cz

however if I change the order:
layouts: [us, es, cz]
current: cz

Without switching the layout which will set mru-sources we don't have a clue what is the current layout after re-ordering because we don't know what was the order before reordering.

OK, I see the problem.

For now, please assume the logic I suggested works (even though it doesn't). We'll need to update mru-sources when the input sources are reordered, not only when they are changed.