Orphaned Packages in epel7 (2016-11-01)

[Till Maas]

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 
=================================================================
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-stomp    orphan, 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 script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py

[Christopher]

On Tue, Nov 1, 2016 at 3:00 PM <opensource(a)till.name&gt; 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?

[Jason L Tibbitts III]

> >>>> "C" == Christopher 
> <ctubbsii(a)fedoraproject.org&gt; writes: 
C> Also, after taking a package, how does one check to see if all of its
C> dependencies are in a good state? (non-orphaned)

Get the list of dependencies (with repoquery or "dnf repoquery" or
inspection of the spec.  Then look them up in pkgdb.  You can do those
lookups from the command line if you like using pkdgb-cli:

  pkgdb-cli acl python-keyring epel7

(the branch names are el5, el6 and epel7 for historical reasons)

Will show you the four current maintainers of python-keyring in EPEL7.
Or you can make an API call and handle the returned json as you wish, if
you want to write something.

C> Aside from these emails for passive notification, is there a way to
C> get a smaller, personalized report, like on pkgdb, about a specific
C> package's dependencies?

pkgdb doesn't track dependencies, so all you can do is ask it about the
status of a particular package.  You'll need to get the dependencies
from the package manager.

C> Or a particular user's packages' dependencies?

That's just extracting from pkgdb the list of packages to which a user
has commit access (assuming commit access is what you want) and then
looking at that package in a loop.

 - J<

[Christopher]

On Wed, Nov 2, 2016 at 3:23 PM Jason L Tibbitts III <tibbs(a)math.uh.edu&gt;
wrote:

>  >>>>> "C" == Christopher 
> <ctubbsii(a)fedoraproject.org&gt; writes:
>
>  C> Also, after taking a package, how does one check to see if all of its
>  C> dependencies are in a good state? (non-orphaned)
>
>  Get the list of dependencies (with repoquery or "dnf repoquery" or
>  inspection of the spec.  Then look them up in pkgdb.  You can do those
>  lookups from the command line if you like using pkdgb-cli:
>
>    pkgdb-cli acl python-keyring epel7
>
>  (the branch names are el5, el6 and epel7 for historical reasons)
>
>  Will show you the four current maintainers of python-keyring in EPEL7.
>  Or you can make an API call and handle the returned json as you wish, if
>  you want to write something.
>
>  C> Aside from these emails for passive notification, is there a way to
>  C> get a smaller, personalized report, like on pkgdb, about a specific
>  C> package's dependencies?
>
>  pkgdb doesn't track dependencies, so all you can do is ask it about the
>  status of a particular package.  You'll need to get the dependencies
>  from the package manager.
>
>  
That's unfortunate. These emails are a bit spammy, are not easily parsed,
and are hard to track. Not only is it hard to tell the difference between
notices sent directly to me, or sent to me via the mailing list, it also
seems impossible to get an immediate report of a newly acquired package.

It seems like it'd be useful for pkgdb (or some other system) to show the
active/orphan/retire status of a package and all its dependencies, on
demand, rather than wait for the next round of emails like this to see that
one of your critical dependencies just got retired.

Basically, I think we need a web UI for whatever system is currently
generating these emails.



>  C> Or a particular user's packages' dependencies?
>
>  That's just extracting from pkgdb the list of packages to which a user
>  has commit access (assuming commit access is what you want) and then
>  looking at that package in a loop.
>
>   - J<
>