And for my package libunicap it assumes FTBFS with "failing to build for Fedora 31" with "src: libraw1394-devel >= 1.1.0" - why? This seems to be wrong, too.

This usually means the buildrequires of the latest build on Fedora 31 cannot longer be met there.

@churchyard so is this NOTABUG, or should we take action? E.g. is there a way of detecting the This usually means the buildrequires of the latest build on Fedora 31 cannot longer be met there. bit so we might be able to look for a better way to present i to the end-user?

E.g. is there a way of detecting...

Yes, this is always the case when the src arch has broken deps.

Hi,

I have a similar issue with one of my packages, gucharmap, that the dashboard reports as FTBFS on F31, listing these dependencies:

• unicode-ucd = 11.0.0
• unicode-ucd-unihan = 11.0.0

The thing is that both gucharmap and its dependencies have moved to unicode 13 and I've verified that it builds on F31. Will this be corrected when repochecker replaces fedora-health-check?

P.S.: Is there an ETA on the move to CommuniShift?

All the best

Hi,

the data about FTBFS for 'gucharmap' is from Fedora repochecker ( https://pagure.io/ironthree/repochecker ) by @decathorpe .

@decathorpe , gucharmap seems to build just fine in F31+updates (just tested it in f31 mock), but it is listed in https://repochecker.decathorpe.com/data/31 as failing/source, can you take a look at it pretty please :) ?

Regarding the CommuniShift, we're waiting for the service to come back online after Fedora data center migration, I am not aware of any eta just yet. We'll move packager dashboard the moment it comes online.

Hello František,

Thanks for the information.
I could be remembering wrong, but I think that unicode-ucd was at version 11.0.0 at the time of F31 branching and for a while there was a mismatch. Besides, in the json gucharmap is listed as being at 12.0.1-1, but its latest stable version is 13.0.2-2.

Hi, the information gathered and reported for broken dependencies includes things for both "fedora" and "updates" repositories. Looking at the raw data ( https://repochecker.decathorpe.com/data/31 ; array items 1148-1152) the broken dependencies come from the "fedora" GA repository. If the package has only been fixed after that point, I can't do anything about this due to a deficiency in how "dnf repoclosure" handles the "--newest" argument.

I don't know how to deal with situations like that yet (filter them out if the package is broken in "fedora" but not in "updates", but only if it's actually present in the "updates" repo? maybe. but that's code I'd have to write :) )

Hey Fabio,

Going through my emails I saw that 9 months ago I had submitted a patch for gucharmap and shortly after I took over and part of the problem was the dependencies on unicode-ucd-11.0.0 and unicode-ucd-unihan-11.0.0 (bug #1735327). At least now we know this is not a new issue in F31 and it will go away when F31 reaches EOL.
I think this is the third broken package I adopt post-GA and I have a bad feeling there's a fourth around the corner. Now that I know how the report is generated, I won't panic the next time I see something similar. I don't know if working on that is worth your time, unless significantly more people come forward, you could leave it at that.

I've created an "upstream" tracking issue for an RFE:
https://pagure.io/ironthree/repochecker/issue/3

I think with this we can close this ticket?

I've created an "upstream" tracking issue for an RFE:
https://pagure.io/ironthree/repochecker/issue/3

I think with this we can close this ticket?

Fine by me, but I'm not the OP

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

Please continue any further discussion there.