-
-
Notifications
You must be signed in to change notification settings - Fork 15k
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-05-02 #229429
staging-next 2023-05-02 #229429
Conversation
`diffoscope` shows no difference before and after the change.
Co-authored-by: Atemu <atemu.main@gmail.com>
numactl: move headers and mans to "dev" and "man" outputs
polyphone: drop redundant INCLUDEPATH to libjack2
This fixes building for x86_64-windows with no libc (for UEFI). Otherwise, it would try to include a malloc header.
It makes sense to allow platform definitions to opt out of having libc at all. One use case would be targetting some obscure new Linux target that doesn't have a libc implementation yet, and another is UEFI, which is basically libc-less Windows. Not having libc is not commonly specified in (GNU) triples (even Linux's build system will just target either -gnu or -musl depending on the platform), so instead, we use a separate attribute for it.
clangNoLibc always uses LLVM bintools, so it still has the useLLVM semantics.
According to <https://gcc.gnu.org/legacy-ml/gcc-patches/2015-08/msg00836.html>, all code is position-independent on Windows. Some compilers apparently warn for -fPIC on Windows, and clang errors: > clang-15: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc' I'm guessing the check was hostPlatform instead of targetPlatform by mistake.
LLD supports Windows-style linker arguments, but these previously triggered purity check false positives, because it saw that they started with a '/' and assumed they were paths. This tweaks the path detection to allow through certain values that could be paths, but are much more likely to be LINK.EXE-style flags. The risk of false negatives here is low — the only things we'd now fail to catch would be attempts to link with libraries in the root directory, which doesn't happen in practice. We also teach the wrapper how to apply its purity checks to library paths specified with the /LIBPATH: option. Tested that paths we expect to be rejected (like /lib/libfoo.so) still are.
Perhaps EDIT: logs differ by platform, apparently: |
So the gnupg patch-update (in 122e774) certainly does break notmuch build (on aarch64-linux). No idea why. There were at least two different notmuch breakages in the bisected span (even though it's just over several days), so it might be more complicated... though I think this commit introduced the right error (same-looking log as in latest EDIT: I did it on |
...into staging-next
|
They started failing after gnupg: 2.4.0 -> 2.4.1: T350-crypto: Testing PGP/MIME signature verification and decryption PASS emacs delivery of signed message via fcc PASS emacs delivery of signed message via fcc and smtp PASS signed part content-type indexing PASS signature verification PASS detection of modified signed contents PASS corrupted pgp/mime signature PASS signature verification without full user ID validity PASS signature verification with signer key unavailable FATAL: /build/notmuch-0.37/test/T350-crypto.sh: interrupted by signal 15 [...] T357-index-decryption: Testing indexing decrypted mail FATAL: /build/notmuch-0.37/test/T357-index-decryption.sh: interrupted by signal 15 I hope the failures don't signify a real issue. There's also gnupg22 which would pass these tests, but it's currently marked as vulnerable (transitively).
Well, the bad tests are skipped in |
|
According to 23.05 schedule, this this iteration is the last one allowed to contain breaking changes (except desktop environments).
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)
python311Packages.pytest-benchmark
(all platforms but 3.11 only)notmuch
https://hydra.nixos.org/build/218564125#tabs-buildsteps
1d6af3f