From mizdebsk at redhat.com Wed Jul 1 10:11:04 2015 From: mizdebsk at redhat.com (Mikolaj Izdebski) Date: Wed, 01 Jul 2015 12:11:04 +0200 Subject: [scl.org] Where is maven30-scldevel >= 1.1-7 and rh-java-common-scldevel >= 1.1-12 In-Reply-To: <5592A9E7.5030809@cora.nwra.com> References: <5592A9E7.5030809@cora.nwra.com> Message-ID: <5593BCB8.8090604@redhat.com> On 06/30/2015 04:38 PM, Orion Poplawski wrote: > I'm trying to rebuild some of my eclipse packages that build on top of the > eclipse scl, but am getting: > > DEBUG util.py:378: Error: Package: > devtoolset-3-build-3.1-10.el7.centos.x86_64 > (coprbecloudfedoraprojectorg_results_rhscl_devtoolset3el7_epel7x86_64) > DEBUG util.py:378: Requires: maven30-scldevel >= 1.1-7 > DEBUG util.py:378: You could try using --skip-broken to work around the problem > DEBUG util.py:378: You could try running: rpm -Va --nofiles --nodigest > DEBUG util.py:378: Error: Package: > devtoolset-3-build-3.1-10.el7.centos.x86_64 > (coprbecloudfedoraprojectorg_results_rhscl_devtoolset3el7_epel7x86_64) > DEBUG util.py:378: Requires: rh-java-common-scldevel >= 1.1-12 > > Where can I find these? They are available in maven30 and rh-java-common collections. https://www.softwarecollections.org/en/scls/rhscl/maven30/ https://www.softwarecollections.org/en/scls/rhscl/rh-java-common/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk From orion at cora.nwra.com Wed Jul 1 16:40:23 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 1 Jul 2015 10:40:23 -0600 Subject: [scl.org] Where is maven30-scldevel >= 1.1-7 and rh-java-common-scldevel >= 1.1-12 In-Reply-To: <5593BCB8.8090604@redhat.com> References: <5592A9E7.5030809@cora.nwra.com> <5593BCB8.8090604@redhat.com> Message-ID: <559417F7.3090604@cora.nwra.com> On 07/01/2015 04:11 AM, Mikolaj Izdebski wrote: > On 06/30/2015 04:38 PM, Orion Poplawski wrote: >> I'm trying to rebuild some of my eclipse packages that build on top of the >> eclipse scl, but am getting: >> >> DEBUG util.py:378: Error: Package: >> devtoolset-3-build-3.1-10.el7.centos.x86_64 >> (coprbecloudfedoraprojectorg_results_rhscl_devtoolset3el7_epel7x86_64) >> DEBUG util.py:378: Requires: maven30-scldevel >= 1.1-7 >> DEBUG util.py:378: You could try using --skip-broken to work around the problem >> DEBUG util.py:378: You could try running: rpm -Va --nofiles --nodigest >> DEBUG util.py:378: Error: Package: >> devtoolset-3-build-3.1-10.el7.centos.x86_64 >> (coprbecloudfedoraprojectorg_results_rhscl_devtoolset3el7_epel7x86_64) >> DEBUG util.py:378: Requires: rh-java-common-scldevel >= 1.1-12 >> >> Where can I find these? > > They are available in maven30 and rh-java-common collections. > > https://www.softwarecollections.org/en/scls/rhscl/maven30/ > https://www.softwarecollections.org/en/scls/rhscl/rh-java-common/ > Hmm, I thought I checked there earlier and didn't find them, but seems to be there now. Next issue: + xmvn -o -DforceContextQualifier=201502031411 verify [WARNING] Error initializing: org.fedoraproject.maven.resolver.impl.DefaultDependencyMap at 6422d556 java.lang.RuntimeException: Failed to load XMvn configuration Do I need to do something special to use xmvn here? Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From hhorak at redhat.com Wed Jul 8 06:17:10 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 08 Jul 2015 08:17:10 +0200 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-07-08) Message-ID: <559CC066.1060102@redhat.com> SCLo SIG meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * We have devtoolset-3-toolchain packages built in CBS * Consulting changes in tags structure in CBS * Layered Docker images based on the SCL packages * propose some other topics :) Honza From hhorak at redhat.com Wed Jul 8 06:35:34 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 08 Jul 2015 08:35:34 +0200 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-07-08) In-Reply-To: <559CC066.1060102@redhat.com> References: <559CC066.1060102@redhat.com> Message-ID: <559CC4B6.2050002@redhat.com> On 07/08/2015 08:17 AM, Honza Horak wrote: > * Consulting changes in tags structure in CBS A short highlight where I'd like to change things (any feedback welcome and we can consult it later today).. We already spoke about it before, but it seems to me the current tags names don't work this way -- the changes basically come from the idea to have two sets of collections: * one set of RHSCL collections (basically RHSCL content, just available for everyone, something like CentOS is to RHEL) * another set of collections that are not in RHSCL (that extend the RHSCL collections or they are something what is not in RHSCL at all, something like EPEL is to CentOS/RHEL) Having the sets separated will be useful for RH customers who will be able to use RHSCL packages from RH, but will be able to use the EPEL-like collections as well. Anyway, that means we'll need to change the tags scheme this way: Instead of sclo7-common-{candidate,testing,release} we'll need to have two sets of tags/repositories: * sclo7-common-rh-{candidate,testing,release} (acts as centos for rhel) * sclo7-common-sclo-{candidate,testing,release} (acts as epel for rhel/centos) Every collection will then put the packages into one of these tags/repositories, e.g.: * sclo7-common-rh-{candidate,testing,release} will contain all packages from collections devtoolset-3, mariadb55, php55, ... * sclo7-common-sclo-{candidate,testing,release} will contain all packages from collections php55-extra, devtoolset-3-extra, erlang18, ... Honza From paul at vanmaaren.org Wed Jul 8 10:43:21 2015 From: paul at vanmaaren.org (Paul van Maaren) Date: Wed, 8 Jul 2015 11:43:21 +0100 Subject: [scl.org] python27-python-requests? Message-ID: <20150708104321.GA20054@mail2.vanmaaren.org> Hi, Is there an easy way to build a python27-python-requests rpm that I can install on RHEL6? I am working my way through the dependencies, but I have trouble generating the python27-python-backports rpm. Any hints will be appreciated. -- Regards, Paul van Maaren From hhorak at redhat.com Fri Jul 10 12:38:12 2015 From: hhorak at redhat.com (Honza Horak) Date: Fri, 10 Jul 2015 14:38:12 +0200 Subject: [scl.org] repos with software collection packages from scl.org web Message-ID: <559FBCB4.3040901@redhat.com> Hi Brian, as we discussed, this is (hopefully) a full list of repos for software collections packages, that are available at softwarecollection.org. I'm not sure whether it is a problem, but except packages of particular collection there is also a package with repository itself. I just wanted to mention it, not sure if it can make any issues in koji.. These packages are all called rhscl--epel-7-x86_64-.noarch, so these can be easily filtered.. https://www.softwarecollections.org/repos/rhscl/devassist09/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/devtoolset-3/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/git19/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/httpd24/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/mariadb55/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/maven30/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/mongodb24/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/mysql55/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/nginx14/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/nginx16/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/nodejs010/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/perl516/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/php54/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/php55/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/postgresql92/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/python27/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/python33/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-java-common/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-mariadb100/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-mongodb26/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-mysql56/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-passenger40/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-perl520/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-php56/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-postgresql94/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-python34/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-ror41/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-ruby22/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/ror40/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/ruby193/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/ruby200/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/thermostat1/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/v8314/epel-7-x86_64 Yeah, quite a lot and even much more packages actually.. Let me know if you need anything else.. Honza From hhorak at redhat.com Fri Jul 10 13:37:14 2015 From: hhorak at redhat.com (Honza Horak) Date: Fri, 10 Jul 2015 15:37:14 +0200 Subject: [scl.org] devtoolset-3 packages tagged Message-ID: <559FCA8A.3080802@redhat.com> As we talked on Wednesday, I've checked the packages once again and was able to build a package with the SCL gcc that was installed by: `yum install devtoolset-3-toolchain`. So I guess we're fine to release them as a testing release.. The images are now tagged as sclo7-devtoolset-3-sclo-release: http://cbs.centos.org/repos/sclo7-devtoolset-3-sclo-release/x86_64/os/Packages/ Good luck :) (I will be less available next week, sorry in advance) Honza From doran at bluehost.com Thu Jul 16 17:23:31 2015 From: doran at bluehost.com (Doran Barton) Date: Thu, 16 Jul 2015 11:23:31 -0600 Subject: [scl.org] Hints on building a package that depends on 2+ collections Message-ID: <20150716112331.499ca7ac@doran-t440s> I plan to produce a build of httpd24-mod_perl that is built against the perl520 collection of Perl. Would that be named httpd24-perl520-mod_perl? What convention has been established, if any, for builds like this? -- Doran L. Barton - Senior Developer at Bluehost "Persons are prohibited from picking flowers from any but their own graves." -- Seen in a cemetery From jkaluza at redhat.com Fri Jul 17 06:09:01 2015 From: jkaluza at redhat.com (=?windows-1252?Q?Jan_Kalu=9Ea?=) Date: Fri, 17 Jul 2015 08:09:01 +0200 Subject: [scl.org] Hints on building a package that depends on 2+ collections In-Reply-To: <20150716112331.499ca7ac@doran-t440s> References: <20150716112331.499ca7ac@doran-t440s> Message-ID: <55A89BFD.6000409@redhat.com> On 07/16/2015 07:23 PM, Doran Barton wrote: > I plan to produce a build of httpd24-mod_perl that is built against the > perl520 collection of Perl. Would that be named httpd24-perl520-mod_perl? > What convention has been established, if any, for builds like this? > That's a good question. I think we do not have any guideline for that. I'm the author of rh-passenger40 SCL which can be optionally used with ruby193, ruby200 and rh-ruby22. I've decided to put the ruby version specific files into subpackages named: - rh-passenger40-ruby193 - rh-passenger40-ruby200 - rh-passenger40-ruby22 So from my point of view, your "httpd24-perl520-mod_perl" name sounds sane. Regards, Jan Kaluza From msuchy at redhat.com Mon Jul 20 08:57:34 2015 From: msuchy at redhat.com (=?UTF-8?Q?Miroslav_Such=c3=bd?=) Date: Mon, 20 Jul 2015 10:57:34 +0200 Subject: [scl.org] Accessibility over ipv6 In-Reply-To: <1435530354.25823.3.camel@skuggor.se> References: <1435530354.25823.3.camel@skuggor.se> Message-ID: <55ACB7FE.2080405@redhat.com> Dne 29.6.2015 v 00:25 D. S. napsal(a): > Could you, pretty please with sugar on top, make sure that there's a > AAAA record and a listening server on the other end of that as well? At > least for the repo/mirrors. The hosting is provided by BlueHost, I am trying to contact them to get IPv6 record. No luck so far. I will try little bit harder. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From msuchy at redhat.com Mon Jul 20 11:37:53 2015 From: msuchy at redhat.com (=?UTF-8?Q?Miroslav_Such=c3=bd?=) Date: Mon, 20 Jul 2015 13:37:53 +0200 Subject: [scl.org] Hints on building a package that depends on 2+ collections In-Reply-To: <20150716112331.499ca7ac@doran-t440s> References: <20150716112331.499ca7ac@doran-t440s> Message-ID: <55ACDD91.3080703@redhat.com> Dne 16.7.2015 v 19:23 Doran Barton napsal(a): > I plan to produce a build of httpd24-mod_perl that is built against the > perl520 collection of Perl. Would that be named httpd24-perl520-mod_perl? > What convention has been established, if any, for builds like this? See: https://www.softwarecollections.org/en/docs/guide/#Creating_Your_Own_Software_Collections and: https://www.softwarecollections.org/en/docs/guide/#sect-The_Software_Collections_Prefix So my recommendation based on this documentation is to named: bluehost-httpd24 which would Requires perl520 packages. However the perl 5.2 is not main reason of this collection (I assume) but the http 2.4 is. Therefore this name. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From seitz at bsd-unix.net Mon Jul 20 16:30:54 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Mon, 20 Jul 2015 12:30:54 -0400 Subject: [scl.org] Accessibility over ipv6 In-Reply-To: <55ACB7FE.2080405@redhat.com> References: <1435530354.25823.3.camel@skuggor.se> <55ACB7FE.2080405@redhat.com> Message-ID: <20150720163054.GA56411@bsd-unix.net> On Mon, Jul 20, 2015 at 10:57:34AM +0200, Miroslav Such?? wrote: > Dne 29.6.2015 v 00:25 D. S. napsal(a): > > Could you, pretty please with sugar on top, make sure that there's a > > AAAA record and a listening server on the other end of that as well? At > > least for the repo/mirrors. > > The hosting is provided by BlueHost, I am trying to contact them to get IPv6 record. > No luck so far. I will try little bit harder. And RSYNC? :) -- Bryan G. Seitz From doran at bluehost.com Wed Jul 22 15:16:59 2015 From: doran at bluehost.com (Doran Barton) Date: Wed, 22 Jul 2015 09:16:59 -0600 Subject: [scl.org] Accessibility over ipv6 In-Reply-To: <55ACB7FE.2080405@redhat.com> References: <1435530354.25823.3.camel@skuggor.se> <55ACB7FE.2080405@redhat.com> Message-ID: <20150722091659.0418f4e0@doran-t440s> On Mon, 20 Jul 2015 10:57:34 +0200 Miroslav Such? wrote: > The hosting is provided by BlueHost, I am trying to contact them to get > IPv6 record. No luck so far. I will try little bit harder. I'll see what I can do to help in the pushing. -- Doran L. Barton - Senior Developer at Bluehost "Have many accidents here." -- Seen in a Tokyo traffic handbook From noah at coderanger.net Mon Jul 27 00:11:45 2015 From: noah at coderanger.net (Noah Kantrowitz) Date: Sun, 26 Jul 2015 17:11:45 -0700 Subject: [scl.org] SCL packages and linker paths Message-ID: <3924C0BB-6D0A-482D-8E5E-6AB1C8FC8CF4@coderanger.net> Hi there. I'm working on some Chef tooling for Python and Ruby to allow swapping runtimes in a modular way. The easiest way to do this is to pass through different paths to a Python binary. For system packages, it uses /usr/bin/python while for SCL it uses /opt/rh/ From msuchy at redhat.com Tue Jul 28 12:33:08 2015 From: msuchy at redhat.com (=?UTF-8?Q?Miroslav_Such=c3=bd?=) Date: Tue, 28 Jul 2015 14:33:08 +0200 Subject: [scl.org] SCL packages and linker paths In-Reply-To: <3924C0BB-6D0A-482D-8E5E-6AB1C8FC8CF4@coderanger.net> References: <3924C0BB-6D0A-482D-8E5E-6AB1C8FC8CF4@coderanger.net> Message-ID: <55B77684.8040500@redhat.com> Dne 27.7.2015 v 02:11 Noah Kantrowitz napsal(a): > Hi there. I'm working on some Chef tooling for Python and Ruby to allow swapping runtimes in a modular way. The easiest way to do this is to pass through different paths to a Python binary. For system packages, it uses /usr/bin/python while for SCL it uses /opt/rh/ References: <3924C0BB-6D0A-482D-8E5E-6AB1C8FC8CF4@coderanger.net> Message-ID: <55B7791C.2010100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 27/07/2015 02:11, Noah Kantrowitz a ?crit : > Hi there. I'm working on some Chef tooling for Python and Ruby to > allow swapping runtimes in a modular way. The easiest way to do > this is to pass through different paths to a Python binary. For > system packages, it uses /usr/bin/python while for SCL it uses > /opt/rh/ `scl enable` command though, which presents a problem. Most of the > environment variables set in the enable files are nice but not > required, but LD_LIBRARY_PATH presents an issue. Because the SCL > binaries do not have an RPATH in their header, they simply fail to > start in most cases, or locate the wrong libraries if there is > overlap with system packages. Is there a compelling reason to not > bake this RPATH into the SCL binaries directly? This would make it > much easier to build tooling that treats the Python and Ruby > packages as just another way to install things. This is what the PHP build system doest for years. Not use in PHP RHSCL because everything is in base system. But various package in the php5xmore collection rely on this behavior. Remi. > --Noah > > > > _______________________________________________ SCLorg mailing > list SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > - -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlW3eRkACgkQYUppBSnxahhwkQCeMNxRtzLMQIJq7Sz0PPrx+xzD YBgAoOYjeBb3l5m1Wea7Acyblb3peObs =qT1k -----END PGP SIGNATURE----- From redhat at veggiechinese.net Tue Jul 28 15:50:30 2015 From: redhat at veggiechinese.net (Will Yardley) Date: Tue, 28 Jul 2015 08:50:30 -0700 Subject: [scl.org] SCL packages and linker paths In-Reply-To: <55B77684.8040500@redhat.com> References: <3924C0BB-6D0A-482D-8E5E-6AB1C8FC8CF4@coderanger.net> <55B77684.8040500@redhat.com> Message-ID: <20150728155030.GB42679@aura.veggiechinese.net> On Tue, Jul 28, 2015 at 02:33:08PM +0200, Miroslav Such? wrote: > Dne 27.7.2015 v 02:11 Noah Kantrowitz napsal(a): > > Hi there. I'm working on some Chef tooling for Python and Ruby to > > allow swapping runtimes in a modular way. The easiest way to do this > > is to pass through different paths to a Python binary. For system > > packages, it uses /usr/bin/python while for SCL it uses > > /opt/rh/ > `scl enable` command though, which presents a problem. Most of the > > environment variables set in the enable files are nice but not > > required, but LD_LIBRARY_PATH presents an issue. Because the SCL > > binaries do not have an RPATH in their header, they simply fail to > > start in most cases, or locate the wrong libraries if there is > > overlap with system packages. Is there a compelling reason to not > > bake this RPATH into the SCL binaries directly? > The easiest way is to create wrapper. > > I created one for ruby193 SCL: > http://koji.katello.org/koji/buildinfo?buildID=4636 That may be the "easiest" way, but doesn't seem very clean. It would be much better if they're built in such a way that tools can use /path/to/foo in the shebang line. Since virtually everything except the LD_LIBRARY_PATH are compiled in, seems like the solution above would allow this to work. w From ncoghlan at redhat.com Wed Jul 29 07:21:19 2015 From: ncoghlan at redhat.com (Nick Coghlan) Date: Wed, 29 Jul 2015 17:21:19 +1000 Subject: [scl.org] SCL packages and linker paths In-Reply-To: <20150728155030.GB42679@aura.veggiechinese.net> References: <3924C0BB-6D0A-482D-8E5E-6AB1C8FC8CF4@coderanger.net> <55B77684.8040500@redhat.com> <20150728155030.GB42679@aura.veggiechinese.net> Message-ID: <55B87EEF.5070208@redhat.com> On 07/29/2015 01:50 AM, Will Yardley wrote: > That may be the "easiest" way, but doesn't seem very clean. It would be > much better if they're built in such a way that tools can use > /path/to/foo in the shebang line. Since virtually everything except the > LD_LIBRARY_PATH are compiled in, seems like the solution above would > allow this to work. I'd managed to avoid learning about RPATH before reading Noah's post, but a web search found me http://blog.tremily.us/posts/rpath/ which seems to offer a decent summary of the current state of affairs. In the case of SCLs, I think the standard arguments against using RPATH aren't applicable - we *don't* support relocating the prebuilt binaries to a different filesystem path, so I think it's OK to say that if you want to move them somewhere else, you need to rebuild them rather than just copying them. If someone wants binaries they can copy around freely and rely on runtime LD_LIBRARY_PATH modifications to find dependencies, then they could still make a normal build rather than an SCL. Cheers, Nick. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect From hhorak at redhat.com Wed Jul 29 08:04:24 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 29 Jul 2015 10:04:24 +0200 Subject: [scl.org] Update where we are with SCLo SIG Message-ID: <55B88908.9080805@redhat.com> A small update for anybody who didn't follow the discussions last weeks around Software Collections in CentOS. Since we got quite a lot requests for devtoolset-3, we started with this collection. That one also requires the most problematic collections maven30 and rh-java-common, that are quite challenging to be rebuilt. Some packages that do not require java packages are already built in cbs.centos.org and available in this repo: http://cbs.centos.org/repos/sclo7-devtoolset-3-sclo-release/x86_64/os/ In order to accomplish the successful rebuilding of all packages we decided to import binary packages into cbs.centos.org as an external repo and rebuild the collections using those packages. Great news from today is it seems the imported packages work -- I was able to build the package devtoolset-3-apache-commons-el that during build needed a package not build in CBS yet (devtoolset-3-hamcrest, successfully used from the imported set). Completing my action items from last meeting: Task bug for creating tags for maven30 and rh-java-common collections: https://bugs.centos.org/view.php?id=9150 Task bug for creating components in dist-git for collections maven30, rh-java-common and devtoolset-3: https://bugs.centos.org/view.php?id=9151 The next step now is to rebuild those three collections using the external repo, while storing the sources into git.centos.org already. Branches for those packages will follow patterns described at http://wiki.centos.org/BrianStinson/GitBranchesandKojiTags, which means e.g. packages for devtoolset-3 will use branch sig-sclo7-devtoolset-3-sclo. Look-aside cache is still not ready, but Fedora's look-aside cache should be fine enough in most cases. Honza From hhorak at redhat.com Wed Jul 29 12:32:44 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 29 Jul 2015 14:32:44 +0200 Subject: [scl.org] Update where we are with SCLo SIG In-Reply-To: <55B88908.9080805@redhat.com> References: <55B88908.9080805@redhat.com> Message-ID: <55B8C7EC.9090500@redhat.com> On 07/29/2015 10:04 AM, Honza Horak wrote: > The next step now is to rebuild those three collections using the > external repo, while storing the sources into git.centos.org already. > > Branches for those packages will follow patterns described at > http://wiki.centos.org/BrianStinson/GitBranchesandKojiTags, which means > e.g. packages for devtoolset-3 will use branch sig-sclo7-devtoolset-3-sclo. Actually since those are pure rebuilds of RHSCL content, we should use -rh as , so it will be rather sig-sclo7-devtoolset-3-rh. > Look-aside cache is still not ready, but Fedora's look-aside cache > should be fine enough in most cases. Some further information how I suppose we can continue with rebuilding, which can also serve as a basic how-to for anybody who would like to help with rebuilding collections: 1) become SCLo sig member if you are not yet http://wiki.centos.org/SpecialInterestGroup/SCLo#head-b6cbebda05530f216acf06e14f8c473a01750ed9 2) get srpm from software collections (list of repositories attached) e.g. repoquery --repofrompath=r,https://www.softwarecollections.org/repos/rhscl/maven30/epel-7-x86_64 --repoid=r maven30-cglib --arch src --location 3) during bootstraping we should use 0.x. as Release in RPM, so we don't produce newer packages than the original NVRs are (1) 4) import the spec/patches into dist-git 5) create srpm from dist-git e.g. by using fedora look-aside cache: fedpkg --dist .rpmbuild -bs --define "scl devtoolset-3" --define 'dist .el7' ~/rpmbuild/SPECS/gcc.spec 6) build the package in cbs.centos.org koji -c /etc/koji.conf.d/cbs-koji.conf add-pkg sclo7-devtoolset-3-rh-candidate --owner=sclo devtoolset-3-memstomp koji -c /etc/koji.conf.d/cbs-koji.conf build sclo7-devtoolset-3-rh-el7 /home/hhorak/rpmbuild/SRPMS/devtoolset-3-memstomp-0.1.5-0.2.el7.src.rpm My /etc/koji.conf.d/cbs-koji.conf also attached. (1) cbs.centos.org doesn't allow to build one package twice with the same NVR. RHSCL product and softwarecollections.org packages already use some NVR. Since we bootstrap the collections, we don't want to produce newer packages (higher NVR) then what is already provided in RHSCL product and softwarecollections.org. Therefore I think we need to use 0.x. as Release in RPMs we will rebuild, where x is just increasing integer. Once we're sure the package is being built properly, we can use the original Release number. Not all above was tested yet. I'll probably do some real work next week, but wanted to share the desired steps if anybody has some ideas or see some issues in the above. Honza -------------- next part -------------- https://www.softwarecollections.org/repos/rhscl/devassist09/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/devtoolset-3/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/git19/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/httpd24/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/mariadb55/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/maven30/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/mongodb24/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/mysql55/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/nginx14/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/nginx16/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/nodejs010/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/perl516/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/php54/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/php55/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/postgresql92/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/python27/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/python33/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-java-common/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-mariadb100/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-mongodb26/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-mysql56/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-passenger40/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-perl520/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-php56/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-postgresql94/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-python34/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-ror41/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/rh-ruby22/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/ror40/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/ruby193/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/ruby200/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/thermostat1/epel-7-x86_64 https://www.softwarecollections.org/repos/rhscl/v8314/epel-7-x86_64 -------------- next part -------------- [koji] ;url of XMLRPC server server = https://cbs.centos.org/kojihub/ ;url of web interface weburl = https://cbs.centos.org/koji ;url of package download site topurl = https://cbs.centos.org/kojifiles ;path to the koji top directory topdir = /mnt/koji ;client certificate cert = ~/.kojicentos/client.crt ;certificate of the CA that issued the client certificate ca = ~/.kojicentos/clientca.crt ;certificate of the CA that issued the HTTP server certificate serverca = ~/.kojicentos/serverca.crt