On Fri, 27 Jan 2017 23:42:04 +
"Robin H. Johnson" wrote:
> On Thu, Jan 19, 2017 at 06:08:26PM +0100, Michał Górny wrote:
> > default/linux/amd64/dev/32bit-userland
> Is this still supported? I've mulled over making a hardened version,
> specifically to support woodpecker.gentoo.org, as it's
Matt Turner posted on Fri, 27 Jan 2017 10:40:16 -0800 as excerpted:
> On Fri, Jan 27, 2017 at 8:22 AM, Mike Gilbert
> wrote:
>> On Fri, Jan 27, 2017 at 2:54 AM, Mart Raudsepp wrote:
>>> Then there is no need to think about what is enabled globally or not.
>>> Point being, use REQUIRED_USE sparin
On Fri, Jan 27, 2017 at 7:36 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Matt Turner posted on Thu, 26 Jan 2017 18:16:12 -0800 as excerpted:
>
>> # Matt Turner (26 Jan 2017)
>> # Dead and replaced by media-libs/mesa[video_cards_radeonsi]
>> # (or the proprietary amdgpu-pro, which is not in tree).
>
On Fri, Jan 27, 2017 at 9:37 PM, Patrick McLean wrote:
>
> I don't think we need to have stable UIDs/GIDs in the "normal" case of
> standalone users with a single Gentoo system at home.
Of course, but as you point out the enterprise case has more
sophisticated solutions. I think the case of some
Matt Turner posted on Thu, 26 Jan 2017 18:16:12 -0800 as excerpted:
> # Matt Turner (26 Jan 2017)
> # Dead and replaced by media-libs/mesa[video_cards_radeonsi]
> # (or the proprietary amdgpu-pro, which is not in tree).
> # Masked for removal in 30 days.
> # Bug #582406
> x11-drivers/ati-drivers
On 01/27/2017 09:37 PM, Patrick McLean wrote:
>
> To make something to solve our problem (and I suspect everyone
> else who cares about this), it would be sufficient to have a mechanism
> to override the default random assignment with a fixed UID/GID.
What I had in mind for this is that a "normal
Rich Freeman posted on Fri, 27 Jan 2017 16:23:02 -0500 as excerpted:
> On Fri, Jan 27, 2017 at 3:09 PM, Michael Orlitzky
> wrote:
>> My first impression is that any package that doesn't care about its UID
>> should default to "first available", but if that causes problems, then
>> that's exactly
On Fri, 27 Jan 2017 14:53:18 -0500
Rich Freeman wrote:
> On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky
> wrote:
> > On 01/27/2017 01:52 PM, Rich Freeman wrote:
> >>
> >> This doesn't really seem like a problem though. Just have a table
> >> somewhere (wiki?) to track who is using what UID
On 01/27/2017 04:15 PM, Michał Górny wrote:
>
>> * users-update: cleanup can be done with --depclean now.
>
> Err, cleanup is never easy. You shouldn't really remove a user if it
> owns any files. I guess you could abuse pkg_prerm() for that but
> depclean will be terribly slow then.
>
What ar
On Thu, Jan 19, 2017 at 06:08:26PM +0100, Michał Górny wrote:
> default/linux/amd64/dev/32bit-userland
Is this still supported? I've mulled over making a hardened version,
specifically to support woodpecker.gentoo.org, as it's 64-bit hardware
now, but the userspace is much older, and dates from whe
måndag 23 januari 2017 kl. 13:56:02 CET skrev Rich Freeman:
> On Mon, Jan 23, 2017 at 4:23 AM, Michał Górny wrote:
> > I've written a short proposal that aims to provide basic infrastructure
> > for defining mix-in profiles in Gentoo. I've tried to keep it simple,
> > and backwards compatible. Th
On Fri, Jan 27, 2017 at 3:09 PM, Michael Orlitzky wrote:
> My first impression is that any package that doesn't care
> about its UID should default to "first available", but if that causes
> problems, then that's exactly the sort of use case I'm looking for.
>
The ones I listed before were filesy
On Fri, 27 Jan 2017 12:54:07 -0500
Michael Orlitzky wrote:
> We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but
> never implemented it. I'm wondering what are the explicit requirements
> that we have for user and group management?
I don't think GLEP 27 could be really conside
On 01/27/2017 12:25 PM, Michael Orlitzky wrote:
> Forked from the gdbm/berkdb thread, wall of text ensues...
>
>
> On 01/27/2017 03:32 AM, Fabian Groffen wrote:
>>
>> You mention REQUIRED_USE should be used sparingly, I think I see your
>> reasoning, but if so, then why did we add it in the first
On 01/27/2017 02:53 PM, Rich Freeman wrote:
>
> I'm not saying we can't have random assignment for things where it
> doesn't matter, or fall back to random assignment, but it seems rather
> silly to go to all the trouble to have blockers when it would be just
> as easy to not have a conflict in th
On 01/27/2017 12:25 PM, Michael Orlitzky wrote:
Forked from the gdbm/berkdb thread, wall of text ensues...
On 01/27/2017 03:32 AM, Fabian Groffen wrote:
You mention REQUIRED_USE should be used sparingly, I think I see your
reasoning, but if so, then why did we add it in the first place?
The
On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky wrote:
> On 01/27/2017 01:52 PM, Rich Freeman wrote:
>>
>> This doesn't really seem like a problem though. Just have a table
>> somewhere (wiki?) to track who is using what UID/GID and encode those
>> defaults into the ebuild that creates those us
On Fri, Jan 27, 2017 at 1:52 PM, Rich Freeman wrote:
> On Fri, Jan 27, 2017 at 12:54 PM, Michael Orlitzky wrote:
> >
> > You don't really have to care what UID/GID is assigned, because each
> > user/group will only be created once and referenced by name (as $PN). By
> > default, we could pick th
On 01/27/2017 01:52 PM, Rich Freeman wrote:
>
> This doesn't really seem like a problem though. Just have a table
> somewhere (wiki?) to track who is using what UID/GID and encode those
> defaults into the ebuild that creates those users.
>
It should be possible to have two different users with
On Fri, Jan 27, 2017 at 12:54 PM, Michael Orlitzky wrote:
>
> You don't really have to care what UID/GID is assigned, because each
> user/group will only be created once and referenced by name (as $PN). By
> default, we could pick the first available UID in most packages.
I might be not following
On Fri, Jan 27, 2017 at 8:22 AM, Mike Gilbert wrote:
> On Fri, Jan 27, 2017 at 2:54 AM, Mart Raudsepp wrote:
>> Then there is no need to think about what is enabled globally or not.
>> Point being, use REQUIRED_USE sparingly, and rarely a good idea to
>> block things with common global USE flags,
On Fri, 27 Jan 2017 12:54:07 -0500
Michael Orlitzky wrote:
> That satisfies most of the requirements that *I* have for user and
> group management on the system. Compared to the GLEP:
>
> * EUSERS + EGROUPS: replaced by (R)DEPEND.
> * Defining Accounts: anyone can add a new package already.
We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but
never implemented it. I'm wondering what are the explicit requirements
that we have for user and group management?
What I'm really wondering is, instead of the proposal in GLEP27, if we
couldn't simply handle users like any oth
Forked from the gdbm/berkdb thread, wall of text ensues...
On 01/27/2017 03:32 AM, Fabian Groffen wrote:
>
> You mention REQUIRED_USE should be used sparingly, I think I see your
> reasoning, but if so, then why did we add it in the first place?
There are a few conflicting interests at play. Bef
On 01/27/2017 07:41 AM, Rich Freeman wrote:
On Fri, Jan 27, 2017 at 7:06 AM, Dirkjan Ochtman wrote:
On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny wrote:
I should point out that:
1) CI is detecting this kind of issues much faster than you are,
and reporting them both to the committer and to
Ühel kenal päeval, R, 27.01.2017 kell 11:22, kirjutas Mike Gilbert:
> On Fri, Jan 27, 2017 at 2:54 AM, Mart Raudsepp
> wrote:
> > Then there is no need to think about what is enabled globally or
> > not.
> > Point being, use REQUIRED_USE sparingly, and rarely a good idea to
> > block things with c
On 01/26/2017 10:33 PM, Mike Gilbert wrote:
>
> Is there any reason to have these USE flags enabled globally?
They are quite uncritical.
> These USE seem pretty package-specific in scope. On my system, they
> are used by around a dozen of 1000+ installed packages. I think it
> might make sense
On 01/27/2017 05:46 PM, William Hubbs wrote:
>> It breaks the highly sought after "Gentoo is about choice" mantra.
>> In this case, choice to not care and have the best chosen for me.
> Actually it doesn't. In this case the user should make a choice rather
> than the maintainer silently making a ch
On Fri, Jan 27, 2017 at 06:27:09PM +0200, Mart Raudsepp wrote:
> Ühel kenal päeval, R, 27.01.2017 kell 13:08, kirjutas Kristian
> Fiskerstrand:
> > On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote:
> > > On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp
> > > wrote:
> > > > Ühel kenal päeval, N, 26.01.2
Ühel kenal päeval, R, 27.01.2017 kell 13:08, kirjutas Kristian
Fiskerstrand:
> On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote:
> > On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp
> > wrote:
> > > Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike
> > > Gilbert:
> > > > I recently ran into a
On Fri, Jan 27, 2017 at 2:54 AM, Mart Raudsepp wrote:
> Then there is no need to think about what is enabled globally or not.
> Point being, use REQUIRED_USE sparingly, and rarely a good idea to
> block things with common global USE flags, or demand a local USE flag
> based on a default enabled gl
On 27/01/17 12:41, Rich Freeman wrote:
>
> I'm a little concerned that stuff like this starts to end up working
> like collective punishment. Fred over here broke the tree, so nobody
> gets to have desert or recess today; you all know what to do with Fred
> when he's looking to sit next to somebo
On 27-01-2017 13:08:41 +0100, Kristian Fiskerstrand wrote:
> > On Fri, Jan 27, 2017 at 9:32 AM, Fabian Groffen wrote:
> >> Replying here because I think said email client is the one I recently
> >> added REQUIRED_USE constraints for.
> >>
> >> Reason I added it is because it greatly simplified the
On Fri, Jan 27, 2017 at 7:06 AM, Dirkjan Ochtman wrote:
>
> On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny wrote:
>> I should point out that:
>>
>> 1) CI is detecting this kind of issues much faster than you are,
>> and reporting them both to the committer and to a *dedicated* mailing
>> list, so
On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote:
> On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp wrote:
>> Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert:
>>> I recently ran into a REQUIRED_USE constraint that required I select
>>> between berkdb and gdbm for an email client.
>>
Wow, Michał, this email comes off as pretty harsh to me... Is that
really necessary?
On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny wrote:
> I should point out that:
>
> 1) CI is detecting this kind of issues much faster than you are,
> and reporting them both to the committer and to a *dedicated*
On Fri, Jan 27, 2017 at 4:33 AM, Mike Gilbert wrote:
> Looking through our profiles, I see we have both berkdb and gdbm
> enabled "globally".
>
> default/linux/make.defaults:USE="berkdb crypt ipv6 ncurses nls pam
> readline ssl tcpd zlib"
> releases/make.defaults:USE="acl gdbm nptl unicode"
>
> Is
Ühel kenal päeval, R, 27.01.2017 kell 13:16, kirjutas Mart Raudsepp:
> If anything, I think this is a suggestion that *maybe* we should a
> > way to
> > specify a mechanism for allowing a default to be chosen from a
> > mutually
> > exclusive set, and then:
>
> Sure, I have some thoughts for this
Ühel kenal päeval, R, 27.01.2017 kell 23:58, kirjutas Kent Fredric:
> On Fri, 27 Jan 2017 09:32:23 +0100
> Fabian Groffen wrote:
>
> > I'm interested to hear how other people feel about this.
>
> Yeah. Pretty much my reaction to
>
> Mart Raudsepp wrote:
>
> > The maintainer should be giving
On Fri, 27 Jan 2017 09:32:23 +0100
Fabian Groffen wrote:
> I'm interested to hear how other people feel about this.
Yeah. Pretty much my reaction to
Mart Raudsepp wrote:
> The maintainer should be giving the choice of both,
> but if only one can be chosen, the maintainer should make the choi
Replying here because I think said email client is the one I recently
added REQUIRED_USE constraints for.
Reason I added it is because it greatly simplified the ebuild: it's not
just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result
a lot of if-else-casing which implemented the im
41 matches
Mail list logo
