I have done some cleanups in the Rust stack recently, and was able to retire a lot of old / obsolete packages in f41+. With a chunk of that work done since yesterday, I merged those retirements to epel9 / epel9-next too. This seems to have worked for all packages where the retirement commit happened yesterday, but not for others where the commit is older than that.
It looks like the detection of "is this a retirement?" based on the age of the commit is too strict. Would it be possible to instead check if the commit that adds the "dead.package" file is the last commit that is being pushed, i.e. the one that becomes the new git HEAD?
These packages are affected (there might be others, I still need to check):
rust-futures-cpupool rust-tokio0.1 rust-tokio-codec rust-tokio-core rust-tokio-current-thread rust-tokio-executor rust-tokio-fs rust-tokio-mock-task rust-tokio-reactor rust-tokio-sync rust-tokio-tcp rust-tokio-threadpool rust-tokio-timer rust-tokio-udp rust-tokio-uds
If the process to block packages that have "dead.package" in git HEAD is run regularly, I guess waiting will resolve this eventually. If it's not, please block these packages in the epel9 tag in koji.
Not urgent. The packages just show up as having broken dependencies in koschei and remain in the epel9 repos, but they're unused.
EPEL9 EOL (which might as well be N/A)
Packages that are intended to be retired by packagers might or might not actually be removed from repositories, depending on the timing of the retirement processing and / or when the retirement commit is merged into non-rawhide branches.
Metadata Update from @phsmoura: - Issue tagged with: medium-gain, medium-trouble, ops
cc: @lenkaseg
Metadata Update from @lenkaseg: - Issue assigned to lenkaseg
I added the time restriction as a temporary solution to distinguish between regular commit push and new branch creation - because on new branch creation all the commits are sent again to message bus and in case of retirement in the history of that package, the toddler would try to block the package in the new branch. I will remove the time restriction and add a call to distgit to see whether there is a dead.package currently on that branch and that should solve this. Thanks for reporting the issue!
Would it be possible to instead check if the commit that adds the "dead.package" file is the last commit that is being pushed, i.e. the one that becomes the new git HEAD?
This will not work if a later commit changes the retirement message or makes other changes that won't unretire the package.
I will remove the time restriction and add a call to distgit to see whether there is a dead.package currently on that branch and that should solve this.
This is better. Thanks
That sounds good to me!
Would it be possible to run the script that checks all packages in dist-git for "dead.package" file on rawhide, f41, epel9, epel9-next, epel10 branches, to see if there were any packages that were missed since this was implemented?
Would be great to have consistent state before the f41 final freeze takes full effect.
Going to run the script now!
Result: All packages that should be blocked: {'epel9': ['rust-futures-cpupool', 'rust-tokio0.1', 'rust-tokio-codec', 'rust-tokio-core', 'rust-tokio-current-thread', 'rust-tokio-executor', 'rust-tokio-fs', 'rust-tokio-mock-task', 'rust-tokio-reactor', 'rust-tokio-sync', 'rust-tokio-tcp', 'rust-tokio-threadpool', 'rust-tokio-timer', 'rust-tokio-udp', 'rust-tokio-uds']}
Opened an issue here in releng: https://pagure.io/releng/issue/12395
This issue should be fixed with this PR: https://pagure.io/fedora-infra/toddlers/pull-request/261
Can you run the dead.package checking script again please? I've retired a bunch of packages in rawhide, epel9, and epel9-next that are not getting processed now because the toddler is having extended sleepytime. For cross-reference (my packages only, there might be more):
retired in rawhide: rust-zbus3 rust-zbus_macros3 rust-zbus_names2 rust-zvariant3 rust-zvariant_derive3 retired in epel9: rust-atomic-polyfill0.1 rust-bitstream-io1 rust-bstr0.2 rust-cache-padded rust-cargo_metadata0.12 rust-cargo_metadata0.17 rust-cookie_store0.16 rust-criterion rust-criterion-plot rust-derive_builder0.9 rust-derive_builder_core0.9 rust-directories4 rust-drain rust-gif0.11 rust-gif0.12 rust-globwalk0.8 rust-humansize1 rust-lscolors0.15 rust-memoffset0.8 rust-miniz_oxide0.6 rust-normpath0.3 rust-oorandom rust-opener0.5 rust-os_pipe0.9 rust-ouroboros0.17 rust-ouroboros_macro0.17 rust-pkcs8_0.7 rust-powierza-coefficient rust-pretty_assertions0.7 rust-proptest-derive0.3 rust-quickcheck0.6 rust-regex-syntax0.7 rust-roxmltree0.18 rust-rust-embed6 rust-rust-embed-impl6 rust-rust-embed-utils7 rust-serial_test0.6 rust-serial_test_derive0.6 rust-serial_test1 rust-serial_test_derive1 rust-signature1 rust-signature_derive1 rust-structopt0.2 rust-structopt-derive0.2 rust-strum0.24 rust-test-case2 rust-test-case-macros2 rust-tiff0.6 rust-tinytemplate rust-toml0.4 rust-treeline rust-trust-dns-resolver rust-ttf-parser0.12 rust-typed-arena1 rust-vergen3 rust-version-sync0.8 rust-winnow0.4 retired in epel9-next: rust-bstr0.2 rust-directories4 rust-os_pipe0.9 rust-regex-syntax0.7 rust-winnow0.4
The toddler responsible for retiring packages is disabled now during the freeze, until I solve the "do not retire on frozen branch" condition. Adding the condition is easy, but I need to get the PR fixing this time restriction corner case thing merged first. The script is running now and I'll open an issue oon releng for manual blocking.
Ran the script and I see only these packages:
All packages that should be blocked: {'f42': ['rust-zbus3', 'rust-zbus_macros3', 'rust-zbus_names2', 'rust-zvariant3', 'rust-zvariant_derive3']}
Seems that the packages are still not in the lookaside cache, were they retired today? The lookaside json files get renewed nightly, that would explain the delay.
Yes, the zbus / zvariant stuff is from yesterday, the others I retired today.
The toddler responsible for retiring packages is disabled now during the freeze
I suppose packages being retired (in rawhide) while the toddler is on vacation will be dealt with eventually? Or should they be listed here?
Once we land the pending big PR, there should be a daily cleanup job that will catch all the ones missed and process them.
If you need it blocked before then for whatever reason we can do so manually.
I'm running the script for detecting retired packages that need blocking on koji twice a day, so everything should be more less in sync.
Thank you! This seems to be working out well for now. It looks like one (maybe more?) packages slipped through the cracks (rust-miniz_oxide0.5 in epel9-next), not sure why.
Metadata Update from @lenkaseg: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
This is solved in commit https://pagure.io/fork/lenkaseg/fedora-infra/toddlers/c/1c910f1215c8d77c2b7c54dd2c89881f5e0f5bca
Log in to comment on this ticket.