[opensuse-buildservice] Giving abuild user a 2nd group?
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? Thanks & 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
On 07/23/2013 10:12 PM, Bernhard Voelker wrote:
Is there a way to tell OBS to add 'abuild' to a 2nd group?
Anyone? 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
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
On 08/05/2013 11:28 AM, Adrian Schröter wrote:
Am Dienstag, 23. Juli 2013, 22:12:21 schrieb Bernhard Voelker:
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.
Hmm, but chances are ~0 that such a package would be available to normal repos like Base:Build, Base:System or Factory, right? 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
* 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 03:48 PM, Philipp Thomas wrote:
- 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?
IMHO another test user is not the solution because during %check we are not able to su(1) to that user, are we? What I wanted is groupadd abuild2 usermod -a -G abuild2 abuild right before "make check-very-expensive" in the %check section. 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
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
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. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Marcus Meissner <meissner@suse.de> 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
On 08/06/2013 08:54 AM, Andreas Schwab wrote:
Marcus Meissner <meissner@suse.de> 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.
Just a moment - "make check" *is* run in %check, and the testsuite logfile *is* packaged today. I'm a bit confused now about the order of the %... sections. I have to test ... 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
* 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
Philipp Thomas <pth@suse.de> writes:
The order is %build->%check->%install
No, it is %prep, %build, %install, %check, %clean. 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
* 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
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? 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
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
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? 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
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
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:... But the testsuite fails with buildinfo is broken... it says: unresolvable: nothing provides coreutils-testsuite-env See https://build.opensuse.org/project/monitor/home:bernhard-voelker:branches:Ba... 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 -- 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 08/07/2013 03:53 PM, Adrian Schröter wrote:
unresolvable: nothing provides coreutils-testsuite-env
You have played with the "useforbuild" flags. The package is not available, when you disable that.
Removed && rebuild. Still no go. ;-( -- 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
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. Thanks & 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
Quoting Bernhard Voelker <mail@bernhard-voelker.de>:
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
participants (7)
-
Adrian Schröter -
Andreas Schwab -
Bernhard Voelker -
Dominique Leuenberger a.k.a. Dimstar -
Marcus Meissner -
Michal Vyskocil -
Philipp Thomas