ffmpeg will be updated from version 5 to version 6 in the next staging cycle. We built almost all dependant packages but cannot test them all.
Should something multimedia-related break in the coming weeks, that might be why. Please create issues and ping us.
https://github.com/NixOS/nixpkgs/pull/261923
Drop of Linux 4.14 (including hardened and hardkernel) as per release wiki page Feature Freeze announcement and pre-release cleanup - NixOS Release Wiki
The default LLVM has been updated from 11 to 16 for the next staging cycle. Some packages may fail to build due to breaking changes in clang. An attempt has been made to catch those failures and preemptively patch the affected packages, but it’s not possible to do so for every single affected package. If a package does not build for you, please open an issue.
The Kea services for dhcp4, dhcp6, ctrl-agent and dhcp-ddns will each get their own RuntimeDirectory shortly, since restarting one unit would previously clean out the shared /run/kea runtime directory.
This is especially relevant for users of the Prometheus Kea Exporter, which relies on the unix socket to retrieve statistics from Kea.
Heads-up, we ran into an annoying issue with newer PostgreSQL and our ensure-logic (ensurePermissions).
TL;DR: services.postgresql.*.ensurePermissions is deprecated and forbidden inside nixpkgs from now on, slated for deletion just after branch-off.
We went back’n’forth with multiple options, as the secondary release manager of NixOS 23.11, I decided to move forward with a semi-breaking change (breaking change because I am deprecating something now and semi because the option is still available in the broken state it is): nixos/postgresql: deprecate ensurePermissions, fix ensureUsers for postgresql15 by Ma27 · Pull Request #266270 · NixOS/nixpkgs · GitHub
What does it mean to you?
ensureDBOwnership which will just ensure that the user will own the database.ensureDBOwnership and any extra fix up procedure will have to use either initialScript (if it’s once) or postStart / preStart measures you design yourself.ensurePermissions being used, check that you don’t own custom logic out of tree on it and migrate it accordingly, otherwise, you may be using such a module out of tree.Will we get ensurePermissions again?
Short-term: No.
Long-term: Anyone is free to work on rethinking the ensure logic design and build more engineering around them to make them usable and stable without potential for data loss, you can look into RFC: `ensure`-style options in NixOS modules · Issue #206467 · NixOS/nixpkgs · GitHub to see the context, and you can contact me if you want to be helped/guided/mentored/whatever to work on that, but please, do not blindly re-introduce ensurePermissions, those options create a high amount of churn for the long term maintainers, and it’s unacceptable to make long term maintainers pay the cost of “nice to have” without proper investment.
Can you provide documentation to migrate?
We will write more documentation:
In a few weeks we will restore the runtime dependency validation of python packages, that use the pypaInstallHook, which is used for the pyproject format.
It will complain about version constraint mismatches
Checking runtime dependencies for sphinx_prompt-1.6.0-py3-none-any.whl
- sphinx==7.0.0 not satisfied by version 7.2.6
- docutils==0.19 not satisfied by version 0.20.1
- pygments==2.15.1 not satisfied by version 2.16.1
as well as missing dependencies
Checking runtime dependencies for pysml-0.1.1-py3-none-any.whl
- aiohttp not installed
Both cases will be considered a hard failure, and indicate further work is needed to get a package to run correctly.
For too tight version constraints I recommend using pythonRelaxDepsHook, which lifts constraints from the built wheel for the package names given in the pythonRelaxDeps list.
The work is currently happening in the following PR, and unfortunately we’ve justed missed the latest staging cycle, so it will be in the next one after that.
Zammad will be updated to version 6.1.0, which now requires a Redis server configured to run Zammad and brings a renamed/replaced systemd service.
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.
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.
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.
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 = "*";
~ };
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.
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, andvirtualisation.containers.cdi.dynamic.enableAt 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.
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.
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
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.
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
Not my change, but I noticed that nodePackages.pyright has simply become pyright now (and nodePackages.pyright fails to build now).
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.
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:
mkDerivation selecting the dev outputs, and the dev outputs propagating everything else.
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.bulidInputs = [ cuda_cudart.dev cuda_cudart.lib cuda_cudart.static ]. Simply write buildInputs = [ cuda_cudart ]; the other outputs are propagated automatically.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").