On Fri, 2012-10-26 at 05:27 -0600, Sankar P wrote: > > >>> On 10/26/2012 at 04:47 PM, in message > <[email protected]>, Dimstar / Dominique > Leuenberger <[email protected]> wrote: > > On Fri, 2012-10-26 at 05:05 -0600, Sankar P wrote: > > > > What files do you have in /etc/pango/ ? I somewhat presume there is a > > > > stale cache file (newer pango moved the cache to %{_libdir}. but the one > > > > in /etc precedes IIRC. > > > > Ok, that's what I expected... can you check if this file is owned by any > > package? (rpm -qf) > > > > This file is owned by libpango-1_0-0-32bit-1.30.1-1.1.2.x86_64 > > which seem to have come as a dependency for a proprietary product (GW client) > :( >
Why don't you upgrade libpango-1_0-0-32bit to 1.32 as well in this case? This would be the correct fix to your issue I guess (you must have the 64bit version updated to 1.32) > > The best 'solution' at this moment is to delete the > > file /etc/pango/pango.modules; this will have pango go to the right > > modules in /usr/lib(64)?/pango/1.8.0. > > > > Thanks. > > But should this be not a bug ? The "-32bit" compat packages should create its > cache/config file(s) in some other location so that they can co-exist with > the 64 bit versions ? Up to 1.30 we carried a patch that made two config files, 32 and 64bit; pango was simply not bi-arch aware. This was changed with version 1.32 and the patch is gone... but the old fallback code to use /etc/pango is in place (from upstream) and unaware of bi-arch. Dominique -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
