Re: Test failure when building libarchive-3.1.2

[Jan Synáček]

On Fri, Nov 20, 2015 at 2:51 PM, Ludovic Courtès <address@hidden> wrote:
> Jan Synáček <address@hidden> skribis:
>
>> On Sat, Nov 14, 2015 at 12:40 PM, Ludovic Courtès <address@hidden> wrote:
>>> Jan Synáček <address@hidden> 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