Bug#919348: bring it in for Bookworm?
Hi! Would you be willing to reconsider for Bookworm? While you do have reservations about xfce4-screensaver, the question is not whether it's perfect, but how it fares against alternatives. And lightm-locker is so buggy it's outright useless for a good deal of users while reports for xfce4-screensaver are better. Thus even if not default, it'd be good to have it as an alternative -- at least installable. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#992360: can be backported
Control: retitle -1 please backport to bullseye Control: severity -1 wishlist Hi! A package not making it to the stable release is by no means a RC bug, merely a statement of the package's quality at a time in the past. I'm adjusting severity accordingly. On the other hand, this case (and associated user frustration) can very well be solved by a backport. I've checked that it builds for Bullseye without modifications. Thus: XFCE guys, please upload to unstable and bullseye-backports! Thanks for your good work so far. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables ⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice. ⠈⠳⣄
Bug#919348: many new releases since -- still "too buggy"?
Hi! Since your last report of a crash, there's been six new releases: five in the 0.1.* version series, and now one 4.16.0-1. As the new version claims a stable release, is there still a reason to keep xfce4-screensaver out of Bullseye? I've been using it happily all the time, with no borkage to report. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#954212: ristretto: can't delete files without "Trash"
Package: ristretto Version: 0.10.0-1 Severity: normal Upon trying to delete images from a jmtpfs mount, I get: .--=== An error occured when sending image 'DSC_0672.jpg' to trash. Unable to find or create trash directory for /tmp/and/Karta SD/DCIM/100ANDRO/DSC_0672.jpg `--=== The option is misnamed -- eg. XFCE's file browser (Thunar) calls it "Move to trash"; some others have even separate "Move to trash" and "Delete". In any case, I'd expect a fallback to actual deletion -- this is what Thunar, Windows Explorer, etc do. Windows even doesn't try using trash for remote filesystems, the confirmation dialog immediately says "delete". Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-rc6-00085-ge6fd0e58416e (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ristretto depends on: ii libc62.30-2 ii libcairo21.16.0-4 ii libexif120.6.21-6 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-3 ii libglib2.0-0 2.64.1-1 ii libgtk-3-0 3.24.14-1 ii libmagic11:5.38-4 ii libpango-1.0-0 1.42.4-8 ii libpangocairo-1.0-0 1.42.4-8 ii libx11-6 2:1.6.9-2 ii libxfce4ui-2-0 4.14.1-1+b1 ii libxfce4util74.14.0-1 ii libxfconf-0-34.14.1-1 Versions of packages ristretto recommends: ii tumbler 0.2.8-1 ristretto suggests no packages. -- no debconf information
Bug#931837: lightdm: Depends =~ s/libpam-systemd/default-logind/
On Thu, Jul 11, 2019 at 08:51:37PM +0200, Yves-Alexis Perez wrote: > Is default-logind [linux-any] as well? I don't think of any logind implementations for non-Linux, so a hard dependency would need to be qualified, yeah. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Yo momma uses IPv4! ⢿⡄⠘⠷⠚⠋⠀ But why should you? ⠈⠳⣄ https://ipv4flagday.net/
Bug#919348: is it still unfit for Bullseye?
On Sat, Jul 13, 2019 at 04:40:31PM +0200, Yves-Alexis Perez wrote: > On Thu, 2019-07-11 at 10:34 +0200, Adam Borowski wrote: > > So... is there any reason to not let xfce4-screensaver go to Bullseye? > > Any day that a human being suffers from light-locker is a bad day. > > Hi Adam, > > could you please refrain from such statements? Some people, volunteers mostly, > have taken time to actual write that software, package it etc. I find this > rude, to be honest. Well, there is no problem in software X having bugs -- any non-trivial program is buggy, and especially a novel approach like that tried by light-locker is bound to run into problems. But, pushing a thoroughly buggy piece of code, that's in my opinion not fit for release, as the default for a major desktop environment, and the only allowed by that DE's task, is not a good idea. Apologies for expressing myself too emphatically -- but with my (indeed rude) wording aside, the point stands. > > If you're afraid about yet-unknown bugs, more exposure to users early > > in the release cycle would be a good idea. > > For a locker screen, I'd really like someone to take a look at the code (even > if only the differences with gnome-screensaver). I'm afraid I have no experience at all with X coding, all I can offer is testing as a mere user. But I do run a diverse set of machines, ranging four archs (amd64 i386 x32 arm64), ages (2004-2018), types (desktops, SoC, laptops), GPUs, rc systems (sysv-rc, openrc -- with one notable omission :p), etc -- thus I believe my good opinion about xfce4-screensaver carries some weight. > The light-locker code in the process which does the locking is actually > quite simple (no complicated UI, no screensaver at all etc.) Yet the way it offloads the task to lightdm is fragile. > > On the other hand, light-locker suffers from a multitude of known > > problems (see the recent debian-devel thread), and you hate the third > > alternative, xscreensaver > > Actually no-one seems to know which package(s) is buggy. My gut feeling is > that the drivers handle vt-switches and backlight off badly, not a bug in > light-locker. But again no-one seems interested to find out. This particular problem may be indeed hard to track, but none of the alternatives (xscreensaver, xfce4-screensaver) suffer from it. Nor from the others (no visual feedback that you're logged in, pointless vt switches, not working when started not from a DM, ... [I haven't retried in a while, some of those might have been fixed]). Unless you have a particular reason to stick with light-locker, fixing it may be a waste of your time. > If you volunteer, I welcome any help on this, whether by finding the issues > with the light-locker/lightdm/DDX stack or actually making sure there's no > security issue in xfce4-screensaver. I'm afraid I have neither the tuits nor expertise to help with fixing or dedicated QA here, just testing as a part of using the product of your efforts in my daily work and hacking. And there's a reason I annoy you rather than Mate, KDE, *shudder* Gnome, or Gnustep folks :) But, in this case, I am very excited that you have a replacement for something I find to be hopelessly buggy -- and the replacement seems near-perfect. Thus, if you switch, you save a lot of time, and any bit of time you save is a bit of time you can spend catering to my other whims. :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned ⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem? ⠈⠳⣄
Bug#919348: is it still unfit for Bullseye?
> So we're filing an RC bug to prevent it from migrating to testing, > this can be closed once buster is frozen. So... is there any reason to not let xfce4-screensaver go to Bullseye? Any day that a human being suffers from light-locker is a bad day. If you're afraid about yet-unknown bugs, more exposure to users early in the release cycle would be a good idea. On the other hand, light-locker suffers from a multitude of known problems (see the recent debian-devel thread), and you hate the third alternative, xscreensaver (jwz's time bomb being indeed a good reason). Closing this bug should be enough...? Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned ⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem? ⠈⠳⣄
Bug#931837: lightdm: Depends =~ s/libpam-systemd/default-logind/
Package: lightdm Version: 1.26.0-5 Severity: wishlist Hi! You've just changed Depends from logind | consolekit to libpam-systemd | logind I assume that you missed the new Policy -- discussed and approved before Buster, released as a package a few days ago. It standardizes the above dependency as: default-logind | logind which it would be nice if you could change to. I'm filing as wishlist as there _currently_ are no functional differences in Debian proper; it matters only because: * derivatives wouldn't need to patch this package * libpam-systemd's packaging may change as it has multiarch issues Thanks for your work so far! Meow. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-00033-ga37b923e2493 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lightdm depends on: ii adduser 3.118 ii dbus1.12.16-1 ii debconf [debconf-2.0] 1.5.72 ii libaudit1 1:2.8.5-1 ii libc6 2.28-10 ii libgcrypt20 1.8.4-5 ii libglib2.0-02.58.3-2 ii libpam-elogind-compat [libpam-systemd] 1.3 ii libpam0g1.3.1-5 ii libxcb1 1.13.1-2 ii libxdmcp6 1:1.1.2-3 ii lsb-base10.2019051400 ii slick-greeter [lightdm-greeter] 1.2.4-2 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+19 Versions of packages lightdm suggests: pn accountsservice ii upower 0.99.10-1 pn xserver-xephyr -- Configuration Files: /etc/lightdm/lightdm.conf changed: [LightDM] [Seat:*] display-setup-script=xrandr --output DisplayPort-0 --mode 2560x1600 --output DVI-D-0 --mode 1600x1200 --rotate left --right-of DisplayPort-0 [XDMCPServer] [VNCServer] -- debconf information: * shared/default-x-display-manager: lightdm lightdm/daemon_name: /usr/sbin/lightdm
Bug#929834: Buster/XFCE unlock screen is blank
On Sat, Jun 01, 2019 at 11:06:42AM +0200, Andreas Tille wrote: > > This appears to be a bug in light-locker specifically, which is the > > default screen lock program with XFCE with lightdm. See, for instance: > > > > https://github.com/the-cavalry/light-locker/issues/114 > > > > Switching to another greeter from the default gtk-greeter appears to help > > according to that bug, which may mean that the bug is actually in > > lightdm-gtk-greeter. There doesn't appear to be a Debian bug for this; it > > might be a good idea to open one against light-locker (or, if you confirm > > switching to slick-greeter per that bug, lightdm-gtk-greeter). > > Yes, please file the bug (and may be report the bug number here). We > should not release with a broken greeter as default since we can not > assume that normal users will find out the "switch VT trick" and instead > will assume the box is frozen. While I greatly prefer slick-greeter (I use it exclusively since the first day I reviewed+sponsored the package), I recall it doesn't support a11y anywhere as well as the default greeter. This is old data, though -- as my wetware doesn't require a11y, I wouldn't even know what to look at. But, the culprit is light-locker. In general, it's in such a buggy state that I believe it shouldn't be in the distribution at all, much less a default of any kind. After it replaced xscreensaver[1] as the xfce's dependency, I went into some pretty heated arguments, but then stormed off and ignored the issue. Just some issues with light-locker. INACCURATE, BASED ON AN OLD VERSION, AND NOT RESEARCHED WELL AT ALL. (Ie, areas to look at, not proper reports) * it doesn't show anyone is logged in -- lock screen is pixel-to-pixel identical as the login screen * breaks when the *DM is not lightdm. A package dependency doesn't mean that lightdm is running or used to start that session. * breaks with multiseat (as in: concurrent same-uid logins from different seats, not the systemd meaning) * breaks if ssh -X into the box is used with some programs * breaks with any non-standard VT assignment (Some of the issues might have been already fixed.) At the time of the xscreensaver debacle, there was no sane alternative (candidates depended on 80% of GNOME, offered no feedback nor discoverable controls to the user, etc). There _is_ a wonderful alternative now: xfce4-screensaver, which seems to work perfectly[2] -- but alas, it's not in Buster. Using unstable myself, I'm not sure what to recommend for Buster. But if the bugs can't get fixed in late freeze, and slick-greeter is not enough, I's light-locker not the greeter I'd propose switching out of. Meow! [1]. When jwz planted a time-bomb in xscreensaver. [2]. There was an issue with taking lots of CPU even when the monitor has been long since powered down, but that's now fixed. -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#921835: xfce4-screensaver: wastes CPU while the display is off
On Thu, Feb 21, 2019 at 01:45:31PM +0100, Yves-Alexis Perez wrote: > On Sat, 2019-02-09 at 11:53 +0100, Adam Borowski wrote: > > Package: xfce4-screensaver > > Version: 0.1.3-2 > > > > I left home for the weekend, just ssh-ed in and I see: > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > > 2375 root 20 0 823412 223376 169752 R 96.3 2.7 1946:54 Xorg > > 24967 kilobyte 20 0 31540 5736 4496 R 34.9 0.1 1:26.92 zoom > > 24966 kilobyte 20 0 31144 5188 4320 S 28.2 0.1 1:11.75 zoom > > > > The screen has been locked for nearly a day, thus it's obviously off (which > > I can't verify). > I think you should be able to disable the screensavers or to just select > “blank screen” instead of letting xfce4-screensaver select a random one. That'd workaround the issue, yeah. > > Once the monitor gets suspended/slept/powered off, there's completely no > > point in drawing anything. On the other hand, a computer with two cores > > worth of activity for a prolonged time wastes a significant amount of > > electricity, which is bad both for the environment and for users' wallets. > > > > Thus: could you please stop spawning new "draw something" processes once > > the saver has gone past the first (visual) stage? > > Agreed, but this is likely a bug in mate-screensaver (or whatever the code > originally comes from). Jonathan, could you take a look? > > Honestly I'd be just fine in just disabling all the screensavers and only keep > blank screen. Do you mean dropping them all by default, or just after the powersave kicks in? The latter would keep the eyecandy when there's a human around. Not that the eyecandy distraction feature is so vital... Just blanking the screen is probably as good. I need *-screensaver as a sane locker (ie, anything _but_ light-locker), not for its visual appeal. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#921835: xfce4-screensaver: wastes CPU while the display is off
Package: xfce4-screensaver Version: 0.1.3-2 Severity: normal I left home for the weekend, just ssh-ed in and I see: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 2375 root 20 0 823412 223376 169752 R 96.3 2.7 1946:54 Xorg 24967 kilobyte 20 0 31540 5736 4496 R 34.9 0.1 1:26.92 zoom 24966 kilobyte 20 0 31144 5188 4320 S 28.2 0.1 1:11.75 zoom The screen has been locked for nearly a day, thus it's obviously off (which I can't verify). For further information, I left this bug report half-written for while; the screensaver has in the meantime rolled over to something else that takes just 20% X + 2*7% for screensavers proper, then to euler3d at 27% X + 2*13%. That's better than nearly two full cores as for zoom, but the question is: why? Once the monitor gets suspended/slept/powered off, there's completely no point in drawing anything. On the other hand, a computer with two cores worth of activity for a prolonged time wastes a significant amount of electricity, which is bad both for the environment and for users' wallets. Thus: could you please stop spawning new "draw something" processes once the saver has gone past the first (visual) stage? Meow! -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.0-rc5-debug-00035-g12a002e2de92 (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xfce4-screensaver depends on: ii libc6 2.28-6 ii libcairo2 1.16.0-2 ii libdbus-1-3 1.12.12-1 ii libdbus-glib-1-20.110-4 ii libgarcon-1-0 0.6.2-1 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgl1 1.1.0-1 ii libglib2.0-02.58.3-1 ii libgtk-3-0 3.24.5-1 ii libpam0g1.1.8-4 ii libpango-1.0-0 1.42.4-6 ii libsystemd0 240-5 ii libx11-62:1.6.7-1 ii libxext62:1.3.3-1+b2 ii libxfce4ui-2-0 4.12.1-3 ii libxfconf-0-2 4.12.1-1 ii libxklavier16 5.4-4 ii libxrandr2 2:1.5.1-1 ii libxss1 1:1.2.3-1 ii libxxf86vm1 1:1.1.4-1+b2 xfce4-screensaver recommends no packages. xfce4-screensaver suggests no packages. -- no debconf information
Bug#915531: ordering, dependencies
> init script ordering Right, it's a race. In my experience elogind seemed to always win this race, but that's luck on my side. Good catch. > Please note that this patch only accounts for boot sequence; fully > enabling elogind support in lightdm/sddm will need further patching but I > know that Adam Borowski already has a patchset, so I leave that to him. I've tried three setups with elogind: xfce + lightdm + slick-greeter [amd64] mate + lightdm + slick-greeter [x32] xfce + slim [i386] using the libpam-elogind-compat hack. All work the same: suspend and some other bits work fine, reboot and shutdown show non-grayed buttons but do nothing after logout. That's a known problem with policykit-1, which is not expected to require changes to packages that interact with it. The libpam-elogind-compat package from experimental is not supposed to ever enter unstable or buster, but functionally doesn't differ from my plan: it affects package dependencies only, without changes beyond dpkg/apt metadata. Once #915407 is accepted, I'll ask you to replace Depends: libpam-systemd with Depends: default-logind | logind but you can't do that yet. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
