[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 263  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6828   
chicken-4.9.0.1-4.el6
 245  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 239  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 170  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8148   
optipng-0.7.5-5.el6
 170  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 129  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 101  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-00c45982f6   
drupal6-6.38-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6e0c318d91   
libssh-0.5.5-5.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6a812bd682   
drupal7-7.43-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-78096a43d9   
php-htmLawed-1.1.21-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b14579b3db   
websvn-2.3.3-12.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

gfal2-2.11.0-1.el6
gfal2-util-1.3.2-1.el6
gtk-gnutella-1.1.9-1.el6
libabigail-1.0-0.rc3.2.el6
libarchive3-3.1.2-1.el6
miniz-1.15-4.r4.el6
mock-1.2.16-1.el6
php-horde-Horde-Core-2.23.0-1.el6
php-horde-Horde-Crypt-2.7.1-1.el6
php-horde-Horde-Form-2.0.13-1.el6
php-horde-Horde-JavascriptMinify-1.1.3-1.el6
php-horde-Horde-Prefs-2.7.6-1.el6
rubygem-sequel-4.32.0-1.el6

Details about builds:



 gfal2-2.11.0-1.el6 (FEDORA-EPEL-2016-30905fbfb6)
 Grid file access library 2.0

Update Information:

New upstream release 2.11.0




 gfal2-util-1.3.2-1.el6 (FEDORA-EPEL-2016-627dc7aeba)
 GFAL2 utility tools

Update Information:

New upstream release 1.3.2




 gtk-gnutella-1.1.9-1.el6 (FEDORA-EPEL-2016-caf00f1a74)
 GUI based Gnutella Client

Update Information:

Update to 1.1.9    Update to 1.1.8

References:

  [ 1 ] Bug #1300181 - [abrt] gtk-gnutella: crash_handler(): gtk-gnutella 
killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1300181




 libabigail-1.0-0.rc3.2.el6 (FEDORA-EPEL-2016-c0cf4b9bc1)
 Set of ABI analysis tools

Update Information:

Bug and scalibility fixes

References:

  [ 1 ] Bug #1315204 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1315204
  [ 2 ] Bug #1311105 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1311105
  [ 3 ] Bug #1309400 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1309400




 libarchive3-3.1.2-1.el6 (FEDORA-EPEL-2016-a82c466e38)
 A library for handling streaming archive formats

Update Information:

initial epel-release

References:

  [ 1 ] Bug #1315307 - Review Request: libarchive3 - A library for handling 
streaming archive formats
https://bugzilla.redhat.com/show_bug.cgi?id=1315307




 miniz-1.15-4.r4.el6 (FEDORA-EPEL-2016-aa9b90269c)
 Compression library implementing the zlib and Deflate

Update Information:

This release corrects miniz-devel dependency on standard library header files.

[EPEL-devel] Re: EPEL Meeting 2016-03-08

[Matthias Runge]

On 09/03/16 20:33, Kevin Fenzi wrote:

>>  -b- We re-review Django14 and put it in. However there are 4+
>> security problems which can't be fixed without a major version move.
>> Because of this , the package may not pass review.

Because it has been retired upstream, I'm not sure if anyone really
looked at that, if there are 2 or really 4 security issues. The most
recent two might have fixes to be even backportable.

For reference, the request for re-review
is here: https://bugzilla.redhat.com/show_bug.cgi?id=1316068
> 
> We actually don't need to review it... if it's been retired less than 2
> weeks, we can just unretire it. We do need someone(s) to take over
> point of contact though. 
> 
> I guess I could do it, but is anyone else willing first? :) 

Actually, I made the mistake and did not retire it in f22-f24; it
doesn't make sense there at all. Could we consider the package as not
being retired at all?

Once the EPEL6 situation is solved, I should retire it on the previously
named branches.
> 
>>  -c- We skip re-review in this case and put the package back in. We do
>> so with an explicite end of life of 180 days (or 7.3 if that is
>> sooner) with either -a- happening or a python27 is packaged AND a
>> django 1.8 AND the packages requiring 1.4 are updated to 1.8.
> 
> Yeah, a time limit might be nice, but not sure how long all the various
> projects need + how long it will take to bring up a python27 + django1.8
> 
> Are any folks willing to work on this?
> 

Bringing in python2.7 and Django-1.8 would be the safest bet (in terms
of future stability), but that requires a bit of work, and just bringing
in python2.7 and Django-1.8 is the smallest portion here.

Matthias
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Standing down from EPSCo

[Stephen John Smoogen]

On 9 March 2016 at 09:43, Dennis Gilmore  wrote:
> Hi All,
>
> Effective immediately I am stepping down from EPSCo, I am unable to give it
> the time it deserves. There is just too much going on in Fedora. I will gladly
> help and guide people to get involved in making process changes in how we ship
> EPEL, or adding a faster stream, or whatever gets decided upon.
>

Dennis thank you for your time and effort over the many years.

 At today's meeting I will look for a replacement for your seat on the
steering committee and we will work from there on what we can do.

> Regards
>
> Dennis
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Standing down from EPSCo

[Dennis Gilmore]

Hi All,

Effective immediately I am stepping down from EPSCo, I am unable to give it 
the time it deserves. There is just too much going on in Fedora. I will gladly 
help and guide people to get involved in making process changes in how we ship 
EPEL, or adding a faster stream, or whatever gets decided upon. 

Regards

Dennis

signature.asc
Description: This is a digitally signed message part.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Django in EPEL6

[Stephen John Smoogen]

On 9 March 2016 at 02:58, Matthias Runge  wrote:
> On 08/03/16 18:55, Orion Poplawski wrote:
>> On 03/08/2016 10:42 AM, Brian Bouterse wrote:
>>> This removal has been problematic for a lot of software including
>>> the listed EPEL dependencies and anything those depend on. I
>>> propose the following be done:
>>>
>>> - Temporarily un-retire Django14 in EPEL6, and allow a planned
>>> sunset after some period of time. It would not receive updates
>>> during this time since upstream Django deprecated it already.
>>>
>>> - Add python-django[0] from EPEL7 (python-django-1.6.11-5.el7) to
>>> EPEL6 in a way that has allows some time overlap with Django14
>>> being also available. During that time other packages can switch to
>>> using python-django gracefully. This should be feasible because
>>> Django 1.6 is the last Django Y release which will run on Python
>>> 2.6 making it feasible to run on EL6.
>>>
>>> Other ideas or suggestions are welcome.
>>>
>>> [0]:
>>> https://admin.fedoraproject.org/pkgdb/package/rpms/python-django/
>>>
>>> -Brian
>>
>> With the relatively fast moving nature of django, I'm wondering if
>> any django package in EPEL should be unversioned.  It seems like we
>> should have python-djangoXX instead.  Although I have no idea how
>> easy it is to implement that.
>>
>> Also, while Matthias has issued an update recently for 1.6 in EPEL7,
>> it looks like its days are numbered as upstream has dropped it as
>> well: https://www.djangoproject.com/download/
>>
>> Hopefully Matthias will chime in with his thoughts.
>>
>
> Hello,
>
> I'm very sorry about this, and I should have communicated at all.
>
> Upstream django releases about every 9 months a new release, they're
> announcing deprecations as soon as they know in advance, leaving enough
> time to adapt. Unfortunately, there are downstreams struggling with the
> speed of development.
>
> So, matter of fact is, Django version 1.4 was the last LTS version being
> able to run on python-2.6.
>
> I had to make a cut here, since there were discovered 4 security issues
> in later django versions. Django-1.4.x was out of support by upstream
> already, thus, nobody really looked at that, if it's vulnerable.
>
> I wouldn't really consider Django-1.6 to be an alternative here, that
> was being deprecated around 9 months before Django-1.4. I may be
> stopping support on Django-1.6 in the near future. For epel7, the better
> candidate for LTS is Django-1.8.
>
> Speaking of python-djangoxx: I have been there, it's a pain as well. And
> that will eventually let the packet space explode, i.e you would have to
> have something like python26-django14-tagging (or whatever).
>
> Situation is not ideal anyways.
>
> My proposal would be, to un-retire Django14 for EPEL6.
>
> Looking at the long list of (now broken) dependencies, I would expect
> lots of leaf packages, living there because someone thought it'd be nice
> to have it. But, in fact, one should seriously think to retire those
> packages.


OK from what I can tell, we are going to need a python27 for EL6 (and
possibly EL5). Can the groups that need django and other later python
toolkits help out on the work required to do this?



-- 
Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org