[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds
On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenziwrote: > On Wed, 24 Aug 2016 21:59:55 -0600 > Dave Johansen wrote: > > > I agree that how to handle SCLs can get really mess really fast, but > > a lot of projects are jumping on the "modern C++" bandwagon and > > allows devtoolset is low risk, easy to do and enables a lot of > > packages to be built with EPEL that otherwise wouldn't be. > > It would be low risk if that was the only SCL in the repo. > My understanding is that they are all there in the one repo, so if we > enable that, everyone could start using anything thats in there. > They're each in their own repo and I would propose adding devtoolset only in repos used by mock during build time. On Thu, Aug 25, 2016 at 2:40 PM, Kevin Fenzi wrote: > On Thu, 25 Aug 2016 12:52:46 -0400 > Stephen John Smoogen wrote: > > > On 25 August 2016 at 02:14, dani wrote: > > > When I proposed importing gcc-5 to EPEL6 back in 04/2016 ( > > > https://lists.fedoraproject.org/archives/list/epel-devel@ > lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/ > > > ) the response was an unequivocal no, EPEL does not install > > > to /opt/ , so it dies right there. > > > > > > Now you are proposing the same ( devtoolset/scl installs to /opt > > > except for the wrapper call) but using a scheme that is somewhat > > > less convenient (In scl the binutils and gcc have to be coupled, > > > and as noted the imported gcc suite is incomplete), much less > > > frequent (the most updated version is gcc-5.2, while I maintain > > > both gcc-5.x and gcc-6.1), and much less complete (I import > > > everything but gcc-gnat, while devtoolset4 only has gcc,gcc-c++ and > > > gcc-gfortran. No gcc-objc, no gcc-go, no cpp, and none of the libs > > > (cilk, gccjit, atomic, asan etc...). > > > > > > I'm still building and maintaining both gcc and bintutils for my own > > > purposes, which are based off of fc24 srpms, and with optionally > > > gcc-c++ specs file hardcoded to use binutils tools at the new > > > prefix so use of env-modules is not required. > > > > > > I'm just wandering why the different treatment - the automatic > > > knee-jerk reaction of dismissal to a newbie proposal vs. accepting > > > the exact same proposal (although wrapped so it's less convenient > > > to use) when it comes from someone else. > > > > > > > You are misreading both responses. There is no knee-jerk acceptance > > and there wasn't a knee jerk dismissal because you were a newbie. > > Please don't find malice where none was intended. > > What smooge said. ;) > > The reason SCL's are under opt is that they got a namespace approved > for that purpose: > > https://fedoraproject.org/wiki/Packaging:Guidelines# > Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt > > "Currently, we have allocated /opt/fedora/scls, /etc/opt/fedora/scls, > and /var/opt/fedora/scls for use by Software Collections. " > > Perhaps you could explain exactly what you want to propose here again? > Just epel6? or 7 as well? Do you have co-maintainers in case you get > busy, etc? > > I think we are all open to ideas how to do things better, but it's > really not clear what is best or even exactly what is proposed. ;) Here's one proposal: 1) Add version X of devtoolset only in repos used by mock 2) N months (maybe 6?) before version X is EOLed, make version X+1 (or whatever the latest is) available in a buildroot override (or something similar) for testing 3) Rebuild all packages that use devtoolset using version X+1 and make available for testing 4) After testing period (maybe 1 month? or 3 months?), upgrade to version X+1 and move all rebuilt packages from testing repos to main repos Or here's another option: 1) Add all non-EOLed versions of devtoolset only in repos used by mock 2) N months (at least 6) before version X is EOLed require that it be rebuilt with a newer version of devtoolset 3) If it's not rebuilt before the EOL happens, then retire the package I like the second option better, because it's easier to setup/maintain from a mock/koji perspective, provides flexibility and doesn't force a mass rebuild/test every 12-18 months when a devtoolset is retired (their life cycle is 2 years). However, it also means that the update is decentralized and depends on maintainers rather an an automated system. ___ 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, 25 Aug 2016 12:52:46 -0400 Stephen John Smoogenwrote: > On 25 August 2016 at 02:14, dani wrote: > > When I proposed importing gcc-5 to EPEL6 back in 04/2016 ( > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/ > > ) the response was an unequivocal no, EPEL does not install > > to /opt/ , so it dies right there. > > > > Now you are proposing the same ( devtoolset/scl installs to /opt > > except for the wrapper call) but using a scheme that is somewhat > > less convenient (In scl the binutils and gcc have to be coupled, > > and as noted the imported gcc suite is incomplete), much less > > frequent (the most updated version is gcc-5.2, while I maintain > > both gcc-5.x and gcc-6.1), and much less complete (I import > > everything but gcc-gnat, while devtoolset4 only has gcc,gcc-c++ and > > gcc-gfortran. No gcc-objc, no gcc-go, no cpp, and none of the libs > > (cilk, gccjit, atomic, asan etc...). > > > > I'm still building and maintaining both gcc and bintutils for my own > > purposes, which are based off of fc24 srpms, and with optionally > > gcc-c++ specs file hardcoded to use binutils tools at the new > > prefix so use of env-modules is not required. > > > > I'm just wandering why the different treatment - the automatic > > knee-jerk reaction of dismissal to a newbie proposal vs. accepting > > the exact same proposal (although wrapped so it's less convenient > > to use) when it comes from someone else. > > > > You are misreading both responses. There is no knee-jerk acceptance > and there wasn't a knee jerk dismissal because you were a newbie. > Please don't find malice where none was intended. What smooge said. ;) The reason SCL's are under opt is that they got a namespace approved for that purpose: https://fedoraproject.org/wiki/Packaging:Guidelines#Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt "Currently, we have allocated /opt/fedora/scls, /etc/opt/fedora/scls, and /var/opt/fedora/scls for use by Software Collections. " Perhaps you could explain exactly what you want to propose here again? Just epel6? or 7 as well? Do you have co-maintainers in case you get busy, etc? I think we are all open to ideas how to do things better, but it's really not clear what is best or even exactly what is proposed. ;) kevin pgpmuZRW4_19i.pgp 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: Adding the devtoolset repo for EPEL builds
On Wed, 24 Aug 2016 21:59:55 -0600 Dave Johansenwrote: > I agree that how to handle SCLs can get really mess really fast, but > a lot of projects are jumping on the "modern C++" bandwagon and > allows devtoolset is low risk, easy to do and enables a lot of > packages to be built with EPEL that otherwise wouldn't be. It would be low risk if that was the only SCL in the repo. My understanding is that they are all there in the one repo, so if we enable that, everyone could start using anything thats in there. > Basically, I think that figuring out how to handle SCLs is a long term > issue that will take some serious work, but coming up with some simple > policies that allow it to be used in EPEL is something that should be > well within the realm of the possible. Perhaps. :) kevin pgp7wkQ0JUQXN.pgp 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: Adding the devtoolset repo for EPEL builds
On 25 August 2016 at 12:49, Stephen John Smoogenwrote: > On 24 August 2016 at 23:59, Dave Johansen wrote: >> On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi wrote: >> >> I agree that how to handle SCLs can get really mess really fast, but a lot >> of projects are jumping on the "modern C++" bandwagon and allows devtoolset >> is low risk, easy to do and enables a lot of packages to be built with EPEL >> that otherwise wouldn't be. >> >> Basically, I think that figuring out how to handle SCLs is a long term issue >> that will take some serious work, but coming up with some simple policies >> that allow it to be used in EPEL is something that should be well within the >> realm of the possible. > > History and experience has taught us that every time we do that it > comes back and bites us big time. Mainly because the simple policies > start getting revised and rewritten or violated as soon as the second > package gets put in... and in fixing that you break the first one.. > and the people who used it. This is ok in Fedora but in EPEL you end > up spending a lot of time fixing people who aren't expecting breakage. I hit send too soon as what is the exact policy proposal you are wanting. > > > -- > Stephen J Smoogen. -- 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
On 25 August 2016 at 02:14, daniwrote: > When I proposed importing gcc-5 to EPEL6 back in 04/2016 ( > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/ > ) the response was an unequivocal no, EPEL does not install to /opt/ , so it > dies right there. > > Now you are proposing the same ( devtoolset/scl installs to /opt except for > the wrapper call) but using a scheme that is somewhat less convenient (In > scl the binutils and gcc have to be coupled, and as noted the imported gcc > suite is incomplete), much less frequent (the most updated version is > gcc-5.2, while I maintain both gcc-5.x and gcc-6.1), and much less complete > (I import everything but gcc-gnat, while devtoolset4 only has gcc,gcc-c++ > and gcc-gfortran. No gcc-objc, no gcc-go, no cpp, and none of the libs > (cilk, gccjit, atomic, asan etc...). > > I'm still building and maintaining both gcc and bintutils for my own > purposes, which are based off of fc24 srpms, and with optionally gcc-c++ > specs file hardcoded to use binutils tools at the new prefix so use of > env-modules is not required. > > I'm just wandering why the different treatment - the automatic knee-jerk > reaction of dismissal to a newbie proposal vs. accepting the exact same > proposal (although wrapped so it's less convenient to use) when it comes > from someone else. > You are misreading both responses. There is no knee-jerk acceptance and there wasn't a knee jerk dismissal because you were a newbie. Please don't find malice where none was intended. -- 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
On 24 August 2016 at 23:59, Dave Johansenwrote: > On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi wrote: >> >> On Wed, 24 Aug 2016 16:43:31 -0600 >> Dave Johansen wrote: >> >> > On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi wrote: >> > >> > > On Tue, 23 Aug 2016 14:21:24 +0100 >> > > Karanbir Singh wrote: >> > > >> > > > On 22/08/16 18:30, Jason L Tibbitts III wrote: >> > > > >> "DJ" == Dave Johansen writes: >> > > > > >> > > > > DJ> devtoolset is designed to do all of this and is already >> > > > > DJ> done, so it seems that the only advantage to putting it in >> > > > > DJ> EPEL itself would be to reduce the number of repos during >> > > > > DJ> 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)? >> > > > >> > > > you should be able to 'yum install centos-release-scl' on a CentOS >> > > > Linux machine and get access to all the SCLs >> > > >> > > Yeah, but if we enable that for EPEL builds, we are going to get all >> > > SCLs right? So, people could start depending on them at runtime >> > > instead of just install time. >> > > >> > > I'm not opposed to devtoolset, but I don't think we want to allow >> > > runtime scls without actual scl guidelines. >> > > >> > >> > I seem to remember that Fedora didn't allow SCLs because there was >> > some compatibility problem or something of the sort. Do you know the >> > details or what the current state is? >> >> It's not a compatibility problem. It's lack of guidelines. >> >> > Also, RedHat has been pushing devtoolset pretty hard. The response to >> > a few bugzillas has even been "use devtoolset because the issue is >> > fixed there and we're not going to fix the system gcc/libc/etc". So >> > it seems like allowing SCLs in Fedora/EPEL makes sense and fits with >> > the direction of RHEL in general. >> >> As I noted, I'd probibly be for devtoolset because the guidelines would >> be pretty simple. Just do X Y and Z in your spec, build as normal and >> users wouldn't see any run time dep on it. >> >> It gets weird where other SCL's come in. Can your package require say >> postgresql from SCL instead of the rhel one? If so, would our users all >> be able to install that? What happens if two packages need different >> SCL versions? Can SCL's depend on each other? Can you make a package >> thats an SCL? we have no guidelines for that, and just saying "do >> whatever you want" is likely to cause mass confusion and make everyone >> miserable. > > > I agree that how to handle SCLs can get really mess really fast, but a lot > of projects are jumping on the "modern C++" bandwagon and allows devtoolset > is low risk, easy to do and enables a lot of packages to be built with EPEL > that otherwise wouldn't be. > > Basically, I think that figuring out how to handle SCLs is a long term issue > that will take some serious work, but coming up with some simple policies > that allow it to be used in EPEL is something that should be well within the > realm of the possible. History and experience has taught us that every time we do that it comes back and bites us big time. Mainly because the simple policies start getting revised and rewritten or violated as soon as the second package gets put in... and in fixing that you break the first one.. and the people who used it. This is ok in Fedora but in EPEL you end up spending a lot of time fixing people who aren't expecting breakage. -- 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: nodejs update
On 08/11/2016 05: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. How does EPEL deal with the fact that nodejs won't work with openssl 1.0.1? For CentOS we have a patch that allows nodejs 4.x to build with openssl 1.0.1 in EL7. Are you using a similar patch? Do you know if the same patch will work with nodejs 6.x? Also need feedback from users. I hope I didn't forget anything important. Regards Zuzka Node.js SIG ___ 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.fedoraproject.org
[EPEL-devel] Re: nodejs update
On 23/08/16 03:48, Stephen Gallagher wrote: >> On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher >>> >> 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. Nodejs 6 bundles openssl 1.0.2.h, where RHEL/CentOS have a much older version. That hasn't been an issue in Fedora; For CentOS, there is a build for Node.js 4 in cbs, including a patch to unbundle openssl and to make it work with the way older lib. Unless we have a comparable patch (if possible) for Node version 6, maybe we should stick with version 4? Matthias ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
On 08/24/2016 11:39 PM, Neal Gompa wrote: On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawskiwrote: I have no idea if there is any interest in this or not. I managed to get the EPEL7 python34 package to build on EL6 with a few modifications. Is there any interest in supporting this? I think the Koji people would be interested in this, as it would help them in moving Koji to Python 3. They have a requirement for Koji to be able to run on EL6, so this could help unblock moving to Python 3. I might be wrong, but I believe I have heard at Flock that Koji is actually trying to maintain support of EL5 still! ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts IIIwrote: > > To be completely fair, I don't actually know EPEL policy here. The rule > is that you can't conflict with RHEL packages, but SRPMs aren't really > installed the same way as other packages and whether or not they would > install to the same location depends somewhat on your personal .rpmrc. > > As far as I know, this is the adopted policy [1]. Though, I'm not sure if that was ever made official since it's still on a user page. I couldn't find anything that specifically says SRPM names can't be the same and it seems like that is not the process for additional architecture packages. [2] They just use a leading 0 in the release, ex: foobar-1.0-0.1. I'm curious if anyone else has any insight. Maybe it is worth bringing up at a FPC meeting. [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_ Python3#Packaging_Parallel_python3X_stacks [2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
> > Which is an annoying bit of process, but it would be quite possible to > exempt those packages from needing package reviews. It needn't take > that long. > > Not needing reviews would help, but I wonder how hard it would be to make them children of python-PACKAGE. The main issue is the SRPM needs to have a different name so there is no conflict with the RHEL SRPM. That's easy to set in the spec file, but the build system requires the SRPM name to match the Fedora pkgdb and git names. Is it possible to define children, so python34-PACKAGE could use the same git repo as python-PACKAGE? This would be cleaner and more accurate than the current convention of creating a python3-PACKAGE git repo and pkgdb package. Avram ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
Definitely, but it runs into the same problem as 3.4 on EL7, the fact that there are few packages available and adding them when the package already exists in RHEL requires creating a separate parent package in Fedora pkgdb. On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawskiwrote: > I have no idea if there is any interest in this or not. I managed to get > the > EPEL7 python34 package to build on EL6 with a few modifications. Is there > any > interest in supporting this? > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 http://www.nwra.com > > ___ > python-devel mailing list > python-de...@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@ > lists.fedoraproject.org > > ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 535 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 297 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 60 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e0c08a1414 php-PHPMailer-5.2.16-2.el7 16 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c redis-3.2.3-1.el7 14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2c0e0e64b2 python34-3.4.3-7.el7 14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b8dd3488d knot-1.6.8-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f0e09b5124 borgbackup-1.0.7-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-df8a00854a openvpn-2.3.12-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3 chicken-4.11.0-3.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4316d954e8 canl-c-2.1.7-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing canl-c-2.1.7-1.el7 chicken-4.11.0-3.el7 Details about builds: canl-c-2.1.7-1.el7 (FEDORA-EPEL-2016-4316d954e8) EMI Common Authentication library - bindings for C Update Information: This is a hotfix for proxy DN manipulation vulnerabilities. chicken-4.11.0-3.el7 (FEDORA-EPEL-2016-e8f4ff76b3) A practical and portable Scheme system Update Information: Security fix for CVE-2016-6830, CVE-2016-6831 References: [ 1 ] Bug #1369108 - CVE-2016-6830 CVE-2016-6831 chicken: Buffer overflow and a memory leak in the POSIX unit's procedures process-execute and process-spawn https://bugzilla.redhat.com/show_bug.cgi?id=1369108 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python34 for EPEL6
On 08/24/2016 11:38 PM, Orion Poplawski wrote: > I have no idea if there is any interest in this or not. I managed to get the > EPEL7 python34 package to build on EL6 with a few modifications. Is there any > interest in supporting this? > > > > ___ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org > Some software like BioPython will lose Python2.6 support in near future. Python34 support can be useful on epel6 provided that all related dependencies are available. -- --- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x6CE6D08A Check on https://keys.fedoraproject.org/ 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] Fedora EPEL 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 805 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-1626 puppet-2.7.26-1.el5 654 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849 sblim-sfcb-1.3.8-2.el5 297 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516 mcollective-2.8.4-1.el5 269 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6 thttpd-2.25b-24.el5 52 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c03e77f531 nginx-1.10.1-1.el5 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5475bf961d lcms2-2.8-2.el5 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-53ac7fc86d openvpn-2.3.12-1.el5 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f91c5f9cf4 canl-c-2.1.7-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing canl-c-2.1.7-1.el5 Details about builds: canl-c-2.1.7-1.el5 (FEDORA-EPEL-2016-f91c5f9cf4) EMI Common Authentication library - bindings for C Update Information: This is a hotfix for proxy DN manipulation vulnerabilities. This update contains also chain validation fixes from version 2.1.6. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 413 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031 python-virtualenv-12.0.7-1.el6 407 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 339 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156 nagios-4.0.8-1.el6 297 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 269 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9 thttpd-2.25b-24.el6 155 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813 vtun-3.0.1-10.el6 60 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-db7e78fac7 php-PHPMailer-5.2.16-2.el6 53 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d0e444c5f2 pypy-5.0.1-4.el6 52 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7a25f65890 nginx-1.10.1-1.el6 20 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bee6c8b3c9 mongodb-2.4.14-3.el6 16 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-3ff1f4485b tomcat-7.0.70-2.el6 14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a1450d7fe0 knot-1.6.8-1.el6 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5c15ca6d8d lcms2-2.8-2.el6 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-93210564dd openvpn-2.3.12-1.el6 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53 chicken-4.11.0-3.el6 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a9c6decf32 canl-c-2.1.7-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing canl-c-2.1.7-1.el6 chicken-4.11.0-3.el6 Details about builds: canl-c-2.1.7-1.el6 (FEDORA-EPEL-2016-a9c6decf32) EMI Common Authentication library - bindings for C Update Information: This is a hotfix for proxy DN manipulation vulnerabilities. chicken-4.11.0-3.el6 (FEDORA-EPEL-2016-8594ed3a53) A practical and portable Scheme system Update Information: Security fix for CVE-2016-6830, CVE-2016-6831 References: [ 1 ] Bug #1369108 - CVE-2016-6830 CVE-2016-6831 chicken: Buffer overflow and a memory leak in the POSIX unit's procedures process-execute and process-spawn https://bugzilla.redhat.com/show_bug.cgi?id=1369108 ___ 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
When I proposed importing gcc-5 to EPEL6 back in 04/2016 ( https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/ ) the response was an unequivocal no, EPEL does not install to /opt/ , so it dies right there. Now you are proposing the same ( devtoolset/scl installs to /opt except for the wrapper call) but using a scheme that is somewhat less convenient (In scl the binutils and gcc have to be coupled, and as noted the imported gcc suite is incomplete), much less frequent (the most updated version is gcc-5.2, while I maintain both gcc-5.x and gcc-6.1), and much less complete (I import everything but gcc-gnat, while devtoolset4 only has gcc,gcc-c++ and gcc-gfortran. No gcc-objc, no gcc-go, no cpp, and none of the libs (cilk, gccjit, atomic, asan etc...). I'm still building and maintaining both gcc and bintutils for my own purposes, which are based off of fc24 srpms, and with optionally gcc-c++ specs file hardcoded to use binutils tools at the new prefix so use of env-modules is not required. I'm just wandering why the different treatment - the automatic knee-jerk reaction of dismissal to a newbie proposal vs. accepting the exact same proposal (although wrapped so it's less convenient to use) when it comes from someone else. On 25/08//2016 06:59, Dave Johansen wrote: On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi> wrote: On Wed, 24 Aug 2016 16:43:31 -0600 Dave Johansen > wrote: > On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi > wrote: > > > On Tue, 23 Aug 2016 14:21:24 +0100 > > Karanbir Singh > wrote: > > > > > On 22/08/16 18:30, Jason L Tibbitts III wrote: > > > >> "DJ" == Dave Johansen > writes: > > > > > > > > DJ> devtoolset is designed to do all of this and is already > > > > DJ> done, so it seems that the only advantage to putting it in > > > > DJ> EPEL itself would be to reduce the number of repos during > > > > DJ> 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)? > > > > > > you should be able to 'yum install centos-release-scl' on a CentOS > > > Linux machine and get access to all the SCLs > > > > Yeah, but if we enable that for EPEL builds, we are going to get all > > SCLs right? So, people could start depending on them at runtime > > instead of just install time. > > > > I'm not opposed to devtoolset, but I don't think we want to allow > > runtime scls without actual scl guidelines. > > > > I seem to remember that Fedora didn't allow SCLs because there was > some compatibility problem or something of the sort. Do you know the > details or what the current state is? It's not a compatibility problem. It's lack of guidelines. > Also, RedHat has been pushing devtoolset pretty hard. The response to > a few bugzillas has even been "use devtoolset because the issue is > fixed there and we're not going to fix the system gcc/libc/etc". So > it seems like allowing SCLs in Fedora/EPEL makes sense and fits with > the direction of RHEL in general. As I noted, I'd probibly be for devtoolset because the guidelines would be pretty simple. Just do X Y and Z in your spec, build as normal and users wouldn't see any run time dep on it. It gets weird where other SCL's come in. Can your package require say postgresql from SCL instead of the rhel one? If so, would our users all be able to install that? What happens if two packages need different SCL versions? Can SCL's depend on each other? Can you make a package thats an SCL? we have no guidelines for that, and just saying "do whatever you want" is likely to cause mass confusion and make everyone miserable. I agree that how to handle SCLs can get really mess really fast, but a lot of projects are jumping on the "modern C++" bandwagon and allows devtoolset is low risk, easy to do and enables a lot of packages to be built with EPEL that otherwise wouldn't be. Basically, I think that figuring out how to handle SCLs is a long term issue that will take some serious work, but coming up with some simple policies that allow it to be used in EPEL is something that should be well within the realm of the possible. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org smime.p7s Description: S/MIME Cryptographic Signature ___