Due to a number of different infrastructure issues, some packages that were properly retired before the start of the F44 final freeze (in some cases, weeks in advance) have still not been dropped from the Fedora 44 repositories (i.e. were not blocked in koji, and are still present in composes).
I propose that package retirements that were intended to happen before the start of the F44 final freeze but which were not processed correctly before the start of the freeze due to automation failures are to be processed by releng (manually, if need be) despite the freeze now being in effect.
In the interest of transparency: Some of my packages are in this category - most of them "compat" packages that were leaf packages since they were no longer needed. And I would like to not have zombified and unfixable versions of them hanging around in f44 repositories.
I think it should be possible to script determining (potentially) affected packages. dist-git has a JSON file with packages that have a retirement commit at the tip of the f44 branch (https://src.fedoraproject.org/lookaside/retired_in_f44.json) and querying koji whether a package is blocked in the f44 tag is also straightforward. The interesting cases are those where there's a retirement commit on the f44 branch (that is older than the start of the final freeze) and the package is not blocked in the f44 tag in koji.
see also this ticket for the currently ongoing issues: https://forge.fedoraproject.org/releng/tickets/issues/13263
and these tickets for other incarnations: https://forge.fedoraproject.org/releng/tickets/issues/13258 https://forge.fedoraproject.org/releng/tickets/issues/13232 https://forge.fedoraproject.org/releng/tickets/issues/13190
+1
The whole point of the auto-retirement process is to avoid delivering unmaintained packages into new Fedora releases. So let's honor that.
Sure, +1... I was going to just suggest this at the releng ticket but have been again swamped. ;(
note that the reason we don't normally retire things in freezes is that there is a chance for breakage that could cause problems for the release.
I think a few years back network-scripts got retired in final freeze and broke a bunch of things. That said, if we are willing to back out any problems or address them we can do this, and if we do so we should do it soon.
Proposing for FastTrack.
And yes, if we discover that one or more of the retirees causes an issue with the compose, we can restore them immediately. Or all of them, if it's too difficult to work out which subset is at fault.
Metadata Update from @sgallagh: - Issue tagged with: fast track
#!/usr/bin/python3 import koji import requests BRANCH = "f44" retired = requests.get( f"https://src.fedoraproject.org/lookaside/retired_in_{BRANCH}.json" ).json()[BRANCH] koji_session = koji.ClientSession("https://koji.fedoraproject.org/kojihub/") not_blocked = [] for package in retired: taglist = koji_session.callMethod("listPackages", pkgID=package, with_dups=True) if not [*filter(lambda x: x["tag_name"] == BRANCH, taglist)][0]["blocked"]: not_blocked.append(package) for package in not_blocked: print("-", package)
Assuming that my script above was correct, these are all the affected packages:
Metadata Update from @siosm: - Issue tagged with: meeting
Oh can we also retire rust-uu_hashsum ? It won't build anymore after the rest of rust-uu_* were updated (it's no longer used and we missed retiring it until after the cut-off)
Context: https://forge.fedoraproject.org/releng/tickets/issues/13302
APPROVED (Fast Track) (+7, 0, 0) https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5YIFT2MGTNWXFX7V672O2EJO2HSZUMHM/
Metadata Update from @siosm: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @siosm: - Issue untagged with: meeting
Filed https://forge.fedoraproject.org/releng/tickets/issues/13317 since it doesn't seem to have happened yet ...