From langdon at redhat.com Mon Jan 4 20:22:57 2016 From: langdon at redhat.com (Langdon White) Date: Mon, 4 Jan 2016 15:22:57 -0500 Subject: [scl.org] 2 questions on software collections In-Reply-To: References: Message-ID: <568AD4A1.8050200@redhat.com> On 12/26/2015 04:07 AM, Natxo Asenjo wrote: > hi, > > 1st: foor rhel/centos 6 are software collections only available for 64 > bit arch or are there plans for i686 too? > As far as Red Hat is concerned, we make decisions like this based on customer feedback. If you are a customer, feel free to file a bug/RFE through your usual channels and follow the PR announcements regarding plans. However, we are not the only contributors, so other people may plan to do i686 versions. > 2nd: how do I switch permanently to the version of the sotfware > collection for a user? If I run > > $ scl enable rh-perl520 bash > after logging off and on I get back to system perl version. Adding > that line to ~/.bash_profile seems to do the trick. Is this the > correct way to do it? > I wrote a quick blog post about this some time back. I think this is still something we would like to see a better solution(s) for. http://developerblog.redhat.com/2014/03/19/permanently-enable-a-software-collection/ > Thanks for the software collection effort, it's going to be very helpful. > Glad you like them.. please help us promote them by mentioning them on social media, write blog posts, tell your friends, etc! Langdon > -- > Groeten, > natxo > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From hhorak at redhat.com Tue Jan 5 15:22:49 2016 From: hhorak at redhat.com (Honza Horak) Date: Tue, 5 Jan 2016 16:22:49 +0100 Subject: [scl.org] Solution for softwarecollections.org troubles In-Reply-To: <56715009.40606@cleal.org> References: <5665E845.4020408@redhat.com> <56715009.40606@cleal.org> Message-ID: <568BDFC9.9090803@redhat.com> On 12/16/2015 12:50 PM, Dominic Cleal wrote: > On 07/12/15 20:12, Honza Horak wrote: >> Most of the software collections (SCL), that are available on >> softwarecollections.org, are now built in cbs.centos.org and the plan >> was to promote those builds quite soon as official community builds of SCLs. >> >> Since the website softwarecollections.org has experienced troubles these >> days, I believe we can officially suggest using builds from CentOS Build >> System as the solution -- not only for now, but also for the future, >> because it would happen anyway. >> >> The software collection packages are now available on CentOS mirrors and >> you can install the repo RPM this way: >> >> $ sudo yum install centos-release-scl >> >> (repo package is available for centos6 [1] or centos7 [2]) >> >> Then, you can install particular collections: >> >> $ sudo yum install rh-ruby22 rh-ror41 >> >> Official announcements for the CentOS hosted collections will follow in >> couple of next days, but you are safe to use the collections now already. > > Will the EL6 package here[1] be pushed to Extras soon? > > It's currently marked with a candidate tag, and while the EL7 version's > on the mirrors, the EL6 one isn't. Only the old capitalised > "centos-release-SCL" package, pointing to the pre-sclo repos exists. As you probably noticed, this has been already fixed some time ago and package is available in CentOS 6 as well. I've just forgot to reply here. Honza From davejohansen at gmail.com Tue Jan 5 15:24:12 2016 From: davejohansen at gmail.com (Dave Johansen) Date: Tue, 5 Jan 2016 08:24:12 -0700 Subject: [scl.org] devtoolset 2? Message-ID: I know that devtoolset 3 is available in softwarecollections.org, but I would like to be able to use devtoolset 2 on EL 6 because it is the same version of gcc that comes with EL 7. Is anyone interested in or working on getting devtoolset 2 setup? What can I do to help get that done? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Tue Jan 5 15:30:41 2016 From: hhorak at redhat.com (Honza Horak) Date: Tue, 5 Jan 2016 16:30:41 +0100 Subject: [scl.org] devtoolset 2? In-Reply-To: References: Message-ID: <568BE1A1.8060207@redhat.com> Interesting, you're first who asks for that. Currently, there is nobody working on it. If you're willing to try that, I wouldn't be against, I just must warn you that rebuilding devtoolset is always a lot of fun (like https://www.redhat.com/archives/sclorg/2015-December/msg00050.html).. Honza On 01/05/2016 04:24 PM, Dave Johansen wrote: > I know that devtoolset 3 is available in softwarecollections.org > , but I would like to be able to use > devtoolset 2 on EL 6 because it is the same version of gcc that comes > with EL 7. > > Is anyone interested in or working on getting devtoolset 2 setup? > What can I do to help get that done? > > Thanks, > Dave > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Tue Jan 5 15:49:22 2016 From: hhorak at redhat.com (Honza Horak) Date: Tue, 5 Jan 2016 16:49:22 +0100 Subject: [scl.org] 2 questions on software collections In-Reply-To: <568AD4A1.8050200@redhat.com> References: <568AD4A1.8050200@redhat.com> Message-ID: <568BE602.7070206@redhat.com> On 01/04/2016 09:22 PM, Langdon White wrote: > > > On 12/26/2015 04:07 AM, Natxo Asenjo wrote: >> hi, >> >> 1st: foor rhel/centos 6 are software collections only available for 64 >> bit arch or are there plans for i686 too? >> > > As far as Red Hat is concerned, we make decisions like this based on > customer feedback. If you are a customer, feel free to file a bug/RFE > through your usual channels and follow the PR announcements regarding > plans. However, we are not the only contributors, so other people may > plan to do i686 versions. Based on my experience with rebuilding collections for x86_64, where we could use already existing builds for bootstrapping, rebuilding for i686 would be quite challenging, because everything would have to be bootstrapped from scratch. But I don't want to scare anybody, if there is enough demand, I definitely won't be against, it would just need a lot of work. >> 2nd: how do I switch permanently to the version of the sotfware >> collection for a user? If I run >> >> $ scl enable rh-perl520 bash >> after logging off and on I get back to system perl version. Adding >> that line to ~/.bash_profile seems to do the trick. Is this the >> correct way to do it? >> > > I wrote a quick blog post about this some time back. I think this is > still something we would like to see a better solution(s) for. > > http://developerblog.redhat.com/2014/03/19/permanently-enable-a-software-collection/ We should update this article to use rather the following: source scl_source enable python33 instead of: source /opt/rh/python33/enable export X_SCLS="`scl enable python33 'echo $X_SCLS'`" Because X_SCLS is not considered to be API, so it might be potentially changed in the future. This whole issue is slightly better implemented in scl-utils 2.0, which are in Fedora right now, but because of backward incompatibility we couldn't update scl-utils in EL 6 and 7. Honza >> Thanks for the software collection effort, it's going to be very helpful. >> > > Glad you like them.. please help us promote them by mentioning them on > social media, write blog posts, tell your friends, etc! > > Langdon > >> -- >> Groeten, >> natxo >> >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From jperrin at centos.org Tue Jan 5 16:00:48 2016 From: jperrin at centos.org (Jim Perrin) Date: Tue, 5 Jan 2016 10:00:48 -0600 Subject: [scl.org] 2 questions on software collections In-Reply-To: <568AD4A1.8050200@redhat.com> References: <568AD4A1.8050200@redhat.com> Message-ID: <568BE8B0.40701@centos.org> On 01/04/2016 02:22 PM, Langdon White wrote: >> 2nd: how do I switch permanently to the version of the sotfware >> collection for a user? If I run >> >> $ scl enable rh-perl520 bash >> after logging off and on I get back to system perl version. Adding >> that line to ~/.bash_profile seems to do the trick. Is this the >> correct way to do it? >> > > I wrote a quick blog post about this some time back. I think this is > still something we would like to see a better solution(s) for. > > http://developerblog.redhat.com/2014/03/19/permanently-enable-a-software-collection/ > It would be interesting to see if it's possible to easily expand the scope of the alternatives framework to include scls. This way admins could take what they already use for java and use it to manage scl version choices as well. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From langdon at redhat.com Tue Jan 5 16:22:34 2016 From: langdon at redhat.com (Langdon White) Date: Tue, 5 Jan 2016 11:22:34 -0500 Subject: [scl.org] 2 questions on software collections In-Reply-To: <568BE8B0.40701@centos.org> References: <568AD4A1.8050200@redhat.com> <568BE8B0.40701@centos.org> Message-ID: <568BEDCA.6060808@redhat.com> On 01/05/2016 11:00 AM, Jim Perrin wrote: > > On 01/04/2016 02:22 PM, Langdon White wrote: > >>> 2nd: how do I switch permanently to the version of the sotfware >>> collection for a user? If I run >>> >>> $ scl enable rh-perl520 bash >>> after logging off and on I get back to system perl version. Adding >>> that line to ~/.bash_profile seems to do the trick. Is this the >>> correct way to do it? >>> >> I wrote a quick blog post about this some time back. I think this is >> still something we would like to see a better solution(s) for. >> >> http://developerblog.redhat.com/2014/03/19/permanently-enable-a-software-collection/ >> > > It would be interesting to see if it's possible to easily expand the > scope of the alternatives framework to include scls. This way admins > could take what they already use for java and use it to manage scl > version choices as well. > Yeah.. I have thought about that a bunch too.. but haven't had a chance to look at it... I know some people have had success with mucking about using environment modules (IIRC the name), ncoghlan comes to mind.... langdon From davejohansen at gmail.com Tue Jan 5 15:35:44 2016 From: davejohansen at gmail.com (Dave Johansen) Date: Tue, 5 Jan 2016 08:35:44 -0700 Subject: [scl.org] devtoolset 2? In-Reply-To: <568BE1A1.8060207@redhat.com> References: <568BE1A1.8060207@redhat.com> Message-ID: On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak wrote: > Interesting, you're first who asks for that. Currently, there is nobody > working on it. > We're working on moving to EL 7, but still need to support EL 6 installations. We'd also like to start allowing use of C++11 in our code base and using the same version of gcc on both EL 6 and 7 seemed like the best way to accomplish both of these goals. > If you're willing to try that, I wouldn't be against, I just must warn you > that rebuilding devtoolset is always a lot of fun (like > https://www.redhat.com/archives/sclorg/2015-December/msg00050.html).. > What's the best way to start this? Are there modifications that are required for source .rpm (removing RedHat naming, etc)? Or is it just start building it and dealing with the issues that pop up? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Tue Jan 5 20:12:03 2016 From: hhorak at redhat.com (Honza Horak) Date: Tue, 5 Jan 2016 21:12:03 +0100 Subject: [scl.org] How to migrate to CentOS builds Message-ID: <568C2393.1080107@redhat.com> Currently, all the collections from RHSCL 2.1 have been released and announced. The website softwarecollections.org already includes steps to install those SCLs by running `yum install centos-release-scl-rh`. However, the original repo packages are still there as well, because removing them would break users' settings (as we saw recently when the website got down). I'd like to find out a way to migrate to CentOS builds. Many users use the repository packages from scl.org now, so simply removing those packages from scl.org right now is not an option. One idea with a relative schedule could be: day 0: make the repository packages deprecated by adding a comment about it on scl.org (+ make some noise around it on ML, twitter, blogs...) day 0+30: hide the repository packages on scl.org and only show `yum install centos-release-scl-rh` there day 0+90: remove the repository packages This way people who care should have enough time to move their infrastructure to using `yum install centos-release-scl-rh` instead of `yum install https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm`, but those who wouldn't notice would have problems. Another way would be replacing the repository packages by empty RPMs that would include centos-release-scl-rh package. This way the movement would be transparent for all users, but I'm not sure whether this is a good way to go, because people would start using another builds without notice. Well, at least it shouldn't break anything. I'd like to hear any opinions, or other alternatives, especially from SCL users. Thanks! Honza From noah at coderanger.net Tue Jan 5 20:13:59 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Tue, 5 Jan 2016 12:13:59 -0800 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568C2393.1080107@redhat.com> References: <568C2393.1080107@redhat.com> Message-ID: <9A7EFFB0-32DE-40B7-8D5D-C50A4B055645@coderanger.net> > On Jan 5, 2016, at 12:12 PM, Honza Horak wrote: > > Currently, all the collections from RHSCL 2.1 have been released and announced. The website softwarecollections.org already includes steps to install those SCLs by running `yum install centos-release-scl-rh`. > > However, the original repo packages are still there as well, because removing them would break users' settings (as we saw recently when the website got down). I'd like to find out a way to migrate to CentOS builds. > > Many users use the repository packages from scl.org now, so simply removing those packages from scl.org right now is not an option. One idea with a relative schedule could be: > > day 0: make the repository packages deprecated by adding a comment about it on scl.org (+ make some noise around it on ML, twitter, blogs...) > day 0+30: hide the repository packages on scl.org and only show `yum install centos-release-scl-rh` there > day 0+90: remove the repository packages > > This way people who care should have enough time to move their infrastructure to using `yum install centos-release-scl-rh` instead of `yum install https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm`, but those who wouldn't notice would have problems. > > Another way would be replacing the repository packages by empty RPMs that would include centos-release-scl-rh package. This way the movement would be transparent for all users, but I'm not sure whether this is a good way to go, because people would start using another builds without notice. Well, at least it shouldn't break anything. > > I'd like to hear any opinions, or other alternatives, especially from SCL users. How does any of this work for people using SCL on actual RHEL, not CentOS? --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From msrb at redhat.com Wed Jan 6 09:58:13 2016 From: msrb at redhat.com (Michal Srb) Date: Wed, 06 Jan 2016 10:58:13 +0100 Subject: [scl.org] problems with rebuilding devtoolset-4 (tycho on centos7) In-Reply-To: <567AA345.1080407@redhat.com> References: <567AA345.1080407@redhat.com> Message-ID: <1452074293.4846.35.camel@redhat.com> Hi, On Wed, 2015-12-23 at 14:36 +0100, Honza Horak wrote: > We have some issues with packages devtoolset-4-tycho and > devtoolset-4-sqt-chart when trying to rebuild devtoolset-4 in centos. > > For centos 6 it went ok, for centos7 we see build errors once we set > %bootstrap macro to 0: > > http://cbs.centos.org/koji/taskinfo?taskID=61162 It looks like java-1.8.0-openjdk-devel is being used during the build: [ERROR] Command line was: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/../bin/javadoc @options @packages JDK8 is more strict than JDK7 when generating javadocs and I think this causes the problem here. The problem is that both JDK7 and JDK8 are in the buildroot and since September of the last year, JDK8 has higher priority than JDK7 ("alternatives" are involved). The workaround could be to build the package with older java-1.8.0-openjdk (java-1.8.0-openjdk-1.8.0.60-2.b27) in the buildroot. Is untagging an option? Regards, Michal > > I suspect the tycho being not properly build without bootstrap can cause > also the swt-chart build error: > > http://cbs.centos.org/koji/taskinfo?taskID=61178 > > Except many errors in tycho build log like this: > > [INFO] Tycho (Incubation) ................................ FAILURE [10.901s] > > ... > > [ERROR] public File getLocation(); > [ERROR] ^ > [ERROR] > /builddir/build/BUILD/org.eclipse.tycho-tycho-0.23.0/tycho-bundles/org.eclipse.tycho.embedder.shared/src/main/java/org/eclipse/tycho/ArtifactDescriptor.java:34: > error: unknown tag: TODO > [ERROR] * @TODO should come from separate ReactorArtifactDescriptor > [ERROR] ^ > [ERROR] > /builddir/build/BUILD/org.eclipse.tycho-tycho-0.23.0/tycho-bundles/org.eclipse.tycho.embedder.shared/src/main/java/org/eclipse/tycho/ArtifactDescriptor.java:36: > warning: no @return > > ... > > I see some suspicious error before: > > ... > > [INFO] Mojo extractor for language: java-annotations found 11 mojo > descriptors. > line 2 column 68 - Error: plugin is not recognized! > > ... > > Not sure if this ^ one is causing the troubles though. > > Full build log is available at: > http://cbs.centos.org/kojifiles/work/tasks/1164/61164/build.log > > I'd be very glad for any help, because I'm already out of ideas. > > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From hhorak at redhat.com Wed Jan 6 12:54:00 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 13:54:00 +0100 Subject: [scl.org] problems with rebuilding devtoolset-4 (tycho on centos7) In-Reply-To: <1452074293.4846.35.camel@redhat.com> References: <567AA345.1080407@redhat.com> <1452074293.4846.35.camel@redhat.com> Message-ID: <568D0E68.3030205@redhat.com> Thanks for the hint. Maybe we can use another java version, but I'd rather turn off the check, if that is something what was not done before. Honza On 01/06/2016 10:58 AM, Michal Srb wrote: > Hi, > > On Wed, 2015-12-23 at 14:36 +0100, Honza Horak wrote: >> We have some issues with packages devtoolset-4-tycho and >> devtoolset-4-sqt-chart when trying to rebuild devtoolset-4 in centos. >> >> For centos 6 it went ok, for centos7 we see build errors once we set >> %bootstrap macro to 0: >> >> http://cbs.centos.org/koji/taskinfo?taskID=61162 > > It looks like java-1.8.0-openjdk-devel is being used during the build: > [ERROR] Command line > was: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/../bin/javadoc @options @packages > > JDK8 is more strict than JDK7 when generating javadocs and I think this > causes the problem here. > > The problem is that both JDK7 and JDK8 are in the buildroot and since > September of the last year, JDK8 has higher priority than JDK7 > ("alternatives" are involved). > > The workaround could be to build the package with older > java-1.8.0-openjdk (java-1.8.0-openjdk-1.8.0.60-2.b27) in the buildroot. > Is untagging an option? > > Regards, > Michal > >> >> I suspect the tycho being not properly build without bootstrap can cause >> also the swt-chart build error: >> >> http://cbs.centos.org/koji/taskinfo?taskID=61178 >> >> Except many errors in tycho build log like this: >> >> [INFO] Tycho (Incubation) ................................ FAILURE [10.901s] >> >> ... >> >> [ERROR] public File getLocation(); >> [ERROR] ^ >> [ERROR] >> /builddir/build/BUILD/org.eclipse.tycho-tycho-0.23.0/tycho-bundles/org.eclipse.tycho.embedder.shared/src/main/java/org/eclipse/tycho/ArtifactDescriptor.java:34: >> error: unknown tag: TODO >> [ERROR] * @TODO should come from separate ReactorArtifactDescriptor >> [ERROR] ^ >> [ERROR] >> /builddir/build/BUILD/org.eclipse.tycho-tycho-0.23.0/tycho-bundles/org.eclipse.tycho.embedder.shared/src/main/java/org/eclipse/tycho/ArtifactDescriptor.java:36: >> warning: no @return >> >> ... >> >> I see some suspicious error before: >> >> ... >> >> [INFO] Mojo extractor for language: java-annotations found 11 mojo >> descriptors. >> line 2 column 68 - Error: plugin is not recognized! >> >> ... >> >> Not sure if this ^ one is causing the troubles though. >> >> Full build log is available at: >> http://cbs.centos.org/kojifiles/work/tasks/1164/61164/build.log >> >> I'd be very glad for any help, because I'm already out of ideas. >> >> Honza >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg > > From hhorak at redhat.com Wed Jan 6 12:58:05 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 13:58:05 +0100 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <9A7EFFB0-32DE-40B7-8D5D-C50A4B055645@coderanger.net> References: <568C2393.1080107@redhat.com> <9A7EFFB0-32DE-40B7-8D5D-C50A4B055645@coderanger.net> Message-ID: <568D0F5D.1030302@redhat.com> On 01/05/2016 09:13 PM, Noah Kantrowitz wrote: > >> On Jan 5, 2016, at 12:12 PM, Honza Horak wrote: >> >> Currently, all the collections from RHSCL 2.1 have been released and announced. The website softwarecollections.org already includes steps to install those SCLs by running `yum install centos-release-scl-rh`. >> >> However, the original repo packages are still there as well, because removing them would break users' settings (as we saw recently when the website got down). I'd like to find out a way to migrate to CentOS builds. >> >> Many users use the repository packages from scl.org now, so simply removing those packages from scl.org right now is not an option. One idea with a relative schedule could be: >> >> day 0: make the repository packages deprecated by adding a comment about it on scl.org (+ make some noise around it on ML, twitter, blogs...) >> day 0+30: hide the repository packages on scl.org and only show `yum install centos-release-scl-rh` there >> day 0+90: remove the repository packages >> >> This way people who care should have enough time to move their infrastructure to using `yum install centos-release-scl-rh` instead of `yum install https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm`, but those who wouldn't notice would have problems. >> >> Another way would be replacing the repository packages by empty RPMs that would include centos-release-scl-rh package. This way the movement would be transparent for all users, but I'm not sure whether this is a good way to go, because people would start using another builds without notice. Well, at least it shouldn't break anything. >> >> I'd like to hear any opinions, or other alternatives, especially from SCL users. > > How does any of this work for people using SCL on actual RHEL, not CentOS? On RHEL people don't use builds from COPR, so they are not influenced. Honza From hhorak at redhat.com Wed Jan 6 13:10:02 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 14:10:02 +0100 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: References: <568C2393.1080107@redhat.com> Message-ID: <568D122A.1030809@redhat.com> On 01/05/2016 10:16 PM, Stephen John Smoogen wrote: > On 5 January 2016 at 13:12, Honza Horak wrote: >> https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm > > > Is there a way to update that file to point to the new repository > layout. That way when people do an update they will get pointed to the > correct trees? That was basically the second solution, just purely described. What I meant by "empty RPMs that would include centos-release-scl-rh package", I basically meant: rhscl--epel-7-x86_64.noarch.rpm package would not include the repo file, but would include Requires: centos-release-scl-rh. By updating the rhscl--epel-7-x86_64.noarch.rpm file, users would get proper trees. Honza From hhorak at redhat.com Wed Jan 6 13:27:16 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 14:27:16 +0100 Subject: [scl.org] 2 questions on software collections In-Reply-To: <568BEDCA.6060808@redhat.com> References: <568AD4A1.8050200@redhat.com> <568BE8B0.40701@centos.org> <568BEDCA.6060808@redhat.com> Message-ID: <568D1634.3060603@redhat.com> On 01/05/2016 05:22 PM, Langdon White wrote: > > > On 01/05/2016 11:00 AM, Jim Perrin wrote: >> >> On 01/04/2016 02:22 PM, Langdon White wrote: >> >>>> 2nd: how do I switch permanently to the version of the sotfware >>>> collection for a user? If I run >>>> >>>> $ scl enable rh-perl520 bash >>>> after logging off and on I get back to system perl version. Adding >>>> that line to ~/.bash_profile seems to do the trick. Is this the >>>> correct way to do it? >>>> >>> I wrote a quick blog post about this some time back. I think this is >>> still something we would like to see a better solution(s) for. >>> >>> http://developerblog.redhat.com/2014/03/19/permanently-enable-a-software-collection/ >>> >>> >> >> It would be interesting to see if it's possible to easily expand the >> scope of the alternatives framework to include scls. This way admins >> could take what they already use for java and use it to manage scl >> version choices as well. >> > > Yeah.. I have thought about that a bunch too.. but haven't had a chance > to look at it... > > I know some people have had success with mucking about using environment > modules (IIRC the name), ncoghlan comes to mind.... Environment modules is the implementation behind the newer scl-utils 2.0 (available just in Fedora, not RHEL yet). With that, something like this should be possible to do: module initadd The `alternatives` is not something I'd recommend, because that is based on creating system-wide symlinks. So, e.g. creating /usr/bin/python that would be actually python SCL binary (or wrapper) is not a good thing to do. That is not how SCLs were designed to be used. SCLs were designed to be used only when someone asks for `python`, but /usr/bin/python should always point to system python. Honza From dominic at cleal.org Wed Jan 6 13:39:34 2016 From: dominic at cleal.org (Dominic Cleal) Date: Wed, 6 Jan 2016 13:39:34 +0000 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568D122A.1030809@redhat.com> References: <568C2393.1080107@redhat.com> <568D122A.1030809@redhat.com> Message-ID: <568D1916.7020004@cleal.org> On 06/01/16 13:10, Honza Horak wrote: > On 01/05/2016 10:16 PM, Stephen John Smoogen wrote: >> On 5 January 2016 at 13:12, Honza Horak wrote: >>> https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm >> >> >> Is there a way to update that file to point to the new repository >> layout. That way when people do an update they will get pointed to the >> correct trees? > > That was basically the second solution, just purely described. What I > meant by "empty RPMs that would include centos-release-scl-rh package", > I basically meant: rhscl--epel-7-x86_64.noarch.rpm package would > not include the repo file, but would include Requires: > centos-release-scl-rh. By updating the > rhscl--epel-7-x86_64.noarch.rpm file, users would get proper trees. This would only work on CentOS with Extras enabled though. I'm a little concerned about other rebuilds, e.g. Scientific or Oracle - would those users even want to use CentOS builds? -- Dominic Cleal dominic at cleal.org From langdon at redhat.com Wed Jan 6 14:00:55 2016 From: langdon at redhat.com (Langdon White) Date: Wed, 6 Jan 2016 09:00:55 -0500 Subject: [scl.org] 2 questions on software collections In-Reply-To: <568D1634.3060603@redhat.com> References: <568AD4A1.8050200@redhat.com> <568BE8B0.40701@centos.org> <568BEDCA.6060808@redhat.com> <568D1634.3060603@redhat.com> Message-ID: <568D1E17.7040500@redhat.com> On 01/06/2016 08:27 AM, Honza Horak wrote: > On 01/05/2016 05:22 PM, Langdon White wrote: >> >> >> On 01/05/2016 11:00 AM, Jim Perrin wrote: >>> >>> On 01/04/2016 02:22 PM, Langdon White wrote: >>> >>>>> 2nd: how do I switch permanently to the version of the sotfware >>>>> collection for a user? If I run >>>>> >>>>> $ scl enable rh-perl520 bash >>>>> after logging off and on I get back to system perl version. Adding >>>>> that line to ~/.bash_profile seems to do the trick. Is this the >>>>> correct way to do it? >>>>> >>>> I wrote a quick blog post about this some time back. I think this is >>>> still something we would like to see a better solution(s) for. >>>> >>>> http://developerblog.redhat.com/2014/03/19/permanently-enable-a-software-collection/ >>>> >>>> >>>> >>> >>> It would be interesting to see if it's possible to easily expand the >>> scope of the alternatives framework to include scls. This way admins >>> could take what they already use for java and use it to manage scl >>> version choices as well. >>> >> >> Yeah.. I have thought about that a bunch too.. but haven't had a chance >> to look at it... >> >> I know some people have had success with mucking about using environment >> modules (IIRC the name), ncoghlan comes to mind.... > > Environment modules is the implementation behind the newer scl-utils > 2.0 (available just in Fedora, not RHEL yet). With that, something > like this should be possible to do: > > module initadd > > The `alternatives` is not something I'd recommend, because that is > based on creating system-wide symlinks. So, e.g. creating > /usr/bin/python that would be actually python SCL binary (or wrapper) > is not a good thing to do. That is not how SCLs were designed to be > used. SCLs were designed to be used only when someone asks for > `python`, but /usr/bin/python should always point to system python. > Yeah, I think we tend to hyper-focus on the python use case, if we were talking ruby or apache it might be better. So, while it may never work for some scls (and I definitely know it is how it wasn't intended to be used) it might be worthwhile to investigate if it works. Even though it kinda flies in the face of "running two versions at the same time." langdon > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From hhorak at redhat.com Wed Jan 6 14:17:00 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 15:17:00 +0100 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568D1916.7020004@cleal.org> References: <568C2393.1080107@redhat.com> <568D122A.1030809@redhat.com> <568D1916.7020004@cleal.org> Message-ID: <568D21DC.8090705@redhat.com> On 01/06/2016 02:39 PM, Dominic Cleal wrote: > On 06/01/16 13:10, Honza Horak wrote: >> On 01/05/2016 10:16 PM, Stephen John Smoogen wrote: >>> On 5 January 2016 at 13:12, Honza Horak wrote: >>>> https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm >>> >>> >>> Is there a way to update that file to point to the new repository >>> layout. That way when people do an update they will get pointed to the >>> correct trees? >> >> That was basically the second solution, just purely described. What I >> meant by "empty RPMs that would include centos-release-scl-rh package", >> I basically meant: rhscl--epel-7-x86_64.noarch.rpm package would >> not include the repo file, but would include Requires: >> centos-release-scl-rh. By updating the >> rhscl--epel-7-x86_64.noarch.rpm file, users would get proper trees. > > This would only work on CentOS with Extras enabled though. I'm a little > concerned about other rebuilds, e.g. Scientific or Oracle - would those > users even want to use CentOS builds? Well, if we speak about SCL packages available on centos mirrors, we won't be able to maintain three copies anyway (one for RH users, one for centos, one for other) and btw. at least Scientific has own rebuilds, which I found just recently: http://ftp.scientificlinux.org/linux/scientific/7rolling/testing/x86_64/scl/ If the comment was just about how to enable the CentOS repositories in Scientific or Oracle, that is something different. That would mean we'd have to have a package in some different place than CentOS Extras, but with the same content as the package `centos-release-scl-rh`. Honza From dominic at cleal.org Wed Jan 6 14:23:25 2016 From: dominic at cleal.org (Dominic Cleal) Date: Wed, 6 Jan 2016 14:23:25 +0000 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568D21DC.8090705@redhat.com> References: <568C2393.1080107@redhat.com> <568D122A.1030809@redhat.com> <568D1916.7020004@cleal.org> <568D21DC.8090705@redhat.com> Message-ID: <568D235D.4050609@cleal.org> On 06/01/16 14:17, Honza Horak wrote: > On 01/06/2016 02:39 PM, Dominic Cleal wrote: >> On 06/01/16 13:10, Honza Horak wrote: >>> On 01/05/2016 10:16 PM, Stephen John Smoogen wrote: >>>> On 5 January 2016 at 13:12, Honza Horak wrote: >>>>> https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm >>>> >>>> >>>> Is there a way to update that file to point to the new repository >>>> layout. That way when people do an update they will get pointed to the >>>> correct trees? >>> >>> That was basically the second solution, just purely described. What I >>> meant by "empty RPMs that would include centos-release-scl-rh package", >>> I basically meant: rhscl--epel-7-x86_64.noarch.rpm package would >>> not include the repo file, but would include Requires: >>> centos-release-scl-rh. By updating the >>> rhscl--epel-7-x86_64.noarch.rpm file, users would get proper trees. >> >> This would only work on CentOS with Extras enabled though. I'm a little >> concerned about other rebuilds, e.g. Scientific or Oracle - would those >> users even want to use CentOS builds? > > Well, if we speak about SCL packages available on centos mirrors, we > won't be able to maintain three copies anyway (one for RH users, one for > centos, one for other) and btw. at least Scientific has own rebuilds, > which I found just recently: > > http://ftp.scientificlinux.org/linux/scientific/7rolling/testing/x86_64/scl/ > > If the comment was just about how to enable the CentOS repositories in > Scientific or Oracle, that is something different. That would mean we'd > have to have a package in some different place than CentOS Extras, but > with the same content as the package `centos-release-scl-rh`. Yes, I meant this latter part - if the rhscl-* release RPM gains a dependency on the CentOS SCLo release package then the package will only install on CentOS unless it's available to RHEL and its other rebuilds (perhaps add it to the scl.org repos). I think I'd prefer to see the repos remain but either prevent new downloads of the release file or affix a large warning to the web UI to ensure people realise it's unmaintained. -- Dominic Cleal dominic at cleal.org From dominic at cleal.org Wed Jan 6 14:28:43 2016 From: dominic at cleal.org (Dominic Cleal) Date: Wed, 6 Jan 2016 14:28:43 +0000 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568C2393.1080107@redhat.com> References: <568C2393.1080107@redhat.com> Message-ID: <568D249B.1050001@cleal.org> On 05/01/16 20:12, Honza Horak wrote: > day 0: make the repository packages deprecated by adding a comment about > it on scl.org (+ make some noise around it on ML, twitter, blogs...) > day 0+30: hide the repository packages on scl.org and only show `yum > install centos-release-scl-rh` there > day 0+90: remove the repository packages > > This way people who care should have enough time to move their > infrastructure to using `yum install centos-release-scl-rh` instead of > `yum install > https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm`, > but those who wouldn't notice would have problems. I'm keen to have as much time as possible before removing any packages, since we're still using them in the Foreman project. I plan on adopting the CentOS SCLo rebuilds soon, but not having packages that we're referring to in installation instructions and code disappear would be ideal, as updating our older releases is more work. -- Dominic Cleal dominic at cleal.org From hhorak at redhat.com Wed Jan 6 14:29:10 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 15:29:10 +0100 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568D235D.4050609@cleal.org> References: <568C2393.1080107@redhat.com> <568D122A.1030809@redhat.com> <568D1916.7020004@cleal.org> <568D21DC.8090705@redhat.com> <568D235D.4050609@cleal.org> Message-ID: <568D24B6.10606@redhat.com> On 01/06/2016 03:23 PM, Dominic Cleal wrote: > On 06/01/16 14:17, Honza Horak wrote: >> On 01/06/2016 02:39 PM, Dominic Cleal wrote: >>> On 06/01/16 13:10, Honza Horak wrote: >>>> On 01/05/2016 10:16 PM, Stephen John Smoogen wrote: >>>>> On 5 January 2016 at 13:12, Honza Horak wrote: >>>>>> https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm >>>>> >>>>> >>>>> Is there a way to update that file to point to the new repository >>>>> layout. That way when people do an update they will get pointed to the >>>>> correct trees? >>>> >>>> That was basically the second solution, just purely described. What I >>>> meant by "empty RPMs that would include centos-release-scl-rh package", >>>> I basically meant: rhscl--epel-7-x86_64.noarch.rpm package would >>>> not include the repo file, but would include Requires: >>>> centos-release-scl-rh. By updating the >>>> rhscl--epel-7-x86_64.noarch.rpm file, users would get proper trees. >>> >>> This would only work on CentOS with Extras enabled though. I'm a little >>> concerned about other rebuilds, e.g. Scientific or Oracle - would those >>> users even want to use CentOS builds? >> >> Well, if we speak about SCL packages available on centos mirrors, we >> won't be able to maintain three copies anyway (one for RH users, one for >> centos, one for other) and btw. at least Scientific has own rebuilds, >> which I found just recently: >> >> http://ftp.scientificlinux.org/linux/scientific/7rolling/testing/x86_64/scl/ >> >> If the comment was just about how to enable the CentOS repositories in >> Scientific or Oracle, that is something different. That would mean we'd >> have to have a package in some different place than CentOS Extras, but >> with the same content as the package `centos-release-scl-rh`. > > Yes, I meant this latter part - if the rhscl-* release RPM gains a > dependency on the CentOS SCLo release package then the package will only > install on CentOS unless it's available to RHEL and its other rebuilds > (perhaps add it to the scl.org repos). > > I think I'd prefer to see the repos remain but either prevent new > downloads of the release file or affix a large warning to the web UI to > ensure people realise it's unmaintained. Thanks for the feedback. I agree that the warning and at least hiding the current repo file to prevent newcomers to use it would be probably the safest and also much easier way. Honza From ppisar at redhat.com Wed Jan 6 14:47:51 2016 From: ppisar at redhat.com (Petr Pisar) Date: Wed, 6 Jan 2016 15:47:51 +0100 Subject: [scl.org] 2 questions on software collections In-Reply-To: <568D1E17.7040500@redhat.com> References: <568AD4A1.8050200@redhat.com> <568BE8B0.40701@centos.org> <568BEDCA.6060808@redhat.com> <568D1634.3060603@redhat.com> <568D1E17.7040500@redhat.com> Message-ID: <20160106144750.GE2374@dhcp-0-146.brq.redhat.com> On Wed, Jan 06, 2016 at 09:00:55AM -0500, Langdon White wrote: > >The `alternatives` is not something I'd recommend, because that is based > >on creating system-wide symlinks. So, e.g. creating /usr/bin/python that > >would be actually python SCL binary (or wrapper) is not a good thing to > >do. That is not how SCLs were designed to be used. SCLs were designed to > >be used only when someone asks for `python`, but /usr/bin/python should > >always point to system python. > > > > Yeah, I think we tend to hyper-focus on the python use case, if we were > talking ruby or apache it might be better. So, while it may never work for > some scls (and I definitely know it is how it wasn't intended to be used) it > might be worthwhile to investigate if it works. Even though it kinda flies > in the face of "running two versions at the same time." > Alternatives rewrite system files. Thus to active a change, you need a superuser and the change applies to all users, all processes, immediatelly. Therefore it's equivalent to uninstalling one package and installing another one. Ergo you do not need SCL for it. Just to package the new version. -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From hhorak at redhat.com Wed Jan 6 15:04:19 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 16:04:19 +0100 Subject: [scl.org] devtoolset 2? In-Reply-To: References: <568BE1A1.8060207@redhat.com> Message-ID: <568D2CF3.50900@redhat.com> On 01/05/2016 04:35 PM, Dave Johansen wrote: > On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak > wrote: > > Interesting, you're first who asks for that. Currently, there is > nobody working on it. > > > We're working on moving to EL 7, but still need to support EL 6 > installations. We'd also like to start allowing use of C++11 in our code > base and using the same version of gcc on both EL 6 and 7 seemed like > the best way to accomplish both of these goals. > > If you're willing to try that, I wouldn't be against, I just must > warn you that rebuilding devtoolset is always a lot of fun (like > https://www.redhat.com/archives/sclorg/2015-December/msg00050.html).. > > > What's the best way to start this? > Are there modifications that are required for source .rpm (removing > RedHat naming, etc)? Or is it just start building it and dealing with > the issues that pop up? There is no need to remove any naming, we usually take srpm from RH and rebuild. However, the bootstrapping is usually very challenging. I'd recommend first to try to rebuild at least basic packages yourself using mock (or copr), so you see how far you can get.. Then, if you'll see it is worth the work, we can create tags/targets in CBS and start with real rebuilds. Honza From msuchy at redhat.com Wed Jan 6 16:20:24 2016 From: msuchy at redhat.com (=?UTF-8?Q?Miroslav_Such=c3=bd?=) Date: Wed, 6 Jan 2016 17:20:24 +0100 Subject: [scl.org] Planned outage 2015-01-11 of website softwarecollection.org Message-ID: <568D3EC8.6050002@redhat.com> Hi, on Monday 2015-01-11 we plan to migrate softwarecollection.org website from its current temporary location to its final location. We plan to start at 08:00 UTC and migration should be done before 12:00 UTC. We plan to do that mostly online, but you may experience several minutes of unavailability. There will be also change of IP address. The new IP address will be 209.132.179.161. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From davejohansen at gmail.com Wed Jan 6 16:41:29 2016 From: davejohansen at gmail.com (Dave Johansen) Date: Wed, 6 Jan 2016 09:41:29 -0700 Subject: [scl.org] devtoolset 2? In-Reply-To: <568D2CF3.50900@redhat.com> References: <568BE1A1.8060207@redhat.com> <568D2CF3.50900@redhat.com> Message-ID: On Wed, Jan 6, 2016 at 8:04 AM, Honza Horak wrote: > On 01/05/2016 04:35 PM, Dave Johansen wrote: > >> On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak > > wrote: >> >> Interesting, you're first who asks for that. Currently, there is >> nobody working on it. >> >> >> We're working on moving to EL 7, but still need to support EL 6 >> installations. We'd also like to start allowing use of C++11 in our code >> base and using the same version of gcc on both EL 6 and 7 seemed like >> the best way to accomplish both of these goals. >> >> If you're willing to try that, I wouldn't be against, I just must >> warn you that rebuilding devtoolset is always a lot of fun (like >> https://www.redhat.com/archives/sclorg/2015-December/msg00050.html).. >> >> >> What's the best way to start this? >> Are there modifications that are required for source .rpm (removing >> RedHat naming, etc)? Or is it just start building it and dealing with >> the issues that pop up? >> > > There is no need to remove any naming, we usually take srpm from RH and > rebuild. However, the bootstrapping is usually very challenging. I'd > recommend first to try to rebuild at least basic packages yourself using > mock (or copr), so you see how far you can get.. Then, if you'll see it is > worth the work, we can create tags/targets in CBS and start with real > rebuilds. > I was just going to start playing around with this on COPR and I noticed that there appears to already be an existing build of devtoolset-2: https://copr.fedoraproject.org/coprs/rhscl/devtoolset/ It looks like it's not complete because only some of the packages succeeded, but would that serve as the best starting point? If so, what's the best way to move forward with that? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Wed Jan 6 16:44:00 2016 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 6 Jan 2016 16:44:00 +0000 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568D1916.7020004@cleal.org> References: <568C2393.1080107@redhat.com> <568D122A.1030809@redhat.com> <568D1916.7020004@cleal.org> Message-ID: <568D4450.7090106@karan.org> On 06/01/16 13:39, Dominic Cleal wrote: > > This would only work on CentOS with Extras enabled though. Just wanted to point out that Extras/ is always enabled by default, and does not overlap with base os packages. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Wed Jan 6 20:47:34 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 21:47:34 +0100 Subject: [scl.org] devtoolset 2? In-Reply-To: References: <568BE1A1.8060207@redhat.com> <568D2CF3.50900@redhat.com> Message-ID: <568D7D66.6090305@redhat.com> On 01/06/2016 05:41 PM, Dave Johansen wrote: > On Wed, Jan 6, 2016 at 8:04 AM, Honza Horak > wrote: > > On 01/05/2016 04:35 PM, Dave Johansen wrote: > > On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak > >> wrote: > > Interesting, you're first who asks for that. Currently, > there is > nobody working on it. > > > We're working on moving to EL 7, but still need to support EL 6 > installations. We'd also like to start allowing use of C++11 in > our code > base and using the same version of gcc on both EL 6 and 7 seemed > like > the best way to accomplish both of these goals. > > If you're willing to try that, I wouldn't be against, I > just must > warn you that rebuilding devtoolset is always a lot of fun > (like > https://www.redhat.com/archives/sclorg/2015-December/msg00050.html).. > > > What's the best way to start this? > Are there modifications that are required for source .rpm (removing > RedHat naming, etc)? Or is it just start building it and dealing > with > the issues that pop up? > > > There is no need to remove any naming, we usually take srpm from RH > and rebuild. However, the bootstrapping is usually very challenging. > I'd recommend first to try to rebuild at least basic packages > yourself using mock (or copr), so you see how far you can get.. > Then, if you'll see it is worth the work, we can create tags/targets > in CBS and start with real rebuilds. > > > I was just going to start playing around with this on COPR and I noticed > that there appears to already be an existing build of devtoolset-2: > https://copr.fedoraproject.org/coprs/rhscl/devtoolset/ > > It looks like it's not complete because only some of the packages > succeeded, but would that serve as the best starting point? If so, > what's the best way to move forward with that? Well, why not, I can add you as collaborator in this project -- what is your copr username? However, I'm afraid that whoever tried that, he got blocked on some non easy issues, which is the reason why it is not finished. Honza From hhorak at redhat.com Wed Jan 6 22:27:27 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 6 Jan 2016 23:27:27 +0100 Subject: [scl.org] problems with rebuilding devtoolset-4 (tycho on centos7) In-Reply-To: <568D0E68.3030205@redhat.com> References: <567AA345.1080407@redhat.com> <1452074293.4846.35.camel@redhat.com> <568D0E68.3030205@redhat.com> Message-ID: <568D94CF.8000703@redhat.com> I've tried my luck and this commit: https://github.com/sclorg-distgit/tycho/commit/36c6193ddac8bf6398418d0afb950cdaebd2bd64 works: https://cbs.centos.org/koji/taskinfo?taskID=62987 I'm not entirely sure whether it is the correct fix to use though. Honza On 01/06/2016 01:54 PM, Honza Horak wrote: > Thanks for the hint. Maybe we can use another java version, but I'd > rather turn off the check, if that is something what was not done before. > > Honza > > On 01/06/2016 10:58 AM, Michal Srb wrote: >> Hi, >> >> On Wed, 2015-12-23 at 14:36 +0100, Honza Horak wrote: >>> We have some issues with packages devtoolset-4-tycho and >>> devtoolset-4-sqt-chart when trying to rebuild devtoolset-4 in centos. >>> >>> For centos 6 it went ok, for centos7 we see build errors once we set >>> %bootstrap macro to 0: >>> >>> http://cbs.centos.org/koji/taskinfo?taskID=61162 >> >> It looks like java-1.8.0-openjdk-devel is being used during the build: >> [ERROR] Command line >> was: >> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre/../bin/javadoc >> @options @packages >> >> JDK8 is more strict than JDK7 when generating javadocs and I think this >> causes the problem here. >> >> The problem is that both JDK7 and JDK8 are in the buildroot and since >> September of the last year, JDK8 has higher priority than JDK7 >> ("alternatives" are involved). >> >> The workaround could be to build the package with older >> java-1.8.0-openjdk (java-1.8.0-openjdk-1.8.0.60-2.b27) in the buildroot. >> Is untagging an option? >> >> Regards, >> Michal >> >>> >>> I suspect the tycho being not properly build without bootstrap can cause >>> also the swt-chart build error: >>> >>> http://cbs.centos.org/koji/taskinfo?taskID=61178 >>> >>> Except many errors in tycho build log like this: >>> >>> [INFO] Tycho (Incubation) ................................ FAILURE >>> [10.901s] >>> >>> ... >>> >>> [ERROR] public File getLocation(); >>> [ERROR] ^ >>> [ERROR] >>> /builddir/build/BUILD/org.eclipse.tycho-tycho-0.23.0/tycho-bundles/org.eclipse.tycho.embedder.shared/src/main/java/org/eclipse/tycho/ArtifactDescriptor.java:34: >>> >>> error: unknown tag: TODO >>> [ERROR] * @TODO should come from separate ReactorArtifactDescriptor >>> [ERROR] ^ >>> [ERROR] >>> /builddir/build/BUILD/org.eclipse.tycho-tycho-0.23.0/tycho-bundles/org.eclipse.tycho.embedder.shared/src/main/java/org/eclipse/tycho/ArtifactDescriptor.java:36: >>> >>> warning: no @return >>> >>> ... >>> >>> I see some suspicious error before: >>> >>> ... >>> >>> [INFO] Mojo extractor for language: java-annotations found 11 mojo >>> descriptors. >>> line 2 column 68 - Error: plugin is not recognized! >>> >>> ... >>> >>> Not sure if this ^ one is causing the troubles though. >>> >>> Full build log is available at: >>> http://cbs.centos.org/kojifiles/work/tasks/1164/61164/build.log >>> >>> I'd be very glad for any help, because I'm already out of ideas. >>> >>> Honza >>> >>> _______________________________________________ >>> SCLorg mailing list >>> SCLorg at redhat.com >>> https://www.redhat.com/mailman/listinfo/sclorg >> >> From noah at coderanger.net Thu Jan 7 02:01:07 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Wed, 6 Jan 2016 18:01:07 -0800 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <568D0F5D.1030302@redhat.com> References: <568C2393.1080107@redhat.com> <9A7EFFB0-32DE-40B7-8D5D-C50A4B055645@coderanger.net> <568D0F5D.1030302@redhat.com> Message-ID: <0579517F-21E4-4326-AC3D-78150F1D602E@coderanger.net> > On Jan 6, 2016, at 4:58 AM, Honza Horak wrote: > > On 01/05/2016 09:13 PM, Noah Kantrowitz wrote: >> >>> On Jan 5, 2016, at 12:12 PM, Honza Horak wrote: >>> >>> Currently, all the collections from RHSCL 2.1 have been released and announced. The website softwarecollections.org already includes steps to install those SCLs by running `yum install centos-release-scl-rh`. >>> >>> However, the original repo packages are still there as well, because removing them would break users' settings (as we saw recently when the website got down). I'd like to find out a way to migrate to CentOS builds. >>> >>> Many users use the repository packages from scl.org now, so simply removing those packages from scl.org right now is not an option. One idea with a relative schedule could be: >>> >>> day 0: make the repository packages deprecated by adding a comment about it on scl.org (+ make some noise around it on ML, twitter, blogs...) >>> day 0+30: hide the repository packages on scl.org and only show `yum install centos-release-scl-rh` there >>> day 0+90: remove the repository packages >>> >>> This way people who care should have enough time to move their infrastructure to using `yum install centos-release-scl-rh` instead of `yum install https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm`, but those who wouldn't notice would have problems. >>> >>> Another way would be replacing the repository packages by empty RPMs that would include centos-release-scl-rh package. This way the movement would be transparent for all users, but I'm not sure whether this is a good way to go, because people would start using another builds without notice. Well, at least it shouldn't break anything. >>> >>> I'd like to hear any opinions, or other alternatives, especially from SCL users. >> >> How does any of this work for people using SCL on actual RHEL, not CentOS? > > On RHEL people don't use builds from COPR, so they are not influenced. Which repos are we talking about here? Because there aren't many other ways to get Python 3 or other recent-y things on RHEL 6/7. --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ppisar at redhat.com Thu Jan 7 06:43:00 2016 From: ppisar at redhat.com (Petr Pisar) Date: Thu, 7 Jan 2016 07:43:00 +0100 Subject: [scl.org] problems with rebuilding devtoolset-4 (tycho on centos7) In-Reply-To: <568D94CF.8000703@redhat.com> References: <567AA345.1080407@redhat.com> <1452074293.4846.35.camel@redhat.com> <568D0E68.3030205@redhat.com> <568D94CF.8000703@redhat.com> Message-ID: <20160107064259.GA2369@dhcp-0-146.brq.redhat.com> On Wed, Jan 06, 2016 at 11:27:27PM +0100, Honza Horak wrote: > I've tried my luck and this commit: > https://github.com/sclorg-distgit/tycho/commit/36c6193ddac8bf6398418d0afb950cdaebd2bd64 > > works: > https://cbs.centos.org/koji/taskinfo?taskID=62987 > > I'm not entirely sure whether it is the correct fix to use though. > Does that mean you still uses JDK 1.8 to compile the code? I worry that the bytecode is not backward compatible and you could encounter problems with running the code using JRE 1.7. -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From mizdebsk at redhat.com Thu Jan 7 08:00:08 2016 From: mizdebsk at redhat.com (Mikolaj Izdebski) Date: Thu, 7 Jan 2016 09:00:08 +0100 Subject: [scl.org] problems with rebuilding devtoolset-4 (tycho on centos7) In-Reply-To: <20160107064259.GA2369@dhcp-0-146.brq.redhat.com> References: <567AA345.1080407@redhat.com> <1452074293.4846.35.camel@redhat.com> <568D0E68.3030205@redhat.com> <568D94CF.8000703@redhat.com> <20160107064259.GA2369@dhcp-0-146.brq.redhat.com> Message-ID: <568E1B08.1010409@redhat.com> On 01/07/2016 07:43 AM, Petr Pisar wrote: > On Wed, Jan 06, 2016 at 11:27:27PM +0100, Honza Horak wrote: >> I've tried my luck and this commit: >> https://github.com/sclorg-distgit/tycho/commit/36c6193ddac8bf6398418d0afb950cdaebd2bd64 >> >> works: >> https://cbs.centos.org/koji/taskinfo?taskID=62987 >> >> I'm not entirely sure whether it is the correct fix to use though. This patch looks correct. IMHO the preferred long-term fix would be backporting the following upstream XMvn patch to maven30-xmvn, which effectively does the same thing, but affects all packages built with Maven: https://github.com/mizdebsk/xmvn/commit/a9cde0b > Does that mean you still uses JDK 1.8 to compile the code? I worry that the > bytecode is not backward compatible and you could encounter problems with > running the code using JRE 1.7. This shouldn't be a problem. First, most projects specify target execution environment and Maven generates bytecode in this specific version. If target is not specified then it defaults to 1.5. Secondly, tycho is a Maven plugin - it is used only for building other packages. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk From mizdebsk at redhat.com Thu Jan 7 08:35:10 2016 From: mizdebsk at redhat.com (Mikolaj Izdebski) Date: Thu, 7 Jan 2016 09:35:10 +0100 Subject: [scl.org] Introduction - Mikolaj Izdebski Message-ID: <568E233E.8050800@redhat.com> Hello, My name is Mikolaj Izdebski. I am one of developers of maven30 and rh-java-common software collections included in RHSCL. I am also Fedora packager and RHEL developer. I would like to join SCLo SIG in order to help with maintenance of existing Java collections and to work on packaging new ones, especially latest version of Maven. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk From hhorak at redhat.com Thu Jan 7 09:07:46 2016 From: hhorak at redhat.com (Honza Horak) Date: Thu, 7 Jan 2016 10:07:46 +0100 Subject: [scl.org] Introduction - Mikolaj Izdebski In-Reply-To: <568E233E.8050800@redhat.com> References: <568E233E.8050800@redhat.com> Message-ID: <568E2AE2.6010707@redhat.com> On 01/07/2016 09:35 AM, Mikolaj Izdebski wrote: > Hello, > > My name is Mikolaj Izdebski. I am one of developers of maven30 and > rh-java-common software collections included in RHSCL. I am also Fedora > packager and RHEL developer. > > I would like to join SCLo SIG in order to help with maintenance of > existing Java collections and to work on packaging new ones, especially > latest version of Maven. Thanks for joining, Mikolaj, giving my +1 as approval. Honza From hhorak at redhat.com Thu Jan 7 13:00:25 2016 From: hhorak at redhat.com (Honza Horak) Date: Thu, 7 Jan 2016 14:00:25 +0100 Subject: [scl.org] How to migrate to CentOS builds In-Reply-To: <0579517F-21E4-4326-AC3D-78150F1D602E@coderanger.net> References: <568C2393.1080107@redhat.com> <9A7EFFB0-32DE-40B7-8D5D-C50A4B055645@coderanger.net> <568D0F5D.1030302@redhat.com> <0579517F-21E4-4326-AC3D-78150F1D602E@coderanger.net> Message-ID: <568E6169.3010303@redhat.com> On 01/07/2016 03:01 AM, Noah Kantrowitz wrote: > >> On Jan 6, 2016, at 4:58 AM, Honza Horak wrote: >> >> On 01/05/2016 09:13 PM, Noah Kantrowitz wrote: >>> >>>> On Jan 5, 2016, at 12:12 PM, Honza Horak wrote: >>>> >>>> Currently, all the collections from RHSCL 2.1 have been released and announced. The website softwarecollections.org already includes steps to install those SCLs by running `yum install centos-release-scl-rh`. >>>> >>>> However, the original repo packages are still there as well, because removing them would break users' settings (as we saw recently when the website got down). I'd like to find out a way to migrate to CentOS builds. >>>> >>>> Many users use the repository packages from scl.org now, so simply removing those packages from scl.org right now is not an option. One idea with a relative schedule could be: >>>> >>>> day 0: make the repository packages deprecated by adding a comment about it on scl.org (+ make some noise around it on ML, twitter, blogs...) >>>> day 0+30: hide the repository packages on scl.org and only show `yum install centos-release-scl-rh` there >>>> day 0+90: remove the repository packages >>>> >>>> This way people who care should have enough time to move their infrastructure to using `yum install centos-release-scl-rh` instead of `yum install https://www.softwarecollections.org/.../rhscl--epel-7-x86_64.noarch.rpm`, but those who wouldn't notice would have problems. >>>> >>>> Another way would be replacing the repository packages by empty RPMs that would include centos-release-scl-rh package. This way the movement would be transparent for all users, but I'm not sure whether this is a good way to go, because people would start using another builds without notice. Well, at least it shouldn't break anything. >>>> >>>> I'd like to hear any opinions, or other alternatives, especially from SCL users. >>> >>> How does any of this work for people using SCL on actual RHEL, not CentOS? >> >> On RHEL people don't use builds from COPR, so they are not influenced. > > Which repos are we talking about here? Because there aren't many other ways to get Python 3 or other recent-y things on RHEL 6/7. I distinguish here between repositories provided by RH (which you gain access to using `yum-config-manager --enable rhel-server-rhscl-7-rpms` in RH and you need RHEL subscription for them) and rebuilds of the same packages for CentOS, which used to be build in Copr and now they are build in cbs.centos.org. This whole thread is only about the CentOS builds. Honza From msuchy at redhat.com Mon Jan 11 14:32:40 2016 From: msuchy at redhat.com (=?UTF-8?Q?Miroslav_Such=c3=bd?=) Date: Mon, 11 Jan 2016 15:32:40 +0100 Subject: [scl.org] Planned outage 2015-01-11 of website softwarecollection.org In-Reply-To: <568D3EC8.6050002@redhat.com> References: <568D3EC8.6050002@redhat.com> Message-ID: <5693BD08.2070908@redhat.com> Dne 6.1.2016 v 17:20 Miroslav Such? napsal(a): > Hi, > on Monday 2015-01-11 we plan to migrate softwarecollection.org website from its current temporary location to its final > location. > We plan to start at 08:00 UTC and migration should be done before 12:00 UTC. > We plan to do that mostly online, but you may experience several minutes of unavailability. > There will be also change of IP address. The new IP address will be 209.132.179.161. > The migration have been finished. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From davejohansen at gmail.com Wed Jan 13 04:14:45 2016 From: davejohansen at gmail.com (Dave Johansen) Date: Tue, 12 Jan 2016 21:14:45 -0700 Subject: [scl.org] devtoolset 2? In-Reply-To: <568D7D66.6090305@redhat.com> References: <568BE1A1.8060207@redhat.com> <568D2CF3.50900@redhat.com> <568D7D66.6090305@redhat.com> Message-ID: On Wed, Jan 6, 2016 at 1:47 PM, Honza Horak wrote: > On 01/06/2016 05:41 PM, Dave Johansen wrote: > >> On Wed, Jan 6, 2016 at 8:04 AM, Honza Horak > > wrote: >> >> On 01/05/2016 04:35 PM, Dave Johansen wrote: >> >> On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak > >> >> wrote: >> >> Interesting, you're first who asks for that. Currently, >> there is >> nobody working on it. >> >> >> We're working on moving to EL 7, but still need to support EL 6 >> installations. We'd also like to start allowing use of C++11 in >> our code >> base and using the same version of gcc on both EL 6 and 7 seemed >> like >> the best way to accomplish both of these goals. >> >> If you're willing to try that, I wouldn't be against, I >> just must >> warn you that rebuilding devtoolset is always a lot of fun >> (like >> >> https://www.redhat.com/archives/sclorg/2015-December/msg00050.html).. >> >> >> What's the best way to start this? >> Are there modifications that are required for source .rpm >> (removing >> RedHat naming, etc)? Or is it just start building it and dealing >> with >> the issues that pop up? >> >> >> There is no need to remove any naming, we usually take srpm from RH >> and rebuild. However, the bootstrapping is usually very challenging. >> I'd recommend first to try to rebuild at least basic packages >> yourself using mock (or copr), so you see how far you can get.. >> Then, if you'll see it is worth the work, we can create tags/targets >> in CBS and start with real rebuilds. >> >> >> I was just going to start playing around with this on COPR and I noticed >> that there appears to already be an existing build of devtoolset-2: >> https://copr.fedoraproject.org/coprs/rhscl/devtoolset/ >> >> It looks like it's not complete because only some of the packages >> succeeded, but would that serve as the best starting point? If so, >> what's the best way to move forward with that? >> > > Well, why not, I can add you as collaborator in this project -- what is > your copr username? However, I'm afraid that whoever tried that, he got > blocked on some non easy issues, which is the reason why it is not finished. > My username is daveisfera. Is there anything special that needs to be done to do these builds? Is there an original location for the source rpms? And is this COPR use those or some modification of them? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Wed Jan 13 14:59:27 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 13 Jan 2016 15:59:27 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) Message-ID: <5696664F.8010707@redhat.com> SCLo SIG meeting will be today at 16: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 = * devtoolset-4 rebuilding updates https://bugs.centos.org/view.php?id=10106 * review of how development of new scls is working rought proposal: building packages -> candidate -> sanity testing -> testing -> [wait till rhscl is released] -> tag released -> sign&release * Provides/Obsoletes to centos-release-scl * package for RHEL users that installs sclo packages above RHSCL Honza From hhorak at redhat.com Wed Jan 13 17:33:35 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 13 Jan 2016 18:33:35 +0100 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: <5696664F.8010707@redhat.com> References: <5696664F.8010707@redhat.com> Message-ID: <56968A6F.2030303@redhat.com> #topic devtoolset-4 rebuilding updates https://bugs.centos.org/view.php?id=10106 - bstinson plans to look at ^ in the evening hopefully - we're looking for a volunteer to write more tests for devtoolset-3/4 like https://github.com/sclorg/sclo-ci-tests/tree/master/collections/devtoolset-3-rh - and another volunteer to integrate tests from ^ to CentOS CI - #action Dominic and hhorak will talk after meeting about the tests and you then Dominic can do some magic in CI - for getting access to CI, follow https://wiki.centos.org/QaWiki/CI#head-d2a4e0fbb3b40c3f283c33b514e88670cb8956b4 #topic review of how development of new scls is working rought proposal: building packages -> candidate -> sanity testing -> testing -> [wait till rhscl is released] -> tag released -> sign&release - usual tagging process: tag -candidate -> [sanity testing] -> tag -testing -> [better testing] -> tag -released -> sign&release - how it will be done for collections that gonna be released in RHSCL in the future? - idea: such collections should stay in -testing until they are released in RHSCL -- bad idea? shout now. #topic Provides/Obsoletes to centos-release-scl - there is the older repo package called centos-release-SCL with quite old packages and centos-release-scl now, witch packages build in cbs - we should add Provides/Obsoletes into centos-release-scl - #action hhorak will test it and ask someone to create an update #topic package for RHEL users that installs sclo packages above RHSCL - there is currently no nice way how to install repo http://mirror.centos.org/centos-7/7/sclo/x86_64/sclo/ in RHEL, when user doesn't have centos-release-sclo packages available - a package in epel or in copr would do the work, while copr seems like a better alternative (some people might be not willing to enable epel for just this package + people were used to install packages from copr (or softwarecollections.org) and it haven't been issue) - #action hhorak will prepare the package and share on ML Honza From ncoghlan at redhat.com Thu Jan 14 06:35:23 2016 From: ncoghlan at redhat.com (Nick Coghlan) Date: Thu, 14 Jan 2016 16:35:23 +1000 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: <56968A6F.2030303@redhat.com> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> Message-ID: On Thu, Jan 14, 2016 at 3:33 AM, Honza Horak wrote: > #topic review of how development of new scls is working > rought proposal: building packages -> candidate -> sanity testing -> > testing -> [wait till rhscl is released] -> tag released -> sign&release > - usual tagging process: tag -candidate -> [sanity testing] -> tag > -testing -> [better testing] -> tag -released -> sign&release > - how it will be done for collections that gonna be released in RHSCL in > the future? > - idea: such collections should stay in -testing until they are released > in RHSCL -- bad idea? shout now. What's the scope of discussion here in terms of "sclo-*" SCLs and "rh-*" SCLs? For "sclo-*" SCLs, I'd expect the RHSCL release cycle to be entirely irrelevant. For "rh-*" SCLs, having them remain in -testing until the downstream release (so they become generally available to RHEL & CentOS users at the same time) seems reasonable. So if someone wanted to take an existing rh-* package and turn it into an sclo-* package that could be updated independently of the RHSCL release cycle, they'd be free to do that. Cheers, Nick. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect From dominic at cleal.org Thu Jan 14 11:35:49 2016 From: dominic at cleal.org (Dominic Cleal) Date: Thu, 14 Jan 2016 11:35:49 +0000 Subject: [scl.org] CentOS CI (was: Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13)) In-Reply-To: <56968A6F.2030303@redhat.com> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> Message-ID: <56978815.5030902@cleal.org> On 13/01/16 17:33, Honza Horak wrote: > #topic devtoolset-4 rebuilding updates > https://bugs.centos.org/view.php?id=10106 > - bstinson plans to look at ^ in the evening hopefully > - we're looking for a volunteer to write more tests for > devtoolset-3/4 like > https://github.com/sclorg/sclo-ci-tests/tree/master/collections/devtoolset-3-rh > - and another volunteer to integrate tests from ^ to CentOS CI > - #action Dominic and hhorak will talk after meeting about the tests > and you then Dominic can do some magic in CI > - for getting access to CI, follow > https://wiki.centos.org/QaWiki/CI#head-d2a4e0fbb3b40c3f283c33b514e88670cb8956b4 I've opened a pull request at https://github.com/sclorg/sclo-ci-tests/pull/2 with some Jenkins job configs for every software collection. Two example jobs for git19-rh are now in CentOS CI, using the Duffy service to provision a CentOS 6 or 7 system and then just uploading and running the tests on it. The SCLo* jobs are all visible at https://ci.centos.org/view/SCLo/ and are triggered by any change to the -candidate tag repos in CBS. Cheers, -- Dominic Cleal dominic at cleal.org From msimacek at redhat.com Thu Jan 14 13:28:38 2016 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Thu, 14 Jan 2016 14:28:38 +0100 Subject: [scl.org] Self-introduction - Michael Simacek Message-ID: <5697A286.3040802@redhat.com> Hi, I'm Michael Simacek and I'd like to become a member of sclo-sig to help with packaging and maintenance of Java related collections. Thank you, Michael From hhorak at redhat.com Thu Jan 14 13:52:48 2016 From: hhorak at redhat.com (Honza Horak) Date: Thu, 14 Jan 2016 14:52:48 +0100 Subject: [scl.org] Self-introduction - Michael Simacek In-Reply-To: <5697A286.3040802@redhat.com> References: <5697A286.3040802@redhat.com> Message-ID: <5697A830.4020305@redhat.com> Michael is part of our SCL team, so giving +1 from me. Honza On 01/14/2016 02:28 PM, Michael ?im??ek wrote: > Hi, > > I'm Michael Simacek and I'd like to become a member of sclo-sig to help > with packaging and maintenance of Java related collections. > > Thank you, > Michael > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From pkajaba at redhat.com Fri Jan 15 16:44:48 2016 From: pkajaba at redhat.com (Pavel Kajaba) Date: Fri, 15 Jan 2016 11:44:48 -0500 (EST) Subject: [scl.org] Self-introduction - Pavel Kajaba In-Reply-To: <790475960.17307705.1452875638602.JavaMail.zimbra@redhat.com> Message-ID: <287484711.17327017.1452876288272.JavaMail.zimbra@redhat.com> Hi, my name is Pavel Kajaba and I'd like to become a member of sclo-sig to help with packaging and maintenance of posgresql related collections. Thank you, Pavel From hhorak at redhat.com Mon Jan 18 11:24:04 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 18 Jan 2016 12:24:04 +0100 Subject: [scl.org] Self-introduction - Pavel Kajaba In-Reply-To: <287484711.17327017.1452876288272.JavaMail.zimbra@redhat.com> References: <287484711.17327017.1452876288272.JavaMail.zimbra@redhat.com> Message-ID: <569CCB54.3020604@redhat.com> +1 for Pavel from myself, he's one of the current SCL crew in RH. Pavel, please, create a FAS account following steps at https://wiki.centos.org/HowTos/CommunityBuildSystem Honza On 01/15/2016 05:44 PM, Pavel Kajaba wrote: > Hi, > > my name is Pavel Kajaba and I'd like to become a member of sclo-sig to help > with packaging and maintenance of posgresql related collections. > > Thank you, > Pavel > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Mon Jan 18 11:44:32 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 18 Jan 2016 12:44:32 +0100 Subject: [scl.org] CentOS CI In-Reply-To: <56978815.5030902@cleal.org> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> <56978815.5030902@cleal.org> Message-ID: <569CD020.5090501@redhat.com> On 01/14/2016 12:35 PM, Dominic Cleal wrote: > On 13/01/16 17:33, Honza Horak wrote: >> #topic devtoolset-4 rebuilding updates >> https://bugs.centos.org/view.php?id=10106 >> - bstinson plans to look at ^ in the evening hopefully >> - we're looking for a volunteer to write more tests for >> devtoolset-3/4 like >> https://github.com/sclorg/sclo-ci-tests/tree/master/collections/devtoolset-3-rh >> - and another volunteer to integrate tests from ^ to CentOS CI >> - #action Dominic and hhorak will talk after meeting about the tests >> and you then Dominic can do some magic in CI >> - for getting access to CI, follow >> https://wiki.centos.org/QaWiki/CI#head-d2a4e0fbb3b40c3f283c33b514e88670cb8956b4 > > I've opened a pull request at > https://github.com/sclorg/sclo-ci-tests/pull/2 with some Jenkins job > configs for every software collection. I've merged all you PRs, thanks a lot, Dominic! > Two example jobs for git19-rh are now in CentOS CI, using the Duffy > service to provision a CentOS 6 or 7 system and then just uploading and > running the tests on it. The SCLo* jobs are all visible at > https://ci.centos.org/view/SCLo/ and are triggered by any change to the > -candidate tag repos in CBS. I see there are already jobs for all collections, great. Hopefully the jobs resutls will look better after the mistakes from PM have been merged.. Honza From hhorak at redhat.com Mon Jan 18 11:49:14 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 18 Jan 2016 12:49:14 +0100 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> Message-ID: <569CD13A.1020208@redhat.com> On 01/14/2016 07:35 AM, Nick Coghlan wrote: > On Thu, Jan 14, 2016 at 3:33 AM, Honza Horak wrote: >> #topic review of how development of new scls is working >> rought proposal: building packages -> candidate -> sanity testing -> >> testing -> [wait till rhscl is released] -> tag released -> sign&release >> - usual tagging process: tag -candidate -> [sanity testing] -> tag >> -testing -> [better testing] -> tag -released -> sign&release >> - how it will be done for collections that gonna be released in RHSCL in >> the future? >> - idea: such collections should stay in -testing until they are released >> in RHSCL -- bad idea? shout now. > > What's the scope of discussion here in terms of "sclo-*" SCLs and "rh-*" SCLs? > > For "sclo-*" SCLs, I'd expect the RHSCL release cycle to be entirely irrelevant. Yes, they may be theoretically influence in cases the sclo-* SCLs depend on some rh-* SCLs -- in that case their release is depended on RHSCL. > For "rh-*" SCLs, having them remain in -testing until the downstream > release (so they become generally available to RHEL & CentOS users at > the same time) seems reasonable. > > So if someone wanted to take an existing rh-* package and turn it into > an sclo-* package that could be updated independently of the RHSCL > release cycle, they'd be free to do that. Yes, in case someone would like to include different set of packages or deliver different version, then it effectively become a new SCL, that needs to be treated that way. Honza From dominic at cleal.org Mon Jan 18 13:47:53 2016 From: dominic at cleal.org (Dominic Cleal) Date: Mon, 18 Jan 2016 13:47:53 +0000 Subject: [scl.org] CentOS CI In-Reply-To: <569CD020.5090501@redhat.com> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> <56978815.5030902@cleal.org> <569CD020.5090501@redhat.com> Message-ID: <569CED09.1090803@cleal.org> On 18/01/16 11:44, Honza Horak wrote: > On 01/14/2016 12:35 PM, Dominic Cleal wrote: >> Two example jobs for git19-rh are now in CentOS CI, using the Duffy >> service to provision a CentOS 6 or 7 system and then just uploading and >> running the tests on it. The SCLo* jobs are all visible at >> https://ci.centos.org/view/SCLo/ and are triggered by any change to the >> -candidate tag repos in CBS. > > I see there are already jobs for all collections, great. Hopefully the > jobs resutls will look better after the mistakes from PM have been merged.. Yep, I got my account on there and added the rest, which seems pretty successful. A few more jobs went green with the merge of that first set of PRs, thanks for that. There are about five more unique issues that I can see for the rest of the failures in python33, sclo-vagrant1, devtoolset-3, ruby193 and all of the database tests. I've filed these at https://github.com/sclorg/sclo-ci-tests/issues, so if anybody's interested in solving these, the details are there. The full logs from the tests are accessible as artifacts in the Jenkins build, so view the job (e.g. https://ci.centos.org/view/SCLo/job/SCLo-sclo-vagrant1-sclo-C7-x86_64/), click a failing build on the left, and click "Build Artifacts" at the top to get access to the results/ directory. You can download or view individual stderr/out results from the tests here, or view tests.log for the overview. -- Dominic Cleal dominic at cleal.org From lfarkas at lfarkas.org Mon Jan 18 16:12:37 2016 From: lfarkas at lfarkas.org (Farkas Levente) Date: Mon, 18 Jan 2016 17:12:37 +0100 Subject: [scl.org] [CentOS-devel] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: <56968A6F.2030303@redhat.com> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> Message-ID: On Wed, Jan 13, 2016 at 6:33 PM, Honza Horak wrote: > #topic devtoolset-4 rebuilding updates > https://bugs.centos.org/view.php?id=10106 > - bstinson plans to look at ^ in the evening hopefully > - we're looking for a volunteer to write more tests for devtoolset-3/4 > like > https://github.com/sclorg/sclo-ci-tests/tree/master/collections/devtoolset-3-rh > - and another volunteer to integrate tests from ^ to CentOS CI > - #action Dominic and hhorak will talk after meeting about the tests and > you then Dominic can do some magic in CI > - for getting access to CI, follow > https://wiki.centos.org/QaWiki/CI#head-d2a4e0fbb3b40c3f283c33b514e88670cb8956b4 > the 15th jan build of devtoolset-4 on el7 no longer works (devtoolset-4-eclipse-platform-4.5.0-10.6.el7.x86_64). while the 8th jan build was working (devtoolset-4-eclipse-platform-4.5.0-10.6.bs3.el7.x86_64). for example felix-gogo files are missing from the latest build and eclipse are not able to start. regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Mon Jan 18 20:43:35 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 18 Jan 2016 21:43:35 +0100 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: <56968A6F.2030303@redhat.com> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> Message-ID: <569D4E77.8060902@redhat.com> On 01/13/2016 06:33 PM, Honza Horak wrote: > #topic Provides/Obsoletes to centos-release-scl > - there is the older repo package called centos-release-SCL with > quite old packages and centos-release-scl now, witch packages build in cbs > - we should add Provides/Obsoletes into centos-release-scl > - #action hhorak will test it and ask someone to create an update I've played around with this added to centos-release-scl SPEC: Release: 7%{?dist} Provides: centos-release-SCL = %{epoch}:%{version}-%{release} Obsoletes: centos-release-SCL < %{epoch}:6-7 and it seems to be working fine, i.e. the package centos-release-scl updates centos-release-SCL on `yum update`. Thomas, if you're not against, could you build an updated centos-release-scl package, please? Honza From hhorak at redhat.com Mon Jan 18 20:55:06 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 18 Jan 2016 21:55:06 +0100 Subject: [scl.org] Announcing release for Vagrant 1.7.4 on CentOS Linux 7 x86_64 SCL In-Reply-To: <1448902355.MyhgHxboyd@x230> References: <30817203.9pMzB8erLz@x230> <5653ADE0.7080203@karan.org> <56545D35.80107@redhat.com> <1448902355.MyhgHxboyd@x230> Message-ID: <569D512A.1000803@redhat.com> On 11/30/2015 04:47 PM, Robert Kratky wrote: >>> if the centos-release-scl-rh were to have a Provides: that matches >>> > >something that's also available from the RHSCL's setup, then this might >>> > >not be a problem; in an environ that has the RHSCL's setup, the content >>> > >will just come from there ( it will need some tracking etc, but >>> > >should'nt be too hard ). >>> > > >>> > >is there such an easy target that might be shared across the two venues ? >> > >> >This is not that easy, because RH packages don't use an RPM package for >> >shipping repo file and key -- and there is probably no similar RPM that >> >we could use. >> > >> >We can either create a separate a new RPM package with just sclo repo >> >file and key or as already proposed before, something like this: >> >* centos-release-scl-rh as now, no difference here >> >* centos-release-scl-sclo, that ships repo file and key >> >* centos-release-scl that requires both of the images above, but doesn't >> >ship anything. > Either of these solutions seems good to me. Would it be hard to make it happen? I've finally created a PoC of the new packages in copr, that are meant to be used on RHEL to install sclo-* collectoins. I think this may work better than trying to deliver the centos packages, because RHEL users wouldn't be able to install centos-release-scl -- this package is only available in centos-extras. So, in order to get the sclo-* collections (vagrant right now), follow steps mentioned at: https://github.com/sclorg/centos-release-scl Let us know how that works for you, thanks! Honza From thomas.oulevey at cern.ch Mon Jan 18 21:43:58 2016 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Mon, 18 Jan 2016 22:43:58 +0100 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: <569D4E77.8060902@redhat.com> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> <569D4E77.8060902@redhat.com> Message-ID: <569D5C9E.5030803@cern.ch> On 18/01/16 21:43, Honza Horak wrote: > On 01/13/2016 06:33 PM, Honza Horak wrote: >> #topic Provides/Obsoletes to centos-release-scl >> - there is the older repo package called centos-release-SCL with >> quite old packages and centos-release-scl now, witch packages build in >> cbs >> - we should add Provides/Obsoletes into centos-release-scl >> - #action hhorak will test it and ask someone to create an update > > > I've played around with this added to centos-release-scl SPEC: > > Release: 7%{?dist} > Provides: centos-release-SCL = %{epoch}:%{version}-%{release} > Obsoletes: centos-release-SCL < %{epoch}:6-7 > > and it seems to be working fine, i.e. the package centos-release-scl > updates centos-release-SCL on `yum update`. > > Thomas, if you're not against, could you build an updated > centos-release-scl package, please? Sure, I'll do it asap. I think we could tweak debug / source URLs at the same time. > > Honza From rkuska at redhat.com Wed Jan 20 11:04:10 2016 From: rkuska at redhat.com (Robert Kuska) Date: Wed, 20 Jan 2016 06:04:10 -0500 (EST) Subject: [scl.org] Self-introduction - Robert Kuska In-Reply-To: <1825292345.9473393.1453287709391.JavaMail.zimbra@redhat.com> Message-ID: <1187942737.9473701.1453287850257.JavaMail.zimbra@redhat.com> Hello everyone! My name is Robert Kuska and I would like to become member of sclo-sig to help with packaging of python related packages. Cheers, Robert Kuska {rkuska} From hhorak at redhat.com Wed Jan 20 16:31:48 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 20 Jan 2016 17:31:48 +0100 Subject: [scl.org] Self-introduction - Robert Kuska In-Reply-To: <1187942737.9473701.1453287850257.JavaMail.zimbra@redhat.com> References: <1187942737.9473701.1453287850257.JavaMail.zimbra@redhat.com> Message-ID: <569FB674.4000201@redhat.com> Hey Robert, welcome on board! Honza On 01/20/2016 12:04 PM, Robert Kuska wrote: > Hello everyone! > > My name is Robert Kuska and I would like to become member > of sclo-sig to help with packaging of python related packages. > > Cheers, > Robert Kuska > {rkuska} > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Wed Jan 20 17:07:58 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 20 Jan 2016 18:07:58 +0100 Subject: [scl.org] devtoolset 2? In-Reply-To: References: <568BE1A1.8060207@redhat.com> <568D2CF3.50900@redhat.com> <568D7D66.6090305@redhat.com> Message-ID: <569FBEEE.50201@redhat.com> On 01/13/2016 05:14 AM, Dave Johansen wrote: > On Wed, Jan 6, 2016 at 1:47 PM, Honza Horak > wrote: > > On 01/06/2016 05:41 PM, Dave Johansen wrote: > > On Wed, Jan 6, 2016 at 8:04 AM, Honza Horak > >> wrote: > > On 01/05/2016 04:35 PM, Dave Johansen wrote: > > On Tue, Jan 5, 2016 at 8:30 AM, Honza Horak > > > > > >>> wrote: > > Interesting, you're first who asks for that. > Currently, > there is > nobody working on it. > > > We're working on moving to EL 7, but still need to > support EL 6 > installations. We'd also like to start allowing use of > C++11 in > our code > base and using the same version of gcc on both EL 6 and > 7 seemed > like > the best way to accomplish both of these goals. > > If you're willing to try that, I wouldn't be > against, I > just must > warn you that rebuilding devtoolset is always a > lot of fun > (like > https://www.redhat.com/archives/sclorg/2015-December/msg00050.html).. > > > What's the best way to start this? > Are there modifications that are required for source > .rpm (removing > RedHat naming, etc)? Or is it just start building it > and dealing > with > the issues that pop up? > > > There is no need to remove any naming, we usually take srpm > from RH > and rebuild. However, the bootstrapping is usually very > challenging. > I'd recommend first to try to rebuild at least basic packages > yourself using mock (or copr), so you see how far you can get.. > Then, if you'll see it is worth the work, we can create > tags/targets > in CBS and start with real rebuilds. > > > I was just going to start playing around with this on COPR and I > noticed > that there appears to already be an existing build of devtoolset-2: > https://copr.fedoraproject.org/coprs/rhscl/devtoolset/ > > It looks like it's not complete because only some of the packages > succeeded, but would that serve as the best starting point? If so, > what's the best way to move forward with that? > > > Well, why not, I can add you as collaborator in this project -- what > is your copr username? However, I'm afraid that whoever tried that, > he got blocked on some non easy issues, which is the reason why it > is not finished. > > > My username is daveisfera. Well, I've realized the copr is not named devtoolset-2, but just devtoolset, which is not ideal.. and renaming is not possible in copr.. maybe it would be better if you'd create your own copr, which has correct name.. > Is there anything special that needs to be done to do these builds? Honestly, I don't know what is necessary to fix the builds, but since they were failing, I expect something would need to be fixed. > Is there an original location for the source rpms? And is this COPR use > those or some modification of them? The sources are available here: http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHDevToolset/SRPMS/ Again, I don't know unfortunately, whether there were already some modifications done, sorry. Honza From hhorak at redhat.com Wed Jan 20 17:12:48 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 20 Jan 2016 18:12:48 +0100 Subject: [scl.org] [CentOS-devel] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> Message-ID: <569FC010.1040906@redhat.com> On 01/18/2016 05:12 PM, Farkas Levente wrote: > On Wed, Jan 13, 2016 at 6:33 PM, Honza Horak > wrote: > > #topic devtoolset-4 rebuilding updates > https://bugs.centos.org/view.php?id=10106 > - bstinson plans to look at ^ in the evening hopefully > - we're looking for a volunteer to write more tests for > devtoolset-3/4 like > https://github.com/sclorg/sclo-ci-tests/tree/master/collections/devtoolset-3-rh > - and another volunteer to integrate tests from ^ to CentOS CI > - #action Dominic and hhorak will talk after meeting about the > tests and you then Dominic can do some magic in CI > - for getting access to CI, follow > https://wiki.centos.org/QaWiki/CI#head-d2a4e0fbb3b40c3f283c33b514e88670cb8956b4 > > the 15th jan build of devtoolset-4 on el7 no longer works > (devtoolset-4-eclipse-platform-4.5.0-10.6.el7.x86_64). > while the 8th jan build was working > (devtoolset-4-eclipse-platform-4.5.0-10.6.bs3.el7.x86_64). > for example felix-gogo files are missing from the latest build and > eclipse are not able to start. well, I see felix.gogo files there.. However, I haven't get into testing the eclipse yet, because I have still troubles with installing a centos with gui in VM.. will try better.. Can somebody else confirm it doesn't work or confirm the opposite meantime? Honza From lfarkas at lfarkas.org Wed Jan 20 18:12:33 2016 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 20 Jan 2016 19:12:33 +0100 Subject: [scl.org] [CentOS-devel] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: <569FC010.1040906@redhat.com> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> <569FC010.1040906@redhat.com> Message-ID: <569FCE11.4000208@lfarkas.org> On 01/20/2016 06:12 PM, Honza Horak wrote: > On 01/18/2016 05:12 PM, Farkas Levente wrote: >> On Wed, Jan 13, 2016 at 6:33 PM, Honza Horak > > wrote: >> >> #topic devtoolset-4 rebuilding updates >> https://bugs.centos.org/view.php?id=10106 >> - bstinson plans to look at ^ in the evening hopefully >> - we're looking for a volunteer to write more tests for >> devtoolset-3/4 like >> >> https://github.com/sclorg/sclo-ci-tests/tree/master/collections/devtoolset-3-rh >> >> - and another volunteer to integrate tests from ^ to CentOS CI >> - #action Dominic and hhorak will talk after meeting about the >> tests and you then Dominic can do some magic in CI >> - for getting access to CI, follow >> >> https://wiki.centos.org/QaWiki/CI#head-d2a4e0fbb3b40c3f283c33b514e88670cb8956b4 >> >> >> the 15th jan build of devtoolset-4 on el7 no longer works >> (devtoolset-4-eclipse-platform-4.5.0-10.6.el7.x86_64). >> while the 8th jan build was working >> (devtoolset-4-eclipse-platform-4.5.0-10.6.bs3.el7.x86_64). >> for example felix-gogo files are missing from the latest build and >> eclipse are not able to start. > > well, I see felix.gogo files there.. However, I haven't get into testing > the eclipse yet, because I have still troubles with installing a centos > with gui in VM.. will try better.. Can somebody else confirm it doesn't > work or confirm the opposite meantime? simple after installing on el7: yum --enablerepo=sclo7-devtoolset-4-rh-candidate install devtoolset-4-ide eclipse won't start. -- Levente "Si vis pacem para bellum!" From shanson at cruiskeenconsulting.com Wed Jan 20 18:21:52 2016 From: shanson at cruiskeenconsulting.com (Steve Hanson) Date: Wed, 20 Jan 2016 12:21:52 -0600 Subject: [scl.org] softwarecollections.org is down? Message-ID: <569FD040.7020807@cruiskeenconsulting.com> Looks like the new softwarecollections.org web server is down? From langdon at redhat.com Wed Jan 20 18:55:05 2016 From: langdon at redhat.com (Langdon White) Date: Wed, 20 Jan 2016 13:55:05 -0500 Subject: [scl.org] softwarecollections.org is down? In-Reply-To: <569FD040.7020807@cruiskeenconsulting.com> References: <569FD040.7020807@cruiskeenconsulting.com> Message-ID: <569FD809.9080809@redhat.com> it does appear that way, not sure why the monitoring is not notifying... On 01/20/2016 01:21 PM, Steve Hanson wrote: > Looks like the new softwarecollections.org web server is down? > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From msuchy at redhat.com Thu Jan 21 09:38:31 2016 From: msuchy at redhat.com (=?UTF-8?Q?Miroslav_Such=c3=bd?=) Date: Thu, 21 Jan 2016 10:38:31 +0100 Subject: [scl.org] rsync for softwarecollections.org is available Message-ID: <56A0A717.1040103@redhat.com> If you want to sync some/all repositories from softwarecollections.org feel free: rsync -rP 'rsync://softwarecollection.org/repos/' ./ -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From msuchy at redhat.com Thu Jan 21 09:41:41 2016 From: msuchy at redhat.com (=?UTF-8?Q?Miroslav_Such=c3=bd?=) Date: Thu, 21 Jan 2016 10:41:41 +0100 Subject: [scl.org] softwarecollections.org is down? In-Reply-To: <569FD040.7020807@cruiskeenconsulting.com> References: <569FD040.7020807@cruiskeenconsulting.com> Message-ID: <56A0A7D5.1040004@redhat.com> Dne 20.1.2016 v 19:21 Steve Hanson napsal(a): > Looks like the new softwarecollections.org web server is down? FYI there was outage in hosting center to upgrade underlying OpenStack. Next time I will try to forward the announce here. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys From acuzoka at gmail.com Thu Jan 21 11:22:35 2016 From: acuzoka at gmail.com (chinedu uzoka) Date: Thu, 21 Jan 2016 11:22:35 +0000 Subject: [scl.org] softwarecollections.org is down? In-Reply-To: <56A0A7D5.1040004@redhat.com> References: <569FD040.7020807@cruiskeenconsulting.com> <56A0A7D5.1040004@redhat.com> Message-ID: Looks like its back up On 21 January 2016 at 09:41, Miroslav Such? wrote: > Dne 20.1.2016 v 19:21 Steve Hanson napsal(a): > > Looks like the new softwarecollections.org web server is down? > > FYI there was outage in hosting center to upgrade underlying OpenStack. > Next time I will try to forward the announce here. > > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanson at cruiskeenconsulting.com Thu Jan 21 18:23:14 2016 From: shanson at cruiskeenconsulting.com (Steve Hanson) Date: Thu, 21 Jan 2016 12:23:14 -0600 Subject: [scl.org] softwarecollections.org is down? In-Reply-To: References: <569FD040.7020807@cruiskeenconsulting.com> <56A0A7D5.1040004@redhat.com> Message-ID: <56A12212.7040004@cruiskeenconsulting.com> On 01/21/2016 05:22 AM, chinedu uzoka wrote: > Looks like its back up Not at the moment, it isn't. I'll be doing a mirror off of it whenever it comes back up - it's getting really hard to maintain servers. > > On 21 January 2016 at 09:41, Miroslav Such? > wrote: > > Dne 20.1.2016 v 19:21 Steve Hanson napsal(a): > > Looks like the newsoftwarecollections.org web > server is down? > > FYI there was outage in hosting center to upgrade underlying > OpenStack. > Next time I will try to forward the announce here. > > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Thu Jan 21 20:44:03 2016 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 21 Jan 2016 13:44:03 -0700 Subject: [scl.org] softwarecollections.org is down? In-Reply-To: <56A12212.7040004@cruiskeenconsulting.com> References: <569FD040.7020807@cruiskeenconsulting.com> <56A0A7D5.1040004@redhat.com> <56A12212.7040004@cruiskeenconsulting.com> Message-ID: On 21 January 2016 at 11:23, Steve Hanson wrote: > On 01/21/2016 05:22 AM, chinedu uzoka wrote: > > Looks like its back up > > > Not at the moment, it isn't. I'll be doing a mirror off of it whenever it > comes back up - it's getting really hard to maintain servers. > The data center the server is at is undergoing maintenance and will be back later today. -- Stephen J Smoogen. From hhorak at redhat.com Fri Jan 22 06:38:19 2016 From: hhorak at redhat.com (Honza Horak) Date: Fri, 22 Jan 2016 07:38:19 +0100 Subject: [scl.org] [CentOS-devel] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-13) In-Reply-To: <569FCE11.4000208@lfarkas.org> References: <5696664F.8010707@redhat.com> <56968A6F.2030303@redhat.com> <569FC010.1040906@redhat.com> <569FCE11.4000208@lfarkas.org> Message-ID: <56A1CE5B.9030508@redhat.com> On 01/20/2016 07:12 PM, Farkas Levente wrote: > On 01/20/2016 06:12 PM, Honza Horak wrote: >> On 01/18/2016 05:12 PM, Farkas Levente wrote: >>> On Wed, Jan 13, 2016 at 6:33 PM, Honza Horak >> > wrote: >>> >>> #topic devtoolset-4 rebuilding updates >>> https://bugs.centos.org/view.php?id=10106 >>> - bstinson plans to look at ^ in the evening hopefully >>> - we're looking for a volunteer to write more tests for >>> devtoolset-3/4 like >>> >>> https://github.com/sclorg/sclo-ci-tests/tree/master/collections/devtoolset-3-rh >>> >>> - and another volunteer to integrate tests from ^ to CentOS CI >>> - #action Dominic and hhorak will talk after meeting about the >>> tests and you then Dominic can do some magic in CI >>> - for getting access to CI, follow >>> >>> https://wiki.centos.org/QaWiki/CI#head-d2a4e0fbb3b40c3f283c33b514e88670cb8956b4 >>> >>> >>> the 15th jan build of devtoolset-4 on el7 no longer works >>> (devtoolset-4-eclipse-platform-4.5.0-10.6.el7.x86_64). >>> while the 8th jan build was working >>> (devtoolset-4-eclipse-platform-4.5.0-10.6.bs3.el7.x86_64). >>> for example felix-gogo files are missing from the latest build and >>> eclipse are not able to start. >> >> well, I see felix.gogo files there.. However, I haven't get into testing >> the eclipse yet, because I have still troubles with installing a centos >> with gui in VM.. will try better.. Can somebody else confirm it doesn't >> work or confirm the opposite meantime? > > simple after installing on el7: > yum --enablerepo=sclo7-devtoolset-4-rh-candidate install devtoolset-4-ide > eclipse won't start. I've finally got to working CentOS with Gnome and reproduced the failure. Interestingly, rebuild of eclipse package seems to fix the issue. Farkas, can you try again with latest build in -candidate? (it's devtoolset-4-eclipse-4.5.0-10.6.sc1.el7). Honza From rcollet at redhat.com Fri Jan 22 09:20:04 2016 From: rcollet at redhat.com (Remi Collet) Date: Fri, 22 Jan 2016 10:20:04 +0100 Subject: [scl.org] sclo-php5# new packages, WIP Message-ID: <56A1F444.6020706@redhat.com> Hi, I'm working on importing, as sclo-php5#-* some packages for extensions missing in the php-5# SCLs Sources are tracked at https://github.com/sclorg-distgit For now, already built sclo-php54 sclo-php54-php-pecl-imagick-3.3.0-1.el* sclo-php54-php-pecl-xdebug-2.3.3-1.el* sclo-php54-php-pecl-http-2.5.5-1.el* sclo-php54-php-pecl-apcu-4.0.10-1.el* sclo-php54-php-pecl-propro-1.0.2-1.el* sclo-php54-php-pecl-raphf-1.1.2-1.el* sclo-php55 sclo-php55-php-pecl-imagick-3.3.0-1.el* sclo-php55-php-pecl-xdebug-2.3.3-1.el* sclo-php55-php-pecl-http-2.5.5-1.el* sclo-php55-php-pecl-apcu-4.0.10-1.el* sclo-php55-php-pecl-propro-1.0.2-1.el* sclo-php55-php-pecl-raphf-1.1.2-1.el* sclo-php56 sclo-php56-php-pecl-imagick-3.3.0-1.el* sclo-php56-php-pecl-http-2.5.5-1.el* sclo-php56-php-pecl-apcu-4.0.10-1.el* sclo-php56-php-pecl-propro-1.0.2-1.el* sclo-php56-php-pecl-raphf-1.1.2-1.el* No yet available in centos-sclo-sclo-testing (but I hope will be soon) These are really part of the base SCL (not a new SCL), and "sclo" prefix is only used in package name to avoid user confusion about their origin. They can be installed using rh name (e.g. php54-php-pecl-xdebug or rh-php56-php-pecl-imagick) Feedback on these new packages will be very welcome. I plan to build some more packages, so if you think of any important and missing extension, just ask. Remi. -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From mail-lists at karan.org Fri Jan 22 11:28:47 2016 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 22 Jan 2016 11:28:47 +0000 Subject: [scl.org] rsync for softwarecollections.org is available In-Reply-To: <56A0A717.1040103@redhat.com> References: <56A0A717.1040103@redhat.com> Message-ID: <56A2126F.6090909@karan.org> On 21/01/16 09:38, Miroslav Such? wrote: > If you want to sync some/all repositories from softwarecollections.org feel free: > > rsync -rP 'rsync://softwarecollection.org/repos/' ./ as a data point - how much content here is missing from the CentOS CDN at this point ? regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Fri Jan 22 11:35:46 2016 From: hhorak at redhat.com (Honza Horak) Date: Fri, 22 Jan 2016 12:35:46 +0100 Subject: [scl.org] rsync for softwarecollections.org is available In-Reply-To: <56A2126F.6090909@karan.org> References: <56A0A717.1040103@redhat.com> <56A2126F.6090909@karan.org> Message-ID: <56A21412.9090106@redhat.com> On 01/22/2016 12:28 PM, Karanbir Singh wrote: > On 21/01/16 09:38, Miroslav Such? wrote: >> If you want to sync some/all repositories from softwarecollections.org feel free: >> >> rsync -rP 'rsync://softwarecollection.org/repos/' ./ > > as a data point - how much content here is missing from the CentOS CDN > at this point ? I'd like to answer here, but don't actually understand, what you're asking for.. can you be more specific, please? Honza From rcollet at redhat.com Fri Jan 22 11:38:26 2016 From: rcollet at redhat.com (Remi Collet) Date: Fri, 22 Jan 2016 12:38:26 +0100 Subject: [scl.org] rsync for softwarecollections.org is available In-Reply-To: <56A2126F.6090909@karan.org> References: <56A0A717.1040103@redhat.com> <56A2126F.6090909@karan.org> Message-ID: <56A214B2.8090505@redhat.com> Le 22/01/2016 12:28, Karanbir Singh a ?crit : > On 21/01/16 09:38, Miroslav Such? wrote: >> If you want to sync some/all repositories from softwarecollections.org feel free: >> >> rsync -rP 'rsync://softwarecollection.org/repos/' ./ > > as a data point - how much content here is missing from the CentOS CDN > at this point ? Probably, at least, all "non-rh" SCLs Remi. > > regards > -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From Jaroslaw.Polok at cern.ch Fri Jan 22 16:08:39 2016 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Fri, 22 Jan 2016 17:08:39 +0100 Subject: [scl.org] Self-introduction Message-ID: <56A25407.9030407@cern.ch> Hi all ! My name is Jarek Polok and I would be interested joining sclo-sig for packaging SSO (Single Sign On) related tools/modules: - mod_auth_mellon - shibboleth (to make these available as add-on for the existing (rh-)httpd24 collection) ... and possibly more in the future. Best Regards Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From hhorak at redhat.com Mon Jan 25 11:25:39 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 25 Jan 2016 12:25:39 +0100 Subject: [scl.org] Self-introduction In-Reply-To: <56A25407.9030407@cern.ch> References: <56A25407.9030407@cern.ch> Message-ID: <56A60633.4000008@redhat.com> On 01/22/2016 05:08 PM, Jarek Polok wrote: > Hi all ! > > My name is Jarek Polok and I would be interested > joining sclo-sig for packaging SSO (Single Sign On) > related tools/modules: > > - mod_auth_mellon > - shibboleth I don't see shibboleth in Fedora so can't easily find what it means in practice, but I expect it will be a library (Apache's module) and potentially some other (config) files? We need to find out how to name that collection -- if we take it as a collection that contains the additional modules that are not in httpd24, could we use "sclo-httpd24"? Joe, since you're responsible for the httpd24 SCL -- does something like that make sense to you? Honza > (to make these available as add-on for the existing > (rh-)httpd24 collection) > > ... and possibly more in the future. > > Best Regards > > Jarek > __ > ------------------------------------------------------- > _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ > _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ > ______________________________________+41_75_411_9487 _ > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From jorton at redhat.com Mon Jan 25 11:53:31 2016 From: jorton at redhat.com (Joe Orton) Date: Mon, 25 Jan 2016 11:53:31 +0000 Subject: [scl.org] Self-introduction In-Reply-To: <56A60633.4000008@redhat.com> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> Message-ID: <20160125115331.GA28898@redhat.com> On Mon, Jan 25, 2016 at 12:25:39PM +0100, Honza Horak wrote: > On 01/22/2016 05:08 PM, Jarek Polok wrote: > >Hi all ! > > > >My name is Jarek Polok and I would be interested > >joining sclo-sig for packaging SSO (Single Sign On) > >related tools/modules: > > > > - mod_auth_mellon > > - shibboleth > > I don't see shibboleth in Fedora so can't easily find what it means in > practice, but I expect it will be a library (Apache's module) and > potentially some other (config) files? > > We need to find out how to name that collection -- if we take it as a > collection that contains the additional modules that are not in httpd24, > could we use "sclo-httpd24"? > > Joe, since you're responsible for the httpd24 SCL -- does something like > that make sense to you? Hi Honza, Jarek, We could do an sclo-httpd24, but I'd generally prefer to see the creation of new collections specific to the tool/technology/whatever, which ship a mod_foo package containing the mod_foo.so & httpd config under httpd24's filesystem locations. That's how we do it for mod_* for language collections, and it seems to work pretty well. jkaluza may have a different opinion :) Regards, Joe -- Joe Orton // Red Hat // Web Stack Team // webstack-team at redhat.com // @notroj From Jaroslaw.Polok at cern.ch Mon Jan 25 12:12:42 2016 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Mon, 25 Jan 2016 13:12:42 +0100 Subject: [scl.org] Self-introduction In-Reply-To: <20160125115331.GA28898@redhat.com> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> <20160125115331.GA28898@redhat.com> Message-ID: <56A6113A.8080002@cern.ch> On 01/25/2016 12:53 PM, Joe Orton wrote: > On Mon, Jan 25, 2016 at 12:25:39PM +0100, Honza Horak wrote: >> On 01/22/2016 05:08 PM, Jarek Polok wrote: >>> Hi all ! >>> >>> My name is Jarek Polok and I would be interested >>> joining sclo-sig for packaging SSO (Single Sign On) >>> related tools/modules: >>> >>> - mod_auth_mellon >>> - shibboleth >> >> I don't see shibboleth in Fedora so can't easily find what it means in >> practice, but I expect it will be a library (Apache's module) and >> potentially some other (config) files? >> No it isn;t : that raises another question: would that be a candidate for potential inclusion in Centos extras perhaps ? (it is actually distributed via: http://download.opensuse.org/repositories/security://shibboleth/CentOS_7/x86_64/) (it is little bit more complicated than httpd module alone: there is a standalone daemon plus a bunch of supporting libraries, also not present in Fedora/RedHat) >> We need to find out how to name that collection -- if we take it as a >> collection that contains the additional modules that are not in httpd24, >> could we use "sclo-httpd24"? >> >> Joe, since you're responsible for the httpd24 SCL -- does something like >> that make sense to you? > > Hi Honza, Jarek, > > We could do an sclo-httpd24, but I'd generally prefer to see the > creation of new collections specific to the tool/technology/whatever, > which ship a mod_foo package containing the mod_foo.so & httpd config > under httpd24's filesystem locations. That's how we do it for mod_* for > language collections, and it seems to work pretty well. jkaluza may > have a different opinion :) > I think that would be an option: sclo-mod_auth_mellon and sclo-shibboleth both depending on httpd24 collection ? > Regards, Joe > Cheers Jarek -- __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From rcollet at redhat.com Mon Jan 25 14:04:45 2016 From: rcollet at redhat.com (Remi Collet) Date: Mon, 25 Jan 2016 15:04:45 +0100 Subject: [scl.org] Self-introduction In-Reply-To: <20160125115331.GA28898@redhat.com> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> <20160125115331.GA28898@redhat.com> Message-ID: <56A62B7D.4090904@redhat.com> Le 25/01/2016 12:53, Joe Orton a ?crit : > On Mon, Jan 25, 2016 at 12:25:39PM +0100, Honza Horak wrote: >> On 01/22/2016 05:08 PM, Jarek Polok wrote: >>> Hi all ! >>> >>> My name is Jarek Polok and I would be interested >>> joining sclo-sig for packaging SSO (Single Sign On) >>> related tools/modules: >>> >>> - mod_auth_mellon >>> - shibboleth >> >> I don't see shibboleth in Fedora so can't easily find what it means in >> practice, but I expect it will be a library (Apache's module) and >> potentially some other (config) files? >> >> We need to find out how to name that collection -- if we take it as a >> collection that contains the additional modules that are not in httpd24, >> could we use "sclo-httpd24"? >> >> Joe, since you're responsible for the httpd24 SCL -- does something like >> that make sense to you? > > Hi Honza, Jarek, > > We could do an sclo-httpd24, but I'd generally prefer to see the > creation of new collections specific to the tool/technology/whatever, > which ship a mod_foo package containing the mod_foo.so & httpd config > under httpd24's filesystem locations. That's how we do it for mod_* for > language collections, and it seems to work pretty well. jkaluza may > have a different opinion :) That is also how we do for sclo-php5x packages, which are really package in the php5# collections, using their filesystems, the prefix is just in the package name, to avoid user confusion. I think the same could be done for sclo-httpd24 packages. And I think it will be nice to see more mod_* for httpd24 ;) Remi -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From Jaroslaw.Polok at cern.ch Tue Jan 26 16:29:22 2016 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Tue, 26 Jan 2016 17:29:22 +0100 Subject: [scl.org] sclo-mod_auth_mellon ( was Re: Self-introduction) In-Reply-To: <56A62B7D.4090904@redhat.com> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> <20160125115331.GA28898@redhat.com> <56A62B7D.4090904@redhat.com> Message-ID: <56A79EE2.3010808@cern.ch> Hi Thanks for comments ! Looking at your work with php55 .. I came up with the following initial attempt at sclo packaging: https://github.com/jaroslawp/sclo-mod_auth_mellon However .. I have some doubts about naming/packaging, and would be glad to hear your comments: The SCL package (sclo-mod_auth_mellon.spec) .. is basically useless (not used in this initial attempt) since what the actual package - mod_auth_mellon.spec - ships goes all into: /opt/rh/httpd24/root/[...] (httpd24 collection) of course that could be split ... rather artificially into a part which would go into: /opt/sclo/mod_auth_mellon/root/[...] but that would be little bit .. useless and confusing since we would end up with sthg alike: /opt/rh/httpd24/root/etc/httpd/conf.d/auth_mellon.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/10-auth_mellon.conf /opt/rh/httpd24/root/run/mod_auth_mellon /opt/rh/httpd24/root/usr/lib/tmpfiles.d/mod_auth_mellon.conf /opt/rh/httpd24/root/usr/lib64/httpd/modules/mod_auth_mellon.so and: /opt/sclo/mod_auth_mellon/root/usr/libexec/mod_auth_mellon /opt/sclo/mod_auth_mellon/root/usr/libexec/mod_auth_mellon/mellon_create_metadata.sh /opt/sclo/mod_auth_mellon/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0 /opt/sclo/mod_auth_mellon/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0/COPYING /opt/sclo/mod_auth_mellon/httpd24/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0/NEWS /opt/slco/mod_auth_mellon/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0/README I think it would be more natural/logical to package having all files under /opt/rh/httpd24/ in this case and name the package: sclo-mod_auth_mellon0-mod_auth_mellon-X.Y (with a provide for httpd24-mod_auth_mellon) ... but ... can we have a collection without the SCL packages ... ? (-runtime/-scldevel/-build ..) I think the case of mod_auth_mellon is little bit special in the sense that this package is only an addon for httpd24 - containing no standalone tools/libraries - unlike php5X .. etc ...) . I would be glad to hear your opinion one the above ... Best Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From rcollet at redhat.com Wed Jan 27 06:56:18 2016 From: rcollet at redhat.com (Remi Collet) Date: Wed, 27 Jan 2016 07:56:18 +0100 Subject: [scl.org] sclo-mod_auth_mellon ( was Re: Self-introduction) In-Reply-To: <56A79EE2.3010808@cern.ch> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> <20160125115331.GA28898@redhat.com> <56A62B7D.4090904@redhat.com> <56A79EE2.3010808@cern.ch> Message-ID: <56A86A12.4060303@redhat.com> Le 26/01/2016 17:29, Jarek Polok a ?crit : > Hi > > Thanks for comments ! > > Looking at your work with php55 .. I came up with > the following initial attempt at sclo packaging: I think you have look at the mod_php package. Bad example ;) This one is really part of the PHP scl (and create some files in the httpd24 collection) I was thinking of packages in the sclo-php5x namespace Ex: https://github.com/sclorg-distgit/php-pecl-apfd Those package are really part of the php5# collections: not a separate collection, no meta package, built using php5#-build. The "sclo" prefix is only used in the package name: > > https://github.com/jaroslawp/sclo-mod_auth_mellon > > However .. I have some doubts about naming/packaging, > and would be glad to hear your comments: > > The SCL package (sclo-mod_auth_mellon.spec) > .. is basically useless (not used in this initial > attempt) since what the actual package > - mod_auth_mellon.spec - ships goes all into: > > /opt/rh/httpd24/root/[...] (httpd24 collection) > > of course that could be split ... rather artificially > into a part which would go into: > > /opt/sclo/mod_auth_mellon/root/[...] > > > but that would be little bit .. useless and > confusing since we would end up with sthg alike: > > > /opt/rh/httpd24/root/etc/httpd/conf.d/auth_mellon.conf > /opt/rh/httpd24/root/etc/httpd/conf.modules.d/10-auth_mellon.conf > /opt/rh/httpd24/root/run/mod_auth_mellon > /opt/rh/httpd24/root/usr/lib/tmpfiles.d/mod_auth_mellon.conf > /opt/rh/httpd24/root/usr/lib64/httpd/modules/mod_auth_mellon.so > > and: > > /opt/sclo/mod_auth_mellon/root/usr/libexec/mod_auth_mellon > /opt/sclo/mod_auth_mellon/root/usr/libexec/mod_auth_mellon/mellon_create_metadata.sh > > /opt/sclo/mod_auth_mellon/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0 > > /opt/sclo/mod_auth_mellon/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0/COPYING > > /opt/sclo/mod_auth_mellon/httpd24/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0/NEWS > > /opt/slco/mod_auth_mellon/root/usr/share/doc/sclo-mod_auth_mellon-mod_auth_mellon-0.11.0/README I agree, this have mostly no sense > > I think it would be more natural/logical to package > having all files under /opt/rh/httpd24/ in this case > > and name the package: > > sclo-mod_auth_mellon0-mod_auth_mellon-X.Y > > (with a provide for httpd24-mod_auth_mellon) Yes, I think you can do something like this, using sclo-httpd24-mod_auth-mellon and providing httpd24-mod_auth-mellon Name: sclo-%{scl_prefix}mod_auth_mellon > ... but ... can we have a collection without the SCL > packages ... ? (-runtime/-scldevel/-build ..) Yes, but, this is not reaaly a collection, only a set of packages, extending a collection, from a different vendor. Remi P.S. notice the %scl_package_override macro seems missing in httpd24 collection, so you have to use _httpd24_* macro...:( > I think the case of mod_auth_mellon is little bit special > in the sense that this package is only an addon > for httpd24 - containing no standalone tools/libraries > - unlike php5X .. etc ...) > > > . I would be glad to hear your opinion > one the above ... > > Best > > Jarek > > __ > ------------------------------------------------------- > _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ > _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ > ______________________________________+41_75_411_9487 _ > > > _______________________________________________ > 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 From rcollet at redhat.com Wed Jan 27 07:25:45 2016 From: rcollet at redhat.com (Remi Collet) Date: Wed, 27 Jan 2016 08:25:45 +0100 Subject: [scl.org] sclo-php5# new packages, WIP In-Reply-To: <56A1F444.6020706@redhat.com> References: <56A1F444.6020706@redhat.com> Message-ID: <56A870F9.6040708@redhat.com> Le 22/01/2016 10:20, Remi Collet a ?crit : > No yet available in centos-sclo-sclo-testing (but I hope will be soon) Those packages are now available, and can be installed using --enablerepo=centos-sclo-sclo-testing Ex: yum --enablerepo=centos-sclo-sclo-testing \ install php54-php-pecl-xdebug yum --enablerepo=centos-sclo-sclo-testing \ install rh-php56-php-pecl-imagick Remi. -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From Jaroslaw.Polok at cern.ch Wed Jan 27 08:06:10 2016 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Wed, 27 Jan 2016 09:06:10 +0100 Subject: [scl.org] sclo-mod_auth_mellon ( was Re: Self-introduction) In-Reply-To: <56A86A12.4060303@redhat.com> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> <20160125115331.GA28898@redhat.com> <56A62B7D.4090904@redhat.com> <56A79EE2.3010808@cern.ch> <56A86A12.4060303@redhat.com> Message-ID: <56A87A72.60609@cern.ch> Hi On 01/27/2016 07:56 AM, Remi Collet wrote: > Le 26/01/2016 17:29, Jarek Polok a ?crit : >> Hi >> >> Thanks for comments ! >> >> Looking at your work with php55 .. I came up with >> the following initial attempt at sclo packaging: > > I think you have look at the mod_php package. > Bad example ;) yep ;-) > This one is really part of the PHP scl > (and create some files in the httpd24 collection) > > I was thinking of packages in the sclo-php5x namespace > Ex: https://github.com/sclorg-distgit/php-pecl-apfd > > Those package are really part of the php5# collections: not a separate > collection, no meta package, built using php5#-build. OK, thank you for the info, making the change now. [...] > > Yes, I think you can do something like this, > using sclo-httpd24-mod_auth-mellon > and providing httpd24-mod_auth-mellon > > Name: sclo-%{scl_prefix}mod_auth_mellon > >> ... but ... can we have a collection without the SCL >> packages ... ? (-runtime/-scldevel/-build ..) > > Yes, but, this is not reaaly a collection, only a set of packages, > extending a collection, from a different vendor. > > > Remi > > Ok, thanks Remi! : I believe that this spec shall work: https://github.com/jaroslawp/sclo-mod_auth_mellon/blob/master/mod_auth_mellon.spec What would be next step to start building with cbs.centos.org ? (I got the account - jpolok , and got approved as sig-sclo member) Requesting build targets ?: sclo{6,7}-sclo-mod_auth_mellon-sclo-el{6,7} ? Cheers Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From rcollet at redhat.com Wed Jan 27 12:12:07 2016 From: rcollet at redhat.com (Remi Collet) Date: Wed, 27 Jan 2016 13:12:07 +0100 Subject: [scl.org] sclo-mod_auth_mellon ( was Re: Self-introduction) In-Reply-To: <56A87A72.60609@cern.ch> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> <20160125115331.GA28898@redhat.com> <56A62B7D.4090904@redhat.com> <56A79EE2.3010808@cern.ch> <56A86A12.4060303@redhat.com> <56A87A72.60609@cern.ch> Message-ID: <56A8B417.80506@redhat.com> Le 27/01/2016 09:06, Jarek Polok a ?crit : > Ok, thanks Remi! : I believe that this spec shall work: > > https://github.com/jaroslawp/sclo-mod_auth_mellon/blob/master/mod_auth_mellon.spec Few comments: - missing sources in github (so I have used fedora ones for test) - tmpfile stuff can be removed (run is not dynamic with SCL, and also not needed on EL-6) - /run (EL-7) vs /var/run (EL-6) - doesn't build (mock), "Could not find apsx2" during configure suggests using the --with-apxs2 option (or enabling the SCL) - %{scl:%_scl_root} => %{?_scl_root} (only cleaner, imho) - missing arched virtual provide Provides: %{?scl_prefix}mod_auth_mellon = %{version}-%{release} Provides: %{?scl_prefix}mod_auth_mellon%{_isa} = %{version}-%{release} With everything fixed, build ok, and content / requires / provides seems ok Remi -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From Jaroslaw.Polok at cern.ch Wed Jan 27 14:20:29 2016 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Wed, 27 Jan 2016 15:20:29 +0100 Subject: [scl.org] sclo-mod_auth_mellon ( was Re: Self-introduction) In-Reply-To: <56A8B417.80506@redhat.com> References: <56A25407.9030407@cern.ch> <56A60633.4000008@redhat.com> <20160125115331.GA28898@redhat.com> <56A62B7D.4090904@redhat.com> <56A79EE2.3010808@cern.ch> <56A86A12.4060303@redhat.com> <56A87A72.60609@cern.ch> <56A8B417.80506@redhat.com> Message-ID: <56A8D22D.1090205@cern.ch> On 01/27/2016 01:12 PM, Remi Collet wrote: > Le 27/01/2016 09:06, Jarek Polok a ?crit : >> Ok, thanks Remi! : I believe that this spec shall work: >> >> https://github.com/jaroslawp/sclo-mod_auth_mellon/blob/master/mod_auth_mellon.spec > > Few comments: > > - missing sources in github (so I have used fedora ones for test) > > - tmpfile stuff can be removed (run is not dynamic with SCL, and also > not needed on EL-6) > > - /run (EL-7) vs /var/run (EL-6) > > - doesn't build (mock), "Could not find apsx2" during configure > suggests using the --with-apxs2 option (or enabling the SCL) > > - %{scl:%_scl_root} => %{?_scl_root} (only cleaner, imho) > > - missing arched virtual provide > > Provides: %{?scl_prefix}mod_auth_mellon = %{version}-%{release} > Provides: %{?scl_prefix}mod_auth_mellon%{_isa} = %{version}-%{release} > > > > With everything fixed, build ok, and content / requires / provides seems ok Thanks Remi ! cbs.centos.org seems to be happy too after implementing these changes for scratch builds for 6 and 7: https://cbs.centos.org/koji/taskinfo?taskID=66330 https://cbs.centos.org/koji/taskinfo?taskID=66332 so I guess the next step is to request cbs setup: https://bugs.centos.org/view.php?id=10255 (I guess that is how this is supposed to be done ? ..) Cheers Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From hhorak at redhat.com Wed Jan 27 14:31:17 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 27 Jan 2016 15:31:17 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-27) Message-ID: <56A8D4B5.9080707@redhat.com> SCLo SIG meeting will be today at 16: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 = I don't have any specific topics but want to be around and available since there are now couple of more people building in SCLo SIG, so maybe there will be some topic raised by someone else. Honza From dominic at cleal.org Wed Jan 27 15:19:42 2016 From: dominic at cleal.org (Dominic Cleal) Date: Wed, 27 Jan 2016 15:19:42 +0000 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-27) In-Reply-To: <56A8D4B5.9080707@redhat.com> References: <56A8D4B5.9080707@redhat.com> Message-ID: <56A8E00E.1050109@cleal.org> On 27/01/16 14:31, Honza Horak wrote: > SCLo SIG meeting will be today at 16: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 = > > I don't have any specific topics but want to be around and available > since there are now couple of more people building in SCLo SIG, so maybe > there will be some topic raised by someone else. I've a couple of items: - Update with state of Jenkins/CI tests - Status update of sclo-ror42 collection -- Dominic Cleal dominic at cleal.org From dominic at cleal.org Wed Jan 27 15:28:31 2016 From: dominic at cleal.org (Dominic Cleal) Date: Wed, 27 Jan 2016 15:28:31 +0000 Subject: [scl.org] sclo-php5# new packages, WIP In-Reply-To: <56A870F9.6040708@redhat.com> References: <56A1F444.6020706@redhat.com> <56A870F9.6040708@redhat.com> Message-ID: <56A8E21F.1050306@cleal.org> Hi Remi, On 27/01/16 07:25, Remi Collet wrote: > Le 22/01/2016 10:20, Remi Collet a ?crit : > >> No yet available in centos-sclo-sclo-testing (but I hope will be soon) > > Those packages are now available, and can be installed using > --enablerepo=centos-sclo-sclo-testing > > Ex: > > yum --enablerepo=centos-sclo-sclo-testing \ > install php54-php-pecl-xdebug > > yum --enablerepo=centos-sclo-sclo-testing \ > install rh-php56-php-pecl-imagick You might want to add some tests to the sclo-ci-tests repository over at https://github.com/sclorg/sclo-ci-tests for these new collections. We can then add them to https://ci.centos.org/view/SCLo/ so they're tested automatically (it tests the -candidate tag.) The repo already has PHP tests for the rh-* collections, so you should be able to copy the structure and update the package lists. Have a look at https://github.com/sclorg/sclo-ci-tests/commit/8f8ee82 to see the sort of thing. There's also a lot of useful info in the README files throughout the source tree and it's easy to run against a plain EL6/EL7 virtual machine with run-remote-git.sh. Let me know if I can be of any help - same goes for anybody else developing new collections. -- Dominic Cleal dominic at cleal.org From hhorak at redhat.com Wed Jan 27 18:20:57 2016 From: hhorak at redhat.com (Honza Horak) Date: Wed, 27 Jan 2016 19:20:57 +0100 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2016-01-27) In-Reply-To: <56A8D4B5.9080707@redhat.com> References: <56A8D4B5.9080707@redhat.com> Message-ID: <56A90A89.6010902@redhat.com> * tags for new collections ruby, ror, python and maven created: https://bugs.centos.org/view.php?id=10256 * we agreed to use scl-httpd24-mod_auth_mellon for the mod_auth_mellon, extending httpd24 SCL (related to https://www.redhat.com/archives/sclorg/2016-January/msg00068.html) we should write this up as there will be more extended SCLs for sure #action alphacc extend cbs doc about sclo SIG tags * hhorak to update the "Gaining Access to SCLs" section and link the "Available Collections" to the SCLo page (https://wiki.centos.org/AdditionalResources/Repositories/SCL) * hhorak to update http://wiki.centos.org/SpecialInterestGroup/SCLo, mentioning sclorg-distgit repos as interim solution * status of CI tests: seems to mostly be there now link https://ci.centos.org/view/SCLo/ just sclo-vagrant1 is failing * sclo-ror42 is built into -candidate tags for el6/7 * newer gcc for gcc-go in virt7-docker* repos -- virt7-docker should be able to inherit devtoolset-4 repos * we need some workflow for the testing => release; it will technically the same than testing, tag the package, as request for repo to be populated, so it is more about policy RemiFedora will write up something like we have in Fedora -- if no problem found, then a week or two for testing the period should probably start by announcing the packages' availability on the centos-devel + sclorg ML (centos-announce is meant for end user announcements only) Honza