[EPEL-devel] Re: Orphaned Packages in epel7 (2016-11-01)

[Christopher]

On Tue, Nov 1, 2016 at 3:00 PM  wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
>
Taking python-keyring[epel7], because I use it and want it maintained. I
have no experience with the package, though, so if another wants it, I'll
gladly hand it over as soon as they step up.

Also, after taking a package, how does one check to see if all of its
dependencies are in a good state? (non-orphaned)

Aside from these emails for passive notification, is there a way to get a
smaller, personalized report, like on pkgdb, about a specific package's
dependencies? Or a particular user's packages' dependencies?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: MongoDB in EPEL7

[Tom Boutell]

Stephen, good question... I was looking here:

https://www.softwarecollections.org/en/scls/rhscl/rh-mongodb26/

Which came up first in Google for rhsc mongodb, but that's not right. I should 
have been looking here:

https://access.redhat.com/support/policy/updates/rhscl

The Software Collections pages are so much more SEO-friendly it's not 
surprising I wound up in the wrong place.

OK, so does this "RHSC will maintain 2.6 until October 2018" policy mean that 
it's reasonable to expect the EPEL package to just leverage that work and keep 
on trucking until then?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Orphaned Packages in epel7 (2016-11-01)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

   Package   (co)maintainersStatus Change 
=
dansguardian orphan, cicku, heffer, steve   5 weeks ago   
firehol  orphan, cicku, error   1 weeks ago   
ipsilon  orphan, puiterwijk, simo   7 weeks ago   
python-keyring   orphan, cicku, rtnpro  35 weeks ago  
rubygem-stomporphan, stevetraylen   28 weeks ago  
sphinx   orphan, cdamian, gbcox, skottler   30 weeks ago  

The following packages require above mentioned packages:
Depending on: python-keyring (3), status change: 2016-02-26 (35 weeks ago)
bugwarrior (maintained by: ralph)
bugwarrior-1.4.0-1.el7.noarch requires python-keyring = 
5.0-1.el7
bugwarrior-1.4.0-1.el7.src requires python-keyring = 5.0-1.el7

python-wheel (maintained by: fschwarz)
python-wheel-0.24.0-2.el7.src requires python-keyring = 
5.0-1.el7

python-boto3 (maintained by: fale)
python-boto3-1.4.0-1.el7.src requires python-wheel = 
0.24.0-2.el7

Depending on: rubygem-stomp (1), status change: 2016-04-14 (28 weeks ago)
mcollective (maintained by: maxamillion)
mcollective-common-2.5.2-1.el7.noarch requires rubygem(stomp) = 
1.3.5

Depending on: sphinx (7), status change: 2016-04-04 (30 weeks ago)
gnuradio (maintained by: jskarvad)
gnuradio-3.7.5.1-2.el7.src requires sphinx = 2.1.5-2.el7

php-pecl-sphinx (maintained by: remi)
php-pecl-sphinx-1.3.2-1.el7.src requires libsphinxclient-devel 
= 2.1.5-2.el7
php-pecl-sphinx-1.3.2-1.el7.x86_64 requires 
libsphinxclient-0.0.1.so()(64bit)

gqrx (maintained by: bressers, daveo, jskarvad)
gqrx-2.3.2-4.el7.x86_64 requires 
libgnuradio-analog-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-blocks-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-fft-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-filter-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-pmt-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-runtime-3.7.5.1.so.0.0.0()(64bit)

gr-fcdproplus (maintained by: jskarvad)
gr-fcdproplus-0-0.7.20140920git1edbe523.el7.x86_64 requires 
libgnuradio-audio-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-blocks-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-runtime-3.7.5.1.so.0.0.0()(64bit)

gr-iqbal (maintained by: jskarvad)
gr-iqbal-0.37.2-3.el7.x86_64 requires 
libgnuradio-pmt-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-runtime-3.7.5.1.so.0.0.0()(64bit)

gr-osmosdr (maintained by: jskarvad)
gr-osmosdr-0.1.3-1.20141023git42c66fdd.el7.x86_64 requires 
libgnuradio-blocks-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-fcd-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-pmt-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-runtime-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-uhd-3.7.5.1.so.0.0.0()(64bit)

gr-rds (maintained by: sharkcz, jskarvad)
gr-rds-0-0.4.20141117gitff1ca15.el7.x86_64 requires 
libgnuradio-pmt-3.7.5.1.so.0.0.0()(64bit), 
libgnuradio-runtime-3.7.5.1.so.0.0.0()(64bit)

Affected (co)maintainers
bressers: sphinx
cdamian: sphinx
cicku: firehol, python-keyring, dansguardian
daveo: sphinx
error: firehol
fale: python-keyring
fschwarz: python-keyring
gbcox: sphinx
heffer: dansguardian
jskarvad: sphinx
maxamillion: rubygem-stomp
puiterwijk: ipsilon
ralph: python-keyring
remi: sphinx
rtnpro: python-keyring
sharkcz: sphinx
simo: ipsilon
skottler: sphinx
steve: dansguardian
stevetraylen: rubygem-stomp

Orphans (6): dansguardian firehol ipsilon python-keyring rubygem-stomp
sphinx


Orphans (dependend on) (3): python-keyring rubygem-stomp sphinx


Orphans (epel7) for at least 6 weeks (dependend on) (3):
python-keyring rubygem-stomp sphinx


Orphans  (epel7)(not depended on) (3): dansguardian firehol ipsilon


Orphans (epel7) for at least 6 weeks (not dependend on) (1): ipsilon


Depending packages (epel7) (11): bugwarrior gnuradio gqrx
gr-fcdproplus gr-iqbal gr-osmosdr gr-rds mcollective
php-pecl-sphinx python-boto3 python-wheel


Packages depending on packages orphaned (epel7) for more than 6 weeks
(11): bugwarrior gnuradio gqrx gr-fcdproplus gr-iqbal gr-osmosdr
gr-rds mcollective php-pecl-sphinx python-boto3 python-wheel


Not found in repo (epel7) (2): dansguardian ipsilon

-- 
The 

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

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 723  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 366  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 337  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5


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

python-dirq-1.7.1-1.el5

Details about builds:



 python-dirq-1.7.1-1.el5 (FEDORA-EPEL-2016-9664a5cf13)
 Directory based queue

Update Information:

Updated from upstream.

References:

  [ 1 ] Bug #1389920 - python-dirq-v1.7.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1389920

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: MongoDB in EPEL7

[Stephen John Smoogen]

On 1 November 2016 at 13:32, Tom Boutell  wrote:
> I think that if a CVE arrives that we can't easily address through a patch, 
> we have to be prepared to force an upgrade. Potentially "abandoning" a 
> package that has CVEs in the wild, in the hope people will read about an 
> optional upgrade, sounds like a policy we could regret.
>
> Is there any history of EPEL just abandoning a package? What should happen in 
> that situation? Perhaps it's been necessary at some point (no support 
> upstream, no one available downstream either...).

There is an incredibly long history of EPEL abandoning packages for
the above reasons all the time. It has been done pretty much from the
get-go. The standard practice has been that when a package no longer
is workable that it is withdrawn.

Yes it sucks all around but in many cases this is the path that has been taken.


> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 482  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 476  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 407  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 366  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 337  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 223  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813   
vtun-3.0.1-10.el6
  68  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  40  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-25e30f6dc3   
jansson-2.9-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2f6f1435ed   
tor-0.2.8.9-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a886ace670   
tomcat-7.0.72-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb5398893b   
nodejs-0.10.48-3.el6


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

lighttpd-1.4.43-1.el6
python-dirq-1.7.1-1.el6

Details about builds:



 lighttpd-1.4.43-1.el6 (FEDORA-EPEL-2016-b7f4c3c75e)
 Lightning fast webserver with light system requirements

Update Information:

1.4.43    Split out mysql and gssapi authn modules.    1.4.42, now with
upstream mod_geoip.

References:

  [ 1 ] Bug #1385640 - lighttpd-1.4.42 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1385640




 python-dirq-1.7.1-1.el6 (FEDORA-EPEL-2016-0814b4f2af)
 Directory based queue

Update Information:

Updated from upstream.

References:

  [ 1 ] Bug #1389920 - python-dirq-v1.7.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1389920

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 603  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 366  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  84  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  68  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-03fb3c1531   
banshee-2.6.2-11.el7 dbus-sharp-0.7.0-15.el7 dbus-sharp-glib-0.5.0-13.el7 
gdata-sharp-1.4.0.2-18.el7 gio-sharp-0.3-14.el7 gkeyfile-sharp-0.1-19.el7 
gnome-sharp-2.24.2-12.el7 gtk-sharp-beans-2.14.0-17.el7 
gtk-sharp2-2.12.26-3.el7 gtk-sharp3-2.99.3-16.el7 gudev-sharp-0.1-18.el7 
libappindicator-12.10.0-11.el7 libgpod-0.8.3-14.el7 libyui-bindings-1.1.0-7.el7 
mono-4.2.4-7.el7 mono-addins-1.1-3.el7 mono-cecil-0.9.6-6.el7 
mono-zeroconf-0.9.0-16.el7 notify-sharp-0.4.0-0.26.20100411svn.el7 
notify-sharp3-3.0.3-2.el7 nunit-3.5-1.el7 nunit2-2.6.4-14.el7 pinta-1.6-5.el7 
taglib-sharp-2.1.0.0-3.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f0f6483aa7   
tor-0.2.8.9-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2fcbc39837   
chromium-54.0.2840.71-1.el7


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

FoXlibf-4.1.2-5.el7
bodhi-2.3.1-2.el7
borgbackup-1.0.8-2.el7
lighttpd-1.4.43-1.el7
python-dirq-1.7.1-1.el7
python-fedmsg-atomic-composer-2016.3-1.el7
python-line_profiler-2.0-1.el7
rubygem-multi_xml-0.5.5-5.el7
scorep-1.4.2-7.el7
tinc-1.0.30-1.el7

Details about builds:



 FoXlibf-4.1.2-5.el7 (FEDORA-EPEL-2016-bbe070a2be)
 A Fortran XML Library

Update Information:

Rebuilt for new gcc-gfortran on el7




 bodhi-2.3.1-2.el7 (FEDORA-EPEL-2016-cd060eeb3c)
 A modular framework that facilitates publishing software updates

Update Information:

Update python-fedmsg-atomic-composer to [2016.3](https://github.com/fedora-infra
/fedmsg-atomic-composer/releases/tag/2016.3) and bodhi to
[2.3.0](https://github.com/fedora-infra/bodhi/releases/tag/2.3.0).  Update bodhi
to [2.3.1](https://github.com/fedora-infra/bodhi/releases/tag/2.3.1).

References:

  [ 1 ] Bug #1389519 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1389519




 borgbackup-1.0.8-2.el7 (FEDORA-EPEL-2016-01814b2db1)
 A deduplicating backup program with compression and authenticated encryption

Update Information:

upstream version 1.0.8 (BZ#1389986)

References:

  [ 1 ] Bug #1389986 - borgbackup 1.0.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1389986




 lighttpd-1.4.43-1.el7 (FEDORA-EPEL-2016-25f309613f)
 Lightning fast webserver with light system requirements

Update Information:

1.4.43    Split out mysql and gssapi authn modules.    1.4.42, now with
upstream mod_geoip.

References:

  [ 1 ] Bug #1385640 - lighttpd-1.4.42 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1385640




 python-dirq-1.7.1-1.el7 (FEDORA-EPEL-2016-65e3d15e2b)
 Directory based queue

Update Information:

Updated from upstream.

References:

  [ 1 ] Bug #1389920 - python-dirq-v1.7.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1389920

[EPEL-devel] Re: MongoDB in EPEL7

[Stephen John Smoogen]

On 1 November 2016 at 13:33, Tom Boutell  wrote:
> Sorry, I just saw the part about RHSCL. But that page says:
>
> "Community Project: Maintained by upstream communities of developers. The 
> software is cared for, but the developers make no commitments to update the 
> repositories in a timely manner."
>

Do you have a link to that? There is softwarecollections.org which is
the equivalent to EPEL. There is Red Hat Software Collections which is
not a community product but a paid for serivce from Red Hat.

> S... is there actually a commitment from Red Hat to patch that at all now 
> that the upstream is done with it? Are you the upstream they are referring 
> to? (:
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: MongoDB in EPEL7

[Tom Boutell]

Sorry, I just saw the part about RHSCL. But that page says:

"Community Project: Maintained by upstream communities of developers. The 
software is cared for, but the developers make no commitments to update the 
repositories in a timely manner."

S... is there actually a commitment from Red Hat to patch that at all now 
that the upstream is done with it? Are you the upstream they are referring to? 
(:
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: MongoDB in EPEL7

[Tom Boutell]

I think that if a CVE arrives that we can't easily address through a patch, we 
have to be prepared to force an upgrade. Potentially "abandoning" a package 
that has CVEs in the wild, in the hope people will read about an optional 
upgrade, sounds like a policy we could regret.

Is there any history of EPEL just abandoning a package? What should happen in 
that situation? Perhaps it's been necessary at some point (no support upstream, 
no one available downstream either...).
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Removing Django from EL6/7

[Stephen John Smoogen]

tl;dr Web apps and frameworks are horrible for EPEL because they
'innovate' so quickly compared to multi-year support paths


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: MongoDB in EPEL7

[Marek Skalický]

To note, I've forgotten that MongoDB 2.6 is in RHSCL, so it should be supported 
till April 2018.

Also I have no problem to backport easy fixes for EPEL6 too, but if problem is 
harder and it is not possible create relatively small patch, I can't manage big 
patches.

Could some user want to still use old 2.6 version?

How much to care about EPEL6? RHEL6 is in Production 2 phase... so no software 
enhancements. What is EPEL policy?

Other option how to provide newer versions of MongoDB could be to prepare copr 
repositories witch each version. One pros for this option could be easier 
managing newer dependencies (I am afraid that newer versions requires packages 
that are not in EPEL - and adding new version specific packages to Fedora/EPEL 
requires package review... so it is harder:-).

So other option how to solve this:
Try to prepare copr repositories for each version to allow users to easily 
install and use new version. Keep 2.4 and 2.6 in EPEL6/7 and backport CVE fixes 
(it seems to me, that is not so often in MongoDB). And if some CVE appear that 
would not be so easy to fix (rewrite a lot of code), do upgrade to newer 
versions (~ build packages from copr in EPEL).

Does someone know if there is some EPEL guideline which describes what is 
better solution?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org