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 136 commits into from Apr 23, 2020

Staging next #85664

merged 136 commits into from Apr 23, 2020


Copy link

FRidh commented Apr 21, 2020

Motivation for this change

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
samueldr and others added 30 commits Dec 7, 2019
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

 * toddr/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

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

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


Though, something *else* is wrong with ``. 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 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).
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):

nix path-info -S:
5.5.0 51509616
5.6.0 51528680

- Need custom pkg-config setting
- add wayland & libxkbcommon
They will be installed now and we can provide $HOSTCC for

New files:

Note: The distributions are generated in a reproducible way.

Co-Authored-By: Benjamin Saunders <>
linux config: Set TCP_CONG_CUBIC=yes to restore the default
gsm: 1.0.18 -> 1.0.19
- 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 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.
FRidh added 4 commits Apr 21, 2020
Copy link

jtojnar left a comment

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.

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
1 check was pending
1 check was pending
grahamcofborg-eval Checking original out paths

This comment has been minimized.

Copy link

sorki commented on nixos/modules/services/x11/gdk-pixbuf.nix in 6c5983a May 3, 2020

What's the reason for this condition @matthewbauer ? It looks to me that the logic is wrong and loadersCache is built even for empty cfg.modulePackages during cross compiling. I've hit this today and ad-hoc commented out GDK_PIXBUF_MODULE_FILE to get around it as the compilation was failing.

This comment has been minimized.

Copy link
Member Author

matthewbauer replied May 7, 2020

The issue I hit was that if GDK_PIXBUF_MODULE_FILE isn't set, the gdk-pixbuf module wouldn't load at all after cross compiling. But if this is failing for you, it may be better to not have that case. I can just set a dummy package so modulePackages is non-null.

This comment has been minimized.

Copy link
Member Author

matthewbauer replied May 7, 2020

pr at #87212

This comment has been minimized.

Copy link

sorki replied May 8, 2020


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.