On Wed, 19 Nov 2014 09:05:17 +0100
Petr Pisar <ppisar(a)redhat.com> wrote:
On Tue, Nov 18, 2014 at 08:23:38PM -0500, Scott Talbert wrote:
> On Thu, 6 Nov 2014, Petr Pisar wrote:
> >>>As far as I know alternative-architecture multi-lib packages are
> >>>distributed in the same repository as packages for the main
> >>>architectue. E.g. glibc-devel.i686 is in x86_64 repository, hence
> >>>glibc-devel is mutlilib. glibc-headers.i686 is not in the the
> >>>x86_64, hence glibc-headers is not multi-lib.
> >>Yeah, but the thing that's bugging me about this now that I'm
> >>digging into it more is that miniz-devel.i686 is installable on
> >>f20 via dnf and yum.
> >I sent a question why miniz is flagged as multi-lib to the
> ><rel-eng(a)lists.fedoraproject.org> and it's waiting on the
> >moderator now. Once it propagates, I will take down a pointer here.
> Did you ever find out why miniz was flagged as multi-lib?
No. I sent on November 6th an e-mail to rel-eng mailing list, got a
message it waits for a moderator and then no reply. Obviously the
Fedora's one-man rel-eng team does not manage the mailing list.
I don't think that the snarky comments about other contributors is
really necessary. Since you know that Fedora rel-eng has been largely a
one-person show until recently, I suspect you know who that is. Perhaps
reaching out to that person or joining the rel-eng list temporarily
would generate a faster response. Moderation requests are easy to lose
in inboxes and both releng and qa are rather busy getting a release out
the door right now.
However I got similar QA check report
which never happened before.
I remember from talks with RHEL rel-engs that they mark all '*-devel'
packages as multi-lib just based on the package name. And then they
have a lot of exception hard-coded into the mashing script. So I
guess similar situation is in the Fedora too and that the script is
just erroneous in same cases. And that it's not in line the packaging
guidelines which explicitly require that any *-devel package must
require specific architecture.
As far as I know, there aren't any exceptions in the Fedora mash
The script used for mashing the release repo is:
which I think points to the default config:
If the QA check bothers you I would recommend to raise this issue to
If the check bothers you, talk to us before going to FESCo, please. I
can't speak to whether or not the packages in question should be
multilib or not but the x86-32 packages do resolve and install properly
on x86_64 bit systems. As far as I'm concerned, this is a bug in
depcheck that needs to be addressed.
I apologize for not getting into this sooner - other things came up and
as far as I knew, this issue was only affecting a single package. I'm
going to be on PTO next week and likely the end of this week but I'll
try to get to this tomorrow or Thursday.