I think it's quite possible and even likely that this was the first time
running 0.3.0+git20220214.adafe4-2 I don't think I have logs going back far
enough to check the messages from the old version.
This all makes sense and failing to set the idle hint might actually
explain an issue I've been ha
I opened https://github.com/wavexx/xss-lock/pull/2 upstream, which at
least improves the docs in the example service.
Ian.
On Mon, 2023-01-23 at 17:28 -0500, Stuart Freeman wrote:
> I actually added the `-s ${XDG_SESSION_ID}` while trying to debug the
> issue after reading through #994762
>
> xss-lock had been working for over a year until as recently as a
> couple days ago when I experienced a prolonged power outage
I actually added the `-s ${XDG_SESSION_ID}` while trying to debug the issue
after reading through #994762 <994...@bugs.debian.org>
xss-lock had been working for over a year until as recently as a couple
days ago when I experienced a prolonged power outage that forced a reboot,
so I'm not sure if i
On Mon, 2023-01-23 at 11:04 -0500, Stuart Freeman wrote:
> Process: 8434 ExecStart=xss-lock -s ${XDG_SESSION_ID} -n
> /usr/libexec/xsecurelock/dimmer -l -- xsecurelock (code=dumped, signal=ABRT)
Are you sure that `${XDG_SESSION_ID}` is being properly substituted
here and with the correct
Control: severity -1 important
Control: tags -1 +help
On Mon, 2023-01-23 at 11:04 -0500, Stuart Freeman wrote:
> Calling `xdg-screensaver activate` causes xss-lock to dump core.
Thank you for your report.
>From the logs it looks like xss-lock is actually hitting an assertion
which manifests in a
Package: xss-lock
Version: 0.3.0+git20220214.adafe4-2
Severity: grave
Justification: renders package unusable
Calling `xdg-screensaver activate` causes xss-lock to dump core.
Output of `systemctl --user status xss-lock:
× xss-lock.service - X Session Lock
Loaded: loaded (/home/stuar
7 matches
Mail list logo
