Skip to content

python310Packages.google-auth: remove pyopenssl#180082

Closed
azuwis wants to merge 200 commits intoNixOS:masterfrom
azuwis:google-auth
Closed

python310Packages.google-auth: remove pyopenssl#180082
azuwis wants to merge 200 commits intoNixOS:masterfrom
azuwis:google-auth

Conversation

@azuwis
Copy link
Contributor

@azuwis azuwis commented Jul 4, 2022

pyopenssl is broken on aarch64-darwin #172397

It's in extras_require (optional), and only needed if mTLS feature is
enabled (disabled by default) googleapis/google-auth-library-python#697

Description of changes
Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 22.11 Release Notes (or backporting 22.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

bdd and others added 30 commits June 1, 2022 00:52
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 NixOS#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 NixOS#173702 runs the previously skipped tests for this
package.
Bug fixed by NixOS#173702 runs the previously skipped tests for this
package.
Bug fixed by NixOS#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 NixOS#173702 runs the previously skipped tests for this
package.
Disable the tests requiring access to gitlab.com

Bug fixed by NixOS#173702 runs the previously skipped tests for this
package.
Bug fixed by NixOS#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 NixOS#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>
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
@SuperSandro2000 SuperSandro2000 changed the title google-auth: Remove pyopenssl python310Packages.google-auth: remove pyopenssl Jul 4, 2022
@SuperSandro2000 SuperSandro2000 changed the base branch from staging to master July 4, 2022 14:44
@github-actions github-actions bot added 6.topic: golang Go is a high-level general purpose programming language that is statically typed and compiled. 6.topic: haskell General-purpose, statically typed, purely functional programming language 6.topic: ruby A dynamic, open source programming language with a focus on simplicity and productivity. 6.topic: rust General-purpose programming language emphasizing performance, type safety, and concurrency. 6.topic: stdenv Standard environment 8.has: documentation This PR adds or changes documentation labels Jul 4, 2022
@SuperSandro2000
Copy link
Member

#180124

@ofborg ofborg bot added 10.rebuild-darwin-stdenv This PR causes stdenv to rebuild on Darwin and must target a staging branch. 10.rebuild-linux-stdenv This PR causes stdenv to rebuild on Linux and must target a staging branch. 8.has: clean-up This PR removes packages or removes other cruft 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. and removed 10.rebuild-darwin: 101-500 This PR causes between 101 and 500 packages to rebuild on Darwin. 10.rebuild-linux: 101-500 This PR causes between 101 and 500 packages to rebuild on Linux. labels Jul 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: darwin Running or building packages on Darwin 6.topic: golang Go is a high-level general purpose programming language that is statically typed and compiled. 6.topic: haskell General-purpose, statically typed, purely functional programming language 6.topic: python Python is a high-level, general-purpose programming language. 6.topic: ruby A dynamic, open source programming language with a focus on simplicity and productivity. 6.topic: rust General-purpose programming language emphasizing performance, type safety, and concurrency. 6.topic: stdenv Standard environment 8.has: clean-up This PR removes packages or removes other cruft 8.has: documentation This PR adds or changes documentation 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-darwin-stdenv This PR causes stdenv to rebuild on Darwin and must target a staging branch. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. 10.rebuild-linux-stdenv This PR causes stdenv to rebuild on Linux and must target a staging branch.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Comments