Am Dienstag, 23. Juli 2013, 22:12:21 schrieb Bernhard Voelker:

Hi *,

in the testsuite of the coreutils package, several tests are skipped because the 'abuild' user is only member of 1 group while these tests require the membership in at least 2 groups.

I want to enhance the test coverage of that basic package. Is there a way to tell OBS to add 'abuild' to a 2nd group?

No, but you could of course define an own test user with other groups in a different package and install that one during your build. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

* Bernhard Voelker (mail@bernhard-voelker.de) [20130805 15:06]:

Hmm, but chances are ~0 that such a package would be available to normal repos like Base:Build, Base:System or Factory, right?

Why? We have the testsuite package that nearly nobody will want to install, so why shoudn't we have a package which a test user? Philipp -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 08/05/2013 04:37 PM, Bernhard Voelker wrote:

On 08/05/2013 03:48 PM, Philipp Thomas wrote:

...

Why? We have the testsuite package that nearly nobody will want to install, so why shoudn't we have a package which a test user?

[...]

What I wanted is groupadd abuild2 usermod -a -G abuild2 abuild right before "make check-very-expensive" in the %check section.

Hmm, with both above sentences close to each other, I have the following idea: can I add the user to such a second group in the e.g. %post section of coreutils-testsuite, and then BuildReq:coreutils-testsuite to have that test environment in the following run? (Sounds like a little cycle, but maybe ...?) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Marcus Meissner writes:

and then run the testsuite in %check as %check is run after the package is installed into the system.

This would avoid loops.

But the testsuite logfile can no longer be packaged. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

* Bernhard Voelker (mail@bernhard-voelker.de) [20130807 10:00]:

I'm a bit confused now about the order of the %... sections. I have to test ...

The order is %build->%check->%install what probably confused Marcus is that we had a case where the whole %check section was inside an %ifdef block and this confused the BS. Philipp -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

* Andreas Schwab (schwab@suse.de) [20130807 12:35]:

No, it is %prep, %build, %install, %check, %clean.

OK, my wrong. But to answer Berny's question, it wouldn't matter for the testsuite package as even when check is run after install the test log is still packaged as the check section creates the compressed log and the %files section references it. Philipp -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Mittwoch, 7. August 2013, 12:58:33 schrieb Bernhard Voelker:

On 08/07/2013 12:43 PM, Philipp Thomas wrote:

...

* Andreas Schwab (schwab@suse.de) [20130807 12:35]:

...

No, it is %prep, %build, %install, %check, %clean.

OK, my wrong. But to answer Berny's question, it wouldn't matter for the testsuite package as even when check is run after install the test log is still packaged as the check section creates the compressed log and the %files section references it.

That means, that the %install section is the "official" way of getting root access during the RPM build in OBS? Just kidding. ;-)

Now, as I can add such a new group and user in %install (needed in %check), is there a way to guard these commands to only be executed in OBS/osc environment, i.e., to prevent this to be executed on real-world hosts where coreutils-testsuite is (accidentally) installed?

only packages building as root can do that in %install. We usually do not allow to build as root. Not because of security, but because it is a bad habbit and the src.rpms might be dangerous for users. So, just do not do it that way. There are documented ways to create users during package installation time.

Have a nice day, Berny

-- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Mittwoch, 7. August 2013, 14:35:01 schrieb Bernhard Voelker:

On 08/07/2013 01:18 PM, Adrian Schröter wrote:

...

So, just do not do it that way. There are documented ways to create users during package installation time.

Thanks. I think you refer to https://en.opensuse.org/Packaging/Users_And_Groups

But nonetheless, I'd prefer adding such a group only in the build environment, i.e., both in OBS and in local builds, but not during the installation on a user's host. Can I guard this?

Just do it via a second package which you do not publish. But build require for your package. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Am Mittwoch, 7. August 2013, 15:46:22 schrieb Bernhard Voelker:

On 08/07/2013 02:38 PM, Adrian Schröter wrote:

...

Just do it via a second package which you do not publish. But build require for your package.

Okay, thanks.

Here it is: https://build.opensuse.org/package/show/home:bernhard-voelker:branches:Base: System/coreutils-testsuite-env

But the testsuite fails with

buildinfo is broken... it says: unresolvable: nothing provides coreutils-testsuite-env

You have played with the "useforbuild" flags. The package is not available, when you disable that.

See https://build.opensuse.org/project/monitor/home:bernhard-voelker:branches:Ba se:System

I can imagine that "coreutils-testsuite-env" is not yet available for packages in Base:System or other projects, but I was hoping that it at least would already work in my home's subproject. ;-( Any hints?

Thanks & have a nice day, Berny

-- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Tue, Aug 06, 2013 at 08:32:37AM +0200, Marcus Meissner wrote:

On Tue, Aug 06, 2013 at 08:14:11AM +0200, Bernhard Voelker wrote:

...

On 08/05/2013 04:37 PM, Bernhard Voelker wrote:

...

On 08/05/2013 03:48 PM, Philipp Thomas wrote:

...

Why? We have the testsuite package that nearly nobody will want to install, so why shoudn't we have a package which a test user?

...

[...]

...

What I wanted is groupadd abuild2 usermod -a -G abuild2 abuild right before "make check-very-expensive" in the %check section.

Hmm, with both above sentences close to each other, I have the following idea: can I add the user to such a second group in the e.g. %post section of coreutils-testsuite, and then BuildReq:coreutils-testsuite to have that test environment in the following run? (Sounds like a little cycle, but maybe ...?)

You can probably do it a bit different.

coreutils-testsuite.spec, create a user in %post

and then run the testsuite in %check as %check is run after the package is installed into the system.

This would avoid loops.

What about to create coreutils-testsuite-setup package with following %post groupadd abuild2 usermod -a -G abuild2 abuild and with README.SUSE explaining the reason for it, becasue empty packages are not allowed in SUSE. Then add BuildRequires: coreutils-testsuite-setup to coreutils(-testsuite).spec and run make check. As groupadd/usermod are in shadow package, this won't even make any build cycles. Regards Michal Vyskocil

Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Quoting Bernhard Voelker :

On 08/08/2013 01:46 PM, Michal Vyskocil wrote:

...

What about to create coreutils-testsuite-setup package with following

%post groupadd abuild2 usermod -a -G abuild2 abuild

and with README.SUSE explaining the reason for it, becasue empty packages are not allowed in SUSE.

Then add BuildRequires: coreutils-testsuite-setup to coreutils(-testsuite).spec and run make check.

As groupadd/usermod are in shadow package, this won't even make any build cycles.

Thanks, that's actually how I tried to do it: https://build.opensuse.org/project/show/home:bernhard-voelker:branches:Base:...

I have no README.SUSE yet in the coreutils-testsuite-env package, so this might be the reason for the "nothing provides coreutils.testsuite-env" error in the ...-testsuite package. I'll give it a try.

Very likely. if you look at: https://build.opensuse.org/package/binaries/home:bernhard-voelker:branches:B... you see that there is only a .src.rpm created and as such, OBS is right: nothing provides what you're looking for (there is no installable package with that name). Dominique -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org