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 #85664

Merged
merged 136 commits into from Apr 23, 2020
Merged

Staging next #85664

merged 136 commits into from Apr 23, 2020

Conversation

FRidh
Copy link
Member

@FRidh FRidh commented Apr 21, 2020

Motivation for this change

https://hydra.nixos.org/jobset/nixpkgs/staging-next

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

samueldr and others added 30 commits December 6, 2019 23:17
Since 2.44_01, the behaviour for `check_lib` in their `Makefile.PL` has
been "fixed" to fail when the `assert_lib` function fails to build the
test.

 * cpan-authors/XML-Parser@2bc1e90

Now, this wouldn't be so bad, since it's good to actually test what
stuff is being compiled against.

Except that *something* is wonky with the cross-compilation build-time
Perl.

```
Undefined subroutine &File::Temp::mktemp called at inc/Devel/CheckLib.pm line 236.
```

As far as I know, this is a built-in function from Perl.

 * https://perldoc.perl.org/File/Temp.html

Though, something *else* is wrong with `Checklib.pm`. Side-stepping the
issue by (eww) shelling out to `mktemp`, we get these errors:

```

/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-armv7l-unknown-linux-gnueabihf-binutils-2.31.1/bin/armv7l-unknown-linux-gnueabihf-ld: assertlib_src1_0.553056903257133: file not recognized: file truncated
collect2: error: ld returned 1 exit status
 -I/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-expat-2.2.8-armv7l-unknown-linux-gnueabihf-dev/include -L/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-expat-2.2.8-armv7l-unknown-linux-gnueabihf/lib -lexpat
/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-armv7l-unknown-linux-gnueabihf-binutils-2.31.1/bin/armv7l-unknown-linux-gnueabihf-ld: assertlib_src2_0.262169388446154: file not recognized: file truncated
collect2: error: ld returned 1 exit status
Can't link/include C library 'expat.h', 'expat', aborting.
```

Meanwhile, the actual build, while building the library, seemingly has
no issues building using those paths. `¯\_(ツ)_/¯`
This will switch the default TCP congestion control algorithm from
new Reno to CUBIC. CUBIC is the default since Linux kernel 2.6.19
(see 597811ec167fa) and most (all?) distributions keep this default
(e.g. Debian and Ubuntu). On NixOS the default was still new Reno
because generate-config.pl changes TCP_CONG_CUBIC from y to m (since we
try to build everything as a module by default).

To check the active and available algorithms:
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
$ sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno

Note: E.g. x86_64_defconfig sets TCP_CONG_CUBIC=y indirectly via
CONFIG_TCP_CONG_ADVANCED=y (but CUBIC is also the default if set to no,
see net/ipv4/Kconfig).
These are expected to be here for Windows compilation. The change in
e1831eb didn’t move these
correctly (while still patching the search paths).

https://hydra.nixos.org/build/114202790
It appears that cairo's configure script, at least on MacOS but perhaps
elsewhere, unconditionally enables xlib support, even if the library
isn't present, which breaks the build on MacOS always (since x11 is
disabled by default now). This explicitly passes `--disable-x11` if
x11Support is set to false, which fixes the build for me.
"Not a lot of changes in this release, most are related to fixing output
formatting and documentation." [0]

File changes (additions/removals):
+share/man/man8/tc-ets.8.gz
+share/man/man8/tc-fq_pie.8.gz

nix path-info -S:
5.5.0 51509616
5.6.0 51528680

[0]: https://marc.info/?l=linux-netdev&m=158585608413591
- Need custom pkg-config setting
- add wayland & libxkbcommon
They will be installed now and we can provide $HOSTCC for
cross-compilation.

New files:
+lib/tc/experimental.dist
+lib/tc/normal.dist
+lib/tc/pareto.dist
+lib/tc/paretonormal.dist

Note: The distributions are generated in a reproducible way.

Co-Authored-By: Benjamin Saunders <ben.e.saunders@gmail.com>
linux config: Set TCP_CONG_CUBIC=yes to restore the default
- add glib to nativeBuildInputs
- only update loaders cache on native builds
This is needed in cross where systemd is not in path.
Also set wayland-scanner to proper path
These should be runtime, not build time deps
Unfortunately, we need to emulate the system to get a real cache.
Native version doesn’t know the right paths.
We can’t cross-compile the cache, so just skip it for now.
This prevents duplication in cross-compiled nixos machines. The
bootstrapped glibc differs from the natively compiled one, so we get
two glibc’s in the closure. To reduce closure size, just use
stdenv.cc.libc where available.
- adds utilmacros
- set null malloc flag
- Needs to be like <cpu>-<os>-gcc.
- Remove unneeded --enable-external-build flag
    This confuses the feature detection and is not needed for cross
    compilation anymore.
Copy link
Contributor

@jtojnar jtojnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can confirm gnome tests succeed and opening random apps in GNOME VM does not seem to reveal any new issues.

The nixos manual build is fixed on master: 830733d.

@FRidh
Copy link
Member Author

FRidh commented Apr 23, 2020

There are still quite some rebuilds needed but the same on master, so I am merging. Will wait a bit with new staging-next round because of the rebuilds on the stable branches as well. That means no new openssl on master for at least several days.

@FRidh FRidh merged commit 2e69baf into master Apr 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet