When doing a conversion and the specified 'xc->xvariant' has no match, select
the x11 layout entry with a matching layout and an empty xvariant if such entry
exists. It's still better than no conversion at all.
When doing x11->console conversions, find_converted_keymap() searches
automatically for a candidate in the converted keymap directory for a given x11
layout.
However doing console->x11 conversions, this automatic search is not done hence
simple conversion in this direction can't be achieved without populating
kbd-model-map with entries for converted keymaps.
For example, let's consider "at" layout which is not part of kbd-model-map. The
"at" x11 layout has a generated keymap
"/usr/share/kbd/keymaps/xkb/at.map.gz". If we configure "at" for the x11
layout, localed is able to automatically find the "at" converted vc layout and
the conversion just works :
$ localectl set-x11-keymap at
$ localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: at
X11 Layout: at
However in the opposite direction, ie when setting the vc keymap to "at", no
conversion is done and the x11 layout is not defined:
$ localectl set-keymap at
$ localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: at
X11 Layout: (unset)
This patch fixes this limitation as the implemenation is relatively simple and
it removes the need to populate kbd-model-map with (many) entries for converted
keymaps. However the patch doesn't remove the existing entries in kbd-model-map
which became unneeded after this change to be on the safe side.
Note: by default the automatically generated x11 keyboard configs use keyboard
model "microsoftpro" which should be equivalent to "pc105" model but with the
internet/media key mapping added.
After manually editing /etc/locale.gen, calling localectl set-locale
sometimes fails. When it fails, the systemd journal shows:
systemd-localed: free() / invalid pointer.
It turned out that it only fails if some of the uncommented lines in
/etc/locale.gen have leading spaces, as in:
* C.UTF-8 <= OK
* en_US.UTF-8 <= OK
* fr_FR.UTF-8 <= NOK
After parsing a line from /etc/locale.gen, we use strstrip() to obtain
the "trimmed" line (without leading or trailing spaces).
However, we store the result of strstrip() in the original pointer
containing the untrimmed line. This pointer is later passed to free
(this is done automatically using _cleanup_free_).
This is a problem because if any leading space is present, the pointer
will essentially be shifted from its original value. This will result in
an invalid free upon cleanup.
The same issue is present in the locale_gen_locale_supported function.
Fixed by storing the result of strstrip() in a different pointer.
This is a combination of fdopen() and fd_reopen(). i.e. it first reopens
the fd, and then converts that into a FILE*.
We do this at various places already manually. let's move this into a
helper call of its own.
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
Follow-up for 82c2095a5e.
> I feel like the logging here may be a bit confusing on the new path.
> Previously you did get a message that explained what was going on. Now you get
> an info message that the layout could not be compiled, and … that's all. I can
> imagine this being a confusing red herring if someone was trying to debug a
> problem and saw this message. Perhaps we should log something else instead/as
> well, on the case where libxkbcommon isn't present, to say that's what we're
> logging about and it just means we can't validate the configuration, not that
> it's definitely invalid?
When compliled without libxkbcommon, we do no verification and accept the
arguments as given. When compliled against with, if dlopen() works, we do the
verification. But if dlopen() fails, we would refuse the call and return
SD_BUS_ERROR_INVALID_ARGS. 5de344704d added things
this way when converting to dlopen(), but it seems not very useful: it can be
expected that when the library is supported but missing at runtime, we degrade
softly, and that the behaviour is something inbetween the cases of hard disable
at compilation time and full support. But right now we behave more strictly then
if disabled at compilation. Change the code to just warn if dlopen fails, but
accept the arguments.
(There are various minimization scenarios where forcing the installation of
libxkbcommon is not useful. E.g. a small installation where we want to set the
keymap via logind, but the configuration is managed by a configuration
management system and is known to be valid. Verification via libxkbcommon is
just overhead in this case.)
800f65f827 moved the check earlier, so now even
a noop case of setting the values that were already in place can fail.
C.f. https://bugzilla.redhat.com/show_bug.cgi?id=2175244.
Although this slightly more verbose it makes it much easier to reason
about. The code that produces the tests heavily benefits from this.
Test lists are also now sorted by test name.
Before this commit, if virtual console keymap is unchanged, localed just
returns without modifying anything. However, the X11 part may need updating.
So we should check for both and ensure they are unmodified.
Replaces #26190.
This also makes x11_convert_to_vconsole() changed in the same way.
Then, their callers update Context if necessary.
No functional change, just preparation for later commits.
Suggested at https://github.com/systemd/systemd/pull/25805#discussion_r1054871210
> we now write multiple files and we cannot possibly guarantee that
> either both updates worked or neither. unix fs apis simply have
> no concept that would allow us to implement that. hence I think
> we should update what we can, log about what we cannot, but return
> success as long as our in-memory state was updated.
Similary, this also renames context_free_x11() -> context_clear_x11(),
to make it clear that these functions do not free Context.
Also, this makes context_clear() support to be called more than once.
- add missing assertions,
- rename arguments for storing results,
- always initialize results on success,
- use _cleanup_ attribute at more places, etc.
These combine strndup() + strspn()/strcspn() into one.
There are a bunch of strndupa() calls that could use similar treatment
(or should be converted to strdup[c]spn(), but this commit doesn't
bother with that.
Since commit 1ad6e8b302, unsetting an environment
variable means restoring it to its default value.
However this doesn't work well when localed updates locale.conf. Indeed when a
variable is removed from that file, localed calls "UnsetAndSetEnvironment"
method which restores the default values of the unset variables obtained by
PID1 when it first read locale.conf. But since locale.conf has been updated,
these default values might be outdated and localed needs to instruct PID1 to
read locale.conf again.
Reloading PID1 configuration is quite an heavy operation for this purpose but
there's no other way unless we change again the meaning of "UnsetEnvironment"
or we introduce a new method that really unset an env variable.
That said given the fact that localed modifies locale.conf, it should have an
effect on PID1 default environment rather than on the environment explicitly
set by the user (m->client_manager).
