Learn more about these different git repos.
Other Git URLs
$ koji list-tagged --inherit --quiet f39-updates-testing-pending waycheck waycheck-0.1.3-1.fc39 f39 ngompa waycheck-0.1.3-1.fc39 f39-updates-testing ngompa waycheck-0.2.0-1.fc39 f39 ngompa waycheck-1.0.0-1.fc39 f39-updates ngompa $ koji latest-build --quiet f39-updates-testing-pending waycheck waycheck-0.1.3-1.fc39 f39-updates-testing ngompa
This is causing flatpak-module-tools to think 0.1.3-1.fc39 is the version to target for building flatpaks, where it should be 1.0.0-1.fc39, and this will continue to occur (whenever the actual latest release is stable) for the duration of F39.
To that end, please koji untag-build f39-updates-testing waycheck-0.1.3-1.fc39
koji untag-build f39-updates-testing waycheck-0.1.3-1.fc39
When do you need this? (YYYY/MM/DD) Not urgent.
When is this no longer needed or useful? (YYYY/MM/DD) March 2024, when we start migrating flatpaks to F40.
If we cannot complete your request, what is the impact? It will take manual intervention to build the correct NVR of any future F39 updates to this package (unless done while itself still in testing) for F39 flatpaks.
fyi @otaylor
Metadata Update from @phsmoura: - Issue tagged with: low-gain, low-trouble, ops
I don't think there's an expectation that things tagged with f39-updates-testing are always going to be higher version than what's tagged with f39 or f39-updates. Certainly bodhi doesn't enforce it in any way. Whenever a build gets karma fast enough to get queued for a stable push before it gets a chance to get pushed to testing, the stable tag gets the new build and nothing changes for the testing tag.
Another aspect is that during the pre-release phase, bodhi never untags builds from updates-testing when they migrate to stable, keeping them tagged with both. This is because bodhi doesn't control the base repo composes (which happen on cron, and might fail for several days in a row sometimes) and bodhi wants to ensure there's an overlap in time so that builds don't disappear from updates-testing and take several days before they appear again in the stable repo.
Yeah, so I think we should add a releng step here to clean this up at/before GA, or perhaps better: get bodhi to clean it up after a few days.
I am going to manually untag the f38/f39 ones today. That is, those builds that are in both f39-updates-testing and f39 (so, it's pointless for them to be in updates-testing)
I am going to leave f37 alone as it goes EOL next week and I don't want to mess with it.
CC: @humaton @jnsamyak
CC: @mattia also
I think the culprit is in https://github.com/fedora-infra/bodhi/blob/b6abafcdf2a09246d178ea5b985c3c6e7b80c7ad/bodhi-server/bodhi/server/tasks/composer.py#L595-L599
When a release is frozen, stable composes are "skipped" by bodhi-composer, so instead of moving builds from one tag to the other, only the newer tag is added. From a first glance, I cannot see why this difference was introduced.
The difference is because of what @kalev said in the comment above. ;) In the time after updates-testing is enabled, but before GA, we don't want updates going from testing to stable to possibly 'disappear' from updates-testing before they appear in a compose. I guess the ideal solution would be to have the branched compose process untag builds from updates-testing if they are in the base tag. (after the compose completes).
Log in to comment on this ticket.