On 17 Dec 2015 11:57, Ulrich Mueller wrote:
> > On Tue, 15 Dec 2015, Mike Frysinger wrote:
> > On 15 Dec 2015 20:23, Anthony G. Basile wrote:
> >> > short/mid term, i was thinking of writing a new package that
> >> > holds the db and tools to query/manage it. user.eclass would
> >> > DEPEND on
> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> On 15 Dec 2015 20:23, Anthony G. Basile wrote:
>> > short/mid term, i was thinking of writing a new package that
>> > holds the db and tools to query/manage it. user.eclass would
>> > DEPEND on it and ask it for details, perhaps even doing the
>>
On 15 Dec 2015 20:23, Anthony G. Basile wrote:
> On 12/15/15 4:55 PM, Mike Frysinger wrote:
> > On 15 Dec 2015 22:35, Ulrich Mueller wrote:
> >> Whatever the format will be, the more important question is where this
> >> would be implemented:
> >>
> >> - In the package manager, with user and group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/15/15 4:55 PM, Mike Frysinger wrote:
> On 15 Dec 2015 22:35, Ulrich Mueller wrote:
>> Whatever the format will be, the more important question is where this
>> would be implemented:
>>
>> - In the package manager, with user and group definition
On 15 Dec 2015 22:35, Ulrich Mueller wrote:
> Whatever the format will be, the more important question is where this
> would be implemented:
>
> - In the package manager, with user and group definition in profiles.
> This seems to be what GLEP 27 suggests, and as far as I can see, it
> would r
> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> On 15 Dec 2015 15:56, Ulrich Mueller wrote:
>> ESR's case study about the password file format seems to disagree:
>> http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332
> because you cited it, i read it anyways. that document is a
On 15 Dec 2015 15:56, Ulrich Mueller wrote:
> > On Tue, 15 Dec 2015, Mike Frysinger wrote:
>
> > a flat text file akin to /etc/passwd is not readable. xml is readable.
>
> ESR's case study about the password file format seems to disagree:
> http://www.catb.org/esr/writings/taoup/html/ch05s01
On 15 Dec 2015 10:35, Alec Warner wrote:
> On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger wrote:
> > a flat text file akin to /etc/passwd is not readable. xml is readable.
>
> u trollin' bro?
in this domain, it's harder to screw up xml and not notice (either human or
machine) whereas it's prett
On 15 Dec 2015 10:24, Anthony G. Basile wrote:
> i looked through portage code and we do have xml parsing sprinkled
> throughout, mostly in repoman for obvious reasons. why are we trying to
> avoid xml? to be honest i don't have strong feelings about either the
> flat file (a la /etc/passwd) or x
On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger wrote:
> On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> > > On Tue, 15 Dec 2015, Mike Frysinger wrote:
> >
> > > On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> > >> The spec seems incomplete. I cannot find a description of the user and
> > >> grou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/15/15 10:08 AM, Mike Frysinger wrote:
> On 15 Dec 2015 15:33, Michał Górny wrote:
>> On Tue, 15 Dec 2015 09:19:36 -0500 Mike Frysinger wrote:
>>> On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> On Tue, 15 Dec 2015, Mike Frysinger wrote:
>
On 15 Dec 2015 15:56, Ulrich Mueller wrote:
> > On Tue, 15 Dec 2015, Mike Frysinger wrote:
>
> > a flat text file akin to /etc/passwd is not readable. xml is readable.
>
> ESR's case study about the password file format seems to disagree:
> http://www.catb.org/esr/writings/taoup/html/ch05s01
On 15 Dec 2015 15:33, Michał Górny wrote:
> On Tue, 15 Dec 2015 09:19:36 -0500 Mike Frysinger wrote:
> > On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> > > > On Tue, 15 Dec 2015, Mike Frysinger wrote:
> > >
> > > > On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> > > >> The spec seems incomp
On 15 Dec 2015 16:00, Michał Górny wrote:
> On Tue, 15 Dec 2015 15:56:34 +0100 Ulrich Mueller wrote:
> > > On Tue, 15 Dec 2015, Mike Frysinger wrote:
> >
> > > a flat text file akin to /etc/passwd is not readable. xml is readable.
> >
> > ESR's case study about the password file format s
On Tue, 15 Dec 2015 15:56:34 +0100
Ulrich Mueller wrote:
> > On Tue, 15 Dec 2015, Mike Frysinger wrote:
>
> > a flat text file akin to /etc/passwd is not readable. xml is readable.
>
> ESR's case study about the password file format seems to disagree:
> http://www.catb.org/esr/writings
> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> a flat text file akin to /etc/passwd is not readable. xml is readable.
ESR's case study about the password file format seems to disagree:
http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332
I think the name:password:uid:gid:gecos
On Tue, 15 Dec 2015 09:19:36 -0500
Mike Frysinger wrote:
> On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> > > On Tue, 15 Dec 2015, Mike Frysinger wrote:
> >
> > > On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> > >> The spec seems incomplete. I cannot find a description of the user and
>
On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> > On Tue, 15 Dec 2015, Mike Frysinger wrote:
>
> > On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> >> The spec seems incomplete. I cannot find a description of the user and
> >> group files' format. (But in fact, there is a standard format which
> >>
> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> On 14 Dec 2015 21:22, Ulrich Mueller wrote:
>> The spec seems incomplete. I cannot find a description of the user and
>> group files' format. (But in fact, there is a standard format which
>> suggests itself, namely that of the passwd(5) and group
On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> The spec seems incomplete. I cannot find a description of the user and
> group files' format. (But in fact, there is a standard format which
> suggests itself, namely that of the passwd(5) and group(5) files.)
i recall going with xml at the time, but i
Ulrich Mueller wrote:
> (If directories are really needed, we could use the scheme foreseen
> in [1] for package.* and use.* files.)
So package.{users,group} ?
> Also a mechanism how a subprofile could undefine a user or group
> defined in its parent seems to be missing.
Maybe set the id to -1
> On Mon, 14 Dec 2015, Michał Górny wrote:
> As far as I can see, this GLEP predates EAPI and does not meet
> modern standards. It needs to be updated or killed with fire.
> For a start, relation to EAPI needs to be defined. This will likely
> require both profiles and ebuilds to use the new
On 12/14/15 3:22 AM, Michał Górny wrote:
>
>
> Dnia 13 grudnia 2015 21:41:02 CET, "Robin H. Johnson"
> napisał(a):
>>On Sun, Dec 13, 2015 at 09:03:51PM +0300, Alexey Shvetsov wrote:
>>> Hi all!
>>>
>>> We trying to use ldap for users @work, many of our workstations
>>running
>>> binary gentoo ba
On 12/14/15 12:06 AM, Robin H. Johnson wrote:
> On Mon, Dec 14, 2015 at 07:49:42AM +0300, Alexey Shvetsov wrote:
>> Hi!
>>
>> Ok. Since there is GLEP27 we should make it reality. To do so i think we
>> should
>> 1. Have some list of system uid/gid (on wiki for example). Also we need
>> to agree o
Dnia 13 grudnia 2015 21:41:02 CET, "Robin H. Johnson"
napisał(a):
>On Sun, Dec 13, 2015 at 09:03:51PM +0300, Alexey Shvetsov wrote:
>> Hi all!
>>
>> We trying to use ldap for users @work, many of our workstations
>running
>> binary gentoo based distro called Calculate linux. However if we
>wa
On Mon, Dec 14, 2015 at 07:49:42AM +0300, Alexey Shvetsov wrote:
> Hi!
>
> Ok. Since there is GLEP27 we should make it reality. To do so i think we
> should
> 1. Have some list of system uid/gid (on wiki for example). Also we need
> to agree on uid/gid numbers for services
This database was alre
Hi!
Ok. Since there is GLEP27 we should make it reality. To do so i think we
should
1. Have some list of system uid/gid (on wiki for example). Also we need
to agree on uid/gid numbers for services
2. Add uid/gid from list to existing ebuilds
3. Make a repoman (or may be eclass) check, that wil
On Sun, Dec 13, 2015 at 09:03:51PM +0300, Alexey Shvetsov wrote:
> Hi all!
>
> We trying to use ldap for users @work, many of our workstations running
> binary gentoo based distro called Calculate linux. However if we wanna
> have wide use of ldap there is a need for determenistic system group
28 matches
Mail list logo
