I'm seeing the same for a bunch of my packages.

@frantisekz Can you have a look at this? Thanks!

• Where does that FTBFS information come from?

It's from fedora repochecker ( https://pagure.io/ironthree/repochecker ). @decathorpe , can you take a look please? We probably need another override.

• Is that FTBFS information accurate?

It isn't, it's caused by an issue in one of dashboard's data sources.

• How can I as a normal packager find out more about it? After all, koji builds do not show any s390x related issues.

We might want to indicate data source somehow in the frontend and/or provide a way to report issue ( to be figured out, @lbrabec :) ).

• Do I need to (or should I) fix terminus-fonts.spec in some way?

I've checked your specfile, it seems to be just fine.
dnf builddep complains about it, there is some issue with macros processing here:

dnf builddep terminus-fonts
enabling fedora-source repository
fedora                                                                                                                                                                         7.3 kB/s | 4.5 kB     00:00    
fedora-source                                                                                                                                                                  1.4 MB/s | 7.2 MB     00:05    
Last metadata expiration check: 0:00:01 ago on Wed Feb 24 08:52:04 2021.
No matching package to install: '/usr/bin/grub2-mkfont'
Package python3-3.9.2-1.fc35.s390x is already installed.
Not all dependencies satisfied
Error: Some packages could not be found.

I am not sure if this is an actual packager_dashboard problem, but packager_dashboard is the first place to expose this issue, so I though I would start the investigation here.

Thanks for reporting it!

Btw, the same goes for some packages on https://packager-dashboard.fedoraproject.org/orion (elpa, openmpi, libASL, scorep,...).

:disappointed: yeah that's an issue with repochecker data. Or rather, a bug in koji / pungi.

The initially built SRPM (from the buildSRPMfromSCM task) is copied to source repositories for all target architectures, instead of using the the rebuilt SRPM from the mock build from each specific target architecture. This results in Exclusive/ExcludeArch'd BuildRequires not matching the architecture of the source repository in question.

Can you give me the release / architecture / dependency / broken values you want to be excluded as false positives (e.g. "rawhide" / "s390x" / "/usr/bin/grub2-mkfont" / "terminus-fonts")? I'll add those values to the repochecker config files.

See: https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json for existing false positive overrides

BTW: I've filed https://pagure.io/koji/issue/2726 because this is issue really starting to annoy me.

FWIW this affects collectd as well (It doesn't build the nut plugin on s390x, but dashboard shows it FTBFS for all branches on s390x due to this.
(at least I think it's the same thing)

@kevin I can add a filter rule for that false positive, if you can give me the appropriate combination of "$release" / "$arch" / "$broken-dep" / "$package".

release: 32 33 34 rawhide and 32-testing 33-testing 34-testing
arch: s390x
broken-dep: nut-devel
package: collectd

Thanks, override added in commit https://pagure.io/ironthree/repochecker/c/4b3c7bd16acd55b25025ea597f0eba7efa7d25b2?branch=master

The package state should clear up within a few hours (as soon as the data is regenerated, and updated data is retrieved from repochecker).

Thanks!

This started to affect RStudio some weeks ago (see my dashboard). I have a permanent FTBFS there pointing to Qt5WebEngine in non-Qt5 arches (that BuildRequires is enclosed in the proper %if, of course). I thought that FTBFSs were just reported from failures from Koschei.

The data from "repochecker" is used for two purposes in the packager dashboard:

• broken dependencies of "binary" packages are shown as "Fails to install" / FTI problems
• broken dependencies of source packages are shown as "Fails to build" problems, alongside the actual status of the package in koschei

It's a difficult problem to solve, especially for source packages. Build results from koji only save one SRPM from a random (?) architecture that the package was built on. Depending on the architecture, this SRPM might encode architecture-dependent BuildRequires, even if they are %ifarched in the spec file (because repository data operates on RPM / SRPM headers, not spec files, and those might contain BuildRequires for architectures that are not applicable everywhere).

The contents of the "architecture-dependent" SRPM files are identical between architectures, only their headers are different, so it wouldn't even make sense to keep the SRPM files from every individual architecture, as that would require 1) much more storage and 2) "source" repositories for every architecture instead of one source repository for all architectures.

The best solution I could come up with for "repochecker" was to maintain a curated list of filters to account for such "false positives". It's pretty easy to add data points to the filter if I know the actual problem:

https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json

This file is structured by "release" / "architecture" / "broken dependency" / "affected packages". Looking at the RStudio case, that would look like:

• rawhide / ppc64le / cmake(Qt5WebEngine) / rstudio
• rawhide / s390x / cmake(Qt5WebEngine) / rstudio

It looks like rstudio was actually already set up, but you changed BuildRequires from pkgconfig(Qt5WebEngine) to cmake(Qt5WebEngine) in rawhide?

Since repochecker cannot know that those two refer to the same package (it's a dependency on something that's not in the repositories, so it couldn't even resolve the virtual provides to check if they are provided by the same package if I wanted to).

Should I add the overrides for cmake(Qt5WebEngine), and make the ones for pkgconfig(Qt5WebEngine) specific to Fedora 35 and 36, or will this change be pushed to stable branches, as well?

It looks like rstudio was actually already set up, but you changed BuildRequires from pkgconfig(Qt5WebEngine) to cmake(Qt5WebEngine) in rawhide?

Yes, I recently switched to the cmake() specification those dependencies with cmake files.

Should I add the overrides for cmake(Qt5WebEngine), and make the ones for pkgconfig(Qt5WebEngine) specific to Fedora 35 and 36, or will this change be pushed to stable branches, as well?

Yes, please, or just add rstudio to the already existing cmake(Qt5WebEngine) key? Whatever fits you best. There is a version in rawhide that cannot be built in <=F36, so the pkgconfig() notation is gonna stay there, and cmake() will be used from F37 on. Thanks.

Fixed with commit:
https://pagure.io/ironthree/repochecker/c/e6f9ff00cff6c41e8ab36b7b6661ffa5537cefaa?branch=master

I've already deployed it to repochecker.decathorpe.com, so the false positive for rstudio should be gone after the next data refresh (worst case: 4 hours).

I think all the problems that were mentioned in this thread are fixed now. If there are any new ones, people should probably create new tickets, this one is starting to be rather large and unwieldy.

Would it be possible to add an infobox / popup on hover / something similar to FTI issues that documents that the data source is not fool-proof due to limitations of the RPM file format and the way pungi composes repositories, and lead people to file issues about false positives?

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/apps/packager_dashboard/issues/81

Please continue any further discussion there.