These seem to origin from repochecker [0] and indeed, seem outdated.

@decathorpe can you take a look when/if you have some free cycles? Thanks!

[0] https://pagure.io/ironthree/repochecker

I'll look at it shortly. This should not happen.

Oh, btw, can you provide the release / repo these errors are shown for?

• The problem for git-lfs seems to be valid, at least according to quick repoqueries on rawhide:

$ repoquery --provides golang-github-git-lfs-gitobj-2-devel
golang(github.com/git-lfs/gitobj) = 2.0.1-1.fc34
golang(github.com/git-lfs/gitobj/errors) = 2.0.1-1.fc34
golang(github.com/git-lfs/gitobj/pack) = 2.0.1-1.fc34
golang(github.com/git-lfs/gitobj/storage) = 2.0.1-1.fc34
golang-github-git-lfs-gitobj-2-devel = 2.0.1-1.fc34
golang-ipath(github.com/git-lfs/gitobj) = 2.0.1-1.fc34

$ repoquery --provides compat-golang-github-git-lfs-gitobj-2-devel
compat-golang-github-git-lfs-gitobj-2-devel = 1:1.4.1-1.fc33
golang(github.com/git-lfs/gitobj/v2) = 1.4.1-1.fc33
golang(github.com/git-lfs/gitobj/v2/errors) = 1.4.1-1.fc33
golang(github.com/git-lfs/gitobj/v2/pack) = 1.4.1-1.fc33
golang(github.com/git-lfs/gitobj/v2/storage) = 1.4.1-1.fc33
golang-symlink(github.com/git-lfs/gitobj/v2) = 1.4.1-1.fc33

So no package provides version >= 2 for the github.com/git-lfs/gitobj/v2 import path. I also find it weird that the v2 version is provided by the compat 1.4.1 version and not by 2.0.1.

• The problem with ocrmypdf is caused by a koji / pungi bug (noarch packages copied to arches that are explicitly ExcludeArch'd - python-img2pdf is not built in s390x):

https://pagure.io/koji/issue/1843

I have added the package to the list of false positives until the upstream bug is resolved:

$ ./overrides.py insert 33 s390x "(python3.9dist(img2pdf) < 0.5 with python3.9dist(img2pdf) >= 0.3)" ocrmypdf
 → adding 1 overrides for /33/s390x/(python3.9dist(img2pdf) < 0.5 with python3.9dist(img2pdf) >= 0.3)
$ ./overrides.py insert rawhide s390x "(python3.9dist(img2pdf) < 0.5 with python3.9dist(img2pdf) >= 0.3)" ocrmypdf
 → adding 1 overrides for /rawhide/s390x/(python3.9dist(img2pdf) < 0.5 with python3.9dist(img2pdf) >= 0.3)

The data will be updated within a few hours of deploying the new config.

• The problem with tinygo is caused by a known limitation in repochecker:

https://pagure.io/ironthree/repochecker/issue/3

Because repoclosure's --newest flag is useless for multiple repositories:

https://bugzilla.redhat.com/show_bug.cgi?id=1811456

I am unsure how to work around this in the repochecker code. Basically, tinygo in the GA / "fedora" repositories indeed has broken dependencies, but you have fixed it after GA, so the "updates" repo has a non-broken version. But because the --newest flag for repoclosure does consider repositories separately instead of together, the old, broken version from the GA repo still shows up as broken.

Did I miss something, or does that answer your questions?

So no package provides version >= 2 for the github.com/git-lfs/gitobj/v2 import path. I also find it weird that the v2 version is provided by the compat 1.4.1 version and not by 2.0.1.

It certainly used to work, at least when I opened this. But it does indeed appear broken now. I think somehow when eclipseo bumped golang-github-git-lfs-gitobj, then reverted it, the wrong thing got tagged into repos. I'm going to retire this on Rawhide at least, because only git-lfs requires it and it needs v2.

Is there anything else I should do here?

Going by the subject of this issue, I'm adding information here. Let me know if you prefer a new ticket and I'll be happy to open one.

In our bi-weekly meetings we (Neuro SIG) use the Packager Dashboard to check the health of the packages we maintain collectively. On the dashboard several packages are shown as being FTBFS. However, looking at the status of these packages in Koschei, shows them to be in good health for all current branches.

Two examples:

python-lsp-server shows as FTBFS in F38. However, Koschei shows no issues for the package.

spyder also shows as FTBFS for F38. And, again, Koschei does not complain.

Am i missing something here? Or is the dashboard broken?

@gui1ty these mean: there are missing build-dependencies detected for those packages on specific architectures.

Note that it's possible that this issue has been fixed in the meantime, but the packages were just broken at GA and the broken versions remain in the "fedora" repo while fixed versions are in the "updates" repo.

In the second case, does this package have a conditional dependency on QtWebEngine? That is not captured by Fedora repository metadata, so the repochecker service cannot know about it. I already have some overrides for false positives like it here: https://github.com/ironthree/repochecker/blob/main/overrides.json

If this is indeed a false positive, please file a ticket there with details of what issue you want filtered out.

Sorry for the delay in replying. It seems I didn't get the e-mail notification I usually get. I will have to look into that.

For python-lsp-server, which is listed FTBFS for all architectures (F38) I already ran a local build in mock. That finished fine without any issues. Thus the package can be build from source. Scratch builds on Koji succeeded for both packages. Am I doing something wrong?

Regarding spyder it uses ExclusiveArch: %{qt5_qtwebengine_arches} following pyqtwebengine. I'll take a look at repochecker to see what it has to say regarding those two packages.
I am wondering why all these different architectures matter, though. Both packages are noarch.

Both packages have seen updates during the F38 life cycle. So, the latest release is in the updates repository, I assume without verifying. But if Packager Dashboard does not take updates into account, it quickly becomes polluted with false positives, doesn't it? Or am I misunderstanding you?

Sorry for the delay in replying. It seems I didn't get the e-mail notification I usually get. I will have to look into that.

I found the mail. One of my filters grabbed it. I only now realize packager-dashboard is part of fedora-qa. At least one problem solved. :smile:

For python-lsp-server, the version the dashboard is complaining about is from this build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2023480

I can reproduce the build failure locally in mock. The package is in the f38 "fedora" repo, even though there are newer versions in the "updates" repo.

For spyder, there are two possibly unrelated issues. One is a packaging issue - it should use both BuildArch: noarch and ExclusiveArch: %{qt5_qtwebengine_arches} noarch - see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unported_dependencies

However, what you're seeing in the dashboard is likely caused by a shortcoming of RPM metadata. There is no way to encode "these BuildRequires are specific to some architectures but not others" - they are present or they are not. So source packages end up with dependencies that are not satisfiable on some architectures, even if they build fine on them, because there's a processing step in-between that drops those BuildRequires.

That is what the overrides that I linked above are for, since there is no way to determine this programmatically from repository metadata (it would require parsing spec files, and I definitaly don't want to do that).

To clarify the situation around "fedora" and "updates" repo: repochecker needs both repos enabled to be able to resolve dependencies, since not all packages are present in the "updates" repo. And the way it does the checks ("dnf repoclosure" with some magic sauce on top) means:

If the package is in both the "fedora" and the "updates" repo, and the version in "fedora" has broken dependencies but the version in "updates" does not, then it will continue showing broken dependencies. It should be possible to work around this somehow - for example, filter out broken dependencies from the "fedora" repo if there is a build without broken dependenices in the "updates" repo, or something like that ... but I haven't had the time to implement advanced filtering like that.

Thanks for looking into it. It helps a lot knowing what is going on behind the scene.

For spyder, there are two possibly unrelated issues. One is a packaging issue - it should use both BuildArch: noarch and ExclusiveArch: %{qt5_qtwebengine_arches} noarch - see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unported_dependencies

Thanks for pointing that out. I will fix spyder according to the packaging guidelines. I will also try to figure out if an override is needed.

I'm no good at Rust. So, I won't be able to help with the advanced filtering. ;)