staging-next 2022-07-01 #179844
Merged
staging-next 2022-07-01 #179844
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
Member
vcunat
commented
Jul 1, 2022
vcunat
commented
- workflow docs: nixos.org/manual/nixpkgs/unstable/#submitting-changes-commit-policy
- important job(s): hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
- jobset: hydra.nixos.org/jobset/nixpkgs/staging-next
- nix-review reports: https://malob.github.io/nix-review-tools-reports/
- previous staging-next: staging-next 2022-06-23 #178690
Bug: Due to the way `buildGoDir` function was repurposed to also run `go test`, if `checkFlags` was defined, `go test` was ran only at the top level directory. Only the first element of `checkFlags` array would get passed to the `go test` command as arguments. Fix: Now the first parameter to `buildGoDir` is handled as the command. If the command is "test" `checkFlags` get passed as arguments along with other build flags like ldflags, tags, etc. Readability: - Iteratively build a flag array in `buildGoDir` instead of single long variable expansion command line. - Bash style: Single line local assignment of positional parameters.
The version of Ginkgo it relies on might be the problem. Bug fixed by #173702 runs the previously skipped tests for this package.
- Disable the tests requiring access to gitlab.com. - Add coreutils to `nativeBuildInputs` for printf and echo binaries. - Fix hard coded paths to coreutils binaries. Bug fixed by #173702 runs the previously skipped tests for this package.
Bug fixed by #173702 runs the previously skipped tests for this package.
Bug fixed by #173702 runs the previously skipped tests for this package.
These test are written in a way that they don't skip themselves if they cannot find an Android device attached over USB to the running host. Bug fixed by #173702 runs the previously skipped tests for this package.
Disable the tests requiring access to gitlab.com Bug fixed by #173702 runs the previously skipped tests for this package.
Bug fixed by #173702 runs the previously skipped tests for this package.
As explained in the comment, this ensures that stage4-coreutils does not leak a reference to the bootstrap-files by way of libgmp. This will allow the next patch in this series to build stage4-coreutils using a dynamically-linked (rather than statically-linked) libgmp.
The usage of `makeStaticLibraries` in stdenv/linux/default.nix is prefaced by this comment: # Link GCC statically against GMP etc. This makes sense because # these builds of the libraries are only used by GCC, so it # reduces the size of the stdenv closure. However "these builds of the libraries are only used by GCC" is not actually true. As currently written, the stage4 coreutils links against these customized, static-ified libraries. Beside the fact that the code doesn't actually do what it says, this causes other problems as well. One example is #168983, which arises because have a dynamically-linked binary (coreutils) which is built from statically-linked libraries (libgmp.a); doing this causes mayhem on platforms where `-fstack-protector` needs an auxiliary `libssp.{so,a}` library; we end up with link failures because some parts of the resulting binary want `libssp.so` and other parts want `libssp_nonshared.a`. Let's make the code actually do what the comment says, by moving these definitions into the `gcc-unwrapped` override. This will cause the stage4-coreutils to link against libgmp dynamically, rather than statically. For this reason this commit depends on the previous commit, which allows that to be done without creating a forbidden reference from stdenv-final to the bootstrap-files.
During stdenv bootstrapping, coreutils is built twice. This makes troubleshooting very difficult, because both packages have name="coreutils", so it is a hassle to figure out "which coreutils am I using / is not building"? The first of these builds is used only in stage4, and is not part of the final stdenv. Let's label that one with a different `name` attribute to make it obvious which is which.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
This reverts commit ff7b216.
Currently `buildPerlPackage` prefixes the Perl version to the package's `pname`, which results in `nix run` not being able to work for any packages build with it out of the box. This commit corrects that and phases out the ability to set `name` directly, as well as refactors the code to not require `cleanedAttrs`.
The XS modules were being built for the build platform, and the perl scripts
had build platform shebangs.
It is possible to build the XS modules by passing
PERL_EXT_CC=${stdenv.cc.targetPrefix}cc and --enable-perl-xs=yes, but they
fail to load due to a handshake key mismatch. Instead, I just decided to
disable the XS modules and use the pure Perl fallbacks when cross-compiling.
The shebangs were fixed manually using substituteInPlace.
texinfo is a nativeBuildInput, but it is overridden in all-packages.nix, which breaks splicing. Therefore, buildPackages.texinfo needs to be used explicitly in the override. This wasn't actually causing any problems because texinfo's scripts were using build platform Perl shebangs. Once texinfo was fixed, gpm started failing to cross-compile.
Without the change parallel build fails as:
gcc -I/build/gnu-efi-code//lib ... -c lib/runtime/rtstr.c -o runtime/rtstr.o
Assembler messages:
Fatal error: can't create runtime/rtstr.o: No such file or directory
Also, aborts when the list contains anything besides the acceptable options.
Because it is easier to look at them as a block, not polluting the directory listing so much.
Following the trend of enhanced composability, and further because it is unusual a build tool using libsForQt5 as scope.
Without the change build with `config.configurePlatformsByDefault = true`
fails as:
Error: Unknown flag: --build=x86_64-unknown-linux-gnu
…80301) Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
|
/cc PR #180336 I'm not entirely sure about this, as I couldn't spend much time, but it seemed plausible that the patch caused a different kind of errors in this tested case - though it's possible I messed the test up. Either way, the tests seem to pass now, unblocking the CVE fixes ;-)
|
I think there are only smaller regressions remaining now, probably not critical.
|
|
The purpose is to integrate the usual Haskell rebuild.
This version is really being phased out, so let's hope it's better somewhat working than not building.
…ch64-darwin python310Packages.twisted: remove pyOpenSSL checkInput on aarch64-darwin
|
|
|
@SuperSandro2000 : #180518 looks fine to me for merge. |
...into staging-next
... with newest sqlite (into staging-next)
vcunat
added
the
1.severity: security
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.