These are all i386 packages in x86_64, so it seems some multi-lib
related stuff is out-of-date:
source rpm: bind-9.3.4-3.fc6.src.rpm
package: bind-devel - 31:9.3.4-3.fc6.i386 from fedora-core-updates-6-x86_64
source rpm: compiz-0.3.6-2.fc6.src.rpm
package: compiz-devel - 0.3.6-2.fc6.i386 from fedora-core-updates-6-x86_64
source rpm: kdeedu-3.5.6-0.1.fc6.src.rpm
package: kdeedu - 3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64
source rpm: kdeutils-3.5.6-0.1.fc6.src.rpm
package: kdeutils-devel - 6:3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64
source rpm: opal-2.2.5-1.fc6.src.rpm
package: opal-devel - 2.2.5-1.fc6.i386 from fedora-core-updates-6-x86_64
source rpm: poppler-0.5.4-5.fc6.src.rpm
package: poppler-devel - 0.5.4-5.fc6.i386 from fedora-core-updates-6-x86_64
how are you generating this list of broken deps? I thought the update tool was
doing a repoclosure to make sure we didn't have broken things.... Luke?
They are found and ignored when running extras-repoclosure. The full
logs are in /srv/extras-push/work/extras-repoclosure/rc-fe*.txt
on buildsys.fedoraproject.org -- I only noticed them when I started
doing experiments with running extras-repoclosure on temporary repos
built from the needsign queue.
I did a "full" install of Core 6 for x86_64, then just did a yum update with
updates and updates-testing enabled. There were no conflicts or unresolved deps
listed. Could repoclosure be finding false negatives?
Can you prove that for any of the reports?
As a specific question, what provides libpython2.4.so.1.0 and
yumibdns.so.22 on that test machine?
Notice that both are 32-bit libraries which are not available in form of
i386 packages in the x86_64 repositories.
I'm pretty sure we blacklisted some of those packages from being multilib. I've
already re-installed the box in question, so I don't have access to it again,
guess I'll have to do another install.
Why spend time on a test-install?
These broken deps are easy to verify, e.g.
bind-devel.i386 requires i386 sonames from bind.i386, but bind.i386
is not available in the x86_64 repo.
Most likely you installed only x86_64 devel packages.
Same game for the other i386 -devel packages in the broken deps list.
And kdeedu.i386 requires i386 Python, which is not available either.
No, I did a full install and didn't strip the x86_64. By default I get all i386
that is available for the packages I selected. I'll verify again, but i think
we "fixed" the glitch with many of these by fixing up the packaging in further
In rawhide? - Yes.
In FC6 Release Updates? - No.
FC6 is what I installed.
Well, if you can tell me what packages in the x86_64 repositories
provide the 32-bit SONAMEs, which repoclosure lists as missing, we
could close this ticket quickly.
I cannot assist further than pointing out that the packages are
missing in base, updates-released and updates-testing.
Indeed. I can confirm the problem here.
Once you have an x86_64 box you need to issue:
yum install kdeedu.i386
Just doing yum update will only update what was installed on the machine. I'm
guessing anaconda didn't install the i386 version of those packages for some
reason. perhaps the packages are in the update repo but not in Core final or
anaconda handles broken-deps differently than yum.
Ah, yes kdeedu was NOT multilib in stock FC6, an update must have been pushed
that accidentally made it multilib.
Really these problems are a bit hard to track all in one bug. Michael, can you
file new bugs for each of these packages, against the package and cc me on them?
We'll need to tackle these one at a time anyway, and that's going to be too
noisy for just one bug.
I'm closing this now confusing bug. Individual bugs need to be filed for
specific multilib cases.