[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[Dave Johansen]

On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenzi  wrote:

> 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

[Kevin Fenzi]

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. ;) 

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

[Kevin Fenzi]

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. 

> 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

[Stephen John Smoogen]

On 25 August 2016 at 12:49, Stephen John Smoogen  wrote:
> 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

[Stephen John Smoogen]

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.




-- 
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

[Stephen John Smoogen]

On 24 August 2016 at 23: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.

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

[Rich Megginson]

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

[Matthias Runge]

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

[Tomas Orsava]

On 08/24/2016 11:39 PM, Neal Gompa wrote:

On Wed, Aug 24, 2016 at 5: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?


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

[Avram Lubkin]

On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts III 
wrote:

>
> 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

[Avram Lubkin]

>
> 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

[Avram Lubkin]

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 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?
>
> --
> 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

[updates]

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

[Antonio Trande]

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

[updates]

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

[updates]

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

[dani]

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
___