* 0b390d2683 One more fixup for d/copyright
* 91d3dadcb5 Update changelog for 261.1-1 release
* 3c287e1f86 d/copyright: update to add new licenses
* a82117f9a3 Install new files for upstream build
* 020caeb149 Override new Lintian false positive
* d55b67b66e d/control: demote libnss-{myhostname,resolve} to Suggests for systemd-resolved
* 1c537705ec Update changelog for 261-2 release
* 6235897bbc Note new package split in NEWS
* a440cb2c4a Install new files for upstream build
* 7eaa21ad05 Split tpm tools into new systemd-tpm package
* 52b28b74f3 Split metrics reporting tools into new systemd-report package
* de2f367f22 Split imds tools into new systemd-imds package
* 2d0a07f5ae d/t/control: do not install xserver-xorg-video-dummy on loong64
* c886c3efc8 Install new files for upstream build
* 0efa66b4af Update changelog for 261-1 release
* e36cf82a1d lintian-overrides: override error about derivative.ubuntu build profile
* fbd38c36ea d/control: do not build systemd-boot-efi-*-signed-template on ubuntu
Observerd on Ubuntu 24.04 with GCC 13 on arm64 architecture.
```
../src/shared/journal-importer.c: In function ‘journal_importer_process_data’:
../src/shared/journal-importer.c:344:30: error: ‘line’ may be used uninitialized [-Werror=maybe-uninitialized]
344 | if (!journal_field_valid(line, n - 1, true)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/journal-importer.c:295:23: note: ‘line’ was declared here
295 | char *line, *sep;
| ^~~~
cc1: all warnings being treated as errors
```
There are already varlink methods for `ResolveHostname`,
`ResolveAddress`, and `ResolveRecord`. Use those in `resolvectl` instead
of the dbus equivalents.
Follow-up to #42422:
- Rename process_image() to context_process_image(), since it now
operates on a Context object.
- Use IN_SET() in image_type_can_sysupdate() instead of a switch.
- Name the return parameters of context_list_components() ret_xyz, per
our coding style.
- Drop a redundant "else" after a return in vl_method_check_new().
This puts the scaffolding in place for a varlink interface, but so far
it only adds a `io.systemd.Sysupdate.CheckNew()` method. Varlinkifying
the other verbs on `systemd-sysupdate` will happen in follow-up PRs, but
I thought I’d try and land this one early to:
* Get review of the overall varlinkification scaffolding
* Lower the chance of big merge conflicts with others’ work by getting
the more invasive changes out of the way
* Get the scaffolding in place so others can start to build on it if
they wish (although I am currently working on porting the other existing
verbs)
It rearranges how the `Context` struct is allocated so that it’ll be
easier to add per-method/verb context structs which contain it in
future. It also changes all the `sysupdate.c` code to use arguments from
`Context` rather than `arg_*` globals, allowing them to be specified as
varlink parameters in future.
It also moves the existing `systemd-sysupdate.{timer,service}` units
(which periodically run `systemd-sysupdate update`) to
`systemd-sysupdate-update.{timer,service}` to clear space for a
`systemd-sysupdate@.service` and `systemd-sysupdate.socket` to act as a
varlink entry point.
/cc @AdrianVovk
postmarketOS image can be built with for example the following mkosi.local.conf:
```
[Distribution]
Distribution=postmarketos
[Output]
Format=disk
[Build]
UseSubvolumes=yes
[Runtime]
Firmware=uefi
```
This is preparation for using varlink methods more in resolvectl. In
particular, this is helpful for proving more accurate error messages,
and maintaining compatibility with existing error messages from the
DBus API.
Generalize json_dispatch_address from nss-resolve, and add support for
strings to be compatible with the existing json_dispatch_{in,in6}_addr
helpers. This will be used in a later commit.
There are several places where address family is dispatched from JSON,
so take json_dispatch_address_family from networkd and put it in
json-util.c.
Update the all instances in the tree to use this new function, adding
SD_JSON_RELAX to the dispatch flags if AF_UNSPEC should be allowed
in that case.
This is the first varlink method added to sysupdate. The D-Bus interface
(via sysupdated) will remain for now; the varlink interface will exist
in parallel.
This method can be called via:
```
varlinkctl call ./path/to/systemd-sysupdate \
io.systemd.SysUpdate.CheckNew \
'{"target":{"class":"host"}}'
SYSTEMD_SYSUPDATE_NO_VERIFY=1 \
varlinkctl call ./path/to/systemd-sysupdate \
io.systemd.SysUpdate.CheckNew \
'{"target":{"class":"component","name":"some-component"}}'
```
This includes some changes to run the integration tests again using the
varlink interface rather than running `systemd-sysupdate` directly, to
test the new interface.
This adds the scaffolding for being able to call sysupdate via varlink,
but it doesn’t yet define or implement any methods. Those will come in
following commits.
The existing `systemd-sysupdate.service` and `systemd-sysupdate.timer`
(which periodically ran `systemd-sysupdate update`) have been renamed
to `systemd-sysupdate-update.{service,timer}` to make way for a new
`systemd-sysupdate@.service` and `systemd-sysupdate.socket` file to
handle varlink activation.
Compatibility symlinks have been added for them.
If a varlink method takes a struct/object as a parameter, and it’s
marked as `SD_JSON_MANDATORY`, and it has an optional field inside it
which is *not* marked as `SD_JSON_MANDATORY`, we want to not require
that field to be set.
Previously, due to using the `merged_flags` from both the mandatory
struct and the optional field, `SD_JSON_MANDATORY` was effectively
always set on the optional field even if we didn’t want it. This
resulted in an error being emitted if the mandatory struct was provided
in a varlink call, but without the optional field.
Fix that by validating the field’s presence only against its own flags
and not also the flags of its parent.
Adds a unit test to prevent regressions.
This will be used in upcoming commits to varlinkify `systemd-sysupdate`;
it will need a way to identify targets over varlink, and the existing
way with a `Target` over D-Bus seems to work quite well.
`process_image()` has historically used `umount_and_freep` to clean up
the mounted directory locally, but callers to it have used
`umount_and_rmdir_and_freep`.
No directory is created after any of the error return paths in
`process_image()`, so it should probably be using
`umount_and_rmdir_and_freep` too.
This is another step towards varlinkifying the program, as it means the
various verb implementations are no longer relying on global state from
the command line.
As part of this, move init of the `Context` struct into a new
`context_from_cmdline()` function.
Additionally pass some context into config parsing `userdata` arguments,
as various config parsers were using `arg_root` via a sneaky `extern`.
This introduces no functional changes.
There’s no need for it to be heap allocated — there’s only ever one
instance of it, and it’s allocated for the lifetime of a `verb_*()`
function.
Simplify things a bit by making it stack allocated. This will also help
with upcoming commits where we introduce derived context structs to help
with varlinkifying sysupdate. By allowing `Context` to be stack
allocated we can include it in the derived context structs.
As part of this, rename `context_make_{offline,online}()` to
`context_load_{offline,online}()` for clarity (since they no longer init
the struct).
This introduces no functional changes.
`process_image()` is always called immediately before (almost) every
`context_make_online()` or `context_make_offline()`, and the structures
it allocates have the same lifetime as `Context`, so we might as well
factor them all together to reduce duplication.
This will also simplify the following commit, which changes heap
allocation of `Context`s, and simplify upcoming changes to factor out
`arg_*` handling.
The call in `verb_pending_or_reboot()` is safe because it already
validates that `arg_image` is `NULL`, hence `process_image()` will bail
out early.
This introduces no functional changes.
This makes it like all the other verbs and therefore easier to refactor.
At the same time, remove the separate `component` argument and instead
use the `component` set on the `Context`. This guards against bugs, as
various parts of the `Context` state depend on the component (for
example, `installdb_fd`) and overriding the component without also
overriding its dependent variables will lead to bugs.
Yu Watanabe
Luca Boccassi
Lennart Poettering
Nick Rosbrook
dirhamtriyadi
Philip Withnall