adamwill reported a new issue against the project: `releng` that you are following: `` * 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931