-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
staging-next 2023-09-17 #255658
Merged
Merged
staging-next 2023-09-17 #255658
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The symbol alias macros now support macOS, so the patch can be dropped.
The current Git revision has had a lot of work done to it to better support macOS and lets us drop the huge patch we were using before. More macOS fixes are apparently on the way, so hopefully the two that are still required can be dropped on the next release.
native build produces binaries with `#!${bash}/bin/sh` as shebang. seems to be a consequence of nixpkgs using bash in the builder, and `patchShebangs` sees that. OTOH cross builds would get `#!/bin/sh` because the builder's bash isn't eligible as a runtime shebang. i can't say which is most "correct" in the context of this tool, but shipping bash in `buildInputs` where `patchShebangs` can see it at least gets us *consistency*.
without this applications won't locate gtk3's schemas even if they're on XDG_DATA_DIRS. this patch solves runtime errors of the form: ``` Settings schema 'org.gtk.Settings.FileChooser' is not installed ```
protobuf>3.20 allows to use the system GTest. Therefore, we can safely remove the logic to use third_party/gmock from `generic-v3-cmake.nix` because it's used only for protobuf>=3.21.
TIme to time I bump into pathological behaviour of `bash` memory allocator. Today's example: $ time { ls /nix/store/ > /dev/null; } real 0m0,965s user 0m0,876s sys 0m0,087s $ time { echo /nix/store/* > /dev/null; } real 2m18,287s user 2m17,946s sys 0m0,125s $ time { echo /nix/store/* > /dev/null; } real 0m1,764s user 0m1,712s sys 0m0,048s Note how initial `echo` takes alsmot 2 minutes to finish. Let's rely on system's allocator instead. After the change initial run is fast again: $ time { echo /nix/store/* > /dev/null; } real 0m1,328s user 0m1,264s sys 0m0,063s
Build needs to run wayland-scanner, so needs a native wayland.
* Apply the patch used for gperf 3.1 in 58f559c; and * Include `string.h` unconditionally in `lib/getopt.c`.
Without the change `which` fails to find programs on filesystems with 64-bit inodes when `which` itself is 32-bit. In my case it is `btrfs` and `i686-linux`. `bison` is in the PATH: $ dev>bison bison: missing operand Try 'bison --help' for more information. But `which` fails to find it: $ which bison which: no bison in ... `bison` is a file with an inode number that overflows 2^31 limit: $ stat ~/bin/bison File: ~/bin/bison Size: 674260 Blocks: 1320 IO Block: 4096 regular file Device: 0,29 Inode: 4384368825 Links: 2 Access: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-09-05 04:48:43.000000000 +0100 Modify: 1970-01-01 01:00:01.000000000 +0100 Change: 2023-09-05 04:48:43.821566578 +0100 Birth: 2023-09-05 04:48:43.772565733 +0100 The change fixes `which` run.
ffmpeg_4 crashes in `ff_seek_frame_binary` due to UB and optimizations clang 16 performs. This is fixed upstream in ffmpeg_5, but the patch can be made to apply to ffmpeg_4.
Remove usage of the register storage class, which is not allowed in C++17 (the default for clang 16).
Feel free to find a better solution. This is just a simple mass-regression stop-gap, as noone seems to care about the failure.
abseil-cpp version hell makes it hard to switch versions (as I feared) https://hydra.nixos.org/build/236112673/nixlog/1/tail So let's avoid tests instead, until someone really investigates this.
Really, I was careless. But at least the default version had it right.
I believe we're good enough to merge now. There were delays mainly due to hydra having less aarch64-linux build power than usual. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
1.severity: security
Issues which raise a security issue, or PRs that fix one
6.topic: nixos
Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS
6.topic: nodejs
6.topic: python
6.topic: qt/kde
6.topic: systemd
6.topic: vim
8.has: changelog
8.has: clean-up
8.has: documentation
8.has: module (update)
This PR changes an existing module in `nixos/`
10.rebuild-darwin: 501+
10.rebuild-darwin: 5001+
10.rebuild-darwin-stdenv
This PR causes stdenv to rebuild
10.rebuild-linux: 501+
10.rebuild-linux: 5001+
10.rebuild-linux-stdenv
This PR causes stdenv to rebuild
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Helpful links
https://hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
https://hydra.nixos.org/job/nixos/staging-next-small/tested
https://hydra.nixos.org/jobset/nixpkgs/staging-next
https://hydra.nixos.org/jobset/nixos/staging-next-small
Mass breakages
(will be edited based on progress)