-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
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-06-02 #235556
staging-next 2023-06-02 #235556
Conversation
The changes are mostly minor; numerous bugs have been fixed and a few new command-line options have been added. Changelog: https://lists.gnu.org/archive/html/coreutils-announce/2023-03/msg00000.html
The bug appears to be resolved: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61386 See also here: openwrt/openwrt#11960 (comment) And here: openwrt/openwrt#12233
was probably broken by recent-ish stdenv work
sord: extract "dev", "doc", "man" outputs
libcap_ng: extract dev, man outputs
soxr: extract dev output
ell: 0.56 -> 0.57
libopenmpt: 0.6.10 -> 0.7.1
This was fixed in 248401cb2c46 ("ice: avoid bonding causing auxiliary plug/unplug under RTNL lock"), which was backported to all relevant kernels.
mupdf: 1.21.1 -> 1.22.1
nixos/no-x-libs: add gst-plugins-bad, gst-plugins-rs
I don't know why it started now, but it only happens in tests, and generally -Werror is more suitable for upstreams than downstreams.
Otherwise it often takes 1-2 hours on Hydra, which seems unnecessary.
This reverts commit add8dd8. This attribute doesn't belong into meta and has no effect there.
...into staging-next
Notable but not really a mass failure:
|
python310Packages.imageio: unbreak on darwin
python310Packages.pyopengl: unbreak on darwin
alacritty: unbreak on darwin
This reverts commit 8392a8b. It's needed for emscripten revert; see the next commit.
This reverts commit 39d2924. Now it will at least fetch sources FIXME correctly and build on *-linux.
Where should I be reporting build failures? It seems that the following are broken:
I would also like to see if the above derivations (exact same hashes) also fail on Hydra. |
I don't know; cross-compilations aren't top-tier targets for us, especially packages that aren't very significant (basic build toolchain). Some stuff gets built on https://hydra.nixos.org/jobset/nixpkgs/cross-trunk but it's only catching up to this merge now and I don't think your packages are there. Generally, if you find particular pull request that broke something, it's good to at least mention on it or link. (I mean, almost all commits in For reading hydra logs for particular derivations, be it failing or succeeding, I'd recommend |
These are not or should not be cross-compiling, as the build, host, and target platforms are all the same. Nixpkgs is imported with I will note that I use a very thin wrapper around |
The |
Indeed, it is suspicious. Is it possible that whatever mechanism bypasses I haven't bothered to investigate further because it was my understanding that cross-compiling for the same |
I don't know such details around cross, I'm afraid. EDIT: but changing the name would certainly cause a rebuild even by itself. |
Who would I ping to help me investigate this? |
Say, the chat I linked above: https://matrix.to/#/#cross-compiling:nixos.org EDIT: I suppose you know about docs at https://nixos.org/manual/nixpkgs/unstable/#chap-cross |
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)
python3Packages.apsw
below