Issue 61250 coreutils disable test on musl

[nh2]

Motivation for this change

Fixes #61250 (comment)

CC @matthewbauer @tobim

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• 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 nix-review --run "nix-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)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[tobim]

Nice work tracking that down.
I wonder if coreutils should have tzdata included in buildInputs, so that these are actually executed in sandboxed mode?

[dtzWill]

Awesome investigation! Minor nit: if only needed for testing, should be added to checkInputs. Although I don't think tzdata will help although I could be wrong.

As for this PR, I would prefer using upstream patch if possible... is it correct that the best patch available is the one from the mailing list? ( https://lists.gnu.org/archive/html/coreutils/2019-05/txtrygo35HvcI.txt or so )

[nh2]

As for this PR, I would prefer using upstream patch if possible... is it correct that the best patch available is the one from the mailing list?

@dtzWill Right now there's no upstream patch; I understood the posted one as "here's a patch, can you try it", and it looks reasonable to me, but I wouldn't call it upstream just yet.

I just gave a super quick shot with

         ++ optional stdenv.hostPlatform.isMusl (fetchpatch {
            url = https://lists.gnu.org/archive/html/coreutils/2019-05/txtrygo35HvcI.txt;
            name = "0001-tests-avoid-false-positive-in-date-debug-test.patch";
            sha256 = "1zg9m79x1i2nifj4kb0waf9x3i5h6ydkypkjnbsb9rnwis8rqypa"; # made up
         })

but somehow fetchpatch doesn't work in this file, I get

error: anonymous function at /home/niklas/src/haskell/static-haskell-nix/nixpkgs/pkgs/build-support/fetchurl/boot.nix:5:1 called with unexpected argument 'meta', at /home/niklas/src/haskell/static-haskell-nix/nixpkgs/pkgs/build-support/fetchpatch/default.nix:14:1

fetchurl works as normal.

Do you want me to use

         ++ optional stdenv.hostPlatform.isMusl (fetchurl {
            url = https://lists.gnu.org/archive/html/coreutils/2019-05/txtrygo35HvcI.txt;
            sha256 = "0blllqds5vkk16nahnakh8krqkk34x6i8hzlvkxbvlkkm79r5214";
         })

?

I wonder if coreutils should have tzdata included in buildInputs, so that these are actually executed in sandboxed mode?

@tobim Sounds like a reasonable idea, more tests being run sounds good. checkInputs as @dtzWill says seems like the right place for it. You need to check though if that helps as the functionality may look in /etc only, I'm not sure. In any case, that's for a different PR, do you want to take that item @tobim? As I'm quite busy with the swathe of small musl related fixes.

[dtzWill]

On Thu, 16 May 2019 11:06:04 -0700, Niklas Hambüchen ***@***.***> wrote: > As for this PR, I would prefer using upstream patch if possible... is it correct that the best patch available is the one from the mailing list? @dtzWill Right now there's no upstream patch; I understood the posted one as "here's a patch, can you try it", and it looks reasonable to me, but I wouldn't call it upstream just yet. I just gave a super quick shot with ``` ++ optional stdenv.hostPlatform.isMusl (fetchpatch { url = https://lists.gnu.org/archive/html/coreutils/2019-05/txtrygo35HvcI.txt; name = "0001-tests-avoid-false-positive-in-date-debug-test.patch"; sha256 = "1zg9m79x1i2nifj4kb0waf9x3i5h6ydkypkjnbsb9rnwis8rqypa"; # made up }) ``` but somehow `fetchpatch` doesn't work in this file, I get

Ahh, sorry for sending you in this direction :3. Don't worry about it if there's nothing upstream yet, especially since as you point out the patch offered was more informal anyway.

``` error: anonymous function at /home/niklas/src/haskell/static-haskell-nix/nixpkgs/pkgs/build-support/fetchurl/boot.nix:5:1 called with unexpected argument 'meta', at /home/niklas/src/haskell/static-haskell-nix/nixpkgs/pkgs/build-support/fetchpatch/default.nix:14:1

I didn't trace this or check fully (eep!) but I think you're encountering the "packages needed by fetchpatch shouldn't use fetchpatch" quirk of how things are bootstrapped up. Usually for these sorts of situations there's either a variant for use only by bootstrap packages or the patch may be best vendored since it doesn't really help to externalize a patch needed by essentially 100% of the packages in nixpkgs :). Anyway, nevermind this and sorry for any wasted time. Appreciate you trying it :).

…

``` `fetchurl` works as normal. Do you want me to use ``` ++ optional stdenv.hostPlatform.isMusl (fetchurl { url = https://lists.gnu.org/archive/html/coreutils/2019-05/txtrygo35HvcI.txt; sha256 = "0blllqds5vkk16nahnakh8krqkk34x6i8hzlvkxbvlkkm79r5214"; }) ``` ? > I wonder if coreutils should have `tzdata` included in `buildInputs`, so that these are actually executed in sandboxed mode? @tobim Sounds like a reasonable idea, more tests being run sounds good. `checkInputs` as @dtzWill says seems like the right place for it. You need to check though if that helps as the functionality _may_ look in `/etc` only, I'm not sure. In any case, that's for a different PR, do you want to take that item @tobim? As I'm quite busy with the swathe of small musl related fixes. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #61471 (comment) part: text/html

[nh2]

@dtzWill Sounds good, should we merge then?

[nh2]

I've switched to using the upstream patch from coreutils/coreutils@0251229.

Ready to merge from my side, if it builds fine.

[nh2]

@GrahamcOfBorg test pkgsMusl.coreutils

[nh2]

@GrahamcOfBorg build pkgsMusl.coreutils

[nh2]

@GrahamcOfBorg build pkgsMusl.coreutils

(I got building of '/...-gcc-7.4.0.drv' timed out after 3600 seconds, and @samueldr explained the timeout is for the whole build)

[tobim]

LGTM