Nixpkgs: findutils tests fails

[truls]

Describe the bug
Building the findutils package on old linuxes (I tried CentOS 6, kernel 2.6.32) fails due to two failing tests involving the getdtablesize function. I can only reproduce this problem when building the package using the nix toolchain on CentOS 6. Building directly on CentOS 6 and building with nix on Fedora 31 works.

The findutils package was previosly patched by nix to disable the failing tests (https://github.com/NixOS/nixpkgs/pull/67753/files), but these patches were removed when updating the package to its current version

To Reproduce
Steps to reproduce the behavior:

1. Find a CentOS 6 (2.6.32) box
2. Build the findutils nix package

Quck test to see if the problem is present:

1. Configure the findutils source
2. Go to the gnulib-tests directory
3. Build the failing test:
   gcc -o test-getdtablesize -I .. test-getdtablesize.c
4. ./test-getdtablesize

Expected behavior
The package should build without test failures.

Metadata

[trulsas@centos610 bin]$ nix-shell -p nix-info --run "nix-info -m"
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked):
  /nix/store/2lv26r396jarxmjlfflxm28q2vdh22hb-nix-info
copying path '/nix/store/2lv26r396jarxmjlfflxm28q2vdh22hb-nix-info' from 'https://cache.nixos.org'...
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
 - system: `"x86_64-linux"`
 - host os: `Linux 2.6.32-754.27.1.el6.x86_64`
 - multi-user?: `no`
 - sandbox: `no`
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
 - version: `nix-env (Nix) 2.3.2`
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
 - channels(trulsas): `"nixpkgs-20.03pre212770.cc1ae9f21b9"`
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
 - nixpkgs: `/home/trulsas/.nix-defexpr/channels/nixpkgs`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: findutils
# a list of nixos modules affected by the problem
module:

[veprbl]

In principle we could re-revert the patch. The tests are not so useful in the first place. But just in case, I'm going to ask: have you considered overriding findutils with doCheck = false in an overlay? Or you need to use the binary cache?

[truls]

Yes, that's what I'm doing currently. However, even though my setup may not be that common I still think that the package should build out of the box?

[veprbl]

It seems like when doing #46669 I found whole bunch of reasons why those tests are not so great. A correct way to proceed, I think, would be to first ask upstream it they would be willing to remove these tests. @truls do you think you could try?

[truls]

@veprbl https://savannah.gnu.org/bugs/index.php?57839

[truls]

Same problem occurs with gnutls which includes the same testsuite

[truls]

findutils maintainer believes the failing test uncovers a real issue with the glibc 2.30/kernel 2.6.32 combination. Looking at the glibc README, it seems glibc 2.30 officially requires kernel >= 3.2, so maybe it doesn't make a lot of sense to add patches to work around an unsupported configuration.

[veprbl]

@truls,
Thank you for getting this started. I think we could have made an argument that the test in question tests a very specific property of the getdtablesize() function rather than dup2() and then make a case for former to be non-essential for findutils. But there is that fact that the test comes as a part of the established gnulib testsuite and maintainers might be reluctant to tailor the tests for their specific application. So this doesn't appear to be the path of the least resistance.

I've submitted a PR with your proposed solution. It should fix the issue for findutils and elsewhere.

[stale[bot]]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[veprbl]

This was fixed by #80961, I believe.