Bug 115329

I was able to reproduce the same problem without rebooting

Steps to Reproduce:

1.Upgrade pango-1.2.5-1.1 to pango-1.2.5-4
2.switch to run level 3
3.switch back to run level 5
4.Observe the problem with GDM login screen

I also backed out to 1.2.5-1.1, switched run levels and everything was
back to normal.

I noticed that the file /etc/pango/i386-redhat-linux-gnu/pango.modules
was not readable by "other".  I was able to fix this problem with the
following command:

chmod a+r /etc/pango/i386-redhat-linux-gnu/pango.modules

Hmm, do you have an unusual configuration of your umask? 
the postinstall scriptlet just creates that file with a 
redirection, so I'm suprised it wasn't world readable.

The 1.2.5-1.1 that I had installed had the pango modules config here:
/etc/pango/pango.modules

But when I upgraded to 1.2.5-4 it moved the file here:
/etc/pango/i386-redhat-linux-gnu/pango.modules

I re-installed 1.2.5-4 and setup a symlink:
[/etc/pango]$ ls -l
total 16
drwxr-xr-x    2 root     root         4096 Feb 11 10:02
i386-redhat-linux-gnu
lrwxrwxrwx    1 root     root           35 Feb 11 10:03 pango.modules
-> i386-redhat-linux-gnu/pango.modules
-rw-r--r--    1 root     root        12178 Dec 18 17:00 pangox.aliases

Everything works just fine now, and I did not notice any permissions
issues with my pango configs.

Can you determine why, when you upgraded to 1.2.5-4, it
didn't write the file at the correct location?

(rpm -q --scripts pango will show you the commands that
it runs on upgrade)

I backed out to 1.2.5.1.1 to see why it installed it there

$ rpm -q --scripts pango
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig
/usr/bin/pango-querymodules > /etc/pango/pango.modules
postuninstall program: /sbin/ldconfig


Then reinstalled 1.2.5-4

$ rpm -q --scripts pango
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig
# autoconf changes linux to linux-gnu
case "i386-redhat-linux" in
  *linux) host="i386-redhat-linux-gnu"
  ;;
  *) host="i386-redhat-linux"
  ;;
esac
 
case "$host" in
  alpha*|ia64*|ppc64*|s390x*|x86_64*)
   /usr/bin/pango-querymodules-64 > /etc/pango/$host/pango.modules
   ;;
  *)
   /usr/bin/pango-querymodules-32 > /etc/pango/$host/pango.modules
   ;;
esac
postuninstall program: /sbin/ldconfig

Yes, those are the scriptlets in question :-) What I was hoping
you could help me with is why these scriplets are not working
on your system. Why does 

 /usr/bin/pango-querymodules-32 >
/etc/pango/i386-redhat-linux-gnu/pango.modules
 
Fail?

It doesn't fail, the scriptlets between the 2 versions are different.
 I sent you a separate e-mail with a possible reason that I wanted to
check before I posted it here.  The old version of pango had a
scriptlet that generated the file in /etc/pango, the new version of
pango puts it into the i386-redhat-linux-gnu sub-directory and from
what I can tell its still looking for it in the /etc/pango directory,
since when I put a symlink there everything works.

Is it possible that you have another version of Pango installed
on your system that programs are linking against? 

Can you provide:

 - A strace of a GTK+ program (testgtk, say, from gtk-devel) as:

   strace -e open testgtk

 - The results of 'ldd' run on testgtk

   ldd /usr/bin/testgtk

Created attachment 97587 [details]
strace -e open testgtk

Created attachment 97588 [details]
ldd /usr/bin/testgtk

The strace shows:

 open("/etc/pango/i386-redhat-linux-gnu/pango.modules", O_RDONLY) = 4

So I really don't have any idea why you needed the symlink. I'm
puzzled.

I was able to reproduce it too. After upgrading, rhn-applet-gui as a
regular user shows:

** (rhn-applet:7776): WARNING **: No builtin or dynamically loaded modules
were found. Pango will not work correctly. This probably means
there was an error in the creation of:
  '/etc/pango/pango.modules'
You may be able to recreate this file by running pango-querymodules.


> ls -l /etc/pango/i386-redhat-linux-gnu/pango.modules
-rw-------    1 root     root         4935 Feb 12 11:33
/etc/pango/i386-redhat-linux-gnu/pango.modules

root's umask is 22.

"chmod a+r /etc/pango/i386-redhat-linux-gnu/pango.modules" solves the
problem.

I'm actually puzzled myself.  I just removed the symlink and
everything still works, and there are no permissions problems.  I
wonder if the rpm that I originally downloaded had a problem with the
rpm script.  I downloaded this version direct from Fedora, and it
seems to work.  It's all a mystery to me now.

Have you rebooted or switched runlevels after the removal of the symlink?

I have 4 machines, that behave exactly the same (version 1.2.5-4 does
not work).  However, I did not try any of the above proposals.  No time.

Here is what has happened so far...

Installed 1.2.5-4 (and updated gnome-libs) through up2date/yum
Began noticing new windows had no fonts
Logged out - no fonts on GDM Greeter
Logged in - no fonts anywhere
Force installed previous versions of pango and gnome-libs
switched to runlevel 3 then back to 5
Fonts showed up in GDM, logged in and fonts were back in GNOME.
Logged out Re-installed updated gnome-libs, cycled runlevels and fonts
still worked.
Re-installed pango-1.2.5-4 and cycled runlevels, font problem
returned, so I rolled back again.
Shutdown and went home.
Booted up, had an idea when I noticed the change in location of the
modules file -> installed 1.2.5-4 again and this time setup symlink in
old location pointing to new.
Cycled runlevels, everything worked.
Shutdown again at end of day, today I booted up and after checking
latest bugzilla message attempted to remove symlink.  After removal
and a runlevel cycled for good measure, everything worked.  I have yet
to reboot, but then again the problems cropped up last time without
even a reboot.  My new hunch is that it might be a bug that came about
from having updated pango and not logging out and cycling runlevels to
make sure that GNOME and GDM were looking for the new version.

Go figure??

People, 

Today I installed two fresh Fedora Core 1's; One at my mom's place (A
Dell OptiPlex GX200 666mhz P3 with 256mb ram) and a n Acer Laptop
(Centrino 1.6ghz, 512mb ram). 

After updating to pango 1.2.5-4 I got the weird font problem I saw
some time ago (approx. january) and tried to find out what was wrong.
It turns out the permissions on

/etc/pango/i386-redhat-linux-gnu/pango.modules

are set to 0600, which is kinda strict I think. A quick change of this
to 0644 fixed all weird behaviour (being no fonts in GDM, no fonts for
anything not root).

Out of the posts above I understand that this doesn't happen on all
systems? Does that really matter? it "should" be mode 0644 anyway.
This bug has been open for quite a while and it is kinda hard to
explain this fix to n00bs, so if we could just add a simple chmod 0644
somewhere, a _lot_ of people would be helped.

Keep up the good work,

Rubin (rubin). 

Is this a dup of bug 112387?

This bug just happened to me.

I installed a fresh Fedora Core 1 box. I logged in with the root
account, and used up2date to install all the latest updates.

Upon rebooting, no more text appeared in the GDM login screen.

I downgraded pango to the version from the original CDs, the problem
went away. I then used up2date to update to the latest pango again,
and the problem did not come back.

It seems a fresh installation is broken by this.

No, this isn't a duplicate of bug 112387. I'm not sure
if it's a single bug or multiple bugs, however the permission problems
that some people have been describing don't seem to be the 
same as the original bug report.

Since there haven't been any reported duplicates with FC2 or 
newer, hopefully something has fixed it, though I'm not sure what.

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

Reassigning pango bugs to Behdad.

Fedora Core 1 is 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 FC5 updates or in the FC6 test release, reopen and change the
version to match.

Thanks!

NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.

Considering the previous comments in this bug, this is fixed in all post-FC1
versions, so I'm closing this.