Description of problem:This seems to be a combination of Bug 350 and Bug 4140 I have all packages installed, and all the screensavers are there in /usr/lib/xscreensaver. I can run each one alone, and it shows in its own window. But none are listed in the setup GUI visible as xscreensaver-demo, and when the screensaver starts, it shows an error message as in Bug 4140. This is independent of Window manager (I have tried KDE and Xfce. I have LXDE, and haven't tried it, but it was in use in Bug 4140.) My .xscreensaver is basic. It contains no entries for screensavers to start. I copied the one from my Mageia1 across, but it has been renamed with a .bak extension, and the first one is in its place again. That would explain why I have none to choose from. I have just copied my working one again, and it was immediately deleted and the first one put back again. It seems to have been deleted: .xscreensaver.bak is another copy of the defective one. This sounds more like Bug 350. Xscreensaver is the default screensaver for Xfce. KDE and Gnome have their own versions of it, but the original is better
Further tests: XFCE will immediately delete any config file it doesn't like. .xscreensaver isn't an Xfce file, but it is the "official" default. Also, I copied my entire .xscreensaver file across from Mageia 1. So I went into KDE. In the .xscreensaver file, I added only the list of screensavers. The GUI still showed nothing, but the file was unchanged. On logging out and in again, .xscreensaver was back how it was before. I am willing to try any further tests, but I can't think of any.
Any ideas guys ?
CC: (none) => fundawang, lists.jjorge, luigiwalserSource RPM: (none) => xscreensaver
Further observation: I happened to have .xscreensaver open in Kwrite and got a message that it had been "deleted by another program." Time to leave it to you guys: I am getting compulsive about it.
I have just uploaded xscreensaver-5.15-2.mga2 to Cauldron. It restores the default screensaver that was removed when this package was first imported into Mageia because a package it depended on hadn't been imported yet. I don't know what's going on with your ~/.xscreensaver file, but try removing it. xscreensaver should install a fresh one when you run it. It's working for me here.
I tried that. No joy. The update hasn't reached my neck of the woods yet. I will report after it does.
(In reply to comment #4) > I have just uploaded xscreensaver-5.15-2.mga2 to Cauldron. It restores the This does not fix the empty list for me.
Created attachment 1675 [details] Current .xscreensaver file in Cauldron.
(In reply to comment #7) > Created attachment 1675 [details] > Current .xscreensaver file in Cauldron. That's not what it should look like. Did you try deleting it?
Yes I did, and it was put straight back. What I have in Mageia 1 is what I have always had. Basically it is the attachment with a whole lot of screensavers listed in the middle, such as: programs: \ - default-n: "GDadou" chbg -xscreensaver -mode smart -bg \ "#000000" \ -interval 0.16 -effect 1 -speed 500 \ -R `/bin/ls \ /usr/share/mga/screensaver/*` \n\ - GL: superquadrics -root \n\ and so on. That is removed as soon as I put it there. As I mentioned before, I first tried copying the whole .xscreensaver file across. There would have been entries for screensavers I didn't have, but I should have been able to pick one that was there. Then, in case there was a version problem, I pasted the list of screensavers into the gap in the default file. That got deleted as well. I would be quite willing to accept that it is just me, except that José is having problems as well.
The RPMs are on my local mirror, but rpmdrake and urpmi can't see them. In "Update your system" the crazy endless loop with LIBODBC1 & 2 is back. The mount point for my CD-ROM has been removed again. I feel like chucking the whole Cauldron and sticking with Mga1. Cauldron seems to have run off the rails. Here we are at Beta 1 and we don't have a workable distro. Mga 1 at this stage was as good as some final releases.
Doug, I can't reproduce the issue with the updated package, so I'm surprised to hear that José is still having problems. Based on what you've described, I'm not surprised to hear that you're still having issues with it. I hope you're able to get the new package installed. If you do go back to mga1, the package should rebuild fine there, so you could try it there as well.
The ODBC is because I enabled too many repos to try to make it see the new packages. I am too old (69) with a congenital health problem, and I just spat the dummy. It is 2 a.m. here. Tomorrow I will (a) clear all my urpmi sources and add the list from the mirrors, then the CD-ROM won't matter. (b) make sure I have the right set of repos enabled; and take it from there. What kind of .xscreensaver are you seeing? Is it as I described, with a list of configs added, or has there been a complete change? I downloaded the latest tarball, and it suggests that there are no drastic changes.
I ran xscreensaver-demo with strace, and the following pair of lines occurred repeatedly. I don't know whether they are normal or not: recv(4, 0x9760280, 4096, MSG_WAITALL) = -1 EAGAIN (Resource temporarily unavailable) recv(4, 0x9760280, 4096, MSG_WAITALL) = -1 EAGAIN (Resource temporarily unavailable) The next line varies.
(In reply to comment #11) > Doug, I can't reproduce the issue with the updated package, so I'm surprised to > hear that José is still having problems. It is a clean MGA2 Beta 1 install i586, where I selected only LXDE. I suppose a package is missing, if your Cauldron xscreensaver lists correctly all screensavers...
(In reply to comment #14) > (In reply to comment #11) > > Doug, I can't reproduce the issue with the updated package, so I'm surprised to > > hear that José is still having problems. > > It is a clean MGA2 Beta 1 install i586, where I selected only LXDE. I suppose a > package is missing, if your Cauldron xscreensaver lists correctly all > screensavers... The updated package was just built yesterday, so it wouldn't be in Beta 1. Did you install the updated package from Cauldron? What xscreensaver packages do you have installed? It worked for me with just xscreensaver and xscreensaver-common, showing like 5 or 6 screensavers in the list (working from memory, I can't check from work). Installing xscreensaver-base made it show a much larger list.
What I have installed is Version 5.15-1. What is on the mirror is 5.15-2. José, if you haven't downloaded any updates, you will have 5.15-1. You can check by typing "rpm -qa | grep xscreensaver" in a Konsole (without the quotes, of course.) You can do this as an ordinary user. It will list all the packages with xscreensaver in the name, with their version number.
As I was typing the above, mgaapplet came on. The updated packages are now installed, but nothing has changed here. The GUI is still empty, and deleting .xscreensaver or adding entries to it results in the "empty" original version coming back. This after rebooting for an updated gcc or whatever, that came down first. Other forum posts referred to imageDirectory. That is empty in my file. Somewhere I saw a reference to one of the "canvas" files. A couple are installed. Is there perhaps a missing dependency that is in your system anyway, David?
(In reply to comment #15) > The updated package was just built yesterday, so it wouldn't be in Beta 1. Did > you install the updated package from Cauldron? Sorry yes, I missed to indicate of course that it is an updated Beta, with 5.15-2.
The image directory should be set to /usr/share/mga/screensaver, and the image files in that directory come from the mageia-theme-Default-screensaver package, which should have been pulled in as a dependency.
Created attachment 1681 [details] .xscreensaver from updated package (In reply to comment #12) > What kind of .xscreensaver are you seeing? Is it as I described, with a list > of configs added, or has there been a complete change? I downloaded the latest > tarball, and it suggests that there are no drastic changes. Attached what the current one should look like.
The list of packages that own files that xscreensaver-demo opens according to strace looks something like the following: filesystem fontconfig fontpackages-filesystem fonts-ttf-dejavu glibc gnome-icon-theme gvfs gvfs-gphoto2 hicolor-icon-theme libart_lgpl2 libatk1.0_0 libavahi-client3 libavahi-common3 libavahi-glib1 libbonobo2_0 libbonoboui2_0 libbonoboui libcairo2 libcanberra0 libcanberra-gtk0 libdbus-1_3 libdbus-glib libexpat1 libfontconfig1 libfreetype6 libgail18 libGConf2_4 libgcrypt11 libgdk_pixbuf2.0_0 libgio2.0_0 libglade2.0_0 libglib2.0_0 libgnome2_0 libgnomecanvas2_0 libgnome-keyring0 libgnomeui2_0 libgnomeui2 libgnome-vfs2_0 libgpg-error0 libgtk+2.0_0 libgtk+-x11 libgvfs0 libia_ora-gnome libice6 libltdl7 libogg0 libopenssl1.0.0 libORBit2_0 libpango1.0_0 libpango1.0_0-modules libpcre0 libpixman-1_0 libpng12_0 libpopt0 libsm6 libtdb1 libtermcap2 libudev0 libvorbis0 libvorbisfile3 libx11_6 libx11-common libxau6 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxi6 libxinerama1 libxml2_2 libxmu6 libxrandr2 libxrender1 libxt6 libzlib1 shared-mime-info x11-data-cursor-themes Are you missing any of these?
I didn't check the files individually, but all the packages are there. I have Cauldron and its /home on two spare partitions. I just formatted both, did a clean re-install of Beta 1, then all available updates, including your updated packages. It is still the same. Then I downloaded your .xscreensaver file, which looks like what I have in Mga 1, and put it in place. It was immediately deleted and the old file put back. This is weird. I can find nothing in the logs. There are no logfiles in /var/log to do with security, and neither kdm.log nor syslog has anything. I haven't had a good look with strace, but I don't really know what it all means.
OK, so the problem isn't with the xscreensaver package itself, something else is causing the problem. Something is eating your configuration. What desktop environment or window manager are you running it in? Can you try it in other desktop environments and window managers to see what happens?
I came to much the same conclusion. It is no different in Xfce. The screensaver starts according to its settings, but it is just a black screen. There isn't even the yellow message mentioned in Bug 4140. I have seen that kind of message before. It used to mean that something like chbg was missing, but it said what the problem was. chbg is in /usr/bin/ I have a completely fresh Beta installation, and deliberately wiped /home in case there was something there. Anybody whose first Linux distro is Beta 1, should see what I am seeing. That is why I thought that you must have something additional which fixes it. If I have a bigger problem, it is outside the distro, Which brings me to my monitor. Under the first Alphas of Version 1, it didn't like the nouveau driver. I got around that by using the nVidia packages, but in Mga 1 I now have the standard "free nVidia" driver, and it has no problems. There is a file /etc/X11/app-defaults/XScreenSaver which is supposed to apply if .xscreensaver is missing. It is how .xscreensaver should be. What package puts .xscreensaver back in $HOME? I saw a reference somewhere to PAM authentication. My /etc/pam.d/xscreensaver doesn't mention Mandriva or Mageia, but the option for Fedora Core 5 is enabled. The distro name is commented out.
I have just rebuilt for Mageia 1 the SRPM from Cauldron and installed it under Mga1 with no problems. There were only two issues in the spec file (a) The extrusion options were enabled, but the files weren't there. Because of this, I had installed gle as a dependency. (b) A dependency could not be found because the package name started with "lib." They were easily fixed, and everything works. I had to uninstall the mesaglut packages to install freeglut. I don't know whether that really matters. What next? Try it again under Cauldron?
You get the gle build dependency when it builds extrusion, but it doesn't install it in the main package, it puts it in a subpackage. You should be able to uninstall the extra build dependencies after building it. So again, what we're seeing is that the problem is not with this package. Something else is eating your configuration. Could you give a more detailed summary of what happens in current Cauldron in different window managers and desktop environments? Do they all delete the config, do some of them just modify it, does it happen as soon as you log in or not until you run xscreensaver, etc. Hopefully we don't have to resort to having you do a strace -f -p 1 early in the boot process :o)
>You get the gle build dependency when it builds extrusion, but it doesn't >install it in the main package, it puts it in a subpackage. It couldn't build extrusion because the man pages were missing. Either one of the two issues I mentioned prevented a successful build. As you say, it is external to the packages. Leave it with me for a few days, while I check it out thoroughly. With both KDE and Xfce, the good .xscreensaver file is deleted as soon as it is written, or when xscreensaver starts. I doubt that I could log in with a proper file, but I want to be definite about that. Correct observation is going to be very important. I am wondering if it is related to the new config in Cauldron (dracut, systemd, etc.)
(In reply to comment #27) > I am > wondering if it is related to the new config in Cauldron (dracut, systemd, > etc.) Don't think so, I have the same issue with the 1 (but it says also that another one is running from gnome) I have read anything in this topic so sorry if I'am of topic.
I was only clutching at straws. The problem arose on a fresh installation on formatted partitions. About the only external factor is hardware, and there is no problem with 1. I won't add too much now.
This is getting out of my depth, and doesn't seem relevant, but the only option for the kernel that is different is that Cauldron has "nokms". I can't go back any deeper than that.
Observations so far: If I put back an .xscreensaver file how it should be, it survives a reboot. Nothing happens until I start xscreensaver-demo AND do something with it, such as switch from one screensaver to random. If I delete the .xscreensaver file completely, the file in /usr/lib should be the basis for a new one, or even used directly. Instead the usual "empty" file is created by xscreensaver-demo (according to the opening lines.) The permissions in /usr/lib look O.K. Nothing wrong with it except that it won't work!
I mentioned before that strace mentioned a resource as temporarily unavailable. After chasing through all the "open (3)" and "close(3)" the one that should be open is a socket: socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0 getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, [20]) = 0 uname({sys="Linux", node="dougshost2.douglaidlaw.net", ...}) = 0 access("/home/doug/.Xauthority", R_OK) = 0 open("/home/doug/.Xauthority", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0600, st_size=181, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb776c000 read(4, "\0\0\0\4\300\250\1\3\0\0010\0\22MIT-MAGIC-COOKIE-1\0"..., 4096) = 181 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb776c000, 4096) = 0 getsockname(3, {sa_family=AF_FILE, NULL}, [2]) = 0 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, {"", 0}, {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, {"O_\227&e\305\332\256IwP\313\177\306\351$", 16}, {"", 0}], 6) = 48 recv(3, 0x948abe8, 8, 0) = -1 EAGAIN (Resource temporarily unavailable) I don't understand enough of what is going on, but being unable to access a socket sounds likely to a guy fresh off the street. Doug.
Doesn't look like anything to worry about, my strace looks almost exactly the same. Basically it is except I don't get recv, I get read. Basically it goes into a poll, write, poll, read loop, and for the reads it's usually more than one, with the first one usually being successful, and the other ones being: read(3, 0x9ab29a8, 4096) = -1 EAGAIN (Resource temporarily unavailable) I would focus on what you see happening with ".xscreensaver" but I suspect it's another process that's messing with it.
I haven't got the know-how. I thought that /etc/X11/app-defaults/XScreenSaver might not be accessible, but strace shows it being read O.K. The behavior is as if xscreensaver-demo looks at the file, doesn't like it, gets rid of it, then can't fall back on /etc/X11/app-defaults/XScreenSaver. Trying to use the .xscreensaver file is what gets it wiped. I believe that the default .xscreensaver should be a copy of XScreenSaver, not what I am getting. I have the identical version running happily on Release 1. Can I look at something there for a comparison? You need to tell me where to look, and I will report back as well as I can. I have no training at all in programming or troubleshooting.
Well the ~/.xscreensaver isn't a copy of the app-defaults file, but clearly it's based on it. I guess xscreensaver-demo reads in the app-defaults one and sanitizes it and strips out some unneeded things and then writes that out as ~/.xscreensaver. Does yours still come out looking exactly like the one you posted to this bug earlier, or is it different now?
It always finishes up like the one I posted. It is what I would expect to see if there were no screensavers installed. A screensaver with a hyphen in front is supposed to be disabled. All my OpenGL screensavers have the hyphen in XScreenSaver, but (a) the one in Mageia 1 is no different, and they run; (b) the result should be that they are listed but unchecked, instead of just not being there.
OK, so maybe when it does the sanitizing of the configuration, it is stripping out all of the screensavers because it doesn't see them or thinks something's wrong with them. If you put the ~/.xscreensaver file from Mageia 1 in place in your home directory, and then on Cauldron run xscreensaver-demo from a terminal, what console output do you get there?
The file is deleted, same as the others. For console output, I will need to go into Cauldron. I can't do that before tomorrow. With Beta 2 due on Thursday, is that a problem? The freeze seems to have taken place already.
(In reply to comment #38) > The file is deleted, same as the others. For console output, I will need to go > into Cauldron. I can't do that before tomorrow. With Beta 2 due on Thursday, > is that a problem? The freeze seems to have taken place already. Deleted? Which is it? You end up with a stripped down version like the one you posted to the bug, or no ~/.xscreensaver file at all? No rush Doug. You can get to it when you have time to. I won't have more time to look at this until the weekend.
There is absolutely nothing shown in a Konsole when I run either xscreensaver or xscreensaver-demo. Nothing to dmesg either. The good file is replaced by the basic one I uploaded. The screensaver mechanism is working. At present it is blanking the screen on a 1 minute timeout, but nothing shows in its place. I just tried again with "xscreensaver &> screensaver.log" and let the screen go blank. The logfile was still empty.
(In reply to comment #40) > There is absolutely nothing shown in a Konsole when I run either xscreensaver > or xscreensaver-demo. Nothing to dmesg either. > > The good file is replaced by the basic one I uploaded. The screensaver > mechanism is working. At present it is blanking the screen on a 1 minute > timeout, but nothing shows in its place. I just tried again with "xscreensaver > &> screensaver.log" and let the screen go blank. The logfile was still empty. Did you put a good .xscreensaver file in place before you ran it? I wouldn't expect any console output using the file it gives you.
Fair comment. The first time, I got confused and ran it with the existing small file. I expected to see something like "Starting xscreensaver daemon..." but there was nothing. Then I put the good file in, and got a line saying the daemon was already running - nothing more. The old file was still restored. Then I made certain the daemon was _not_ running, and I got no output at all, with either command. I left KDE with a good file and walked away for a minute or so. When I returned, the short file was back. I have the "debug" rpm; would that help? Only I don't know what to do.
You won't have time to look at it before the week-end. By then, Beta 2 will be out. Whatever it is, it is very elusive. I suggest that I try a fresh install of Beta 2. Anything weird may not recur. If it does, at least the context will be up-to-date.
I also see this on a new system, (recently installed beta 2, updated), under KDE. It may be useful when debugging to do: sudo chown root:root .xscreensaver; sudo chattr +i .xscreensaver which will prevent the config file getting deleted every time.
CC: (none) => mageia
O.K. it does. A new .xscreensaver.tmp is created but can't overwrite .xscreensaver. Then .xscreensaver.tmp disappears. strace shows: unlink("/home/doug/.xscreensaver.tmp") = -1 ENOENT (No such file or directory) open("/home/doug/.xscreensaver.tmp", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9 stat64("/home/doug/.xscreensaver", {st_mode=S_IFREG|0664, st_size=7988, ...}) = 0 getuid32() = 500 fchmod(9, 0100664) = 0 getuid32() = 500 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=1152, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7 723000 read(10, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1152 close(10) = 0 munmap(0xb7723000, 4096) = 0 time(NULL) = 1331699229 open("/etc/localtime", O_RDONLY) = 10 fstat64(10, {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0 fstat64(10, {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7 723000 read(10, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) = 2183 _llseek(10, -28, [2155], SEEK_CUR) = 0 read(10, "\nEST-10EST,M10.1.0,M4.1.0/3\n", 4096) = 28 _llseek(10, 2182, [2182], SEEK_SET) = 0 close(10) = 0 munmap(0xb7723000, 4096) = 0 fstat64(9, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7723000 write(9, "# XScreenSaver Preferences File\n"..., 1030) = 1030 close(9) = 0 munmap(0xb7723000, 4096) = 0 stat64("/home/doug/.xscreensaver.tmp", {st_mode=S_IFREG|0664, st_size=1030, ...}) = 0 rename("/home/doug/.xscreensaver.tmp", "/home/doug/.xscreensaver") = -1 EPERM (Operation not permitted) time(NULL) = 1331699229 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0 dup(2) = 9 fcntl64(9, F_GETFL) = 0x2 (flags O_RDWR) fstat64(9, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7723000 _llseek(9, 0, 0xbfa66794, SEEK_CUR) = -1 ESPIPE (Illegal seek) write(9, "xscreensaver-demo: 15:27:09: err"..., 130) = 130 close(9) = 0 munmap(0xb7723000, 4096) = 0 unlink("/home/doug/.xscreensaver.tmp") = 0 brk(0x9680000) = 0x9680000 That tells me nothing about why .xscreensaver.tmp is created or what its contents are.
You don't really have Beta 2, do you, Richard? It isn't due out until tomorrow, and I am about 8 hours ahead of French time, so I have to wait that much longer. If what you have is really Beta 2, it means that the bug is still present. I was hoping that it would quietly creep away! I can't contribute anything more, and for health reasons, I will have to leave it alone for a few days.
(In reply to comment #46) > You don't really have Beta 2, do you, Richard? Sorry, my brain is obviously getting tired. I meant "Beta of Mageia 2". It might be worth asking JWZ (the author of xscreensaver) to take a look at this, as he may be able to suggest something.
I have now installed Beta 2. It is no different. I was thinking of asking JWZ, but somebody more techy than myself will have to do it. I will give him the link. How many cases do we have -- you me and José.
More weirdness! JWZ has a protocol for generating a log file. It involves running xscreensaver in verbose mode and directing output to a log file with the -log option. In Beta 2 I got no output and no log, not even an empty one. In Mga 1 using just the -verbose option, there is plenty of output. Both are running the same version of Xscreensaver. I can report it without the log, but this is another clue, and I would like some feedback on it first. KDE's screensaver installs the hacks from Xscreensaver, but has its own driver for them, and doesn't install the xscreensaver package itself.
(In reply to comment #49) > More weirdness! > Not really : see comment 23. We already know that it is probably an Xorg change that has broken xscreensaver....
As I mentioned somewhere up above, I downloaded the SRPM for xscreensaver from Cauldron (the installed version) and rebuilt it for Mageia 1. It works perfectly there. Current versions of Xorg: Mageia 1 : 1.10.1-1.1 Cauldron : 1.11.4-2 The versions of Xorg and Xscreensaver are not common in other RPM distros. Where they do appear, it is often in a development stream like Cauldron. Mandriva Cooker still has Release 14 of Xscreensaver. BTW Dave: It is O.K. putting the extrusion hack in its own RPM, but the files should not have been removed from the SRPM. They aren't in any other SRPM, and the default setting in the spec file is to create the extrusion RPM as well, but it can't, and the whole build fails. The files should be there, and excluded by the switch. At present, it is mandatory to toggle the switch, and there is no way of compiling the extrusion hack from an SRPM. I know that Mandriva has the same set-up, but I don't know if they have taken the files out as well.
I have just sent off a detailed bug report to JWZ, with a link to this Bugzilla location. I will report further when I hear from him.
The reply from JWZ was: "Sounds like something's pretty screwed up about that distro. You might have better luck installing from source..." He "switched from Linux to Mac years ago!" So we are on our own. This is getting beyond my capability. The source code has a generic .spec file which creates a .desktop file specific for Gnome. That doesn't suit our distro. I found that the xscreenaver-gl RPM I created from the Mageia SRPM contained only a README file, no hacks. Unfortunately, that wasn't the answer. I have reinstalled Beta 2 with the packages from Cauldron, and the problem is still there. Looking for a clue to explain all the symptoms, the common factor seems to be creating text. There are no hacks added to the config file; and the output to the Konsole doesn't print as it does in Mga 1. The indication to the contrary is that the .xscreensaver file isn't left alone, but emptied of hack definitions. With only a few of us having trouble, the bug may be hardware-specific; I notice a comment on the Wiki that several are like that. I think that I have done pretty well for somebody with no training, but I have reached my limit. Doug.
Thanks for your patience, and for reporting this Doug. I set up a fresh Cauldron VM in VMWare at work and was able to reproduce this. Something certainly is screwed up, but I don't know what. We're also experiencing a weird bug in mplayer-gui (that I also couldn't reproduce at home, but did at work), and I wouldn't be surprised if they end up being related.
Perhaps another clue: I just tried to build the RPM again under Mga 1. While compiling, it couldn't find GL/gl.h, which is supposed to be put there by libmesagl1-devel. That package is installed, and vital to a few KDE packages.but gl.h is missing. The nVidia drivers are inclined to do that, but I am running the nouveau driver. Does it do the same? The result was that my xscreensaver-gl package had no hacks again. The standard fix is to install libmesagl1-devel again with --force, and I am about to do so, but that doesn't sound practical in the installation scenario.
But of course, installing the final RPM doesn't require header files. config.log mentions other missing header files, but this one is flagged as a fatal error.
Doug, I think you may be on to something, pointing out the differences in Xorg versions. I just spent some time looking at the very verbose ltrace output, and it looks like what's happening is it's using the X11 API (XrmGetResource) to read the Xresources-style app-defaults config file, and on Cauldron it's failing and not getting anything, so the values in the config file are falling back to some compiled-in defaults. In my ltrace output files, on line 63 in the good one and 66 in the bad one, XrmGetResources returns 1 in the good one and 0 in the bad one. In the good one, immediately after that it starts pulling in the options from the app-defaults file.
CC: (none) => thierry.vignaud
(In reply to comment #51) > BTW Dave: It is O.K. putting the extrusion hack in its own RPM, but the files > should not have been removed from the SRPM. They aren't in any other SRPM, and > the default setting in the spec file is to create the extrusion RPM as well, > but it can't, and the whole build fails. The files should be there, and > excluded by the switch. At present, it is mandatory to toggle the switch, and > there is no way of compiling the extrusion hack from an SRPM. I know that > Mandriva has the same set-up, but I don't know if they have taken the files out > as well. I don't understand this comment. The spec isn't conditionally including any source files or patches (as that would be incorrect), so I don't see a problem here.
(In reply to comment #57) > Doug, I think you may be on to something, pointing out the differences in Xorg > versions. I just spent some time looking at the very verbose ltrace output, > and it looks like what's happening is it's using the X11 API (XrmGetResource) > to read the Xresources-style app-defaults config file, and on Cauldron it's > failing and not getting anything, so the values in the config file are falling > back to some compiled-in defaults. In my ltrace output files, on line 63 in > the good one and 66 in the bad one, XrmGetResources returns 1 in the good one > and 0 in the bad one. In the good one, immediately after that it starts > pulling in the options from the app-defaults file. That is where it gets too deep for me. I simply listed the "vital statistics," without knowing if they were relevant.
(In reply to comment #58) > (In reply to comment #51) > > BTW Dave: It is O.K. putting the extrusion hack in its own RPM, but the files > > should not have been removed from the SRPM. They aren't in any other SRPM, and > > the default setting in the spec file is to create the extrusion RPM as well, > > but it can't, and the whole build fails. The files should be there, and > > excluded by the switch. At present, it is mandatory to toggle the switch, and > > there is no way of compiling the extrusion hack from an SRPM. I know that > > Mandriva has the same set-up, but I don't know if they have taken the files out > > as well. > > I don't understand this comment. The spec isn't conditionally including any > source files or patches (as that would be incorrect), so I don't see a problem > here. Near the beginning of the spec is the line: %define enable_extrusion 0 Originally, that was set to 1. I changed it to 0 because when it is set to 1, the build process tries to build the extrusion RPM: %if %enable_extrusion %package extrusion but it can't, because the files for the extrusion RPM are missing from the sources. So I am suggesting: leave the files in the source, and let the above take care of it. There is no method for building the extrusion RPM on its own. Having run the hack in an mplayer window, I don't mind not having it, anyway.
(In reply to comment #60) > Near the beginning of the spec is the line: > > %define enable_extrusion 0 > > Originally, that was set to 1. I changed it to 0 because when it is set to 1, > the build process tries to build the extrusion RPM: > > %if %enable_extrusion > %package extrusion > > but it can't, because the files for the extrusion RPM are missing from the > sources. So I am suggesting: leave the files in the source, and let the above > take care of it. There is no method for building the extrusion RPM on its own. > Having run the hack in an mplayer window, I don't mind not having it, anyway. It's set to 1 in our spec and it builds just fine. What files are missing?
The files are there all right, and the source tarball is the same size as the one I downloaded from jwz.org. I think that I misinterpreted what was happening. Quite a few header files that have been installed, aren't where they should be in Mga 1. I suspect they have been removed by the nouveau driver: see my comment 55. A clean start failed because GL/glu.h was missing. That is not installed by the same package as gl.h. There are several others. When I tried to compile with extrusion enabled before, I got a message that its man page was missing for one, and I think the executable as well. I jumped to the conclusion that they weren't there initially. In truth, they hadn't been prepared for installation, and weren't in the build directory. In comment 55, I mentioned that the result was an xscreensaver-gl package with no hacks. This time, I didn't get that far. I need a test bed without the nouveau driver, which has most likely removed the missing files. That can't be done directly during installation. It requires a special setup, and in my experience, uninstalling the nVidia driver doesn't always roll back properly; I would still have to overwrite installed RPMs. Since I can't take the issue any further, I don't want to do all that.
Finally getting somewhere. The Xresources settings loaded from /etc/X11/Xresources are breaking this. If you run the command: xrdb -remove Before running xscreensaver-demo, it works.
There are still some problems with it. It seems to work if it's in Only One Screen Saver mode, but if it's in Random Screen Saver mode, sometimes it works and sometimes it doesn't. Maybe if it randomly picks one that doesn't work or doesn't install, it barfs. Also, even when you get it into Only One Screen Saver mode, if you keep killing it and running it again, sometimes it goes back to Random Screen Saver mode.
Glad to hear you are making progress. It has been a long time coming. I have found no other distro with this combination of Xorg and Xscreensaver, to prove that it is capable of working as it is. Your findings may be quite general.
It would be interesting to see what it does do on another distro with the same Xorg. It still seems like a libX11 problem to me. I tried updating to the newest version from upstream, but no dice. The randomness of the problem doesn't help debug it, and xscreensaver-demo's inconsistent behavior between starts is a problem.
According to rpmfind.net the only rpm distro with Xorg 1.11.4 is Fedora 16 updates. Fedora 17 and Rawhide have 1.11.2. There was a bug reported in Ubuntu, but it didn't look relevant.
CC: (none) => jacques.pronchery
On xscreensaver-demo when clicking on the button ^ (up) under the empty list, we have the message : [jacques@localhost ~]$ xscreensaver-demo xscreensaver-demo: 14:30:14: Gtk-critical: IA__gtk_tree_model_iter_nth_child: assertion `n >= 0' failed [jacques@localhost ~]$ Many gtk apps have warnings or errors !!!! Is it a bad version when compiling, or a buggy GTK ???
This message is in two Bugzilla entries for Red Hat Bug 755621 and Bug 803326. A third Google entry had to do with midori, the subject of Bug 803326. The fix there was an updated midori package.
So I was stepping through with a debugger, and I found the call I mentioned in Comment 57. When it calls XrmGetResource with name_str = "xscreensaver.programs" and class_str = XScreenSaver.Programs, which basically is the list of hacks from the app-defaults file, it returns 0. I don't know why, but that seems to be where the problem is.
Stepped down into XrmQGetResource, and there's a line: if (db && db->linfo.lock && *names) { and it will return False if that if statement is not true, but db->linfo.lock is 0. I have no idea what that means, but that appears to be the problem.
(In reply to comment #71) > Stepped down into XrmQGetResource, and there's a line: > if (db && db->linfo.lock && *names) { > > and it will return False if that if statement is not true, but db->linfo.lock > is 0. I have no idea what that means, but that appears to be the problem. In Mageia 1, that line is only if (db && *names) {, and db->linfo.lock is still 0, so that change in libX11 is what broke this. Now, it could be that in either case db->linfo.lock shouldn't be 0 and something is wrong (probably in libXt which initializes the db object) and this just uncovered it, but it works fine in Mageia 1 that way.
(In reply to comment #72) > (In reply to comment #71) > > Stepped down into XrmQGetResource, and there's a line: > > if (db && db->linfo.lock && *names) { > > > > and it will return False if that if statement is not true, but db->linfo.lock > > is 0. I have no idea what that means, but that appears to be the problem. > > In Mageia 1, that line is only if (db && *names) {, and db->linfo.lock is still > 0, so that change in libX11 is what broke this. Now, it could be that in > either case db->linfo.lock shouldn't be 0 and something is wrong (probably in > libXt which initializes the db object) and this just uncovered it, but it works > fine in Mageia 1 that way. And indeed, patching libx11 and changing that back in Cauldron makes it work.
Glad to hear that you are making progress. It has been very elusive, and so many bugs affect only a few users.
The change in libx11 wasn't made upstream, it was a local Mageia patch. The patch has been updated and should fix this. Should be OK once libx11-1.4.99.1-4.mga2 hits your mirror.
Glad to hear it. I will report back as soon as it reaches my side of the world (which can take a week.)
Now in LXDE xscreensaver works fine.
I can confirm this is fixed.
Status: NEW => RESOLVEDResolution: (none) => FIXED
Fixed here as well. Thanks for your patience, Dave.