[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#14024: closed (Test failure in coreutils 8.13)

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#14024: closed (Test failure in coreutils 8.13)
Date: Fri, 12 Apr 2013 22:02:02 +0000

Your message dated Fri, 12 Apr 2013 22:57:36 +0100
with message-id <address@hidden>
and subject line Re: bug#14024: Test failure in coreutils 8.13
has caused the debbugs.gnu.org bug report #14024,
regarding Test failure in coreutils 8.13
to be marked as done.

(If you believe you have received this mail in error, please contact

14024: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14024
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Test failure in coreutils 8.13 Date: Thu, 21 Mar 2013 16:55:14 +0000
        Test failure in coreutils 8.13

To: <address@hidden>

1 Background

The release used was NOT the latest, so it is quite likely that these matters
have been previously addressed.  On the other hand, it is possible that
installation has not been attempted for this actual Unix version.

Running Mac OS X:

  System Version:       Mac OS X 10.5.8 (9L30)
  Kernel Version:       Darwin 9.8.0
  >uname -mpv
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386

        The reason for installing 8.13 was that version 8.21 from the ftp area
(ftp://ftp.gnu.org/gnu/coreutils/) was an xz version and there seemed to be
no support for that format on this machine.  The latest gz was 8.13 from
Sep 2011, so also downloaded version 8.13, and proceeded to install this.

        This problem was formerly included in bug#13912, but has now been
split off from other topics covered there.

2 An error reported by make check.

        Tried `make check'.  Ran to completion, recording one failure

  FAIL: install/install-C

There was also a log in tests/test-suite.log, but it seemed to be removed later
by make clean.

        The `make installcheck' has not been done.  If it is of help to you,
then this can be done, or partially done, to identify the exact failure.

3 Test failure reported in README

        There is a test failure in 'make check' reported in README concerning
Mac OS X 10.5.1 (Darwin 9.1). This concerns ACL support, and suggests using

        This machine has Mac OS X 10.5.8 (Darwin 9.8.0).  The 'make check' was
performed without having done --disable-acl, but the "numerous failures" stated did not arise, although there was one error (see previous section). The tests were done as a normal user (not root), but having the privilege to use sudo (not used at this point). It is not clear whether or not the FAIL above was one of those
with Darwin 9.1.

        The different effect for this Mac version might or might not be of
relevance to Gnu developers!

4 Conclusion

The config.log file is available (5.3MB), plus config.status (96kB). There is also a file from redirecting standard output during the run of configure (60kB).

        If extra information about the matters reported above would be of
value please contact:


Ellis N. Thomas/21-Mar-2013

--- End Message ---
--- Begin Message --- Subject: Re: bug#14024: Test failure in coreutils 8.13 Date: Fri, 12 Apr 2013 22:57:36 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
On 04/12/2013 10:30 PM, Ellis N. Thomas wrote:
> On 12 Apr 2013, at 02:37, Pádraig Brady wrote:
>> Great thanks.
>> That shows that the gid of the files is 80, which I presume is
>> separate to your gid. That can happen if you're in a dir hierarchy
>> that's g+s to a group other than your own.
>> Hmm I see the test already detects this case and skips the test
>> with skip_if_setgid_(). Perhaps POSIX default ACLs or something are
>> setting this admin group for you?
>> Can you confirm that the dir isn't setgid by showing the output of:
>> /usr/local/bin/stat .
>> Can you display ACLs with `getfacl .` ?
> Pádraig,
>     Following your points below about groups, I checked the owner/groups
> of the various directories where I variously ran and repeated the coreutils 
> tests
> and did sequences for you like:
> echo test > a
> /usr/local/bin/install -Cv -m0644 a b
> /usr/local/bin/stat a b
> /usr/local/bin/install -Cv -m0644 a b
>     I now see why my latest ones gave different results from the earlier ones,
> and why the earlier ones did not seem to match the reported test failures.
>     The earlier sequences were run in my own directory ~/tmp, so that the 
> files
> a and b were in a temporary directory.  However, the latest ones, that 
> responded
> with:
>     removed 'b'
>     'a' -> 'b'
> were run where I had just rerun the
>     "make check TESTS=tests/install/install-C.sh VERBOSE=yes SUBDIRS=."
> which is /Gnu/coreutils/coreutils-8.21.  This dir hierarchy is not g+s to a 
> group other than
> my own, but does have group values that are not my own.  There do not seem to 
> be ACLs
> on these directories, but some have "extended attributes".
>     I was not able to use getfacl on this system, but ls -e shows ACLs, and 
> if the file or
> directory has extended security information, the permissions field printed by 
> the -l option
> is followed by a '+' character (from man ls).
>     My user on this iMac has Administrator privileges, which in practice 
> means that
> it is in group 'admin', and several other groups.  These users have the 
> ability to create
> "top-level" directories, like /Gnu.  This ability seems to arise because '/' 
> has group
> 'admin', and the created directories do too, but are owned by the creator 
> (the result
> seems to be the same whether the directory is created by a Unix mkdir, or 
> using the
> Mac gui Finder application):
> ls -Ald@ / /Gnu /Gnu/coreutils/ /Gnu/coreutils/coreutils-8.21
> drwxrwxr-t  45 root          admin  1598 Apr 12 20:40 /
> drwxrwxr-x  12 admin         admin   408 Feb 16 12:12 /Gnu
> drwxr-xr-x  11 ellisnthomas  admin   374 Apr 12 20:42 /Gnu/coreutils/
> drwxr-xr-x@ 57 ellisnthomas  admin  1938 Apr 11 15:27 
> /Gnu/coreutils/coreutils-8.21
>         com.apple.quarantine      78
>     (I am not clear what this extended attribute does.  It seems related to 
> Mac regarding
> downloaded files with suspicion - the directory tree was originally extracted 
> from
> /Gnu/coreutils/coreutils-8.21.tar.gz)
>     In my own directories, the group is staff:
> ls -Ald ~
> drwxr-xr-x+ 53 ellisnthomas  staff  1802 Apr 12 20:04 /Users/ellisnthomas
> ls -Alde ~/tmp/ drwxr-xr-x 8 ellisnthomas staff 272 Mar 27 20:59 
> /Users/ellisnthomas/tmp/
>     To clarify the gids and uids I checked the groups, using dscacheutil
> (man says "dscacheutil does various operations against the Directory Service 
> cache
>      including gathering statistics, initiating lookups, inspection, cache
>      flush, etc.  This tool replaces most of the functionality of the lookupd
>      tool previously available
>  Darwin   Jan 14, 2007")
>     One aspect here is that there is both a user 'admin' and a group 'admin'.
> It seems that user admin created the directory /Gnu, but user ellisnthomas
> created /Gnu/coreutils/ later.
> dscacheutil -q group -a name admin
> name: admin
> password: *
> gid: 80
> users: root ellisnthomas admin
> dscacheutil -q group -a gid 20
> name: staff
> password: *
> gid: 20
> users: root ellisnthomas admin susanthomas
> dscacheutil -q user -a name ellisnthomas
> name: ellisnthomas
> password: ********
> uid: 501
> gid: 20
> dir: /Users/ellisnthomas
> shell: /bin/bash
> gecos: Ellis Thomas
> dscacheutil -q user -a name admin
> name: admin
> password: ********
> uid: 502
> gid: 20
> dir: /Users/admin
> shell: /bin/bash
> gecos: ExtraLeveLInSoftware
>     The usage of getfacl is not possible, but tried ls -e.
> type -a getfacl
> bash: type: getfacl: not found
> ls -Alde /Gnu/coreutils/coreutils-8.21
> drwxr-xr-x@ 57 ellisnthomas  admin  1938 Apr 11 15:27 
> /Gnu/coreutils/coreutils-8.21
> ls -Alde /Gnu/
> drwxrwxr-x  12 admin  admin  408 Feb 16 12:12 /Gnu/
> ls -Alde ~/tmp/
> drwxr-xr-x  8 ellisnthomas  staff  272 Mar 27 20:59 /Users/ellisnthomas/tmp/
> ls -Alde ~
> drwxr-xr-x+ 53 ellisnthomas  staff  1802 Apr 12 09:01 /Users/ellisnthomas
>  0: group:everyone deny delete
>     This seems to be the only one with an ACL.
>     So in summary it seems that install is seeing the two different groups:
> 'admin' in the existing 'a' file, and expecting to set 'staff' in the new 'b' 
> file
> as you suggested, but because the parent directory already has 'admin'
> without either the g+s or ACL involvement.
>     It seems it is now explained, anyway.

Thanks for the detail.
I'll probably work around that test failure with the attached.


Attachment: osx-install-C-skip.patch
Description: Text Data

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]