This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1257152 - coreutils fails to rebuild as root
coreutils fails to rebuild as root
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: coreutils (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ondrej Vasik
qe-baseos-daemons
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-26 07:33 EDT by Karel Volný
Modified: 2015-09-04 03:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-02 13:44:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2015-08-26 07:33:44 EDT
Description of problem:
Trying to rebuild coreutils as root, I'm getting failure on all systems.

Version-Release number of selected component (if applicable):
coreutils-8.22-14.el7.src.rpm

How reproducible:
always

Steps to Reproduce:
1. # rpmbuild --rebuild coreutils-8.22-14.el7.src.rpm

Actual results:
...
checking whether mknod can create fifo without root privileges... configure: error: in `/usr/src/redhat/BUILD/coreutils-8.22':
configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)
See `config.log' for more details
+ :
+ touch man/arch.x man/base64.x man/basename.x man/cat.x man/chcon.x man/chgrp.x man/chmod.x man/chown.x man/chroot.x man/cksum.x man/comm.x man/cp.x man/csplit.x man/cut.x man/date.x man/dd.x man/df.x man/dir.x man/dircolors.x man/dirna
me.x man/du.x man/echo.x man/env.x man/expand.x man/expr.x man/factor.x man/false.x man/fmt.x man/fold.x man/groups.x man/head.x man/hostid.x man/hostname.x man/id.x man/install.x man/join.x man/kill.x man/link.x man/ln.x man/logname.x m
an/ls.x man/md5sum.x man/mkdir.x man/mkfifo.x man/mknod.x man/mktemp.x man/mv.x man/nice.x man/nl.x man/nohup.x man/nproc.x man/numfmt.x man/od.x man/paste.x man/pathchk.x man/pinky.x man/pr.x man/printenv.x man/printf.x man/ptx.x man/pw
d.x man/readlink.x man/realpath.x man/rm.x man/rmdir.x man/runcon.x man/seq.x man/sha1sum.x man/sha224sum.x man/sha256sum.x man/sha384sum.x man/sha512sum.x man/shred.x man/shuf.x man/sleep.x man/sort.x man/split.x man/stat.x man/stdbuf.x
 man/stty.x man/sum.x man/sync.x man/tac.x man/tail.x man/tee.x man/test.x man/timeout.x man/touch.x man/tr.x man/true.x man/truncate.x man/tsort.x man/tty.x man/uname.x man/unexpand.x man/uniq.x man/unlink.x man/uptime.x man/users.x man
/vdir.x man/wc.x man/who.x man/whoami.x man/yes.x
+ make all -j2
There seems to be no Makefile in this directory.
You must run ./configure before running 'make'.
make: *** [abort-due-to-no-makefile] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.A6bvwd (%build)
...


Expected results:
no such errors

Additional info:
note that the rebuild might need to be run as root because some tests need root permissions
Comment 2 Ondrej Vasik 2015-08-26 08:55:37 EDT
Sorry, rpmbuild and builds generally are not meant to be run as a root. We need to run configure. If you read the error message, you will see you can actually get through the error via setting environment variable. Not a good default, though. Therefore closing NOTABUG.
Comment 3 Karel Volný 2015-09-02 11:06:35 EDT
(In reply to Ondrej Vasik from comment #2)
> Sorry, rpmbuild and builds generally are not meant to be run as a root.

okay, but then ...

> We need to run configure. If you read the error message, you will see you can
> actually get through the error via setting environment variable. Not a good
> default, though. Therefore closing NOTABUG.

1) would you consider changing this to RFE (reopening for that ...) to modify the specfile to fail more gracefully, right at the begining, instead of letting it to bail out in the middle of configure? - see e.g. bug #1035340 for inspiration

2) as mentioned, not running as root means some tests are skipped - but the testsuite is not packaged to allow to run that outside of package rebuild ... so we are losing some tests that may be important

do you think that a -tests subpackage could be created so that tests can be run as root and on installed binaries, rather than during rebuild with 'FORCE_UNSAFE_CONFIGURE=1' set?
Comment 4 Ondrej Vasik 2015-09-02 13:44:59 EDT
1) There is a difference... in the case of #1035340, just testsuite is skipped - in the case of coreutils, we need to run configure. I consider error message saying what you need to activate in environment "friendly enough" for non-default workflow.

2) This is flaw in your workflow. Build package as non-root and then run make check as a root to get root tests executed, set envvar for RUN_VERY_EXPENSIVE_TESTS=yes and/or RUN_EXPENSIVE_TESTS=yes to execute expensive tests from upstream testsuite (root and expensive tests are not executed at the build time). There are several more things to reduce number of skipped tests. Actually - there is already a test covering it.

Ad -tests subpackage: No, I don't think this make sense. As I said, QE already has this test based on my https://bugzilla.redhat.com/show_bug.cgi?id=674094 .

Please do not reopen again.
Comment 5 Karel Volný 2015-09-03 08:06:54 EDT
(In reply to Ondrej Vasik from comment #4)
> 1) There is a difference... in the case of #1035340, just testsuite is
> skipped - in the case of coreutils, we need to run configure. I consider
> error message saying what you need to activate in environment "friendly
> enough" for non-default workflow.

IMHO this difference doesn't matter - the important part is that package rebuild just doesn't pass, and so it doesn't make any sense to let it go any further than to userid and environment check

from that POV, the user doesn't care if it bails out in %build or in %check, the interesting thing is only that _something_ has to be set so the whole rebuild passes

> 2) This is flaw in your workflow. Build package as non-root and then run
> make check as a root to get root tests executed, set envvar for
> RUN_VERY_EXPENSIVE_TESTS=yes and/or RUN_EXPENSIVE_TESTS=yes to execute
> expensive tests from upstream testsuite (root and expensive tests are not
> executed at the build time). There are several more things to reduce number
> of skipped tests. Actually - there is already a test covering it.

um, seems I was extremely bad at expressing my point again ...

building the package on our own and running the tests on it is less than optimal, because these are not the bits that Red Hat is going to sign and distribute ... the compiler version will usually differ from what is available in Brew etc.

and the code is not tested (by this subset of tests) in Brew as Brew doesn't run the rebuild as root

but -

> Ad -tests subpackage: No, I don't think this make sense. As I said, QE
> already has this test based on my
> https://bugzilla.redhat.com/show_bug.cgi?id=674094 .

after all, seems you're right (at least for our workflow; and if there's no customer demand ...)

our test ( /CoreOS/coreutils/Regression/bz663055-automate-coreutils-internal-testsuite ) cheats, and after compiling the package, it simply links the actual installed binaries over those created during package recompilation, so it _does_ test the bits that Red Hat distributes

which shifts the existence of -tests subpackage from "really nice to have" to "if all important problems of humankind are solved, we can look also into this one" ;-)
Comment 6 Ondrej Vasik 2015-09-04 03:59:38 EDT
(In reply to Karel Volný from comment #5)
> (In reply to Ondrej Vasik from comment #4)
> > 1) There is a difference... in the case of #1035340, just testsuite is
> > skipped - in the case of coreutils, we need to run configure. I consider
> > error message saying what you need to activate in environment "friendly
> > enough" for non-default workflow.
> 
> IMHO this difference doesn't matter - the important part is that package
> rebuild just doesn't pass, and so it doesn't make any sense to let it go any
> further than to userid and environment check
> from that POV, the user doesn't care if it bails out in %build or in %check,
> the interesting thing is only that _something_ has to be set so the whole
> rebuild passes

It does matter - in the case of above mentioned bz, unimportant part of build is skipped. In my case, I would need to enable potentially dangerous envvar for whole build. Sorry - no go for me.

You can set this variable in your environment, if you really want this - but this is not good default even for root build - as I really think root build should fail here.

> > 2) This is flaw in your workflow. Build package as non-root and then run
> > make check as a root to get root tests executed, set envvar for
> > RUN_VERY_EXPENSIVE_TESTS=yes and/or RUN_EXPENSIVE_TESTS=yes to execute
> > expensive tests from upstream testsuite (root and expensive tests are not
> > executed at the build time). There are several more things to reduce number
> > of skipped tests. Actually - there is already a test covering it.
> 
> um, seems I was extremely bad at expressing my point again ...
> 
> building the package on our own and running the tests on it is less than
> optimal, because these are not the bits that Red Hat is going to sign and
> distribute ... the compiler version will usually differ from what is
> available in Brew etc.
> 
> and the code is not tested (by this subset of tests) in Brew as Brew doesn't
> run the rebuild as root
> 
> but -
> 
> > Ad -tests subpackage: No, I don't think this make sense. As I said, QE
> > already has this test based on my
> > https://bugzilla.redhat.com/show_bug.cgi?id=674094 .
> 
> after all, seems you're right (at least for our workflow; and if there's no
> customer demand ...)
> 
> our test (
> /CoreOS/coreutils/Regression/bz663055-automate-coreutils-internal-testsuite
> ) cheats, and after compiling the package, it simply links the actual
> installed binaries over those created during package recompilation, so it
> _does_ test the bits that Red Hat distributes
> 
> which shifts the existence of -tests subpackage from "really nice to have"
> to "if all important problems of humankind are solved, we can look also into
> this one" ;-)

Yes, thanks. Actually for shipping test subpackage, it would require to do some wrapper to do similar hacks as are done in the internal script that runs testsuite with red hat shipped binaries.

Note You need to log in before you can comment on or make changes to this bug.