Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NixOS 24.05 — Feature Freeze & Release Blockers #303286

Closed
39 tasks done
wegank opened this issue Apr 11, 2024 · 37 comments
Closed
39 tasks done

NixOS 24.05 — Feature Freeze & Release Blockers #303286

wegank opened this issue Apr 11, 2024 · 37 comments
Labels
5. scope: tracking Long-lived issue tracking long-term fixes or multiple sub-problems

Comments

@wegank
Copy link
Member

wegank commented Apr 11, 2024

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:

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

Platforms

  • Darwin: @NixOS/darwin-maintainers

Languages ecosystem

Compilers, build systems

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!

@wegank

This comment was marked as duplicate.

@RossComputerGuy
Copy link
Member

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
Copy link
Contributor

K900 commented Apr 11, 2024

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

@tfc
Copy link
Contributor

tfc commented Apr 11, 2024

@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
Copy link
Contributor

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
Copy link
Member

arianvp commented Apr 11, 2024

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
Copy link
Contributor

imincik commented Apr 11, 2024

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

@maralorn
Copy link
Member

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
Copy link
Member

raboof commented Apr 11, 2024

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
Copy link
Member

garbas commented Apr 11, 2024

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:

@hraban
Copy link
Member

hraban commented Apr 11, 2024

Lisp compilers are good to go 👍

@wineee
Copy link
Member

wineee commented Apr 11, 2024

No blockers for deepin

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

@bobby285271
Copy link
Member

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
Copy link
Member

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

@wegank wegank pinned this issue Apr 11, 2024
@OPNA2608
Copy link
Contributor

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
Copy link
Contributor

jbedo commented Apr 11, 2024

R is good to go 👍

@matklad
Copy link
Member

matklad commented Apr 12, 2024

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
Copy link
Contributor

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

@ulrikstrid
Copy link
Member

ulrikstrid commented Apr 14, 2024

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

jonringer commented Apr 15, 2024

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-
Copy link
Member

lf- commented Apr 15, 2024

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

SomeoneSerge commented Apr 18, 2024

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
Copy link
Contributor

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.

@samueldr samueldr added the 5. scope: tracking Long-lived issue tracking long-term fixes or multiple sub-problems label Apr 23, 2024
@marsam
Copy link
Contributor

marsam commented Apr 25, 2024

  • 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
Copy link
Contributor

ShamrockLee commented Apr 25, 2024

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
Copy link
Member

Mic92 commented Apr 25, 2024

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

@Mic92
Copy link
Member

Mic92 commented Apr 26, 2024

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
Copy link
Member

ryantm commented Apr 27, 2024

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

@teto
Copy link
Member

teto commented May 2, 2024

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
Copy link
Member Author

wegank commented May 31, 2024

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

@wegank wegank closed this as completed May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
5. scope: tracking Long-lived issue tracking long-term fixes or multiple sub-problems
Projects
None yet
Development

No branches or pull requests