Learn more about these different git repos.
Other Git URLs
The output of spam-o-matic (depcheck in the compose logs) is just utterly wrong for recent Rawhide composes. e.g. this, from the most recent Rawhide compose:
depcheck
[calamares] calamares-3.1.8-10.fc29.i686 requires hicolor-icon-theme calamares-3.1.8-10.fc29.i686 requires dnf calamares-3.1.8-10.fc29.i686 requires console-setup calamares-3.1.8-10.fc29.i686 requires system-release [calibre] calibre-3.29.0-2.fc30.i686 requires python2-cssutils calibre-3.29.0-2.fc30.i686 requires python2-dateutil calibre-3.29.0-2.fc30.i686 requires python2-dns calibre-3.29.0-2.fc30.i686 requires python2-enum34 calibre-3.29.0-2.fc30.i686 requires python2-feedparser calibre-3.29.0-2.fc30.i686 requires python2-beautifulsoup calibre-3.29.0-2.fc30.i686 requires python2-mechanize calibre-3.29.0-2.fc30.i686 requires python2-pygments calibre-3.29.0-2.fc30.i686 requires python2-odfpy
All those deps actually are in the tree, they should not be shown as broken. We've known the output has been kinda unreliable for a while, but IIRC this related only to soft deps and/or modules. Aside from that it was still more or less correct for x86_64, so it was usable for spotting real broken deps. But it's now just stuffed with completely incorrect info and unusable.
It's not utterly critical, but I was hoping to find broken deps introduced by the Python 2 subpackage removal. Without any kind of usable dep check this is hard to do.
When is this no longer needed or useful? (YYYY/MM/DD)
If we cannot complete your request, what is the impact?
It'll be harder to find and fix broken deps in Rawhide.
@ngompa @mohanboddu
This looks like the problem we were having with ARM arches (rh#1565257) has now affected every non-native arch.
This was definitely working for most architectures when I wrote the code back in 2017...
(cc: @dmach)
I suspect the bit where it filters the packages by arch no longer works like it used to, but I haven't been able to look at it yet.
From our grooming discussion on #fedora-releng channel on Apr 12 2019
Close and link 6365 in favor of 7931
Also linking the dnf BZ ticket https://bugzilla.redhat.com/show_bug.cgi?id=1565257
Um. I don't know quite what you intended to do, @mohanboddu , but the message and the actions seem to be at odds with each other. This issue is still open and https://pagure.io/releng/issue/6365 was closed, but with a message saying it was closed in favor of itself.
So...I don't know whether you meant to keep this issue or 6365 open, but what actually happened is very confusing to try and read :)
@adamwill Yeah, I wrote the wrong thing, but did the right thing.
I have to close #6365 and leave #7931 open. Let me fix the writing.
Metadata Update from @kevin: - Issue tagged with: backlog
Well this turned out to be stupid easy:
https://pagure.io/releng/pull-request/10890
Now I feel like an idiot for leaving it sitting here for three years. I got sidetracked onto it this afternoon and it took all of thirty minutes to set up a test directory and fix it. And the cause was exactly what I suspected it was three years ago. Hah.
Well, looks like the report is 53MB... x86_64 looks fine, but...
See https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220920.n.0/logs/depcheck
huh, it wasn't doing that when I fixed it. let me look again.
hmm. yes, I can reproduce that locally. but I don't see why. grr.
So, this depends on the arch the script runs on. If I run the script on a ppc64le system, it gives correct results for ppc64le but wrong for x86_64. Not sure why yet.
After poking around at this for a bit, I concluded it really seems like a bug in libdnf.
Thanks to @churchyard , https://pagure.io/releng/pull-request/11041 should fix this.
Login to comment on this ticket.