From trepik at redhat.com Wed Jun 14 06:44:55 2017 From: trepik at redhat.com (Tomas Repik) Date: Wed, 14 Jun 2017 02:44:55 -0400 (EDT) Subject: [scl.org] New SCLo collection: cassandra3 ? In-Reply-To: <2144984866.20664287.1497421307656.JavaMail.zimbra@redhat.com> Message-ID: <1619845464.20668941.1497422695350.JavaMail.zimbra@redhat.com> Good news everyone! Past year or so I've been working on packaging Appache Cassandra as a rpm for Fedora. Simultaneously I SCLized the package and all the dependencies needed for building and running. Our ultimate goal is shipping Cassandra in RHSC, but before that I'd like to get some feedback from developers and users, so that the collection is more ready to use. Therefore I would like to propose to introduce sclo-cassandra3 collection for CentOS 7 (maybe 6 as well) Cassandra is a partitioned row store. Rows are organized into tables with a required primary key. Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically re-partition as machines are added/removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL. Links to the fedora package [1], fedora container [2], git repository of the SCLized package [3] and metapackage [4] can be found down bellow. What do you think ? Tomas [1] https://admin.fedoraproject.org/pkgdb/package/rpms/cassandra/ [2] https://admin.fedoraproject.org/pkgdb/package/container/cassandra/ [3] https://github.com/devexp-db/sclo-cassandra3-cassandra [4] https://github.com/devexp-db/sclo-cassandra3 From Fedora at FamilleCollet.com Fri Jun 16 06:32:24 2017 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 16 Jun 2017 08:32:24 +0200 Subject: [scl.org] [SCLo SIG] new sclo-php*-php-pecl-amqp packages available for testing Message-ID: <5edc272a-a96e-342f-c7eb-bd52a1bab039@FamilleCollet.com> Yet another package available in centos-sclo-sclo-testing (requested by some users) This extension can communicate with any AMQP spec 0-9-1 compatible server, such as RabbitMQ, OpenAMQP and Qpid, giving you the ability to create and delete exchanges and queues, as well as publish to any exchange and consume from any queue. https://pecl.php.net/package/amqp For rh-php56 * sclo-php56-php-amqp-1.9.1-1 For rh-php70 * sclo-php70-php-amqp-1.9.1-1 Notice: this package doesn't requires "librabbitmq" which is not available in base repository (only in EPEL), but use a static library instead. Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo From hhorak at redhat.com Fri Jun 16 12:58:07 2017 From: hhorak at redhat.com (Honza Horak) Date: Fri, 16 Jun 2017 14:58:07 +0200 Subject: [scl.org] New SCLo collection: cassandra3 ? In-Reply-To: <1619845464.20668941.1497422695350.JavaMail.zimbra@redhat.com> References: <1619845464.20668941.1497422695350.JavaMail.zimbra@redhat.com> Message-ID: <3f7501a0-0a50-01f3-fd9d-9dc7066e5e37@redhat.com> I definitely agree and the suggested name sclo-cassandra3 looks very good to me. Let's wait couple of days for other ideas, but if there are no objections we can ask for tags later next week.. Honza On 06/14/2017 08:44 AM, Tomas Repik wrote: > Good news everyone! > > Past year or so I've been working on packaging Appache > Cassandra as a rpm for Fedora. Simultaneously I SCLized > the package and all the dependencies needed for building > and running. Our ultimate goal is shipping Cassandra > in RHSC, but before that I'd like to get some feedback > from developers and users, so that the collection is > more ready to use. > > Therefore I would like to propose to introduce > > sclo-cassandra3 collection for CentOS 7 (maybe 6 as well) > > Cassandra is a partitioned row store. Rows are organized into tables with > a required primary key. Partitioning means that Cassandra can distribute your > data across multiple machines in an application-transparent matter. Cassandra > will automatically re-partition as machines are added/removed from the cluster. > Row store means that like relational databases, Cassandra organizes data by > rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL. > > Links to the fedora package [1], fedora container [2], git repository of the > SCLized package [3] and metapackage [4] can be found down bellow. > > What do you think ? > > Tomas > > [1] https://admin.fedoraproject.org/pkgdb/package/rpms/cassandra/ > [2] https://admin.fedoraproject.org/pkgdb/package/container/cassandra/ > [3] https://github.com/devexp-db/sclo-cassandra3-cassandra > [4] https://github.com/devexp-db/sclo-cassandra3 > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From ncoghlan at redhat.com Mon Jun 19 07:47:52 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Mon, 19 Jun 2017 17:47:52 +1000 Subject: [scl.org] Python3 (always latest) community SCL In-Reply-To: References: Message-ID: On Wed, May 10, 2017 at 3:37 PM, Nick Coghlan wrote: > To provide an indicative timeline for this: I'm currently trying to > get PEP 538's locale coercion squared away for Python 3.7 before > Fedora 26 hits code freeze, and then will be busy with proposal > reviews for the PyCon Australia Education Seminar for the next couple > of weeks. > > So that will mean I'll start figuring out the details of setting up > this rolling community SCL some time in late May or early June. > A (lack of) progress update here: while PEP 538 has landed, I had to partially revert it to get the FreeBSD buildbots passing again, and that partial reversion also had the side effect of disabling it on Mac OS X. I'd like to get all that sorted out before starting any other new upstream commitments, and PyCon Australia itself is now looming not too far in the future :) So if anyone else is keen to see the Python 3 SCL rolling release idea happen, *please* don't feel obliged to wait for me to find the time to drive it - I'll be happy to help out regardless. However, if we do leave it to me, then I'll hopefully be able to get PEP 538 finalised some time in the next couple of weeks, while would mean putting together an initial collection some time in July. If I miss that date, then it's likely to slip all the way into September or October due to my other commitments in August. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjtuhjh at hotmail.com Fri Jun 16 02:49:13 2017 From: sjtuhjh at hotmail.com (Huang Jinhua) Date: Fri, 16 Jun 2017 02:49:13 +0000 Subject: [scl.org] SoftwareCollections Port Message-ID: <8c476d683816478fb73d4deb2ebc3770SG2PR01MB13445359108F637E3F95989ABDC10@SG2PR01MB1344.apcprd01.prod.exchangelabs.com> Hi, Software Collections Tool is one greate tool. Do you know how to port this tool to other platforms such as Debian or Ubuntu? Thanks Jinhua -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Tue Jun 27 13:57:26 2017 From: hhorak at redhat.com (Honza Horak) Date: Tue, 27 Jun 2017 15:57:26 +0200 Subject: [scl.org] New SCLo collection: cassandra3 ? In-Reply-To: <3f7501a0-0a50-01f3-fd9d-9dc7066e5e37@redhat.com> References: <1619845464.20668941.1497422695350.JavaMail.zimbra@redhat.com> <3f7501a0-0a50-01f3-fd9d-9dc7066e5e37@redhat.com> Message-ID: Since nobody raised any push backs couple of days here, nor during today's meeting, let' call this approved. I'll request the tags soon. This SCL will depend on rh-maven33 and rh-java-common? Honza On 06/16/2017 02:58 PM, Honza Horak wrote: > I definitely agree and the suggested name sclo-cassandra3 looks very > good to me. Let's wait couple of days for other ideas, but if there are > no objections we can ask for tags later next week.. > > Honza > > On 06/14/2017 08:44 AM, Tomas Repik wrote: >> Good news everyone! >> >> Past year or so I've been working on packaging Appache >> Cassandra as a rpm for Fedora. Simultaneously I SCLized >> the package and all the dependencies needed for building >> and running. Our ultimate goal is shipping Cassandra >> in RHSC, but before that I'd like to get some feedback >> from developers and users, so that the collection is >> more ready to use. >> >> Therefore I would like to propose to introduce >> >> sclo-cassandra3 collection for CentOS 7 (maybe 6 as well) >> >> Cassandra is a partitioned row store. Rows are organized into tables with >> a required primary key. Partitioning means that Cassandra can >> distribute your >> data across multiple machines in an application-transparent matter. >> Cassandra >> will automatically re-partition as machines are added/removed from the >> cluster. >> Row store means that like relational databases, Cassandra organizes >> data by >> rows and columns. The Cassandra Query Language (CQL) is a close >> relative of SQL. >> >> Links to the fedora package [1], fedora container [2], git repository >> of the >> SCLized package [3] and metapackage [4] can be found down bellow. >> >> What do you think ? >> >> Tomas >> >> [1] https://admin.fedoraproject.org/pkgdb/package/rpms/cassandra/ >> [2] https://admin.fedoraproject.org/pkgdb/package/container/cassandra/ >> [3] https://github.com/devexp-db/sclo-cassandra3-cassandra >> [4] https://github.com/devexp-db/sclo-cassandra3 >> >> _______________________________________________ >> 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 Jun 28 23:20:59 2017 From: hhorak at redhat.com (Honza Horak) Date: Thu, 29 Jun 2017 01:20:59 +0200 Subject: [scl.org] SoftwareCollections Port In-Reply-To: <8c476d683816478fb73d4deb2ebc3770SG2PR01MB13445359108F637E3F95989ABDC10@SG2PR01MB1344.apcprd01.prod.exchangelabs.com> References: <8c476d683816478fb73d4deb2ebc3770SG2PR01MB13445359108F637E3F95989ABDC10@SG2PR01MB1344.apcprd01.prod.exchangelabs.com> Message-ID: <483c4b81-1551-e41e-dbff-7341f987fbbb@redhat.com> SCL concept requires two basic things: * change location where the files are installed by changing default RPM macros (I expect something like that exists in the .deb packages as well) * change the environment variables like PATH, etc. so the binaries and libraries are found on the alternative path. This part should be same in Debian as on RHEL. Anyway, this would be cool, although I'm not sure home much work it would require to accomplish it. My guess is that it won't be just a weekend project. Honza On 06/16/2017 04:49 AM, Huang Jinhua wrote: > Hi, > > > Software Collections Tool is one greate tool. Do you know how to port > this tool to other platforms such as Debian or Ubuntu? > > > > Thanks > > Jinhua > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From ncoghlan at redhat.com Thu Jun 29 06:08:32 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Thu, 29 Jun 2017 16:08:32 +1000 Subject: [scl.org] SoftwareCollections Port In-Reply-To: <483c4b81-1551-e41e-dbff-7341f987fbbb@redhat.com> References: <8c476d683816478fb73d4deb2ebc3770SG2PR01MB13445359108F637E3F95989ABDC10@SG2PR01MB1344.apcprd01.prod.exchangelabs.com> <483c4b81-1551-e41e-dbff-7341f987fbbb@redhat.com> Message-ID: On Thu, Jun 29, 2017 at 9:20 AM, Honza Horak wrote: > SCL concept requires two basic things: > > * change location where the files are installed by changing default RPM > macros (I expect something like that exists in the .deb packages as well) A point worth noting about the way this works is that the RPM spec file itself needs to be updated to be "SCL aware", and use the SCL macros in the right places: https://www.softwarecollections.org/en/docs/guide/#sect-Converting_a_Conventional_Spec_File So SCLs for Debian would presumably need to do something comparable in the Debian control file, and thus end up with a similar distinction between "conventional packages" and "SCL enabled packages". > * change the environment variables like PATH, etc. so the binaries and > libraries are found on the alternative path. This part should be same in > Debian as on RHEL. A variant potentially worth exploring on the runtime side of things would be following through on the current environment modules generation and seeing if that could be made the default way of working on Debian (et al): https://www.softwarecollections.org/en/docs/guide/#sect-Converting_Software_Collection_Scriptlets_into_Environment_Modules That way, the main aspect that SCLs would be contributing would be the "/opt//" (filesystem) and "-"(package name) conventions for parallel installation support, with the existing "module" command handling the activation process. So yeah, as far as I'm aware, SCLs for non-RPM systems should definitely be technical feasible, but it wouldn't be trivial either. Cheers, Nick. P.S. While we're not aware of any way to avoid per-package changes if you actually want to support parallel *installation* of packages, I figure it's worth mentioning that the Fedora Modularity project is currently looking at less intrusive ways of supporting parallel *availability* of different package streams that don't require updates to each individual package: https://docs.pagure.org/modularity/ As a trade-off though, going down that path is requiring changes to the package management system in Fedora itself, so it isn't readily usable atop existing systems the way SCLs are. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From acaringi at redhat.com Thu Jun 29 14:56:22 2017 From: acaringi at redhat.com (Augusto Caringi) Date: Thu, 29 Jun 2017 10:56:22 -0400 (EDT) Subject: [scl.org] Self-introduction In-Reply-To: <1187066634.44656114.1498747480073.JavaMail.zimbra@redhat.com> Message-ID: <1765405511.44657951.1498748182929.JavaMail.zimbra@redhat.com> Hi everyone, My name is Augusto Caringi, I'm a Software Engineer working at Red Hat in the Core Services/Databases team and I would like to become member of sclo-sig to help with packaging of Apache Cassandra. Best regards, -- Augusto Caringi From daniel.davis at nih.gov Thu Jun 29 15:24:56 2017 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Thu, 29 Jun 2017 15:24:56 +0000 Subject: [scl.org] Python "latest" SCLo Message-ID: I've been lurking on this list for a while, and I wanted to bring myself up to date. I noticed some talk of a community SCL for a "latest" Python, which would be a non-patched pure build of Python that is kept up-to-date by the community. Where is that at? Who is leading it? How can I help? For background, we've used rh-python34 for some time, but our security team recently dinged us for sticking with Python 3.4.2, and my DevOps team (who have less time due to tickets), just recompiled Python 3.4.6 blind to get past the security problem. I would have argued we should move to rh-python35, but that would eventually suffer the same problem. What we need is a distribution that keeps up to date, but is still distributed as an rpm. Thanks, 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 bgollahe at redhat.com Thu Jun 29 15:49:38 2017 From: bgollahe at redhat.com (Brian Gollaher) Date: Thu, 29 Jun 2017 11:49:38 -0400 Subject: [scl.org] Python "latest" SCLo In-Reply-To: References: Message-ID: <69d3a82d-f797-2c84-f306-2a158666d40f@redhat.com> Hi Dan. May I ask a question? Is your security team looking for a fix to a specific security problem or CVE or are they asking that you run the latest version as a rule? thanks, Brian On 06/29/2017 11:24 AM, Davis, Daniel (NIH/NLM) [C] wrote: > > I?ve been lurking on this list for a while, and I wanted to bring > myself up to date. I noticed some talk of a community SCL for a > ?latest? Python, which would be a non-patched pure build of Python > that is kept up-to-date by the community. Where is that at? Who is > leading it? How can I help? > > For background, we?ve used rh-python34 for some time, but our security > team recently dinged us for sticking with Python 3.4.2, and my DevOps > team (who have less time due to tickets), just recompiled Python 3.4.6 > blind to get past the security problem. I would have argued we > should move to rh-python35, but that would eventually suffer the same > problem. What we need is a distribution that keeps up to date, but > is still distributed as an rpm. > > Thanks, > > Dan Davis, Systems/Applications Architect (Contractor), > > Office of Computer and Communications Systems, > > National Library of Medicine, NIH > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.davis at nih.gov Thu Jun 29 15:54:01 2017 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Thu, 29 Jun 2017 15:54:01 +0000 Subject: [scl.org] Python "latest" SCLo In-Reply-To: <69d3a82d-f797-2c84-f306-2a158666d40f@redhat.com> References: <69d3a82d-f797-2c84-f306-2a158666d40f@redhat.com> Message-ID: The DevOps team wants to update to the latest Python as a rule as a security from security mitigation technique. I hope that makes sense. From: Brian Gollaher [mailto:bgollahe at redhat.com] Sent: Thursday, June 29, 2017 11:50 AM To: Davis, Daniel (NIH/NLM) [C] ; sclorg at redhat.com Subject: Re: [scl.org] Python "latest" SCLo Hi Dan. May I ask a question? Is your security team looking for a fix to a specific security problem or CVE or are they asking that you run the latest version as a rule? thanks, Brian On 06/29/2017 11:24 AM, Davis, Daniel (NIH/NLM) [C] wrote: I've been lurking on this list for a while, and I wanted to bring myself up to date. I noticed some talk of a community SCL for a "latest" Python, which would be a non-patched pure build of Python that is kept up-to-date by the community. Where is that at? Who is leading it? How can I help? For background, we've used rh-python34 for some time, but our security team recently dinged us for sticking with Python 3.4.2, and my DevOps team (who have less time due to tickets), just recompiled Python 3.4.6 blind to get past the security problem. I would have argued we should move to rh-python35, but that would eventually suffer the same problem. What we need is a distribution that keeps up to date, but is still distributed as an rpm. Thanks, Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications Systems, National Library of Medicine, NIH _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgollahe at redhat.com Thu Jun 29 16:51:30 2017 From: bgollahe at redhat.com (Brian Gollaher) Date: Thu, 29 Jun 2017 12:51:30 -0400 Subject: [scl.org] Python "latest" SCLo In-Reply-To: References: <69d3a82d-f797-2c84-f306-2a158666d40f@redhat.com> Message-ID: <864cf556-67af-b5a2-b3ea-fd29f5bb5b2b@redhat.com> Yes, thanks Dan. Many security scanning tools look for the latest version and flag older versions as being a potential risk. I wanted to be sure that this is what is happening, rather than collections not receiving security updates fast enough and actually missing an important CVE. On 06/29/2017 11:54 AM, Davis, Daniel (NIH/NLM) [C] wrote: > > The DevOps team wants to update to the latest Python as a rule as a > security from security mitigation technique. I hope that makes sense. > > *From:*Brian Gollaher [mailto:bgollahe at redhat.com] > *Sent:* Thursday, June 29, 2017 11:50 AM > *To:* Davis, Daniel (NIH/NLM) [C] ; > sclorg at redhat.com > *Subject:* Re: [scl.org] Python "latest" SCLo > > Hi Dan. May I ask a question? Is your security team looking for a > fix to a specific security problem or CVE or are they asking that you > run the latest version as a rule? > > thanks, > Brian > > On 06/29/2017 11:24 AM, Davis, Daniel (NIH/NLM) [C] wrote: > > I?ve been lurking on this list for a while, and I wanted to bring > myself up to date. I noticed some talk of a community SCL for a > ?latest? Python, which would be a non-patched pure build of Python > that is kept up-to-date by the community. Where is that at? > Who is leading it? How can I help? > > For background, we?ve used rh-python34 for some time, but our > security team recently dinged us for sticking with Python 3.4.2, > and my DevOps team (who have less time due to tickets), just > recompiled Python 3.4.6 blind to get past the security problem. > I would have argued we should move to rh-python35, but that would > eventually suffer the same problem. What we need is a > distribution that keeps up to date, but is still distributed as an > rpm. > > Thanks, > > Dan Davis, Systems/Applications Architect (Contractor), > > Office of Computer and Communications Systems, > > National Library of Medicine, NIH > > > > > _______________________________________________ > > SCLorg mailing list > > SCLorg at redhat.com > > https://www.redhat.com/mailman/listinfo/sclorg > > > > -- > Brian Gollaher > Red Hat Platform Product Management > Phone: 978 392-3173 > Cell: 508 740-6549 > briang at redhat.com -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.davis at nih.gov Thu Jun 29 17:07:37 2017 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Thu, 29 Jun 2017 17:07:37 +0000 Subject: [scl.org] Python "latest" SCLo In-Reply-To: <864cf556-67af-b5a2-b3ea-fd29f5bb5b2b@redhat.com> References: <69d3a82d-f797-2c84-f306-2a158666d40f@redhat.com> <864cf556-67af-b5a2-b3ea-fd29f5bb5b2b@redhat.com> Message-ID: So, maybe I've missed something, but is this more complicated than running rpmbuild with different Macros? I'm pretty good with rpms, but I know I don't always follow Fedora Packaging Guidelines. I know that our DevOps guys will not want to submit builds to Copr, etc., and may not even use a local chroot to assure than BuildRequires is right. However, if most of the time, they can download a tarball for Python, download the SRPM for rh-python34 or rh-python34, and then run rpmbuild with different options, they would probably be OK, and I could break the back of that work so that they have some wikis and local knowledge to go from. This is how I complied with security guidelines when I did a lot of rpm building, but generally it was slightly simpler packages than Python. For instance, with Apache httpd, our customers network scanner would say, you are still running httpd X.Y.Z, and so I would pull the SRPM for httpd from Fedora 16 (going back a ways), take a look at the required libraries and versions on Fedora 16, and compare with CentOS 6, then I would copy the tarball and adjust version macros for our own custom version of httpd, make sure to include Conflicts with the system package, and so on. So, I understand that SCLs aren't the only way to have other versions, but SCLs prevent conflicts. It gives RedHat customers a step between tarball and rpm that may conflict. That's what I'm looking for. However, https://www.softwarecollections.org/en/docs/guide/#Creating_Your_Own_Software_Collections is somewhat imposing, even for me. For our DevOps team, who normally deal with a little bash, a little ansible, and a lot of Jenkins, this is very imposing. From: Brian Gollaher [mailto:bgollahe at redhat.com] Sent: Thursday, June 29, 2017 12:52 PM To: Davis, Daniel (NIH/NLM) [C] ; sclorg at redhat.com Subject: Re: [scl.org] Python "latest" SCLo Yes, thanks Dan. Many security scanning tools look for the latest version and flag older versions as being a potential risk. I wanted to be sure that this is what is happening, rather than collections not receiving security updates fast enough and actually missing an important CVE. On 06/29/2017 11:54 AM, Davis, Daniel (NIH/NLM) [C] wrote: The DevOps team wants to update to the latest Python as a rule as a security from security mitigation technique. I hope that makes sense. From: Brian Gollaher [mailto:bgollahe at redhat.com] Sent: Thursday, June 29, 2017 11:50 AM To: Davis, Daniel (NIH/NLM) [C] ; sclorg at redhat.com Subject: Re: [scl.org] Python "latest" SCLo Hi Dan. May I ask a question? Is your security team looking for a fix to a specific security problem or CVE or are they asking that you run the latest version as a rule? thanks, Brian On 06/29/2017 11:24 AM, Davis, Daniel (NIH/NLM) [C] wrote: I've been lurking on this list for a while, and I wanted to bring myself up to date. I noticed some talk of a community SCL for a "latest" Python, which would be a non-patched pure build of Python that is kept up-to-date by the community. Where is that at? Who is leading it? How can I help? For background, we've used rh-python34 for some time, but our security team recently dinged us for sticking with Python 3.4.2, and my DevOps team (who have less time due to tickets), just recompiled Python 3.4.6 blind to get past the security problem. I would have argued we should move to rh-python35, but that would eventually suffer the same problem. What we need is a distribution that keeps up to date, but is still distributed as an rpm. Thanks, Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications Systems, National Library of Medicine, NIH _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Fri Jun 30 08:44:01 2017 From: hhorak at redhat.com (Honza Horak) Date: Fri, 30 Jun 2017 10:44:01 +0200 Subject: [scl.org] Self-introduction In-Reply-To: <1765405511.44657951.1498748182929.JavaMail.zimbra@redhat.com> References: <1765405511.44657951.1498748182929.JavaMail.zimbra@redhat.com> Message-ID: Welcome on board! Honza On 06/29/2017 04:56 PM, Augusto Caringi wrote: > Hi everyone, > > My name is Augusto Caringi, I'm a Software Engineer working at Red Hat in the Core Services/Databases team and I would like to become member of sclo-sig to help with packaging of Apache Cassandra. > > Best regards, >