Bug 861824
| Summary: | Error: Multilib version problems found ( depency i686 package in x86_64 ) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | sangu <sangu.fedora> |
| Component: | pycanberra | Assignee: | Mathieu Bridon <bochecha> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | bochecha, elad |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-12-20 16:16:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
From #fedora-desktop: <elad> yaneti: why does gnome-clocks require pycanberra? don't they use gobject-introspection to access such libraries? <yaneti> elad: libcanberra is not introspectable afaik <elad> oh, darn <elad> plus it seems to pull 32bit libcanberra on a 64bit system <elad> that shouldn't happen, the python bindings should use the 64bit lib... <yaneti> hmm, not here it requires /usr/lib64/libcanberra.so.0 <elad> --> Processing Dependency: /usr/lib/libcanberra.so.0 for package: pycanberra-0-0.1.git65c3b3f.fc18.noarch <yaneti> argh, this is because the one here was locally built... thet requires needs rework <elad> libdir defaults to /usr/lib on noarch packages. <elad> so that's why it happened. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers pycanberra-0-0.2.git65c3b3f.fc18, gnome-clocks-0.1.3-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-14937/pycanberra-0-0.2.git65c3b3f.fc18,gnome-clocks-0.1.3-1.fc18 (In reply to comment #1) > From #fedora-desktop: > > <elad> yaneti: why does gnome-clocks require pycanberra? don't they use > gobject-introspection to access such libraries? > <yaneti> elad: libcanberra is not introspectable afaik > <elad> oh, darn > <elad> plus it seems to pull 32bit libcanberra on a 64bit system > <elad> that shouldn't happen, the python bindings should use the 64bit lib... > <yaneti> hmm, not here it requires /usr/lib64/libcanberra.so.0 > <elad> --> Processing Dependency: /usr/lib/libcanberra.so.0 for package: > pycanberra-0-0.1.git65c3b3f.fc18.noarch > <yaneti> argh, this is because the one here was locally built... thet > requires needs rework > <elad> libdir defaults to /usr/lib on noarch packages. To be entirely clear, this is untrue. libdir defaults to the correct value on the machine where the package was built. i686 packages are built on i686 machines, and x86_64 packages are built on x86_64 machines, so they have the correct value of libdir. However, noarch packages can be built on one or the other, so they could very well have a libdir of /usr/lib or /usr/lib64, depending on each build. ----- It doesn't change the fact that I completely screwed up on this one, trying to be clever with the dependencies, and being bitten by the fact that what I intended is not possible on noarch. I edited the update with a new build of pycanberra which should fix the issue. Sorry about the trouble. pycanberra-0-0.2.git65c3b3f.fc18, gnome-clocks-0.1.3-2.fc18 has been pushed to the Fedora 18 testing repository. pycanberra-0-0.2.git65c3b3f.fc18, gnome-clocks-0.1.3-2.fc18 has been pushed to the Fedora 18 stable repository. |
Description of problem: $ yum install pycanberra Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing it that there is a problem. Eg.: [...] Protected multilib versions: libcanberra-0.29-4.fc18.i686 != libcanberra-0.29-5.fc18.x86_64 $ rpm -qRp pycanberra-0-0.1.git65c3b3f.fc18.noarch.rpm /usr/lib/libcanberra.so.0 <-- i686 python(abi) = 2.7 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 Version-Release number of selected component (if applicable): 0-0.1.git65c3b3f.fc18 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: