From jortel at redhat.com Wed Mar 1 16:22:26 2017 From: jortel at redhat.com (Jeff Ortel) Date: Wed, 1 Mar 2017 10:22:26 -0600 Subject: [scl.org] mongo26 In-Reply-To: <1488268501.2930.6.camel@redhat.com> References: <08e32aad-069d-c5b7-06b5-5b6c677b813b@redhat.com> <1488268501.2930.6.camel@redhat.com> Message-ID: On 02/28/2017 01:55 AM, Marek Skalick? wrote: > Jeff Ortel p??e v Po 27. 02. 2017 v 15:09 -0600: >> Hello, >> >> I am with Satellite engineering and trying to determine if mongoDB >> 2.6 is available through SCL for EL6. >> Looking at the web[1], it appears it's available from Copr builds but >> not from the YUM repositories listed on >> that page. Also, I looked that the RH (stage) CDN and only find >> mongodb24-* in rhscl/ for both EL6 & 7. Can >> you help me resolve this? > > Hi, > it is available. It should be in RHEL and CentOS yum repositories too. > > The naming was changed, so collection name is rh-mongodb26 ("rh-" > prefix was added). Does this help? Yes. Found it on the CDN. The naming fooled me. Thanks! > > Marek > >> >> Thanks, >> >> Jeff >> >> >> >> [1] https://www.softwarecollections.org/en/scls/rhscl/rh-mongodb26/ >> >> _______________________________________________ >> 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: 847 bytes Desc: OpenPGP digital signature URL: From hhorak at redhat.com Mon Mar 6 10:00:10 2017 From: hhorak at redhat.com (Honza Horak) Date: Mon, 6 Mar 2017 11:00:10 +0100 Subject: [scl.org] How different is rh-postgresql94 from community Postgres 94? In-Reply-To: References: Message-ID: Hello Aawardhan, how do you install Postgres 9.5 in CentOS? Since it may be different answer for the two cases bellow: 1) install from CentOS SCLo SIG repos: yum install centos-release-scl-rh yum install rh-postgresql95 2) install from Upstream repos: yum install https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-7-x86_64/pgdg-centos95-9.5-3.noarch.rpm yum install postgresql95-server Honza On 02/28/2017 06:28 AM, Aawardhan Logandan wrote: > If my product is certified to run in Postgres 9.5 (tested in Cent OS), > can I claim that it will work in rh-postgresql95? > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Mon Mar 6 11:31:11 2017 From: hhorak at redhat.com (Honza Horak) Date: Mon, 6 Mar 2017 12:31:11 +0100 Subject: [scl.org] How different is rh-postgresql94 from community Postgres 94? In-Reply-To: References: Message-ID: <8cc0b45d-92e2-e5de-bb69-0f9586b1c2c0@redhat.com> The biggest differences will be visible for admin, because rh-postgresql95 uses concept of Software Collections (https://www.softwarecollections.org/en/docs/) which means binaries are put into alternate directory (/opt) and user needs to run `scl` command to adjust $PATH first: $ psql bash: psql: command not found... $ scl enable rh-postgresql95 bash $ psql psql: could not connect to server: No such file or directory Also name of the service is different, rh-postgresql95 uses this name: systemctl status rh-postgresql95-postgresql And location of the data is different as well, by default data files are located at: /var/opt/rh/rh-postgresql95/lib/pgsql As for the feature set and usage from remote server, I don't think there are any differences, so applications won't see any difference IMO. Regards, Honza On 03/06/2017 12:22 PM, Aawardhan Logandan wrote: > We install it from Upstream repository. > > In general what are the difference between postgresql95 and rh-postgresql95? > > Thanks, > Aawardhan > > On Mon, Mar 6, 2017 at 3:30 PM, Honza Horak > wrote: > > Hello Aawardhan, > > how do you install Postgres 9.5 in CentOS? Since it may be different > answer for the two cases bellow: > > 1) install from CentOS SCLo SIG repos: > > yum install centos-release-scl-rh > yum install rh-postgresql95 > > 2) install from Upstream repos: > > yum install > https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-7-x86_64/pgdg-centos95-9.5-3.noarch.rpm > > yum install postgresql95-server > > Honza > > On 02/28/2017 06:28 AM, Aawardhan Logandan wrote: > > If my product is certified to run in Postgres 9.5 (tested in > Cent OS), > can I claim that it will work in rh-postgresql95? > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > > > From aawardhan at gmail.com Mon Mar 6 11:22:27 2017 From: aawardhan at gmail.com (Aawardhan Logandan) Date: Mon, 6 Mar 2017 16:52:27 +0530 Subject: [scl.org] How different is rh-postgresql94 from community Postgres 94? In-Reply-To: References: Message-ID: We install it from Upstream repository. In general what are the difference between postgresql95 and rh-postgresql95? Thanks, Aawardhan On Mon, Mar 6, 2017 at 3:30 PM, Honza Horak wrote: > Hello Aawardhan, > > how do you install Postgres 9.5 in CentOS? Since it may be different > answer for the two cases bellow: > > 1) install from CentOS SCLo SIG repos: > > yum install centos-release-scl-rh > yum install rh-postgresql95 > > 2) install from Upstream repos: > > yum install https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhe > l-7-x86_64/pgdg-centos95-9.5-3.noarch.rpm > yum install postgresql95-server > > Honza > > On 02/28/2017 06:28 AM, Aawardhan Logandan wrote: > >> If my product is certified to run in Postgres 9.5 (tested in Cent OS), >> can I claim that it will work in rh-postgresql95? >> >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawardhan at gmail.com Mon Mar 6 11:34:26 2017 From: aawardhan at gmail.com (Aawardhan Logandan) Date: Mon, 6 Mar 2017 17:04:26 +0530 Subject: [scl.org] How different is rh-postgresql94 from community Postgres 94? In-Reply-To: <8cc0b45d-92e2-e5de-bb69-0f9586b1c2c0@redhat.com> References: <8cc0b45d-92e2-e5de-bb69-0f9586b1c2c0@redhat.com> Message-ID: Thanks a lot !! that was helpful. On Mon, Mar 6, 2017 at 5:01 PM, Honza Horak wrote: > The biggest differences will be visible for admin, because rh-postgresql95 > uses concept of Software Collections (https://www.softwarecollectio > ns.org/en/docs/) which means binaries are put into alternate directory > (/opt) and user needs to run `scl` command to adjust $PATH first: > > $ psql > bash: psql: command not found... > $ scl enable rh-postgresql95 bash > $ psql > psql: could not connect to server: No such file or directory > > Also name of the service is different, rh-postgresql95 uses this name: > > systemctl status rh-postgresql95-postgresql > > And location of the data is different as well, by default data files are > located at: > > /var/opt/rh/rh-postgresql95/lib/pgsql > > As for the feature set and usage from remote server, I don't think there > are any differences, so applications won't see any difference IMO. > > Regards, > Honza > > On 03/06/2017 12:22 PM, Aawardhan Logandan wrote: > >> We install it from Upstream repository. >> >> In general what are the difference between postgresql95 and >> rh-postgresql95? >> >> Thanks, >> Aawardhan >> >> On Mon, Mar 6, 2017 at 3:30 PM, Honza Horak > > wrote: >> >> Hello Aawardhan, >> >> how do you install Postgres 9.5 in CentOS? Since it may be different >> answer for the two cases bellow: >> >> 1) install from CentOS SCLo SIG repos: >> >> yum install centos-release-scl-rh >> yum install rh-postgresql95 >> >> 2) install from Upstream repos: >> >> yum install >> https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhe >> l-7-x86_64/pgdg-centos95-9.5-3.noarch.rpm >> > el-7-x86_64/pgdg-centos95-9.5-3.noarch.rpm> >> yum install postgresql95-server >> >> Honza >> >> On 02/28/2017 06:28 AM, Aawardhan Logandan wrote: >> >> If my product is certified to run in Postgres 9.5 (tested in >> Cent OS), >> can I claim that it will work in rh-postgresql95? >> >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fedora at FamilleCollet.com Tue Mar 7 10:19:44 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 7 Mar 2017 11:19:44 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php* packages available for testing In-Reply-To: References: Message-ID: Le 14/02/2017 ? 12:09, Remi Collet a ?crit : > Yet another package available in centos-sclo-sclo-testing > > "PHP extension for interfacing with Redis" > > A stable version was recently released with PHP 5 and 7 compatibility. > > > For rh-php56 > > * sclo-php56-php-pecl-redis-3.1.1-1 > > For rh-php70 > > * sclo-php70-php-pecl-redis-3.1.1-1 > Pushed to stable From Fedora at FamilleCollet.com Tue Mar 7 10:20:22 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 7 Mar 2017 11:20:22 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php* packages available for testing In-Reply-To: References: Message-ID: <580e906c-9cca-f3a5-c548-a5b928323cd7@FamilleCollet.com> Le 15/02/2017 ? 17:09, Remi Collet a ?crit : > For rh-php70 > > * sclo-php70-php-pecl-msgpack-2.0.2-1 > * sclo-php70-php-pecl-memcached-3.0.2-1 (EL-7 only) Pushed to stable From Fedora at FamilleCollet.com Tue Mar 7 10:44:10 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 7 Mar 2017 11:44:10 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php*-php-imap packages available for testing Message-ID: <150a2772-8f0d-0d38-7e1d-a78a134c9b86@FamilleCollet.com> Yet another package available in centos-sclo-sclo-testing The php-imap package module will add IMAP (Internet Message Access Protocol) support to PHP. IMAP is a protocol for retrieving and uploading e-mail messages on mail servers. PHP is an HTML-embedded scripting language. If you need IMAP support for PHP applications, you will need to install this package. For rh-php56 (EL-7 only) * sclo-php56-php-imap-5.6.25-2.el7 For rh-php70 (EL-7 only) * sclo-php70-php-imap-7.0.14-2.el7 Notices: - this extension is already available in upstream collection for CentOS/RHEL 6 (rh-php56-php-imap andf rh-php70-php-imap) - this extension requires "libc-client" which is not part of CentOS/RHEL 7, but available in EPEL-7. - in both versions the yum install "rh-phpxx-php-imap" will work. Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo From Fedora at FamilleCollet.com Tue Mar 7 13:21:28 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 7 Mar 2017 14:21:28 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php*-php-smbclient packages available for testing Message-ID: <3f2e3bd6-1b70-daed-6c4c-add3b193c20a@FamilleCollet.com> Yet another package available in centos-sclo-sclo-testing smbclient is a PHP extension that uses Samba's libsmbclient library to provide Samba related functions and 'smb' streams to PHP programs. For rh-php56 * sclo-php56-php-smbclient-0.9.0-1 For rh-php70 * sclo-php70-php-smbclient-0.9.0-1 This extension may be used by (among other projects): - nextcloud / owncloud (via icewind/smb) - EGroupware (via php streams). Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo From Fedora at FamilleCollet.com Wed Mar 8 14:56:44 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 8 Mar 2017 15:56:44 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php*-php-mcrypt packages available for testing Message-ID: Yet another package available in centos-sclo-sclo-testing The -mcrypt package contains a dynamic shared object that will add support for using the mcrypt library to PHP. For rh-php56 * sclo-php56-php-mcrypt-5.6.28-1 For rh-php70 * sclo-php70-php-mcrypt-7.0.16-1 WARNING: libmcrypt is a dead project, use this extension for crytography at your own risk. This extension is still used by lot of projects, like ZendFramework, despite most recent versions have switch to something maintained. You can also read: https://blog.remirepo.net/post/2015/07/07/About-libmcrypt-and-php-mcrypt Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo From Fedora at FamilleCollet.com Thu Mar 9 13:10:37 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Thu, 9 Mar 2017 14:10:37 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php*-php-tidy packages available for testing Message-ID: <55911108-bab3-d19e-a0f4-e584439c0a1f@FamilleCollet.com> Yet another package available in centos-sclo-sclo-testing The php-tidy package contains a dynamic shared object that will add support for using the tidy library to PHP. http://php.net/tidy For rh-php56 (EL-7 only) * sclo-php56-php-tidy-5.6.25-1.el7 For rh-php70 (EL-7 only) * sclo-php70-php-tidy-7.0.10-1.el7 Notices: - this extension is already available in upstream collection for CentOS/RHEL 6 (rh-php56-php-tidy and rh-php70-php-tidy) - this extension requires "libtidy" which is not part of CentOS/RHEL 7, but available in EPEL-7. - in both versions the yum install "rh-phpxx-php-tidy" will work. Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo From Souvignier at itc.rwth-aachen.de Fri Mar 10 10:15:40 2017 From: Souvignier at itc.rwth-aachen.de (Souvignier, Daniel) Date: Fri, 10 Mar 2017 10:15:40 +0000 Subject: [scl.org] New git package Message-ID: <0de1d08ab1e04155bd60f5f394161076@rwthex-w2-b.rwth-ad.de> Hi all, due to GitLab requiring at least git 2.9 for their new 9.0 release which will be released on 22nd March, something needs to be done either here or on distro side. Is it possible to do a new software collection with the recent git version (should be 2.12 as of now)? Regards, Daniel -- Daniel Souvignier IT Center Gruppe: Linux-basierte Anwendungen Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel.: +49 241 80-29267 souvignier at itc.rwth-aachen.de www.itc.rwth-aachen.de -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5780 bytes Desc: not available URL: From Souvignier at itc.rwth-aachen.de Fri Mar 10 10:17:58 2017 From: Souvignier at itc.rwth-aachen.de (Souvignier, Daniel) Date: Fri, 10 Mar 2017 10:17:58 +0000 Subject: [scl.org] New git package In-Reply-To: <0de1d08ab1e04155bd60f5f394161076@rwthex-w2-b.rwth-ad.de> References: <0de1d08ab1e04155bd60f5f394161076@rwthex-w2-b.rwth-ad.de> Message-ID: <5d2dcc955f5549d48e13ba4b41e080d9@rwthex-s1-a.rwth-ad.de> Forgot to include a link, see here: https://gitlab.com/gitlab-org/gitlab-ce/issues/19609 Regards, Daniel -- Daniel Souvignier IT Center Gruppe: Linux-basierte Anwendungen Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel.: +49 241 80-29267 souvignier at itc.rwth-aachen.de www.itc.rwth-aachen.de Von: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] Im Auftrag von Souvignier, Daniel Gesendet: Freitag, 10. M?rz 2017 11:16 An: sclorg at redhat.com Betreff: [scl.org] New git package Hi all, due to GitLab requiring at least git 2.9 for their new 9.0 release which will be released on 22nd March, something needs to be done either here or on distro side. Is it possible to do a new software collection with the recent git version (should be 2.12 as of now)? Regards, Daniel -- Daniel Souvignier IT Center Gruppe: Linux-basierte Anwendungen Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel.: +49 241 80-29267 souvignier at itc.rwth-aachen.de www.itc.rwth-aachen.de -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5780 bytes Desc: not available URL: From Jaroslaw.Polok at cern.ch Fri Mar 10 10:35:29 2017 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Fri, 10 Mar 2017 11:35:29 +0100 Subject: [scl.org] New git package In-Reply-To: <5d2dcc955f5549d48e13ba4b41e080d9@rwthex-s1-a.rwth-ad.de> References: <0de1d08ab1e04155bd60f5f394161076@rwthex-w2-b.rwth-ad.de> <5d2dcc955f5549d48e13ba4b41e080d9@rwthex-s1-a.rwth-ad.de> Message-ID: Hello On 03/10/2017 11:17 AM, Souvignier, Daniel wrote: > Forgot to include a link, see here: > https://gitlab.com/gitlab-org/gitlab-ce/issues/19609 > Software collections already do provide Git 2.9(.3): https://www.softwarecollections.org/en/scls/rhscl/rh-git29/ Best Regards Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From Souvignier at itc.rwth-aachen.de Fri Mar 10 11:56:44 2017 From: Souvignier at itc.rwth-aachen.de (Souvignier, Daniel) Date: Fri, 10 Mar 2017 11:56:44 +0000 Subject: [scl.org] New git package In-Reply-To: References: <0de1d08ab1e04155bd60f5f394161076@rwthex-w2-b.rwth-ad.de> <5d2dcc955f5549d48e13ba4b41e080d9@rwthex-s1-a.rwth-ad.de> Message-ID: <04a85aade986483fbf550ca02a46e57d@rwthex-w2-b.rwth-ad.de> That's true, but it's a quite old collection already and I'm not sure if it still gets updates, so it would be better to do a new one. I know that I can use the old one for now. Regards, Daniel -- Daniel Souvignier IT Center Gruppe: Linux-basierte Anwendungen Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel.: +49 241 80-29267 souvignier at itc.rwth-aachen.de www.itc.rwth-aachen.de -----Urspr?ngliche Nachricht----- Von: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] Im Auftrag von Jarek Polok Gesendet: Freitag, 10. M?rz 2017 11:35 An: sclorg at redhat.com Betreff: Re: [scl.org] New git package Hello On 03/10/2017 11:17 AM, Souvignier, Daniel wrote: > Forgot to include a link, see here: > https://gitlab.com/gitlab-org/gitlab-ce/issues/19609 > Software collections already do provide Git 2.9(.3): https://www.softwarecollections.org/en/scls/rhscl/rh-git29/ 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5780 bytes Desc: not available URL: From Jaroslaw.Polok at cern.ch Fri Mar 10 12:45:35 2017 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Fri, 10 Mar 2017 13:45:35 +0100 Subject: [scl.org] New git package In-Reply-To: <04a85aade986483fbf550ca02a46e57d@rwthex-w2-b.rwth-ad.de> References: <0de1d08ab1e04155bd60f5f394161076@rwthex-w2-b.rwth-ad.de> <5d2dcc955f5549d48e13ba4b41e080d9@rwthex-s1-a.rwth-ad.de> <04a85aade986483fbf550ca02a46e57d@rwthex-w2-b.rwth-ad.de> Message-ID: On 03/10/2017 12:56 PM, Souvignier, Daniel wrote: > That's true, but it's a quite old collection already and I'm not sure if it > still gets updates, so it would be better to do a new one. I know that I can > use the old one for now. Software Collections 2.3 including git 2.9.3 has been released November 2016 and its Retirement Date is November 2018. (these are the dates for upstream Red Hat product) (git 2.9.3 itself is few months older of course) So I think its still OK to use it for some time Best Regards Jarek > > Regards, > Daniel > > -- > Daniel Souvignier > > IT Center > Gruppe: Linux-basierte Anwendungen > Abteilung: Systeme und Betrieb > RWTH Aachen University > Seffenter Weg 23 > 52074 Aachen > Tel.: +49 241 80-29267 > souvignier at itc.rwth-aachen.de > www.itc.rwth-aachen.de > > > -----Urspr?ngliche Nachricht----- > Von: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] Im Auftrag > von Jarek Polok > Gesendet: Freitag, 10. M?rz 2017 11:35 > An: sclorg at redhat.com > Betreff: Re: [scl.org] New git package > > Hello > > On 03/10/2017 11:17 AM, Souvignier, Daniel wrote: >> Forgot to include a link, see here: >> https://gitlab.com/gitlab-org/gitlab-ce/issues/19609 >> > > Software collections already do provide Git 2.9(.3): > > https://www.softwarecollections.org/en/scls/rhscl/rh-git29/ > > > 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 > -- __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From Souvignier at itc.rwth-aachen.de Fri Mar 10 13:03:14 2017 From: Souvignier at itc.rwth-aachen.de (Souvignier, Daniel) Date: Fri, 10 Mar 2017 13:03:14 +0000 Subject: [scl.org] New git package In-Reply-To: References: <0de1d08ab1e04155bd60f5f394161076@rwthex-w2-b.rwth-ad.de> <5d2dcc955f5549d48e13ba4b41e080d9@rwthex-s1-a.rwth-ad.de> <04a85aade986483fbf550ca02a46e57d@rwthex-w2-b.rwth-ad.de> Message-ID: Thing is: When will git 2.9 itself be EOL? Or do upstream patches get backported into scls as well (similar to normal packages)? Regards, Daniel -- Daniel Souvignier IT Center Gruppe: Linux-basierte Anwendungen Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel.: +49 241 80-29267 souvignier at itc.rwth-aachen.de www.itc.rwth-aachen.de -----Urspr?ngliche Nachricht----- Von: Jarek Polok [mailto:Jaroslaw.Polok at cern.ch] Gesendet: Freitag, 10. M?rz 2017 13:46 An: Souvignier, Daniel ; sclorg at redhat.com Betreff: Re: AW: [scl.org] New git package On 03/10/2017 12:56 PM, Souvignier, Daniel wrote: > That's true, but it's a quite old collection already and I'm not sure > if it still gets updates, so it would be better to do a new one. I > know that I can use the old one for now. Software Collections 2.3 including git 2.9.3 has been released November 2016 and its Retirement Date is November 2018. (these are the dates for upstream Red Hat product) (git 2.9.3 itself is few months older of course) So I think its still OK to use it for some time Best Regards Jarek > > Regards, > Daniel > > -- > Daniel Souvignier > > IT Center > Gruppe: Linux-basierte Anwendungen > Abteilung: Systeme und Betrieb > RWTH Aachen University > Seffenter Weg 23 > 52074 Aachen > Tel.: +49 241 80-29267 > souvignier at itc.rwth-aachen.de > www.itc.rwth-aachen.de > > > -----Urspr?ngliche Nachricht----- > Von: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] Im > Auftrag von Jarek Polok > Gesendet: Freitag, 10. M?rz 2017 11:35 > An: sclorg at redhat.com > Betreff: Re: [scl.org] New git package > > Hello > > On 03/10/2017 11:17 AM, Souvignier, Daniel wrote: >> Forgot to include a link, see here: >> https://gitlab.com/gitlab-org/gitlab-ce/issues/19609 >> > > Software collections already do provide Git 2.9(.3): > > https://www.softwarecollections.org/en/scls/rhscl/rh-git29/ > > > 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 > -- __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5780 bytes Desc: not available URL: From Fedora at FamilleCollet.com Mon Mar 20 12:04:08 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 20 Mar 2017 13:04:08 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php*-php-* packages available Message-ID: <4e95ad09-88aa-e172-befd-6d62055cec45@FamilleCollet.com> Just pushed to centos-sclo-sclo stable repository: For rh-php56 * sclo-php56-php-imap-5.6.25-2.el7 (EL-7 only) * sclo-php56-php-smbclient-0.9.0-1 * sclo-php56-php-mcrypt-5.6.28-1 * sclo-php56-php-tidy-5.6.25-1 (EL-7 only) For rh-php70 * sclo-php70-php-imap-7.0.14-2.el7 (EL-7 only) * sclo-php70-php-smbclient-0.9.0-1 * sclo-php70-php-mcrypt-7.0.16-1 * sclo-php70-php-tidy-7.0.10-1 (EL-7 only) Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo From hhorak at redhat.com Tue Mar 21 15:05:26 2017 From: hhorak at redhat.com (Honza Horak) Date: Tue, 21 Mar 2017 16:05:26 +0100 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide Message-ID: This is basically a kick-off for getting more feedback for an idea shared at http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. Shortly, SCL has worked nicely for several years and people love them. But even the beloved ones have some issues. And what we hear from users, the issues with Software Collections concept currently are basically those: * we need to use scl enable, which changes $PATH and other environment variables, so the binaries placed in different location are visible by the system * scripts originally written for "normal" MySQL use full paths (like /usr/bin/mysql) which does not work when we only have the Software Collection installed * Data directory, config files and log files are on different location than it is common The blog post tries to summarize possible solution, which I'm looking for feedback now, ideally by replying to this mail.. TIA, Honza From manuel.vacelet at enalean.com Tue Mar 21 17:04:13 2017 From: manuel.vacelet at enalean.com (Vacelet, Manuel) Date: Tue, 21 Mar 2017 18:04:13 +0100 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: Message-ID: On Tue, Mar 21, 2017 at 4:05 PM, Honza Horak wrote: > This is basically a kick-off for getting more feedback for an idea shared > at http://www.themindiseverything.eu/2017/03/software- > collections-daemons-made.html. > > Shortly, SCL has worked nicely for several years and people love them. But > even the beloved ones have some issues. And what we hear from users, the > issues with Software Collections concept currently are basically those: > > * we need to use scl enable, which changes $PATH and other environment > variables, so the binaries placed in different location are visible by the > system > * scripts originally written for "normal" MySQL use full paths (like > /usr/bin/mysql) which does not work when we only have the Software > Collection installed > * Data directory, config files and log files are on different location > than it is common > > The blog post tries to summarize possible solution, which I'm looking for > feedback now, ideally by replying to this mail.. > > Hi Honza, I do love SCLs and I share most of the pitfalls you raised about using them (I would have loved not to write tons of custom scripts to manage my various parallel PHP / Nginx versions on my systems). Do you foresee a way to deal with package dependencies ? I might be wrong but when I'm installing packages that requires php(language>=5.3) it doesn't see rh-php56 or rh-php70 scls It's a bit cumbersome because I end-up having the default package installed whereas I'm only using the ones that come from SCLs Last, as an alternative to wrapper package, I find useful the "update-alternative" from debian. It's pretty much the same thing (links AFAIK) but switch is done with a command rather than a package install. Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Tue Mar 21 17:17:34 2017 From: hhorak at redhat.com (Honza Horak) Date: Tue, 21 Mar 2017 18:17:34 +0100 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: Message-ID: <44620a1a-9cf1-aff5-4d62-d2bb4361e691@redhat.com> On 03/21/2017 06:04 PM, Vacelet, Manuel wrote: > On Tue, Mar 21, 2017 at 4:05 PM, Honza Horak > wrote: > > This is basically a kick-off for getting more feedback for an idea > shared at > http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html > . > > Shortly, SCL has worked nicely for several years and people love > them. But even the beloved ones have some issues. And what we hear > from users, the issues with Software Collections concept currently > are basically those: > > * we need to use scl enable, which changes $PATH and other > environment variables, so the binaries placed in different location > are visible by the system > * scripts originally written for "normal" MySQL use full paths (like > /usr/bin/mysql) which does not work when we only have the Software > Collection installed > * Data directory, config files and log files are on different > location than it is common > > The blog post tries to summarize possible solution, which I'm > looking for feedback now, ideally by replying to this mail.. > > > Hi Honza, > > I do love SCLs and I share most of the pitfalls you raised about using > them (I would have loved not to write tons of custom scripts to manage > my various parallel PHP / Nginx versions on my systems). > > Do you foresee a way to deal with package dependencies ? > I might be wrong but when I'm installing packages that requires > php(language>=5.3) it doesn't see rh-php56 or rh-php70 scls > It's a bit cumbersome because I end-up having the default package > installed whereas I'm only using the ones that come from SCLs Interesting point. In case php(language) is common in php world, then someone might expect php from base is installed when asking for such requirement and thus adding the same virtual name into rh-php56 or rh-php70 scls might make troubles. Or maybe more important issue -- if modules are meant to work with php 5.5, then they might break with 5.6, especially in case of binary extensions. That's why the original idea was concerning the daemon SCLs like databases only. > Last, as an alternative to wrapper package, I find useful the > "update-alternative" from debian. > It's pretty much the same thing (links AFAIK) but switch is done with a > command rather than a package install. Yeah, it would be nice, although I'm not sure entirely how this concept works with tens of binaries (requiring to run alternative command for every binary would not be very nice). Also, alternatives require all of the alternatives to support this method, which we are not able to do in RHEL-7/CentOS-7, because it would mean to change packages from the base system. Honza From wesley.griffin at nist.gov Wed Mar 22 03:30:21 2017 From: wesley.griffin at nist.gov (Griffin, Wesley (Fed)) Date: Wed, 22 Mar 2017 03:30:21 +0000 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: Message-ID: I will chime in as the "old curmudgeon" - as long as you don't break the existing use case, then I'm fine with any changes. The blog post says subpackages will be used to ensure no breakage - I just want to re-iterate that this is important and should not get lost if the proposal changes. Thanks, Wes ________________________________________ From: sclorg-bounces at redhat.com on behalf of Honza Horak Sent: Tuesday, March 21, 2017 11:05:26 AM To: sclorg at redhat.com Subject: [scl.org] Idea: Software Collections Daemons Made System-wide This is basically a kick-off for getting more feedback for an idea shared at http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. Shortly, SCL has worked nicely for several years and people love them. But even the beloved ones have some issues. And what we hear from users, the issues with Software Collections concept currently are basically those: * we need to use scl enable, which changes $PATH and other environment variables, so the binaries placed in different location are visible by the system * scripts originally written for "normal" MySQL use full paths (like /usr/bin/mysql) which does not work when we only have the Software Collection installed * Data directory, config files and log files are on different location than it is common The blog post tries to summarize possible solution, which I'm looking for feedback now, ideally by replying to this mail.. TIA, Honza _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg From ncoghlan at redhat.com Wed Mar 22 06:42:10 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Wed, 22 Mar 2017 16:42:10 +1000 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: Message-ID: On Wed, Mar 22, 2017 at 1:05 AM, Honza Horak wrote: > This is basically a kick-off for getting more feedback for an idea shared at > http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. > > Shortly, SCL has worked nicely for several years and people love them. But > even the beloved ones have some issues. And what we hear from users, the > issues with Software Collections concept currently are basically those: > > * we need to use scl enable, which changes $PATH and other environment > variables, so the binaries placed in different location are visible by the > system > * scripts originally written for "normal" MySQL use full paths (like > /usr/bin/mysql) which does not work when we only have the Software > Collection installed > * Data directory, config files and log files are on different location than > it is common > > The blog post tries to summarize possible solution, which I'm looking for > feedback now, ideally by replying to this mail.. If you change the exec line in the wrapper script to be: exec -a $0 `basename "$0"` "$@" I believe this may actually also deal with the Python sys.executable and hence setuptools and pipsi compatibility problems that I raised in https://bugzilla.redhat.com/show_bug.cgi?id=1385471 Otherwise sys.executable will still be set to the unwrapped binary, and any generated shebang lines would refer to that rather than the wrapper script. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From hhorak at redhat.com Wed Mar 22 07:41:54 2017 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Mar 2017 08:41:54 +0100 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: Message-ID: <9e6e2808-e291-dce1-129a-de0508885df2@redhat.com> I don't expect we'll do this for existing packages we provide, it's more a vision for new collections (e.g. mariadb 10.2 at some point). Anyway, do you also see the same point for those upcoming collections (where we're not tight by keeping backward compatibility), e.g. because you're fine with all the SCL specifics and adapting to the new way would be troublesome? Honza On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote: > I will chime in as the "old curmudgeon" - as long as you don't break the existing use case, then I'm fine with any changes. The blog post says subpackages will be used to ensure no breakage - I just want to re-iterate that this is important and should not get lost if the proposal changes. > > Thanks, > Wes > > ________________________________________ > From: sclorg-bounces at redhat.com on behalf of Honza Horak > Sent: Tuesday, March 21, 2017 11:05:26 AM > To: sclorg at redhat.com > Subject: [scl.org] Idea: Software Collections Daemons Made System-wide > > This is basically a kick-off for getting more feedback for an idea > shared at > http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. > > Shortly, SCL has worked nicely for several years and people love them. > But even the beloved ones have some issues. And what we hear from users, > the issues with Software Collections concept currently are basically those: > > * we need to use scl enable, which changes $PATH and other environment > variables, so the binaries placed in different location are visible by > the system > * scripts originally written for "normal" MySQL use full paths (like > /usr/bin/mysql) which does not work when we only have the Software > Collection installed > * Data directory, config files and log files are on different location > than it is common > > The blog post tries to summarize possible solution, which I'm looking > for feedback now, ideally by replying to this mail.. > > TIA, > Honza > > _______________________________________________ > 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 Fedora at FamilleCollet.com Wed Mar 22 07:44:42 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 22 Mar 2017 08:44:42 +0100 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: Message-ID: Le 21/03/2017 ? 18:04, Vacelet, Manuel a ?crit : > Do you foresee a way to deal with package dependencies ? > I might be wrong but when I'm installing packages that requires > php(language>=5.3) it doesn't see rh-php56 or rh-php70 scls The virtual provides used in PHP stack are not in the SCL packages by design (to really not alter base system) Adding this virtual provide in a system-wide additional and optional sub-package doesn't seems a real good idea. 1/ there is tons of extensions, so each one will need a system-wide subpackage... And we cannot (in RHEL) write rich dependencies... 2/ this will add multiple providers for php(language), thus making yum crazy when trying to resolve it (as it was in EL-5 with dual php/php53 stack) > It's a bit cumbersome because I end-up having the default package installed > whereas I'm only using the ones that come from SCLs I think we have to stay in this situation until more modern dependencies will be allowed and used in packaged app (rpm 4.13) Requires: (php(language) >= 5.3 or rh-php56-php(language) or rh-php70-php(language)) Requires (php-mysqli if php-common) Requires (rh-php56-php-mysqli if rh-php56-php-common) Requires (rh-php70-php-mysqli if rh-php70-php-common) Notice: be aware that packaged app (in EPEL) cannot be warrantied to work with a different PHP versions than the base one. Ex (from upstream information) * phpMyAdmin 4.0 (EL-6) only supports PHP 5.x * phpMyAdmin 4.4 (EL-7) supports PHP 5.3 to 7.0 * phpMyAdmin 4.6 (Fedora) supports PHP 5.5 to 7.1 The real and proper solution will be to have a rh-php56-phpMyAdmin package, design to work with the rh-php56 collection. Remi. From Fedora at FamilleCollet.com Wed Mar 22 10:07:30 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 22 Mar 2017 11:07:30 +0100 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: Message-ID: <7da2bb63-12ad-048a-d1bc-4a20eef66ff2@FamilleCollet.com> Le 21/03/2017 ? 16:05, Honza Horak a ?crit : > This is basically a kick-off for getting more feedback for an idea > shared at > http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. Having an -system-wide package, providing a set of symlinks looks like a nice idea This can become hard to create, when there is multiple packages providing commands / service: e.g php-cli => /usr/bin/php php-devel => /usr/bin/phpize (and some others) php-pear => /usr/bin/pear (and some others) php-fpm => /usr/bin/php-fpm and php-fpm.service php-pecl-xdebug => /usr/bin/debugclient Another possible tricky bit is the socket used For now php-fpm listen on a network socket (localhost:9000) in base system and SCL, so the SCL provided service can really simply replace the system default one (like for databases). But, if we switch to UDS in the future this will become a bit more tricky (each SCL listen on a different UDS), symlink "could" work (this need to be checked). BTW a bit more simple for PHP which doesn't need any wrapper ;) (a simple symlink to the SCL binary is enough) Just few other comments which may help (a bit out-of-topic with your proposal, but related to SCL usability) - have you tried the service alias ? (exists in both SysV and systemd) - moving man page to base system As it could be consider a bit strange to have to enable the collection to read the documentation explaining how to enable it... - providing the module configuration file Because "scl enable" is not the best user friendly command, and may raise PATH overflow when used a lot, "module load" seems better (at least to me) This is default with scl-utils v2, but works perfectly with scl-utils v1, just dropping the file in the right place (/usr/share/Modules/modulefiles/) Remi. From wesley.griffin at nist.gov Wed Mar 22 14:48:35 2017 From: wesley.griffin at nist.gov (Griffin, Wesley (Fed)) Date: Wed, 22 Mar 2017 14:48:35 +0000 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: <9e6e2808-e291-dce1-129a-de0508885df2@redhat.com> References: , <9e6e2808-e291-dce1-129a-de0508885df2@redhat.com> Message-ID: My use case is for newer compilers and interpreters on development workstations. I do not, however, manage my systems - our system administrator does that, so I work with him to get the SCL packages installed where necessary. I am pretty confident that if I wanted to install an SCL package and it wrapped the system binary in some way he would refuse. He supports many more machines than just my development group and tries to maintain the same set of packages across all machines. The beauty of SCL is that he can install it everywhere, but not affect anybody that doesn't opt-in. We have a similar setup for Intel compilers, Matlab, and other scientific software used in our organization. So in that sense, adapting to a new approach would be troublesome, but only if it was the only approach. As long as the system binary wrappers are in subpackages which are optional, then I see no issues for us to continue using future SCL packages. Thanks, Wes ________________________________________ From: Honza Horak Sent: Wednesday, March 22, 2017 3:41:54 AM To: Griffin, Wesley (Fed); sclorg at redhat.com Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide I don't expect we'll do this for existing packages we provide, it's more a vision for new collections (e.g. mariadb 10.2 at some point). Anyway, do you also see the same point for those upcoming collections (where we're not tight by keeping backward compatibility), e.g. because you're fine with all the SCL specifics and adapting to the new way would be troublesome? Honza On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote: > I will chime in as the "old curmudgeon" - as long as you don't break the existing use case, then I'm fine with any changes. The blog post says subpackages will be used to ensure no breakage - I just want to re-iterate that this is important and should not get lost if the proposal changes. > > Thanks, > Wes > > ________________________________________ > From: sclorg-bounces at redhat.com on behalf of Honza Horak > Sent: Tuesday, March 21, 2017 11:05:26 AM > To: sclorg at redhat.com > Subject: [scl.org] Idea: Software Collections Daemons Made System-wide > > This is basically a kick-off for getting more feedback for an idea > shared at > http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. > > Shortly, SCL has worked nicely for several years and people love them. > But even the beloved ones have some issues. And what we hear from users, > the issues with Software Collections concept currently are basically those: > > * we need to use scl enable, which changes $PATH and other environment > variables, so the binaries placed in different location are visible by > the system > * scripts originally written for "normal" MySQL use full paths (like > /usr/bin/mysql) which does not work when we only have the Software > Collection installed > * Data directory, config files and log files are on different location > than it is common > > The blog post tries to summarize possible solution, which I'm looking > for feedback now, ideally by replying to this mail.. > > TIA, > Honza > > _______________________________________________ > 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 daniel.davis at nih.gov Wed Mar 22 14:50:00 2017 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Wed, 22 Mar 2017 14:50:00 +0000 Subject: [scl.org] Feedback on /usr/bin symlinks for python Message-ID: For the python SCLs, I would potentially love this, but one would need to be careful to version the wrappers/symlinks, and/or worry about rpaths and ld config. To be more specific - one problem I've had is running a testing tool called "tox" - the idea is that "tox" runs your python code with multiple versions of Python, and/or possibly multiple versions of Python packages (i.e. Django 1.7, 1.8, etc.). Many tox configurations are setup to look for a python executable called python3.4 and/or python2.7 and/or python3. So the wrapper rpms might want to provide these as scripts that enable the SCL within them and then invoke the language. As an example (and a test case), here's one upstream package I've contributed to - https://github.com/mingchen/django-cas-ng. Here is its tox configuration file - https://github.com/mingchen/django-cas-ng/blob/master/tox.ini An excerpt shows how it is expecting to find the python version in the test matrix: [testenv:py27-django19] basepython=python2.7 deps = Django>=1.9,<1.10 {[base]deps} [testenv:py34-django15] basepython=python3.4 deps = Django>=1.5,<1.6 {[base]deps} [testenv:py34-django16] basepython=python3.4 deps = Django>=1.6,<1.7 {[base]deps} Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications Systems, National Library of Medicine, NIH -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.davis at nih.gov Wed Mar 22 14:51:07 2017 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Wed, 22 Mar 2017 14:51:07 +0000 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: , <9e6e2808-e291-dce1-129a-de0508885df2@redhat.com> Message-ID: Amen to this. I shipped an appliance install base on Pungi/Anaconda, but in my current role, I do not have root. I found SCL and got what we needed without us having to build it ourself. -----Original Message----- From: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] On Behalf Of Griffin, Wesley (Fed) Sent: Wednesday, March 22, 2017 10:49 AM To: Honza Horak ; sclorg at redhat.com Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide My use case is for newer compilers and interpreters on development workstations. I do not, however, manage my systems - our system administrator does that, so I work with him to get the SCL packages installed where necessary. I am pretty confident that if I wanted to install an SCL package and it wrapped the system binary in some way he would refuse. He supports many more machines than just my development group and tries to maintain the same set of packages across all machines. The beauty of SCL is that he can install it everywhere, but not affect anybody that doesn't opt-in. We have a similar setup for Intel compilers, Matlab, and other scientific software used in our organization. So in that sense, adapting to a new approach would be troublesome, but only if it was the only approach. As long as the system binary wrappers are in subpackages which are optional, then I see no issues for us to continue using future SCL packages. Thanks, Wes ________________________________________ From: Honza Horak Sent: Wednesday, March 22, 2017 3:41:54 AM To: Griffin, Wesley (Fed); sclorg at redhat.com Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide I don't expect we'll do this for existing packages we provide, it's more a vision for new collections (e.g. mariadb 10.2 at some point). Anyway, do you also see the same point for those upcoming collections (where we're not tight by keeping backward compatibility), e.g. because you're fine with all the SCL specifics and adapting to the new way would be troublesome? Honza On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote: > I will chime in as the "old curmudgeon" - as long as you don't break the existing use case, then I'm fine with any changes. The blog post says subpackages will be used to ensure no breakage - I just want to re-iterate that this is important and should not get lost if the proposal changes. > > Thanks, > Wes > > ________________________________________ > From: sclorg-bounces at redhat.com on behalf > of Honza Horak > Sent: Tuesday, March 21, 2017 11:05:26 AM > To: sclorg at redhat.com > Subject: [scl.org] Idea: Software Collections Daemons Made System-wide > > This is basically a kick-off for getting more feedback for an idea > shared at > http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. > > Shortly, SCL has worked nicely for several years and people love them. > But even the beloved ones have some issues. And what we hear from > users, the issues with Software Collections concept currently are basically those: > > * we need to use scl enable, which changes $PATH and other environment > variables, so the binaries placed in different location are visible by > the system > * scripts originally written for "normal" MySQL use full paths (like > /usr/bin/mysql) which does not work when we only have the Software > Collection installed > * Data directory, config files and log files are on different location > than it is common > > The blog post tries to summarize possible solution, which I'm looking > for feedback now, ideally by replying to this mail.. > > TIA, > Honza > > _______________________________________________ > 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 > > _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg From hhorak at redhat.com Wed Mar 22 16:34:17 2017 From: hhorak at redhat.com (Honza Horak) Date: Wed, 22 Mar 2017 17:34:17 +0100 Subject: [scl.org] Idea: Software Collections Daemons Made System-wide In-Reply-To: References: <9e6e2808-e291-dce1-129a-de0508885df2@redhat.com> Message-ID: <59428e11-7b73-6135-ed20-a12736b8d5d7@redhat.com> Thanks for your input, guys, really appreciated. Honza On 03/22/2017 03:51 PM, Davis, Daniel (NIH/NLM) [C] wrote: > Amen to this. I shipped an appliance install base on Pungi/Anaconda, but in my current role, I do not have root. > I found SCL and got what we needed without us having to build it ourself. > > -----Original Message----- > From: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] On Behalf Of Griffin, Wesley (Fed) > Sent: Wednesday, March 22, 2017 10:49 AM > To: Honza Horak ; sclorg at redhat.com > Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide > > My use case is for newer compilers and interpreters on development workstations. > > I do not, however, manage my systems - our system administrator does that, so I work with him to get the SCL packages installed where necessary. > > I am pretty confident that if I wanted to install an SCL package and it wrapped the system binary in some way he would refuse. He supports many more machines than just my development group and tries to maintain the same set of packages across all machines. > > The beauty of SCL is that he can install it everywhere, but not affect anybody that doesn't opt-in. We have a similar setup for Intel compilers, Matlab, and other scientific software used in our organization. > > So in that sense, adapting to a new approach would be troublesome, but only if it was the only approach. As long as the system binary wrappers are in subpackages which are optional, then I see no issues for us to continue using future SCL packages. > > Thanks, > Wes > > ________________________________________ > From: Honza Horak > Sent: Wednesday, March 22, 2017 3:41:54 AM > To: Griffin, Wesley (Fed); sclorg at redhat.com > Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide > > I don't expect we'll do this for existing packages we provide, it's more a vision for new collections (e.g. mariadb 10.2 at some point). > > Anyway, do you also see the same point for those upcoming collections (where we're not tight by keeping backward compatibility), e.g. because you're fine with all the SCL specifics and adapting to the new way would be troublesome? > > Honza > > > On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote: >> I will chime in as the "old curmudgeon" - as long as you don't break the existing use case, then I'm fine with any changes. The blog post says subpackages will be used to ensure no breakage - I just want to re-iterate that this is important and should not get lost if the proposal changes. >> >> Thanks, >> Wes >> >> ________________________________________ >> From: sclorg-bounces at redhat.com on behalf >> of Honza Horak >> Sent: Tuesday, March 21, 2017 11:05:26 AM >> To: sclorg at redhat.com >> Subject: [scl.org] Idea: Software Collections Daemons Made System-wide >> >> This is basically a kick-off for getting more feedback for an idea >> shared at >> http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html. >> >> Shortly, SCL has worked nicely for several years and people love them. >> But even the beloved ones have some issues. And what we hear from >> users, the issues with Software Collections concept currently are basically those: >> >> * we need to use scl enable, which changes $PATH and other environment >> variables, so the binaries placed in different location are visible by >> the system >> * scripts originally written for "normal" MySQL use full paths (like >> /usr/bin/mysql) which does not work when we only have the Software >> Collection installed >> * Data directory, config files and log files are on different location >> than it is common >> >> The blog post tries to summarize possible solution, which I'm looking >> for feedback now, ideally by replying to this mail.. >> >> TIA, >> Honza >> >> _______________________________________________ >> 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 >> >> > > _______________________________________________ > 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 ncoghlan at redhat.com Thu Mar 23 07:04:49 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Thu, 23 Mar 2017 17:04:49 +1000 Subject: [scl.org] Feedback on /usr/bin symlinks for python In-Reply-To: References: Message-ID: On Thu, Mar 23, 2017 at 12:50 AM, Davis, Daniel (NIH/NLM) [C] wrote: > For the python SCLs, I would potentially love this, but one would need to be > careful to version the wrappers/symlinks, and/or worry about rpaths and ld > config. Aye, Python's going to have to be a special case as it isn't possible to uninstall the base "python" package in current versions of RHEL & CentOS. However, it should be possible to get system-wide Python SCLs to work similarly to the pythonXY packages in Fedora and EPEL, where they only provide the "/usr/bin/pythonX.Y" links, and not the more generic "python" or "pythonX" links. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From thjones2 at gmail.com Thu Mar 23 11:19:49 2017 From: thjones2 at gmail.com (Thomas Jones) Date: Thu, 23 Mar 2017 07:19:49 -0400 Subject: [scl.org] Asking questions via StackOverflow Message-ID: The FAQ page says to ask questions on StackOverflow and use the "software-collections" tag. This tag is not currently available on StackOverflow and my points-count is too low to create it, myself. Any chance this lack of tac can be rectified by someone on the SCL team? At any rate, the question I was attempting to post to StackOverflow was: *Our security folks prefer that we enable GPG-checking for all RPMs to be installed. We've recently started using packages from the CentOS.Org packaging of Software Collections. When I try to install these, yum helpfully yells at me about not having verifiable keys. When I look at the CentOS.Org site's page concerning GPG keys, the SCL packages are shown as having a key/fingerprint, but, unlike the other keys listed on that page, there's no download link.* *Is the GPG verification key simply not available or am I simply missing something blindingly obvious. At any rate, any help in tracking down a checking-key that I can install to my systems would be of great assistance.* So, in short, is my goal achievable. If so, where do I find the verification keys and not just the key's printout? -- You can only be -so- accurate with a claw-hammer. --me -------------- next part -------------- An HTML attachment was scrubbed... URL: From meson at posteo.de Sat Mar 25 14:50:23 2017 From: meson at posteo.de (meson) Date: Sat, 25 Mar 2017 15:50:23 +0100 Subject: [scl.org] Python 3.6 availability Message-ID: <69bb8b75b19f849c61d7bcf225edd22e@posteo.net> Hi, is there any estimate on when Python 3.6 will be available as SCL? Our devs are asking about it. If it's going to take a long time, I'll try my hand at building the packages myself. A general question: is the SCL development open? I did not find any public git repositories apart from the CentOS source server. I'd love to contribute. Kind Regards meson From Fedora at FamilleCollet.com Wed Mar 29 06:46:06 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 29 Mar 2017 08:46:06 +0200 Subject: [scl.org] Python 3.6 availability In-Reply-To: <69bb8b75b19f849c61d7bcf225edd22e@posteo.net> References: <69bb8b75b19f849c61d7bcf225edd22e@posteo.net> Message-ID: Le 25/03/2017 ? 15:50, meson a ?crit : > Hi, > > is there any estimate on when Python 3.6 will be available as SCL? Can't say. > Our devs are asking about it. If it's going to take a long time, I'll > try my hand at building the packages myself. > > A general question: is the SCL development open? I did not find any > public git repositories apart from the CentOS source server. I'd love to > contribute. rh-* packages are maintained upstream by Red Hat, the SIG only takes care of the rebuild in CentOS. sclo-* packages are maintained by the community (the SCLo SIG) See: https://github.com/sclorg-distgit Remi From ncoghlan at redhat.com Fri Mar 31 08:30:44 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Fri, 31 Mar 2017 18:30:44 +1000 Subject: [scl.org] Python 3.6 availability In-Reply-To: <69bb8b75b19f849c61d7bcf225edd22e@posteo.net> References: <69bb8b75b19f849c61d7bcf225edd22e@posteo.net> Message-ID: On Sun, Mar 26, 2017 at 12:50 AM, meson wrote: > Hi, > > is there any estimate on when Python 3.6 will be available as SCL? > > Our devs are asking about it. If it's going to take a long time, I'll try my > hand at building the packages myself. It likely makes sense to have some community maintained sclo-* Python packages regardless, as the rh-* ones are officially Red Hat maintained, and hence: - are published in line with Red Hat's product schedules rather than necessarily being ASAP after the upstream release - have RHEL-style rules against rebasing components within the collection (so some updates have to wait for the next revision of the entire collection) - are restricted to components that Red Hat is currently willing to commercially support with security backports By contrast, community packages could adopt more permissive policies around package inclusion and rebasing, without having to take Red Hat's commercial support obligations into account the way the official SCLs do. > A general question: is the SCL development open? I did not find any public > git repositories apart from the CentOS source server. I'd love to > contribute. Remi, do you have access to edit the CentOS wiki? It would be good to provide a pointer to https://github.com/sclorg-distgit from https://wiki.centos.org/SpecialInterestGroup/SCLo and you have a much better understanding than I do of how the existing sclo-* SCLs are maintained. Cheers, Nick. P.S. Perhaps it would be worth adding an "sclo-admin" repo to the sclo-distgit org, and pinning it? Then the README for that could be used as a second entry point for info about the SCLo sig, and it could also provide an issue tracker for the SIG itself, rather than relying solely on the mailing list and the RHSCL component in Red Hat's bugzilla instance (which only covers the official SCLs anyway). -- Nick Coghlan Red Hat Platform Engineering, Brisbane From Fedora at FamilleCollet.com Fri Mar 31 09:02:29 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 31 Mar 2017 11:02:29 +0200 Subject: [scl.org] Python 3.6 availability In-Reply-To: References: <69bb8b75b19f849c61d7bcf225edd22e@posteo.net> Message-ID: Le 31/03/2017 ? 10:30, Nick Coghlan a ?crit : > Remi, do you have access to edit the CentOS wiki? It would be good to > provide a pointer to https://github.com/sclorg-distgit from > https://wiki.centos.org/SpecialInterestGroup/SCLo Please, review if this change seems clear enough : https://wiki.centos.org/SpecialInterestGroup/SCLo#head-429ebba9d9c8bcd7e55c1ae23c7ba652901a629c Remi