[EPEL-devel] Re: nodejs update
> On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher wrote: > > Let me (or open a rel-eng ticket) when you want a epel7-nodejs6 side > tag to build it into. Will make it easier so you don't need to deal > with a billion build overrides etc. > I'm not sure that will be strictly necessary; we figured out during the Fedora process that once we moved to the bundled NPM, we only had about a dozen packages that actually needed a rebuild to support Node.js 6.x (just the ones that build a native, archful module). But yes, I'll make sure to let you know if we decide it needs a side-tag. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] intent to retire pam_script from epel5
I doubt anyone is using but as a heads up, I am planning on retiring pam_script from epel5. If you are using the epel5 package and would like to maintain it just apply for ACLs and I'll hand them over. JT ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: nodejs update
On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher wrote: > On 08/11/2016 07:43 AM, Stephen Gallagher wrote: >> On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote: >>> Hi! >>> >>> As some of you may know, nodejs package that is present in >>> EPEL is pretty outdated. The current v0.10 that we have will >>> go EOL in October and npm (package manager) is already not >>> maintained. >>> >>> Currently, upstreams' plan is to have two versions of Long >>> Term Support (LTS) at once, one in active development and one >>> in maintenance mode. >>> Currently active is v4, which is switching to maintenance in >>> April and v6 which is switching to LTS in October. >>> This is also reason why we would like to skip v4, although >>> both will get security updates. Nodejs v6 also comes with >>> newer npm and v8 (which might best be bundled, as it is in >>> Fedora and Software Collections) (v8 might concern ruby and >>> database maintainers, but old v8 package still remains in >>> the repo). >>> >>> There was also an idea to have both LTS versions in repo, >>> but we're not quite sure, how we'd do it and if it's even a >>> good idea. >>> >>> Also, another thing is, if it is worth of updating every year >>> to new LTS or update only after the current one goes EOL. >>> According to guidelines, I'd say it's the latter, but it's >>> not exactly how node development works and some feedback from >>> users on this would be nice, because I have none. >>> >>> >>> tl;dr Need to update nodejs, but can't decide if v4 or v6, >>> v4: will update sooner, shorter support (2018-04-01) >>> v6: longer support (2019-04-01), *might* break more things, >>> won't be in stable sooner than mid-October if everything >>> goes well >> >> FYI, I think this tl;dr missed explaining why v6 won't be in stable until >> mid-October. What Zuzana and I discussed on another list is that the Node.js >> v6 >> schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. >> However, v6 is already out and available. The major thing that changes at >> that >> point is just that from then on, they commit to adding no more major features >> (as I understand it). This is the best moment for us to switch over to it. >> >> However, in the meantime we will probably want to be carrying 6.x in >> updates-testing for at least a month prior to declaring it stable (with >> autokarma disabled) with wide announcements about the impending upgrade. This >> will be safe to do since Node.js 6.x has already reached a point where no >> backwards-incompatible changes are allowed in, so we can start the migration >> process early. >> > > OK, as we stated before, we really need to get Node.js 6.x into the > updates-testing repository soon. We mentioned that we wanted it to sit there > for > at least a month before we cut over, and "at least a month" means "by next > week" > since the cut over is planned for 2016-10-01. > > I'm putting together a COPR right now as a first pass at this upgrade: Let me (or open a rel-eng ticket) when you want a epel7-nodejs6 side tag to build it into. Will make it easier so you don't need to deal with a billion build overrides etc. Peter > https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/ > > I've run into the following blocker issues: > > * We cannot jump to 6.x in EPEL 6 easily at this time, because upstream > strictly > requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible > to resolve this with SCLs, but I am no expert there. Zuzana? > > * Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2 > and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 > and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL > or otherwise) for linking EPEL to a newer version of OpenSSL. > > The OpenSSL 1.0.2 problem is a significant one; we cannot build against the > bundled copy of OpenSSL because it includes patented algorithms that are not > acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's > OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the > base RHEL/CentOS repositories. > > > Right now, the only thing I can think of would be for someone to build a > parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to > the > openssl101e package available for EPEL 5) and patch our specfile to be able to > work with that instead. > > This is a task I'm not anxious to embark upon personally; there is too much > overhead in maintaining a fork of OpenSSL to make me comfortable. > > How shall we proceed? > > > ___ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org > ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 532 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 295 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 57 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e0c08a1414 php-PHPMailer-5.2.16-2.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c redis-3.2.3-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2c0e0e64b2 python34-3.4.3-7.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b8dd3488d knot-1.6.8-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f0e09b5124 borgbackup-1.0.7-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing perl-Exception-Base-0.2501-1.el7 Details about builds: perl-Exception-Base-0.2501-1.el7 (FEDORA-EPEL-2016-22753b2cc4) Lightweight exceptions Update Information: Current upstream release, fixes some warnings and an unwanted side-effect of the to_string method. References: [ 1 ] Bug #1273668 - to_string() appends 'undef' to array attribute https://bugzilla.redhat.com/show_bug.cgi?id=1273668 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds
On Mon, Aug 22, 2016 at 11:30 AM, Jason L Tibbitts III wrote: > > "DJ" == Dave Johansen writes: > > DJ> devtoolset is designed to do all of this and is already done, so it > DJ> seems that the only advantage to putting it in EPEL itself would be > DJ> to reduce the number of repos during build time. > > So is devtoolset something I get access to as a CentOS user? How do I > build these packages myself (i.e. in mock)? > The official version used to be behind a paywall, but there were builds by CentOS and CERN. It's now been turned over to a SIG and is all open: https://www.softwarecollections.org/en/scls/?search=devtoolset Building just the compiler part isn't too bad, but building the IDE and other parts of devtoolset takes some working out of the build order that I never worked out because I only cared about the compiler: https://www.redhat.com/archives/sclorg/2016-January/msg2.html Here's a blog on building SCLs in mock: http://developers.redhat.com/blog/2015/01/07/using-mock-to-build-python27-software-collections-packages-for-rhel6/ For building in COPR, I followed these instructions (but the main magic point is editting each of the supported chroots to have "scl-utils-build -build"): https://www.redhat.com/archives/sclorg/2014-November/msg00015.html ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Meeting this week.
I have to be out due to a family emergency. Can some one take over running the meeting this week? Thank you -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds
> "DJ" == Dave Johansen writes: DJ> devtoolset is designed to do all of this and is already done, so it DJ> seems that the only advantage to putting it in EPEL itself would be DJ> to reduce the number of repos during build time. So is devtoolset something I get access to as a CentOS user? How do I build these packages myself (i.e. in mock)? - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds
On Thu, Aug 18, 2016 at 10:03 PM, Orion Poplawski wrote: > On 08/18/2016 05:57 PM, Jason L Tibbitts III wrote: > >> Can we not just have an updated gcc package in EPEL? It wouldn't be >> hard to make one. Or do we have to not conflict with whatever Red Hat >> might put in one of their addons? Even then it would be easy to avoid >> both file and package name conflicts. >> > > I don't see why not (we only promise to not conflict with a couple base > channels), though I'm willing to believe that it would be hard, especially > for EL6. devtoolset is designed to do all of this and is already done, so it seems that the only advantage to putting it in EPEL itself would be to reduce the number of repos during build time. In my opinion that's not a big enough advantage to justify all of the work that would be involved. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: nodejs update
On 08/11/2016 07:43 AM, Stephen Gallagher wrote: > On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote: >> Hi! >> >> As some of you may know, nodejs package that is present in >> EPEL is pretty outdated. The current v0.10 that we have will >> go EOL in October and npm (package manager) is already not >> maintained. >> >> Currently, upstreams' plan is to have two versions of Long >> Term Support (LTS) at once, one in active development and one >> in maintenance mode. >> Currently active is v4, which is switching to maintenance in >> April and v6 which is switching to LTS in October. >> This is also reason why we would like to skip v4, although >> both will get security updates. Nodejs v6 also comes with >> newer npm and v8 (which might best be bundled, as it is in >> Fedora and Software Collections) (v8 might concern ruby and >> database maintainers, but old v8 package still remains in >> the repo). >> >> There was also an idea to have both LTS versions in repo, >> but we're not quite sure, how we'd do it and if it's even a >> good idea. >> >> Also, another thing is, if it is worth of updating every year >> to new LTS or update only after the current one goes EOL. >> According to guidelines, I'd say it's the latter, but it's >> not exactly how node development works and some feedback from >> users on this would be nice, because I have none. >> >> >> tl;dr Need to update nodejs, but can't decide if v4 or v6, >> v4: will update sooner, shorter support (2018-04-01) >> v6: longer support (2019-04-01), *might* break more things, >> won't be in stable sooner than mid-October if everything >> goes well > > FYI, I think this tl;dr missed explaining why v6 won't be in stable until > mid-October. What Zuzana and I discussed on another list is that the Node.js > v6 > schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. > However, v6 is already out and available. The major thing that changes at that > point is just that from then on, they commit to adding no more major features > (as I understand it). This is the best moment for us to switch over to it. > > However, in the meantime we will probably want to be carrying 6.x in > updates-testing for at least a month prior to declaring it stable (with > autokarma disabled) with wide announcements about the impending upgrade. This > will be safe to do since Node.js 6.x has already reached a point where no > backwards-incompatible changes are allowed in, so we can start the migration > process early. > OK, as we stated before, we really need to get Node.js 6.x into the updates-testing repository soon. We mentioned that we wanted it to sit there for at least a month before we cut over, and "at least a month" means "by next week" since the cut over is planned for 2016-10-01. I'm putting together a COPR right now as a first pass at this upgrade: https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/ I've run into the following blocker issues: * We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible to resolve this with SCLs, but I am no expert there. Zuzana? * Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2 and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL. The OpenSSL 1.0.2 problem is a significant one; we cannot build against the bundled copy of OpenSSL because it includes patented algorithms that are not acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the base RHEL/CentOS repositories. Right now, the only thing I can think of would be for someone to build a parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the openssl101e package available for EPEL 5) and patch our specfile to be able to work with that instead. This is a task I'm not anxious to embark upon personally; there is too much overhead in maintaining a fork of OpenSSL to make me comfortable. How shall we proceed? signature.asc Description: OpenPGP digital signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Major Nginx update for EL7, EL6, EL5
Hi, On Tuesday 6th September, these updates will be pushed from epel-testing to stable. Please do review and test the update before it gets rolled out, just in case your websites break. (ie, yum --enablerepo=epel-testing update nginx) See the previous email for the full details. Kind regards, -- Jamie Nguyen ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
