Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
On 2/14/23 05:25, Jonathan Dowland wrote: On Sat, Jan 21, 2023 at 09:26:03PM -0600, Aaron Rainbolt wrote: If the XScreenSaver configuration file is included as a part of the core xscreensaver package itself, as a file that is simply unpacked, the following situation will result: … If the configuration file is split out into its own separate xscreensaver-config package … This is totally orthogonal to a solution to the bug reporter's issue. Splitting the xscreensaver package up and shipping the same files in different sub-packages and adding alternatives or other metapackage complications will do nothing to solve their problem. Your motivation for all that extra complexity is also orthogonal to Debian: you're talking about an enhancement for Ubuntu. As it stands, you're talking about making Debian worse to make Ubuntu better, and that's a hard sell. I don't really understand the purpose of this message - the bug report is closed and a solution was already uploaded. -- Aaron Rainbolt Lubuntu Developer https://github.com/ArrayBolt3 https://launchpad.net/~arraybolt3 @arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat OpenPGP_0x6169B9B4248C0464.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
On Sat, Jan 21, 2023 at 09:26:03PM -0600, Aaron Rainbolt wrote: If the XScreenSaver configuration file is included as a part of the core xscreensaver package itself, as a file that is simply unpacked, the following situation will result: … If the configuration file is split out into its own separate xscreensaver-config package … This is totally orthogonal to a solution to the bug reporter's issue. Splitting the xscreensaver package up and shipping the same files in different sub-packages and adding alternatives or other metapackage complications will do nothing to solve their problem. Your motivation for all that extra complexity is also orthogonal to Debian: you're talking about an enhancement for Ubuntu. As it stands, you're talking about making Debian worse to make Ubuntu better, and that's a hard sell. -- Jonathan Dowland ✎ j...@dow.land https://jmtd.net
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Note that Debian hasn't installed any /usr/lib/X11/app-defaults/XScreenSaver at least since 2000 (xscreensaver 3.26). The installation (postinst) would also for a long time remove any stale fiiles from that location. The app defaults file is shipped in /etc/X11/app-defaults. If Lubuntu has been shipping their own (broken?) file in /usr/lib/X11/app-defaults that would not affect Debian. The other discussion is interesting, but I think there are already other bugs open where these topics are treated, or new ones should be opened. Tormod
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
You are making this all needlessly complicated. Each distro should have exactly one xscreensaver package which contains exactly one app-defaults file, with whatever patches are necessary to that. Which should be "just about none", as configure should have figured out the correct settings for things like newLoginCommand.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
(When am I going to start using the right email address? For crying out loud, Thunderbird.) On 1/21/23 21:11, Jamie Zawinski wrote: No. There should be exactly one XScreenSaver package. So, so many problems have stemmed from this incomplete, broken installations as a result of this ridiculous extras-data-extras-gl-extras-extras nonsense. I am decades weary of hearing about them. lol, to be fair, I don't fully understand what is with all of the tons of "extras" packages either. And I've not been around for long enough to know what all the pros and cons are. But I think that's beside the point for this particular situation. If the XScreenSaver configuration file is included as a part of the core xscreensaver package itself, as a file that is simply unpacked, the following situation will result: 1. There will be exactly one possible configuration file that ships with the defaults generated at compile time. 2. That file will become the only possible file that can be shipped in that location. 3. Any attempt to install a package which contains a customized version of that file will fail and cause a broken installation/upgrade attempt due to the file conflict. This technically might be able to be worked around by using a postinst script to replace the file, but that is a very hacky solution to a problem apt already has the capability to solve on its own. (Plus this workaround goes against Debian policy.) If the configuration file is split out into its own separate xscreensaver-config package, and the core package is made to depend on the -config package, then: 1. The configuration file generated at compile time will be installed by default if a user installs xscreensaver themselves. 2. Software that ships a customized version of that file can also provide a configuration package that uses Conflicts/Provides to replace xscreensaver-config. 3. The package containing the customized file can then be installed instead of xscreensaver-config, all dependencies will be satisfied, and everything will work, but in the way that the file customizer intended. Yes, this comes with the con of having yet *another* package involved, but it has a clear, practical use case. If you have an idea for how else to allow the configuration file to be customized, that doesn't involve the addition of another package, that would be great. -- Aaron Rainbolt Lubuntu Developer https://github.com/ArrayBolt3 https://launchpad.net/~arraybolt3 @arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
No. There should be exactly one XScreenSaver package. So, so many problems have stemmed from this incomplete, broken installations as a result of this ridiculous extras-data-extras-gl-extras-extras nonsense. I am decades weary of hearing about them.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
On 1/21/23 19:36, Jamie Zawinski wrote: Yes, it is critical that the version of /usr/lib/X11/app-defaults/XScreenSaver actually correspond to the version of XScreenSaver that is installed. I would have thought this to be obvious. If the file does not exist at all, things *should* work ok, but having an old version there is definitely going to screw everything up. So just install it. Any solution that involves *increasing* rather than *decreasing* the number of packages that comprise XScreenSaver is an asinine solution. I disagree that increasing the number of packages is a bad thing - if the core xscreensaver package includes the configuration file in question, it makes it difficult for a different package to ship the same file. For instance, lubuntu-default-settings in Ubuntu ships this file, with special customizations that make sense for Lubuntu but probably don't make a whole lot of sense for Debian or even for other flavors of Ubuntu. Having a separate xscreensaver-config package allows other packages to ship this file with specific customizations. While Debian doesn't have lubuntu-default-settings to contend with, it's not beyond possibility that other packages in the future might want to customize that file, and it's already the case that downstream Debian derivatives want to customize this file.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Yes, it is critical that the version of /usr/lib/X11/app-defaults/XScreenSaver actually correspond to the version of XScreenSaver that is installed. I would have thought this to be obvious. If the file does not exist at all, things *should* work ok, but having an old version there is definitely going to screw everything up. So just install it. Any solution that involves *increasing* rather than *decreasing* the number of packages that comprise XScreenSaver is an asinine solution.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Actually, it dawns on me that the whole "virtual package" thing is overly complicated - just making an xscreensaver-config package should be good enough, and anything that needs to replace it can use a Conflicts/Provides to replace it.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Package: xscreensaver Version: 6.02+dfsg1-2+b1 Followup-For: Bug #1014782 X-Debbugs-Cc: arraybo...@ubuntu.com I can verify that this is still happening with a fully updated Debian Sid VM running IceWM. Myself and the Lubuntu Development team encountered this bug in Lubuntu, and it was determined that the problem was a faulty configuration file at /usr/lib/X11/app-defaults/XScreenSaver. If the file at this location is not configured properly, various functionality of XScreenSaver 6.02 may break, including (but not necessarily limited to) the Preview button. After rewriting the configuration file to be compatible with the XScreenSaver 6.02, all functionality was restored. The exact file Lubuntu 23.04 currently uses is at https://git.lubuntu.me/Lubuntu/lubuntu-default-settings/src/branch/ubuntu/lunar/src/usr/lib/X11/app-defaults/XScreenSaver Currently, the latest version of XScreenSaver in Debian does not ship a configuration file in this location at all. I believe this is likely the reason for this bug. I believe that, by default, when XScreenSaver is installed from source code, an auto-generated configuration file is written to the correct location. I suspect it has been disabled or omitted either by accident or for some reason, or possibly included in a package that is not being installed by default. My suggested fix would be to cause the automatically generated configuration file to be included as part of a package, "xscreensaver-config". This package would also provide a virtual package, "xscreensaver-conf" (or something similarly named). xscreensaver could then depend on xscreensaver-conf, which I believe would cause it to pull in xscreensaver-config by default, fixing the bug. This will allow any future packages that want to provide an XScreenSaver configuration file to do so (for instance, Lubuntu ships a customized XScreenSaver configuration file and would benefit from this). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.65.2 ii libatk1.0-0 2.46.0-4 ii libc62.36-8 ii libcrypt11:4.4.33-2 ii libglib2.0-0 2.74.5-1 ii libgtk2.0-0 2.24.33-2 ii libpam0g 1.5.2-6 ii libpango-1.0-0 1.50.12+ds-1 ii libsystemd0 252.4-1 ii libx11-6 2:1.8.3-3 ii libxext6 2:1.3.4-1+b1 ii libxft2 2.3.6-1 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxml2 2.9.14+dfsg-1.1+b2 ii libxrandr2 2:1.5.2-2+b1 ii libxt6 1:1.2.1-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data6.02+dfsg1-2+b1 Versions of packages xscreensaver recommends: ii gsfonts-x11 2:20200910-6 ii libjpeg-turbo-progs 1:2.1.2-1+b1 ii perl 5.36.0-7 ii wamerican [wordlist] 2020.12.07-2 Versions of packages xscreensaver suggests: pn fortune pn gdm3 | kdm-gdmcompat pn qcam | streamer pn www-browser pn xdaliclock pn xfishtank pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- no debconf information
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Package: xscreensaver
Version: 6.02+dfsg1-2
Severity: important
I have been using xscreensaver for years. Recently (a few weeks or
months ago), it has stopped activating when the "Preview" button is
clicked and (rather more importantly) as per the delay specified via the
"Blank after" setting. It still activates fine via command line
invocation ("xscreensaver-command -activate"), and when the system goes to
sleep (hibernate).
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xscreensaver depends on:
ii init-system-helpers 1.64
ii libatk1.0-0 2.38.0-1
ii libc62.33-7
ii libcrypt11:4.4.28-1
ii libglib2.0-0 2.72.3-1
ii libgtk2.0-0 2.24.33-2
ii libpam0g 1.4.0-13
ii libpango-1.0-0 1.50.7+ds-1
ii libsystemd0 251.2-8
ii libx11-6 2:1.7.5-1
ii libxext6 2:1.3.4-1
ii libxft2 2.3.4-1
ii libxi6 2:1.8-1
ii libxinerama1 2:1.1.4-3
ii libxml2 2.9.14+dfsg-1
ii libxrandr2 2:1.5.2-2+b1
ii libxt6 1:1.2.1-1
ii libxxf86vm1 1:1.1.4-1+b2
ii xscreensaver-data6.02+dfsg1-2
Versions of packages xscreensaver recommends:
ii gsfonts-x11 0.28
ii libjpeg-turbo-progs 1:2.1.2-1
ii perl 5.34.0-5
ii wamerican [wordlist] 2020.12.07-2
Versions of packages xscreensaver suggests:
ii chromium [www-browser] 103.0.5060.53-1
ii firefox [www-browser]102.0-1
pn fortune
pn gdm3 | kdm-gdmcompat
ii lynx [www-browser] 2.9.0dev.10-1
pn qcam | streamer
pn xdaliclock
pn xfishtank
pn xscreensaver-data-extra
pn xscreensaver-gl
pn xscreensaver-gl-extra
-- Configuration Files:
/etc/pam.d/xscreensaver changed:
auth sufficient pam_u2f.so cue debug
@include common-auth
@include common-account
-- no debconf information
