Bug 1257152

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.

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

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.

(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" ;-)

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