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

[Peter]

On 16/08/16 06:24, Tom Callaway wrote:
> I'd like to propose that we enable the Developer Toolset repo in EPEL
> and allow packages to depend on it. Thoughts?

There is one issue with this that I don't think others have addressed
yet on this list.  EPEL 6 supports i686 as a build target, but
devtoolset for el6 is available for x86_64 only, so it would cause
problems with i686 builds.


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

[Neal Gompa]

On Fri, Aug 26, 2016 at 6:24 PM, dani  wrote:
>
> I think it is high time to rethink the single version of a package policy,
> and come up with some scheme that would allow for any package to maintain
> multiple versions in a consistent manner.

We wouldn't even be the first distro to wind up discarding that
policy. Both openSUSE and Mandriva did the same many years ago. That
led to the restructuring of the packaging to the current form openSUSE
and Mageia have[1][2].

[1]: https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines
[2]: https://wiki.mageia.org/en/Libraries_policy



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: new DNF for everyone

[Orion Poplawski]

On 08/26/2016 12:26 PM, Sérgio Basto wrote:
> On Sex, 2016-07-01 at 13:04 -0400, Honza Šilhan wrote:
>> Hi,
>>
>> DNF is in EPEL for more than one year, unfortunately there was still
>> the old
>> DNF-0.6.4
>> version. Over that time in DNF were implemented a lot of great
>> features and
>> plenty of bugs
>> have been fixed. DNF (especially its libraries) could not be updated
>> in EPEL
>> repository
>> because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL
>> 7 and
>> CentOS 7 users
>> in our COPR repository [1].
>>
>> In order to install DNF follow the instructions here [2].
>>
> 
> Can't we add this to epel 7 for "Red Hat Enterprise Linux 7.3" 
> 
> dnf in epel it is a bit useless, it doesn't have copr plugin for
> example . 

This is the problem:

Available Packages
hawkey.x86_64  0.5.8-2.git.0.202b194.el7  rhel-7-server-rpms
hawkey.x86_64  0.6.3-4.el7rhel-7-server-beta-rpms
libsolv.x86_64 0.6.11-1.el7   rhel-7-server-rpms
libsolv.x86_64 0.6.20-5.el7   rhel-7-server-beta-rpms

libsolv.x86_64   0.6.20-4.el7.centos
group_rpm-software-management-dnf-stack-el7
hawkey.x86_64 0.6.3-4.el7.centos
group_rpm-software-management-dnf-stack-el7

But it does like it will be possible to update dnf in EPEL7 when EL7.3 comes
out with updated hawkey and libsolv.

-- 
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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: new DNF for everyone

[Sérgio Basto]

On Sex, 2016-07-01 at 13:04 -0400, Honza Šilhan wrote:
> Hi,
> 
> DNF is in EPEL for more than one year, unfortunately there was still
> the old
> DNF-0.6.4
> version. Over that time in DNF were implemented a lot of great
> features and
> plenty of bugs
> have been fixed. DNF (especially its libraries) could not be updated
> in EPEL
> repository
> because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL
> 7 and
> CentOS 7 users
> in our COPR repository [1].
> 
> In order to install DNF follow the instructions here [2].
> 

Can't we add this to epel 7 for "Red Hat Enterprise Linux 7.3" 

dnf in epel it is a bit useless, it doesn't have copr plugin for
example . 

> Honza
> 
> [1] https://copr.fedorainfracloud.org/coprs/g/rpm-software-management
> /dnf-stack-el7/
> [2] http://dnf.baseurl.org/2016/07/01/fresh-dnf-for-rhel-7-and-centos
> -7/
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedorapr
> oject.org
-- 
Sérgio M. B.

___
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 26 August 2016 at 12:58, Stephen John Smoogen  wrote:
> On 26 August 2016 at 06:00, Daniel Letai  wrote:
>>
>>
>> On 08/25/2016 11:40 PM, Kevin Fenzi wrote:
>>
>> 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 propose adding several gnu packages (namely gcc, binutils and gdb) with
>> versions following those supplied by fedora, specifically for epel6, but
>> possibly for epel7 if requested.
>>
>> This could hold a pattern such as /opt/gnu/[gcc|binutils|gdb]// to
>> allow several version to co-exist.
>> I don't have any co-maintainers, but I mainly get busy in my day job, which
>> happens to be the reason I maintain those packages.
>>
>
> OK there were multiple reasons there were reservations for this:
>
> 1) /opt/gnu (and many other /opt/*) names are already in use by many
> site admistrators. Putting our packages in there and over-writing
> locally compiled apps is going to cause problems. [Remember rpm will
> overwrite /opt/gnu/gcc/5.0/bin/gcc if it wasn't in the rpm db before
> hand without any report of a conflict.]

In reading some of the FESCO tickets, we can't use /opt/gnu because we
are not the GNU organization.
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html

We would need to use the /opt/fedora or go through the process of
becoming an entity that the LANANA.org people would recognize.


-- 
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: Fwd: [rhelv6-beta-list] Red Hat Enterprise Linux 7.3 Beta Now Available

[Orion Poplawski]

On 08/25/2016 07:35 PM, Stephen John Smoogen wrote:
> So the RHEL7.3 beta is now available for testing. Doing a simplified
> check of what packages I could find in centos-7.2 and beta 7.3 it
> looks like there are 220+ packages with version updates and maybe 60
> added packages.
> 
> NetworkManager-1.0.6
> NetworkManager-1.4.0
> NetworkManager-libreswan-1.0.6
> NetworkManager-libreswan-1.2.4
> 
> [some of these updates may already have been done through the
> quarterly as I didn't factor those in.]
> 
> Developers and testers please download and see if you run into any
> issues with EPEL.

Missed one more:

cpuid.x86_64 20151017-1.el7  epel
cpuid.x86_64 20151017-4.el7  rhel-7-server-beta-rpms

-- 
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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Fwd: [rhelv6-beta-list] Red Hat Enterprise Linux 7.3 Beta Now Available

[Orion Poplawski]

On 08/25/2016 07:35 PM, Stephen John Smoogen wrote:
> So the RHEL7.3 beta is now available for testing. Doing a simplified
> check of what packages I could find in centos-7.2 and beta 7.3 it
> looks like there are 220+ packages with version updates and maybe 60
> added packages.
> 
> NetworkManager-1.0.6
> NetworkManager-1.4.0
> NetworkManager-libreswan-1.0.6
> NetworkManager-libreswan-1.2.4
> 
> [some of these updates may already have been done through the
> quarterly as I didn't factor those in.]
> 
> Developers and testers please download and see if you run into any
> issues with EPEL.
> 
> Thank you.

Here's what I could find conflicting with EPEL:

copy-jdk-configs.noarch  1.2-1.el7   epel-testing
copy-jdk-configs.noarch  1.2-1.el7   rhel-7-server-beta-rpms

hsakmt.x86_641.0.0-6.el7 epel
hsakmt.x86_641.0.0-7.el7 rhel-7-server-beta-rpms

libnftnl.x86_64  1.0.6-1.el7 epel
libnftnl.x86_64  1.0.6-1.el7 rhel-7-server-beta-rpms

libpmem.x86_64   1.1-1.el7   epel
libpmem.x86_64   1.1-4.el7   rhel-7-server-beta-rpms
libpmemblk.x86_641.1-1.el7   epel
libpmemblk.x86_641.1-4.el7   rhel-7-server-beta-rpms
libpmemlog.x86_641.1-1.el7   epel
libpmemlog.x86_641.1-4.el7   rhel-7-server-beta-rpms
libpmemobj.x86_641.1-1.el7   epel
libpmemobj.x86_641.1-4.el7   rhel-7-server-beta-rpms
libpmempool.x86_64   1.1-1.el7   epel
libpmempool.x86_64   1.1-4.el7   rhel-7-server-beta-rpms
libvmem.x86_64   1.1-1.el7   epel
libvmem.x86_64   1.1-4.el7   rhel-7-server-beta-rpms
libvmmalloc.x86_64   1.1-1.el7   epel
libvmmalloc.x86_64   1.1-4.el7   rhel-7-server-beta-rpms
nvml-tools.x86_641.1-1.el7   epel
nvml-tools.x86_641.1-4.el7   rhel-7-server-beta-rpms

memkind.x86_64   1.1.0-1.el7 epel
memkind.x86_64   1.1.0-1.el7 rhel-7-server-beta-rpms

python-idna.noarch   2.0-1.el7   epel
python-idna.noarch   2.0-1.el7   rhel-7-server-beta-rpms

python-ipaddress.noarch  1.0.7-4.el7 epel
python-ipaddress.noarch  1.0.16-2.el7rhel-7-server-beta-rpms

python-netifaces.x86_64  0.5-4.el7   epel
python-netifaces.x86_64  0.10.4-3.el7rhel-7-server-beta-rpms

qt5-designer.x86_64  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-designer.x86_64  5.6.1-2.el7 epel
qt5-linguist.x86_64  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-linguist.x86_64  5.6.1-2.el7 epel
qt5-qdoc.x86_64  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qdoc.x86_64  5.6.1-2.el7 epel
qt5-qhelpgenerator.x86_645.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qhelpgenerator.x86_645.6.1-2.el7 epel
qt5-qt3d.i6865.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qt3d.x86_64  5.6.1-1.el7 epel
qt5-qt3d.x86_64  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qt3d-devel.i686  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qt3d-devel.x86_645.6.1-1.el7 epel
qt5-qt3d-devel.x86_645.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtbase.i686  5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase.x86_645.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase.x86_645.6.1-3.el7 epel
qt5-qtbase-common.noarch 5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-common.noarch 5.6.1-3.el7 epel
qt5-qtbase-devel.i6865.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-devel.x86_64  5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-devel.x86_64  5.6.1-3.el7 epel
qt5-qtbase-gui.i686  5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-gui.x86_645.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-gui.x86_645.6.1-3.el7 epel
qt5-qtbase-mysql.i6865.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-mysql.x86_64  5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-mysql.x86_64  5.6.1-3.el7 epel
qt5-qtbase-odbc.i686 5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-odbc.x86_64   5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-odbc.x86_64   5.6.1-3.el7 epel
qt5-qtbase-postgresql.i686   5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-postgresql.x86_64 5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-qtbase-postgresql.x86_64 5.6.1-3.el7 epel
qt5-qtcanvas3d.x86_645.6.1-1.el7 epel
qt5-qtcanvas3d.x86_645.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtconnectivity.i686  

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

[Kevin Fenzi]

On Thu, 25 Aug 2016 15:04:58 -0600
Dave Johansen  wrote:

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

Oh? thats good... I was understanding that they were all in a scl
repo/channel. 

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

Right. I would prefer the second one too, but we would still need some
automated detection that the packages no longer build. 

kevin


pgp90AftUBcgI.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: Upgrading Mono in Epel7

[Kevin Fenzi]

On Fri, 26 Aug 2016 07:24:33 +0200
Timotheus Pokorra  wrote:

> Hello,
> 
> Just to give a heads up: I am now working on this upgrade to Mono 4.2.
> I will build the mono package and the depending packages in a
> BuildRoot Override, and submit them for testing.
> They will sit in testing for a couple of months, and hopefully when
> CentOS 7.3 is released (October or November???) we can submit the
> updated packages to Epel7.
> Are there any problems with that plan?

Sounds reasonable to me. 

> I guess this is the Epel SIG?
> Would you want to discuss the bootstrap build of Mono in Epel7, and
> exception to the Epel Update Policy? Please let me know if I should
> attend the meeting on coming Wednesday, 18:00 UTC in #fedora-meeting.
> I would then try to be there.

If you like we can, but also we can just see if anyone thinks that is
needed. ;) IMHO your plan is fine. 

kevin



pgpm__l4ROaoS.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] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 414  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 408  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 340  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 298  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 270  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 156  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813   
vtun-3.0.1-10.el6
  61  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-db7e78fac7   
php-PHPMailer-5.2.16-2.el6
  54  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d0e444c5f2   
pypy-5.0.1-4.el6
  54  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7a25f65890   
nginx-1.10.1-1.el6
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bee6c8b3c9   
mongodb-2.4.14-3.el6
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-3ff1f4485b   
tomcat-7.0.70-2.el6
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a1450d7fe0   
knot-1.6.8-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5c15ca6d8d   
lcms2-2.8-2.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-93210564dd   
openvpn-2.3.12-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
   1  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

golang-gopkg-yaml-1-14.el6
opensc-0.14.0-2.el6
vmtouch-1.1.0-1.el6

Details about builds:



 golang-gopkg-yaml-1-14.el6 (FEDORA-EPEL-2016-b2e68882ec)
 Enables Go programs to comfortably encode and decode YAML values

Update Information:

Enable devel and unit-test for epel7

References:

  [ 1 ] Bug #1250524 - Tracker for golang-gopkg-yaml
https://bugzilla.redhat.com/show_bug.cgi?id=1250524




 opensc-0.14.0-2.el6 (FEDORA-EPEL-2016-bb99a95b7b)
 Smart card library and applications

Update Information:

Update to 0.14 with the patches from RHEL7 (#1367907)

References:

  [ 1 ] Bug #1367907 - [RFE] rebase opensc to newer version
https://bugzilla.redhat.com/show_bug.cgi?id=1367907




 vmtouch-1.1.0-1.el6 (FEDORA-EPEL-2016-0efb8c579c)
 Portable file system cache diagnostics and control

Update Information:

Update to 1.1.0.

References:

  [ 1 ] Bug #1288680 - vmtouch-v1.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1288680

___
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

[Daniel Letai]

On 08/25/2016 11:40 PM, Kevin Fenzi wrote:

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 propose adding several gnu packages (namely gcc, binutils and gdb) 
with versions following those supplied by fedora, specifically for 
epel6, but possibly for epel7 if requested.


This could hold a pattern such as /opt/gnu/[gcc|binutils|gdb]// 
to allow several version to co-exist.
I don't have any co-maintainers, but I mainly get busy in my day job, 
which happens to be the reason I maintain those packages.


I propose importing fc24 packages as and when they become available, 
maintaining the exact same packages - so gcc6.1 srpm would create the 
entire suite* of rpms currently available on fc24.


My current scheme is relying on environment modules to "switch" between 
versions - each installation of course creates and installs the modules 
file which also maintains dependencies - binutils >= 2.24 must be loaded 
prior to loading gcc6 etc.


(*) I have no experience building and packaging gcc-gnat, so not quite 
the entire suite, but I could probably learn to build that too.




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



___
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] Orphaned Packages in epel7 (2016-08-26)

[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)maintainers   Status Change 
===
and orphan, s4504kr   3 weeks ago   
bashdb  orphan, roma  14 weeks ago  
bcfg2   orphan, fab, solj, zultron6 weeks ago   
bouncycastle-mail   orphan, s4504kr   3 weeks ago   
dbmail  orphan, bjohnson  8 weeks ago   
dwatch  orphan, bjohnson  8 weeks ago   
js-jquery-migrate   orphan, group::nodejs-sig, jamielinux,3 weeks ago   
patches 
libsieveorphan, bjohnson  8 weeks ago   
libupnp orphan, cicku, mcepl  25 weeks ago  
libzdb  orphan, bjohnson, cicku   8 weeks ago   
netmonitor  orphan, fab   6 weeks ago   
ola orphan, daveo 14 weeks ago  
polipo  orphan, bjohnson  8 weeks ago   
python-keyring  orphan, cicku, rtnpro 25 weeks ago  
queuegraph  orphan, bjohnson  8 weeks ago   
radiusclient-ng orphan, nmav  5 weeks ago   
rubygem-stomp   orphan, stevetraylen  19 weeks ago  
snobol  orphan, s4504kr   3 weeks ago   
sphinx  orphan, cdamian, gbcox, skottler  20 weeks ago  
suckorphan, s4504kr   3 weeks ago   
thttpd  orphan, fab   6 weeks ago   
tmdaorphan, bjohnson  8 weeks ago   

The following packages require above mentioned packages:
Depending on: libupnp (1), status change: 2016-02-26 (25 weeks ago)
kf5-solid (maintained by: dvratil)
kf5-solid-5.24.0-1.el7.src requires libupnp-devel = 1.6.19-2.el7


Depending on: python-keyring (2), status change: 2016-02-26 (25 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, stardust85)
python-wheel-0.24.0-2.el7.src requires python-keyring = 
5.0-1.el7


Depending on: radiusclient-ng (6), status change: 2016-07-21 (5 weeks ago)
nagios-plugins (maintained by: nb, kmf, mhayden, ondrejj, swilkerson)
nagios-plugins-2.0.3-3.el7.src requires radiusclient-ng-devel = 
0.5.6-9.el7
nagios-plugins-radius-2.0.3-3.el7.x86_64 requires 
libradiusclient-ng.so.2()(64bit)

opensips (maintained by: peter, ivaxer)
opensips-1.10.5-3.el7.src requires radiusclient-ng-devel = 
0.5.6-9.el7
opensips-aaa_radius-1.10.5-3.el7.x86_64 requires 
libradiusclient-ng.so.2()(64bit)

nagios-plugins-check-updates (maintained by: jpo)
nagios-plugins-check-updates-1.6.16-1.el7.x86_64 requires 
nagios-plugins = 2.0.3-3.el7

nagios-plugins-lcgdm (maintained by: aalvarez, andreamanzi)
nagios-plugins-lcgdm-common-0.9.6-1.el7.x86_64 requires 
nagios-plugins(x86-64) = 2.0.3-3.el7, nrpe(x86-64) = 2.15-7.el7

nrpe (maintained by: nb, jpo, kmf, mhayden, ondrejj, skottler, 
swilkerson)
nagios-plugins-nrpe-2.15-7.el7.x86_64 requires nagios-plugins = 
2.0.3-3.el7

nordugrid-arc-nagios-plugins (maintained by: ellert, jonkni)
nordugrid-arc-nagios-plugins-1.8.4-3.el7.x86_64 requires 
nagios-plugins = 2.0.3-3.el7


Depending on: rubygem-stomp (1), status change: 2016-04-14 (19 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 (20 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 

[EPEL-devel] Orphaned Packages in epel6 (2016-08-26)

[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)maintainers   Status Change 
===
YafaRay orphan, roma  14 weeks ago  
apcupsd orphan, mhlavink  9 weeks ago   
avraorphan, musolinoa 4 weeks ago   
bashdb  orphan, roma  14 weeks ago  
bcfg2   orphan, fab, solj, zultron6 weeks ago   
blender orphan, hobbes1069, s4504kr   3 weeks ago   
bouncycastle-mail   orphan, s4504kr   3 weeks ago   
bouncycastle-tsporphan, s4504kr   3 weeks ago   
cinepaint   orphan11 weeks ago  
dbmail  orphan, bjohnson  8 weeks ago   
dinotrace   orphan, chitlesh  46 weeks ago  
directfborphan, kwizart, thias47 weeks ago  
dom4j   orphan, s4504kr   3 weeks ago   
dwatch  orphan, bjohnson  8 weeks ago   
electronics-menuorphan, chitlesh  46 weeks ago  
glpiorphan, remi, trasher 4 weeks ago   
glpi-data-injection orphan, remi, rjt 4 weeks ago   
glpi-mass-ocs-importorphan, remi  4 weeks ago   
glpi-pdforphan, remi  4 weeks ago   
gmime   orphan, alexl, bjohnson,  8 weeks ago   
caillon, caolanm, group::gnome- 
sig, hadess, johnp, mbarnes,
rhughes, rstrode, ssp, xiphmont 
gnucap  orphan, chitlesh  46 weeks ago  
gnustep-backorphan, s4504kr   3 weeks ago   
gnustep-examplesorphan, s4504kr   3 weeks ago   
gnustep-gui orphan, s4504kr   3 weeks ago   
gormorphan, s4504kr   3 weeks ago   
gtkwhiteboard   orphan, roma  14 weeks ago  
hiredis orphan, cicku 25 weeks ago  
icu4j   orphan, s4504kr   3 weeks ago   
inadyn  orphan, s4504kr   3 weeks ago   
isorelaxorphan, s4504kr   3 weeks ago   
itext   orphan, s4504kr   3 weeks ago   
iverilogorphan, chitlesh  46 weeks ago  
jaxen-bootstrap orphan, s4504kr   3 weeks ago   
js-jquery-migrate   orphan, group::nodejs-sig,3 weeks ago   
jamielinux, patches 
js-sizzle   orphan, group::nodejs-sig,3 weeks ago   
jamielinux, patches 
kyumorphan, s4504kr   3 weeks ago   
libXaw3dXft orphan, roma  14 weeks ago  
libsieveorphan, bjohnson  8 weeks ago   
libzdb  orphan, bjohnson  8 weeks ago   
mingw32-tk  orphan, roma  14 weeks ago  
msp430-binutils orphan, rspanton, swhiteho7 weeks ago   
msp430-gcc  orphan, rspanton, swhiteho7 weeks ago   
msp430-libc orphan, rspanton  7 weeks ago   
msp430mcu   orphan, rspanton  7 weeks ago   
mspdebugorphan, rspanton  7 weeks ago   
msv orphan, s4504kr   3 weeks ago   
ode orphan, s4504kr   3 weeks ago   
ola orphan, daveo 14 weeks ago  
partimage   orphan, roma  14 weeks ago  
phpMemcachedAdmin   orphan9 weeks ago   
picprog