Bug 136754

Dan, did something change here? The FC2 redhat-artwork has a
multilib-conflict which has been fixed later. Do i need to release an
update for it?

Could you do that?  The new OOo links to GTK and uses the GTK
filechooser, this was to fix another bug for x86_64 where GTK would
use the built-in theme rather than Bluecurve on a default install
becuase it couldn't find the 32-bit libbluecurve.so, along with all
the icons and whatnot for that theme.  If you could release a
multi-lib redhat-artwork as an FC2 update, that would be great.

*** Bug 136776 has been marked as a duplicate of this bug. ***

*** Bug 136823 has been marked as a duplicate of this bug. ***

From the text before I understand the bug has been fixed in some way.
I still get the same error 26 October. To this date OOo won install
due to conflict. Error messg same as in 1st bugreport, I see no change.

I'd like to see this bug escalated to security level because this
problem is preventing all automatic nightly yum updates from running
on x86_64, and those updates include security updates xpdf-3.00-3.4
and cups-1.1.20-11.6 (so far).

Those needing a security workaround can do:
yum -y update xpdf cups
...and monitor for more security updates until this is resolved.

--jh--

Looks to me like redhat-artwork-0.96-2 fixes the problem, and it's
been released.  Had the problem on a x86-64 machine, now updates.

In my case, I have updated to redhat-artwork-0.96-2 and,
unfortunately, the problem with updating OpenOffice still persists.

I also tried to manually upgrade the OpenOffice packages, no luck either:

  >rpm -Uvh openoffice.org-*
  error: Failed dependencies:
  libbluecurve.so is needed by openoffice.org-1.1.2-10.fc2

As Joe Harrington pointed out earlier, this is becoming a security
issue, since it prevents other updates from being performed.

Please let me know if I can provide any further information in order
to help fixing this problem.

Best regards,
Sebastian Paul Avarvarei

Everything is right with the new packages, and if you let yum work out
the dependencies everything will install fine.  If you insist on doing
it manually, make sure you have both i386 and x86_64 versions of
redhat-artwork-0.96-2 installed.  The openoffice packages are built
for i386, so you need the i386 bluecurve.so.

Sorry if I have not expressed myself correctly. I don't "insist" on 
doing things manually.




I did let up2date/yum to update redhat-artwork. And then I ran 
up2date again in order to update OpenOffice. But this failed again, 
with the same error I was getting when redhat-artwork-0.96-1 was 
installed.




I provided the output of manually running "rpm -Uvh" just in case it 
would help with anything.




If any other information would be of help, please let me know.




Best regards,


Sebastian Paul Avarvarei

Can you do this?

rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\n"
redhat-artwork

I personally took an x86-64 system with FC2 and successfully did an
upgrade of OOo.  It _did_ fail before I installed the i386 version of
redhat-artwork-0.96-2 using a manual RPM.  I then updated
openoffice.org using yum.  This really should work, it was flawless
for me.

The new packages worked for me on x86_64.  The only manual updates I
did were xpdf and cups, as above.  My system's nightly yum update took
the OOo updates the night redhat-artwork-0.96-2 got posted.  I have an
"everything" install.

Thanks to those who got on the ball and fixed this!

--jh--

Yes, what I have in the system is redhat-artwork-0.96-2-x86_64. If I
would manually install the i386 version probably the auto-update of
OpenOffice will work too.

But I don't think this can really be called a solution. The whole
point of using up2date is to be able to automate the updating process.

What I would consider a solution would be to either:
1. Modify the redhat-artwork x86_64 rpm so it provides what OpenOffice
needs.
2. Modify at least the OpenOffice rpm so it will include the i386
version of redhat-artwork in its requirements, so the up2date process
would install it automatically.

Best regards,
Sebastian

No, that's not the way it works Sebastian.

You point yum/up2date at repositories of RPMs.  Contained in those
repositories are the RPMS you need.  If they aren't there, it won't
work.  But they _are_ there:

http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/x86_64/redhat-artwork-0.96-2.i386.rpm

Note that this is the _i386_ RPM but its in the x86_64 repository. 
That's multilib for you.  But if you use yum it _will work_.

You can't just modify OOo to use the x86_64 RPM, because the bits that
OOo needs are 32-bit, and the x86_64 RPM doesn't provide anything
that's 32-bit.  That's why the i386 redhat-artwork RPM is there,
that's what OOo needs.  If you did a fully automatic update pointed at
the right place, you'd have no problems.  You need to install BOTH the
x86_64 and the i386 redhat-artwork RPMs, this is normal.

Stick this in your /etc/yum.conf file, run 'yum update openoffice.org'
and you'll be fine:

[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
retries=20

[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/

[updates]
name=Fedora Core $releasever - $basearch - Updates
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/

This still can't be called a solution. The point is quite simple:
redhat-artwork breaks the auto-update for OpenOffice. Any discussion
about manually installing packages or manually running yum is, in my
opinion, pretty much besides the point.

And yes, I was using the standard yum.conf as it was installed by
Fedora, only modified it to point to a mirror.

Anyway, if you don't want to acknowledge this as a bug, that's your
choice. Why should I bother?

No, I'm trying to say I don't understand what's different about your
situtation.  The current updates tree is as normal AFAIK, everything
is as it should be.  I don't understand why that's not working for
you.  I'm not saying its not a bug.

Can you paste the output of 'yum update openoffice.org' and the
contents of your yum.conf file?

Thanks!
Dan

Sorry, too late. I installed redhat-artwork i386 manually to get it
over with, as this already took too much of my time.

But you can reproduce the error yourself quite easily: just install a
new FC2 system and run up2date.

Can you paste in your copy of /etc/sysconfig/rhn/sources so I can try
to duplicate then?  Let me repeat that this worked for me with yum,
but I haven't tried up2date, so that may be the issue.

Created attachment 106015 [details]
yum.conf

Created attachment 106016 [details]
sysconfig/rhn/sources

Please find attached the requested config files - I included yum.conf
too, in case it might help with anything.

Ok, in your yum.conf file you have a bad URL for the updates-released,
which might be the problem:

baseurl=http://ftp.lug.ro/fedora/linux/core/2/updates/$releasever/$basearch/os/

That URL returns an error since its actually
fedora/linux/core/updates/2 rather than fedora/linux/core/2/updates.

All other updates (except redhat-artwork and OpenOffice) ran very 
well, so I would doubt that this was indeed the problem.

Created attachment 106267 [details]
Output of up2date openoffice.org showing entire session and problem

Reading other comments it sounded like somebody wanted to see an example.
Here's mine, if it can help.

Thanks,

David

*** Bug 138410 has been marked as a duplicate of this bug. ***

Adrian:  seems to be only up2date that has this issue.  yum deals with
it fine.

sounds like a bug I fixed in 4.3.56, can someone
try it with 4.3.56?

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

no response in nearly a year from reporter... closing.