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

staging-next 2023-05-02 #229429

Merged
merged 98 commits into from
May 7, 2023
Merged

staging-next 2023-05-02 #229429

merged 98 commits into from
May 7, 2023

Conversation

vcunat
Copy link
Member

@vcunat vcunat commented May 2, 2023

According to 23.05 schedule, this this iteration is the last one allowed to contain breaking changes (except desktop environments).

Helpful links

Mass breakages

(will be edited based on progress)

aviallon and others added 30 commits April 5, 2023 00:26
`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.
@vcunat
Copy link
Member Author

vcunat commented May 5, 2023

Perhaps notmuch maintainers could look into its build regression? @flokli @puckipedia

EDIT: logs differ by platform, apparently:

@vcunat
Copy link
Member Author

vcunat commented May 5, 2023

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 staging-next).

EDIT: I did it on aarch64.nixos.community so it has the binaries, in case someone wants to play with this.

@vcunat
Copy link
Member Author

vcunat commented May 7, 2023

notmuch: relevant parts of test logs (thanks to Lily):

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

vcunat and others added 2 commits May 7, 2023 11:09
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).
@vcunat
Copy link
Member Author

vcunat commented May 7, 2023

Well, the bad tests are skipped in notmuch now, but I think it would be still nice if someone looked into that...

@vcunat vcunat merged commit 51f728c into master May 7, 2023
@vcunat
Copy link
Member Author

vcunat commented May 8, 2023

  • sway test times out when waiting for gpg to show "Passphrase"
      # Test gpg-agent starting pinentry-gnome3 via D-Bus (tests if
      # $WAYLAND_DISPLAY is correctly imported into the D-Bus user env):
      swaymsg("exec gpg --no-tty --yes --quick-generate-key test")
      machine.wait_until_succeeds("pgrep --exact gpg")
      machine.wait_for_text("Passphrase")
      machine.screenshot("gpg_pinentry")
      machine.send_key("alt-shift-q")
      machine.wait_until_fails("pgrep --exact gpg")
    This is blocking nixos-unstable channel.

This was referenced May 8, 2023
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: python 6.topic: stdenv Standard environment 8.has: package (new) This PR adds a new package 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
Projects
None yet
Development

Successfully merging this pull request may close these issues.