The Xbox Wireless Headset does not get assigned a sound form factor
when connected via the dongle using the `xone` driver.
Add USB IDs for the old & new dongle and built-in variants.
Since we use varargs for sd_message_append() we need to make sure the
parameters we pass are actually 64bit wide, if "t" is used. Hence cast
appropriately if necessary.
I went through the whole tree, and in most cases we got it right, but
there are some cases we missed so far.
Inspired by: #31420
This renames a few of the switches vmspawn takes, such as --qemu-mem=
and --qemu-smp= to names without the "qemu" moniker and uses less
cryptic names (i.e. --ram= and --cpus=).
I think it's a bit unsystematic that so far we use the "qemu" prefix for
some options but not for others. At least I could not figure out a
system when we use it and when we don't. Hence let's clean it up and
just use simpler names without suffix.
After all we might want to plug other hypervisors behind vmspawn one
day, hence I think there's value in sticking to generic names for these
switches that allow us to switch out backends easily. In particular for
--ram= and --cpus= which are probably the most fundamental of VM settings
there are.
The old switches are support for compat, but not advertised in man page
or --help text anymore.
I left "--qemu-gui" under its current name, since it fundamentally is a
a qemu concept, exposing a qemu specific graphical UI.
The 1-based VT indexes are what people usually expect, since the primary
name of VTs uses them (i.e. /dev/tty1, /dev/tty2, …). Hence, let's
always use 1-based VT indexes, and early on convert 0-based VT indexes
to minimize confusion.
If specified we'll not try to find a free V, but instead just output
directly to the specified TTY. This is particularly useful for
debugging, as it means "systemd-bsod --tty=/dev/tty" just works.
Apparently on HyperV the measurement logs announce the hash algs in a
different order in the header than the records have them. Let's handle
this gracefully
Let's split off a new vcs-tag option from version-tag that configures whether
the current commit should be appended to the version tag. Doing this saves
us from having to fiddle around with generating git versions in packaging
specs and instead let's meson do it for us, even if we pass in a custom
version tag.
With this approach there's no more need for tools/meson-vcs-tag.sh so
we remove it.
Otherwise weird stuff happens on the other side:
[1217111.957263] testsuite-46.sh[61]: + homectl create test-user --disk-size=min --luks-discard=yes --image-path=/home/test-user.home --luks-pbkdf-type=pbkdf2 --luks-pbkdf-time-cost=1ms
[1217112.598219] homectl[66]: Operation on home test-user failed: Provided flags are unsupported (0ad2578000000000).
(taken from TEST-46-HOME run on armv7l)
Fixes issue mentioned in https://github.com/systemd/systemd/pull/31419#issuecomment-1955117397.
We have a number of components these days that are split into multiple
binaries, i.e. a primary one, and a worker callout usually. These
binaries are closely related, they typically speak a protocol that is
internal, and not safe to mix and match. Examples for this:
- homed and its worker binary homework
- userdbd and its worker binary userwork
- import and the various pull/import/export handlers
- sysupdate the same
- the service manager and the executor binary
Running any of these daemons directly from the meson build tree is
messy, since the implementations will typically invoke the installed
callout binaries, not the ones from the build tree. This is very
annoying, and not obvious at first.
Now, we could always invoke relevant binaries from $(dirname
/proc/self/exe) first, before using the OS installed ones. But that's
typically not what is desired, because this means in the installed case
(i.e. the usual one) we'll look for these callout binaries at a place
they typically will not be found (because these callouts generally are
located in libexecdir, not bindir when installed).
Hence, let's try to do things a bit smarter, and follow what build
systems such as meson have already been doing to make sure dynamic
library discovery works correctly when binaries are run from a build
directory: let's start looking at rpath/runpath in the main binary that
is executed: if there's an rpath/runpath set, then we'll look for the
callout binaries next to the main binary, otherwise we won't. This
should generally be the right thing to do as meson strips the rpath
during installation, and thus we'll look for the callouts in the build
dir if in build dir mode, and in the OS otherwise.
Yu Watanabe
Mike Yuan
medusalix
Lennart Poettering
Frantisek Sumsal
Susant Sahani
Luca Boccassi
Daan De Meyer
hulkoba
Martin Ivicic
Antonio Alvarez Feijoo
Sam Leonard