On 05/01/2015 10:09, Daniel Micay wrote:
> On 04/01/15 04:05 PM, Christian Hesse wrote:
> I would create a wiki page with the list and then see if you can find a
> developer interested in mass-adding the missing signatures. I'd be
> interested in helping with it for [community], but you'll likely b
I'm not going to remove any groups, but I want to make sure I'm not
configuring mdev to set ownership to a group that may not exist in the
future. I will probably create a new group called "hardware" that will
allow users to access audio, video, serial, and USB storage devices, and
use Posix ACLs t
On Mon, Jan 05, 2015 at 09:59:51PM +, Neale Pickett wrote:
> This is very helpful. Thank you!
If you go with your own group list, check configs of your daemons to see which
groups they expect. Some (e.g. dnsmasq) will call useradd and groupadd in their
.install files. But syslog-ng, for exampl
This is very helpful. Thank you!
On Mon Jan 05 2015 at 2:06:50 PM Leonid Isaev wrote:
> On Mon, Jan 05, 2015 at 07:12:41PM +, Neale Pickett wrote:
> > I run mdev instead of systemd-udev and was just alerted to the
> deprecation
> > of all the groups I'd been using. Looking at the filesystem
On Mon, Jan 05, 2015 at 07:12:41PM +, Neale Pickett wrote:
> I run mdev instead of systemd-udev and was just alerted to the deprecation
> of all the groups I'd been using. Looking at the filesystem package, it
> seems that most of them are still present, but I presume they'll go away
> eventual
All right.
Can someone then comment on which groups are actually deprecated, and which
are not? I would like to not leave users with a broken system when the
filesystem package is updated.
On Mon Jan 05 2015 at 12:36:08 PM Daniel Micay
wrote:
> On 05/01/15 02:30 PM, Neale Pickett wrote:
> > htt
On 05/01/15 02:30 PM, Neale Pickett wrote:
> https://wiki.archlinux.org/index.php/users_and_groups#Deprecated_or_unused_groups
The groups have been replaced / deprecated as a way of giving hardware
access to users with local sessions. That doesn't mean that they're
deprecated as a whole or that th
This is related to / mirroring the functionality of the -r switch of
useradd, which populates (at least as configured in the shadow package
provided by Arch) from 999 downward.
On Fri, Jan 02, 2015 at 01:17:25PM -0600, Troy Engel wrote:
> On Fri, Jan 2, 2015 at 12:49 PM, Oliver Temlin wrote:
> >
https://wiki.archlinux.org/index.php/users_and_groups#Deprecated_or_unused_groups
On Mon Jan 05 2015 at 12:29:39 PM Daniel Micay
wrote:
> On 05/01/15 02:24 PM, Neale Pickett wrote:
> > I apologize for mentioning systemd.
> >
> > What non-deprecated group would be best for a "hardware user"?
>
>
On 05/01/15 02:24 PM, Neale Pickett wrote:
> I apologize for mentioning systemd.
>
> What non-deprecated group would be best for a "hardware user"?
Who is telling you that the groups in base are deprecated?
signature.asc
Description: OpenPGP digital signature
I apologize for mentioning systemd.
What non-deprecated group would be best for a "hardware user"?
On Mon Jan 05 2015 at 12:23:22 PM Daniel Micay
wrote:
> On 05/01/15 02:12 PM, Neale Pickett wrote:
> > I feel like this notion ought to be part of the base
> > install, even though systemd appears
On 05/01/15 02:12 PM, Neale Pickett wrote:
> I feel like this notion ought to be part of the base
> install, even though systemd appears to have reworked how Unix device
> access is controlled.
It didn't change this. ConsoleKit used a similar model for sessions and
also set ACLs on devices for the
I run mdev instead of systemd-udev and was just alerted to the deprecation
of all the groups I'd been using. Looking at the filesystem package, it
seems that most of them are still present, but I presume they'll go away
eventually.
What, then, would be the best group for me to use for "a user who
On Mon, Jan 05, 2015 at 04:09:50AM -0500, Daniel Micay wrote:
> On 04/01/15 04:05 PM, Christian Hesse wrote:
> > Hello everybody,
> >
> > pacman 4.2.0 gained support for verifying source tarballs with kernel.org
> > style signature. Some (even essential) packages could benefit from that,
> > linux
On 05/01/15 12:28 PM, Leonid Isaev wrote:
> On Mon, Jan 05, 2015 at 10:16:10AM +0100, Christian Hesse wrote:
>> I do not think we need HTTPS, though it does not hurt. If anybody tries to
>> fool us with man-in-the-middle via HTTP we should detect that just fine with
>> broken signatures (given sign
On Mon, Jan 05, 2015 at 10:16:10AM +0100, Christian Hesse wrote:
> I do not think we need HTTPS, though it does not hurt. If anybody tries to
> fool us with man-in-the-middle via HTTP we should detect that just fine with
> broken signatures (given signatures are provided...).
>
> Appending .sign m
> I do not think we need HTTPS, though it does not hurt. If anybody tries to
> fool us with man-in-the-middle via HTTP we should detect that just fine with
> broken signatures (given signatures are provided...).
Well, I mean when no signatures are available. It's not really that
common for upstrea
Daniel Micay on Mon, 2015/01/05 04:01:
> On 04/01/15 05:03 PM, Doug Newgard wrote:
> > On Sun, 4 Jan 2015 22:05:21 +0100
> > Christian Hesse wrote:
> >
> >> Hello everybody,
> >>
> >> pacman 4.2.0 gained support for verifying source tarballs with
> >> kernel.org style signature. Some (even essen
On 04/01/15 04:05 PM, Christian Hesse wrote:
> Hello everybody,
>
> pacman 4.2.0 gained support for verifying source tarballs with kernel.org
> style signature. Some (even essential) packages could benefit from that,
> linux and git come to mind.
>
> How to handle this? Report a bug for every pac
On 04/01/15 05:03 PM, Doug Newgard wrote:
> On Sun, 4 Jan 2015 22:05:21 +0100
> Christian Hesse wrote:
>
>> Hello everybody,
>>
>> pacman 4.2.0 gained support for verifying source tarballs with
>> kernel.org style signature. Some (even essential) packages could
>> benefit from that, linux and git
20 matches
Mail list logo
