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
adamwill added a new comment to an issue you are following: `` @ngompa @mohanboddu ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931
ngompa added a new comment to an issue you are following: `` This looks like the problem we were having with ARM arches ([rh#1565257](https://bugzilla.redhat.com/show_bug.cgi?id=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) ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931
adamwill added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931
mohanboddu added a new comment to an issue you are following: `` From our grooming discussion on #fedora-releng channel on Apr 12 2019 ``` Close and link 6365 in favor of 7931 ```
Closing this in favor of https://pagure.io/releng/issue/6365
Also linking the dnf BZ ticket https://bugzilla.redhat.com/show_bug.cgi?id=1565257 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931
adamwill added a new comment to an issue you are following: `` 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 :) ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931
mohanboddu added a new comment to an issue you are following: `` @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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931
rel-eng@lists.fedoraproject.org
-
Adam Williamson -
Mohan Boddu
-
Neal Gompa