Re: [aur-general] Moving xss-lock to community

On 2018-02-03 14:41:33 (+0100), Pierre Neidhardt wrote: > You are probably right about that. I think however that this should be > reported upstream to systemd rather than being part of the xss-lock > package. Hmm, I could find a (probably) related RFE [1]. [1]

Re: [aur-general] Moving xss-lock to community

David Runge writes: >> I'm no systemd expert: what is the intent of the suggest systemd unit? > This would only ensure, that lock already happens right before suspend > (in the case, someone wants that). > This use-case gets around the problem of showing a small portion of >

Re: [aur-general] Moving xss-lock to community

On 2018-02-03 14:00:29 (+0100), Pierre Neidhardt wrote: > As far as I can tell, xss-lock is already run when I resume from a > suspend. Ah lol... I was under the impression, that xss-lock would need to be told to lock. It seems loginctl sends out the 'lock-sessions' after waking up from suspend by

Re: [aur-general] Moving xss-lock to community

David Runge writes: > Could you also include a service file, that propagates the lock-sessions > command, in the vein of what was suggested upstream [1]? As far as I can tell, xss-lock is already run when I resume from a suspend. I'm no systemd expert: what is the intent of

Re: [aur-general] TU application: Ivy Foster

On February 2, 2018 12:40:57 AM GMT+01:00, Ivy Foster wrote: > >For cgo, since upstream pulled in the patches I submitted, LDFLAGS are >properly picked up and we have full relro. > >libbulletml was a bit tougher. I wound up throwing out Debian's >patches to upstream's Makefile

Re: [aur-general] Moving xss-lock to community

Hi Pierre, On 2018-01-23 10:14:12 (+0100), Pierre Neidhardt via aur-general wrote: > No answer from the dev so far, so I've packaged the latest commit as Eli > suggested. > Let me know if there is anything wrong. nice to see this in [community]! Could you also include a service file, that