I am sorry that we missed this. Once the packages are unretired please make sure that the dead.package file is removed and the spec is restored. Also you might need to bump the release, build it and push an update.

@ralph or @pingou need to unretire them for now according to https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_adopt_an_orphaned_package_or_unretire_a_package.3F_.28TODO.29

These packages seem to be affected according to koji list-history --tag=epel7 --after 2017-08-01 | grep -C 1 blocked

EPEL7:

celt
dock
freeradius-client
geoipupdate
ghc-xhtml
golang-github-gorilla-context
golang-github-gorilla-mux
golang-github-kr-pty
golang-github-syndtr-gocapability
heat-cfntools
jbrout
libscigraphica
munipack
oxygen-icon-theme
perl-TAP-Harness
perl-Throwable
php-pear-Structures-DataGrid-DataSource-MDB2
powermock
python-astroid
python-cherrypy2
python-django-babel
python-flask
python-netifaces
python-paste-script
python-peak-rules
python-pycadf
python-requests
python-sphinx10
python-subunit
python-tornado
python-turbocheetah
python-turbojson
python-turbokid
python-urllib3
python-werkzeug
rubygem-rails
scigraphica
sunbird
terminology
thunderbird-lightning

EPEL6:

compat-wxGTK
compat-wxPythonGTK2
desktop-data-model
dmlite-plugins-librarian
evolution-bogofilter
fgfs-base
freeradius-client
ggz-client-libs
gimpfx-foundry
gimpfx-foundry
gstreamer-plugins-pulse
gtk+extra
iozone
jruby
k3b-extras
kdeartwork-extras
kdegraphics-extras
kdemultimedia-extras
kickpim
lessjs
libggz
libkexiv2
libkipi
libnetfilter_conntrack
log4cxx
man2html
mathml-fonts
mediawiki-SpecialInterwiki
mytop
ocaml-bitmatch
openal
perl-Digest-SHA
perl-ExtUtils-CBuilder
perl-ExtUtils-ParseXS
perl-IO-Compress-Base
perl-IPC-Cmd
perl-Locale-Maketext-Simple
perl-Module-Build
perl-Module-CoreList
perl-Module-Load
perl-Module-Load-Conditional
perl-Module-Loaded
perl-Module-Pluggable
perl-Package-Constants
perl-Params-Check
perl-Pod-Escapes
perl-Pod-Simple
perl-TAP-Harness
perl-Test-Builder-Tester
perl-Time-Piece
php-json
php-pecl-json
postgresql-pgpool
pykdeextensions
python-gammu
python-json
python-memcached
python-sqlite2
python-urljr
python-yadis
scite
superkaramba
synergy
sysusage
tzdata-java
ugene
unison
znc

That caught too many packages - FWIW pcre2 was retired on 8/2 due to being added to RHEL7.4, and conntrack-tools was retired long ago (Apr 25 2016).

But in any case, it should be fairly obvious if there is a dead.package file along with a .spec file.

That caught too many packages - FWIW pcre2 was retired on 8/2 due to being added to RHEL7.4, and conntrack-tools was retired long ago (Apr 25 2016).

Thank you, I updated the list. I also removed ttywatch, which was also retired as intended.
AFAICS conntrack-tools got a dead.package file but it was not retired in pkgdb2:
https://admin.fedoraproject.org/pkgdb/package/rpms/conntrack-tools/

But in any case, it should be fairly obvious if there is a dead.package file along with a .spec file.

python-cherrypy2 only contains a dead.package file in the EPEL7 branch FWIW. I do not have the time to check everything else right now.

I think the authoritative source of this should be the retirement state in Pkgdb, not presence or absence of dead.package. As @till notes, python-cherrypy2 doesn't even have a spec in dist-git currently because it has never actually been built since 2014. But it should not be retired.

When I say "authoritative source" I am talking about the list of wrongly retired packages which need fixing up. Not saying that we need to resurrect Pkgdb or anything. :-)

@till if the list of packages in your comment is all the ones which were retired as part of the Pagure transition -- then I guess we could just filter that down to ones which are not retired according to the read-only Pkgdb data, right? Then that gives us the list of packages that need fixing.

Seems like the problematic retirements all happened on 5 August, so we can narrow the range a bit. And I crafted this curl+jq invocation to ask Pkgdb if a package was actually retired:

$ p=python-cherrypy2; curl -s -f "https://admin.fedoraproject.org/pkgdb/api/package/$p/" | jq -r '.packages[] | select(.collection.branchname == "epel7") | .status'
Approved
$ p=pcre2; curl -s -f "https://admin.fedoraproject.org/pkgdb/api/package/$p/" | jq -r '.packages[] | select(.collection.branchname == "epel7") | .status'
Retired

So based on the koji history we can cross-reference. For EPEL7:

koji list-history --tag=epel7 --after=2017-08-05 --before=2017-08-06 | grep -B1 blocked | grep -P -o '(?<=package list entry for ).*(?= in epel7)' | while read p ; do if [[ $(curl -s -f "https://admin.fedoraproject.org/pkgdb/api/package/$p/" | jq -r '.packages[] | select(.collection.branchname == "epel7") | .status') == "Approved" ]] ; then echo $p ; else echo NOT $p ; fi ; done

and similarly for EPEL6:

koji list-history --tag=dist-6E-epel --after=2017-08-05 --before=2017-08-06 | grep -B1 blocked | grep -P -o '(?<=package list entry for ).*(?= in dist-6E-epel)' | while read p ; do if [[ $(curl -s -f "https://admin.fedoraproject.org/pkgdb/api/package/$p/" | jq -r '.packages[] | select(.collection.branchname == "el6") | .status') == "Approved" ]] ; then echo $p ; else echo NOT $p ; fi ; done

So unless I've made a mistake in my bash command above, it shows that all the EPEL packages retired on 5 August were wrongly retired and should be unblocked and retagged in Koji.

I compared the lists and it's the same set of packages listed by @till in his comment above, except conntrack-tools which is listed in Pkgdb as approved but according to @orion's comment it should stay retired.

From the data it is hard to tell whether a package was intentionally not retired in pkgdb. For example it might be that there was just an error that resulted in the celt package not being retired. I set the SLAS for the affected packages to the default SLAS and unblocked the packages from the respective tags. You should be able to restore the spec files soonish to create a new build/update. We can then mark all remaining dead.package packages again as retired after maintainers had enough time to restore them.

Hate to be a bother, but any update on this? My team depends on some of these packages existing in the EPEL, so just wondering if there is any clear resolution in sight. Thanks!

I guess it's now down to the individual EPEL maintainers to rebuild the affected packages and post an update. I've done that for the ones in the TurboGears dep chain, namely:

python-cherrypy2
python-paste-script
python-peak-rules
python-turbocheetah
python-turbojson
python-turbokid

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e84f3a46a0

@dcallagh We can also re-tag individual builds if the individual maintainers explicitly state that these builds should be re-tagged.

@inequity Which packages does your team depend on? If you name specific packages we can take a look.

@till - Thanks for the reply.

We depend on:
python-turbocheetah
python-cherrypy2
python-turbojson
python-paste-script
python-peak-rules
python-turbokid

All of which are required by TurboGears-1.1.3-8.el7.noarch (epel)

@till - Thanks for the reply.
We depend on:
python-turbocheetah
python-cherrypy2
python-turbojson
python-paste-script
python-peak-rules
python-turbokid
All of which are required by TurboGears-1.1.3-8.el7.noarch (epel)

@inequity afaics all the packages are in the following update, I added the missing +1 to make it go to stable with the next push:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e84f3a46a0

@dcallagh btw. you can also set the auto karma value to a lower value to make updates go to stable with less positive karma (AFAIK)

I think this is all done now? Please re-open if there's anything further here.

:department_store: