From hhorak at redhat.com Thu Sep 7 11:15:19 2017 From: hhorak at redhat.com (Honza Horak) Date: Thu, 7 Sep 2017 13:15:19 +0200 Subject: [scl.org] Update to rh-git29-git-2.9.3-3 In-Reply-To: References: Message-ID: <01660170-2f5e-bea1-9016-1e6904a2372c@redhat.com> I've just started the scripts and it should be in repos in couple of next days, once the publishing scripts notice the change. Honza On 08/30/2017 12:05 PM, Thomas Gerbet wrote: > Hello all, > > Sorry for the noise (or if it's the wrong place to ask such question) > but I was wondering about the update to 2.9.3-3 since only 2.9.3-2 is > available in the repository. > > I saw that the Git repo [1] has been updated a couple of weeks back but > it looks like the build has not been triggered on CBS [2]. > > > Regards, > Thomas Gerbet. > > > [1] https://git.centos.org/summary/?r=rpms/rh-git29-git.git > [2] https://cbs.centos.org/koji/packageinfo?packageID=4532 > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Thu Sep 14 09:21:07 2017 From: hhorak at redhat.com (Honza Horak) Date: Thu, 14 Sep 2017 11:21:07 +0200 Subject: [scl.org] SCL devtoolset on arm64/aarch64 In-Reply-To: <9E4B6DAE-F6FD-4301-87B2-12BD465EC69B@theobroma-systems.com> References: <9E4B6DAE-F6FD-4301-87B2-12BD465EC69B@theobroma-systems.com> Message-ID: <84219436-a329-c268-f2b1-dd46f00fc084@redhat.com> Christoph, I'm afraid this request was kinda forgotten without proper feedback, sorry for that.. Anyway, I expect you talk about devtoolset-6 SCL, right? Have you tried to use the aarch64 packages from buildlogs (testing repository)? $ yum install centos-release-scl-rh $ yum-config-manager --enable centos-sclo-rh-testing Jim, we probably did not finish moving the devtoolset-6 builds into mirrors, but I already forgot whether there was some reason for that.. Honza On 05/19/2017 07:39 PM, Christoph M?llner wrote: > Hi sclorg list, > > I am using CentOS 7 on an arm64 machine and ran into the problem, that > the shipped compiler is not recent enough for the source code I want to build > (some required C++11 features are not available). > > On x86_64 I could use your devtoolset packages to circumvent the issue, > but on arm64/aarch64 these packages are not available. > > Therefore I'd like to ask if there are some plans to get the devtoolset packages > available on arm64? > > Thanks, > Christoph > > -- > Christoph M?llner > Theobroma Systems Design und Consulting GmbH > Seestadtstra?e 27 (Aspern IQ), 1220 Wien, Austria > Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 > http://www.theobroma-systems.com > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From christoph.muellner at theobroma-systems.com Thu Sep 14 10:30:37 2017 From: christoph.muellner at theobroma-systems.com (=?utf-8?Q?Christoph_M=C3=BCllner?=) Date: Thu, 14 Sep 2017 12:30:37 +0200 Subject: [scl.org] SCL devtoolset on arm64/aarch64 In-Reply-To: <84219436-a329-c268-f2b1-dd46f00fc084@redhat.com> References: <9E4B6DAE-F6FD-4301-87B2-12BD465EC69B@theobroma-systems.com> <84219436-a329-c268-f2b1-dd46f00fc084@redhat.com> Message-ID: <88159F25-5A4D-4586-A123-739E50AA5117@theobroma-systems.com> Hi Honza, thank's for the reply! You are right, I was searching for devtoolset-6 for arm64. On another mailing list I already got the hint to use the packages from buildlogs.centos.org (https://buildlogs.centos.org/centos/7/sclo/aarch64/rh/devtoolset-6/). As I had to use g++ 4.9 or 5.x back then (the code base was not ready for g++ 6.x), I ended up using a self-built g++ 5.4 (with -D_GLIBCXX_USE_CXX11_ABI=0 to be able to link against pre-built CentOS libraries). I just wanted to give it a try and use your instructions to install devtoolset-6. However, I ended up with the following error: > cmuellner at gryphon2 ~$ sudo yum update > Loaded plugins: auto-update-debuginfo, fastestmirror > http://mirror.centos.org/centos/7/sclo/aarch64/rh/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found > Trying other mirror. > To address this issue please refer to the below knowledge base article > > https://access.redhat.com/articles/1320623 > > If above article doesn't help to resolve this issue please create a bug on https://bugs.centos.org/ > > > > One of the configured repositories failed (CentOS-7 - SCLo rh), > and yum doesn't have enough cached data to continue. At this point the only > safe thing yum can do is fail. There are a few ways to work "fix" this: > > 1. Contact the upstream for the repository and get them to fix the problem. > > 2. Reconfigure the baseurl/etc. for the repository, to point to a working > upstream. This is most often useful if you are using a newer > distribution release than is supported by the repository (and the > packages for the previous distribution release still work). > > 3. Run the command with the repository temporarily disabled > yum --disablerepo=centos-sclo-rh ... > > 4. Disable the repository permanently, so yum won't use it by default. Yum > will then just ignore the repository until you permanently enable it > again or use --enablerepo for temporary usage: > > yum-config-manager --disable centos-sclo-rh > or > subscription-manager repos --disable=centos-sclo-rh > > 5. Configure the failing repository to be skipped, if it is unavailable. > Note that yum will try to contact the repo. when it runs most commands, > so will have to try and fail each time (and thus. yum will be be much > slower). If it is a very temporary problem though, this is often a nice > compromise: > > yum-config-manager --save --setopt=centos-sclo-rh.skip_if_unavailable=true > > failure: repodata/repomd.xml from centos-sclo-rh: [Errno 256] No more mirrors to try. > http://mirror.centos.org/centos/7/sclo/aarch64/rh/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found So I can confirm, that the packages are not there. If you plan to make them available, then I'd be happy to test them. Thanks, Christoph -- Christoph M?llner Theobroma Systems Design und Consulting GmbH Seestadtstra?e 27 (Aspern IQ), 1220 Wien, Austria Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 http://www.theobroma-systems.com > On 14 Sep 2017, at 11:21, Honza Horak wrote: > > Christoph, I'm afraid this request was kinda forgotten without proper feedback, sorry for that.. Anyway, I expect you talk about devtoolset-6 SCL, right? Have you tried to use the aarch64 packages from buildlogs (testing repository)? > > $ yum install centos-release-scl-rh > $ yum-config-manager --enable centos-sclo-rh-testing > > Jim, we probably did not finish moving the devtoolset-6 builds into mirrors, but I already forgot whether there was some reason for that.. > > Honza > > On 05/19/2017 07:39 PM, Christoph M?llner wrote: >> Hi sclorg list, >> I am using CentOS 7 on an arm64 machine and ran into the problem, that >> the shipped compiler is not recent enough for the source code I want to build >> (some required C++11 features are not available). >> On x86_64 I could use your devtoolset packages to circumvent the issue, >> but on arm64/aarch64 these packages are not available. >> Therefore I'd like to ask if there are some plans to get the devtoolset packages >> available on arm64? >> Thanks, >> Christoph >> -- >> Christoph M?llner >> Theobroma Systems Design und Consulting GmbH >> Seestadtstra?e 27 (Aspern IQ), 1220 Wien, Austria >> Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 >> http://www.theobroma-systems.com >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP URL: From jperrin at centos.org Thu Sep 14 16:34:24 2017 From: jperrin at centos.org (Jim Perrin) Date: Thu, 14 Sep 2017 09:34:24 -0700 Subject: [scl.org] SCL devtoolset on arm64/aarch64 In-Reply-To: <84219436-a329-c268-f2b1-dd46f00fc084@redhat.com> References: <9E4B6DAE-F6FD-4301-87B2-12BD465EC69B@theobroma-systems.com> <84219436-a329-c268-f2b1-dd46f00fc084@redhat.com> Message-ID: <1eac15f3-7a01-f4f1-dc7a-53b3493f67ba@centos.org> I think the only thing required is a bump around the -release file that specifies the mirror location being different from the x86_64 path. The packages will need to be signed but beyond that they work quite well (I've used them for quite a few things). I can work with you later this week on it if you have time. On 09/14/2017 02:21 AM, Honza Horak wrote: > Christoph, I'm afraid this request was kinda forgotten without proper > feedback, sorry for that.. Anyway, I expect you talk about devtoolset-6 > SCL, right? Have you tried to use the aarch64 packages from buildlogs > (testing repository)? > > ? $ yum install centos-release-scl-rh > ? $ yum-config-manager --enable centos-sclo-rh-testing > > Jim, we probably did not finish moving the devtoolset-6 builds into > mirrors, but I already forgot whether there was some reason for that.. > > Honza > > On 05/19/2017 07:39 PM, Christoph M?llner wrote: >> Hi sclorg list, >> >> I am using CentOS 7 on an arm64 machine and ran into the problem, that >> the shipped compiler is not recent enough for the source code I want >> to build >> (some required C++11 features are not available). >> >> On x86_64 I could use your devtoolset packages to circumvent the issue, >> but on arm64/aarch64 these packages are not available. >> >> Therefore I'd like to ask if there are some plans to get the >> devtoolset packages >> available on arm64? >> >> Thanks, >> Christoph >> >> -- >> Christoph M?llner >> Theobroma Systems Design und Consulting GmbH >> Seestadtstra?e 27 (Aspern IQ), 1220 Wien, Austria >> Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 >> http://www.theobroma-systems.com >> >> >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg >> -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From steve.traylen at cern.ch Fri Sep 15 07:35:36 2017 From: steve.traylen at cern.ch (Steve Traylen) Date: Fri, 15 Sep 2017 09:35:36 +0200 Subject: [scl.org] Introduction from me. Message-ID: <1505460936.4033.3.camel@cern.ch> Hi, I've requested to join the Software Collections SIG. Initially I wanted to build and add rh-pythonXX-matplotlib against the exisiting numpy packages but generally I will be building more SLC packages. I run the interactive interactive login services at work so mostly random clients and scientific packages. I've been a fedora packager and sponser for a number of years (username =stevetraylen) and work here at CERN with Thomas and Jarek. Steve. From hhorak at redhat.com Fri Sep 15 11:09:55 2017 From: hhorak at redhat.com (Honza Horak) Date: Fri, 15 Sep 2017 13:09:55 +0200 Subject: [scl.org] Introduction from me. In-Reply-To: <1505460936.4033.3.camel@cern.ch> References: <1505460936.4033.3.camel@cern.ch> Message-ID: <017469a3-17e3-9d25-495b-c8dc4cc17b68@redhat.com> Hey Steve, that all sounds great to me, so welcome on board! On 09/15/2017 09:35 AM, Steve Traylen wrote: > > Hi, > > I've requested to join the Software Collections SIG. > > Initially I wanted to build and add rh-pythonXX-matplotlib against Just a small correction here -- such packages should be part of the community collections that Jarek was building recently, so in the end it will be sclo-pythonXX-matplotlib etc.. > the exisiting numpy packages but generally I will be building > more SLC packages. I run the interactive interactive login services > at work so mostly random clients and scientific packages. > > I've been a fedora packager and sponser for a number of years (username =stevetraylen) > and work here at CERN with Thomas and Jarek. Awesome, so you already have mentors around, who should be able to help you with getting up to speed. Good luck and don't hesitate to contact me or anybody else from the group members if there are any troubles. Honza > Steve. > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From Jaroslaw.Polok at cern.ch Fri Sep 15 11:18:49 2017 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Fri, 15 Sep 2017 13:18:49 +0200 Subject: [scl.org] Introduction from me. In-Reply-To: <1505460936.4033.3.camel@cern.ch> References: <1505460936.4033.3.camel@cern.ch> Message-ID: <9319e96c-e84a-12e2-6ada-0b9ddb29500b@cern.ch> Hi Steve ! On 09/15/2017 09:35 AM, Steve Traylen wrote: > > Hi, > > I've requested to join the Software Collections SIG. > Yes, I see your account awaits approval on accounts.centos.org now. > Initially I wanted to build and add rh-pythonXX-matplotlib against > the exisiting numpy packages but generally I will be building > more SLC packages. I run the interactive interactive login services > at work so mostly random clients and scientific packages. For sclo python packages: we are in process of making additional python packages available for pyhon27,34 and 35 versions: https://buildlogs.centos.org/centos/7/sclo/x86_64/sclo/ (oops. reminds me I should have asked to push these to production .. will ask now) For above mentioned packages you can find specs here: https://github.com/sclorg-distgit/sclo-python{27,34,35} it would be certainly interesting and useful to get more in these collections ! So: welcome ! Cheers Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From ncoghlan at redhat.com Mon Sep 18 05:29:58 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Mon, 18 Sep 2017 15:29:58 +1000 Subject: [scl.org] Setting SCL RPM build options in COPR? Message-ID: 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 From hhorak at redhat.com Mon Sep 18 11:29:27 2017 From: hhorak at redhat.com (Honza Horak) Date: Mon, 18 Sep 2017 13:29:27 +0200 Subject: [scl.org] Setting SCL RPM build options in COPR? In-Reply-To: References: Message-ID: <9260887b-6bf8-5299-7e31-59d6f8a60b2c@redhat.com> 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. > From ncoghlan at redhat.com Tue Sep 19 06:16:12 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Tue, 19 Sep 2017 16:16:12 +1000 Subject: [scl.org] Setting SCL RPM build options in COPR? In-Reply-To: <9260887b-6bf8-5299-7e31-59d6f8a60b2c@redhat.com> References: <9260887b-6bf8-5299-7e31-59d6f8a60b2c@redhat.com> Message-ID: 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 From pkubat at redhat.com Tue Sep 19 07:31:46 2017 From: pkubat at redhat.com (Petr Kubat) Date: Tue, 19 Sep 2017 09:31:46 +0200 Subject: [scl.org] Setting SCL RPM build options in COPR? In-Reply-To: References: <9260887b-6bf8-5299-7e31-59d6f8a60b2c@redhat.com> Message-ID: <1e0afdb3-18e1-d660-3022-07a6f8297284@redhat.com> 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) > From ncoghlan at redhat.com Tue Sep 19 08:10:21 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Tue, 19 Sep 2017 18:10:21 +1000 Subject: [scl.org] Setting SCL RPM build options in COPR? In-Reply-To: <1e0afdb3-18e1-d660-3022-07a6f8297284@redhat.com> References: <9260887b-6bf8-5299-7e31-59d6f8a60b2c@redhat.com> <1e0afdb3-18e1-d660-3022-07a6f8297284@redhat.com> Message-ID: 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 From daniel.davis at nih.gov Tue Sep 19 14:39:11 2017 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Tue, 19 Sep 2017 14:39:11 +0000 Subject: [scl.org] Setting SCL RPM build options in COPR? In-Reply-To: References: <9260887b-6bf8-5299-7e31-59d6f8a60b2c@redhat.com> <1e0afdb3-18e1-d660-3022-07a6f8297284@redhat.com> Message-ID: 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-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] On Behalf Of Nick Coghlan Sent: Tuesday, September 19, 2017 4:10 AM To: Petr Kubat Cc: sclorg at 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 at redhat.com https://www.redhat.com/mailman/listinfo/sclorg From ncoghlan at redhat.com Tue Sep 19 14:57:24 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Wed, 20 Sep 2017 00:57:24 +1000 Subject: [scl.org] Setting SCL RPM build options in COPR? In-Reply-To: References: <9260887b-6bf8-5299-7e31-59d6f8a60b2c@redhat.com> <1e0afdb3-18e1-d660-3022-07a6f8297284@redhat.com> Message-ID: 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