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).
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
See https://bugzilla.redhat.com/show_bug.cgi?id=2121106 for the
background on this. One of Fedora's QA folks ran an install
and chose two keyboard layouts: Czech (qwerty) and US. Due to
the sad details of how the whole logic flow for trying to decide
what kbd layout best matches a given xkb config works (see
details in the bug comments), we wound up deciding the best-
matching kbd layout for this situation was cz-us-qwertz, which
is a czech/us switched layout, but is qwertz, not qwerty. This
seems like a poor outcome. Adding this line should result in us
picking cz-qwerty in this case. Which may be the 'legacy'
cz-qwerty.map from upstream kbd project (which is switched
cz/us), or may be the auto-converted xkb layout (which obviously
isn't switched). But either way, at least its primary mode is
Czech qwerty, which seems like a *better* choice than a layout
whose primary mode is Czech qwertz.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
All users were setting this to some static string (usually "-"), so let's
simplify things by not doing strdup, but instead limiting callers to a fixed
set of values. In preparation for the next commit, the function is renamed from
"empty" to "replacement", because it'll be used for more than empty fields. I
didn't do the whole string-table setup, because it's all used internally in one
file and this way we can immediately assert if an invalid value is passed in.
Some callers were (void)ing the error, others were ignoring it, and others
propagating. It's nicer to remove the boilerplate.
Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.