NixOS 24.05 — Feature Freeze & Release Blockers

[wegank]

Hi, we are Weijia Wang & Jörg Thalheim, the release managers for NixOS 24.05 ("Uakari").

As we approach the next release of NixOS, it's time to discuss the upcoming feature freeze period. We want to ensure that this release is as stable and reliable as possible, and your contributions are crucial to achieving that goal, here are the two upcoming dates in that context:

• 2024-04-17: Restrict breaking changes to Release Critical Packages
• 2024-05-01: Restrict all breaking changes except for desktop environments.

The complete timeline is available here:

• NixOS 24.05 — Release Schedule #303285

The first restriction will be in place very soon, therefore, we encourage all teams to check in now and mention possible roadblocks, so we get a good overview of what's ahead.

Blockers

Whether you were pinged or not, we encourage everyone to create issues for release blockers and add them to the 24.05 Blockers project.

Check-in

Please comment your status quo and possible issues as soon as possible. We'll check teams once they have checked in.

If you think some subsystem, person or team should be added or removed from this list, update maintainers/team-list.nix in time before the next feature freeze announcement.

Desktop environments

• Cinnamon: @bobby285271 @mkg20001
• DDE: @wineee
• Enlightenment: @NixOS/enlightenment
• GNOME: @NixOS/gnome @bobby285271 @dasj19 @amaxine
• Lomiri: @OPNA2608
• Lumina: @NixOS/lumina
• LXQt: @NixOS/lxqt
• MATE: @bobby285271 @johannesloetzsch @romildo
• Pantheon: @NixOS/pantheon
• Qt / KDE: @NixOS/qt-kde @ilya-fedin @K900 @LunNova @mjm @NickCao @SuperSandro2000
• Xfce: @bobby285271 @romildo @muscaln

Platforms

• Darwin: @NixOS/darwin-maintainers

Languages ecosystem

• BEAM: @NixOS/beam @minijackson
• C: @matthewbauer @Mic92
• Coq: @CohenCyril @Zimmi48 @siraben @vbgl @Alizter
• Dhall: @Gabriella439 @ehmry
• Go: @NixOS/golang
• Haskell: @NixOS/haskell
• Lisp: @NixOS/lisp @hraban
• Lua: @NixOS/lua
• Node.js: @lilyinstarlight @marsam @winterqt
• OCaml: @NixOS/ocaml @Alizter @vbgl
• Perl: @stigtsp
• PHP: @NixOS/php
• Python: @FRidh @mweinelt @jonringer @tjni
• R: @bcdarwin @jbedo
• Ruby: @marsam
• Rust: @NixOS/rust
• Zig: @AndersonTorres @figsoda

Compilers, build systems

• Bazel: @mboes @marsam @uri-canva @avdv @olebedev @groodt @aherrmann @ylecornec
• LLVM: @dtzWill @Ericson2314 @lovek323 @alyssais @RossComputerGuy @rrbutani @sternenseemann

Programs

• Geospatial: @NixOS/geospatial @l0b0

Modules

• ACME: @aanderse @andrew-d @arianvp @emilazy @flokli @m1cr0man
• systemd: @NixOS/systemd

Core

• Docs:
• Marketing: @garbas @tomberek
• Module system: @infinisil @roberth
• Nix/nix-cli ecosystem: @NixOS/nix-team
• NixOS tests: @tfc

Everyone Else

@NixOS/nixpkgs-committers @NixOS/release-engineers

Finally

No issue is too big or too small, but let's remember that we are all working on the project voluntarily in our free time here, so let's focus on issues that can be realistically addressed in the remaining time before the release.

We thank everyone for their contribution!

[RossComputerGuy]

On my side, LLVM is good to go. I would like to get #299807 in but isn't a blocker. If it can get in before the release then that'll be cool.

[K900]

Plasma is as good as it's going to be probably, though #300933 would be nice to get in.

[tfc]

@wegank The only thing regarding NixOS tests that should ideally be sorted before the next release is the situation regarding #303187 and #303150.

Should be a minor thing but i consider it important.
Summary: NixOS integration tests work just fine on macOS, but currently they are marked as not supported by the platform list. Just need to resolve this.

update: this has been resolved via #303597

[ElvishJerricco]

I would be very disappointed if 24.05 didn't include systemd stage 1 by default, but I do have a lot of work left to make that happen. This issue looks worse than it is. Hopefully I can power this out in the next week or two. Any help would be appreciated.

[arianvp]

I would like to have https://nixos.github.io/amis either linked from the homepage or integrated into the homepage. So that people are aware again that there are AWS AMIs for 24.05!

Happy to coordinate with the marketing team on this

[imincik]

Geospatial software (@NixOS/geospatial) is in pretty good shape, no major changes are required, just regular maintenance.

[maralorn]

I think the Haskell packages are fine since we just updated to GHC 9.6. We will do another round of "remove all broken flags and see how many packages do actually build now" before release, but we have plenty of time for that.

[raboof]

For the Reproducible Builds initiative in NixOS, I think we are in good shape: for us the only blockers should be issues that prevent reproduction of the minimal iso. While https://github.com/orgs/NixOS/projects/30 does list some of those, the jfsutils nondeterminism seems sporadic and the others have known workarounds or a PR ready (#303436).

[garbas]

I would like to have https://nixos.github.io/amis either linked from the homepage or integrated into the homepage. So that people are aware again that there are AWS AMIs for 24.05!

Happy to coordinate with the marketing team on this

Awesome work. Let's get this work done ... are you able to do this work yourself, or you need some help from the marketing team?

The relevant code is here:

• https://github.com/NixOS/nixos-homepage/blob/main/src/components/pages/download/AWSTable.astro
• https://github.com/NixOS/nixos-homepage/blob/main/flake.nix#L63-L65

[hraban]

Lisp compilers are good to go 👍

[wineee]

No blockers for deepin

deepin will release v23 at the end of May, and I plan to port it on 24.11

[bobby285271]

No blockers for all GNOME-adjacent desktop environments I maintain so far, unfortunately I lost track of GNOME 46 update progress and I believe I really need to get around to test all the stuff there.

[SuperSandro2000]

We have a blocker for an unknown amount of wrapped python applications which unfortunately is a mass rebuild #302385

[OPNA2608]

Lomiri:

• Lomiri shell package, modules & tests: init #292872 will give us a basic usable DE ( 🥳 ) which I'm hoping to get finished up & merged in time. Further bits n pieces are fine in 24.11, with maybe some backports to fix missing extra functionalities.
• UBports plans to upgrade their base to yet-to-be-released Ubuntu 24.04 (~ end of April), not sure when exactly & how fast that'll happen. Might come with some new versions of Lomiri components to fix compatibilities. If it happens quick enough then I'll submit it to 24.05, otherwise off to 24.11 it goes.

Nothing else to report / no other blockers.

[jbedo]

R is good to go 👍

[matklad]

Vivaldi browser is currently broken with qt 6:

#286522 (comment)

I have a hacky PR which fixes this issue by allowing the user to explicitly opt-into plasma 6:

#292148

Would be good to fix this properly though, but I am unlikely to do that.

[happysalada]

Beam ecosystem (erlang , elixir...) Has no blockers .

[ulrikstrid]

Not sure if this should be considered a blocker but without #299589 #305920 composable_kernel in the ROCm packages is not cached by hydra and since it takes multiple hours to build even on a 64 core machine it's essentially unusable without the cache.

Cc @mschwaig

[mschwaig]

Not sure if this should be considered a blocker but without #299589 composable_kernel in the ROCm packages is not cached by hydra and since it takes multiple hours to build even on a 64 core machine it's essentially unusable without the cache.

Cc @mschwaig

Yes. Landing #299589 would be important, since I would consider ROCm 6.0 effectively broken without it. If we cannot backport this later I would consider it a blocker.

It would be nice it we could also get in get in #298388, to get ROCm working out of the box on more GPUs, since there are users on stable releases, who have opened issues related to that (#302412).

[iFreilicht]

I would argue that Zig is not ready for release right now. Most importantly, it doesn't build on darwin at all, see #299091, which breaks all packages that depend on it.

[thufschmitt]

Regarding Nix, we plan on releasing 2.22 next week, and we'd like to have that be the version included in NixOS 24.05

[RaitoBezarius]

Regarding Nix, we plan on releasing 2.22 next week, and we'd like to have that be the version included in NixOS 24.05

We can make it an nixUnstable version but I am not so sure a nixStable attribute can be made so fast and in time for this NixOS' release window, unfortunately.

[jonringer]

I agree with @RaitoBezarius , I think some time on nixpkgs unstable is warranted to ensure that there's no obvious regressions. (e.g. submodule flake usage broke in 2.20).

EDIT:
I'll defer the judgement call to @wegank. But the nix cli default is definitely something I would like to be more cautious about updating, as it directly relates to the usability of nix at large.

EDIT (@wegank):
NixOS 24.05 will ship Nix 2.18.

[lf-]

Regarding Nix, we plan on releasing 2.22 next week, and we'd like to have that be the version included in NixOS 24.05

I don't think this is a good idea personally, nix releases historically need time to bake, perhaps like a month of being the unstable to knock out the regressions not caught by people running the development branch (does anyone do that?), and it's too late in the release cycle to make that happen imo.

[RossComputerGuy]

I don't think this is a good idea personally, nix releases historically need time to bake, perhaps like a month of being the unstable to knock out the regressions not caught by people running the development branch (does anyone do that?), and it's too late in the release cycle to make that happen imo.

Agreed, I was thinking of updating the default LLVM version but it was decided to not do that until after 24.05 for a similar reason. We don't want sudden regressions before a release. Maybe after a release and it isn't backported then that would be fine.

[reckenrode]

I had a hope that I might be able to get cctools and ld64 updated for the release, but they’re going to have to wait because the refactoring I’m doing along with the update is too much change this close to the release. I was hoping #301354 could make it, but it’s probably going to have to wait.

Agreed, I was thinking of updating the default LLVM version but it was decided to not do that until after 24.05 for a similar reason. We don't want sudden regressions before a release. Maybe after a release and it isn't backported then that would be fine.

Darwin will be updating as well (since the plan after last year’s stdenv work was to do the update annually). If it helps make things easier, I can wait until after Linux is updated. I wouldn’t do the update on Darwin anyway until the 18.1.x update cycle ends to avoid requiring LLVM 18 updates go through staging.

[infinisil]

No blockers for the module system :)

Just a brief note regarding lib, I plan to write release notes for all changes to it, like I did last release

[SomeoneSerge]

No blockers for CUDA specifically, but there is a related PR open where a decision needs to be made about the recently introduced virtualisation.containers.cdi before the release: #290979 (CC @ereslibre).

EDIT: Cf. a tracking issue for all things CDI that are worth addressing before the release, #290609

[jonringer]

For python, we are doing a python-updates round, and that's the major changes I would like to see before going into ZHF.

cc @mweinelt for any additional python changes he would like to see as well.

[marsam]

• Ruby
  No blockers.
  I wanted make Ruby 3.2 the default, I think it's quite safe but I didn't have the time to fully test it.

• Node.js
  No blockers
  master now has Node.js v22.0.0, and I removed v21.7.3 since it was going to EOL during the 25.05 release

• Bazel
  No blockers

• PostgreSQL
  No blockers for PostgreSQL

---

This is my last involvement with NixOS, so I wish you a very successful 24.05 release.

[ShamrockLee]

Sylabs SingularityCE (singularity) on master fails to execute images.

The fix is now available as #306730, but that unfortunately includes behavioral changes and argument/configuration option deprecation. Is it possible to backport a fix like this one with deprecation warnings omitted?

Cc: @GaetanLepage @jbedo @SomeoneSerge

[Mic92]

• C
  No blocker as far as I know. Everything is up-to-date.
• Rust
  No blockers

[Mic92]

I would be very disappointed if 24.05 didn't include systemd stage 1 by default, but I do have a lot of work left to make that happen. This issue looks worse than it is. Hopefully I can power this out in the next week or two. Any help would be appreciated.

In srvos we still have a list of conditions when we need to disable systemd stage1: https://github.com/nix-community/srvos/blob/a1bbd4ab45c065bb2583f6344f9f72663c683fcb/nixos/common/default.nix#L20
I think those should be addressed before we can enable this. And than we should also have at least a decent amount of time to test this new implementation, which is currently only used by a subset of all NixOS users - Probably more time than compared to a systemd upgrade. It may also requires deprecation warnings for all options like boot.initrd.postDeviceCommands (if used by users)

[ryantm]

Can you remove me from the docs contact? I am no longer the best contact here.

[teto]

Lots of improvements on the lua side for this release. There is a big last one pending in staging then I'll need to fix 2/3 of 3 packages for ZHF.
I would like to bring neovim plugin transitive dependencies in the wrapper (e.g, you install rocks.nvim, it brings all its lua dependencies in scope, which doesnt work at the moment). I have it working locally and it shouldn't be breaking but I will have other people betatest.

[wegank]

NixOS 24.05 released! https://discourse.nixos.org/t/nixos-24-05-released/46279