GNU bug report logs - #17669
solaris: tests: cp,mv acl tests fail

Previous Next

To reply to this bug, email your comments to 17669 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ben Walton <bdwalton <at> gmail.com>
To: bug-gnulib <at> gnu.org, bug-coreutils <at> gnu.org
Subject: Solaris acl woes
Date: Mon, 2 Jun 2014 13:38:29 +0100

Hi All,

I've hit a "bug" in the coreutils test suite when exercising acl code
from gnulib. I'm cross-posting to both lists, I hope that's ok.
(Please apply the cluebat gently if not...)

When running tests involving cp -a (in /tmp for this example), I see
errors like:

+ cp -a --parents d/a/b/c e
cp: preserving permissions for 'e/d/a/b/c': Operation not applicable
cp: preserving permissions for 'e/d/a/b': Operation not applicable
+ fail=1
+ cp -a --parents sym/b/c g
cp: preserving permissions for 'g/sym/b/c': Operation not applicable
cp: preserving permissions for 'g/sym/b': Operation not applicable

The code that results in this error in in lib/qcopy-acl.c:
# ifdef ACE_GETACL
  if (ace_count > 0)
    {
      ret = (dest_desc != -1
             ? facl (dest_desc, ACE_SETACL, ace_count, ace_entries)
             : acl (dst_name, ACE_SETACL, ace_count, ace_entries));
      if (ret < 0 && saved_errno == 0)
        {
          saved_errno = errno;
          if ((errno == ENOSYS || errno == EINVAL || errno == ENOTSUP)
              && !acl_ace_nontrivial (ace_count, ace_entries))
            saved_errno = 0;
        }
    }
  free (ace_entries);
# endif

The error returned is ENOSYS, but acl_ace_nontrivial fires and thus
the saved_errno isn't reset to 0.

The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
      switch ((access_masks[0] | access_masks[1])
              & ~(NEW_ACE_READ_NAMED_ATTRS
                  | NEW_ACE_READ_ATTRIBUTES
                  | NEW_ACE_READ_ACL
                  | NEW_ACE_SYNCHRONIZE))
        {
        case 0:
        case NEW_ACE_READ_DATA:
        case                     NEW_ACE_WRITEA_DATA:
        case NEW_ACE_READ_DATA | NEW_ACE_WRITEA_DATA:
        case                                           NEW_ACE_EXECUTE:
        case NEW_ACE_READ_DATA |                       NEW_ACE_EXECUTE:
        case                     NEW_ACE_WRITEA_DATA | NEW_ACE_EXECUTE:
        case NEW_ACE_READ_DATA | NEW_ACE_WRITEA_DATA | NEW_ACE_EXECUTE:
          break;
        default:
          return 1;
        }


It seems as though the $getacl calls succeed but $setacl calls fail.
We are able to retrieve what we consider complex acl information but
cannot subsequently set it.

You can see similar behaviour by doing:

$ pwd
/tmp/coreutils-8.22

$ getfacl README

# file: README
# owner: bwalton
# group: csw
user::rw-
group::r--              #effective:r--
mask:rwx
other:r--

$ getfacl README | setfacl -f - README
README: failed to set acl entries
setacl error: Operation not applicable

Other than this issue, which affects 6 tests identically, all tests pass.

I'm not sure what the best way to fix this is. I'm happy to supply
complete test logs if they'd help and will run any commands/gather any
additional info you need.

(Note: I'm only running this in /tmp to isolate some other issues that
seem to be nfs related - I'll report on those separately when I've
debugged far enough to provide something useful.)

Thanks
-Ben
-- 
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself.  Much more happiness,
truth, beauty and wisdom will come to you that way.

-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------

Message #8 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 17669 <at> debbugs.gnu.org
Cc: 17664-done <at> debbugs.gnu.org
Subject: Fwd: Re: Solaris acl woes
Date: Mon, 02 Jun 2014 10:44:57 -0700

[Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled it 
under 17664; closing 17664.]

-------- Original Message --------
Subject: 	Re: Solaris acl woes
Date: 	Mon, 02 Jun 2014 06:56:03 -0700
From: 	Paul Eggert <eggert <at> cs.ucla.edu>
Organization: 	UCLA Computer Science Department
To: 	Ben Walton <bdwalton <at> gmail.com>, bug-gnulib <at> gnu.org, 
bug-coreutils <at> gnu.org



Ben Walton wrote:

> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:

Why is it returning 1, exactly?  What are the value of access_masks[0,
1] and how do they compare to the masks, and what bits are set that
shouldn't be if we want the ACLs to be trivial?

Message #11 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Ben Walton <bdwalton <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17664-done <at> debbugs.gnu.org, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Tue, 3 Jun 2014 07:51:20 +0100

[Message part 1 (text/plain, inline)]

On Jun 2, 2014 6:46 PM, "Paul Eggert" <eggert <at> cs.ucla.edu> wrote:
>
> [Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled it
under 17664; closing 17664.]
>
> -------- Original Message --------
> Subject:        Re: Solaris acl woes
> Date:   Mon, 02 Jun 2014 06:56:03 -0700
> From:   Paul Eggert <eggert <at> cs.ucla.edu>
> Organization:   UCLA Computer Science Department
> To:     Ben Walton <bdwalton <at> gmail.com>, bug-gnulib <at> gnu.org,
bug-coreutils <at> gnu.org
>
>
>
> Ben Walton wrote:
>
>> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
>
>
> Why is it returning 1, exactly?  What are the value of access_masks[0,
> 1] and how do they compare to the masks, and what bits are set that
> shouldn't be if we want the ACLs to be trivial?

I didn't get back to this yesterday but will tonight.

What do you think about the fact that the Solaris tools seem to exhibit the
same behavior?

Thanks
-Ben

[Message part 2 (text/html, inline)]

Message #14 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ben Walton <bdwalton <at> gmail.com>
Cc: 17664-done <at> debbugs.gnu.org, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17664: bug#17669: Fwd: Re: Solaris acl woes
Date: Tue, 03 Jun 2014 00:02:23 -0700

Ben Walton wrote:
> What do you think about the fact that the Solaris tools seem to exhibit the
> same behavior?

If they do this too, then I guess we're in good company.

Message #17 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Ben Walton <bdwalton <at> gmail.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Tue, 03 Jun 2014 11:22:36 +0100

On 06/03/2014 07:51 AM, Ben Walton wrote:
> On Jun 2, 2014 6:46 PM, "Paul Eggert" <eggert <at> cs.ucla.edu> wrote:
>>
>> [Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled it
> under 17664; closing 17664.]
>>
>> -------- Original Message --------
>> Subject:        Re: Solaris acl woes
>> Date:   Mon, 02 Jun 2014 06:56:03 -0700
>> From:   Paul Eggert <eggert <at> cs.ucla.edu>
>> Organization:   UCLA Computer Science Department
>> To:     Ben Walton <bdwalton <at> gmail.com>, bug-gnulib <at> gnu.org,
> bug-coreutils <at> gnu.org
>>
>>
>>
>> Ben Walton wrote:
>>
>>> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
>>
>>
>> Why is it returning 1, exactly?  What are the value of access_masks[0,
>> 1] and how do they compare to the masks, and what bits are set that
>> shouldn't be if we want the ACLs to be trivial?
> 
> I didn't get back to this yesterday but will tonight.
> 
> What do you think about the fact that the Solaris tools seem to exhibit the
> same behavior?

I'd probably adjust the tests to first:

getfacl test.acl | setfacl -f - test.acl || skip_ "system is unable to copy ACLs"

thanks,
Pádraig

Message #20 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Ben Walton <bdwalton <at> gmail.com>
Cc: 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Tue, 03 Jun 2014 09:21:40 -0700

On 06/03/2014 03:22 AM, Pádraig Brady wrote:
> I'd probably adjust the tests to first:
>
> getfacl test.acl | setfacl -f - test.acl || skip_ "system is unable to copy ACLs"

Good idea.  +1 and all that.

Message #23 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Ben Walton <bdwalton <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Tue, 3 Jun 2014 19:07:05 +0100

[Message part 1 (text/plain, inline)]

On Jun 3, 2014 11:22 AM, "Pádraig Brady" <P <at> draigbrady.com> wrote:
>
> On 06/03/2014 07:51 AM, Ben Walton wrote:
> > On Jun 2, 2014 6:46 PM, "Paul Eggert" <eggert <at> cs.ucla.edu> wrote:
> >>
> >> [Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled
it
> > under 17664; closing 17664.]
> >>
> >> -------- Original Message --------
> >> Subject:        Re: Solaris acl woes
> >> Date:   Mon, 02 Jun 2014 06:56:03 -0700
> >> From:   Paul Eggert <eggert <at> cs.ucla.edu>
> >> Organization:   UCLA Computer Science Department
> >> To:     Ben Walton <bdwalton <at> gmail.com>, bug-gnulib <at> gnu.org,
> > bug-coreutils <at> gnu.org
> >>
> >>
> >>
> >> Ben Walton wrote:
> >>
> >>> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
> >>
> >>
> >> Why is it returning 1, exactly?  What are the value of access_masks[0,
> >> 1] and how do they compare to the masks, and what bits are set that
> >> shouldn't be if we want the ACLs to be trivial?
> >
> > I didn't get back to this yesterday but will tonight.
> >
> > What do you think about the fact that the Solaris tools seem to exhibit
the
> > same behavior?
>
> I'd probably adjust the tests to first:
>
> getfacl test.acl | setfacl -f - test.acl || skip_ "system is unable to
copy ACLs"
>

Not a bad idea, but those tools have different names on different systems
and possibly different calling conventions.

If this is a preferred approach, at the very least, a presence check for
the binary needs to wrap the precondition.

Thanks
-Ben

> thanks,
> Pádraig
>

[Message part 2 (text/html, inline)]

Message #26 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Ben Walton <bdwalton <at> gmail.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Tue, 03 Jun 2014 19:27:04 +0100

On 06/03/2014 07:07 PM, Ben Walton wrote:
> 
> On Jun 3, 2014 11:22 AM, "Pádraig Brady" <P <at> draigbrady.com <mailto:P <at> draigbrady.com>> wrote:
>>
>> On 06/03/2014 07:51 AM, Ben Walton wrote:
>> > On Jun 2, 2014 6:46 PM, "Paul Eggert" <eggert <at> cs.ucla.edu <mailto:eggert <at> cs.ucla.edu>> wrote:
>> >>
>> >> [Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled it
>> > under 17664; closing 17664.]
>> >>
>> >> -------- Original Message --------
>> >> Subject:        Re: Solaris acl woes
>> >> Date:   Mon, 02 Jun 2014 06:56:03 -0700
>> >> From:   Paul Eggert <eggert <at> cs.ucla.edu <mailto:eggert <at> cs.ucla.edu>>
>> >> Organization:   UCLA Computer Science Department
>> >> To:     Ben Walton <bdwalton <at> gmail.com <mailto:bdwalton <at> gmail.com>>, bug-gnulib <at> gnu.org <mailto:bug-gnulib <at> gnu.org>,
>> > bug-coreutils <at> gnu.org <mailto:bug-coreutils <at> gnu.org>
>> >>
>> >>
>> >>
>> >> Ben Walton wrote:
>> >>
>> >>> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
>> >>
>> >>
>> >> Why is it returning 1, exactly?  What are the value of access_masks[0,
>> >> 1] and how do they compare to the masks, and what bits are set that
>> >> shouldn't be if we want the ACLs to be trivial?
>> >
>> > I didn't get back to this yesterday but will tonight.
>> >
>> > What do you think about the fact that the Solaris tools seem to exhibit the
>> > same behavior?
>>
>> I'd probably adjust the tests to first:
>>
>> getfacl test.acl | setfacl -f - test.acl || skip_ "system is unable to copy ACLs"
>>
> 
> Not a bad idea, but those tools have different names on different systems and possibly different calling conventions.
> 
> If this is a preferred approach, at the very least, a presence check for the binary needs to wrap the precondition.

We already have that in require_acl_
Though yes it's very awkward that there is no standard here.
This is how one copies ACLs on the systems I've just checked:

solaris: getfacl file1 | setfacl -f - file2
linux:   getfacl file1 | setfacl --set-file=- file2
freebsd: getfacl file1 | setfacl -b -n -M - file2

So not ideal at all.

Which 6 tests did this affect BTW?

thanks,
Pádraig

Message #29 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Ben Walton <bdwalton <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Tue, 3 Jun 2014 21:25:06 +0100

On Tue, Jun 3, 2014 at 7:27 PM, Pádraig Brady <P <at> draigbrady.com> wrote:
> On 06/03/2014 07:07 PM, Ben Walton wrote:
>>
>> On Jun 3, 2014 11:22 AM, "Pádraig Brady" <P <at> draigbrady.com <mailto:P <at> draigbrady.com>> wrote:
>>>
>>> On 06/03/2014 07:51 AM, Ben Walton wrote:
>>> > On Jun 2, 2014 6:46 PM, "Paul Eggert" <eggert <at> cs.ucla.edu <mailto:eggert <at> cs.ucla.edu>> wrote:
>>> >>
>>> >> [Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled it
>>> > under 17664; closing 17664.]
>>> >>
>>> >> -------- Original Message --------
>>> >> Subject:        Re: Solaris acl woes
>>> >> Date:   Mon, 02 Jun 2014 06:56:03 -0700
>>> >> From:   Paul Eggert <eggert <at> cs.ucla.edu <mailto:eggert <at> cs.ucla.edu>>
>>> >> Organization:   UCLA Computer Science Department
>>> >> To:     Ben Walton <bdwalton <at> gmail.com <mailto:bdwalton <at> gmail.com>>, bug-gnulib <at> gnu.org <mailto:bug-gnulib <at> gnu.org>,
>>> > bug-coreutils <at> gnu.org <mailto:bug-coreutils <at> gnu.org>
>>> >>
>>> >>
>>> >>
>>> >> Ben Walton wrote:
>>> >>
>>> >>> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
>>> >>
>>> >>
>>> >> Why is it returning 1, exactly?  What are the value of access_masks[0,
>>> >> 1] and how do they compare to the masks, and what bits are set that
>>> >> shouldn't be if we want the ACLs to be trivial?
>>> >
>>> > I didn't get back to this yesterday but will tonight.
>>> >
>>> > What do you think about the fact that the Solaris tools seem to exhibit the
>>> > same behavior?
>>>
>>> I'd probably adjust the tests to first:
>>>
>>> getfacl test.acl | setfacl -f - test.acl || skip_ "system is unable to copy ACLs"
>>>
>>
>> Not a bad idea, but those tools have different names on different systems and possibly different calling conventions.
>>
>> If this is a preferred approach, at the very least, a presence check for the binary needs to wrap the precondition.
>
> We already have that in require_acl_
> Though yes it's very awkward that there is no standard here.
> This is how one copies ACLs on the systems I've just checked:
>
> solaris: getfacl file1 | setfacl -f - file2
> linux:   getfacl file1 | setfacl --set-file=- file2
> freebsd: getfacl file1 | setfacl -b -n -M - file2
>
> So not ideal at all.

Ok, let me see what I can bang together. I vaguely recall seeing other
code that was doing something along these lines so I might be able to
find a useful reference to start from.

>
> Which 6 tests did this affect BTW?

FAIL: tests/cp/backup-dir
  cp -a
FAIL: tests/cp/cp-parents
  cp -a
FAIL: tests/cp/parent-perm-race
  cp --preserve=mode
FAIL: tests/cp/preserve-link
  cp -a
FAIL: tests/cp/reflink-perm
  cp --preserve
FAIL: tests/cp/src-base-dot
  cp -a

Thanks
-Ben
-- 
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself.  Much more happiness,
truth, beauty and wisdom will come to you that way.

-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------

Message #32 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Pádraig Brady <P <at> draigbrady.com>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Fri, 19 Oct 2018 21:30:15 -0600

(triaging old bugs)

Hello,

This bug ( https://bugs.gnu.org/17669 ) deals
with ACL test failures on Solaris for coreutils 8.22 .

Shortly after the release of 8.22 (but few months before this
bug was submitted), Bernard pushed this:

----
commit 5d7591d0edf0dd31c2daa195ee766c1383b89f4c
Author: Bernhard Voelker <mail <at> bernhard-voelker.de>
Date:   Fri Jan 10 16:48:25 2014 +0100

 tests: improve test for a working setfacl
 Prompted by a test framework failure of tests/mkdir/p-acl.sh on armv7l:
 The previous test for a working setfacl was not sufficient in some
 circumstances.
----

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5d7591d0edf0dd31c2daa195ee766c1383b89f4c


Is that by any chance solve the problem ?
(is this even still a problem?)


regards,
 - assaf

Message #35 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Pádraig Brady <P <at> draigbrady.com>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Sat, 20 Oct 2018 19:41:50 +0200

On 10/20/18 5:30 AM, Assaf Gordon wrote:
> (triaging old bugs)
> 
> Hello,
> 
> This bug ( https://bugs.gnu.org/17669 ) deals
> with ACL test failures on Solaris for coreutils 8.22 .
> 
> Shortly after the release of 8.22 (but few months before this
> bug was submitted), Bernard pushed this:
> 
> ----
> commit 5d7591d0edf0dd31c2daa195ee766c1383b89f4c
> Author: Bernhard Voelker <mail <at> bernhard-voelker.de>
> Date:   Fri Jan 10 16:48:25 2014 +0100
> 
>   tests: improve test for a working setfacl
>   Prompted by a test framework failure of tests/mkdir/p-acl.sh on armv7l:
>   The previous test for a working setfacl was not sufficient in some
>   circumstances.
> ----
> 
> https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5d7591d0edf0dd31c2daa195ee766c1383b89f4c
> 
> 
> Is that by any chance solve the problem ?

yes, possibly, although 'require_setfacl_' does not use different
setfacl/getfacl syntax for Solaris/*BSD.

> (is this even still a problem?)

sorry, I don't have a Solaris system here, and your CFARM doesn't have
xattr-devel installed.

Thanks & have a nice day,
Berny

Message #38 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Assaf Gordon <assafgordon <at> gmail.com>
Cc: Pádraig Brady <P <at> draigbrady.com>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Sat, 20 Oct 2018 16:12:59 -0700

Bernhard Voelker wrote:
>> Is that by any chance solve the problem ?
> yes, possibly, although 'require_setfacl_' does not use different
> setfacl/getfacl syntax for Solaris/*BSD.

It does not fix the problem. I just now built the development coreutils 
(8.30.19-8ea92) on Solaris 10 sparc with GCC 3.4.3 
(csl-sol210-3_4-branch+sol_rpath) in a /tmp swap filesystem, and 'make check' 
had problems with:

tests/cp/preserve-2
tests/cp/preserve-link
tests/cp/reflink-perm
tests/cp/src-base-dot
tests/id/zero
tests/mv/dup-source
tests/mv/part-fail
tests/mv/part-symlink

Message #45 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Assaf Gordon <assafgordon <at> gmail.com>
Cc: Pádraig Brady <P <at> draigbrady.com>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Mon, 22 Oct 2018 22:57:36 +0200

On 10/21/18 1:12 AM, Paul Eggert wrote:
> Bernhard Voelker wrote:
>>> Is that by any chance solve the problem ?
>> yes, possibly, although 'require_setfacl_' does not use different
>> setfacl/getfacl syntax for Solaris/*BSD.
> 
> It does not fix the problem. I just now built the development coreutils 
> (8.30.19-8ea92) on Solaris 10 sparc with GCC 3.4.3 
> (csl-sol210-3_4-branch+sol_rpath) in a /tmp swap filesystem, and 'make check' 
> had problems with:
> 
> tests/cp/preserve-2
> tests/cp/preserve-link
> tests/cp/reflink-perm
> tests/cp/src-base-dot
> tests/id/zero
> tests/mv/dup-source
> tests/mv/part-fail
> tests/mv/part-symlink

Would you mind attaching the 'test-suite.log' (maybe categorized,
e.g. the failure in tests/id/zero is probably unrelated to the others),
so that we have a chance to squash each issue one after another?

Thanks & Have a nice day,
Berny

Message #48 received at 17669 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Assaf Gordon <assafgordon <at> gmail.com>
Cc: Pádraig Brady <P <at> draigbrady.com>, 17669 <at> debbugs.gnu.org
Subject: Re: bug#17669: Fwd: Re: Solaris acl woes
Date: Mon, 22 Oct 2018 16:18:06 -0700

[Message part 1 (text/plain, inline)]

On 10/22/18 1:57 PM, Bernhard Voelker wrote:
> Would you mind attaching the 'test-suite.log' (maybe categorized,
> e.g. the failure in tests/id/zero is probably unrelated to the others),
> so that we have a chance to squash each issue one after another?

Sure, compressed tarball of logs attached.

[coreutils-tests.tar.gz (application/gzip, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.