[releng] Issue #6945: packages which had a dead.package file but weren't retired, have been erroneously retired
dcallagh reported a new issue against the project: `releng` that you are following: `` Recently I noticed a bunch of TurboGears dependencies disappeared from EPEL7 with no explanation. Koschei [noticed it too](https://apps.fedoraproject.org/koschei/package/TurboGears?collection=epel7):
``` Package resolution failed No package found for: python-turbojson >= 1.3 No package found for: python-paste-script No package found for: python-cherrypy2 No package found for: python-turbokid >= 1.0.5 No package found for: python-peak-rules No package found for: python-turbocheetah ```
According to `koji list-tag-history` these were untagged on 5 August, for example:
``` Sat Aug 5 15:24:19 2017: python-cherrypy2-2.3.0-18.el7 untagged from epel7 by releng ```
The common theme is that these packages were previously retired in 2014 when TurboGears was abandoned by Toshio, and then later they were *un-retired* after I picked it up. The `dead.package` file was created when they were retired, but then it was left behind in git when they were un-retired (these packages don't really ever get updates as you can see).
https://src.fedoraproject.org/rpms/python-cherrypy2/c/f0c006f5de16796a9d31fd... https://src.fedoraproject.org/rpms/python-cherrypy2/tree/epel7
You can see in the Pkgdb read-only view that the package was indeed *not* retired as of last week:
https://admin.fedoraproject.org/pkgdb/package/rpms/python-cherrypy2/
I guess this was a mistake in the Pkgdb-to-Pagure transition, which wrongly assumed the presence of a `dead.package` file in git meant the package was actually retired.
Other packages affected were python-astroid (#6941) and possible many others? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
till added a new comment to an issue you are following: `` 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_a...
These packages seem to be affected according to ```koji list-history --tag=epel7 --after 2017-08-01 | grep -C 1 blocked```
EPEL7:
celt conntrack-tools 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 pcre2 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 ttywatch tzdata-java ugene unison znc ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
orion added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
till added a new comment to an issue you are following: ``
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.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
dcallagh added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
dcallagh added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
dcallagh added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
till added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
inequity added a new comment to an issue you are following: `` 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! ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
dcallagh added a new comment to an issue you are following: `` 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 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
till added a new comment to an issue you are following: `` @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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
inequity added a new comment to an issue you are following: `` @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) ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
till added a new comment to an issue you are following: ``
@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) ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6945
rel-eng@lists.fedoraproject.org
-
Dan Callaghan -
Orion Poplawski
-
Robert Kelly
-
Till Maas