With mautrix-signal v0.7.0 the bridge is built upon the bridgev2
architecture. With this, the configuration file was slightly rearranged.
Options like login_shared_secret_map and double_puppet_server_map were
dropped.
Because `virtualisation.diskSize = null` does result in a broken vm runner,
see https://github.com/NixOS/nixpkgs/issues/292901.
diskSize was declared to be nullable when it first got types in a
tree-wide commit:
30f0faac22
But it seemingly never actually supported it, as "${cfg.diskSize}M" is
passed to qemu-img create, which doesn't allow an empty size parameter.
closes: https://github.com/NixOS/nixpkgs/issues/292901
2.3.0 is the final release, the repo is now archived.
Also I don't use it anymore for quite a while, so it didn't have a real
nixpkgs maintainer either.
Closes#338712
A sed with nested double quotes is inserting malformed XML into /etc/fonts/fonts.conf, this commit put the sed command into single quotes to properly insert double quotes to enclose the XML attribute.
When using `lib.optionals`, the return value of both branches of the
condition get set as a value to the option.
When using `lib.mkIf`, only the positive condition gets set as a value
to the option.
This small distinction is important when dealing with precedence. For
example here, we wanted to set a boot.grub.devices default value with
lib.mkDefault, and that was getting overridden with the empty value of
`lib.optional (cfg.device != "") cfg.device`.
See https://github.com/nix-community/srvos/pull/491#discussion_r1738827651
The general conclusion is that using `lib.mkIf` is preferable to
`lib.optional` or `lib.optionals` when setting values in the NixOS
module system.
This is the error message on fail:
> qemu-system-aarch64: -device canokey,file=/tmp/canokey-file: Warning:
> speed mismatch trying to attach usb device "CanoKey QEMU" (full
> speed) to bus "usb0.0", port "3" (high speed)
My Understanding of the Issue is: The test failed because
qemu-system-aarch64 apparently has different USB controllers enabled by
default, resulting in a "speed mismatch" between the USB controller and
CanoKey that only occurred on aarch64.
I could reproduce the issue on x86_64 by enabling the EHCI controller
and then fix the issue by specifying which USB bus to use for the
CanoKey.
This didn't fully fix the issue on my first attempt, because the UCHI
controller enabled by -usb doesn't have the same bus name on aarch64
and x86_64.
While bus=usb-bus.0 worked on x86_64, on aarch64 i get this message:
> qemu-system-aarch64: -device canokey,bus=usb-bus.0,file=
> /tmp/canokey-file: Bus 'usb-bus.0' not found
The final solution now manually enables the OHCI controller (which may
be similar to UHCI, but i really have no idea other than it works) and
assigns it the id aka bus name "usb-bus", so it works the same under
both architectures.
