[Top][All Lists]

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

[Emacs-bug-tracker] bug#8244: closed (Test failures in coreutils 8.10)

From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#8244: closed (Test failures in coreutils 8.10)
Date: Wed, 16 Mar 2011 05:55:02 +0000

Your message dated Wed, 16 Mar 2011 06:54:07 +0100
with message-id <address@hidden>
and subject line Re: bug#8244: Test failures in coreutils 8.10
has caused the GNU bug report #8244,
regarding Test failures in coreutils 8.10
to be marked as done.

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

8244: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8244
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Please report to address@hidden Date: Sun, 13 Mar 2011 19:08:31 +0300
This happend at stage:

6.22. Coreutils-8.10

The Coreutils package contains utilities for showing and setting the basic system characteristics.

Approximate build time: 3.2 SBU
Required disk space: 99 MB

6.22.1. Installation of Coreutils

A known issue with the uname program from this package is that the -p switch always returns unknown. The following patch fixes this behavior for Intel architectures:

case `uname -m` in
i?86 | x86_64) patch -Np1 -i ../coreutils-8.10-uname-1.patch ;;

POSIX requires that programs from Coreutils recognize character boundaries correctly even in multibyte locales. The following patch fixes this non-compliance and other internationalization-related bugs:

patch -Np1 -i ../coreutils-8.10-i18n-1.patch


In the past, many bugs were found in this patch. When reporting new bugs to Coreutils maintainers, please check first if they are reproducible without this patch.

Now prepare Coreutils for compilation:

./configure --prefix=/usr \

The meaning of the configure options:


The purpose of this switch is to prevent Coreutils from installing binaries that will be installed by other packages later.

Compile the package:


Skip down to “Install the package” if not running the test suite.

Now the test suite is ready to be run. First, run the tests that are meant to be run as user root:

make NON_ROOT_USERNAME=nobody check-root

Attachment: test-suite.log
Description: Text Data

--- End Message ---
--- Begin Message --- Subject: Re: bug#8244: Test failures in coreutils 8.10 Date: Wed, 16 Mar 2011 06:54:07 +0100
Pádraig Brady wrote:
> FAIL: misc/chroot-credentials (exit: 1)
> FAIL: misc/truncate-owned-by-other (exit: 1)
> FAIL: mv/sticky-to-xpart (exit: 1)
> FAIL: rm/no-give-up (exit: 1)
> FAIL: touch/now-owned-by-other (exit: 1)
> FAIL: cp/special-bits (exit: 1)
> The above 6 are all due to the same issue,
> that the "nobody" user is not allowed to execute stuff,
> as demonstrated by this in one of the tests:
> $ chroot --userspec=nobody:99 / whoami
> chroot: failed to run command `whoami': Permission denied
> This seems unusual to me.
> It will help us decide if we need to skip these tests in this case,
> if you could detail the credentials on your system preventing
> "nobody" from executing these programs.

That is typically what happens when you run "sudo make check-root"
without setting NON_ROOT_USERNAME as suggested in README:

    Running tests as root:

    If you run the tests as root, note that a few of them create files
    and/or run programs as a non-root user, `nobody' by default.
    If you want to use some other non-root username, specify it via
    the NON_ROOT_USERNAME environment variable.  Depending on the
    permissions with which the working directories have been created,
    using `nobody' may fail, because that user won't have the required
    read and write access to the build and test directories.
    I find that it is best to unpack and build as a non-privileged
    user, and then to run the following command as that user in order
    to run the privilege-requiring tests:

      sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root

    If you can run the tests as root, please do so and report any
    problems.  We get much less test coverage in that mode, and it's
    arguably more important that these tools work well when run by
    root than when run by less privileged users.

I've marked this issue as closed,
but if you have additional comments or reason
to think it should not be closed, feel free to
continue the discussion and/or reopen the issue.

--- End Message ---

reply via email to

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