Re: [scl.org] Setting SCL RPM build options in COPR?
On Wed, Sep 20, 2017 at 12:39 AM, Davis, Daniel (NIH/NLM) [C] wrote: > Nick, > > Now that your question has been answered, let me ask mine.The > instructions to build pyscl-devel separate from Copr are not clear enough for > me. Are you suggesting that I run pipsi in a virtual environment? pipsi creates an auto-activated virtual environment, so the call to `rpmlb` implicitly runs the command in an environment with all the right Python dependencies. I'll add a note about how pipsi works to the README for the benefit of folks that aren't already familiar with it, as simply installing rpmlb into a separately managed virtual environment is indeed a valid alternative. > How is scrlo-python involved? It's the first and last item in the build recipe (the first time to get the relevant scl macros and other helpers defined, the second time to actually define the metapackage that depends on the default package set for the SCL). > I'm going to try later today, and want to be clear about what is involved... > I've built multi-package rpms before, sometimes from scripts and makefiles, > but not multi-package repositories from scripts, and I've never used Copr and > friends. I've never used a chroot to build rpms, but I think I've installed > mock even though I didn't really need it. If you're on Fedora, you'll probably want to do "dnf install fedora-packager" to ensure you have the necessary pieces (since the script uses `fedpkg` in addition to `mock`). If you're on RHEL or CentOS, you'll need to get `fedpkg` from EPEL instead. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
Re: [scl.org] Setting SCL RPM build options in COPR?
Nick, Now that your question has been answered, let me ask mine.The instructions to build pyscl-devel separate from Copr are not clear enough for me. Are you suggesting that I run pipsi in a virtual environment?How is scrlo-python involved? I'm going to try later today, and want to be clear about what is involved... I've built multi-package rpms before, sometimes from scripts and makefiles, but not multi-package repositories from scripts, and I've never used Copr and friends. I've never used a chroot to build rpms, but I think I've installed mock even though I didn't really need it. -Original Message- From: sclorg-boun...@redhat.com [mailto:sclorg-boun...@redhat.com] On Behalf Of Nick Coghlan Sent: Tuesday, September 19, 2017 4:10 AM To: Petr Kubat Cc: sclorg@redhat.com Subject: Re: [scl.org] Setting SCL RPM build options in COPR? On Tue, Sep 19, 2017 at 5:31 PM, Petr Kubat wrote: > On 09/19/2017 08:16 AM, Nick Coghlan wrote: >> I couldn't find anything in sclorg-distgit that actually *sets* them >> for the rh-python35 case. >> >> >> https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-pytho >> n35-rh/macros.additional.rh-python35 >> has the comment "the @scl@* macros are defined in >> macros.python3.python33 in python33-python-devel" >> >> That's presumably referring to >> >> https://github.com/sclorg-distgit/python/blob/sig-sclo7-rh-python35-r >> h/macros.python3, which still doesn't *set* "@scl@" or "@vendorscl@", >> it assumes they're set somewhere else. > > > The "@scl@" and "@vendorscl@" symbols are replaced by proper values > during the build of the metapackage [1], and the resulting macros get > installed using the *-build sub-package [2] as Honza mentioned. > > [1] > https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python > 35-rh/rh-python35.spec#L113 > [2] > https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python > 35-rh/rh-python35.spec#L137 Ah, thanks - that's the step I was missing :) I'll amend the sclo-python version of the macro files to explain that more clearly, and probably put something in the pyscl-devel README as well. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
Re: [scl.org] Setting SCL RPM build options in COPR?
On Tue, Sep 19, 2017 at 5:31 PM, Petr Kubat wrote: > On 09/19/2017 08:16 AM, Nick Coghlan wrote: >> I couldn't find anything in sclorg-distgit >> that actually *sets* them for the rh-python35 case. >> >> >> https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python35-rh/macros.additional.rh-python35 >> has the comment "the @scl@* macros are defined in >> macros.python3.python33 in python33-python-devel" >> >> That's presumably referring to >> >> https://github.com/sclorg-distgit/python/blob/sig-sclo7-rh-python35-rh/macros.python3, >> which still doesn't *set* "@scl@" or "@vendorscl@", it assumes they're >> set somewhere else. > > > The "@scl@" and "@vendorscl@" symbols are replaced by proper values during > the build of the metapackage [1], and the resulting macros get installed > using the *-build sub-package [2] as Honza mentioned. > > [1] > https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python35-rh/rh-python35.spec#L113 > [2] > https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python35-rh/rh-python35.spec#L137 Ah, thanks - that's the step I was missing :) I'll amend the sclo-python version of the macro files to explain that more clearly, and probably put something in the pyscl-devel README as well. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
Re: [scl.org] Setting SCL RPM build options in COPR?
Hi Nick, sending the mail again since I did not send the reply to list before (sorry!). On 09/19/2017 08:16 AM, Nick Coghlan wrote: On Mon, Sep 18, 2017 at 9:29 PM, Honza Horak wrote: On 09/18/2017 07:29 AM, Nick Coghlan wrote: 2. Assuming I haven't missed anything, how do the *default* values for "scl" and "vendorscl" actually get set? We can kinda control what packages are part of the minimal buildroot for every copr or cbs tag -- for SCL case there is the -build package that sets this 'scl' macro. You can add more macros if you like and they will be defined at a time a particular SRPM/RPM is built. By that trick and changing what macros are defined in -build, you may basically build more variants of a single SRPM and produce different output. That's what I thought, but I couldn't find anything in sclorg-distgit that actually *sets* them for the rh-python35 case. https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python35-rh/macros.additional.rh-python35 has the comment "the @scl@* macros are defined in macros.python3.python33 in python33-python-devel" That's presumably referring to https://github.com/sclorg-distgit/python/blob/sig-sclo7-rh-python35-rh/macros.python3, which still doesn't *set* "@scl@" or "@vendorscl@", it assumes they're set somewhere else. The "@scl@" and "@vendorscl@" symbols are replaced by proper values during the build of the metapackage [1], and the resulting macros get installed using the *-build sub-package [2] as Honza mentioned. [1] https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python35-rh/rh-python35.spec#L113 [2] https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python35-rh/rh-python35.spec#L137 So I'm still confused as to: - what's up with the "@" symbols in "@scl@" and "@vendorscl@"? - where can I find an example package that shows how to define them via a package in the buildroot so I can set up sclo-python-preview COPR builds? - where can I find documentation that explains how to do this when you *can't* pass arbitrary RPM build options? Cheers, Nick. P.S. https://www.softwarecollections.org currently appears to be down (I noticed when attempting to find docs about this) ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
Re: [scl.org] Setting SCL RPM build options in COPR?
On Mon, Sep 18, 2017 at 9:29 PM, Honza Horak wrote: > On 09/18/2017 07:29 AM, Nick Coghlan wrote: >> 2. Assuming I haven't missed anything, how do the *default* values for >> "scl" and "vendorscl" actually get set? > > We can kinda control what packages are part of the minimal buildroot for > every copr or cbs tag -- for SCL case there is the -build package that > sets this 'scl' macro. You can add more macros if you like and they will be > defined at a time a particular SRPM/RPM is built. By that trick and changing > what macros are defined in -build, you may basically build more > variants of a single SRPM and produce different output. That's what I thought, but I couldn't find anything in sclorg-distgit that actually *sets* them for the rh-python35 case. https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python35-rh/macros.additional.rh-python35 has the comment "the @scl@* macros are defined in macros.python3.python33 in python33-python-devel" That's presumably referring to https://github.com/sclorg-distgit/python/blob/sig-sclo7-rh-python35-rh/macros.python3, which still doesn't *set* "@scl@" or "@vendorscl@", it assumes they're set somewhere else. So I'm still confused as to: - what's up with the "@" symbols in "@scl@" and "@vendorscl@"? - where can I find an example package that shows how to define them via a package in the buildroot so I can set up sclo-python-preview COPR builds? - where can I find documentation that explains how to do this when you *can't* pass arbitrary RPM build options? Cheers, Nick. P.S. https://www.softwarecollections.org currently appears to be down (I noticed when attempting to find docs about this) -- Nick Coghlan Red Hat Platform Engineering, Brisbane ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
Re: [scl.org] Setting SCL RPM build options in COPR?
On 09/18/2017 07:29 AM, Nick Coghlan wrote: Using RPM List Builder, I have a recipe for bootstrapping the initial set of sclo-python RPMs locally in mock: https://github.com/ncoghlan/pyscl-devel/ Before building that in the CentOS build system, I'm aiming to first do a preview build in COPR: https://copr.fedorainfracloud.org/coprs/ncoghlan/sclo-python-preview/ However, I've hit a problem in translating the local mock build command into a copr-cli build command, which is that the local builds are relying on the ability to pass in arbitrary RPM build options to specify the right settings for "scl" and "vendorscl". As far as I can tell, that isn't going to work for COPR or CBS, since they expect to be able to just build the component as is, and don't offer the ability to configure the build step. So I have two questions: 1. Have I missed something, and it's actually possible to pass extra RPM build options for COPR builds? (it would make sense to me that I can't - the build isn't going to very repeatable if I can run it with different non-default settings each time) That's correct, I think your point about reproducibility is actually the reason why it works this way. 2. Assuming I haven't missed anything, how do the *default* values for "scl" and "vendorscl" actually get set? We can kinda control what packages are part of the minimal buildroot for every copr or cbs tag -- for SCL case there is the -build package that sets this 'scl' macro. You can add more macros if you like and they will be defined at a time a particular SRPM/RPM is built. By that trick and changing what macros are defined in -build, you may basically build more variants of a single SRPM and produce different output. Honza Cheers, Nick. ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
[scl.org] Setting SCL RPM build options in COPR?
Using RPM List Builder, I have a recipe for bootstrapping the initial set of sclo-python RPMs locally in mock: https://github.com/ncoghlan/pyscl-devel/ Before building that in the CentOS build system, I'm aiming to first do a preview build in COPR: https://copr.fedorainfracloud.org/coprs/ncoghlan/sclo-python-preview/ However, I've hit a problem in translating the local mock build command into a copr-cli build command, which is that the local builds are relying on the ability to pass in arbitrary RPM build options to specify the right settings for "scl" and "vendorscl". As far as I can tell, that isn't going to work for COPR or CBS, since they expect to be able to just build the component as is, and don't offer the ability to configure the build step. So I have two questions: 1. Have I missed something, and it's actually possible to pass extra RPM build options for COPR builds? (it would make sense to me that I can't - the build isn't going to very repeatable if I can run it with different non-default settings each time) 2. Assuming I haven't missed anything, how do the *default* values for "scl" and "vendorscl" actually get set? Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane ___ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg
