[6168] in Release_7.7_team

home help back first fref pref prev next nref lref last post

firefox 3 printing fix

daemon@ATHENA.MIT.EDU (Robert A Basch)
Thu Jan 15 19:02:09 2009

Message-Id: <200901160002.n0G021q2029572@abulia.mit.edu>
To: release-team@MIT.EDU
Date: Thu, 15 Jan 2009 19:02:01 -0500
From: Robert A Basch <rbasch@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00

Concerning the firefox 3 printing bug on Linux (testers [7791])...

I have verified that the problem is fixed by applying the patch from
"http://bugzilla.gnome.org/show_bug.cgi?id=390159".  I propose using
our blobrpm facility to get this fix into the release ASAP, as
follows:

1) Build the patched lpr backend library:

   * Get the gtk+-2.10.4 source tarball from gnome.org.
   * Apply the patch.
   * Install the evolution28-*-devel RPMs on the build machine
   * Build the package using the /usr/evolution28 prefix.
   * Copy only the lpr backend library from the build tree.

2) Create the blob RPM, containing only the lpr backend library,
   /usr/evolution28/lib/gtk-2.0/2.10.0/i386-redhat-linux-gnu/printbackends/libprintbackend-lpr.so;
   the i386-redhat-linux-gnu directory does not exist now, but is before
   the existing library in the module search path (the buggy library is
   /usr/evolution28/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-lpr.so).

In this way, we can fix the problem by adding the blob RPM to the
release, without having to overwrite the existing library or to adjust
the module search path.  If Red Hat ever releases an update RPM with the
fix, we can just remove the blob RPM from the release.

I realize this is pretty awful, but I think it is the most feasible option
we have to deal with this bug; I doubt that Red Hat will release a fix in
anything like a suitable time frame.

I will work on this solution unless someone has a better idea.  I will,
of course, provide notes on how to build the library and blob RPM.

Thoughts?

Bob

home help back first fref pref prev next nref lref last post