Github messages for voidlinux
 help / color / mirror / Atom feed
From: sgn <sgn@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [WIP] wlroots: update to 0.12.0
Date: Wed, 11 Nov 2020 01:34:47 +0100	[thread overview]
Message-ID: <20201111003447.FF6iInvdl7oNy9vhWUlnma1E62sjK8limaskcbVhzSE@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-26224@inbox.vuxu.org>

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

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/26224#issuecomment-725041788

Comment:
> I know I suggested renaming the `elogind` build option to `setuid` to achieve the default behavior, but looking at this propagating everywhere, I really think this is an inappropriate abuse of a build option.

`xorg-server` also has `elogind` build option, with that option on, `setsuid` is dropped, too. So, I think *the* convention is use `elogind`.

p/s: I have no opinion, whatsoever, just want to point out current practice. I still live in xorg land.

> 
> After package installation, XBPS does not track file permissions, so the user can always set or clear the setuid bit depending on desired behavior. This gets a little annoying if updates toggle the bit, but is it any more annoying than having to rebuild the package after every update with some build option just to toggle the bit for you? I submit that it is _less_ annoying, and users can always hold the package to avoid being surprised if they really want.
> 
> Either the binaries should default to setuid root or they should not; this is a question for regular Wayland users (one of which I am not) to hash out. But I strongly suggest the build option be dropped.



  parent reply	other threads:[~2020-11-11  0:34 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08 15:36 [PR PATCH] " ofiala-a51
2020-11-08 15:46 ` ericonr
2020-11-08 17:04 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-08 17:16 ` ofiala-a51
2020-11-08 17:46 ` [WIP] " ericonr
2020-11-08 17:53 ` ofiala-a51
2020-11-08 18:14 ` ofiala-a51
2020-11-08 18:21 ` jbeich
2020-11-08 18:22 ` jbeich
2020-11-08 18:28 ` ofiala-a51
2020-11-08 18:48 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-08 19:05 ` ofiala-a51
2020-11-08 19:43 ` ofiala-a51
2020-11-10 15:23 ` ifreund
2020-11-10 16:45 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-10 16:48 ` ofiala-a51
2020-11-10 16:53 ` ofiala-a51
2020-11-10 16:54 ` ofiala-a51
2020-11-10 18:21 ` [PR REVIEW] " ericonr
2020-11-10 18:29 ` ericonr
2020-11-10 18:30 ` [PR REVIEW] " ahesford
2020-11-10 18:34 ` ericonr
2020-11-10 19:53 ` st3r4g
2020-11-10 19:53 ` st3r4g
2020-11-10 19:54 ` st3r4g
2020-11-10 20:02 ` st3r4g
2020-11-10 20:04 ` st3r4g
2020-11-10 20:12 ` st3r4g
2020-11-10 20:38 ` st3r4g
2020-11-10 20:39 ` st3r4g
2020-11-10 20:55 ` st3r4g
2020-11-10 21:08 ` ifreund
2020-11-10 21:25 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-10 21:28 ` [PR REVIEW] " ofiala-a51
2020-11-10 21:28 ` ofiala-a51
2020-11-10 22:04 ` [PR REVIEW] " ifreund
2020-11-10 22:04 ` ifreund
2020-11-10 22:39 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-10 22:40 ` [PR REVIEW] " ofiala-a51
2020-11-10 22:40 ` ofiala-a51
2020-11-10 23:22 ` ahesford
2020-11-10 23:23 ` st3r4g
2020-11-10 23:23 ` st3r4g
2020-11-10 23:25 ` st3r4g
2020-11-10 23:38 ` [PR REVIEW] " st3r4g
2020-11-10 23:40 ` ofiala-a51
2020-11-10 23:52 ` ifreund
2020-11-10 23:54 ` ifreund
2020-11-10 23:57 ` [PR REVIEW] " ofiala-a51
2020-11-11  0:02 ` ifreund
2020-11-11  0:03 ` sgn
2020-11-11  0:08 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-11  0:08 ` [PR REVIEW] " ofiala-a51
2020-11-11  0:34 ` sgn [this message]
2020-11-11  0:55 ` travankor
2020-11-11  1:13 ` ericonr
2020-11-11  1:24 ` [PR REVIEW] " ofiala-a51
2020-11-11  1:44 ` travankor
2020-11-11 14:03 ` ofiala-a51
2020-11-11 14:14 ` ahesford
2020-11-11 14:52 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-11 15:43 ` ofiala-a51
2020-11-12 22:28 ` ericonr
2020-11-13 10:19 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-13 10:20 ` ofiala-a51
2020-11-17  3:14 ` ericonr
2020-11-17  3:14 ` ericonr
2020-11-17  3:39 ` ericonr
2020-11-17  3:56 ` ericonr
2020-11-17 13:10 ` ericonr
2020-11-17 13:11 ` ericonr
2020-11-17 13:17 ` ericonr
2020-11-17 14:11 ` ericonr
2020-11-17 15:06 ` ericonr
2020-11-17 15:13 ` ericonr
2020-11-17 15:36 ` ericonr
2020-11-17 18:28 ` ericonr
2020-11-18 14:49 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-18 14:51 ` ofiala-a51
2020-11-18 15:02 ` ofiala-a51
2020-11-18 15:04 ` ofiala-a51
2020-11-19 13:12 ` ericonr
2020-11-19 17:00 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-20 21:50 ` [PR PATCH] [Merged]: " 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=20201111003447.FF6iInvdl7oNy9vhWUlnma1E62sjK8limaskcbVhzSE@z \
    --to=sgn@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).