Hello, Jeremy Robst <j...@bas.ac.uk> skribis:
>>> Any ideas? >> >> I get the same failures intermittently. Other times the build passes. > > Yes, I've built it many times over the past few days - sometimes I get > a failure, other times it builds ok, like you. If I do > > ./pre-inst-env guix gc > ./pre-inst-env guix build hdf4 Instead, you can run: ./pre-inst-env guix build --check hdf4 > Looking at the HDF code it's doing things with the maximum number of > open files - is there anything guix does when it's creating the > restricting environment for the build user that would limit the number > of open files ? It does not use ‘setrlimit’, which means it inherits the limits of its parent process. There was a problem on the maximum number of processes for people running guix-daemon from systemd, which commit f489ce3c9343e3ba9927645d11fcb91bb69f0fa7 addressed. But anyway, I hit the problem on GuixSD, so it’s not systemd-related. It might be worth trying: #:parallel-tests? #f though I suspect it’s a per-process limit that we’re hitting, not a global limit. Next step would be to ask the HDF4 developers. :-) > libhdf4.settings includes the build user and the details of the build > host as well as the build time. This file is included in the final > build. I patched configure to set the build time to the epoch, taken > from the HDF5 patch. Clearing the build time is definitely necessary. > However I also changed the libhdf4.settings to remove details of the > build user and build host since I was aiming for reproducibilty across > builds across machines. E.g I happen to always have built it with the > user guixbuild00, but if I was building 2 or more things in parallel > then it might get built with guixbuild01 and I thought this would then > show us as a different build (since the username would be in > libhdf4.settings in the file output). Is that right or am I > misunderstanding something ? You are right, the user name could differ, so it’s best to patch it if it gets embedded in the end. Thanks, Ludo’.
