Github messages for voidlinux
 help / color / mirror / Atom feed
From: ericonr <ericonr@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: [ISSUE] Restructure dependencies on elogind 
Date: Sun, 12 Apr 2020 21:20:14 +0200	[thread overview]
Message-ID: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-20930@inbox.vuxu.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

New issue by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/20930

Description:
As was agreed when writing the Wayland docs page, elogind is a requirement for a safe wayland session. Therefore, should we make elogind a dependency of the wayland package itself?

Packages like Sway currently have it as a build option, defaulting to a setuid binary instead. Cage, on the other hand, doesn't enable setuid, so it definitely requires elogind (at least in its current state). However, Cage currently doesn't list elogind as a dependency, so if you try to simply install it and run it (without looking at the docs), it will error out due to missing capabilities. Even running as root doesn't work, because then it can't drop privileges properly.

Making elogind a dependency for wayland seems like it would be the best solution for all cases. I would even make a case for an INSTALL message telling the user to enable the service and restart their device (or just log in and out, idk. Whenever I enable elogind I have to reboot for it to work).

Tagging @Duncaen, because you made the case for elogind being a requirement for Wayland.

             reply	other threads:[~2020-04-12 19:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-12 19:20 ericonr [this message]
2020-04-12 20:18 ` st3r4g
2020-04-12 20:20 ` st3r4g
2020-04-12 20:30 ` st3r4g
2020-04-12 21:25 ` ericonr
2020-04-12 21:56 ` travankor
2020-04-12 21:57 ` st3r4g
2020-04-12 21:58 ` st3r4g
2020-04-12 22:08 ` st3r4g
2020-04-12 22:09 ` st3r4g
2020-04-12 22:30 ` st3r4g
2020-04-12 23:28 ` ericonr
2020-04-15 19:33 ` st3r4g
2020-04-15 19:34 ` st3r4g
2020-04-16 12:22 ` travankor
2020-04-16 12:41 ` xtraeme
2020-04-16 13:17 ` travankor
2020-04-16 13:41 ` Duncaen
2020-04-16 13:41 ` st3r4g
2020-04-18  6:47 ` ericonr
2020-04-18  7:49 ` travankor
2020-04-18  7:50 ` travankor
2020-04-18  7:55 ` travankor
2020-04-18 16:20 ` ericonr
2020-04-21  7:44 ` ericonr
2020-04-22  2:45 ` travankor
2020-04-22 14:57 ` travankor
2020-04-22 17:22 ` ericonr
2020-04-22 17:26 ` ericonr
2020-05-30 11:51 ` travankor
2020-05-30 12:52 ` st3r4g
2020-08-14  2:38 ` travankor
2020-12-03  9:52 ` SevereOverfl0w
2020-12-03 11:51 ` st3r4g
2020-12-03 20:49 ` ericonr
2020-12-19  3:30 ` ericonr
2020-12-19  3:30 ` [ISSUE] [CLOSED] " ericonr
2020-12-19  3:31 ` ericonr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-20930@inbox.vuxu.org \
    --to=ericonr@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).