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