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
On Tue, Nov 1, 2016 at 3:00 PM opensource@till.name 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?
"C" == Christopher ctubbsii@fedoraproject.org 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<
On Wed, Nov 2, 2016 at 3:23 PM Jason L Tibbitts III tibbs@math.uh.edu wrote:
"C" == Christopher ctubbsii@fedoraproject.org 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<
epel-devel@lists.fedoraproject.org
-
Christopher -
Jason L Tibbitts III -
Till Maas