On Fri, Nov 20, 2015 at 2:51 PM, Ludovic Courtès <l...@gnu.org> wrote: > Jan Synáček <jan.syna...@gmail.com> skribis: > >> On Sat, Nov 14, 2015 at 12:40 PM, Ludovic Courtès <l...@gnu.org> wrote: >>> Jan Synáček <jan.syna...@gmail.com> skribis: >>> >>>> Reference files will be read from: >>>> /tmp/nix-build-libarchive-3.1.2.drv-0/libarchive-3.1.2/tar/test >>>> Running tests on: >>>> "/tmp/nix-build-libarchive-3.1.2.drv-0/libarchive-3.1.2/./bsdtar" >>>> Exercising: bsdtar 3.1.2 - libarchive 3.1.2 >>> >>> [...] >>> >>>> 17: test_option_b FAIL >>> >>> Ricardo reported the same issue a while back: >>> >>> https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00182.html >>> >>> What platform is this on, i686? >>> >>> It would be nice to see if this systematically fails. If it is >>> non-deterministic, we should build it with --keep-failed until it fails >>> (removing successful builds with ‘guix gc -d’), collect useful info from >>> the build tree, and debug. >>> >>> (You can also work around it by enabling substitutes since Hydra had no >>> problems building it.) >>> >>> Ludo’. >> >> In my case the build fails always. I'm running guix on Fedora 23, x86_64. > > What file system is this on?
The test itself seems to always run in /tmp, which is tmpfs in my case. I tried patching it to run in /var/tmp, which is ext4 (on LVM), but that failed as well. > I’ve run several builds on my x86_64 GuixSD, ext4, but I’ve failed to > reproduce the test failure. I could reproduce the issue even outside of the guix build process. I downloaded the tarball, extracted it and ran configure + make + make check. The latest git version worked fine, even though the asserts in test_option_b.c didn't change. > I noticed that libarchive uses ‘readdir’ calls as-is, without sorting > directory entries afterwards. Thus, the order of directory entries is > effectively non-deterministic and may change depending on the phase of > the moon. > > This has been reported at: > > https://github.com/libarchive/libarchive/issues/602 > > Could you add the patch that’s given at that URL to the ‘patches’ field > or libarchive’s ‘origin’ form and see if the problem shows up again, > preferably building several times in a row? I built it once and it passed (note that it failed *everytime* I wanted to build it). Maybe a dumb question, but how do I force a rebuild of an already built package?:) > At any rate we’ll probably apply the patch. > > Thanks, > Ludo’. Cheers, -- Jan Synáček
