Description of problem: OO.o2 will not install on x86_64 (through up2date) because it is missing a dependency: libcrux-engine.so. gnome-themes includes the library, but it is found in /usr/lib64/gtk-2.0/2.4.0/engines/libcrux-engine.so (lib64). Since OO.o is i386, it expects the library in /usr/lib/... Version-Release number of selected component (if applicable): gnome-themes-2.8.0-1.x86_64 openoffice.org2-core-2.0.4-5.7.0 How reproducible: Every time. Steps to Reproduce: 1. up2date openoffice.org2-core Actual results: Unresolvable chain of dependencies: openoffice.org2-core 2.0.4-5.7.0 requires libcrux-engine.so Is there some reason that we don't have an x86_64 version of OO.o2?
I don't see that there's a bug here for me to fix, this is a i386 OOo so it needs an i386 gnome-themes not an x86_64 gnome-themes. They should be installable in parallel. The dependency chain should have pulled in a 32bit gtk stack from gnome-themes downwards. An x86_64 RHEL-4 OOo2 2.0.4 was not provided because there was no x86_64 OOo 1.1.X for RHEL-4, and because the state of e.g. 64bit java/gcj on RHEL-4 is even more of a mess than the 32bit java RHEL-4 world
I agree that this is really a RHN bug. Which compontent should I change it to so the RHN folks can look at this? Thanks for the information (and the laugh) about 64-bit OOo.
You only have the 64bit gnome-themes installed in the above afaics, What happens if you repeat the above test after installing gnome-themes-2.8.0-1.i386 ?
That just enables building the native x86_64 OOo port which I considered too experimental and too much effort to build for RHEL-4 even for the tech preview.
Since an x86_64 native build is going to be such a problem then perhaps a change to the spec file for OOo by adding gnome-themes-2.8.0-1.i386 would make more sense ? At least it does for me. Issue escalated to RHEL 4 Desktop by: alanm. Internal Status set to 'Waiting on Engineering' This event sent from IssueTracker by alanm issue 122938
I was just able to successfully install OO.o2 on x86_64. The dependency issues seem to be resolved.
Oops, I mistakenly ran it on an i386 system. x86_64 is still broken. Here are the new dependency errors: Unresolvable chain of dependencies: openoffice.org2-core 2.0.4-5.7.0.1.0 requires libcrux-engine.so openoffice.org2-core 2.0.4-5.7.0.1.0 requires libnspr4.so openoffice.org2-core 2.0.4-5.7.0.1.0 requires libnss3.so openoffice.org2-core 2.0.4-5.7.0.1.0 requires libplc4.so openoffice.org2-core 2.0.4-5.7.0.1.0 requires libplds4.so openoffice.org2-core 2.0.4-5.7.0.1.0 requires libsmime3.so openoffice.org2-core 2.0.4-5.7.0.1.0 requires libsoftokn3.so openoffice.org2-core 2.0.4-5.7.0.1.0 requires libssl3.so
this needs to be assigned to the right owner so that it doesn't get lost. As this not an up2date issue, I'm not the right owner for this bug. Could you please assign this to whoever owns openoffice.org ?
There is no bug in the OOo rpms AFAICS, there was no native x86_64 OOo2 rpm provided, and a Requires on libcrux-engine.so was inserted deliberately to ensure that if the 32bit OOo2 was installed on 64bit that the necessary but otherwise not auto-required runtime 32bit dependencies are pulled in. Apparently they are not being pulled in on RHEL-4 because the required 32bit packages are not automatically available on the 64bit channel. I know nothing about how all that works, but comment #5 looks sort of the right thing. Of course I could always enable building the 64bit OOo (i.e. #6 and #9) which I guess sidesteps some of this foo and confusion, and I'm tempted to do that if we ever have to otherwise respin the OOo2 for RHEL-4.
Since the root issue appear to be a missing mulitlib package, I'm reassigning this bug to myself and changing the component to comps.
re: Caolan, what do you think? sure, dropping emailmerge and pyuno is no biggy for the tech preview from my POV
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2007-0866.html