Hi Ludo,
> hydra.gnu.org is unfortunately too often overloaded these days, so you
> probably arrived on a bad day. Nevertheless, the solution to this
> specific issue is for you to use substitutes to circumvent the bug
> described below.
It seems to always be busy for me; I tried on different day
(Please keep 20...@debbugs.gnu.org copied.)
Andy Patterson skribis:
>> hydra.gnu.org is unfortunately too often overloaded these days, so you
>> probably arrived on a bad day. Nevertheless, the solution to this
>> specific issue is for you to use substitutes to circumvent the bug
>> described b
Pádraig Brady wrote:
Yes I agree, either behavior is possible
In that case let's change the test case to not run afoul of this
implementtion-defined behavior. I don't think we need to change tar, as it's a
contrived test case that users are not likely to run into.
On 24/05/15 14:53, Ludovic Courtès wrote:
> Pádraig Brady skribis:
>
>> On 24/05/15 12:33, Ludovic Courtès wrote:
>
> [...]
>
>>> unlinkat(4, "foo_file", 0) = 0
>>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0
>>> unlinkat(5, "bar_file", 0) = 0
>>> unlinkat(4, "../bar",
On 24/05/15 12:33, Ludovic Courtès wrote:
> (Please keep 20...@debbugs.gnu.org Cc'd.)
> (Gnulib: please scroll further down for the ‘unlinkat’ issue.)
>
> Andy Patterson skribis:
>
>>> I suppose this is Guix 0.8.2 on top of another distribution, right? Did
>>> you install from source or from th
Pádraig Brady skribis:
> On 24/05/15 12:33, Ludovic Courtès wrote:
[...]
>> unlinkat(4, "foo_file", 0) = 0
>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0
>> unlinkat(5, "bar_file", 0) = 0
>> unlinkat(4, "../bar", AT_REMOVEDIR) = -1 ENOENT (No such file or
>> direc
(Please keep 20...@debbugs.gnu.org Cc'd.)
(Gnulib: please scroll further down for the ‘unlinkat’ issue.)
Andy Patterson skribis:
> > I suppose this is Guix 0.8.2 on top of another distribution, right? Did
> > you install from source or from the binary tarball? Did you enable
> > substitutes (i
