Please include analog clock screensaver patch for x11-misc/xscreensaver. It is much more useful and visually pleasing to have an analog clock on the lock screen instead of just staring at a black screen. That's why many Android mobile phones have similar feature. The patch is available here: http://pt2k.xii.jp/software/anclock/xscreensaver/index_e.html
Adding that patch to x11-misc/xscreensaver will potentially block version bumps of XScreenSaver to versions incompatible with that patch. We had a similar situation with webalizer in the past so I would rather not have that situation again, let alone for security and increased workload downstream. Does the /etc/portage/patches appraoch [1] work for you to achieve the same for yourself with XScreenSaver? [1] https://wiki.gentoo.org/wiki//etc/portage/patches
Technically, x11-misc/xscreensaver also needs some per-screensaver plumbing so the installed screensavers are usable in Xfce's built-in screensaver module (I've created bug 748126 about it), so the upstream patch alone in /etc/portage/patches is not sufficient. I've just asked the author of this patch whether he plans to upstream it, but it does not seem likely. If a version bump is needed and there isn't a compatible patch version then the package can be simply updated while (temporarily) skipping the patch - I've seen other packages do it that way. By the way, it's not like there is a tremendous code churn at xscreensaver - it sees perhaps two releases a year. So it should be a rare case anyway.
(In reply to Maciej S. Szmigiero from comment #2) > Technically, x11-misc/xscreensaver also needs some per-screensaver plumbing > so the installed screensavers are usable in Xfce's built-in screensaver > module (I've created bug 748126 about it), so the upstream patch alone in > /etc/portage/patches is not sufficient. Okay, good to know. > I've just asked the author of this patch whether he plans to upstream it, > but it does not seem likely. Probably because upstream has a document aversion of clock screensavers. Quoting from README.hacking: "No clocks! [..] [E]veryone seems to think that their first screen saver should be a clock of some kind. Nobody needs to know what time it is with such frequency. Fight The Tyranny Of The Clock." > If a version bump is needed and there isn't a compatible patch version then > the package can be simply updated while (temporarily) skipping the patch - > I've seen other packages do it that way. I'm not sure that's ideal. The ebuild is already in a state where it's not so easy to just touch and bump things and I would personally want to see that situation become significantly better before we make it even small bits worse. > By the way, it's not like there is a tremendous code churn at xscreensaver - > it sees perhaps two releases a year. > So it should be a rare case anyway. There is (unpackaged) version 6 beta 1 and beta 2 [1] upstream already today and I personally expect some post-6 fix-up releases after 6, given the scope of the changes. [1] https://www.jwz.org/blog/tag/xscreensaver/
(In reply to Sebastian Pipping from comment #3) > (In reply to Maciej S. Szmigiero from comment #2) > > I've just asked the author of this patch whether he plans to upstream it, > > but it does not seem likely. > > Probably because upstream has a document aversion of clock screensavers. > Quoting from README.hacking: > > "No clocks! [..] [E]veryone seems to think that their first screen saver > should be a clock of some kind. Nobody needs to know what time it is > with such frequency. Fight The Tyranny Of The Clock." Okay, so the patch probably won't make it upstream then. By the way, looking at his blog, the upstream has aversion to lot of things besides clock screensavers... > > If a version bump is needed and there isn't a compatible patch version then > > the package can be simply updated while (temporarily) skipping the patch - > > I've seen other packages do it that way. > > I'm not sure that's ideal. The ebuild is already in a state where it's not > so easy to just touch and bump things and I would personally want to see > that situation become significantly better before we make it even small bits > worse. I guess you mean here that the ebuild applies a few existing patches and patches out some things when "offensive" USE flag is disabled. And these need to be forward-ported for new releases. > > > By the way, it's not like there is a tremendous code churn at xscreensaver - > > it sees perhaps two releases a year. > > So it should be a rare case anyway. > > There is (unpackaged) version 6 beta 1 and beta 2 [1] upstream already today > and I personally expect some post-6 fix-up releases after 6, given the scope > of the changes. > > [1] https://www.jwz.org/blog/tag/xscreensaver/ I've checked the patch against this version and it only needs context updates in two places to apply clearly to this beta version (it compiles fine, too). It also helps that "hacks" are mostly separate programs. Attached the updated patch.
Created attachment 691419 [details, diff] xscreensaver-6.00b2 patch
(In reply to Maciej S. Szmigiero from comment #4) > By the way, looking at his blog, the upstream has aversion to lot of things > besides clock screensavers... That's one reason why I'm a bit shy stepping up as the next maintainer of this ebuild, yes. > I guess you mean here that the ebuild applies a few existing patches and > patches out some things when "offensive" USE flag is disabled. > And these need to be forward-ported for new releases. That and the downstream patch files, yes. I bumped from 5.44-r4 to 5.45 two days ago, so I am speaking from first hand experience. > I've checked the patch against this version and it only needs context updates > in two places to apply clearly to this beta version (it compiles fine, too). > It also helps that "hacks" are mostly separate programs. > > Attached the updated patch. That's nice, thank you!
Can't the provider of the patch make a separate screen saver. For example electric sheep does that and xscreensaver recognizes the third party Screensaver and integrates it like a Screensaver that comes with it. https://electricsheep.org/
> Can't the provider of the patch make a separate screen saver. That's a question better asked of the analog clock patch author - there's a link to his page in the original bug description above.
I asked him and he says it's too much work to put that in a separate app. I have a different idea, we put that in a separate ebuild, where xsceeensaver is patched with the anclock patch and compiled. Then for installation we only install this screensaver into /etc/libexec or something. I will give this a try, but in fact the site where the patch is is down right now. I think this should go in the Guru then. Would this be an acceptable solution?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=a0b9cf72662b619c23d69913a5df4b246c7d8bf3 commit a0b9cf72662b619c23d69913a5df4b246c7d8bf3 Author: Pascal Jäger <pascal.jaeger@leimstift.de> AuthorDate: 2022-10-24 21:08:19 +0000 Commit: Pascal Jäger <pascal.jaeger@leimstift.de> CommitDate: 2022-10-24 21:14:08 +0000 x11-misc/xscreensaver-anclock: new package, version 2.1.0 Bug: https://bugs.gentoo.org/748123 Signed-off-by: Pascal Jäger <pascal.jaeger@leimstift.de> x11-misc/xscreensaver-anclock/Manifest | 2 + .../files/xscreensaver-5.31-pragma.patch | 11 ++ .../files/xscreensaver-5.45-gcc.patch | 16 +++ .../xscreensaver-6.01-configure-install_sh.patch | 12 ++ .../xscreensaver-6.01-configure.ac-sandbox.patch | 120 ++++++++++++++++ .../files/xscreensaver-6.01-gentoo.patch | 47 +++++++ .../files/xscreensaver-6.01-gtk-detection.patch | 25 ++++ .../files/xscreensaver-6.01-interix.patch | 30 ++++ .../files/xscreensaver-6.01-non-gtk-install.patch | 56 ++++++++ .../xscreensaver-6.01-without-gl-makefile.patch | 28 ++++ .../xscreensaver-6.03-without-gl-configure.patch | 12 ++ .../xscreensaver-6.05-configure-exit-codes.patch | 29 ++++ .../xscreensaver-anclock-2.1.0.ebuild | 151 +++++++++++++++++++++ 13 files changed, 539 insertions(+)
