f54855d
app-crypt/dirmngr20170123-18:17 alonbl 0615cd9
app-emulation/genymotion-bin 20170123-17:03 mudler 56ca523
app-misc/todo20170129-21:32 monsieurpc24a30d
app-text/mandoc 20170128-06:49 vapier d4a7512
dev-java/gradle-bin
On 01/29/2017 06:34 PM, Ulrich Mueller wrote:
>
> Our syntax for package names is more restrictive than what POSIX
> allows for a portable user name. Therefore, there could be user names
> that are not representable. Have you checked if all user and group
> names currently in use (at least in the
> On Sun, 29 Jan 2017, Michael Orlitzky wrote:
> I put together a draft of the "fixed UIDs with random fallback" model:
> https://wiki.gentoo.org/wiki/User:Mjo/GLEP:User_packages
> If we decide to fix UID/GID management, I think it would be a lot
> easier to implement that draft than GLEP:
On 01/29/2017 05:30 PM, Alan McKinnon wrote:
>
> Good catch with symlinks.
> I don't see the point about hardlinks, they are just files with 2
> dentries. When find gets to the second one it's already changed, so no
> problem.
>
Any user can create a hard link in its home directory to /etc/shado
On 30/01/2017 00:20, Michael Orlitzky wrote:
> On 01/29/2017 05:07 PM, Alan McKinnon wrote:
>>
>> Sure it can be done, just don't chown -R ~user. DO it the VERY
>> long way round, file by file. Say you changed user "awesome" uid 300 to 400:
>>
>> find / -uid 300 -exec chown awesome {} \+
>>
>
> T
On 01/29/2017 05:07 PM, Alan McKinnon wrote:
>
> Sure it can be done, just don't chown -R ~user. DO it the VERY
> long way round, file by file. Say you changed user "awesome" uid 300 to 400:
>
> find / -uid 300 -exec chown awesome {} \+
>
That will find symlinks created by UID 300, and chown w
On 01/27/2017 12:54 PM, 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?
>
> What I'm really wondering is, instead of the proposal
On 29/01/2017 19:05, Michael Orlitzky wrote:
> On 01/29/2017 03:26 AM, Alan McKinnon wrote:
>>>
>>> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I
>>> may have convinced myself that fixed UIDs are better.
>>
>> The general process I would recommend is that if the ebuild fin
> > Proposal No 2:
> > * Leave profiles.desc unmodified
> > * Introduce a new file arch.desc, which contains the "stability
> > status" of an
> > arch;
> >
> > Syntax: 2 columns,
> > # arch status
> > amd64 stable
> > mipstesting
> > sh unstable
> >
> > The meaning of the
Am Montag, 30. Januar 2017, 09:29:06 CET schrieb Kent Fredric:
> ---
>amd64 keywords=strict checkdeps=stable enforcedeps=stable
>mips keywords=mixed checkdeps=stable enforcedeps=dev
>m68k keywords=mixed checkdeps=expenforcedeps=exp
> ---
The problem with this is that (already
On Sun, 29 Jan 2017 14:08:05 -0500
james wrote:
> I do
> not have access to Kent's posting so perhaps a reference to Kent's ideas?
Happened on IRC, not on any ML ( though I copied a basic copy of it in another
thread )
But I'm not going to reiterate it here due to its chances of introducing
Bug: https://bugs.gentoo.org/416069
---
eclass/xorg-2.eclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index b7c7ba2..fabad09 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -468,8 +468,14 @@ xorg-2_src_configure() {
On Sun, Jan 29, 2017 at 12:00 PM, Sergei Trofimovich wrote:
> On Sun, 29 Jan 2017 11:42:16 -0800
> Matt Turner wrote:
>
>> Bug: https://bugs.gentoo.org/416069
>> ---
>> eclass/xorg-2.eclass | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.ecla
On Sun, 29 Jan 2017 11:42:16 -0800
Matt Turner wrote:
> Bug: https://bugs.gentoo.org/416069
> ---
> eclass/xorg-2.eclass | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
> index b7c7ba2..7d681f2 100644
> --- a/eclass/xorg-2.eclass
> +++ b
---
eclass/llvm.eclass | 98 ++
1 file changed, 98 insertions(+)
create mode 100644 eclass/llvm.eclass
diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
new file mode 100644
index ..a0ce616d5b92
--- /dev/null
+++ b/eclass/llvm.ec
Bug: https://bugs.gentoo.org/416069
---
eclass/xorg-2.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index b7c7ba2..7d681f2 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -468,6 +468,11 @@ xorg-2_src_configure() {
On 01/29/2017 12:22 PM, A. Wilcox wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/01/17 11:05, Michael Orlitzky wrote:
On 01/29/2017 03:26 AM, Alan McKinnon wrote:
Can anyone think of an upgrade path for fixed UIDs? That issue
aside, I may have convinced myself that fixed UIDs ar
On 01/29/2017 10:06 AM, Andreas K. Huettel wrote:
So I've been talking to kent\n and the conclusion is that our ideas basically
do and achieve the same, with a slightly different approach. (I still like
mine better though. :)
However one valid point that came up in discussions is - whether an ar
On Sun, 29 Jan 2017 18:20:34 +0200
Mart Raudsepp wrote:
> Might want a "broken" (with maybe a better name) for some of these. I
> bet the ~arch of some of these is broken too, and no-one to respond to
> keyword requests, just happens when it happens.
> arm64 and mips are in that state too until w
On Sun, 29 Jan 2017 11:16:50 -0600
"A. Wilcox" wrote:
> On 28/01/17 13:32, James Le Cuirot wrote:
> > On Sat, 28 Jan 2017 12:13:53 -0600 "A. Wilcox"
> > wrote:
> >
> >> Having a file that user.eclass would use to map new users/groups
> >> to IDs would be extremely beneficial to me. I was thi
On Sun, 29 Jan 2017 18:20:34 +0200
Mart Raudsepp wrote:
> Maybe declare from the start that any extra columns should be silently
> ignored in implementations from start, as to be able to safely add more
> columns in the future without breaking backwards compatibility.
Maybe not silently, maybe j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/01/17 11:05, Michael Orlitzky wrote:
> On 01/29/2017 03:26 AM, Alan McKinnon wrote:
>>>
>>> Can anyone think of an upgrade path for fixed UIDs? That issue
>>> aside, I may have convinced myself that fixed UIDs are better.
>>
>> The general pr
On 01/29/2017 05:03 AM, Ulrich Mueller wrote:
>> On Sat, 28 Jan 2017, Michael Orlitzky wrote:
>
>> [...] sys-user/echo [...]
>
> [Replying to a random message in this thread, as I have some backlog.]
>
> Users and groups aren't packages, so IMHO packages and *DEPEND
> variables shouldn't be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/01/17 13:32, James Le Cuirot wrote:
> On Sat, 28 Jan 2017 12:13:53 -0600 "A. Wilcox"
> wrote:
>
>> Having a file that user.eclass would use to map new users/groups
>> to IDs would be extremely beneficial to me. I was thinking about
>> diving
On 01/29/2017 03:26 AM, Alan McKinnon wrote:
>>
>> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I
>> may have convinced myself that fixed UIDs are better.
>
> The general process I would recommend is that if the ebuild finds the user
> already exists, leave it, it's UID an
Ühel kenal päeval, P, 29.01.2017 kell 16:06, kirjutas Andreas K.
Huettel:
> However one valid point that came up in discussions is - whether an
> arch
> supports stable keywords is a per-arch setting, not a per-profile
> setting. So
> we can actually make things much easier (and the transition sa
So I've been talking to kent\n and the conclusion is that our ideas basically
do and achieve the same, with a slightly different approach. (I still like
mine better though. :)
However one valid point that came up in discussions is - whether an arch
supports stable keywords is a per-arch setting
On Fri, 27 Jan 2017 15:51:27 -0500
NP-Hardass wrote:
> 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
On Sun, 29 Jan 2017 11:03:25 +0100
Ulrich Mueller wrote:
> > On Sat, 28 Jan 2017, Michael Orlitzky wrote:
>
> > [...] sys-user/echo [...]
>
> [Replying to a random message in this thread, as I have some backlog.]
>
> Users and groups aren't packages, so IMHO packages and *DEPEND
> vari
> On Sat, 28 Jan 2017, Michael Orlitzky wrote:
> [...] sys-user/echo [...]
[Replying to a random message in this thread, as I have some backlog.]
Users and groups aren't packages, so IMHO packages and *DEPEND
variables shouldn't be abused for things like that. This has been
discussed in bug
On 29/01/2017 03:56, Michael Orlitzky wrote:
> On 01/27/2017 11:21 PM, Rich Freeman wrote:
>>
>> It isn't like inconsistent UIDs are the end of the world. However,
>> IMO it still makes sense to at least try to standardize such things.
>> Really, if you have a package always installing the same us
31 matches
Mail list logo
