Hi,
Can someone please help me with a depcheck question? See this log file for the package 'miniz':
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/6954/...
As best I as I can tell, the depcheck is failing because there is no 32-bit glibc-headers package in the x86_64 repository. But do we care because miniz 32-bit package won't be in the x86_64 repository either?
Thanks, Scott
On Thu, 30 Oct 2014 20:27:34 -0400 (EDT) Scott Talbert swt@techie.net wrote:
Hi,
Can someone please help me with a depcheck question? See this log file for the package 'miniz':
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/6954/...
As best I as I can tell, the depcheck is failing because there is no 32-bit glibc-headers package in the x86_64 repository. But do we care because miniz 32-bit package won't be in the x86_64 repository either?
True, it's not in the x86_64 repository but x86_64 systems are multilib which means that you can install i686 packages on them.
I don't see many other packages which have a requires on glibc-headers, so I wonder if there is a different way to represent that which doesn't cause problems for multilib systems.
# repoquery --whatrequires glibc-headers cfitsio-devel-0:3.350-2.fc20.i686 cfitsio-devel-0:3.350-2.fc20.x86_64 glibc-devel-0:2.18-11.fc20.i686 glibc-devel-0:2.18-11.fc20.x86_64 glibc-devel-0:2.18-16.fc20.i686 glibc-devel-0:2.18-16.fc20.x86_64 libecb-0:0.20130509-2.fc20.noarch loki-lib-devel-0:0.1.7-8.fc20.i686 loki-lib-devel-0:0.1.7-8.fc20.x86_64 sg3_utils-devel-0:1.37-2.fc20.i686 sg3_utils-devel-0:1.37-2.fc20.x86_64 shedskin-0:0.9-5.fc20.noarch smp_utils-devel-0:0.97-5.fc20.i686 smp_utils-devel-0:0.97-5.fc20.x86_64
Tim
On Mon, Nov 03, 2014 at 08:15:20AM -0500, Scott Talbert wrote:
On Mon, 3 Nov 2014, Petr Pisar wrote:
I emailed the maintainers. They don't seem to think it is a bug because even though glibc-headers 32-bit isn't in the 64-bit repo, someone could still install it.
Frankly I don't understand the error message. They checks miniz-devel.i686 on x86_64. So they checks packages accross different repositories. That does not make much sense. Could send me the contact?
I used the qa-devel mailing list. This is the message exchange: https://lists.fedoraproject.org/pipermail/qa-devel/2014-October/001015.html
Could you explain why you take i686 package from x86-32 repository and check it against x86_64 repository?
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.
-- Petr
Could you explain why you take i686 package from x86-32 repository and check it against x86_64 repository?
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.
-- Petr
Are you building miniz as multilib? Depcheck checks the x86_64 and i686 repos separately; it is not pulling out of the i686 repo here.
John.
On Wed, Nov 05, 2014 at 09:34:44AM -0500, John Dulaney wrote:
Could you explain why you take i686 package from x86-32 repository and check it against x86_64 repository?
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.
Are you building miniz as multilib?
The questions is nonsesne. Building a package in Koji does not have anything to do with multi-lib. Multi-lib is an attribute to a binary package set by release engineers.
Now I checked the x86_64 rawhide repository again, and indeed the i686 miniz package is there. Something is wrong with the script release engineers use for the multi-lib flagging. I will ask them.
-- Petr
On Tue, 4 Nov 2014 14:59:44 +0100 Petr Pisar ppisar@redhat.com wrote:
On Mon, Nov 03, 2014 at 08:15:20AM -0500, Scott Talbert wrote:
On Mon, 3 Nov 2014, Petr Pisar wrote:
I emailed the maintainers. They don't seem to think it is a bug because even though glibc-headers 32-bit isn't in the 64-bit repo, someone could still install it.
Frankly I don't understand the error message. They checks miniz-devel.i686 on x86_64. So they checks packages accross different repositories. That does not make much sense. Could send me the contact?
I used the qa-devel mailing list. This is the message exchange: https://lists.fedoraproject.org/pipermail/qa-devel/2014-October/001015.html
Could you explain why you take i686 package from x86-32 repository and check it against x86_64 repository?
A normal x86_64 system has access to the x86-32 repos and with few exceptions, x86-32 builds are installable via yum or dnf on an x86_64 system.
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'm not quite sure what's going on here but I'm going to dig into it more. Filed a bug:
https://phab.qadevel.cloud.fedoraproject.org/T372
Tim
On Thu, Nov 06, 2014 at 09:10:09AM -0700, Tim Flink wrote:
On Tue, 4 Nov 2014 14:59:44 +0100 Petr Pisar ppisar@redhat.com 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@lists.fedoraproject.org and it's waiting on the moderator now. Once it propagates, I will take down a pointer here.
-- Petr
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@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 is flagged as multi-lib?
Scott
qa-devel@lists.fedoraproject.org
-
John Dulaney -
Petr Pisar -
Scott Talbert -
Tim Flink