Same for me.

ACK. The same command should eventually work.

Two things to do still:

• We need to deploy the following server side system to propagate retirement from the dead.package file to PDC: https://github.com/fedora-infra/pdc-updater/pull/63
• We need to remove the call to pkgdb from fedpkg.

(Sorry for the mess. This is on our list. Getting to it!)

fedpkg patch -> https://pagure.io/fedpkg/pull-request/129

@ralph fixed upstream?

This still isn't working in the just built fedpkg 1.29, it gives a different error of "Could not execute retire: 'kojiconfig'"

@pbrobinson with which version of python2-rpkg?

The thread on the devel list seems to imply that one needs both:
- fedpkg-1.29
- python2-rpkg-1.50

Could you retire the package in Fedora ≥ 27? If I run "fedpk retire" with the new tools, I only get:

$ fedpkg retire 'All Fedora packages were migrated to libwbxml.'
dead.package found, package probably already retired - will not remove files from git or overwrite existing dead.package file
Everything up-to-date

The package is still not blocked in koji and probably in PDC.

I still see issues and in theory I'm an rel-eng admin so I don't think this issue is fixed

I'm trying to retire gridengine as well in master/f27 but it's not taking.

PR #7001 should fix blocking in rawhide. Let's see if it fixes the problem.

Link: https://pagure.io/releng/pull-request/7001

It does.

Can everyone on this issue please update fedpkg/rpkg and try and retire things? They should get dead.packaged, marked in pdc and then blocked on the next rawhide compose run.

I've just retry it in f27 branch for rpms/libwbxml-compat. Will it automatically retire the package also in higher Fedoras (f28) or should I run the command again from master branch?

The package is still not blocked in koji.

Yes, I'm still seeing issues too (not retired f27/f28), reran "fedpkkg retire" a few days ago and still not blocked in koji

https://koji.fedoraproject.org/koji/packageinfo?packageID=13075
https://src.fedoraproject.org/rpms/rubygem-kgio/commits/master

@ralph @mprahl whats the status here?

My understanding of the workflow is that someone does 'fedpkg retire' and it makes the dead.package file.
pdc-updater then runs (where? when?) and sees that event and updates the package to 'active: false' on those branches.
Finally the rawhide / branched compose runs and blocks anything thats active false in pdc thats not already blocked?

Is that it? And it seems the first step is fine, and now the 3rd is working, but something isn't updating for the second one?

@kevin this is the code in pdc-updater that retires it in PDC:
https://github.com/fedora-infra/pdc-updater/blob/bfc3ecf6cd31939545392911c0cf5dfdabf655f1/pdcupdater/handlers/retirement.py#L11

It does seem to be updated in PDC for f27:
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=libwbxml-compat&name=f27

It's still active for rawhide though:
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=libwbxml-compat&name=master

Edit: It seems that the "master" branch doesn't have a dead.package file which is why pdc-updater didn't pick it up for rawhide: https://src.fedoraproject.org/rpms/libwbxml-compat/blob/master/f/dead.package

My understanding of the workflow is that someone does 'fedpkg retire' and it makes the dead.package file.

That's right.

pdc-updater then runs (where? when?)...

It runs on pdc-updater02. It's buried in there. See the CSI information for the pdc-backend group.

and sees that event and updates the package to 'active: false' on those branches.

Yes. Well, technically, it sets the EOL of those branches to today. The active property is read-only and is dynamically derived from the EOLs of the branch.

Finally the rawhide / branched compose runs and blocks anything thats active false in pdc thats not already blocked?

That's right.

Is that it? And it seems the first step is fine, and now the 3rd is working, but something isn't updating for the second one?

I think @mprahl identified above that for the libwbxml-compat package in question above, the dead.package file had not actually been committed to the master branch. Only f27. It looks like @ppisar did that today, so it should get blocked in the next compose run.

(It may be approaching time to close this. Let's wait and see if libwbxml-compat gets blocked in the next sweep.)

So "fedpkg retire" only creates the dead.package. There is no additional API call involved? I.e. running "fedpkg retire" in master branch and merging the commit into older branches is enough?

I ask because this is different procedure from the previous implementation when one has to run "fedpkg retire" in the oldest branch.

Correct, "fedpkg retire" only creates dead.package and pushes to dist-git. Then pdc-updater marks branch as EOL in PDC, after seeing fedmsg with dead.package commit.

The package is indeed blocked correctly now.

I am going to close this out, but feel free to re-open if I missed anything left to do.