#7931 spam-o-matic (depcheck) is wildly, uselessly wrong
Opened 5 years ago by adamwill. Modified 2 years ago

  • Describe the issue

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:

[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.

  • When do you need this? (YYYY/MM/DD)

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.


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

4 years ago

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.

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.

Login to comment on this ticket.

Metadata