[aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU

[Eli Schwartz via aur-general]

Not everything that is available only to an aurweb account of the
Trusted User type, qualifies as a TU "privilege"

Signed-off-by: Eli Schwartz 
---

Handy link to context and surrounding discussion:

https://lists.archlinux.org/pipermail/aur-general/2018-January/033789.html

The current wording of the bylaws indicates that there are two ways for
a TU to qualify for special removal due to inactivity:

1) Do not participate in voting, thereby potentially blockading a quorum.

2) Do not participate in general TU'ish activities like maintaining
   [community], administrating the AUR and the packagers and users therein,
   being representative of TUs in general on this mailing list by being
   awesome and stuff, i.e. posting (hopefully useful information that helps
   AUR users), and... um... voting?

Point #2 calls out "performed any action that required TU privileges on
the AUR", but does the tu voting interface on aurweb count as that or
not? Moreover, do we *want* it to count? It seems to be somewhat
defeating the purpose of the process, i.e. as long as a TU doesn't
actually block quorum during a vote, they can remain while not actually
performing any of the inherent functions of a TU.

Now, I would argue that under a common sense interpretation the original
intent of the bylaws was almost certainly that voting does not count as
a "TU privilege", since a TU is someone who has the "privilege" to
administrate AUR packages and users in order to keep good order, and
select good packages to upload to [community]. 

But bylaws exist in order to prevent people from having different
interpretations of common sense. So this should be clarified no matter
what.


 tu-bylaws.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tu-bylaws.txt b/tu-bylaws.txt
index c7a376e..27e4804 100644
--- a/tu-bylaws.txt
+++ b/tu-bylaws.txt
@@ -142,7 +142,9 @@ A TU who has not done ANY of the following for a period of 
at least 2 months:
 
 1. added, removed or updated a package in +[community]+ or the AUR
 
-2. performed any action that required TU privileges on the AUR
+2. performed any action that required TU privileges on the AUR, for example
+resolving package requests, modifying user accounts, or force pushing to a
+package base, but NOT including participation in a voting period
 
 3. posted a message to 
https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]
 
-- 
2.16.0

Re: [aur-general] Special Removal of an Inactive TU: speps

[Doug Newgard via aur-general]

On Thu, 18 Jan 2018 22:05:10 +0100
Thorsten Toepper  wrote:

> Whether the votes happens in the AUR web interface or on a separate
> private mailing list is unimportant for the real process I agree, just
> at the moment it's the AUR webinterface and the second point is simply
> not too well formulated, in it's current form this also includes the
> votes and therefore in case someone participated in a vote both blocks
> are neglected. So the "either" "or" doesn't really work here.
> 

Yes, it is a bit ambiguous. The discussion in #archlinux-tu concluded that the
voting being an the AUR was just happenstance and intent of the section was
that voting not be included in point 2. With many/most of the most active TUs
participating or present for that discussion, I would conclude that the general
understanding of this section was followed in this case and the motions have
passed.


pgpM3bTPDM63B.pgp
Description: OpenPGP digital signature

Re: [aur-general] Special Removal of an Inactive TU: speps

[Lukas Fleischer via aur-general]

On Thu, 18 Jan 2018 at 22:05:10, Thorsten Toepper wrote:
> [...]
> Whether the votes happens in the AUR web interface or on a separate
> private mailing list is unimportant for the real process I agree, just
> at the moment it's the AUR webinterface and the second point is simply
> not too well formulated, in it's current form this also includes the
> votes and therefore in case someone participated in a vote both blocks
> are neglected. So the "either" "or" doesn't really work here.
> 
> Rephrasing the bylaw to something like
> 
> "performed any action that required TU privileges on the AUR
> (*excluding* participation in votes for there is below rule)"
> [...]

Due to lack of time, I did not follow the whole discussion, so please
excuse me for potentially addressing things that are resolved already.

Using common sense, the bylaws are pretty clear. It makes no sense to
count TU voting as an "action that required TU privileges". Otherwise,
the statement after the "OR" would imply the statements before the "OR",
making the extra part "who has not voted in a consecutive series of
voting periods [...]" superfluous.

That said, I would appreciate any efforts to improve the wording, just
to avoid future confusion and discussion.

Best regards,
Lukas

Re: [aur-general] Special Removal of an Inactive TU: speps

[Thorsten Toepper]

On 18.01.2018 22:11, Eli Schwartz via aur-general wrote:
> On 01/18/2018 04:05 PM, Thorsten Toepper wrote:
>> First of all: Congratulations for becoming a TU, you should have applied
>> sooner so I could've given you my "yes". :-)
> 
> Thanks! :)
> 
>> Rephrasing the bylaw to something like
>>
>> "performed any action that required TU privileges on the AUR
>> (*excluding* participation in votes for there is below rule)"
>>
>> would solve the problem, that TUs may only act in the absolute
>> background of participation votes, yet not taking care of any binary
>> packages or AUR package management any more.
> 
> I would definitely agree that we need to clarify the bylaws on this
> point, and I'll probably propose something soon.
> 
> I'm not sure what that means we should do about the current vote though.
> 

My idea last night was that the unquestionable move would be to declare
the current results as something like "invalid"/"to be ignored" and
after the bylaw has been adjusted to repeat them. I can't see the state
of the quorum for the recent proposals, but as long as that wasn't in
any danger I'd say there is no real urge as everyone knows (or should
know) that the proposals and votes will be repeated afterwards in case
the situation does not change and speps or faidoc become more active again.

Alternatives that currently come to my mind are to either start
proposals based on the "normal" removal bylaw.

Or, the probably easier approach, that there is a public agreement of
multiple TUs on this list that the voting results are ignored until an
adjustment of the rule has been accepted and applied. In case they have
not become more active until the change becoming accepted the results
are acknowledged in retro perspective. This would give them themselves a
chance to act by either becoming more active, explaining what happened
or simply resigning and save all other TUs some time.

And now it's time for bed. Good night. :-)



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Special Removal of an Inactive TU: speps

[Eli Schwartz via aur-general]

On 01/18/2018 04:05 PM, Thorsten Toepper wrote:
> First of all: Congratulations for becoming a TU, you should have applied
> sooner so I could've given you my "yes". :-)

Thanks! :)

> Rephrasing the bylaw to something like
> 
> "performed any action that required TU privileges on the AUR
> (*excluding* participation in votes for there is below rule)"
> 
> would solve the problem, that TUs may only act in the absolute
> background of participation votes, yet not taking care of any binary
> packages or AUR package management any more.

I would definitely agree that we need to clarify the bylaws on this
point, and I'll probably propose something soon.

I'm not sure what that means we should do about the current vote though.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Special Removal of an Inactive TU: speps

[Thorsten Toepper]

On 18.01.2018 02:11, Eli Schwartz via aur-general wrote:
> On 01/17/2018 06:18 PM, Thorsten Toepper wrote:
>> I'm no longer a TU so I can't see how active both speps and faidoc have
>> been regarding participation in the votes. Yet the TU-Bylaws are pretty
>> strict and given that Bluewind/Florian pointed out during the discussion
>> period that both TUs had participated in proposal 99 that started on
>> December 18 2017 which is in my TZ now exactly one month ago. Therefore
>> the second requirement, to NOT do any special action on the AUR
>> requiring TU privileges is not fulfilled, as participating in votes is
>> exactly one of these TU privileges. Also the alternative option with
>> inactivity due to non-participation in votes has been invalidated by
>> this participation. Unless of course there have been six such votes
>> before, again I can't see that nor if they themselves participated in
>> the votes for proposal 100 and 101.
> 
> "as participating in votes is exactly one of these TU privileges"
> 
> This does seem to be unclear in the Bylaws. As someone mentioned on IRC:
>> In my mind aurweb just happens to be a convenient place for the vote
>> functionality to be located, but isn't actually part of the AUR.
> 
> Does voting, an action which doesn't seem to have a lot to do with
> *being* a TU, merely deciding who should be allowed to do so, and is
> more or less invisible to the community, constitute a "TU privilege" on
> the AUR?
> 
> Looking at the context of previous amendment discussions, it seems like
> the Special Removal was motivated by the desire to remove TUs who
> 
> EITHER
> block quorum by failing to vote,
> 
> OR
> fail to enhance the AUR as TUs are intended to do, by such qualifying
> actions as:
> - elevating packages to [community]
> - contributing to the AUR as a good example
> - moderating the package list or users
> - participated in general discussion about the AUR on this list
> 
> To that end, as bgyorgy said, the "Arch User Repository" would be "that
> which the regular users interact with to upload package recipes", and
> totally unrelated to an administrative voting interface which is only
> implemented in aurweb (not the AUR) insomuch as it would be bloat to
> host it separately.
> 

First of all: Congratulations for becoming a TU, you should have applied
sooner so I could've given you my "yes". :-)

As I just wrote in the other mail and as we all seem to agree the social
management is also an important task a TU needs to do. As you say, the
historic background was the problem that TUs being active in the formal
part of being a TU by actively contributing to package management, but
ignoring the social part could not be actively "motivated" so it was
necessary to redefine the rules for reaching a valid quorum and getting
rid of people not taking the social part serious.

Whether the votes happens in the AUR web interface or on a separate
private mailing list is unimportant for the real process I agree, just
at the moment it's the AUR webinterface and the second point is simply
not too well formulated, in it's current form this also includes the
votes and therefore in case someone participated in a vote both blocks
are neglected. So the "either" "or" doesn't really work here.

Rephrasing the bylaw to something like

"performed any action that required TU privileges on the AUR
(*excluding* participation in votes for there is below rule)"

would solve the problem, that TUs may only act in the absolute
background of participation votes, yet not taking care of any binary
packages or AUR package management any more.

As I wrote in the other mail I fully support Gjörgy's action to check
all TUs and initiate votes, it's just that the rule that was chosen to
be applied has this loophole with the participation in votes. And it
should be considered to fix this.

Two TUs initiating the "normal" process based solely on arguments
would've also been fine.

Cheers,
Thorsten

PS: Sorry in case there are too many words missing in sentences, as I'm
very tired I only proof-read once so I most likely missed several occasions.



signature.asc
Description: OpenPGP digital signature

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

[Alad Wenter via aur-general]

On Thu, Jan 18, 2018 at 09:32:46PM +0100, Bennett Piater wrote:
> 
> 
> On 01/18/2018 09:25 PM, Alad Wenter via aur-general wrote:
> > On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> > Except, as noted, that "major feature" doesn't work at all...
> 
> Doesn't it?
> It appeared to work when I tried it, and that was this morning...
>
See the bug report I linked in the first reply.

https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-to-systemd-logind

Alad


signature.asc
Description: PGP signature

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

[Bennett Piater]

On 01/18/2018 09:25 PM, Alad Wenter via aur-general wrote:
> On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> Except, as noted, that "major feature" doesn't work at all...

Doesn't it?
It appeared to work when I tried it, and that was this morning...

Cheers,
Bennett

-- 
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Special Removal of an Inactive TU: speps

[Thorsten Toepper]

On 18.01.2018 01:43, Balló György via aur-general wrote:
> On 18.01.2018 00.18, Thorsten Toepper via aur-general wrote:
>> Therefore the second requirement, to NOT do any special action on the
>> AUR requiring TU privileges is not fulfilled, as participating in
>> votes is exactly one of these TU privileges.
> 
> This is unclear in the bylaws. I assumed that AUR is the repository
> where the user-contributed packages are stored. Therefore the actions
> that require AUR privileges are: disown/merge/delete a package. These
> actions are tracked on the aur-requests mailing list only if a request
> was filed before the action, so we don't really know the last
> privileged action of a TU. I think it should be implemented within the
> AUR web interface.

Well, from my point of view being a TU is not solely about package
management or taking care of what users posted about the packages stored
in the AUR. It's also about what you did here with this action, keeping
the group of users who have a higher influence on what happens with Arch
Linux (be it what ends up in [community] or is dropped again, management
of users in the AUR system) in a good shape.

Please don't misunderstand my mail from last night it's no "WHAT YOU DID
WAS WRONG DON'T DO THAT EVER AGAIN!!!". I consider it great that you
initiated these proposals, I just feel uneasy about the point that
Florian pointing out for both that they still participate in the social
part of being a TU. We wouldn't have this discussion if there had been a
second person initiating this with you and the "normal" removal had been
applied. Your arguments are fine, they are objective and there is no
personal affection visible, so this should have sufficed.

As the special removal has been applied the votes need to be considered
in both blocks, the one before the big OR and the one afterwards. My
position is that in the first block the second point, has been fulfilled
due to participation in the social part of being a TU and this also
applied for the second block.

I can't remember how many years it's been since there was the last
discussion that lead to this rule and I won't invest time (the lack of
that made step down) searching the office, but what I [think to]
remember pretty well that the problem point back then was people having
the special privileges of being a TU didn't participate in votes which
lead to failures due to quorums that couldn't be reached without their
participation. And there were also discussions in case applications
overlapped how in case the first applicant becomes a TU will be counted
into the quorum of the second application. As vote participation was one
of the central points back then I consider the votes to be an important
factor if this "method" is chosen to be applied.

That's why I proposed at the end of last nights mail to consider a
overhaul of the wording of the definition to make the definition more
strict and reduce the room of interpretation. With a second vote
afterwards there wouldn't be anything to question.

So again, this is no attack in any form, last night I just remembered
old discussions in public and behind the curtains in the IRC about the
problem with the quorums and that there was the need of a rule to strip
TUs of their special status in case they ignored this social aspect of
their task. And therefore I think that if that rule is chosen, the
historic background should not be forgotten.

And again: It's good you looked at the status of all TUs and took
action. :-)

Cheers,
Thorsten



signature.asc
Description: OpenPGP digital signature

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

[Alad Wenter via aur-general]

On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> This doesn't take care of locking on inactivity though, which is the other 
> major feature of xss-lock. 
> 
That said, a short implementation may look as follows:

https://github.com/grawity/hacks/blob/master/desktop/systemd-lock-handler

Alad


signature.asc
Description: PGP signature

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

[Alad Wenter via aur-general]

On Thu, Jan 18, 2018 at 09:24:04PM +0100, Bennett Piater wrote:
> This doesn't take care of locking on inactivity though, which is the other 
> major feature of xss-lock. 
> 
Except, as noted, that "major feature" doesn't work at all...

Alad


signature.asc
Description: PGP signature

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

[Bennett Piater]

This doesn't take care of locking on inactivity though, which is the other 
major feature of xss-lock. 

Cheers, 
Bennett
-- 
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808

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

[Alad Wenter via aur-general]

On Thu, Jan 18, 2018 at 08:52:23PM +0100, Pierre Neidhardt wrote:
> 
> Alad Wenter via aur-general  writes:
> 
> > If you use polkit and acpid, a "simple" alternative is to use
> > systemd-inhibit, and run actions based on acpid events. Not sure there's
> > a ready implementation with X support in mind.
> 
> Could you detail this?  How do you set it up?  What is lacking in terms
> of X support?
> 
As we know, logind by default does actions like suspend on closing the
lid or pressing the suspend button. Rather than modify these actions to
run some event (like locking the screen priorly) through services files,
you can temporarily disable them with systemd-inhibit. [1] Example:

  $ systemd-inhibit --what=handle-lid-switch --why=Locker screenlocker

The default mode is "block", which delays the set actions indefinitely.
To use it as a regular user, you rely on polkit. This is quite similar
what DE power managers à la xfce4-power-manager do.

"screenlocker" in its most basic form would look at ACPI events from
acpid, and run actions accordingly. Example: [2]

  #!/bin/bash
  coproc acpi_listen
  trap 'kill $COPROC_PID' EXIT

  while read -u "${COPROC[0]}" -a event; do
  handler.sh "${event[@]}"
  done

The benefit of this (and xss-lock's) approach is that your screenlocker
program is run in the environment of the current user, so there's no
need for common hacks such as hardcoding DISPLAY. With systemd-inhibit
you also have some fallback in place should "screenlocker" fail for some
reason, at least assuming it exits on error.

Of course, you can extend the scope of "screenlocker" to react to any
arbitrary ACPI events, for example for volume controls - with latter you
get functional controls in full-screen applications as well.

One issue remains and that is how the program should react when you log
out from your X session, that is when the currently running X server
terminates. xss-lock would simply quit in this case, and if writing in C
you should be able to easily replace this behavior. Unsure about shell.

Another potential issue is on multi-user systems. If both listen to acpi
events in this way there may be conflicts.

Alad

[1] https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
[2] https://wiki.archlinux.org/index.php/Acpid#Connect_to_acpid_socket


signature.asc
Description: PGP signature

Re: [aur-general] Wrong AUR Build file

[Morgan Adamiec via aur-general]

Yes you would have that responsibility or maybe you could find
some one else to maintain it instead.
if the package is broken and you don't plan on maintaining it, that's
when I would send a deletion request.
Any one is free re upload the fixed package again in future.

On 18 January 2018 at 20:05, Panayotis Katsaloulis via aur-general
 wrote:
>
> Picking up the package doesn't also have the great responsibility of
> maintaining the package? :-o
>
>
> Στις Πεμ, 18 Ιαν, 2018 at 10:02 ΜΜ, ο/η Morgan Adamiec
> via aur-general  έγραψε:
>> I would probably leave a comment over emailing directly.
>> If you get no response after a while I would then send an
>> orphan/deletion
>> request detailing the problem and pick up the package myself and fix
>> the problems.
>>
>> On 18 January 2018 at 19:55, Panayotis Katsaloulis via aur-general
>>  wrote:
>>>  Hello people
>>>
>>>  Newbie here in Arch Linux.
>>>
>>>  I have a question, which I didn't find in the documentation.
>>>
>>>  What is the proposed way to inform about an AUR build file
>>> containing
>>>  errors? Especially if I e-mailed the maintainer with no response?
>>>
>>>  Thank you!
>

Re: [aur-general] Wrong AUR Build file

[Eli Schwartz via aur-general]

On 01/18/2018 03:05 PM, Panayotis Katsaloulis via aur-general wrote:
> Picking up the package doesn't also have the great responsibility of 
> maintaining the package? :-o

Is it very problematic to do so?
I assume you're interested in the software, so why not maintain it while
you are at it?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

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

[Eli Schwartz via aur-general]

On 01/18/2018 03:02 PM, Pierre Neidhardt via aur-general wrote:
> 
> It's only 4 commits since 0.3.0, two of them being critical fixes.
> I could backport those two commits (just tried: no conflict); it feels
> needlessly pedantic however, compared to using "master" straight away.
> 
> I've contacted the developer, see if he replies within a few days.  If
> not, I'll go ahead with the patches.

If upstream has abandoned the project for years without tagging a stable
release, then I would feel totally okay about taking my own prerogative
to evaluate if master is stable, and if so, package the latest

source=("https://bitbucket.org/raymonad/xss-lock/get/${_commit}.tar.gz;)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Wrong AUR Build file

[Panayotis Katsaloulis via aur-general]

Picking up the package doesn't also have the great responsibility of 
maintaining the package? :-o


Στις Πεμ, 18 Ιαν, 2018 at 10:02 ΜΜ, ο/η Morgan Adamiec 
via aur-general  έγραψε:
> I would probably leave a comment over emailing directly.
> If you get no response after a while I would then send an 
> orphan/deletion
> request detailing the problem and pick up the package myself and fix
> the problems.
> 
> On 18 January 2018 at 19:55, Panayotis Katsaloulis via aur-general
>  wrote:
>>  Hello people
>> 
>>  Newbie here in Arch Linux.
>> 
>>  I have a question, which I didn't find in the documentation.
>> 
>>  What is the proposed way to inform about an AUR build file 
>> containing
>>  errors? Especially if I e-mailed the maintainer with no response?
>> 
>>  Thank you!

Re: [aur-general] Wrong AUR Build file

[Morgan Adamiec via aur-general]

I would probably leave a comment over emailing directly.
If you get no response after a while I would then send an orphan/deletion
request detailing the problem and pick up the package myself and fix
the problems.

On 18 January 2018 at 19:55, Panayotis Katsaloulis via aur-general
 wrote:
> Hello people
>
> Newbie here in Arch Linux.
>
> I have a question, which I didn't find in the documentation.
>
> What is the proposed way to inform about an AUR build file containing
> errors? Especially if I e-mailed the maintainer with no response?
>
> Thank you!

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

[Pierre Neidhardt via aur-general]

It's only 4 commits since 0.3.0, two of them being critical fixes.
I could backport those two commits (just tried: no conflict); it feels
needlessly pedantic however, compared to using "master" straight away.

I've contacted the developer, see if he replies within a few days.  If
not, I'll go ahead with the patches.

--
Pierre Neidhardt

Sodd's Second Law:
Sooner or later, the worst possible set of circumstances is
bound to occur.


signature.asc
Description: PGP signature

[aur-general] Wrong AUR Build file

[Panayotis Katsaloulis via aur-general]

Hello people

Newbie here in Arch Linux.

I have a question, which I didn't find in the documentation.

What is the proposed way to inform about an AUR build file containing 
errors? Especially if I e-mailed the maintainer with no response?

Thank you!

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

[Pierre Neidhardt via aur-general]

Alad Wenter via aur-general  writes:

> If you use polkit and acpid, a "simple" alternative is to use
> systemd-inhibit, and run actions based on acpid events. Not sure there's
> a ready implementation with X support in mind.

Could you detail this?  How do you set it up?  What is lacking in terms
of X support?

-- 
Pierre Neidhardt

Nobody said computers were going to be polite.


signature.asc
Description: PGP signature

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

[Levente Polyak via aur-general]

On January 18, 2018 7:26:33 PM GMT+01:00, Pierre Neidhardt via aur-general 
 wrote:
>
>The 100%-cpu issue should be fixed upstream on master (and thus also in
>the -git package).
>I've mentioned this on the wiki:
>

Why not simply backporting it via a patch file then?

Cheers,
Levente 

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

[Alad Wenter via aur-general]

On Thu, Jan 18, 2018 at 07:26:33PM +0100, Pierre Neidhardt wrote:
> 
> The 100%-cpu issue should be fixed upstream on master (and thus also in the 
> -git package).
> I've mentioned this on the wiki:
> 
> https://wiki.archlinux.org/index.php/Power_management#xss-lock
> 
Since that's a fairly significant issue, why not include the commit that
fixes it in the community package? git cherry-pick should do the job.

Alad


signature.asc
Description: PGP signature

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

[Pierre Neidhardt via aur-general]

The 100%-cpu issue should be fixed upstream on master (and thus also in the 
-git package).
I've mentioned this on the wiki:

https://wiki.archlinux.org/index.php/Power_management#xss-lock


I'll ask the author if he's still maintaining it.
I might consider a fork otherwise.

-- 
Pierre Neidhardt

A real friend isn't someone you use once and then throw away.
A real friend is someone you can use over and over again.


signature.asc
Description: PGP signature

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

[Alad Wenter via aur-general]

On Tue, Jan 16, 2018 at 10:59:49AM +0100, Pierre Neidhardt via aur-general 
wrote:
> 
> Seems fairly popular, plus it's useful to lock the screen on sleep
> without systemd.
I realize I'm somewhat late with this response, but upstream hasn't
updated their project in years and the release has several outstanding
issues, such as using 100% CPU [1] and broken features such as the
advertised IdleAction support. [2]

If you use polkit and acpid, a "simple" alternative is to use
systemd-inhibit, and run actions based on acpid events. Not sure there's
a ready implementation with X support in mind.

Or now that you've adopted it, perhaps you could look over the ~700
lines of C code and fix outstanding issues. :)

Alad

[1] 
https://bitbucket.org/raymonad/xss-lock/issues/6/hang-high-cpu-on-session-exit
[2] 
https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-to-systemd-logind