Description of problem: When I try to enable the antspotlight screensaver X reliably dies with my newly recompiled xorg-x11 x server. The screen turns almost black with some blocky gray patterns that resembles graphics bugs on my friends' C64's that I saw when I was a kid. The keyboard is unresponsive and I can't use ctrl-alt-f1 to switch to console. Logging into the box remotely and running 'killall -9 X' creates a colorful ansi character screen for about a second before X dies and gdm restarts it. Version-Release number of selected component (if applicable): xorg-x11-0.0.6.6-0.0.2004_03_11.5 How reproducible: always Steps to Reproduce: 1. go to screensaver control panel. 2. select antspotlight screensaver 3. Actual results: X death, as explained above Expected results: no X death Additional info: I use a locally recompiled xorg-x11-0.0.6.6-0.0.2004_03_11.5.src.rpm (the one from the devel tree depended on a new glibc) that I installed with --nodeps work around packages that required XFree86. The system is a fedora core 1 + released updates system. For some reason /usr/X11R6/lib disappeared from /etc/ld.so.conf when doing the update, so the %postinstall script for xorg-x11-100dpi-fonts failed (mkfontdir misssed it's shared libraries). After manaully adding /usr/X11R6/lib and running ldconfig i redid the installation with --force to make sure all the %post scripts was really run. I guess this problem is due to some bad interation with rawhide XFree86 that I had installed before (4.3.0-63 it seems) and it shouldn't affect the above filed bug report but I thought I should mention it anyway.
Created attachment 98681 [details] the XFree86.0.log really should get a better name
While I'm at it: Please use .bz2 for the xorg-x11 source and save me ~12 MiB of download from download.fedora.redhat.com (development packages propagate rather slowly to my local mirror)
>I use a locally recompiled xorg-x11-0.0.6.6-0.0.2004_03_11.5.src.rpm We do not support customer/user recompiled packages. However, having said that, the ld.so.conf problem is already known since Wednesday, and a fix was attempted in the 0.0.6.6-0.0.2004_03_11.6 package. The actual bug is not a bug in xorg-x11, but in the XFree86-libs package that gets uninstalled. It's %postun removes the X lib dir from ld.so.conf. All the new packages can do, is try to put it back, which they do. RPM itself decides what order the various package's pre/post/postun/preun/etc. scripts run in however, and so there may not be any way for me to force xorg-x11 packages to ensure ld.so.conf is correct. > the XFree86.0.log really should get a better name The log name is $PROGRAMNAME.$DISPLAY_NUMBER.log It is possible to have multiple X server's running on a machine all at the same time, each on it's own display, so the log files must contain the $DISPLAY number or else there is contention with multiple servers writing to the same log or overwriting the same log. Since it is possible to run multiple different X servers at the same time, the name of the program needs to be in the log filename. The extension ".log" is just common for Linux/UNIX style log files. The log files will get renamed to Xorg.$DISPLAY.log in the near future once we update to the latest upstream changes that incorporate the name change, however Red Hat does not determine what the name used is, rather the X.org people will decide. Whatever is decided, Red Hat will use, in order to be consistent with the upstream naming. >While I'm at it: Please use .bz2 for the xorg-x11 source and save me >~12 MiB of download from download.fedora.redhat.com (development >packages propagate rather slowly to my local mirror) bz2 compressed main tarball takes double the time to decompress it every time I rebuild the rpm package, or approximately an extra minute to a minute and a half over gzip -9. As such, I changed from using bzip2 to tar.gz a long time back in order to help speed up my local test builds, as build speed performance is important to me. While I plan on continuing to use tar.gz for the forseeable future, I will switch to bzip2 compressed sources once the X.org source tree gets split up into much smaller pieces which can be put into individual src.rpms, as the time it takes to decompress the main tarball will then be significantly smaller, and much less of an inconvenience to me in my daily work. In the mean time, if download time is a hindrance for you, you can instead try exploding the src.rpm on a fast remote machine, and then using rsync to download the patches/spec locally. I use this technique to transfer the src.rpm contents to/from Red Hat and it is very effective in minimizing network transfer overhead. It takes me about 45 seconds to upload a new src.rpm to Red Hat in this way. Hope this helps.
For your Radeon problem, please reinstall the officially provided Red Hat binary rpm packages. While it likely the problem exists in the Red Hat packages as well, it is also possible that your recompilation may have introduced a problem that is not present in our binaries, and we need to rule that possibility out. Please attach the log file and config file from using the Red Hat built rpms. Thanks in advance.
Thanks for taking the time to explain why .tar.gz. Supporting only rh-built pacakges seem perfectly reasonable also. Regarding download times, I have access to several boxen with 10mbit/s connections up here in northen europe (sweden) but no one have faster downloads from download.fedora.us than 10kb/s. It doesn't matter today because it seems ftp.funet.fi has picked up the latest development tree. Someday I'll write a rpmdiff utility that creates nice small diffs for binary rpm packages :) I have now reproduced the X death with Build Host: tweety.devel.redhat.com. Attaching log and config file below.
Created attachment 98689 [details] XFree86.0.log.old
Created attachment 98690 [details] XF86Config
I can no longer reproduce the problem with xorg-x11-0.6.6-0.2004_03_30.5 from the development tree