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.
For a long time now, the SDK and minimum target version for
`x86_64-darwin` has been stuck on macOS 10.12. In the past, the minimum
SDK was updated quite regularly; at first, the current situation was
just because updating the SDKs was excessively burdensome and nobody
was up for doing the work, but the introduction of `aarch64-darwin`
with its macOS 11 default SDK has resulted in a long‐term fracture
of the two platforms.
Per <https://endoflife.date/macos>, macOS 10.12 has not received
an update since 2017 and went out of security support 5 years
ago. Trying to support it in Nixpkgs has been a large burden on the
Darwin maintainers, resulting in workarounds, porting work, and even
patching functionality out of applications. The existence of Nix
users using a macOS version this old is, to my knowledge, entirely
theoretical, and we pay in both maintenance costs and functionality:
for instance, applications built for `x86_64-darwin` do not support
automatic dark mode switching by default.
This situation has always been suboptimal, but it is
now becoming untenable. Python, a critical component
of the Nixpkgs standard environment for builds, is
dropping support for versions older than 10.13 in 3.13:
<https://www.python.org/downloads/release/python-3130rc1/>. Qt 6 only
supports macOS 11 and newer. libuv only supports the versions Apple
does, and is a ticking time bomb due to its use in the standard
environment. QEMU only supports the last two macOS releases, and
won’t build with an SDK older than macOS 12; we previously vendored
a set of backporting changes and functionality‐removing reverts
to keep it building for 10.12, but this also became overly onerous,
and we gave up in <https://github.com/NixOS/nixpkgs/pull/338598>.
`x86_64-darwin` is a platform with a limited upstream future. Apple no
longer sells any hardware that runs it natively, and it is unclear how
much longer they will support it in the operating system. There are
still many users of the platform, myself included, so we shouldn’t
drop support for it prematurely, but it’s unreasonable to try and
patch the entire world to keep it supporting insecure versions of
the OS that only run on hardware that is no longer sold.
Therefore, this adds a release note to warn users ahead of time that
25.05 will only support macOS 11 and newer, as suggested by the 24.05
release team when the possibility of bumping the required version
was raised.
Why target Big Sur, rather than any other version? The
reason is simple: it’s the same SDK and deployment target as
`aarch64-darwin`. There are many packages that work on `aarch64-darwin`
but not `x86_64-darwin`, and Darwin maintainers frequently need to be
called in to fix things that work fine on the newer platform but not
the older one. This change will increase the health of `x86_64-darwin`
by aligning the SDK versions and support between the two platforms;
the vast majority of packages that work on one will Just Work on the
other. macOS 11 is almost four years old and has itself been out of
security support for a year now, but as the first version to support
Apple Silicon, it’s a far more compatible base for us to build our
Darwin packages for. Any future change in supported versions should
be synchronized between the two Darwin architectures.
When 25.05 is released, users on old, unsupported versions of macOS
will have the following options:
* Update to a new macOS version. For users that are on hardware
that Apple has dropped support for, OpenCore Legacy Patcher
(<https://dortania.github.io/OpenCore-Legacy-Patcher/>) can enable
the use of newer macOS versions on hardware even older than 10.12
supports.
* Install NixOS. That obviously precludes the use of macOS software
(though most of that software has already dropped support for 10.12),
but will give users a secure, supported operating system that we
can actually own the support for going forward.
* Keep using 24.11 forever. Since they’re not getting updates
to their OS and core applications anyway, this is likely to be
acceptable to many users.
* Switch to MacPorts. They support all the way back to 10.6 for
`x86_64-darwin` by building packages separately for every OS release,
though not every package is available for every version.
* Send patches. We *may* accept non‐invasive patches to keep
certain critical packages (such as the core `stdenv` packages)
building for old OS versions, on a case‐by‐case basis, but we
can’t guarantee it. This will ultimately have to be a decision
made by package maintainers and personally I doubt this will be a
viable path to sustainably support older versions.
- change tested app from gnome-calculator to gnome-pomodoro as plotinus
only works on gtk3 apps
- change screenshot result to one that shows popup from plotinus
instead of preferences window
- add 2 minute timeouts waiting for windows
- add 10 minute timeout for full test
When wireguard began being tested on multiple kernel versions, the
current default version at the time was hard coded:
41bd6d2614.
We should update this and prevent it from becoming stale ever again by
computing the default value.
The current kubernetes module only allows you to set a single DNS
resolver for the kubelet. Historically, this has not mattered as the
value was passed to a cli argument as a string and as per the kubelet's
configuration parsing mechanism, multiple values could be passed as a
comma-delimited string. However, recently, the module was refactored to
make configure kubernetes components via configuration files rather than
the deprecated command-line arguments. These files more strongly-typed
than CLI arguments and to pass multiple values, one must define a list
in the file. When this change was made, an incorrect assumption was made
that only a single DNS server could be specified and forced a
single-item list into this configuration file. We need to introduce a
breaking change to the module in order to allow the user to supply their
own list with however many dns resolvers they wish to use.
