From ncoghlan at redhat.com Wed May 3 07:13:37 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Wed, 3 May 2017 17:13:37 +1000 Subject: [scl.org] Python3 (always latest) community SCL In-Reply-To: References: Message-ID: On Fri, Apr 14, 2017 at 12:27 AM, Tomas Orsava wrote: > Hi! > > On 04/11/2017 10:24 AM, Nick Coghlan wrote: >> >> I've been mulling this idea over for the past couple of weeks, and I'm >> wondering if it might make sense to create a rolling "sclo-python3" >> SCL, that's initially forked from >> https://www.softwarecollections.org/en/scls/rhscl/rh-python35/, but >> explicitly promises to rebase to new Python feature releases when they >> come out. >> >> So if people were happy to always run on the leading edge (even for >> X.Y.0 releases), they could use "sclo-python3", but if they wanted to >> stay on a particular X.Y release for a while, they would need to >> switch to the downstream rh-pythonXY SCLs. >> >> Remi, if I wanted to do that, where would I start? >> https://github.com/sclorg-distgit is useful as a reference for >> submitting changes to existing community SCLs, but it doesn't provide >> any guidance on how to start a new one (and that info is also missing >> from the wiki). > > It would be great to have a state-of-the-art Python in Enterprise Linux, but > I think it would be better using the existing (though lacking maintenance) > Python 3 in EPEL [0] mechanism. > > While installing and using SCLs isn't hard, I think an RPM packaged version > is still easier for both maintenance and usage and people can have EPEL > packages built against it as well. In addition the transition mechanism is > smoother, as two Python versions are coexisting during the transition > period, whereas the rolling SCL would just switch and everyone would have to > immediately adjust. > > What would be the advantage of creating a rolling 'scl-python3' collection > over the EPEL mechanism [1]? The main practical issue I see with the EPEL parallel installation design is the part about updating "/usr/bin/python3" to new "stable" versions: ============== In a situation when python3X is in EPEL and 3.X+1 is released upstream, the following happens: * python3X+1 package is created for EPEL ASAP and all extension packages are built also for this new python3X+1 stack. * When all packages are rebuilt for python3X+1, the old python3X stack is retired after certain period. This period gives everyone enough time to rebuild their packages while being as short as possible. There is intentionally no hard limit here, we will approach this case by case. * "/usr/bin/python3" belongs to the "stable" python3X stack. Switching /usr/bin/python3 from python3X to python3X+1 happens shortly before the end of transitional period (== before obsoleting python3X) and it is announced on epel-devel. Usage of "/usr/bin/python3" is discouraged in favour of using /usr/bin/python3.X explicitly. ============== While I thought this sounded reasonable at the time, it turns out to have a lot of problems in practice, as it makes it hard for developers to say "I just want to run on a pre-built version of the latest upstream Python". Instead, they have to choose between: * referring to python3.x in their own code, and having to update all those references to switch to a new version * keeping their "python3" references, and trusting that the originally planned EPEL transitions will happen in a timely fashion And then regardless of the approach they choose, they have to rely on either virtualenv or fiddling with the system level symlink to run against an alternative Python 3 stack. Accordingly, the main benefit I see to the rolling community SCL is that it makes "python3" load the SCL version when the SCL is enabled, which *does* make it easy for developers to choose between running against either the latest Python 3.x (by building on top of either Fedora or the proposed community SCL), or against a specific Python 3.x version (by using the Red Hat SCLs). If the native EPEL builds are retained, then they would be a *downstream* of the Red Hat SCLs, so the complete maintenance flow would be: - upstream release happens - Fedora system Python and rolling Python 3 community SCL are updated - Python 3.x Red Hat SCLs are updated - EPEL Python 3.x stacks are updated That approach is then a lot closer to the traditional RPM update flow from upstream->Fedora->RHEL->CentOS, just modified to be upstream->SCLo->RHSCL->EPEL since there isn't a system Python 3 stack in RHEL & CentOS. Cheers, Nick. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From torsava at redhat.com Wed May 3 11:44:06 2017 From: torsava at redhat.com (Tomas Orsava) Date: Wed, 3 May 2017 13:44:06 +0200 Subject: [scl.org] Python3 (always latest) community SCL In-Reply-To: References: Message-ID: On 05/03/2017 09:13 AM, Nick Coghlan wrote: > On Fri, Apr 14, 2017 at 12:27 AM, Tomas Orsava wrote: >> Hi! >> >> On 04/11/2017 10:24 AM, Nick Coghlan wrote: >>> I've been mulling this idea over for the past couple of weeks, and I'm >>> wondering if it might make sense to create a rolling "sclo-python3" >>> SCL, that's initially forked from >>> https://www.softwarecollections.org/en/scls/rhscl/rh-python35/, but >>> explicitly promises to rebase to new Python feature releases when they >>> come out. >>> >>> So if people were happy to always run on the leading edge (even for >>> X.Y.0 releases), they could use "sclo-python3", but if they wanted to >>> stay on a particular X.Y release for a while, they would need to >>> switch to the downstream rh-pythonXY SCLs. >>> >>> Remi, if I wanted to do that, where would I start? >>> https://github.com/sclorg-distgit is useful as a reference for >>> submitting changes to existing community SCLs, but it doesn't provide >>> any guidance on how to start a new one (and that info is also missing >>> from the wiki). >> It would be great to have a state-of-the-art Python in Enterprise Linux, but >> I think it would be better using the existing (though lacking maintenance) >> Python 3 in EPEL [0] mechanism. >> >> While installing and using SCLs isn't hard, I think an RPM packaged version >> is still easier for both maintenance and usage and people can have EPEL >> packages built against it as well. In addition the transition mechanism is >> smoother, as two Python versions are coexisting during the transition >> period, whereas the rolling SCL would just switch and everyone would have to >> immediately adjust. >> >> What would be the advantage of creating a rolling 'scl-python3' collection >> over the EPEL mechanism [1]? > The main practical issue I see with the EPEL parallel installation > design is the part about updating "/usr/bin/python3" to new "stable" > versions: > > ============== > In a situation when python3X is in EPEL and 3.X+1 is released > upstream, the following happens: > > * python3X+1 package is created for EPEL ASAP and all extension > packages are built also for this new python3X+1 stack. > * When all packages are rebuilt for python3X+1, the old python3X stack > is retired after certain period. This period gives everyone enough > time to rebuild their packages while being as short as possible. There > is intentionally no hard limit here, we will approach this case by > case. > * "/usr/bin/python3" belongs to the "stable" python3X stack. Switching > /usr/bin/python3 from python3X to python3X+1 happens shortly before > the end of transitional period (== before obsoleting python3X) and it > is announced on epel-devel. > Usage of "/usr/bin/python3" is discouraged in favour of using > /usr/bin/python3.X explicitly. > ============== > > While I thought this sounded reasonable at the time, it turns out to > have a lot of problems in practice, as it makes it hard for developers > to say "I just want to run on a pre-built version of the latest > upstream Python". Instead, they have to choose between: > > * referring to python3.x in their own code, and having to update all > those references to switch to a new version > * keeping their "python3" references, and trusting that the originally > planned EPEL transitions will happen in a timely fashion I agree that it's not exactly seamless, you can make a single boolean macro in your spec file using which it will be switched to the alternative Python, so it shouldn't be a significant maintenance burden. > And then regardless of the approach they choose, they have to rely on > either virtualenv or fiddling with the system level symlink to run > against an alternative Python 3 stack. If I may ask, what do you mean by fiddling with the system level symlink? I believe they can invoke `/usr/bin/python3.X` using the %{__python3_other} macro. > Accordingly, the main benefit I see to the rolling community SCL is > that it makes "python3" load the SCL version when the SCL is enabled, > which *does* make it easy for developers to choose between running > against either the latest Python 3.x (by building on top of either > Fedora or the proposed community SCL), or against a specific Python > 3.x version (by using the Red Hat SCLs). If the native EPEL builds are > retained, then they would be a *downstream* of the Red Hat SCLs, so > the complete maintenance flow would be: > > - upstream release happens > - Fedora system Python and rolling Python 3 community SCL are updated > - Python 3.x Red Hat SCLs are updated > - EPEL Python 3.x stacks are updated > > That approach is then a lot closer to the traditional RPM update flow > from upstream->Fedora->RHEL->CentOS, just modified to be > upstream->SCLo->RHSCL->EPEL since there isn't a system Python 3 stack > in RHEL & CentOS. I do see the benefits of the added rolling SCL, though in my mind the benefits are lessened by the pre-existence of Python 3 in EPEL, and thus I'm not sure it's worth the added maintenance. However, that's only my personal reasoning. If we can find volunteers for the effort I'll be glad to lend a hand with the creation of the SCL. Best regards, Tomas > > Cheers, > Nick. > > > > > Cheers, > Nick. > From ncoghlan at redhat.com Wed May 3 12:35:34 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Wed, 3 May 2017 22:35:34 +1000 Subject: [scl.org] Python3 (always latest) community SCL In-Reply-To: References: Message-ID: On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava wrote: > On 05/03/2017 09:13 AM, Nick Coghlan wrote: >>> On 04/11/2017 10:24 AM, Nick Coghlan wrote: >> While I thought this sounded reasonable at the time, it turns out to >> have a lot of problems in practice, as it makes it hard for developers >> to say "I just want to run on a pre-built version of the latest >> upstream Python". Instead, they have to choose between: >> >> * referring to python3.x in their own code, and having to update all >> those references to switch to a new version >> * keeping their "python3" references, and trusting that the originally >> planned EPEL transitions will happen in a timely fashion > > > I agree that it's not exactly seamless, you can make a single boolean macro > in your spec file using which it will be switched to the alternative Python, > so it shouldn't be a significant maintenance burden. For the use cases I'm interested in, there's no application level spec file - just a container definition or Ansible deployment script. SCLs are really useful for those cases, since it's relatively straightforward to ensure the SCL is enabled at the appropriate times, while RPM macros aren't available. >> And then regardless of the approach they choose, they have to rely on >> either virtualenv or fiddling with the system level symlink to run >> against an alternative Python 3 stack. > > If I may ask, what do you mean by fiddling with the system level symlink? I > believe they can invoke `/usr/bin/python3.X` using the %{__python3_other} > macro. Choosing a stack other than the default one at runtime (rather than when building an RPM). I'm not suggesting changing the symlink would be a good idea, just pointing out it's basically the only option left if you're not using either SCLs or a Python level venv and aren't willing to qualify every Python 3 invocation with a specific minor version. >> That approach is then a lot closer to the traditional RPM update flow >> from upstream->Fedora->RHEL->CentOS, just modified to be >> upstream->SCLo->RHSCL->EPEL since there isn't a system Python 3 stack >> in RHEL & CentOS. > > I do see the benefits of the added rolling SCL, though in my mind the > benefits are lessened by the pre-existence of Python 3 in EPEL, and thus I'm > not sure it's worth the added maintenance. However, that's only my personal > reasoning. > > If we can find volunteers for the effort I'll be glad to lend a hand with > the creation of the SCL. I'd like to see this happen enough to volunteer to maintain it myself, so I'll start working through the checklist that Honza posted :) Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From torsava at redhat.com Wed May 3 12:45:50 2017 From: torsava at redhat.com (Tomas Orsava) Date: Wed, 3 May 2017 14:45:50 +0200 Subject: [scl.org] Python3 (always latest) community SCL In-Reply-To: References: Message-ID: <50d0d9a3-3c15-c369-5316-d261eb34eee1@redhat.com> On 05/03/2017 02:35 PM, Nick Coghlan wrote: > On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava wrote: >> On 05/03/2017 09:13 AM, Nick Coghlan wrote: >>>> On 04/11/2017 10:24 AM, Nick Coghlan wrote: >>> While I thought this sounded reasonable at the time, it turns out to >>> have a lot of problems in practice, as it makes it hard for developers >>> to say "I just want to run on a pre-built version of the latest >>> upstream Python". Instead, they have to choose between: >>> >>> * referring to python3.x in their own code, and having to update all >>> those references to switch to a new version >>> * keeping their "python3" references, and trusting that the originally >>> planned EPEL transitions will happen in a timely fashion >> >> I agree that it's not exactly seamless, you can make a single boolean macro >> in your spec file using which it will be switched to the alternative Python, >> so it shouldn't be a significant maintenance burden. > For the use cases I'm interested in, there's no application level spec > file - just a container definition or Ansible deployment script. > > SCLs are really useful for those cases, since it's relatively > straightforward to ensure the SCL is enabled at the appropriate times, > while RPM macros aren't available. > >>> And then regardless of the approach they choose, they have to rely on >>> either virtualenv or fiddling with the system level symlink to run >>> against an alternative Python 3 stack. >> If I may ask, what do you mean by fiddling with the system level symlink? I >> believe they can invoke `/usr/bin/python3.X` using the %{__python3_other} >> macro. > Choosing a stack other than the default one at runtime (rather than > when building an RPM). I'm not suggesting changing the symlink would > be a good idea, just pointing out it's basically the only option left > if you're not using either SCLs or a Python level venv and aren't > willing to qualify every Python 3 invocation with a specific minor > version. > >>> That approach is then a lot closer to the traditional RPM update flow >>> from upstream->Fedora->RHEL->CentOS, just modified to be >>> upstream->SCLo->RHSCL->EPEL since there isn't a system Python 3 stack >>> in RHEL & CentOS. >> I do see the benefits of the added rolling SCL, though in my mind the >> benefits are lessened by the pre-existence of Python 3 in EPEL, and thus I'm >> not sure it's worth the added maintenance. However, that's only my personal >> reasoning. >> >> If we can find volunteers for the effort I'll be glad to lend a hand with >> the creation of the SCL. > I'd like to see this happen enough to volunteer to maintain it myself, > so I'll start working through the checklist that Honza posted :) In that case: Godspeed! And do contact me if I can help you with building of the collection! All the best, Tomas > > Cheers, > Nick. > From gregswift at gmail.com Wed May 10 03:54:42 2017 From: gregswift at gmail.com (Greg Swift) Date: Wed, 10 May 2017 03:54:42 +0000 Subject: [scl.org] Node versions Message-ID: Has the general community plan for tracking node versions been discussed before? I see that Node4 went into maintenance a few days ago[1]. I was looking into this because one of my peers was trying to install ethercalc in openshift on node4, and it doesnt work because it requires node 4.8+ (well 5 if you want to avoid feature flags). I found a few attempts at SCL builds in COPR [2], but only one looked like it was going anywhere with node 6 (current LTS) [3]. Doesn't appear that anyone has mentioned node on this list since 2015[4]. Nothing on stackoverflow either.[5] I've been watching some of the other chats on here, such as about Python3.latest. So I'm just kinda curious what people's thoughts are? I'm interested in helping and also into looking into building an node6 lts version of the LTS. I'm also planning on looking at doing a build of the OpenShift containers and s2i[6] for node6. No idea what my time schedule is, but my co-workers are definitely interested and they are my customers :D -greg [1] https://github.com/nodejs/LTS [2] https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=nodejs [3] https://copr.fedorainfracloud.org/coprs/zvetlik/rh-nodejs6/ [4] https://www.google.com/#q=site:https://www.redhat.com/archives/sclorg+node [5] https://stackoverflow.com/search?q=%5Bsoftware-collections%5D+node [6] https://github.com/sclorg/s2i-nodejs-container -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at redhat.com Wed May 10 05:37:11 2017 From: ncoghlan at redhat.com (Nick Coghlan) Date: Wed, 10 May 2017 15:37:11 +1000 Subject: [scl.org] Python3 (always latest) community SCL In-Reply-To: References: Message-ID: On Wed, May 3, 2017 at 10:35 PM, Nick Coghlan wrote: > On Wed, May 3, 2017 at 9:44 PM, Tomas Orsava wrote: >> I do see the benefits of the added rolling SCL, though in my mind the >> benefits are lessened by the pre-existence of Python 3 in EPEL, and thus I'm >> not sure it's worth the added maintenance. However, that's only my personal >> reasoning. >> >> If we can find volunteers for the effort I'll be glad to lend a hand with >> the creation of the SCL. > > I'd like to see this happen enough to volunteer to maintain it myself, > so I'll start working through the checklist that Honza posted :) 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. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From zsvetlik at redhat.com Wed May 10 18:53:23 2017 From: zsvetlik at redhat.com (Zuzana Svetlikova) Date: Wed, 10 May 2017 20:53:23 +0200 Subject: [scl.org] Node versions In-Reply-To: References: Message-ID: Hi Greg, currently we ship LTS releases in RHSCL, which means v4, v6 (released recently, s2i image should be available soon as well) and there are definitely plans for v8 in the future. About having latest Node.js available as SCL (as in having odd releases and latest z-stream), I believe that would make a lot of people happy and I'd like to see it happen, but I'm afraid it could be realized only as a COPR project. I am sorry the new collection isn't available in CentOS yet, I'll try to get it to repos as soon as possible. Zuzka Node.js maintainer On Wed, May 10, 2017 at 5:54 AM, Greg Swift wrote: > Has the general community plan for tracking node versions been discussed > before? I see that Node4 went into maintenance a few days ago[1]. I was > looking into this because one of my peers was trying to install ethercalc > in openshift on node4, and it doesnt work because it requires node 4.8+ > (well 5 if you want to avoid feature flags). > > I found a few attempts at SCL builds in COPR [2], but only one looked like > it was going anywhere with node 6 (current LTS) [3]. Doesn't appear that > anyone has mentioned node on this list since 2015[4]. Nothing on > stackoverflow either.[5] > > I've been watching some of the other chats on here, such as about > Python3.latest. So I'm just kinda curious what people's thoughts are? I'm > interested in helping and also into looking into building an node6 lts > version of the LTS. I'm also planning on looking at doing a build of the > OpenShift containers and s2i[6] for node6. > > No idea what my time schedule is, but my co-workers are definitely > interested and they are my customers :D > > -greg > > [1] https://github.com/nodejs/LTS > [2] https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=nodejs > [3] https://copr.fedorainfracloud.org/coprs/zvetlik/rh-nodejs6/ > [4] https://www.google.com/#q=site:https://www.redhat.com/ > archives/sclorg+node > [5] https://stackoverflow.com/search?q=%5Bsoftware-collections%5D+node > [6] https://github.com/sclorg/s2i-nodejs-container > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jaroslaw.Polok at cern.ch Mon May 15 07:14:37 2017 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Mon, 15 May 2017 09:14:37 +0200 Subject: [scl.org] New git package In-Reply-To: <2fc3811046b44c78b2dc5fac54555d17@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> <47a4bb5c-a201-c736-7d05-11ee58907d14@redhat.com> <2fc3811046b44c78b2dc5fac54555d17@rwthex-w2-b.rwth-ad.de> Message-ID: <60ba20f2-5246-a8f8-ca06-df7d00e05e4f@cern.ch> Hi all FYI: I have actually prepared new git packages ... a month ago (git 2.12) .... but somehow these are still not in testing repos ... https://bugs.centos.org/view.php?id=13127 Cheers Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/CM/LCS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From zsvetlik at redhat.com Wed May 17 10:44:03 2017 From: zsvetlik at redhat.com (Zuzana Svetlikova) Date: Wed, 17 May 2017 12:44:03 +0200 Subject: [scl.org] Node versions In-Reply-To: References: Message-ID: Hi, rh-nodejs6 SCL is now in CentOS testing repository. On Wed, May 10, 2017 at 8:53 PM, Zuzana Svetlikova wrote: > Hi Greg, > > currently we ship LTS releases in RHSCL, which means v4, v6 (released > recently, s2i image should be available soon as well) and there are > definitely plans for v8 in the future. > > About having latest Node.js available as SCL (as in having odd releases > and latest z-stream), I believe that would make a lot of people happy and > I'd like to see it happen, > but I'm afraid it could be realized only as a COPR project. > > I am sorry the new collection isn't available in CentOS yet, I'll try to > get it to repos as soon as possible. > > Zuzka > Node.js maintainer > > On Wed, May 10, 2017 at 5:54 AM, Greg Swift wrote: > >> Has the general community plan for tracking node versions been discussed >> before? I see that Node4 went into maintenance a few days ago[1]. I was >> looking into this because one of my peers was trying to install ethercalc >> in openshift on node4, and it doesnt work because it requires node 4.8+ >> (well 5 if you want to avoid feature flags). >> >> I found a few attempts at SCL builds in COPR [2], but only one looked >> like it was going anywhere with node 6 (current LTS) [3]. Doesn't appear >> that anyone has mentioned node on this list since 2015[4]. Nothing on >> stackoverflow either.[5] >> >> I've been watching some of the other chats on here, such as about >> Python3.latest. So I'm just kinda curious what people's thoughts are? I'm >> interested in helping and also into looking into building an node6 lts >> version of the LTS. I'm also planning on looking at doing a build of the >> OpenShift containers and s2i[6] for node6. >> >> No idea what my time schedule is, but my co-workers are definitely >> interested and they are my customers :D >> >> -greg >> >> [1] https://github.com/nodejs/LTS >> [2] https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=nodejs >> [3] https://copr.fedorainfracloud.org/coprs/zvetlik/rh-nodejs6/ >> [4] https://www.google.com/#q=site:https://www.redhat.com/archiv >> es/sclorg+node >> [5] https://stackoverflow.com/search?q=%5Bsoftware-collections%5D+node >> [6] https://github.com/sclorg/s2i-nodejs-container >> >> >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregswift at gmail.com Thu May 18 14:49:20 2017 From: gregswift at gmail.com (Greg Swift) Date: Thu, 18 May 2017 14:49:20 +0000 Subject: [scl.org] Node versions In-Reply-To: References: Message-ID: Thanks, I'll check it out. and thanks for the information about the general plans. -greg On Wed, May 17, 2017 at 5:44 AM Zuzana Svetlikova wrote: > Hi, > > rh-nodejs6 SCL is now in CentOS testing repository. > > > On Wed, May 10, 2017 at 8:53 PM, Zuzana Svetlikova > wrote: > >> Hi Greg, >> >> currently we ship LTS releases in RHSCL, which means v4, v6 (released >> recently, s2i image should be available soon as well) and there are >> definitely plans for v8 in the future. >> >> About having latest Node.js available as SCL (as in having odd releases >> and latest z-stream), I believe that would make a lot of people happy and >> I'd like to see it happen, >> but I'm afraid it could be realized only as a COPR project. >> >> I am sorry the new collection isn't available in CentOS yet, I'll try to >> get it to repos as soon as possible. >> >> Zuzka >> Node.js maintainer >> >> On Wed, May 10, 2017 at 5:54 AM, Greg Swift wrote: >> >>> Has the general community plan for tracking node versions been discussed >>> before? I see that Node4 went into maintenance a few days ago[1]. I was >>> looking into this because one of my peers was trying to install ethercalc >>> in openshift on node4, and it doesnt work because it requires node 4.8+ >>> (well 5 if you want to avoid feature flags). >>> >>> I found a few attempts at SCL builds in COPR [2], but only one looked >>> like it was going anywhere with node 6 (current LTS) [3]. Doesn't appear >>> that anyone has mentioned node on this list since 2015[4]. Nothing on >>> stackoverflow either.[5] >>> >>> I've been watching some of the other chats on here, such as about >>> Python3.latest. So I'm just kinda curious what people's thoughts are? I'm >>> interested in helping and also into looking into building an node6 lts >>> version of the LTS. I'm also planning on looking at doing a build of the >>> OpenShift containers and s2i[6] for node6. >>> >>> No idea what my time schedule is, but my co-workers are definitely >>> interested and they are my customers :D >>> >>> -greg >>> >>> [1] https://github.com/nodejs/LTS >>> [2] https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=nodejs >>> [3] https://copr.fedorainfracloud.org/coprs/zvetlik/rh-nodejs6/ >>> [4] >>> https://www.google.com/#q=site:https://www.redhat.com/archives/sclorg+node >>> [5] https://stackoverflow.com/search?q=%5Bsoftware-collections%5D+node >>> [6] https://github.com/sclorg/s2i-nodejs-container >>> >>> >>> >>> _______________________________________________ >>> SCLorg mailing list >>> SCLorg at redhat.com >>> https://www.redhat.com/mailman/listinfo/sclorg >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elyscape at gmail.com Thu May 18 20:33:48 2017 From: elyscape at gmail.com (Eli Young) Date: Thu, 18 May 2017 13:33:48 -0700 Subject: [scl.org] Software Collections website appears to be down Message-ID: Since at least yesterday, attempting to go to https://www.softwarecollections.org/ results in a timeout. I have determined that this is not just me; I get timeouts when trying to curl from my servers, friends have responded that it times out for them as well, and isup.me reports failures as well. From christoph.muellner at theobroma-systems.com Fri May 19 17:39:47 2017 From: christoph.muellner at theobroma-systems.com (=?utf-8?Q?Christoph_M=C3=BCllner?=) Date: Fri, 19 May 2017 19:39:47 +0200 Subject: [scl.org] SCL devtoolset on arm64/aarch64 Message-ID: <9E4B6DAE-F6FD-4301-87B2-12BD465EC69B@theobroma-systems.com> Hi sclorg list, I am using CentOS 7 on an arm64 machine and ran into the problem, that the shipped compiler is not recent enough for the source code I want to build (some required C++11 features are not available). On x86_64 I could use your devtoolset packages to circumvent the issue, but on arm64/aarch64 these packages are not available. Therefore I'd like to ask if there are some plans to get the devtoolset packages available on arm64? Thanks, Christoph -- Christoph M?llner Theobroma Systems Design und Consulting GmbH Seestadtstra?e 27 (Aspern IQ), 1220 Wien, Austria Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9 http://www.theobroma-systems.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP URL: