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

[GNU bug Tracking System]

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
address@hidden)


-- 
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 ;;
esac

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

Note

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 \
    --enable-no-install-program=kill,uptime

The meaning of the configure options:

--enable-no-install-program=kill,uptime

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

Compile the package:

make

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

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 ---