#9520 Update in inconsistent state - refuses to go stable
Closed: Fixed by mohanboddu. Opened by ellert.

  • Describe the issue

The update
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d7c1181e05
is in an inconsistent state.

(The web interface to bodhi times out for this update - probably due to the number of builds it contains. Use bodhi cli to get info.)

Of the 274 builds in this update 271 are currently tagged "epel8-testing".

One (accounts-qml-module-0.7-1.el8) is tagged "epel8-testing" and "epel8-testing-candidate"

Two (kde-dev-scripts-19.12.2-1.el8 and qt5-qtnetworkauth-5.12.8-1.el8) are tagged "epel8-testing-candidate"

There are no comments to the update about builds having been added or removed, so all builds should have the same tags.

  • When do you need this? (YYYY/MM/DD)

As soon as possible.

  • When is this no longer needed or useful? (YYYY/MM/DD)

Never

  • If we cannot complete your request, what is the impact?

This update is needed to make the EPEL 8 buildroot consistent.
The RHEL base updated QT version, and the EPEL QT packages must be updated to match.

Here is an example of a package that currently can not be built due to inconsistent buildroot:
https://koschei.fedoraproject.org/package/root?collection=epel8


As wrote in https://github.com/fedora-infra/bodhi/issues/4044 the builds in this update are joined with those buildroot overrides that have an enormous data in notes. That probably causes a lot of problems when Bodhi tries to operate on that update, loading all those builds and all chained buildroot overrides.

To fix this problem we would need to polish the tagging status of those builds still tagged into testing-candidate and also trim the notes of the buildroot overrides to prevent Bodhi to hang in future.
Can an admin run a manual query on Bodhi database like:
UPDATE buildroot_overrides SET notes = LEFT(notes, 2000) WHERE LENGTH(notes) > 2000;
?

Well, we need to get updates flowing again... and then i hope it will go out... the last thing it complained about is fixed.

There were a number of updates going out to EPEL 8, but this one did not make it. It is still in Status: pending.

   Update ID: FEDORA-EPEL-2020-d7c1181e05
Content Type: rpm
     Release: Fedora EPEL 8
      Status: pending

The tags on the builds in the update are still inconsistent (no changes)

Of the 274 builds in this update 271 are currently tagged "epel8-testing".

One (accounts-qml-module-0.7-1.el8) is tagged "epel8-testing" and "epel8-testing-candidate"

Two (kde-dev-scripts-19.12.2-1.el8 and qt5-qtnetworkauth-5.12.8-1.el8) are tagged "epel8-testing-candidate"

I have pushed again the update to stable and now it seems that Bodhi has successfully tagged all the builds the right way (the update is marked as signed).
Hopefully it will go out with the next push.

No, the update was ejected again.

          bodhi - 2020-06-15 09:18:46 (karma 0)
          FEDORA-EPEL-2020-d7c1181e05 ejected from the push because "Cannot
          find relevant tag for analitza-19.12.2-1.el8.  None of
          ['epel8-testing', 'epel8-testing-pending', 'epel8-pending'] are in
          ['f32-container-updates-candidate', 'f33-updates-candidate', ...

The tags on all builds must be set consistently by someone that can do that, and then the request to push to stable can be done.

I.e. add the epel8-testing tag to the two packages that don't have it, and remove the epel8-testing-candidate tag from the three pacages that have it. Until all packages are tagged consistently, the push will keep failing.

Actually, I think it complaints about a missing epel8-testing-candidate tag, I will add it manually to the affected builds.

The update is now pushed to stable.
For the records, in such cases, since a pending update cannot be unpushed, a workaround is to obsolete the update and then push it again to testing/stable.
That will take care of adding the right tags to all the builds.

Closing the ticket as the issue seems to be resolved.

Please reopen if you find anymore issues.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata