Bug 222217 - pango 20070110 update makes a lot programs unhappy
pango 20070110 update makes a lot programs unhappy
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pango (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Behdad Esfahbod
:
: 225503 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-10 17:00 EST by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-12 15:58:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-01-10 17:00:54 EST
Description of problem:

After an update to pango-1.15.3-2.fc7 one can find right away in
~/.xsession-errors (multiple times and this is only a small sample -
actually ~/.xsession-errors grows really quickly):

(bug-buddy:5875): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(bug-buddy:5875): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(gnome-desktop-item-edit:6026): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(gnome-desktop-item-edit:6026): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(gnome-panel:5807): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(gnome-panel:5807): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(gvim:5901): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(gvim:5901): Pango-WARNING **: /usr/lib64/pango/1.6.0/modules/pango-basic-fc.so:
cannot open shared object file: No such file or directory
(gvim:5979): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(gvim:5979): Pango-WARNING **: /usr/lib64/pango/1.6.0/modules/pango-basic-fc.so:
cannot open shared object file: No such file or directory
(nautilus:5809): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(nautilus:5809): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
Window manager warning: Log level 16: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
Window manager warning: Log level 16:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory

Correct. There is no such file or directory.  There are eight script
specific "pango-*-fc.so" files, from "arabic" to "tibetan", but only
pango-basic-x.so.  As I do not recall such complaints in the past
I gather that this something new and the file in question used to
exist.  Forgotten or anything which refers to it has to be recompiled?
Not sure if SIGSEGV in gnome-terminal and bug-buddy are directly
related.  Other things seem to whine and still run.

Version-Release number of selected component (if applicable):
pango-1.15.3-2.fc7
Comment 1 Behdad Esfahbod 2007-01-10 17:32:02 EST
SIGSEGV in gnome-terminal is a separate issue and should be fixed in
vte-0.15.1-2 that hit rawhide today.

As for this bug, no, the basic-fc module is not forgotten.  It's not compiled
into the pangoft2.so file, for performance reasons.  This only affects
applications running at the time of the update.  Restarting apps should fix it.
 If it doesn't, something's going wrong.
Comment 2 Michal Jaegermann 2007-01-10 21:08:15 EST
> This only affects applications running at the time of the update.
> Restarting apps should fix it.

In that case something is really wrong.

Just to be sure that I have no strays I rebooted and before
starting a gnome session I checked from a remote that .xsession-errors
does not exist.  Immediately after logging into a section on a desktop
and starting rxvt I collected the following:

(gnome-panel:2770): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(gnome-panel:2770): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(gnome-panel:2770): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(gnome-panel:2770): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(gnome-panel:2770): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(gnome-panel:2770): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(nautilus:2772): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(nautilus:2772): Pango-WARNING **: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
(nautilus:2772): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(nautilus:2772): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
(nautilus:2772): Pango-WARNING **:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
Window manager warning: Log level 16:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
Window manager warning: Log level 16: Failed to load Pango module
'/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so' for id 'BasicScriptEngineFc'
Window manager warning: Log level 16:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory
Window manager warning: Log level 16:
/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so: cannot open shared object
file: No such file or directory

Perfomance, eh?
Comment 3 Behdad Esfahbod 2007-01-10 23:03:58 EST
Does running "grep basic-fc /etc/pango/*/pango.modules" produce any output?

And what does "rpm -q pango" say?

Just upgraded an x86_64 machine of mine and it works as expected.  Something
seems broken with your setup.  Seems like you have a stale pango.modules file.
Comment 4 John Ellson 2007-01-10 23:24:00 EST
I'm having the same problem.   For me, running "grep basic-fc
/etc/pango/*/pango.modules" produces:

/usr/lib64/pango/1.6.0/modules/pango-basic-fc.so BasicScriptEngineFc
PangoEngineShape PangoRenderFc armenian:* bopomofo:* cherokee:* coptic:*
cyrillic:* deseret:* ethiopic:* georgian:* gothic:* greek:* han:* hiragana:*
katakana:* latin:* ogham:* old-italic:* runic:* canadian-aboriginal:* yi:*
braille:* cypriot:* limbu:* osmanya:* shavian:* linear-b:* ugaritic:*
glagolitic:* cuneiform:* phoenician:* common:

Commenting out this line seems to fix the problem.

"rpm -q pango" returns:

pango-1.15.3-2.fc7.x86_64

I have no i386 packages installed on this system.
Comment 5 Behdad Esfahbod 2007-01-11 01:39:30 EST
Thanks John.  And what's the output of "ls /etc/pango"?  And the modification
time of /etc/pango/*/pango.modules file you modified?  Guess you modified it, so
you don't know :).
Comment 6 Michal Jaegermann 2007-01-11 01:53:08 EST
> And what does "rpm -q pango" say?

As I wrote:
"Version-Release number of selected component (if applicable):
pango-1.15.3-2.fc7"

"grep basic-fc /etc/pango/*/pango.modules" does produce the
same output as in comment #4.  /etc/pango/x86_64-redhat-linux-gnu/pango.modules
is the only file present which fits that pattern,
'rpm -qf /etc/pango/x86_64-redhat-linux-gnu/pango.modules' prints
pango-1.15.3-2.fc7 and this one is silent:
'rpm -qVf /etc/pango/x86_64-redhat-linux-gnu/pango.modules'

OTOH looking at 'rpm -q --scripts pango' it is clear that this file
is created by /usr/bin/pango-querymodules-64 and there is no
"basic-fc" pattern in an output of this command.  Which really means
that 'yum' is screwing us up because it first installs new 'pango'
package, while old modules are still around, and only later removes
old ones.  This ordering created problems on other ocassions too
(although I do not remember specifics at this moment).  Recreating
'pango.modules' file(s) indeed solves the issue.

I think that you can work around by dumping old modules in '%pre' so
they are not available when pango-querymodules-64 or pango-querymodules-32
runs in '%post'.

Oh, I see.  You are effectively hardwiring $host into postinstall
scriptlet so the correct one will run if both pango.x86_64 and
pango.i386 are installed.
Comment 7 Behdad Esfahbod 2007-01-11 02:14:56 EST
Well, apparently this only happens if just the x86_64 version of pango is
installed.  So I guess the old modules are not the problem.  We actually seem to
have a similar problem with fontconfig.

My current guess is that the computed host value is screwing up here, but don't
have much evidence for that.  What might be an evidence is the modification time
of the pango.modules file.
Comment 8 Michal Jaegermann 2007-01-11 02:29:08 EST
> What might be an evidence is the modification time
> of the pango.modules file.

A mod time on this file coincided with "Install Date:" which was
my first clue that the file was created by one of package scripts.
Right now, obviously, is different as in the meantime I run

 /usr/bin/pango-querymodules-64 >  \
       /etc/pango/x86_64-redhat-linux-gnu/pango.modules

which, like I said, made the issue to vanish.  The only line in
new 'pango.modules' which has 'basic' in it looks like this:

/usr/lib64/pango/1.6.0/modules/pango-basic-x.so BasicScriptEngineX
PangoEngineShape PangoRenderX common:
Comment 9 John Ellson 2007-01-11 09:05:32 EST
Re Comment #5.  Yes, sorry, my modification to the file lost the original
timestamp, but running "rpm -Uvh --replacepkgs pango-1.15.3-2.fc7.x86_64.rpm"
does refresh the pango.modules file, and doing this removed my commented line
and did not add back pango-basic-fc.so.

"ls /etc/pango" returns:

pangox.aliases  x86_64-redhat-linux-gnu
Comment 10 Michal Jaegermann 2007-01-11 10:50:31 EST
> and doing this removed my commented line
> and did not add back pango-basic-fc.so.

This is not surprising at all as the file in question is generated
while you are installing.

The only chance to recreate the problem would be to revert to the
previous version of pango, the one which presumably had
pango-basic-fc.so module, and after that

   yum localinstall pango-1.15.3-2.fc7.x86_64.rpm

Mind you, 'rpm -Fvh pango-1.15.3-2.fc7.x86_64.rpm' will be not
good enough.

Unfortunately not so long time ago I accidentally destroyed my
cache of older packages.
Comment 11 John Ellson 2007-01-11 11:48:44 EST
I have pango-1.14.0-2.x86_64.rpm and pango-1.15.2-1.fc7.x86_64.rpm in my cache.
 Installing pango-1.14.0-2.x86_64.rpm reinstated
the pango-basic-fc.so in /etc/pango/x86_64-redhat-linux-gnu/pango.modules.

Upgrading directly to pango-1.15.3-2 worked OK and removed the pango-basic-fc.so
line.

Reinstalling pango-1.14.0-2, then upgrading in two steps: pango-1.15.2-1 then
pango-1.15.3-2, leaves me with the problem again.


Comment 12 Behdad Esfahbod 2007-01-11 13:15:23 EST
True, upgrading from 1.14.x doesn't hit the bug since 1.14 stores its modules in
a different dir.

The bug can be closed, because it will not be hit when upgrading from FC6, but I
like to figure exactly what's going on first, and try to fix it.
Comment 13 Behdad Esfahbod 2007-01-11 16:47:49 EST
Ok, you are right.  This is because %post is run before the old package is removed.

I first moved the pango.modules generation to %posttrans.  Should do it.  This
is what's in pango-1.15.3-3.

However, seems like we should avoid %posttrans at all expenses.  So I backed
that up, and instead put pango.modules regeneration code in %postun.  The idea
is to avoid similar problems in the future.

For the actual problem in this bug, there's not much that can be done without
posttrans or triggers.  So, we're gonna just ignore it.  It only happens when
updating from rawhide.  FC6->FC7 is not a problem, and future packages shouldn't
have this problem.
Comment 14 Michal Jaegermann 2007-01-11 18:30:36 EST
> instead put pango.modules regeneration code in %postun

Eh?  This runs post uninstall and that means that if you are
installing pango "fresh", or if you first just replaced old
version with a new one (because you are running
'rpm -Fvh pango-<something>.rpm') then 'pango.modules' will be
not generated or you will do that with possibly wrong modules -
like an empty set.  Without yum you are not reversing a "natural"
order and apart of that you may also just plain uninstall and that
will mean, among other things, that you generation utility
will be simply not available.

It seems to me that to avoid problems you really have to run
that regeneration twice, in %post and %postun, check that there
is indeed something to run and possbily suppress errors if lack
of modules would make 'pango-querymodules*' unhappy.  Costs are
negligible but a comment would be highly desirable. :-)
Comment 15 Behdad Esfahbod 2007-01-12 15:58:34 EST
(In reply to comment #14)
> > instead put pango.modules regeneration code in %postun
> 
> Eh?  This runs post uninstall and that means that if you are
> installing pango "fresh", or if you first just replaced old
> version with a new one (because you are running
> 'rpm -Fvh pango-<something>.rpm') then 'pango.modules' will be
> not generated or you will do that with possibly wrong modules -
> like an empty set.  Without yum you are not reversing a "natural"
> order and apart of that you may also just plain uninstall and that
> will mean, among other things, that you generation utility
> will be simply not available.
> 
> It seems to me that to avoid problems you really have to run
> that regeneration twice, in %post and %postun, check that there
> is indeed something to run and possbily suppress errors if lack
> of modules would make 'pango-querymodules*' unhappy.  Costs are
> negligible but a comment would be highly desirable. :-)

That's exactly what I did.  My description was a bit vague.  Lets close.  Humm,
what to?
Comment 16 Behdad Esfahbod 2007-01-30 21:43:17 EST
*** Bug 225503 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.