Bug 115329 - pango-1.2.5-4 does not render fonts for regular users
Summary: pango-1.2.5-4 does not render fonts for regular users
Alias: None
Product: Fedora
Classification: Fedora
Component: pango   
(Show other bugs)
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Behdad Esfahbod
QA Contact:
: 117254 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-02-10 21:22 UTC by Frank Bures
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version: fc2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-25 19:11:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace -e open testgtk (28.59 KB, text/plain)
2004-02-11 19:02 UTC, James Walton
no flags Details
ldd /usr/bin/testgtk (1.38 KB, text/plain)
2004-02-11 19:03 UTC, James Walton
no flags Details

Description Frank Bures 2004-02-10 21:22:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4.1)

Description of problem:
After upgrade to pango-1.2.5-4 from the original Fedora1
distribution version 1.2.5-1.1 no fonts are rendered for regular
users.  The login screen does not contain any visible text.
If one blindly logs in as root, then the fonts are rendered.
In case of login as non-root, no fonts are rendered.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Upgrade pango-1.2.5-1.1 to pango-1.2.5-4
3.Observe the problem

Actual Results:  No fonts are rendered on the login screen.

Expected Results:  Normal login screen

Additional info:  Downgrade to 1.2.5-1.1 solves the problem

Comment 1 James Walton 2004-02-10 22:26:29 UTC
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.

Comment 2 Tom Parks 2004-02-11 14:53:04 UTC
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

Comment 3 Owen Taylor 2004-02-11 15:04:05 UTC
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.

Comment 4 James Walton 2004-02-11 15:21:35 UTC
The 1.2.5-1.1 that I had installed had the pango modules config here:

But when I upgraded to 1.2.5-4 it moved the file here:

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

Comment 5 Owen Taylor 2004-02-11 16:51:59 UTC
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)

Comment 6 James Walton 2004-02-11 17:04:44 UTC
I backed out to to see why it installed it there

$ rpm -q --scripts pango
postinstall scriptlet (using /bin/sh):
/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):
# autoconf changes linux to linux-gnu
case "i386-redhat-linux" in
  *linux) host="i386-redhat-linux-gnu"
  *) host="i386-redhat-linux"
case "$host" in
   /usr/bin/pango-querymodules-64 > /etc/pango/$host/pango.modules
   /usr/bin/pango-querymodules-32 > /etc/pango/$host/pango.modules
postuninstall program: /sbin/ldconfig

Comment 7 Owen Taylor 2004-02-11 17:18:56 UTC
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 >

Comment 8 James Walton 2004-02-11 18:02:52 UTC
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.

Comment 9 Owen Taylor 2004-02-11 18:40:19 UTC
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

Comment 10 James Walton 2004-02-11 19:02:20 UTC
Created attachment 97587 [details]
strace -e open testgtk

Comment 11 James Walton 2004-02-11 19:03:07 UTC
Created attachment 97588 [details]
ldd /usr/bin/testgtk

Comment 12 Owen Taylor 2004-02-11 22:20:54 UTC
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

Comment 13 Need Real Name 2004-02-12 10:38:28 UTC
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:
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

root's umask is 22.

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

Comment 14 James Walton 2004-02-12 14:00:53 UTC
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.

Comment 15 Frank Bures 2004-02-12 15:28:58 UTC
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.

Comment 16 James Walton 2004-02-12 15:41:12 UTC
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??

Comment 17 Rubin Simons 2004-03-27 15:49:48 UTC

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


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@vt100.nl). 

Comment 18 Leonard den Ottolander 2004-04-19 13:54:56 UTC
Is this a dup of bug 112387?

Comment 19 Marc Deslauriers 2004-08-28 14:46:46 UTC
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.

Comment 20 Owen Taylor 2004-09-09 19:21:51 UTC
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.

Comment 21 Owen Taylor 2004-09-09 19:42:36 UTC
*** Bug 117254 has been marked as a duplicate of this bug. ***

Comment 22 Matthias Clasen 2006-06-20 05:12:01 UTC
Reassigning pango bugs to Behdad.

Comment 23 Matthew Miller 2006-07-11 17:38:38 UTC
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.


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.

Comment 24 John Thacker 2006-10-25 19:11:28 UTC
Considering the previous comments in this bug, this is fixed in all post-FC1
versions, so I'm closing this.

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