Taskotron depcheck question

[Tim Flink]

On Wed, 19 Nov 2014 09:05:17 +0100
Petr Pisar <ppisar at 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 at 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
> <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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20141119/9819c039/attachment.sig>