Red Hat Bugzilla – Bug 173602
Location of "XScreenSaver" app-defaults file needs update for modular X
Last modified: 2007-11-30 17:11:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051018 Epiphany/1.8.2
Description of problem:
The location of the "XScreenSaver" app-defaults file has not
yet been adapted to modular X. It can still be found in its
old place which was "/usr/X11R6/lib/X11/app-defaults".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Check content of "/usr/X11R6/lib/X11/app-defaults".
Actual Results: There is a a file! Its name: "XScreenSaver".
Expected Results: File "XScreenSaver" should be in "/usr/lib/X11/app-defaults".
Actually, where must XScreenSaver.ad in xscreensaver-4.22/driver
directory of the source be installed?
When I switched to modular X by upgrading rpms repeatedly, xscreensaver came to
fail to load XScreensaver file in /usr/X11R6/lib/X11/app-defaults
directory (see the attached image files below). After some investigation, I
found that XrmGetResource in get_string_resource() function in
utils/resources.c fails each time it is called.
After I moved XScreenSaver
to /usr/lib/X11/app-defaults or /usr/share/X11/app-defaults (by libXt-0.99.2-2
changelog: now my XScreenSaver file is here, this problem remained.
For now, I have to deal with the X environment ( I don't know well ) like
"XAPPLRESDIR=/usr/share/X11/app-defaults xscreensaver -nosplash". I don't know
if this problem is whether by my dirty upgrading or by xscreensaver program
Created attachment 121798 [details]
lock screen under modular X rpm
xscreensaver lock screen with xscreensaver-4.22-19 and development
modular X rpm (I don't know what X rpm is really related to the
problem I commented above).
The lock panel title is set as "Screen Locked" by passwd.heading.label
but in the real lock screen, its setting is ignored (unloaded) and
the title reads "XScreenSaver 4.22".
Created attachment 121799 [details]
lock screen with setting X environment
Lock screen with the same rpms but with setting X environment like
This lock screen is the expected one.
My comment 1 was a bit wrong.
I verified in xscreensaver-4.22-21 that putting XScreenSaver file in
/usr/X11R6/lib/X11/app-defaults or /usr/lib/X11/app-defaults no longer works;
xscreensaver command cannot load the XScreenSaver config file any more.
Putting XScreenSaver file in /usr/share/lib/app-defaults works well
( as expected like in libXt-0.99.2-2 changelog) ; xscreensaver correctly
load the XScreenSaver config file.
Please move XScreenSaver into /usr/share/X11/app-defaults.
> Expected Results: File "XScreenSaver" should be in "/usr/lib/X11/app-defaults".
It is like that in xscreensaver-base-4.22-21.2 from recent updates but this
location is architecture dependent and this really should go to
/usr/share/X11/app-defaults/ together with other default resource files.
"file /usr/lib/X11/app-defaults is not owned by any package" you will get
now if you will ask rpm for an owner.
Fixed in "xscreensaver-base-4.22-21.2" or earlier.
Determining where "XScreenSaver.ad" will be installed starts from
around the line 6800 of configure.
From reading configure file around there, "XScreenSaver.ad" will be
installed correctly in /usr/share/X11/app-defaults only when the command
"imake" exists (around the line 6817) (now in imake rpm, but imake command
is thought to be deprecated...). Current rawhide sets XAPPLOADDIR as
/usr/share/X11/app-defaults (this is the reason XScreenSaver.ad should be
installed), so imake correctly points to this directory.
When I forcely changed the permission of /usr/bin/imake as 000,
configure pointed to /usr/lib/X11/app-defaults (as the newest rawhide rpm),
which is now incorrect.
This problem is also discussed in the bug 176218.
In my comment 7, "the command "imake" exists" was "the command "xmkmf" exists",
and "changed the permission of /usr/bin/imake" was "changed the permission
This is fixed in rawhide rpm 4.23-1.
Note: in xscreensaver-4.23-1 src rpm, the patch18
(xscreensaver-4.23-modularX-addoption.patch) and the added CFLAGS option
removes the necessity of imake.