Fractal: Test timeout on aarch64-linux

[OPNA2608]

Describe the bug Building fractal fails on aarch64-linux, both a physical device and cross-compilation on my desktop. Compilation will succeed, but the test phase will time out and the build will be considered a failure.

To Reproduce Steps to reproduce the behavior:

• nix-build '<channel>' -A fractal on aarch64-linux device
• nix-build '<channel>' -A fractal --argstr system aarch64-linux on foreign architecture with binfmt emulation for aarch64-linux enabled

(Tested channel on my end was nixos-unstable)

Compilation will succeed, but the test phase will time out and the build will be considered a failure.

Expected behavior Installation finishes after successful build.

Screenshots

Additional context -

Notify maintainers cc @dtzWill @worldofpeace

Metadata (aarch64-linux device)

• system: "aarch64-linux"
• host os: Linux 5.8.0, postmarketOS, 1.23.0-905a5ce3
• multi-user?: no
• sandbox: yes
• version: nix-env (Nix) 2.3.7
• channels(bt1cn): "nixpkgs-21.03pre234895.72b9660dc18"
• nixpkgs: /home/bt1cn/.nix-defexpr/channels/nixpkgs

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: [ fractal ]
# a list of nixos modules affected by the problem
module:

[dtzWill]

Hmm, not sure if this'll help but for some time I had the following in the postPatch:

substituteInPlace scripts/test.sh --replace 'cargo test -j1' 'cargo test'

with comment about "not limiting tests to single thread" and "don't limit build threads for tests".

Don't suppose adding that helps?

I noticed the script still has --test-threads 1.

So this change frees the test.sh script's cargo test invocation to build things with more cores (since it uses debug for that, not the release actually built which seems both useful (esp if debug means extra checking?) and sadface re:testing what is shipped, but nevermind).

If this helps (preferably consistently so, but that may be hard to test) this should be an easy PR. Sorry for sitting on it, I think I was never sure if this helped or was "lucky" (failure happened on an (over)loaded build machine) but seems like might help and if fixes things reliably for you or anyone else that's a promising finding :).

[dtzWill]

Hmm, I see you are building on arm and two build cores (-j2 -l2) or so...

So the above might not help enough.

The failed test log appears to confirm the problem is building the code under test .. during a "test" that is subject to timeout.

Maybe bugging upstream about it would make sense, but I'm not sure if this is a bug in their normal/targeted compilation+development workflows.

Alternative ideas:

• Disable test on aarch64 (not ideal but worth considering)?
• Explicitly build the code in debug mode (or whatever is needed) as part of build phase, probably in addition to release :( (preserving the double-building behavior but doing it outside the test harness timeout).
• (not sure if reasonable) test the code as built and installed

I don't know rust very well (mostly from packaging them with nix) so apologies if I'm off on some of the bits re:testing-what-is-shipped (I suppose they might test both or testing builds "side" files or any number of things, and don't mean to unduly malign their practices I just am reporting what it looks like to me :innocent: ).

[stale[bot]]

I marked this as stale due to inactivity. → More info