Bug#572485: xscreensaver: should not hardcode screenhacks list
On 12/06/2011 09:26 PM, Martín Ferrari wrote: [...] > José, do you think it is possible to implement Jamie's suggestion? > There aren't many xscreensaver hacks in the archive, but they will > benefit from this, and it would make a lot easier to package new > hacks... > Sure Martín, just send me a patch. We maintain everything on git.debian.org/git/collab-maint/xscreensaver.git Send it on email or just let me know from where make pull. Cheers! -- Jose Luis Rivas - GPG: 0x7C4DF50D / 0xCACAB118 The Debian Project Developer -- http://ghostbar.ath.cx Barquisimeto, Venezuela signature.asc Description: OpenPGP digital signature
Bug#572485: xscreensaver: should not hardcode screenhacks list
> Now, as a maintainer, how I am supposed to add a hack to the list? > Surely not editing a conffile from other package in postinst, as that > is not permitted by the Debian Policy. Is there any other way to do > this? Policy aside, that is how you do it. I don't see another way. If ~user/.xscreensaver lists hacks A, B and C, and you want them to also see D, you need to put D in the system-wide /.../app-defaults/XScreenSaver file. I guess you could modify both packages to install their version as XScreenSaver-pkgname and then have postinst for both packages treat the app-defaults file as a generated file from whatever wild carded files it finds. Maybe that would work as a loophole for whatever the policy is. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572485: xscreensaver: should not hardcode screenhacks list
It's documented in the man page... If you think it's unclear send me a change. I guess you could just regenerate the programs section of the app-defaults file from the existing XML files if you wanted. Then postinst could run the "rebuild" script you've added to the xscreensaver package. I don't think that modding the xscreensaver daemon itself to scan and read the entire directory of XML files is a great idea, because that's a lot of file I/O, but maybe it doesn't matter. The daemon itself currently contains no XML parser and I want to keep it that way. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572485: xscreensaver: should not hardcode screenhacks list
On Wed, Dec 7, 2011 at 01:48, Jamie Zawinski wrote: > If ~user/.xscreensaver lists hacks A, B and C, and you want them to also see > D, you need to put D in the system-wide /.../app-defaults/XScreenSaver file. > > I guess you could modify both packages to install their version as > XScreenSaver-pkgname and then have postinst for both packages treat the > app-defaults file as a generated file from whatever wild carded files it > finds. Maybe that would work as a loophole for whatever the policy is. The policy has good reasons for that. Although, what you suggest could be a solution, the problem is migrating current configurations where that file has been locally modified. As a side note, I would like to suggest you to document this somewhere in the upstream source, as I think most people will assume that the XML files are enough, and spend a lot of time trying to understand why XScreensaver is not reading them. José, do you think it is possible to implement Jamie's suggestion? There aren't many xscreensaver hacks in the archive, but they will benefit from this, and it would make a lot easier to package new hacks... -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572485: xscreensaver: should not hardcode screenhacks list
>> The configuration dialog only shows screenhacks that are either hardcoded >> inside the xscreensaver binary, or manually entered into ~/.xscreensaver. >> This means there is no easy way to make packages that provide additional >> screenhacks. > No, that's what the /usr/lib/X11/app-defaults/XScreenSaver file is for. > (Exact directory may vary. Consult your doctor.) >> Currently there's the rss-glx package which has to use an awful hack >> to make the screensavers work: rss_glx-install, a script that has to be >> run by *every* user on the system manually. Not user friendly at all! > That does, indeed, sound like a very dumb way to do it. The maintainers of > that package should do something less dumb. I am facing the same problem. After *many* hours of trying to understand why nor xscreensaver, nor xscreensaver-demo was not reading my XML file, I finally realised that only the global config file and the user config file are checked to get a list of hacks. Now, as a maintainer, how I am supposed to add a hack to the list? Surely not editing a conffile from other package in postinst, as that is not permitted by the Debian Policy. Is there any other way to do this? -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572485: xscreensaver: should not hardcode screenhacks list
> The configuration dialog only shows screenhacks that are either hardcoded > inside the xscreensaver binary, or manually entered into ~/.xscreensaver. > This means there is no easy way to make packages that provide additional > screenhacks. No, that's what the /usr/lib/X11/app-defaults/XScreenSaver file is for. (Exact directory may vary. Consult your doctor.) > Currently there's the rss-glx package which has to use an awful hack > to make the screensavers work: rss_glx-install, a script that has to be > run by *every* user on the system manually. Not user friendly at all! That does, indeed, sound like a very dumb way to do it. The maintainers of that package should do something less dumb. > It shouldn't just read the xml files at runtime, but also the contents > of the directory, so that additional screenhack packages can just dump > their xml file into /usr/share/xscreensaver/config and just work. The XML directory is used only by the "xscreensaver-demo" program, the GUI. The app-defaults file is used by both "xscreensaver" and "xscreensaver-demo". -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572485: xscreensaver: should not hardcode screenhacks list
Package: xscreensaver Version: 5.10-7 Severity: wishlist The configuration dialog only shows screenhacks that are either hardcoded inside the xscreensaver binary, or manually entered into ~/.xscreensaver. This means there is no easy way to make packages that provide additional screenhacks. Currently there's the rss-glx package which has to use an awful hack to make the screensavers work: rss_glx-install, a script that has to be run by *every* user on the system manually. Not user friendly at all! The package should instead do what is suggested by one way of interpreting /usr/share/xscreensaver/config/README: > This directory contains XML files that describe each of the screenhacks; > the per-hack user interface is constructed based on the things in these > files. The files are loaded at run-time by xscreensaver-demo (also > known as "the Control Center screensaver properties capplet".) It shouldn't just read the xml files at runtime, but also the contents of the directory, so that additional screenhack packages can just dump their xml file into /usr/share/xscreensaver/config and just work. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xscreensaver depends on: ii libatk1.0-0 1.28.0-1The ATK accessibility toolkit ii libc62.10.2-6Embedded GNU C Library: Shared lib ii libcairo21.8.10-2The Cairo 2D vector graphics libra ii libfontconfig1 2.8.0-2 generic font configuration library ii libfreetype6 2.3.11-1FreeType 2 font engine, shared lib ii libglade2-0 1:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.22.4-1The GLib library of C routines ii libgtk2.0-0 2.18.7-1The GTK+ graphical user interface ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libpam0g 1.1.1-2 Pluggable Authentication Modules l ii libpango1.0-01.26.2-1Layout and rendering of internatio ii libsm6 2:1.1.1-1 X11 Session Management library ii libx11-6 2:1.3.3-1 X11 client-side library ii libxext6 2:1.1.1-2 X11 miscellaneous extension librar ii libxinerama1 2:1.1-2 X11 Xinerama extension library ii libxml2 2.7.6.dfsg-2+b1 GNOME XML library ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library ii libxpm4 1:3.5.8-1 X11 pixmap library ii libxrandr2 2:1.3.0-3 X11 RandR extension library ii libxrender1 1:0.9.5-1 X Rendering Extension client libra ii libxt6 1:1.0.7-1 X11 toolkit intrinsics library ii libxxf86vm1 1:1.1.0-2 X11 XFree86 video mode extension l ii xscreensaver-data5.10-7 data files to be shared among scre Versions of packages xscreensaver recommends: ii libjpeg-progs 8-2.1 Programs for manipulating JPEG fil ii perl [perl5] 5.10.1-11 Larry Wall's Practical Extraction ii wamerican [wordlist] 6-3 American English dictionary words ii xli1.17.0+20061110-3 command line tool for viewing imag Versions of packages xscreensaver suggests: ii elinks [www-browser]0.12~pre5-2 advanced text-mode WWW browser pn fortune(no description available) ii iceweasel [www-browser] 3.5.8-1 Web browser based on Firefox ii lynx-cur [www-browser] 2.8.8dev.2-1 Text-mode WWW Browser with NLS sup pn qcam | streamer(no description available) ii w3m [www-browser] 0.5.2-4 WWW browsable pager with excellent pn xdaliclock (no description available) pn xfishtank (no description available) ii xscreensaver-gl 5.10-7 GL(Mesa) screen hacks for xscreens -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
