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.

> 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?

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.

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.

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 :).

> 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.

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.

> 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:

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

> 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.

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.

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.

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.

> 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. :-)

(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?

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