[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-01-29 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2017-01-29 23:59 UTC.

Removals:
app-admin/phpsyslogng20170125-09:43 gokturk  3de8672
app-crypt/dirmngr20170123-17:29 alonbl   530dc0b
dev-perl/IPTables-libiptc20170128-16:31 polynomial-c 6cddb23
net-libs/qtweetlib   20170124-05:58 johu 8ef9246
sys-power/powerman   20170125-18:43 johu da05780
virtual/python-asyncio   20170126-22:18 mgorny   8e07d09

Additions:
app-admin/serf   20170123-04:59 zmedico  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  20170124-11:56 chainsaw f5c210d
dev-libs/concurrencykit  20170126-07:04 gokturk  294cb80
dev-python/aiohttp-cors  20170129-11:06 bman f85cda0
dev-util/idea-community  20170126-09:33 alicef   f597b36
dev-util/kcov20170125-23:57 wizardedit   f1f2283
media-libs/libnspsl  20170124-00:22 xmw  0a3dd0f
net-im/discord-bin   20170129-20:20 johu 6fafe7e
net-im/openmittsu20170129-17:37 ulm  7caf5ff
net-libs/shairplay   20170110-19:31 soap e7b104c
net-libs/zmqpp   20170125-12:54 grozin   5749a9e
net-misc/nicstat 20170127-18:49 zmedico  1af3bab
sec-policy/selinux-syncthing 20170123-16:04 perfinion04e345f
x11-misc/sct 20170128-22:58 monsieurpa44f5f7

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
dev-perl/IPTables-libiptc,removed,polynomial-c,20170128-16:31,6cddb23
virtual/python-asyncio,removed,mgorny,20170126-22:18,8e07d09
sys-power/powerman,removed,johu,20170125-18:43,da05780
app-admin/phpsyslogng,removed,gokturk,20170125-09:43,3de8672
net-libs/qtweetlib,removed,johu,20170124-05:58,8ef9246
app-crypt/dirmngr,removed,alonbl,20170123-17:29,530dc0b
Added Packages:
app-misc/todo,added,monsieurp,20170129-21:32,c24a30d
net-im/discord-bin,added,johu,20170129-20:20,6fafe7e
net-im/openmittsu,added,ulm,20170129-17:37,7caf5ff
dev-python/aiohttp-cors,added,bman,20170129-11:06,f85cda0
dev-libs/concurrencykit,added,gokturk,20170126-07:04,294cb80
x11-misc/sct,added,monsieurp,20170128-22:58,a44f5f7
app-text/mandoc,added,vapier,20170128-06:49,d4a7512
net-misc/nicstat,added,zmedico,20170127-18:49,1af3bab
dev-util/idea-community,added,alicef,20170126-09:33,f597b36
sec-policy/selinux-syncthing,added,perfinion,20170123-16:04,04e345f
dev-util/kcov,added,wizardedit,20170125-23:57,f1f2283
net-libs/zmqpp,added,grozin,20170125-12:54,5749a9e
app-emulation/genymotion-bin,added,mudler,20170123-17:03,56ca523
dev-java/gradle-bin,added,chainsaw,20170124-11:56,f5c210d
media-libs/libnspsl,added,xmw,20170124-00:22,0a3dd0f
net-libs/shairplay,added,soap,20170110-19:31,e7b104c
app-crypt/dirmngr,added,alonbl,20170123-18:17,0615cd9
app-admin/serf,added,zmedico,20170123-04:59,f54855d

Done.

Re: [gentoo-dev] Requirements for UID/GID management

[Michael Orlitzky]

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 main tree) also follow the
> rules for package names? IIRC, at some point in time we had names
> starting with "_" (which is ugly, but would be allowed as a package
> name) and some "foo-1" type names (which are not allowed).

There's already a variable SYS_USER_NAME=${PN}. If it turns out there
are unrepresentable names, we can change that to a default value and let
people change it in the ebuild. The main benefit of having the username
be the package name is that it prevents duplicates without any
additional code or convention.


> What about duplicates turning up in searches for packages? For example,
> "emerge portage" won't work any more because there would be the ones
> in sys-group and sys-user too.

Isn't that why we have categories in the first place?

Re: [gentoo-dev] Requirements for UID/GID management

[Ulrich Mueller]

> 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:27. I would be interested
> in hearing for which use cases GLEP:27 would be preferable.

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 main tree) also follow the
rules for package names? IIRC, at some point in time we had names
starting with "_" (which is ugly, but would be allowed as a package
name) and some "foo-1" type names (which are not allowed).

What about duplicates turning up in searches for packages? For example,
"emerge portage" won't work any more because there would be the ones
in sys-group and sys-user too.

Ulrich


pgpmi_F9fNiS7.pgp
Description: PGP signature

Re: [gentoo-dev] Requirements for UID/GID management

[Michael Orlitzky]

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/shadow, so
long as (a) they live on the same filesystem, and (b) there are no
special kernel protections in place to prevent it. If you call chown on
that hard link, it will change the ownership of /etc/shadow.

I thought real hard about ways to avoid that and ultimately gave up. The
only safe way to chown is to "chown away"; that is, switch to the guy
who owns the files, and then give them to someone else.

Re: [gentoo-dev] Requirements for UID/GID management

[Alan McKinnon]

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 {} \+
>>
> 
> That will find symlinks created by UID 300, and chown will follow them
> to give "awesome" ownership of the TARGET of the symlink; an easy root
> exploit. If you are about to suggest "find -type f" or the
> "--no-dereference" flag, then beware that chown will also follow
> hardlinks and you're still screwed (albeit limited to one filesystem,
> and on vanilla kernels).
> 
> 


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.

But I'm sure there are plenty edge case scenarios that make this whole
process go awry, all pointing to the same conclusion:

As a dev you shouldn't even try. Let the sysadmin deal with it.
If a system user already has a UID different to the published standard,
leave it alone, it's a human's problem

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-dev] Requirements for UID/GID management

[Michael Orlitzky]

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 will follow them
to give "awesome" ownership of the TARGET of the symlink; an easy root
exploit. If you are about to suggest "find -type f" or the
"--no-dereference" flag, then beware that chown will also follow
hardlinks and you're still screwed (albeit limited to one filesystem,
and on vanilla kernels).

Re: [gentoo-dev] Requirements for UID/GID management

[Michael Orlitzky]

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 in GLEP27, if we
> couldn't simply handle users like any other package.

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:27. I would be interested in hearing
for which use cases GLEP:27 would be preferable.

If anyone wants to play with the draft or work on a reference
implementation, I can move this stuff to a public namespace.

Re: [gentoo-dev] Requirements for UID/GID management

[Alan McKinnon]

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 finds the user
>> already exists, leave it, it's UID and it's file ownerships alone, and keep
>> them as they are. If the user does not exist then create it.
> 
> That's what I've got it doing now...
> 
> 
>> Preferably use a pre-assigned UID/GID so there is some consistency
>> with most other Gentoo things out there.
> 
> This is the only point we have left to consider. To recap, there are
> three approaches to try:


[snip]

>   3 Mostly fixed UIDs, but with a fallback to random ones if you don't
> get the UID you want. Here, everyone specifies their "preferred"
> UID, and we try that first. If it doesn't work, you get the random
> assignment.
> 
> Pros (w.r.t option 2):
> 
>   * On a new installation, all of the UIDs that are assigned will
> likely be fixed, so you get some of the benefit of the first
> option without having to create an overlay.

This is my preferred choice

> 
> Cons (w.r.t. option 2):
> 
>   * The upgrade path is a little hairier. On an existing system,
> we'll be introducing a bunch of new user packages that want
> a particular UID but don't get it. On existing systems, the
> UID assignment will still essentially be random. That's
> problematic for packages that truly need the UID they've
> requested.

I say drop the upgrade path entirely. Why do you as a dev care?
You've made a compelling case that making any changes at all is hairy,
so don't even try and automate it.

As a mere user I personally would never expect Gentoo devs to deal with
this, and if there's a knob in make.conf to enable/disable such a user
upgrade path, I'd probably disable it.

I've had to do this exercise more times than I care to admit, usually to
get multiple machines across a network in sync or to deal with nfsv3,
and it's not something I'd ever dare throw a script or ebuild at.

If you achieved the simpler status of new installs of packages get the
preferred UID if available, then I'm 100% happy and over the moon.
Everything else is my problem, not yours (although I appreciate the
effort to even make the attempt)

> Option #1 is pretty much dead in the water without an upgrade path.
> We're considering #2 and #3 at the moment, but they're really not
> that different.
> 
> 
>> It could output an elog
>> saying the uid/gid doesn't match the new Gentoo norm, and provide the
>> commands to run to bring things into line (usermod, groupmod, find /
>> -user -exec chown, etc, etc)
>>
> 
> There's no safe way to do that. If you call chown (as root) on
> everything in a user-owned directory, that user can just create a
> symlink to e.g. /root/.bashrc and you'll give it root. It's really a
> miserable time trying to switch ownership of anything safely once it's
> been created.

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 {} \+

It works every time, but involves " find / " - ouch - and you can't do
it if the user is logged in or has running processes. This is all for
system accounts, so I reckon you have a huge show stopper right there,
requiring admin intervention

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[Andreas K. Huettel]

> > 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 keywords "stable", "testing", "unstable" is the
> > same as in 
> > the previous proposal, 
> 
> 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.

Makes sense.

> > 3) On introduction of the new column, it will be set to "stable" for
> > all 
> > stable arches, "testing" for all arches where "inofficial" stable
> > keywords 
> > exist (sh, s390, ...), and "unstable" everywhere else. 
> 
> 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 we get that fixed and could
> move to "testing" and then later "stable" in case of arm64.

That's already "in the system". Let's discuss, for example, m68k (my favourite 
broken arch). 

Now: 
* There are some stable keywords hanging around, but nobody cares about them 
except the m68k arch team (= Mike).
* All m68k profiles are "exp".
Repoman happily ignores it (unless you use -e).

In the near future:
* m68k is marked "testing" in arches.desc
* All m68k profiles remain "exp"
Repoman *still* happily ignores it (unless you use -e); if you use -e, it will 
test it with ~m68k=m68k.

In the far future, given the arch team is intersted:
* Upgrade profiles from exp to dev or even stable -> repoman will test it more, 
but still using ~m68k=m68k. 

So, whatever "non-support for broken arches" we have now will keep existing. 
Just that migrating away from it gets easier.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[Andreas K. Huettel]

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 now) dependency checking and enforcing 
is done per profile. And (as we've seen in a separate thread) via mask and 
force files the deptree can look quite different. 

So this would have to apply to *all* profiles of an arch, with a loss of 
functionality. And with a loss of speed, there's a good reason why on arm e.g. 
only one profile is stable.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[Kent Fredric]

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 
confusion.

To an extent there are things I like about the arches.desc proposal, but there 
are
things I'd avoid.

For instance:

---
  amd64  stable
---

In arches.desc doesn't really improve the situation a whole lot over the 
current situation
where the equivalent data in profiles.desc is itself, lacking sufficient 
granularity.

Instead, I'd rather the  file contain columns describing specific 
treatment of
specific things.

So instead, I'd prefer something in  akin to ( but not necessarily 
identical to )

---
   amd64 keywords=strict checkdeps=stable enforcedeps=stable
   mips  keywords=mixed  checkdeps=stable enforcedeps=dev
   m68k  keywords=mixed  checkdeps=expenforcedeps=exp
---

Now, I've used a "=" syntax here inline mostly because it makes 
examples easier
to show briefly, but a column-oriented syntax as 
"arch,keywords,checkdeps,enforcedeps" would also be fine.

I'd imagine the legal values for "keywords" being as follows:

- strict: arch-foo and ~arch-foo treated distinctly
- mixed: arch-foo treated as ~arch-foo
- any: packages that exist and have any keywords are ~arch-foo


"checkdeps" and "enforcedeps" are controls that dictate how to handle this arch
by default in repoman, all accepting the terms "stable, dev, exp, never"

- checkdeps=stable : dependency consistency is checked and reported by default
- checkdeps=dev: dependency consistency is only checked and reported with 
-d or -e y
- checkdeps=exp: dependency consistency is only checked and reported with 
-e y

- enforcedeps=stable : dependency consistency failures are fatalised by default
- enforcedeps=dev: dependency consistency failures are only fatalized with 
-d or -e y
- enforcedeps=exp: dependency consistency failures are only fatailised with 
-e y

However, in writing this, I realised that some profiles we may have in future 
may be inherently *archless*
and I don't know how this approach will work in conjunction with that.

Which draws me back to my original idea of having "profiles.types", where 
field[1] is a freeform value
which is used as field[3] in profiles.desc

Here is what a "profiles.types" would look like today:

---
   stable keywords=strict checkdeps=stable enforcedeps=stable
   devkeywords=strict checkdeps=devenforcedeps=dev
   expkeywords=strict checkdeps=expenforcedeps=exp
---

And here is how we want it to look in the near future

---
   stable keywords=strict checkdeps=stable enforcedeps=stable
   devkeywords=mixed  checkdeps=stable enforcedeps=dev
   expkeywords=mixed  checkdeps=expenforcedeps=exp
---

And down the road, we may want to add a third grade, "testing"

---
   stable  keywords=strict checkdeps=stable enforcedeps=stable
   testing keywords=strict checkdeps=stable enforcedeps=dev
   dev keywords=mixed  checkdeps=stable enforcedeps=dev
   exp keywords=mixed  checkdeps=expenforcedeps=exp
---

Even later down the road we could add an argument "-t" to repoman
which would allow us to add another field to the list:

- checkdeps=testing   : dependency consistency is checked  with -t, -d, or -e y
- enforcedeps=testing : dependency consistency is enforced with -t, -d, or -e y

---
   stable  keywords=strict checkdeps=stable enforcedeps=stable
   testing keywords=strict checkdeps=stable enforcedeps=testing
   dev keywords=mixed  checkdeps=stable enforcedeps=dev
   exp keywords=mixed  checkdeps=expenforcedeps=exp
---

But like, I'm not really sure enough about what I want to write a full proposal
for anything yet, ( Though I am getting really fond of = instead of
relying on columns to identify key )





pgp30z1qRmt2l.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] xorg-2.eclass: Use --disable-selective-werror.

[Matt Turner]

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() {
local dep_track="--disable-dependency-tracking"
fi
 
+   # Check if package supports disabling of selective -Werror=...
+   if grep -q -s "disable-selective-werror" ${ECONF_SOURCE:-.}/configure; 
then
+   local selective_werror="--disable-selective-werror"
+   fi
+
local myeconfargs=(
${dep_track}
+   ${selective_werror}
${FONT_OPTIONS}
"${xorgconfadd[@]}"
)
-- 
2.7.3

Re: [gentoo-dev] [PATCH] xorg-2.eclass: Use --disable-selective-werror.

[Matt Turner]

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.eclass
>> index b7c7ba2..7d681f2 100644
>> --- a/eclass/xorg-2.eclass
>> +++ b/eclass/xorg-2.eclass
>> @@ -468,6 +468,11 @@ xorg-2_src_configure() {
>>   local dep_track="--disable-dependency-tracking"
>>   fi
>>
>> + # Check if package supports disabling of selective -Werror=...
>> + if grep -q -s "disable-selective-werror" ${ECONF_SOURCE:-.}/configure; 
>> then
>> + local dep_track="--disable-selective-werror"
>
> I guess you planned to use new local var name here (or '+='). Otherwise
> code will drop --disable-dependency-tracking a few lines above.

Derp. Thanks for noticing.

Re: [gentoo-dev] [PATCH] xorg-2.eclass: Use --disable-selective-werror.

[Sergei Trofimovich]

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/xorg-2.eclass
> @@ -468,6 +468,11 @@ xorg-2_src_configure() {
>   local dep_track="--disable-dependency-tracking"
>   fi
>  
> + # Check if package supports disabling of selective -Werror=...
> + if grep -q -s "disable-selective-werror" ${ECONF_SOURCE:-.}/configure; 
> then
> + local dep_track="--disable-selective-werror"

I guess you planned to use new local var name here (or '+='). Otherwise
code will drop --disable-dependency-tracking a few lines above.

> + fi
>
>   local myeconfargs=(
>   ${dep_track}
>   ${FONT_OPTIONS}

-- 

  Sergei


pgpfhfFoZhKnC.pgp
Description: Цифровая подпись OpenPGP

[gentoo-dev] [PATCH] llvm.eclass: An eclass to handle dependencies on slotted LLVM

[Michał Górny]

---
 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.eclass
@@ -0,0 +1,98 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+# @ECLASS: llvm.eclass
+# @MAINTAINER:
+# Michał Górny 
+# @AUTHOR:
+# Michał Górny 
+# @BLURB: Utility functions to build against slotted LLVM
+# @DESCRIPTION:
+# The llvm.eclass provides utility functions that can be used to build
+# against specific version of slotted LLVM (with fallback to :0 for old
+# versions).
+#
+# This eclass does not generate dependency strings. You need to write
+# a proper dependency string yourself to guarantee that appropriate
+# version of LLVM is installed.
+#
+# Example use for a package supporting LLVM 3.8 to 5:
+# @CODE
+# inherit cmake-utils llvm
+#
+# RDEPEND="
+#  =sys-devel/llvm-3.8:0
+#  )
+# "
+#
+# src_configure() {
+#  local mycmakeargs=(
+#  -DLLVM_CONFIG="$(get_llvm_config 5)"
+#  )
+#  cmake-utils_src_configure
+# }
+# @CODE
+
+if [[ ! ${_LLVM_ECLASS} ]]; then
+
+# @ECLASS-VARIABLE: _LLVM_KNOWN_SLOTS
+# @INTERNAL
+# @DESCRIPTION:
+# Correct values of LLVM slots, newest first.
+declare -g -r _LLVM_KNOWN_SLOTS=( 5 4 )
+
+# @FUNCTION: get_llvm_config
+# @USAGE: []
+# @DESCRIPTION:
+# Prints path to llvm-config executable for the newest matching version
+# of LLVM. If  is provided, then no version newer than
+# the specified slot will be used. If it is not, the newest installed
+# version will be used.
+#
+# Note that the function does not support lower-bound version, so you
+# need to set proper dependencies. Otherwise, the function can return
+# a lower LLVM version than required.
+get_llvm_config() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local max_slot=${1}
+   local slot
+   for slot in "${_LLVM_KNOWN_SLOTS[@]}"; do
+   # skip higher slots
+   if [[ -n ${max_slot} ]]; then
+   if [[ ${max_slot} == ${slot} ]]; then
+   max_slot=
+   else
+   continue
+   fi
+   fi
+
+   local p=${EPREFIX}/usr/lib/llvm/${SLOT}/bin/llvm-config
+   if [[ -x ${p} ]]; then
+   echo "${p}"
+   return
+   fi
+   done
+
+   if [[ -n ${max_slot} ]]; then
+   die "${FUNCNAME}: invalid max_slot=${max_slot}"
+   fi
+
+   # fallback to :0
+   # assume it's always <= 4 (the lower max_slot allowed)
+   p=${EPREFIX}/usr/bin/llvm-config
+   if [[ -x ${p} ]]; then
+   echo "${p}"
+   return
+   fi
+
+   die "No LLVM slot${max_slot:+ <= ${max_slot}} found in PATH!"
+}
+
+_LLVM_ECLASS=1
+fi
-- 
2.11.0

[gentoo-dev] [PATCH] xorg-2.eclass: Use --disable-selective-werror.

[Matt Turner]

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() {
local dep_track="--disable-dependency-tracking"
fi
 
+   # Check if package supports disabling of selective -Werror=...
+   if grep -q -s "disable-selective-werror" ${ECONF_SOURCE:-.}/configure; 
then
+   local dep_track="--disable-selective-werror"
+   fi
+
local myeconfargs=(
${dep_track}
${FONT_OPTIONS}
-- 
2.7.3

Re: [gentoo-dev] Requirements for UID/GID management

[james]

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 are better.


The general process I would recommend is that if the ebuild finds
the user already exists, leave it, it's UID and it's file
ownerships alone, and keep them as they are. If the user does not
exist then create it.


That's what I've got it doing now...



Preferably use a pre-assigned UID/GID so there is some
consistency with most other Gentoo things out there.


This is the only point we have left to consider. To recap, there
are three approaches to try:

1 Truly fixed IDs. Every user gets the UID it wants, or it doesn't
get created. The UIDs are all determined beforehand.

2 Mostly random UIDs, and the few packages that need to specify
one can do so. Usually installation will never fail, but if some
user specifies a particular UID and doesn't get it, we die().

3 Mostly fixed UIDs, but with a fallback to random ones if you
don't get the UID you want. Here, everyone specifies their
"preferred" UID, and we try that first. If it doesn't work, you get
the random assignment.



You could easily start with #3, and after some years, move to #1.


Yep.  But, why can't (1) be  selectable (now) as  part of a profile, 
once that discussion on profiles is formalized into a pathway forward?




Anyone with a 20 year old Gentoo install (by that time) should expect
to have to do very heavy lifting.


Just leave them alone for now, as gentoo systems can now have different 
gid/uid mappings. Migration strategies will emerge over time. We'd  need 
some mechanism to determine if a given package attempts to set a 
contrarian uid/gid.  Perhaps a flag for those packages could address 
uid/gid conflicts going forward in a one-off solution?




I for one am more than willing to do whatever shell commands necessary
to make all my Gentoo installs agree on UIDs and get #1 now, but I
realise most people are not.


YES! I think after (1) is finalized, it should be part of the handbook 
installation as a default, but selectable. That way the migration

is gently fast-tracked. Matching up with Debian, is a really good idea,
as long as nothing is conflated by systemd.


- --arw



hth,
James



- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYjiTOAAoJEMspy1GSK50UCgYP/j7zBRAiL6w7fACER+A+J/3x
keXe4OsBzlNsUxqC+BrQ/Y9tCSJnIHRIs6ozQCgEdfAKJfkLqkSmKAY3O3RT+mho
VzjUCibftf/UNGOnFf6BqXCeBEjtV1YA7URlYumNyHxdG/AFIICWYFSSTLwzJoR1
91wqJmbcUI3LtQXoXodaYC2nbUWvcbO8RyxpDmxZ33L8xj1lAgpuFNcdEs+Rscxp
oDK4zJC/K8wUYTUR2YO1Lb3lPF6qgJbMcX0YpQaXIGeYA2PXf4O+LqTXmGNr4O9r
DFM3dbPgq2YPuHORACUY5YsmPBjHiaJlgzJo2WrhnIc2D1MPhA430Xlloiua3kF9
G7yqkz7mhBtJFrExoQ2MrtXMB5vwDUZ+3qrBzx/cKfxpSzsRck5NZ27eWK0oEpg2
fAUFJT7iIwSD3WyLkQbc2HHQ5nnTlnrBHM56YgCIPgz1Y4aNSB7hA+tCfQj4CNZC
Y25d9VzBM2KclASiH6ROQLK5EyU0joMtZvTRx89b8SJV+AebLeaWtCsGe41KeF/W
iDSnPGXtKRLYZtdebxGCXZwbaUVCRu/cIH2TXMpWDjm0iw3GoFZ6jiLveRCns59U
UecZNQph5tPc/HBX2zCTTmH3jNfifSfb525aHVnUSVlyTWa8SQzw2jlnOuAkI33q
8MY5++CHplEPGVCvYMrc
=99NE
-END PGP SIGNATURE-

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[james]

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 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 safer).

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 keywords "stable", "testing", "unstable" is the same as in
the previous proposal,


"Does this arch support stable keywords, and how should "arch" vs. "~arch"
be treated?"
- "stable": separately check consistency of ~arch and arch tree, both have
to be OK. This is what repoman is doing now, and is the default if the 4th
column is undefined.
- "testing": treat "arch" as "~arch" when requiring consistency, do not
check "arch" alone. Useful if an arch wants to prepare going stable, useful
for arch teams maintaining a pseudo-stable subset for stages. repoman could
have a new command line switch that temporarily upgrades from "testing" to
"stable" (for arch team work).
- "unstable": check "~arch" only, "arch" in an ebuild produces a fatal
repoman error


The combination of current profiles.desc and new arch.desc provides the same
flexibility as in the previous e-mail.

Compatibility and transition:

0) PMS should be amended to allow the additional file.

1) Compatibility: No arch.desc and new system, or arch not listed in arch.desc
*Arches* are treated as "stable" by repoman (current behaviour), with profile
status according to profiles.desc.
Gentoolkit and other tools trying to determine a list of stable arches should
fall back to current method of scanning profiles.desc for stable profiles.

2) Compatibility: arch.desc and old system
Tools ignore the unknown file (?).
Repoman and other tools may emit surplus errors when profiles are checked on
arches that are "testing" (they check the consistency of the stable tree
alone, which is not OK, since "arch" is supposed to be treated like "~arch").

3) On introduction of the new column, it will be set to "stable" for all
stable arches, "testing" for all arches where "inofficial" stable keywords
exist (sh, s390, ...), and "unstable" everywhere else.

4) Arches in "testing" or "unstable" may eventually consider re-introducing
stable *profiles* so their deptree in ~arch remains consistent.

More opinions, flames, cookies?

Cheers, Andreas


I like what I have read here and elsewhere.

Solutions centric around  a minimized profile will allow gentooers to 
use identical (minimized) profiles for a wide variety of hardware 
types:: different uP, dsp, fpga, custom (soc, asic, etc). I.E. 
heterogeneous gentoo clusters without any systemd associated codes. I do 
not have access to Kent's posting so perhaps a reference to Kent's ideas?



It would be very much appreciated if there is a posting on this list of 
what the consensus becomes, with some discussion as to how it will 
affect the ever expanding variety of cluster formations, particularly 
gentoo-style unikernel types of clusters and how to cluster up a variety 
of gentoo-embedded systems, which are actually quite similar to

unikernel based clusters.


A state-diagram of just how all of these profiles are intertwined, would 
help to clarify the details and thus be keenly appreciate, when a final 
verdict is reached.



hth,
James

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[Kent Fredric]

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 we get that fixed and could
> move to "testing" and then later "stable" in case of arm64.

This is one aspect I liked about my other proposal, that the behaviours
associated with various keywords was well defined.

---
# keywords: 
#   - strict: arch-foo and ~arch-foo treated distinctly
#   - mixed: arch-foo treated as ~arch-foo
#   - any: packages that exist and have any keywords are ~arch-foo
#
# dependencies:
#   - enforce: referential integrity within logical keywords 
#  is required
#   - warn: referential integrity within logical keywords
#   warns when its bad, and enforced with -d
#   - ignore: referential integrity is not even considered
# without -e y  and enforced with -e y

# name  | keywords | dependencies
stable strict check

# was strict ignore
dev mixed warn
exp mixed ignore


In that, its instructive as to the significance of the terms.

"Unstable" and "Broken" don't really say much to me.

But dependencies=ignore much more adequately communicates to me
the state that, dependency coherence is known to be problematic
and that you should not care about dependency coherence unless
you have some specific agenda.


If we can mix and match some of these designs with the arch.desc file
however, I'm all for it.


pgpEFP9VLjrpv.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Requirements for UID/GID management

[James Le Cuirot]

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 thinking about
> >> diving in to that some time later, after the GLEP 70 work I'm
> >> doing, but if someone else wants to take it - please!  That would
> >> greatly ease the pain of not only NFS, but swapping data disks
> >> around between different / .
> >> 
> >> Consider, for example, one of my use cases for this:  I have a 
> >> LibreSSL / that I use solely for testing ebuilds against it, and
> >> my regular / with OpenSSL.  I share /home and /srv between these
> >> two, but the apache, nginx, and charybdis users have different
> >> UIDs between them.  Therefore I have to chown -R each time I test
> >> LibreSSL.
> >> 
> >> I could use a different /home and /srv, or make two copies, but
> >> it's much easier for me to test these apps having my entire
> >> normal environment available to me.  
> > 
> > As mentioned in my other post, why are you not using idmapd? It's 
> > trivial to set up on top of NFSv4.
> 
> I think you have missed the point.  This is not on a network and this
> has nothing to do with NFS of any version.

Apologies, I didn't read that as closely as I should have done.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp10NwqXXfhX.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[Kent Fredric]

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 just a warning that there are additional columns
or field values not supported by the existing version, so that one knows
they are possibly missing out on some important checks.

Maybe even worth specifying that the first line of the file is a comment
like

# version:app-portage/repoman-2.3.1

Which can be extracted and displayed to a user as follows:

"Unsupported values in profiles/arch.desc: foo, bar, baz
 Consider upgrading to at least ${version} or equivalent"

Where "${version}" is extracted via /#\s*version:([^ ]*)/

( That is, showing the contents of the part after "version:" verbatim
  and not even considering doing version comparisons )




pgpgkPqU2hPu5.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Requirements for UID/GID management

[A. Wilcox]

-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 process I would recommend is that if the ebuild finds
>> the user already exists, leave it, it's UID and it's file
>> ownerships alone, and keep them as they are. If the user does not
>> exist then create it.
> 
> That's what I've got it doing now...
> 
> 
>> Preferably use a pre-assigned UID/GID so there is some
>> consistency with most other Gentoo things out there.
> 
> This is the only point we have left to consider. To recap, there
> are three approaches to try:
> 
> 1 Truly fixed IDs. Every user gets the UID it wants, or it doesn't 
> get created. The UIDs are all determined beforehand.
> 
> 2 Mostly random UIDs, and the few packages that need to specify
> one can do so. Usually installation will never fail, but if some
> user specifies a particular UID and doesn't get it, we die().
> 
> 3 Mostly fixed UIDs, but with a fallback to random ones if you
> don't get the UID you want. Here, everyone specifies their
> "preferred" UID, and we try that first. If it doesn't work, you get
> the random assignment.


You could easily start with #3, and after some years, move to #1.

Anyone with a 20 year old Gentoo install (by that time) should expect
to have to do very heavy lifting.

I for one am more than willing to do whatever shell commands necessary
to make all my Gentoo installs agree on UIDs and get #1 now, but I
realise most people are not.

- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYjiTOAAoJEMspy1GSK50UCgYP/j7zBRAiL6w7fACER+A+J/3x
keXe4OsBzlNsUxqC+BrQ/Y9tCSJnIHRIs6ozQCgEdfAKJfkLqkSmKAY3O3RT+mho
VzjUCibftf/UNGOnFf6BqXCeBEjtV1YA7URlYumNyHxdG/AFIICWYFSSTLwzJoR1
91wqJmbcUI3LtQXoXodaYC2nbUWvcbO8RyxpDmxZ33L8xj1lAgpuFNcdEs+Rscxp
oDK4zJC/K8wUYTUR2YO1Lb3lPF6qgJbMcX0YpQaXIGeYA2PXf4O+LqTXmGNr4O9r
DFM3dbPgq2YPuHORACUY5YsmPBjHiaJlgzJo2WrhnIc2D1MPhA430Xlloiua3kF9
G7yqkz7mhBtJFrExoQ2MrtXMB5vwDUZ+3qrBzx/cKfxpSzsRck5NZ27eWK0oEpg2
fAUFJT7iIwSD3WyLkQbc2HHQ5nnTlnrBHM56YgCIPgz1Y4aNSB7hA+tCfQj4CNZC
Y25d9VzBM2KclASiH6ROQLK5EyU0joMtZvTRx89b8SJV+AebLeaWtCsGe41KeF/W
iDSnPGXtKRLYZtdebxGCXZwbaUVCRu/cIH2TXMpWDjm0iw3GoFZ6jiLveRCns59U
UecZNQph5tPc/HBX2zCTTmH3jNfifSfb525aHVnUSVlyTWa8SQzw2jlnOuAkI33q
8MY5++CHplEPGVCvYMrc
=99NE
-END PGP SIGNATURE-

Re: [gentoo-dev] Requirements for UID/GID management

[Michael Orlitzky]

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 abused for things like that. This has been
> discussed in bug 53269 previously.

Well they're not packages now because they're not packages now. If we
make them packages, they'll be packages. We treat them a lot like
packages, and by making them packages, a lot of things get simpler.


> IMHO the way to go is to add proper variables in the next EAPI, like
> the EUSERS and EGROUPS proposed (and approved) in GLEP 27.

But then we need to add features to make EUSERS and EGROUPS work exactly
like DEPEND and RDEPEND, which seems counter-productive. What if I need
a user conditionally on some USE flag? What if I need to share a user
with another package? How do users get removed?

I will try to coalesce all of this into a wiki page at some point.

Re: [gentoo-dev] Requirements for UID/GID management

[A. Wilcox]

-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 in to that some time later, after the GLEP 70 work I'm
>> doing, but if someone else wants to take it - please!  That would
>> greatly ease the pain of not only NFS, but swapping data disks
>> around between different / .
>> 
>> Consider, for example, one of my use cases for this:  I have a 
>> LibreSSL / that I use solely for testing ebuilds against it, and
>> my regular / with OpenSSL.  I share /home and /srv between these
>> two, but the apache, nginx, and charybdis users have different
>> UIDs between them.  Therefore I have to chown -R each time I test
>> LibreSSL.
>> 
>> I could use a different /home and /srv, or make two copies, but
>> it's much easier for me to test these apps having my entire
>> normal environment available to me.
> 
> As mentioned in my other post, why are you not using idmapd? It's 
> trivial to set up on top of NFSv4.
> 

I think you have missed the point.  This is not on a network and this
has nothing to do with NFS of any version.

This is two LVM volumes, /dev/ciall/libressl and /dev/ciall/root,
mounting /dev/ciall/home and /dev/ciall/srv where they belong.  The
kernel is started with different root=, or sometimes I just bind mount
and chroot if I want to run both at the same time.

Nothing to do with networking, just two parallel Gentoo installs on the
same machine that can't agree worth a darn on UIDs/GIDs.

I like the pre_pkg_setup idea spouted elsewhere in this thread and will
likely start using this myself until Gentoo figures out how to guarantee
stability with UIDs.

Regards,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYjiOAAAoJEMspy1GSK50UWrAQAIq0fz+oxA2SWCEBNdKKZgRN
gNJOcnEj9lWSiE4bXA4C4diFj38GD5HhTK6awwNjEJ2e3S/+IvJvy97RcUjzpP09
iE+77p3YyZeVxywONJ+BK0gSWc3pJrYzzZWMmHMhIhA5TW78OPKFgP4q+FT8Ruwu
TdYL4/cH6shcELacsgLq+0fBxgT8xkl5LA0OWdW5g2lVFzcnZ7sM/qX7WMlksaVY
o4fPBc10hNwrAW5HsSBOw6tZsf+8CtaBaYVub1DfgWSLxmE70+9pX+4VCObvuc9m
CZ1u3tvcus7xBbpIDxD9M6yC7Jkj250Gr0IAJol2y8JJY5EyCu/iNtUbHT3lgb+F
qRKLbMDp91F9jzHmup04UuJdVkcDaxA4nfb7RWGOnH4U5BmmCdHkxUMtSA2vPNAh
9m7dwn+Yb6OjHKvB/gswbRfT4vV6bn0a07/J72GBgoWvEvGZ/rj9mO5O7gu/k9eQ
zXc3eSWWmi6S3FtDHKNP7U+CrBGOu6DN79GGDO4zzGpl8aWGFm8ol3qW5jtWKdsP
y0K1n2erH1Xfj5CoXzcbm3s7EQxiB3hEHlfv2gYYMrZZuqKgrVXQ5krvNApbsiQo
dVmGOugfIUnVcv/o6rpwtCzNnyGahq6PISkJbRwzh3irA7fsZjYYZITnN6Ba0jIU
EVO3/JgkJDAvyn+ZWQ8O
=aaA7
-END PGP SIGNATURE-

Re: [gentoo-dev] Requirements for UID/GID management

[Michael Orlitzky]

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 and it's file ownerships alone, and keep
> them as they are. If the user does not exist then create it.

That's what I've got it doing now...


> Preferably use a pre-assigned UID/GID so there is some consistency
> with most other Gentoo things out there.

This is the only point we have left to consider. To recap, there are
three approaches to try:

  1 Truly fixed IDs. Every user gets the UID it wants, or it doesn't
get created. The UIDs are all determined beforehand.

Pros:

  * Cleaner code
  * UIDs agree on all systems
  * Sweet subslot rebuilds
  * Could decide on UIDs to match e.g. Debian

Cons:

  * Absolutely no way to introduce it into the tree
without breaking every existing system.


  2 Mostly random UIDs, and the few packages that need to specify one
can do so. Usually installation will never fail, but if some user
specifies a particular UID and doesn't get it, we die().

Pros (w.r.t. option 3):

  * The upgrade path is a little smoother. Most packages don't care
about their UID, and the UIDs on your system *right now* are all
random, so the upgrade path is "leave them there."

Cons (w.r.t. option 3):

  * The UIDs on your system will never be predictable, and anyone
who needs their UIDs consistent across systems will have to
create an overlay that changes the behavior of a few ebuilds.

  3 Mostly fixed UIDs, but with a fallback to random ones if you don't
get the UID you want. Here, everyone specifies their "preferred"
UID, and we try that first. If it doesn't work, you get the random
assignment.

Pros (w.r.t option 2):

  * On a new installation, all of the UIDs that are assigned will
likely be fixed, so you get some of the benefit of the first
option without having to create an overlay.

Cons (w.r.t. option 2):

  * The upgrade path is a little hairier. On an existing system,
we'll be introducing a bunch of new user packages that want
a particular UID but don't get it. On existing systems, the
UID assignment will still essentially be random. That's
problematic for packages that truly need the UID they've
requested.

Option #1 is pretty much dead in the water without an upgrade path.
We're considering #2 and #3 at the moment, but they're really not
that different.


> It could output an elog
> saying the uid/gid doesn't match the new Gentoo norm, and provide the
> commands to run to bring things into line (usermod, groupmod, find /
> -user -exec chown, etc, etc)
> 

There's no safe way to do that. If you call chown (as root) on
everything in a user-owned directory, that user can just create a
symlink to e.g. /root/.bashrc and you'll give it root. It's really a
miserable time trying to switch ownership of anything safely once it's
been created.

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[Mart Raudsepp]

Ü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 safer).
> 
> 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
> mips  testing
> shunstable
> 
> The meaning of the keywords "stable", "testing", "unstable" is the
> same as in 
> the previous proposal, 

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.

> > "Does this arch support stable keywords, and how should "arch" vs.
> > "~arch"
> > be treated?"
> > - "stable": separately check consistency of ~arch and arch tree,
> > both have
> > to be OK. This is what repoman is doing now, and is the default if
> > the 4th
> > column is undefined.
> > - "testing": treat "arch" as "~arch" when requiring consistency, do
> > not
> > check "arch" alone. Useful if an arch wants to prepare going
> > stable, useful
> > for arch teams maintaining a pseudo-stable subset for stages.
> > repoman could
> > have a new command line switch that temporarily upgrades from
> > "testing" to
> > "stable" (for arch team work).
> > - "unstable": check "~arch" only, "arch" in an ebuild produces a
> > fatal
> > repoman error
> 
> The combination of current profiles.desc and new arch.desc provides
> the same 
> flexibility as in the previous e-mail.
> 
> Compatibility and transition:
> 
> 0) PMS should be amended to allow the additional file.
> 
> 1) Compatibility: No arch.desc and new system, or arch not listed in
> arch.desc
> *Arches* are treated as "stable" by repoman (current behaviour), with
> profile 
> status according to profiles.desc.
> Gentoolkit and other tools trying to determine a list of stable
> arches should 
> fall back to current method of scanning profiles.desc for stable
> profiles.
> 
> 2) Compatibility: arch.desc and old system
> Tools ignore the unknown file (?).
> Repoman and other tools may emit surplus errors when profiles are
> checked on 
> arches that are "testing" (they check the consistency of the stable
> tree 
> alone, which is not OK, since "arch" is supposed to be treated like
> "~arch").
> 
> 3) On introduction of the new column, it will be set to "stable" for
> all 
> stable arches, "testing" for all arches where "inofficial" stable
> keywords 
> exist (sh, s390, ...), and "unstable" everywhere else. 

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 we get that fixed and could
move to "testing" and then later "stable" in case of arm64.

> 4) Arches in "testing" or "unstable" may eventually consider re-
> introducing 
> stable *profiles* so their deptree in ~arch remains consistent.

Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[Andreas K. Huettel]

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, not a per-profile setting. So 
we can actually make things much easier (and the transition safer).

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 keywords "stable", "testing", "unstable" is the same as in 
the previous proposal, 

> "Does this arch support stable keywords, and how should "arch" vs. "~arch"
> be treated?"
> - "stable": separately check consistency of ~arch and arch tree, both have
> to be OK. This is what repoman is doing now, and is the default if the 4th
> column is undefined.
> - "testing": treat "arch" as "~arch" when requiring consistency, do not
> check "arch" alone. Useful if an arch wants to prepare going stable, useful
> for arch teams maintaining a pseudo-stable subset for stages. repoman could
> have a new command line switch that temporarily upgrades from "testing" to
> "stable" (for arch team work).
> - "unstable": check "~arch" only, "arch" in an ebuild produces a fatal
> repoman error

The combination of current profiles.desc and new arch.desc provides the same 
flexibility as in the previous e-mail.

Compatibility and transition:

0) PMS should be amended to allow the additional file.

1) Compatibility: No arch.desc and new system, or arch not listed in arch.desc
*Arches* are treated as "stable" by repoman (current behaviour), with profile 
status according to profiles.desc.
Gentoolkit and other tools trying to determine a list of stable arches should 
fall back to current method of scanning profiles.desc for stable profiles.

2) Compatibility: arch.desc and old system
Tools ignore the unknown file (?).
Repoman and other tools may emit surplus errors when profiles are checked on 
arches that are "testing" (they check the consistency of the stable tree 
alone, which is not OK, since "arch" is supposed to be treated like "~arch").

3) On introduction of the new column, it will be set to "stable" for all 
stable arches, "testing" for all arches where "inofficial" stable keywords 
exist (sh, s390, ...), and "unstable" everywhere else. 

4) Arches in "testing" or "unstable" may eventually consider re-introducing 
stable *profiles* so their deptree in ~arch remains consistent.

More opinions, flames, cookies?

Cheers, Andreas


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...

[Róbert Čerňanský]

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 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. Before REQUIRED_USE,
> > we would have a bunch of checks in pkg_pretend() to test if the
> > user's configuration was invalid. If it was, we could output a nice
> > explanation and tell him to try again. But, bash code in
> > pkg_pretend can't be understood by the package manager, and
> > requires execution to determine if a package can be installed. So
> > we got REQUIRED_USE, which fixes those problems, and introduces a
> > new one: no one knows WTF to do when portage outputs a REQUIRED_USE
> > error. Now you get what looks like a core dump of the dependency
> > graph instead of "this package only uses one database, so pick
> > either mysql or sqlite."
> > 
> > Both approaches have another problem: USE flag constraints on
> > packages simply don't work with global USE flags. Global USE flags
> > don't work that well to begin with, since the same flag means
> > different things to each package (and the fact that they're global
> > means "enable foo" is all we get for documentation). Regardless,
> > when you have 100 flags enabled globally and start installing
> > thousands of packages with USE constraints, you're eventually going
> > to get to a point where everything has conflicting requirements and
> > you need to switch to package.use to sort it all out.
> > 
> > Both pkg_pretend and REQUIRED_USE have that problem and try to
> > solve it in different ways. If you don't care about
> > machine-readability, then in pkg_pretend you could try to choose
> > "the best" of two conflicting flags and just silently go with it.
> > There are a lot of problems with that, like what happens if you
> > need to add a conditional dependency on those flags (you can't
> > change DEPEND in pkg_pretend). With REQUIRED_USE, you instead need
> > to set IUSE defaults to get it to do something without user
> > interaction, but the tricks that you can do with IUSE don't solve
> > every REQUIRED_USE conflict. In the harder cases, you can try to
> > figure out what to do on behalf of the user in the ebuild, but then
> > you're right back to the same set of problems that you had with
> > pkg_pretend, because the decision is being made in code and not in
> > metadata/flags.
> > 
> > I think a slow migration away from global USE flags is the only way
> > out of the jam. We get better USE flag docs for free, and no
> > REQUIRED_USE conflicts that the user didn't cause himself. We could
> > probably also get rid of a lot of IUSE defaults that serve only to
> > undo various profile defaults. It would be annoying at first, but
> > once a few critical profile defaults are moved into package.use,
> > better. 
> 
> I might be wrong, but my suspicion is that those that advocate for
> pkg_pretend over REQUIRED_USE tend to do so because of the blocking
> nature of REQUIRED_USE's current implementation rather than the
> construct of describing USE flag inter-dependencies itself.
> 
> So, personally, I think that we should be discussing ways of adding
> interactivity to the package manager for resolution of REQUIRED_USE
> conflicts rather than discussing ways to work around or remove it.
> It's a good construct, we should take advantage of it, and work to
> make it more user friendly.
> 
> My initial feeling is having flags, one for interactive handling, one
> for current behavior.  Interactive has two modes, like --autounmask
> and --autounmask-write (and could even reuse these if possible),
> which does something similar to how Debian's apt handles dependency
> conflicts by calculating the alternatives and prompting the user to
> select a numbered option.  So the autounmask equivalent displays the
> changes to the config files and the autounmask-write equivalent
> writes them to the appropriate config files.  This is just a general
> idea that I just came up with right now, so I haven't put too much
> thought into it.  It is mostly meant to get solutions for interactive
> handling discussed on the ML.

If I may add a user opinion.  I agree with you but I would choose
different solution for user-friendliness.  Instead of _adding_
interactivity to PM I would _remove_ it.  So if there would be multiple
choices the user would not be prompted, but some default option would be
selected by PM.  To the user, such behaviour would be similar to
current handling of virtuals - if a package depends on a virtual the
user is not prompted to make a choice but the default is selected
instead.

Some of the USE settings levels would have to be overridable by PM in
order to achieve this - most likely it would be global and defau

Re: [gentoo-dev] Requirements for UID/GID management

[Michał Górny]

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
> variables shouldn't be abused for things like that. This has been
> discussed in bug 53269 previously.
> 
> IMHO the way to go is to add proper variables in the next EAPI, like
> the EUSERS and EGROUPS proposed (and approved) in GLEP 27.

Don't forget to introduce a properly convoluted way of expressing
conditionals on USE flags etc. ;-)

-- 
Best regards,
Michał Górny



pgpyxbw87d5xh.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Requirements for UID/GID management

[Ulrich Mueller]

> 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 53269 previously.

IMHO the way to go is to add proper variables in the next EAPI, like
the EUSERS and EGROUPS proposed (and approved) in GLEP 27.

Ulrich


pgphh0BJneUAd.pgp
Description: PGP signature

Re: [gentoo-dev] Requirements for UID/GID management

[Alan McKinnon]

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 user simply
>> sticking a default UID without any effort to avoid collisions is
>> better than nothing, but having a wiki page where people can register
>> UIDs isn't that big a deal.
>>
> 
> I threw together an ugly implementation so I could play with both
> approaches -- random or fixed UIDs by default. The code to get user and
> group management working is of course nice and simple in either case.
> Where they both turn to shit is the upgrade path.
> 
> Here's a problem I have no solution for. Suppose we tell everyone to
> pick a fixed UID for their user packages. I have a randomly assigned
> "tcpdump" user as UID 102 on my machine today. If we roll this out next
> week and the tcpdump maintainer chooses UID=321 as his fixed UID, what
> happens when I go to install sys-user/tcpdump? Every option is bad:
> 
>   * Keep the existing user. Now its UID is wrong. You might say "so
> what," but the majority of users on the majority of systems are
> going to have this problem, so you have to wonder what we've
> gained by deciding on fixed UIDs and then ultimately assigning
> them randomly anyway.
> 
> There's the related problem of what to do if the tuxracer maintainer
> decides he wants to use UID=102 and I still have tcpdump using it.
> 
>   * Overwrite the existing user with the new one. Your packages all
> break.
> 
>   * Have the ebuild die(), and tell the user to fix the UID and file
> ownership himself before emerge can continue. Good luck with that.
> 
> In the mostly-random-UIDs approach, I have an answer, even if it's not
> pretty: I can use the pre-existing UID instead of the next available
> one. This still fails if the ebuild author requests a specific
> (conflicting) UID, but that should be extremely rare in the random-UIDs
> model.
> 
> 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 and it's file ownerships alone, and keep
them as they are. If the user does not exist then create it. Preferably
use a pre-assigned UID/GID so there is some consistency with most other
Gentoo things out there.

If the user already exists, it's presumably because the sysadmin wants
it that way or it was installed that way from an older ebuild. Either
way the ebuild cannot mess around with that. It could output an elog
saying the uid/gid doesn't match the new Gentoo norm, and provide the
commands to run to bring things into line (usermod, groupmod, find /
-user -exec chown, etc, etc)



-- 
Alan McKinnon
alan.mckin...@gmail.com