Breaking changes announcement for unstable

Development
42

With its 2023.12.0 release the home-assistant package started to more widely depend on its matter integration in through various other components.

Unfortunately, the matter integration is currently only available as binary wheel, and since it is built in an Ubuntu 20.04 container it depends on the OpenSSL version available in that distro release, which is 1.1. We provide openssl_1_1 through autopatchElfHook here.

While nixpkgs still has openssl_1_1 available, we decided a long time ago to set meta.knownVulnerabilities due to its end of life in early September 2023.

The result is that home-assistant will now transitively be flagged insecure for relying on openssl_1_1. To continue using it, a snippet like the following is most likely required:

{
  nixpkgs.config.permittedInsecurePackages = [
    "openssl-1.1.1w"
  ];
}

To my knowledge, we still cache packages depending on openssl_1_1, so there will be no further impact for the time being, but time is surely running out.

In the meantime I’m trying to communicate this problem upstream.

15 Likes
43

With the upgrade of the Linux default version to 6.6 we’ve seen the nixosTests.nfs3.simple regressing.

https://hydra.nixos.org/build/251337679
https://hydra.nixos.org/build/251337696

It broke somewhere between v6.3.12..v6.4.0 and our kernel maintainers are trying to bisect it further, but it is a costly process, and it is not guaranteed, that it will yield results.

To unbreak the channel we therefore decided to remove nfs3 from the tested set, and replace it with the newer nfs4.

NFS4, depending how you count is between 9 years (RFC7530) and 21 years (https://www.usenix.org/system/files/login/articles/mcdonald_0.pdf) old, and should by now be the primary NFS version in use.

The impact of this change should therefore hopefully be minimal.

11 Likes
44

With the next nixos-unstable evaluation home-assistant will not require allowing openssl-1.1.1w in permittedInsecurePackages any longer. The matter integration that was previously using it was migrated to boringssl (thanks to Matt Leon), which will also benefit Home Assistant upstream, which is awesome!

Please make sure to remove the previously mentioned config snippet, so you’ll become aware again, when you use packages relying on openssl_1_1.

5 Likes
45

nixosTests.networking: refactor and add NetworkManager support by Janik-Haag · Pull Request #292472 · NixOS/nixpkgs · GitHub will break networking.networkmanager.extraConfig the fix should be quite easy and you basically just have to convert your ini string to the equivalent attrset. For example:

~  networking.networkmanager = {
-    extraConfig = ''
-      [main]
-      no-auto-default=*
-    ''
+    extraConfig.main.no-auto-default = "*";
~  };
4 Likes
46

cudaPackages.cudatoolkit has been renamed into cudaPackages.cudatoolkit-legacy-runfile: cudaPackages.cudatoolkit: rename, replace with a symlinkJoin · Issue #295655 · NixOS/nixpkgs · GitHub

A symlinkJoin wrapper is left at the old path for compatibility which includes most of the toolchain and common libraries, but not e.g. nsight-systems. Use the split packages instead: NixOS Search.

1 Like
47

Heads up on CDI: Add `mount-nvidia-binaries` and `mount-nvidia-docker-1-directories` options by ereslibre · Pull Request #290979 · NixOS/nixpkgs · GitHub. This PR removes two recently introduced (in unstable too) NixOS options:

  • virtualisation.containers.cdi.static.enable, and
  • virtualisation.containers.cdi.dynamic.enable

At this time, the dynamic configuration is only implemented for Nvidia (it contains a CDI generator.) It has replaced the virtualisation.containers.cdi.dynamic.enable option with hardware.nvidia-container-toolkit.enable.

It has further features that are not implemented in current unstable, like the ability to add user defined mounts to containers, or the ability to choose whether the user wants to mount nvidia-docker-1 directories or the Nvidia executables inside containers.

There is still work in progress that will continue after the 24.05 cut, recorded at [Tracking issue] CDI Support · Issue #290609 · NixOS/nixpkgs · GitHub by @SergeK.

1 Like
48

appimageTools.wrapAppImage: remove version from `pname` by pbsds · Pull Request #271071 · NixOS/nixpkgs · GitHub implements proper pname+version support for appimageTools.wrapAppImage. If you previously relied on AppImages being linked to $out/bin/${pname}-${version} and/or had a workaround in place to link it to just pname, this change will be breaking.

An attempt was made to cover all appimageTools.wrapAppImage usages in Nixpkgs but at over 100 packages, it’s likely some were missed or done improperly. If an AppImage breaks the coming week, this may be the culprit, so please point people to the PR.

6 Likes
49

We decided to revert the change to dbus-broker by default due to reported issues.

However due to switch-to-configuration not handling aliases and the rule that “Dbus may not be restarted or stopped under any circumstances” it might happen that when you switch to configuration that dbus-broker.service gets stopped. Which breaks many things. Unfortunately this also breaks the reboot command and this means you might need a hard-reset to get your machine working again. The safest option is to do a nixos-rebuild boot and boot into the new configuration.

We’ve been trying to make it safer to switch between dbus implementations by delaying the restart til next boot. However this won’t help you not hit this bug that the revert caused

I’m still trying to come up with a fix that doesn’t cause nixos-rebuild switch to break but I am not sure how we can fix this properly.

If people have ideas I’m happy to hear them.

I hope at least with this post I’m saving people from some nasty surprises

Edit:

You can do sudo reboot -ff to bypas logind and dbus

9 Likes
50

Starting with the next nixos-unstable evaluation, chromium will no longer be able to automatically download and load its proprietary Widevine DRM component when it encounters DRM protected content.

Those that want to continue playing DRM protected content in chromium need to explicitly opt into our Widevine (-wv) wrapper using

environment.systemPackages = with pkgs; [
    (chromium.override { enableWideVine = true; })
];

now.

enableWideVine has been part of our chromium drv for almost 10 years.
Meaning there is a high chance those that need Widevine may already have that override in their config.

5 Likes
51

Let me remind this thread that “breaking changes” are generally not allowed currently. For details see NixOS 24.05 — Release Schedule · Issue #303285 · NixOS/nixpkgs · GitHub

3 Likes
52

Not my change, but I noticed that nodePackages.pyright has simply become pyright now (and nodePackages.pyright fails to build now).

1 Like
53

The latest python-updates cycle migrated the primary Python version to 3.12. This release has been particularly breaking with the removal of commonly used modules of the past like distutils or imp.

If your package is affected by this, make sure to bug your upstream about it, maybe they already noticed and you can fetch a patch.

In the meantime you can resolve breakages by pinning packages ot python311 for the 24.11 release cycle.

9 Likes
54

I think we might merge cudaPackages: make getOutput work again by SomeoneSerge · Pull Request #323056 · NixOS/nixpkgs · GitHub this week. This removes an old and abominable hack related to our symlink abuse, but temporarily this also adds another ugly feature: for most packages p in cudaPackages, p.out is now going to be nearly empty. This will, for instance, break expressions such as ${cuda_nvcc}/bin/nvcc.

Migration strategy:

  • First and foremost, try not to mention outputs at all, but rely on mkDerivation selecting the dev outputs, and the dev outputs propagating everything else.
    • For instance, do not start with a symlinkJoin, but try enumerating cuda dependencies in buildInputs (except cuda_nvcc, which goes in nativeBuildInputs). By not using symlinkJoin you’ll let Nix discard references to most of the inputs after the build. The output closure will be much smaller than the input closure.
    • Do not write things like bulidInputs = [ cuda_cudart.dev cuda_cudart.lib cuda_cudart.static ]. Simply write buildInputs = [ cuda_cudart ]; the other outputs are propagated automatically.
  • Do not expect that any particular output names are present in cudaPackages, instead rely on getDev (e.g. -I${lib.getDev cuda_cudart}/include will keep working), getLib (e.g. -L${getLib libcublas}/lib), getOutput "static", getOutput "stubs", getBin and getExe (e.g. ${getBin cuda_nvcc}/bin/nvcc, getExe cuda_nvcc, getExe' cuda_nvcc "nvcc").
5 Likes
55

sound.enable has been removed in nixos/alsa: kill sound.enable and friends with fire by K900 · Pull Request #326262 · NixOS/nixpkgs · GitHub

The manual/PR contains instructions for how to update: nixpkgs/nixos/doc/manual/release-notes/rl-2411.section.md at 3eeff54780a1a8c73c82ca51987962b62bd4219e · K900/nixpkgs · GitHub

9 Likes
56

The lib and out outputs of lldb have been combined on Darwin. Packages should use lib.getLib to access the lib output of lldb.

(This change may be reverted if an alternate workaround for the issue can be found.)

2 Likes
57

cctools and ld64 have been upgraded on Darwin. These changes are part of the current staging-next cycle and should land in master assuming no issues are found.

nixpkgs breaking changes:

  • ld64 has been split out of cctools into its own package. If you need ld64 specifically, you should depend on the ld64 package;
  • cctools and ld64 have been moved to the by-name hierarchy. The old darwin.cctools names have been added to darwin-aliases.nix and can’t be used in nixpkgs;
  • GNU as is now in a separate output (cctools^gas);
  • postLinkSignHook has been removed. ld64 now handles code-signing itself. Binaries that are signed by ld64 with an ad hoc signature will have a “linker-signed” flag set; and
  • strip and install_name_tool understand the “linker-signed” flag, so they are no longer wrapped because the automatically update ad hoc signatures. Other signatures (e.g., manual codesign, certificates) will have to be regenerated manually after the binary is modified.

Upstream breaking changes:

  • ld64 no longer accepts nested archives. If a package tries to include an archive inside another archive, linking will fail. This can be fixed by linking the static libraries separately instead of embedding one inside the other;
  • ld64 is stricter about which command-line arguments it accepts. For example, passing -rpath when merging a Mach-O object file now results in an error. The fix is not to do that;
  • ld64 has limitations on size when using special response files (e.g., passing them via process substitution in Bash). These are worked around in ld-wrapper by using a temporary file; and
  • The implementation is now based on Apple’s upstream instead of cctools-port. libtapi should build and work on Linux, but more work is required to finish porting cctools and ld64.
5 Likes
58

As of ffmpeg: ffmpeg_6 -> ffmpeg_7 by emilazy · Pull Request #337855 · NixOS/nixpkgs · GitHub, ffmpeg’s major version will be moved from 6 to 7. This change will be included in the next staging-next cycle.

If you encounter build failures related to libav* or notice issues relating to media codecs in your applications, please create issues and ping @Atemu @emily and @jopejoe1.

4 Likes
59

The method to safely handle secrets in the networking.wireless module has been changed (PR #180872) to benefit from a new feature of wpa_supplicant. The syntax to refer to secrets has changed slightly and the option environmentFile has been replaced by secretsFile.

Only if you have been using networking.wireless.environmentFile a small migration is necessary: the instructions will show up in the nixos-rebuild output.

If you have any problems create an issue and ping @rnhmjoj.

2 Likes
60

The dnscrypt-wrapper package was removed since the project has been effectively unmaintained since 2018; moreover the NixOS module had to rely on an abandoned version of dnscrypt-proxy v1 for the rotation of keys.

If you want to wrap a resolver with DNSCrypt you can instead use dnsdist, which has supported this for a while. See options services.dnsdist.dnscrypt.*

For more information see PR # 341838.

5 Likes
61

The logrotate systemd unit has received some thorough hardening, that in theory shouldn’t bite you. I know few people are probably using the module directly, but rather through other modules that set it up. But unless they’re doing anything weird, like access the network, which now requires allowNetworking to be set, they’ll probably be fine.

2 Likes