search

fedora-infra / koschei

Continuous integration for Fedora packages
GNU General Public License v2.0
37 stars 15 forks source link

Packages never get out of error states, even after the cause of the error is fixed since a long time #321

Closed ellert closed 2 years ago

ellert commented 4 years ago

Some examples.

https://koschei.fedoraproject.org/package/root?collection=epel8

This package reports:

The broken dependencies were fixed 2020-06-15 with this update:

But Koschei still reports that the dependencies are broken more than 2 weeke later.

https://koschei.fedoraproject.org/package/arc-gui-clients?collection=f33

This package reports:

The latter is inconstant with what is reported further down the page, where it says "Dependency changes since last build". So one part of Koschei seems to be able to resolve the dependencies, while an other says the package is not tested because the dependences are unresolvable. The SRPM from the latest build is available from koji, and can be built. And Koschei itself has built it before. So this seem to be some short term temporary glitch in communicating with koji, and Koschei does not recognize that the problem is long gone. The package has been in this state for weeks.

https://koschei.fedoraproject.org/package/R-qtl?collection=f32

This package reports:

The first two are no more true for this package than for the previous example. That the package has no known builds not even Koschei itself believes, because it lists many builds further down the page under "Most recent builds", but Koschei still lists it as a reason not to run test builds for the package. The package has been in this state for weeks.

That Koschei might take up to a few hours to clear an error state after the error is fixed would be understandable. But that it never happens (or takes more than two weeks) is not reasonable.

The above are just a few examples. The complete list of packages affected is much longer,

ellert commented 4 years ago

It is possible to work around some of the problems by using the "skip resolution" options. Clicking this option for packages in the "No suitable SRPM was found" or "Package dependencies were not resolved yet" state gets scheduled. Sadly, packages in "Package has no known build" state are not helped by this option, koschei still refuses to schedule builds for those. Bug?

After having forced a build this way and then unchecking the "skip resolution" option again, the "No suitable SRPM was found" error is cleared, but the "Package dependencies were not resolved yet" error is not. Another bug?

mizdebsk commented 4 years ago

I've just reset states of all affected packages, but that is fixing the symptom only. The real cause still needs a proper fix.

ellert commented 3 years ago

Hi.

Is there any progress on this. I haven't checked all the packages I maintain, but at least the following are stuck for months without a build triggered by koschei even though there are no dependency issues:

https://koschei.fedoraproject.org/package/root?collection=f34 https://koschei.fedoraproject.org/package/root?collection=epel8 https://koschei.fedoraproject.org/package/HepMC3?collection=epel8

ellert commented 2 years ago

Packages that I maintain that were affected by this got put of the broken state on 2021-11-19 and have been checked by koschei since then.