Bug 239948 - Failing to bring in i386 packages as needed
Summary: Failing to bring in i386 packages as needed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora Hosted Projects
Classification: Retired
Component: mock
Version: unspecified
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Clark Williams
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-13 04:09 UTC by John Morris
Modified: 2013-01-10 04:18 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-06 17:54:06 UTC
Embargoed:


Attachments (Terms of Use)

Description John Morris 2007-05-13 04:09:49 UTC
Description of problem:

mock and/or yum is failing to bring in i[36]86 packages as needed to satisfy
build deps, appearing instead to simply add a second requirement for the x86_64
package.

Version-Release number of selected component (if applicable):

mock-0.6.13-1

How reproducible:

Always

Steps to Reproduce:
1.  mock --debug --autocache rebuild SRPMS/compat-gcc-32-3.2.3-61.src.rpm
(or gcc-4.1 but this one is smaller.)

Actual results:

Failure, specifically:
In file included from /usr/include/features.h:352,
                 from /usr/include/signal.h:29,
                 from ../../gcc/config/i386/linux64.h:77,
                 from tconfig.h:23,
                 from ../../gcc/libgcc2.c:40:
/usr/include/gnu/stubs.h:7:27: gnu/stubs-32.h: No such file or directory

Oops, obviously no glibc-devel.i386 was pulled in, lets go to the tape for an
instant replay:

DEBUG: Executing /usr/sbin/mock-helper yum --installroot
/var/lib/mock/wbel-5-x86_64/root resolvedep  'zlib-devel' 'flex'
'/lib64/libc.so.6' 'dejagnu' '/usr/lib64/libc.so' '/lib/libc.so.6' 'binutils >=
2.16.91.0.5-1' 'gettext' 'bison' '/usr/lib/libc.so' 'glibc-devel >= 2.2.90-12'
'texinfo'
0:zlib-devel-1.2.3-3.x86_64
0:flex-2.5.4a-41.el5.x86_64
0:glibc-2.5-12.x86_64
1:dejagnu-1.4.4-5.1.noarch
0:glibc-devel-2.5-12.x86_64
0:glibc-2.5-12.x86_64
0:binutils-2.17.50.0.6-2.el5.x86_64
0:gettext-0.14.6-4.el5.x86_64
0:bison-2.3-2.1.x86_64
0:glibc-devel-2.5-12.x86_64
0:glibc-devel-2.5-12.x86_64
0:texinfo-4.8-14.el5.x86_64

Don't know enough of the guts of yum, python or rpm to feel confident of diving
into that mess and producing a fix that won't make things worse elsewhere.

Comment 1 Jan Kratochvil 2007-06-07 12:32:54 UTC
There is intentional suppression of i386 rpms for x86_64 builds:
/etc/mock/fedora-6-x86_64-core.cfg:
exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86
g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i?86

Red Hat us using in some repositories glibc32.x86_64 with glibc.i386 32-bit
files packaged into x86_64 rpm.  Not sure where these packages should be present
in the Fedora repositories.

Another problem is that this unsatisfied dependency is not reported - Bug 243117.


Comment 2 John Morris 2007-06-07 22:28:06 UTC
A specific exclusion, such as the default FC6 config is not a bug.  That isn't
what is happening here.  My config currently has no exclude lines, but is using
a x86_64 package tree with only the three must have i[36]86.rpms to allow gcc &
friends to rebuild.

In the dump above, a specific dependency for a library in glibc.i686 appears to
be being transformed into a dup for glibc.x86_64.  No doubt it is related to the
problem of normally wanting to supress the normal practice of yum wanting to
install both arches of darned near the whole distro if the packages are
available to it.  Perhaps a switch to supress that behaviour for the few
packages that it breaks would be good enough.

Comment 3 Fedora Update System 2007-06-14 21:12:03 UTC
mock-0.7.1-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

Comment 4 Jesse Keating 2007-06-16 12:04:42 UTC
This is still not fixed.  It appears the config change I made got lost in some
shuffling.  I've committed a config change to HEAD that should fix this.

Comment 5 Clark Williams 2008-03-07 20:38:32 UTC
Is this still a bug in mock-0.9?

Comment 6 Clark Williams 2009-02-06 17:54:06 UTC
Looks like this is fixed as of F10


Note You need to log in before you can comment on or make changes to this bug.