From Jaroslaw.Polok at cern.ch Wed Jun 1 07:36:30 2016 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Wed, 1 Jun 2016 09:36:30 +0200 Subject: [scl.org] Listing collections on softwarecollections.org ? Message-ID: <574E907E.8050600@cern.ch> Hi all, Now that sclo-git25, sclo-subversion19 and sclo-httpd24more collections are available via Centos sclo repos: How could I proceed to get these listed on: https://www.softwarecollections.org ? (I believe that on this list are few people who manage the web site in question ?) Thanks 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 Jun 1 08:21:23 2016 From: rcollet at redhat.com (Remi Collet) Date: Wed, 1 Jun 2016 10:21:23 +0200 Subject: [scl.org] php56-php-pecl-uploadprogress package in Software Collections ? In-Reply-To: <574E8EF5.6070004@cern.ch> References: <574E8EF5.6070004@cern.ch> Message-ID: Le 01/06/2016 ? 09:29, Marek Salwerowicz a ?crit : > Hello Remi, > > I have found you as maintainer of package php56-php-pecl-uploadprogress: > > https://www.rpmfind.net/linux/RPM/remi/enterprise/7/x86_64/php56-php-pecl-uploadprogress-1.0.3.1-5.el7.remi.x86_64.html First I think such question should be raised on scl.org mailing list, so adding it in the loop. I'm always surprised that this extension still exists, when PHP have native support for upload since 5.4 (ok, using a different API) http://php.net/manual/en/session.upload-progress.php BTW, this extension is already available in "php56more" repo (designed to work with rh-php56 collection) https://www.softwarecollections.org/en/scls/remi/php56more/ I will try to find some time to import it in the sclo repo. Remi. > > > > I would like to ask if you plan to push the package to the CentOS > Software Collections repository ? > > > Best regards, > Marek > > -- 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 Jun 1 10:39:25 2016 From: rcollet at redhat.com (Remi Collet) Date: Wed, 1 Jun 2016 12:39:25 +0200 Subject: [scl.org] php56-php-pecl-uploadprogress package in Software Collections ? In-Reply-To: References: <574E8EF5.6070004@cern.ch> Message-ID: <688948d4-3fa8-f801-8ebb-f682ccfbb854@redhat.com> Le 01/06/2016 ? 10:21, Remi Collet a ?crit : > I will try to find some time to import it in the sclo repo. Packages built and tagged, should be available in "centos-sclo-sclo-testing" repostiory in a few hours. Feedback welcome. 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 Fedora at FamilleCollet.com Wed Jun 1 12:40:57 2016 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 1 Jun 2016 14:40:57 +0200 Subject: [scl.org] sclo-php5*: new packages available for testing Message-ID: <9da89fb8-4b57-2160-584e-4c1abe5bad34@FamilleCollet.com> New packages built and tagged: sclo-php54-php-pecl-uploadprogress-1.0.3.1-1.el6.x86_64.rpm sclo-php55-php-pecl-uploadprogress-1.0.3.1-1.el6.x86_64.rpm sclo-php56-php-pecl-uploadprogress-1.0.3.1-1.el6.x86_64.rpm sclo-php54-php-pecl-uploadprogress-1.0.3.1-1.el7.x86_64.rpm sclo-php55-php-pecl-uploadprogress-1.0.3.1-1.el7.x86_64.rpm sclo-php56-php-pecl-uploadprogress-1.0.3.1-1.el7.x86_64.rpm These packages extend the php54, php55 and rh-php56 collections, and are available now in centos-sclo-sclo-testing repostiory. Feedback welcome. These packages will be push in stable repository in a few weeks if no bugs are reported. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo From hhorak at redhat.com Fri Jun 3 11:40:39 2016 From: hhorak at redhat.com (Honza Horak) Date: Fri, 3 Jun 2016 13:40:39 +0200 Subject: [scl.org] New SCL packages for CentOS available for testing Message-ID: <57516CB7.8080503@redhat.com> RHSCL 2.2 was released recently [1] and this release includes several new collections: rh-mariadb101 rh-postgresql95 rh-maven33 rh-mongodb30upg rh-mongodb32 rh-python35 rh-nodejs4 rh-ruby23 rh-ror42 SRPMs were taken and rebuilt for CentOS users in cbs.centos.org by SCLo SIG group. The packages are now available in the testing repositories via: sudo yum install centos-release-scl sudo yum-config-manager --enable centos-sclo-rh-testing sudo yum install rh-mariadb101 They will be soon moved to mirrors, but in case there are some issues, let us know. Please, mind, that these packages are not meant to be used on RHEL. On RHEL you can acquire the packages as documented at [1]. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html-single/2.2_Release_Notes/ Regards, Honza From hhorak at redhat.com Fri Jun 3 13:05:41 2016 From: hhorak at redhat.com (Honza Horak) Date: Fri, 3 Jun 2016 15:05:41 +0200 Subject: [scl.org] Listing collections on softwarecollections.org ? In-Reply-To: <574E907E.8050600@cern.ch> References: <574E907E.8050600@cern.ch> Message-ID: <575180A5.9080704@redhat.com> You can log in via Fedora FAS account and "import" a new collection there. The URL will use your FAS username, so I'm just thinking about creating one common username for collections from SCLo SIG, so the links would not have to include particular usernames (they could if you prefer). Suggested common FAS could be: sclo or sclosig Honza On 06/01/2016 09:36 AM, Jarek Polok wrote: > Hi all, > > Now that sclo-git25, sclo-subversion19 and sclo-httpd24more > collections are available via Centos sclo repos: > > How could I proceed to get these listed on: > > https://www.softwarecollections.org > > ? > > (I believe that on this list are few people who > manage the web site in question ?) > > Thanks > > 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 hhorak at redhat.com Mon Jun 6 20:46:45 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 6 Jun 2016 22:46:45 +0200 Subject: [scl.org] New SCL packages for CentOS available for testing In-Reply-To: <57516CB7.8080503@redhat.com> References: <57516CB7.8080503@redhat.com> Message-ID: <5755E135.1040601@redhat.com> Except the new collections, there were some other updated, including devtoolset-4. However, there are some issues with rebuilding some of the devtoolset-4 packages. Hereby I'd like to ask for help with resolving those issues, if anybody is interested in the devtoolset-4 updates on CentOS. The failing builds are: http://cbs.centos.org/koji/buildinfo?buildID=11085 http://cbs.centos.org/koji/buildinfo?buildID=11079 http://cbs.centos.org/koji/buildinfo?buildID=11076 http://cbs.centos.org/koji/buildinfo?buildID=11074 http://cbs.centos.org/koji/buildinfo?buildID=11067 http://cbs.centos.org/koji/buildinfo?buildID=11066 http://cbs.centos.org/koji/buildinfo?buildID=11010 http://cbs.centos.org/koji/buildinfo?buildID=11009 Any help appreciated. Honza On 06/03/2016 01:40 PM, Honza Horak wrote: > RHSCL 2.2 was released recently [1] and this release includes several > new collections: > > rh-mariadb101 > rh-postgresql95 > rh-maven33 > rh-mongodb30upg > rh-mongodb32 > rh-python35 > rh-nodejs4 > rh-ruby23 > rh-ror42 > > SRPMs were taken and rebuilt for CentOS users in cbs.centos.org by SCLo > SIG group. The packages are now available in the testing repositories via: > > sudo yum install centos-release-scl > sudo yum-config-manager --enable centos-sclo-rh-testing > sudo yum install rh-mariadb101 > > They will be soon moved to mirrors, but in case there are some issues, > let us know. > > Please, mind, that these packages are not meant to be used on RHEL. On > RHEL you can acquire the packages as documented at [1]. > > [1] > https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html-single/2.2_Release_Notes/ > > > Regards, > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From ncoghlan at redhat.com Thu Jun 9 14:07:07 2016 From: ncoghlan at redhat.com (Nick Coghlan) Date: Thu, 9 Jun 2016 07:07:07 -0700 Subject: [scl.org] Problems with Python scripts that use SCL runtimes Message-ID: Hi folks, The question of the explicit "scl enable" step for using SCLs is one that's come up a few times in different contexts, and I finally sat down to document a relatively straightforward scenario that illustrates the problem: https://github.com/ncoghlan/scl-pipsi-demo#demonstrating-the-problem What the demo covers doing is: 1. Enable the Python 3.5 SCL 2. Use pipsi within that SCL to install the pygmentize script for a particular user within a virtual environment configured to use that particular runtime 3. Disable the SCL 4. Show that the installed script doesn't work due to the runtime being unable to find its shared libraries Ideally, the fact I used an SCL to install (and subsequently run) pygmentize would be an invisible implementation detail. However, at the moment, it's visible, since Python's virtual environment machinery only fixes paths for Python level imports - it doesn't touch the paths for operating system level dynamic library loading. As far as I am aware, changing the SCL binaries to set RPATH and/or RUNPATH should be sufficient to resolve the problem, at least with pipsi managed script installation (plain "--user" installations are likely to still have problems, but I'm more comfortable with a restriction saying not to use --user installs in conjunction with SCLs) Regards, Nick. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect From daniel.davis at nih.gov Thu Jun 9 14:59:00 2016 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Thu, 9 Jun 2016 14:59:00 +0000 Subject: [scl.org] Problems with Python scripts that use SCL runtimes In-Reply-To: References: Message-ID: Nick, We also encountered this issue, and we wished DevOps and developers not to have the issue. So, our development users, DevOps account, and CI account all have in their ~/.bash_profile: test -f /opt/rh/rh-python34/enable && source /opt/rh/rh-python34/enable This enable script is different from "scl enable" in that it does not start a sub-process. This could be done for everyone via /etc/profile.d/, but we haven't gone that far - we would want then to test whether the user is in a group that gets Python 3, because we don't want this for everyone - vendor provided python scripts may sadly start with "#!/usr/bin/env python"! We also place this line in /etc/sysconfig/httpd, but now that we have switched from mod_wsgi to Phusion Passenger, it is not clear that this is needed. Does this address your issue? Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications Systems, National Library of Medicine, NIH -----Original Message----- From: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] On Behalf Of Nick Coghlan Sent: Thursday, June 09, 2016 10:07 AM To: sclorg at redhat.com Subject: [scl.org] Problems with Python scripts that use SCL runtimes Hi folks, The question of the explicit "scl enable" step for using SCLs is one that's come up a few times in different contexts, and I finally sat down to document a relatively straightforward scenario that illustrates the problem: https://github.com/ncoghlan/scl-pipsi-demo#demonstrating-the-problem What the demo covers doing is: 1. Enable the Python 3.5 SCL 2. Use pipsi within that SCL to install the pygmentize script for a particular user within a virtual environment configured to use that particular runtime 3. Disable the SCL 4. Show that the installed script doesn't work due to the runtime being unable to find its shared libraries Ideally, the fact I used an SCL to install (and subsequently run) pygmentize would be an invisible implementation detail. However, at the moment, it's visible, since Python's virtual environment machinery only fixes paths for Python level imports - it doesn't touch the paths for operating system level dynamic library loading. As far as I am aware, changing the SCL binaries to set RPATH and/or RUNPATH should be sufficient to resolve the problem, at least with pipsi managed script installation (plain "--user" installations are likely to still have problems, but I'm more comfortable with a restriction saying not to use --user installs in conjunction with SCLs) Regards, Nick. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg From ncoghlan at redhat.com Thu Jun 9 18:41:08 2016 From: ncoghlan at redhat.com (Nick Coghlan) Date: Thu, 9 Jun 2016 11:41:08 -0700 Subject: [scl.org] Problems with Python scripts that use SCL runtimes In-Reply-To: References: Message-ID: On Thu, Jun 9, 2016 at 7:59 AM, Davis, Daniel (NIH/NLM) [C] wrote: > Nick, > > We also encountered this issue, and we wished DevOps and developers not to have the issue. > So, our development users, DevOps account, and CI account all have in their ~/.bash_profile: > > test -f /opt/rh/rh-python34/enable && source /opt/rh/rh-python34/enable > > This enable script is different from "scl enable" in that it does not start a sub-process. > > This could be done for everyone via /etc/profile.d/, but we haven't gone that far - we would want then to test whether the user is in a group that gets Python 3, because we don't want this for everyone - vendor provided python scripts may sadly start with "#!/usr/bin/env python"! > > We also place this line in /etc/sysconfig/httpd, but now that we have switched from mod_wsgi to Phusion Passenger, it is not clear that this is needed. > > Does this address your issue? Not quite, although I do like it as a way to improve the situation in managed environments that only want to support a single non-system-Python version at a time. It occurs to me that a potential better illustrator than pipsi of the user experience problem I see with the status quo is the "vex" virtual environment manager, which I use to switch between Python 2 and Python 3 for different projects (my own primary OS is Fedora, so I have both installed as system packages): vex --python `which python2` -m py2-example vex --python `which python3` -m py3-example Given virtual environments created that way, I no longer need to remember which ones are Python 2 and which are Python 3 - "vex py2-example" and "vex py3-example" will automatically activate the right runtime. SCLs don't currently offer that same degree of seamlessness, since they rely on LD_LIBRARY_PATH being set in the environment, rather than building knowledge of the SCLs additional shared library directories directly into the binaries. They certainly *can* be used without it, but it's an ongoing source of friction since Python tools generally assume that a Python runtime will know where to find its shared libraries. Cheers, Nick. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect From daniel.davis at nih.gov Thu Jun 9 18:50:49 2016 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Thu, 9 Jun 2016 18:50:49 +0000 Subject: [scl.org] Problems with Python scripts that use SCL runtimes In-Reply-To: References: Message-ID: I must concede that scl is not as convenient as just having both python and python3 installed side by side, as they are on Ubuntu and Fedora. I really don't think developer convenience is the differentiator point of CentOS/RHEL however, CentOS/RHEL do well in managed environments. During my start-up experience, our desktops were Fedora, and the product ran on CentOS, depending on the version. That is not a bad way to do it if your governance/systems allows it. I am feeling your pain, however. My current organization runs Python 3 on Windows and deploys on CentOS, as the best solution to some concerns about security and what developers are allowed/encouraged to do. Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications Systems, National Library of Medicine, NIH -----Original Message----- From: Nick Coghlan [mailto:ncoghlan at redhat.com] Sent: Thursday, June 09, 2016 2:41 PM To: Davis, Daniel (NIH/NLM) [C] Cc: sclorg at redhat.com Subject: Re: [scl.org] Problems with Python scripts that use SCL runtimes On Thu, Jun 9, 2016 at 7:59 AM, Davis, Daniel (NIH/NLM) [C] wrote: > Nick, > > We also encountered this issue, and we wished DevOps and developers not to have the issue. > So, our development users, DevOps account, and CI account all have in their ~/.bash_profile: > > test -f /opt/rh/rh-python34/enable && source > /opt/rh/rh-python34/enable > > This enable script is different from "scl enable" in that it does not start a sub-process. > > This could be done for everyone via /etc/profile.d/, but we haven't gone that far - we would want then to test whether the user is in a group that gets Python 3, because we don't want this for everyone - vendor provided python scripts may sadly start with "#!/usr/bin/env python"! > > We also place this line in /etc/sysconfig/httpd, but now that we have switched from mod_wsgi to Phusion Passenger, it is not clear that this is needed. > > Does this address your issue? Not quite, although I do like it as a way to improve the situation in managed environments that only want to support a single non-system-Python version at a time. It occurs to me that a potential better illustrator than pipsi of the user experience problem I see with the status quo is the "vex" virtual environment manager, which I use to switch between Python 2 and Python 3 for different projects (my own primary OS is Fedora, so I have both installed as system packages): vex --python `which python2` -m py2-example vex --python `which python3` -m py3-example Given virtual environments created that way, I no longer need to remember which ones are Python 2 and which are Python 3 - "vex py2-example" and "vex py3-example" will automatically activate the right runtime. SCLs don't currently offer that same degree of seamlessness, since they rely on LD_LIBRARY_PATH being set in the environment, rather than building knowledge of the SCLs additional shared library directories directly into the binaries. They certainly *can* be used without it, but it's an ongoing source of friction since Python tools generally assume that a Python runtime will know where to find its shared libraries. Cheers, Nick. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect From noah at coderanger.net Fri Jun 10 00:44:38 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Thu, 9 Jun 2016 17:44:38 -0700 Subject: [scl.org] How to submit patches for SCLs Message-ID: <4371CDD1-B780-40D2-BD26-20F45D0DB512@coderanger.net> Specifically looking at SCL packages that are originally from RHSCL. I think that means I would need to send patches for the spec files to RedHat but I can't figure out where those specs actually live (i.e. which git repo to send a patch in for). Anyone have a direction to look at? Taking rh-python34 as an example, SCLo links to COPR (https://copr.fedorainfracloud.org/coprs/rhscl/rh-python34-el7) but COPR links to 404'd git repo (http://copr-dist-git.fedorainfracloud.org/cgit/rhscl/rh-python34-el7/rh-python34.git). --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dominic at cleal.org Fri Jun 10 07:13:13 2016 From: dominic at cleal.org (Dominic Cleal) Date: Fri, 10 Jun 2016 08:13:13 +0100 Subject: [scl.org] How to submit patches for SCLs In-Reply-To: <4371CDD1-B780-40D2-BD26-20F45D0DB512@coderanger.net> References: <4371CDD1-B780-40D2-BD26-20F45D0DB512@coderanger.net> Message-ID: <575A6889.7000600@cleal.org> On 10/06/16 01:44, Noah Kantrowitz wrote: > Specifically looking at SCL packages that are originally from RHSCL. I think that means I would need to send patches for the spec files to RedHat but I can't figure out where those specs actually live (i.e. which git repo to send a patch in for). Anyone have a direction to look at? Taking rh-python34 as an example, SCLo links to COPR (https://copr.fedorainfracloud.org/coprs/rhscl/rh-python34-el7) but COPR links to 404'd git repo (http://copr-dist-git.fedorainfracloud.org/cgit/rhscl/rh-python34-el7/rh-python34.git). It might be that the Copr builds on softwarecollections.org were from before Copr added dist-git support. Anyway, you'll find specs for all of the builds in the CentOS SCLo SIG under this GitHub org: https://github.com/sclorg-distgit, with one repo per component and branches within. I don't know if anybody's paying attention to pull requests, you might need to contact the maintainer too. -- Dominic Cleal dominic at cleal.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From noah at coderanger.net Fri Jun 10 08:03:03 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Fri, 10 Jun 2016 01:03:03 -0700 Subject: [scl.org] How to submit patches for SCLs In-Reply-To: <575A6889.7000600@cleal.org> References: <4371CDD1-B780-40D2-BD26-20F45D0DB512@coderanger.net> <575A6889.7000600@cleal.org> Message-ID: Will patches there end up in RHSCL too or do I need to send all patches to some magical place in RedHat too? --Noah > On Jun 10, 2016, at 12:13 AM, Dominic Cleal wrote: > > On 10/06/16 01:44, Noah Kantrowitz wrote: >> Specifically looking at SCL packages that are originally from RHSCL. I think that means I would need to send patches for the spec files to RedHat but I can't figure out where those specs actually live (i.e. which git repo to send a patch in for). Anyone have a direction to look at? Taking rh-python34 as an example, SCLo links to COPR (https://copr.fedorainfracloud.org/coprs/rhscl/rh-python34-el7) but COPR links to 404'd git repo (http://copr-dist-git.fedorainfracloud.org/cgit/rhscl/rh-python34-el7/rh-python34.git). > > It might be that the Copr builds on softwarecollections.org were from > before Copr added dist-git support. > > Anyway, you'll find specs for all of the builds in the CentOS SCLo SIG > under this GitHub org: https://github.com/sclorg-distgit, with one repo > per component and branches within. I don't know if anybody's paying > attention to pull requests, you might need to contact the maintainer too. > > -- > Dominic Cleal > dominic at cleal.org > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dominic at cleal.org Tue Jun 14 14:50:57 2016 From: dominic at cleal.org (Dominic Cleal) Date: Tue, 14 Jun 2016 15:50:57 +0100 Subject: [scl.org] [CentOS-devel] Obsolete centos-release-SCL in CentOS-6 with centos-release-scl-rh In-Reply-To: <574C388A.4030601@centos.org> References: <574C388A.4030601@centos.org> Message-ID: <576019D1.1080609@cleal.org> On 30/05/16 13:56, Johnny Hughes wrote: > Honza, > > Can you set centos-release-scl-rh (or if more appropriate, > centos-release-scl) to obsolete centos-release-SCL in CentOS-6. I have > removed the old SCL/ repo in 6.8 and you have newer versions of all > packages. I've updated the package to obsolete centos-release-SCL, and would appreciate somebody double-checking the upgrade works for them too before I tag it to -release. The build is at https://cbs.centos.org/koji/taskinfo?taskID=96522. (No Extras buildlogs/testing repo is available as far as I can tell, I filed https://bugs.centos.org/view.php?id=11025.) http://vault.centos.org/6.7/extras/x86_64/Packages/ contains the old centos-release-SCL for testing. -- Dominic Cleal dominic at cleal.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From hhorak at redhat.com Thu Jun 16 09:14:05 2016 From: hhorak at redhat.com (Honza Horak) Date: Thu, 16 Jun 2016 11:14:05 +0200 Subject: [scl.org] [CentOS-devel] Obsolete centos-release-SCL in CentOS-6 with centos-release-scl-rh In-Reply-To: <576019D1.1080609@cleal.org> References: <574C388A.4030601@centos.org> <576019D1.1080609@cleal.org> Message-ID: <57626DDD.6070003@redhat.com> I've tried the new package and it looks good, it does everything it should from my PoV. The tested scenarios were: * installing centos-release-SCL --> it pulled centos-release-scl-rh * updating previously installed centos-release-SCL --> centos-release-scl-rh replaced it Thanks! Honza On 06/14/2016 04:50 PM, Dominic Cleal wrote: > On 30/05/16 13:56, Johnny Hughes wrote: >> Honza, >> >> Can you set centos-release-scl-rh (or if more appropriate, >> centos-release-scl) to obsolete centos-release-SCL in CentOS-6. I have >> removed the old SCL/ repo in 6.8 and you have newer versions of all >> packages. > > I've updated the package to obsolete centos-release-SCL, and would > appreciate somebody double-checking the upgrade works for them too > before I tag it to -release. The build is at > https://cbs.centos.org/koji/taskinfo?taskID=96522. > > (No Extras buildlogs/testing repo is available as far as I can tell, I > filed https://bugs.centos.org/view.php?id=11025.) > > http://vault.centos.org/6.7/extras/x86_64/Packages/ contains the old > centos-release-SCL for testing. > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From dominic at cleal.org Thu Jun 16 09:17:50 2016 From: dominic at cleal.org (Dominic Cleal) Date: Thu, 16 Jun 2016 10:17:50 +0100 Subject: [scl.org] [CentOS-devel] Obsolete centos-release-SCL in CentOS-6 with centos-release-scl-rh In-Reply-To: <57626DDD.6070003@redhat.com> References: <574C388A.4030601@centos.org> <576019D1.1080609@cleal.org> <57626DDD.6070003@redhat.com> Message-ID: <57626EBE.90501@cleal.org> On 16/06/16 10:14, Honza Horak wrote: > I've tried the new package and it looks good, it does everything it > should from my PoV. Thanks for testing, I've tagged it for release. -- Dominic Cleal dominic at cleal.org From Fedora at FamilleCollet.com Tue Jun 21 06:18:44 2016 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 21 Jun 2016 08:18:44 +0200 Subject: [scl.org] sclo-php5*: new packages available for testing In-Reply-To: <9da89fb8-4b57-2160-584e-4c1abe5bad34@FamilleCollet.com> References: <9da89fb8-4b57-2160-584e-4c1abe5bad34@FamilleCollet.com> Message-ID: Le 01/06/2016 ? 14:40, Remi Collet a ?crit : > New packages built and tagged: > > sclo-php54-php-pecl-uploadprogress-1.0.3.1-1.el6.x86_64.rpm > sclo-php55-php-pecl-uploadprogress-1.0.3.1-1.el6.x86_64.rpm > sclo-php56-php-pecl-uploadprogress-1.0.3.1-1.el6.x86_64.rpm > sclo-php54-php-pecl-uploadprogress-1.0.3.1-1.el7.x86_64.rpm > sclo-php55-php-pecl-uploadprogress-1.0.3.1-1.el7.x86_64.rpm > sclo-php56-php-pecl-uploadprogress-1.0.3.1-1.el7.x86_64.rpm > > These packages extend the php54, php55 and rh-php56 collections, > and are available now in centos-sclo-sclo-testing repostiory. These packages are now tagged for release and will available soon in stable repository. Remi. From dominic at cleal.org Tue Jun 21 08:48:41 2016 From: dominic at cleal.org (Dominic Cleal) Date: Tue, 21 Jun 2016 09:48:41 +0100 Subject: [scl.org] sclo-vagrant1: new OpenStack provider available for testing Message-ID: <5768FF69.6090502@cleal.org> A new OpenStack provider for the sclo-vagrant1 collection is available for testing in the centos-sclo-sclo-testing repository. To install it, run: yum install centos-release-scl yum install --enablerepo=centos-sclo-sclo-testing sclo-vagrant1-vagrant-openstack-provider It can be used by running: scl enable sclo-vagrant1 "vagrant up --provider=openstack" and documentation is available for the provider in the -doc RPM or from https://github.com/ggiamarchi/vagrant-openstack-provider. Please provide feedback if you have it, else I'll push to the stable repo in a week or so. Kind regards, -- Dominic Cleal dominic at cleal.org From hhorak at redhat.com Tue Jun 28 14:01:22 2016 From: hhorak at redhat.com (Honza Horak) Date: Tue, 28 Jun 2016 16:01:22 +0200 Subject: [scl.org] How to submit patches for SCLs In-Reply-To: References: <4371CDD1-B780-40D2-BD26-20F45D0DB512@coderanger.net> <575A6889.7000600@cleal.org> Message-ID: <57728332.5020903@redhat.com> General rule of what goes in is that it always depends on the author of the particular collection. For collections coming from SCLo SIG group (community), the best thing to do would be sending pull requests on github as mentioned bellow and contact this ML if nothing happens (not everybody tracks github appropriately). For collections coming from Red Hat (usually those with rh- prefix), we have quite strict rule, that we don't want to include anything what is not included in RHSCL packages. So, what might be more successful strategy for collections coming from Red Hat is reporting bug to the Red Hat Bugzilla and increase probability of inclusion by contacting Red Hat Support. HTH, Honza On 06/10/2016 10:03 AM, Noah Kantrowitz wrote: > Will patches there end up in RHSCL too or do I need to send all patches to some magical place in RedHat too? > > --Noah > >> On Jun 10, 2016, at 12:13 AM, Dominic Cleal wrote: >> >> On 10/06/16 01:44, Noah Kantrowitz wrote: >>> Specifically looking at SCL packages that are originally from RHSCL. I think that means I would need to send patches for the spec files to RedHat but I can't figure out where those specs actually live (i.e. which git repo to send a patch in for). Anyone have a direction to look at? Taking rh-python34 as an example, SCLo links to COPR (https://copr.fedorainfracloud.org/coprs/rhscl/rh-python34-el7) but COPR links to 404'd git repo (http://copr-dist-git.fedorainfracloud.org/cgit/rhscl/rh-python34-el7/rh-python34.git). >> >> It might be that the Copr builds on softwarecollections.org were from >> before Copr added dist-git support. >> >> Anyway, you'll find specs for all of the builds in the CentOS SCLo SIG >> under this GitHub org: https://github.com/sclorg-distgit, with one repo >> per component and branches within. I don't know if anybody's paying >> attention to pull requests, you might need to contact the maintainer too. >> >> -- >> Dominic Cleal >> dominic at cleal.org >> >> _______________________________________________ >> 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 >