-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Update to nixos-23.11 #9546
Update to nixos-23.11 #9546
Conversation
I think I would like to do #9535 first. Some of the more exotic things have regressions in 23.11 I need to fix also. |
This is failing because the |
It's used for LSP (if you run your It was marked broken in NixOS/nixpkgs#250435 (comment) because it fails to build on x86_64-darwin (it built fine on aarch64-darwin for me). |
I guess let's adjust that |
That was already started in NixOS/nixpkgs#279035 |
@thufschmitt can you have another go at this? bear is fixed now, and I now have a PR blocked on the C++ compiler being antique. |
The fix hasn't been backported to 23.11 (I've just opened NixOS/nixpkgs#291814 for that). |
8fa8b60
to
3626935
Compare
@Ericson2314 the evaluation failures on Darwin (https://github.com/NixOS/nix/actions/runs/8064971474/job/22029891317?pr=9546) are above my pay grade, do you think you can have a look? |
OK, so I managed to fix the evaluation errors on Darwin (by just disabling everything that failed). I'm quite bewildered by the evaluation performance between 23.05 and 23.11 though: evaluating the flake on 23.11 takes nearly 3x longer than on 23.05 (despite having removed some outputs) $ hyperfine --warmup 1 \
"nix flake show nix/nixos-23.11 --option eval-cache false --all-systems" \
"nix flake show nix --all-systems --option eval-cache false"
Benchmark 1: nix flake show nix/nixos-23.11 --option eval-cache false --all-systems
Time (mean ± σ): 27.201 s ± 0.065 s [User: 19.490 s, System: 2.875 s]
Range (min … max): 27.100 s … 27.310 s 10 runs
Benchmark 2: nix flake show nix --all-systems --option eval-cache false
Time (mean ± σ): 9.398 s ± 0.216 s [User: 7.261 s, System: 1.046 s]
Range (min … max): 9.054 s … 9.843 s 10 runs
Summary
nix flake show nix --all-systems --option eval-cache false ran
2.89 ± 0.07 times faster than nix flake show nix/nixos-23.11 --option eval-cache false --all-systems any one knows what that could be due to? |
@infinisil there's a failure in the fileset tests on darwin: https://github.com/NixOS/nix/actions/runs/8069576505/job/22044909419?pr=9546 does that match anything already known? |
Oof this is weird, it looks like a bash regex matching bug. The behavior of matching # default.nix
{ system ? builtins.currentSystem }:
let
pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/tarball/931ee755b560f905775a11b3a719a303c8f992e1") {
inherit system;
config = {};
overlays = [];
};
in
pkgs.runCommandNoCC "bash-regex-${system}" {} ''
r="^\s$"
if [[ " " =~ $r ]]; then
echo "\s working"
else
echo "\s NOT working"
fi > $out
''
(can't test on |
Turns out |
This was found when trying to run the fileset tests on Darwin (NixOS/nix#9546 (comment)), which mysteriously fail on Darwin: test case at lib/fileset/tests.sh:342 failed: toSource { root = "/nix/store/foobar"; fileset = ./.; } should have errored with this regex pattern: lib.fileset.toSource: `root` \(/nix/store/foobar\) is a string-like value, but it should be a path instead. \s*Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead. but this was the actual error: error: lib.fileset.toSource: `root` (/nix/store/foobar) is a string-like value, but it should be a path instead. Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead. After dissecting this, I find out that apparently \s works on Linux, but not on Darwin for some reason! From the bash source code, it looks like <regex.h> with `REG_EXTENDED` is used for all platforms the same, so there's nothing odd there. It's almost impossible to know where <regex.h> comes from, but it looks to be a POSIX thing. So after digging through the almost impossible to find POSIX specifications (https://pubs.opengroup.org/onlinepubs/007908799/xbd/re.html#tag_007_003_005), I can indeed confirm that there's no mention of \s or the like! _However_, there is a mention of `[[:blank:]]`, so we'll use that instead.
This was found when trying to run the fileset tests on Darwin (NixOS/nix#9546 (comment)), which mysteriously fail on Darwin: test case at lib/fileset/tests.sh:342 failed: toSource { root = "/nix/store/foobar"; fileset = ./.; } should have errored with this regex pattern: lib.fileset.toSource: `root` \(/nix/store/foobar\) is a string-like value, but it should be a path instead. \s*Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead. but this was the actual error: error: lib.fileset.toSource: `root` (/nix/store/foobar) is a string-like value, but it should be a path instead. Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead. After dissecting this, I find out that apparently \s works on Linux, but not on Darwin for some reason! From the bash source code, it looks like <regex.h> with `REG_EXTENDED` is used for all platforms the same, so there's nothing odd there. It's almost impossible to know where <regex.h> comes from, but it looks to be a POSIX thing. So after digging through the almost impossible to find POSIX specifications (https://pubs.opengroup.org/onlinepubs/007908799/xbd/re.html#tag_007_003_005), I can indeed confirm that there's no mention of \s or the like! _However_, there is a mention of `[[:blank:]]`, so we'll use that instead. (cherry picked from commit 3429594)
About time :) This required disabling `bear` on darwin as it's currently broken (fixed on master, but not yet on 23.11).
The required version check was a bit too lenient, and `nixpkgs#nixUnstable` was considered valid while it didn't have the fix.
Just `stdenv.isDarwin` isn't enough because it doesn't apply to the build platform, which mean that cross packages building from darwin to another platform will have `isDarwin` set to false. Replace it by `stdenv.buildPlatform.isDarwin`.
Don't evaluate, and probably not really useful (if at all)
Flake lock file updates: • Updated input 'nixpkgs': 'github:NixOS/nixpkgs/4dd376f7943c64b522224a548d9cab5627b4d9d6' (2024-02-26) → 'github:NixOS/nixpkgs/b550fe4b4776908ac2a861124307045f8e717c8e' (2024-02-28)
I hate this. We should have it, but for now we can't.
a37370c
to
8dc4b41
Compare
The required version check was a bit too lenient, and `nixpkgs#nixUnstable` was considered valid while it didn't have the fix.
Apparently gcc is able to implicitly cast from `FileIngestionMethod` to `ContentAddressMethod`, but clang isn't. So explicit the cast
`NIX_HARDENING_ENABLE` causes `_FORTIFY_SOURCE` to be defined. This isn't compatible with `-O0`, and the compiler will happily remind us about it at every call, spamming the terminal with warnings and stack traces. We don't really care hardening in that case, so just disable it if we pass `OPTIMIZE=0`.
++ lib.optional stdenv.cc.isClang pkgs.buildPackages.bear | ||
# TODO: Remove the darwin check once | ||
# https://github.com/NixOS/nixpkgs/pull/291814 is available | ||
++ lib.optional (stdenv.cc.isClang && !stdenv.buildPlatform.isDarwin) pkgs.buildPackages.bear |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed #9900 did not need it. 👍
Docker push is failing: https://github.com/NixOS/nix/actions/runs/8084099897/job/22090423845 This is caused by using Nix 2.13.3: Line 119 in 587c7dc
Which doesn't have |
Clang shell is now broken because a change in how
|
@Ericson2314 As above, that only happens with Nix versions <2.13.5, though no idea why such an old version is used there |
This reverts commit d6d7d2c.
This was found when trying to run the fileset tests on Darwin (NixOS/nix#9546 (comment)), which mysteriously fail on Darwin: test case at lib/fileset/tests.sh:342 failed: toSource { root = "/nix/store/foobar"; fileset = ./.; } should have errored with this regex pattern: lib.fileset.toSource: `root` \(/nix/store/foobar\) is a string-like value, but it should be a path instead. \s*Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead. but this was the actual error: error: lib.fileset.toSource: `root` (/nix/store/foobar) is a string-like value, but it should be a path instead. Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead. After dissecting this, I find out that apparently \s works on Linux, but not on Darwin for some reason! From the bash source code, it looks like <regex.h> with `REG_EXTENDED` is used for all platforms the same, so there's nothing odd there. It's almost impossible to know where <regex.h> comes from, but it looks to be a POSIX thing. So after digging through the almost impossible to find POSIX specifications (https://pubs.opengroup.org/onlinepubs/007908799/xbd/re.html#tag_007_003_005), I can indeed confirm that there's no mention of \s or the like! _However_, there is a mention of `[[:blank:]]`, so we'll use that instead.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tweag-nix-dev-update-55/40996/1 |
Motivation
Update to the latest stable NixOS release.
I didn't try to deeply check anything, just updated the flake input (and removed a redundant fetch) and saw that the build and tests didn't break.
Priorities
Add 👍 to pull requests you find important.