On Wed, 19 Nov 2014 09:05:17 +0100 Petr Pisar <[email protected]> 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 > > ><[email protected]> 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 > <https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/13277/steps/runtask/logs/stdio> > for pcre > <https://admin.fedoraproject.org/updates/FEDORA-2014-14639/pcre-8.35-7.fc21> > 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 scripts. The script used for mashing the release repo is: https://git.fedorahosted.org/cgit/releng/tree/scripts/mashcompose which I think points to the default config: https://git.fedorahosted.org/cgit/mash/tree/configs/branched.mash > If the QA check bothers you I would recommend to raise this issue to > FESCo. 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. Tim
pgpMOuXWQzKBE.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/qa-devel
