date:20161130

There are some things I noticed in the tmpfiles_process() function:

- `type` currently also checks for functions, alias, and builtins,
besides executable files.  If that's not intended, the `-P` option
should be added.
- What happens if neither systemd-tmpfiles nor opentmpfiles is found?
- Shouldn't the function return a nonzero if an error occurs?  It
would help scripts abort.
- `[[ ${ROOT} == / ]] || return 0` seems to present a harmless false
condition, and it doesn't show an error message.  I would be helpful
to have a comment added above it to give details why.

I also prefer some things this way:

- Indent the contents of the first `if` block for consistency's sake,
and less confusion.
- Patterns in the `case` block doesn't have to be indented. This makes
the contents of the `case` block aligned with the contents of the
other blocks (`if`, `while`, etc.), and it makes the use of indents at
minimum when the block is used recursively.
- The subject word in the case block does not have to be quoted.
- Always keep blocks isolated from adjacent lines.

-- 
konsolebox


tmpfiles.eclass
Description: Binary data

Re: [gentoo-dev] Developer GitHub usernames

2016-11-30 Thread Daniel Campbell

On 11/26/2016 01:08 AM, Michał Górny wrote:
> On Sat, 26 Nov 2016 00:03:59 -0800
> Daniel Campbell  wrote:
> 
>> 
>> A funny deficiency of GitHub is it doesn't allow for open conversations.
>> You're always forced to talk about something directly related to the
>> code, like an Issue or a Commit. Gists can be somewhat analogous to an
>> open discussion, but that strikes me as abuse of the medium.
>> Additionally, it's not a threaded format so it's hard to guess which
>> branch of conversation you're on.
>>
>> Of course sometimes you *want* to focus strictly on the code, but that's
>> not how real-world organizations work. They're made of people, and most
>> people end up talking about things *around* the code that are still
>> important, like the various RFCs that we post here on the ML. None of
>> what GitHub offers is suitable for that imo.
>> 
> 
> GitHub is a code hosting and review tool, not a forum. It's not
> a replacement for everything ever invented.
> 
The GitHub guys seem to disagree with you; unless you consider custom
emoji support (and reactions, thumbs-up counts, etc) integral to the
code review process.

Since you didn't address it, what tone was intended by the quip about
others "pretending" to not use GitHub?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] ChangeLog generation, profiles/ mess.

2016-11-30 Thread Ulrich Mueller

> On Tue, 29 Nov 2016, Robin H Johnson wrote:

>> - one ChangeLog for each first-level subdir other than categories
>>   (i.e. eclass, licenses, profiles, etc.),
> Already done, just querying if profiles/ needs more ChangeLog detail.

Yeah, keep one ChangeLog for all of profiles/. The existing
sub-ChangeLogs there are rather confusing because they don't seem to
follow any consistent layout.

Keeping one single file would also agree with the recommendation for
commit messages, namely to prepend "profiles:" for any change below
the profiles/ dir.
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_format

> Here's the size of the non-category non-package changelogs, with
> splitting to all top-levels.
> 127 scripts/ChangeLog-2016
>1266 metadata/ChangeLog-2016
>1929 ChangeLog-2016
>   11987 licenses/ChangeLog-2016
>  198021 eclass/ChangeLog-2016
>  362733 profiles/ChangeLog-2016

> If we collapse to have:
> - per-package
> - major top-levels: eclass/, profile/, licenses/
> - (everything else)
> Then we get:
>   11972 licenses/ChangeLog-2016
>   12941 ChangeLog-2016
>  196905 eclass/ChangeLog-2016
>  362040 profiles/ChangeLog-2016

I like the second scheme better. (No strong opinion about keeping
separate ChangeLogs for metadata/ and scripts/ though.)

Ulrich

pgpJIMernMHEX.pgp
Description: PGP signature

Re: [gentoo-dev] linux-mod.eclass: Check for !TRIM_UNUSED_KSYMS

2016-11-30 Thread Jeroen Roovers

On Tue, 29 Nov 2016 10:39:04 -0500
Mike Gilbert  wrote:

> On Tue, Nov 29, 2016 at 9:14 AM, Jeroen Roovers 
> wrote:
> > --- a/eclass/linux-mod.eclass
> > +++ b/eclass/linux-mod.eclass
> > @@ -566,6 +566,9 @@ linux-mod_pkg_setup() {
> > return
> > fi
> >
> > +   # External modules use kernel symbols (bug #591832)
> > +   export CONFIG_CHECK+=" !TRIM_UNUSED_KSYMS"
> > +
> > linux-info_pkg_setup;
> > require_configured_kernel
> > check_kernel_built;
> >  
> 
> There is no need to export CONFIG_CHECK to the environment here.

Interesting. The same is done in linux-mod_pkg_setup_binary(), so which?


 jer

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 4

On Wed, Nov 30, 2016 at 3:38 AM, konsolebox  wrote:
> There are some things I noticed in the tmpfiles_process() function:
>
> - `type` currently also checks for functions, alias, and builtins,
> besides executable files.  If that's not intended, the `-P` option
> should be added.

I cannot conceive of any way a function or alias would be defined with
these names unless an ebuild author did it intentionally or a user did
it via /etc/portage/bashrc. In either case, I see no need to prevent
that.

> - `[[ ${ROOT} == / ]] || return 0` seems to present a harmless false
> condition, and it doesn't show an error message.  I would be helpful
> to have a comment added above it to give details why.

We only want to process tmpfiles for the currently running system.

If ROOT is not /, it indicates we are installing the package for use
on a different system or in a container. In either case, the tmpfiles
would be processed upon boot when that system/container is started.

I find this fairly obvious, but if William wants to document it that's fine.

> I also prefer some things this way:
>
> - Indent the contents of the first `if` block for consistency's sake,
> and less confusion.

I disagree; indenting the entire eclass is silly and does not really
improve readability. Also, this is a very common pattern found in
other eclasses.

> - Patterns in the `case` block doesn't have to be indented. This makes
> the contents of the `case` block aligned with the contents of the
> other blocks (`if`, `while`, etc.), and it makes the use of indents at
> minimum when the block is used recursively.

Sorry, I have no idea what you're trying to say here. Recursive blocks?

This really feels like you're making a personal style suggestion here,
and I personally see nothing wrong with it as-is.

Re: [gentoo-dev] linux-mod.eclass: Check for !TRIM_UNUSED_KSYMS

On Wed, Nov 30, 2016 at 6:16 AM, Jeroen Roovers  wrote:
> On Tue, 29 Nov 2016 10:39:04 -0500
> Mike Gilbert  wrote:
>
>> On Tue, Nov 29, 2016 at 9:14 AM, Jeroen Roovers 
>> wrote:
>> > --- a/eclass/linux-mod.eclass
>> > +++ b/eclass/linux-mod.eclass
>> > @@ -566,6 +566,9 @@ linux-mod_pkg_setup() {
>> > return
>> > fi
>> >
>> > +   # External modules use kernel symbols (bug #591832)
>> > +   export CONFIG_CHECK+=" !TRIM_UNUSED_KSYMS"
>> > +
>> > linux-info_pkg_setup;
>> > require_configured_kernel
>> > check_kernel_built;
>> >
>>
>> There is no need to export CONFIG_CHECK to the environment here.
>
> Interesting. The same is done in linux-mod_pkg_setup_binary(), so which?

As far as I know, it's a bash variable used by functions defined in
linux-info.eclass. It does not need to be passed to any child
processes, and so it does not need to be defined in the environment.

The export in linux-mod_pkg_setup_binary is unnecessary as well.

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 4

On 11/30/16, Mike Gilbert  wrote:
> On Wed, Nov 30, 2016 at 3:38 AM, konsolebox  wrote:
>> - `[[ ${ROOT} == / ]] || return 0` seems to present a harmless false
>> condition, and it doesn't show an error message.  I would be helpful
>> to have a comment added above it to give details why.
>
> We only want to process tmpfiles for the currently running system.
>
> If ROOT is not /, it indicates we are installing the package for use
> on a different system or in a container. In either case, the tmpfiles
> would be processed upon boot when that system/container is started.
>
> I find this fairly obvious, but if William wants to document it that's
> fine.

I'm not familiar with that, and so would other scripters who would
look at the eclass.

>> I also prefer some things this way:
>>
>> - Indent the contents of the first `if` block for consistency's sake,
>> and less confusion.
>
> I disagree; indenting the entire eclass is silly and does not really
> improve readability. Also, this is a very common pattern found in
> other eclasses.

I prefer following consistency before anything else.  And it's just
uncommon and odd, but it's not silly.  Imagine if you use another `if`
block on the second level where more functions are defined.  Would you
also not indent that?

>> - Patterns in the `case` block doesn't have to be indented. This makes
>> the contents of the `case` block aligned with the contents of the
>> other blocks (`if`, `while`, etc.), and it makes the use of indents at
>> minimum when the block is used recursively.
>
> Sorry, I have no idea what you're trying to say here. Recursive blocks?

One expensive in the use of indents:

case $x in
a)
# first inner level
case $y in
1)
# second inner level
case ...
;;
2)
;;
esac
;;
b)
;;
esac

if [ "$x" = a ]; then
# first inner level
if [ "$y" = 1 ]; then
# second inner level
elif [ "$y" = 2 ]; then
:
else
:
fi
elif [ "$x" = b ]; then
:
else
:
fi

vs.

case $x in
a)
case $y in
1)
case ...
;;
2)
;;
esac
;;
b)
;;
esac

> This really feels like you're making a personal style suggestion here,
> and I personally see nothing wrong with it as-is.

Yes the second part is more personal.

-- 
konsolebox

[gentoo-dev] New project: GitHub

2016-11-30 Thread Michał Górny

Hello, everyone.

Following the recent additions to our infrastructure, I've finally
decide to form the GitHub project [1] that was requested for some time
[2] already.

The project will mostly serve administrative and documentation
purposes. In other words, we're the people who will maintain the GitHub
organization and related infra, run the syncing scripts, provided
documentation for using GitHub and help other developers with their
requests regarding GitHub.

Feel free to add yourself to the project.

[1]:https://wiki.gentoo.org/wiki/Project:GitHub
[2]:https://bugs.gentoo.org/559592

-- 
Best regards,
Michał Górny



pgp_fufFqcFkr.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 4

On Wed, Nov 30, 2016 at 7:11 AM, konsolebox  wrote:
>>> I also prefer some things this way:
>>>
>>> - Indent the contents of the first `if` block for consistency's sake,
>>> and less confusion.
>>
>> I disagree; indenting the entire eclass is silly and does not really
>> improve readability. Also, this is a very common pattern found in
>> other eclasses.
>
> I prefer following consistency before anything else.  And it's just
> uncommon and odd, but it's not silly.  Imagine if you use another `if`
> block on the second level where more functions are defined.  Would you
> also not indent that?

That first "if" is a bit of a special case; it's only there to prevent
the code from being executed more than once in global scope. This
provides a minor speed boost when the eclass gets sourced more than
once, and makes sure that any global variables are only set once.

I think of it as being similar to pre-processor statement you would
find in a C header file; one does not generally indent all the code
within a C header file, because it just introduces a big chunk of
whitespace that does not improve code readability.

[gentoo-dev] Last rites: gnustep-libs/smbkit, gnustep-apps/gwnet, gnustep-apps/camera, gnustep-apps/stepulator

2016-11-30 Thread Bernard Cafarelli


# Bernard Cafarelli  (30 Nov 2016)
# Do not support gnustep-make v2 mode, last release more than 10 years 
ago

# Bugs #591576, #592546
# Removal in a month
gnustep-apps/camera
gnustep-apps/stepulator

# Bernard Cafarelli  (30 Nov 2016)
# Fails to build, abandoned 10 years ago, bug #590088
# Removal in a month
gnustep-apps/gwnet
gnustep-libs/smbkit

--
Bernard Cafarelli (Voyageur)

Re: [gentoo-dev] Step on my toes, please.

Hi,

On Thu, 3 Nov 2016 11:15:07 +0100 Jason A. Donenfeld wrote:
> Hey guys,
> 
> Every other day on IRC, I see people arguing about touching each
> others packages, despite our policies against it. 

We don't have policies against it, we do have the policy regulating
it. See section "Touching other developers ebuilds" in the
devmanual:
https://devmanual.gentoo.org/ebuild-maintenance/index.html

So this is OK to touch stuff of other people if:
- bug is created;
- no response after 2 weeks + ping + 2 weeks
- this is not @system or other critical stuff

> (Sometimes it's even
> me who's doing the touching!) My instinctive reaction is always,
> "can't everybody calm down and be happy somebody is doing your work
> for you?" The answer to this question is, of course, that it depends
> who the developer is and how competent you are.
> 
> So, nothing new here. I don't want to bikeshed about it. Business as usual.
> 
> I thought I'd do something loose and informal to rectify the problem.
> See my package-policy.txt on my developer space:
> 
> http://dev.gentoo.org/~zx2c4/package-policy.txt

It is likely that nobody will read this file. If you want to allow
people to modify your stuff faster than the policy above says, put
this somewhere in ebuilds as a comment. If you want to deny people
to touch your stuff when they are within the rules, you can't do
that (e.g. if you will go AWOL, your packages will still need care).

Best regards,
Andrew Savchenko

pgpiuLrkFVSMl.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Userkit.eclass

On Wednesday, November 30, 2016 8:54:42 AM EST Michał Górny wrote:
> On Tue, 29 Nov 2016 18:13:29 -0500
> 
> "William L. Thomson Jr."  wrote:
>>
> > I think you mean enewgroup and enewuser
> 
> FYI, enew* functions handle UID/GID collisions gracefully, and just
> fallback to using next free UID/GID.

I would disagree with such and some what makes specifying a UID/GID pointless 
if it simply will use the next available in the event of a collision. Which 
available likely comes from the default allocation range > 500 or 1000. If 
system and was intended to be below that, not really ideal.

> I'm not sure if you're aware that but most of tools doing backups
> actually use usernames/group names. So does new enough tar. So does
> ssh.

tar can map users and groups via file, but why waste the time with such?

> Are you specifically using some obsolete or braindead tools to prove
> your point? If you don't sync UIDs/GIDs properly, then you don't use
> them when moving data across systems. Simple as that.

I start with consistent base images and have the same uid/gid all on all so 
syncing is not needed. Nor do I need to deal with it during restoration.

> The only thing that you could worry about then are missing users/groups
> on the target system. But then, so far none of your talk solved that
> problem.

A problem that should not exist with a proper setup.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Optimizing toe stepping

On Thu, 3 Nov 2016 21:49:16 + Robin H. Johnson wrote:
> On Thu, Nov 03, 2016 at 05:36:03PM -0400, William L. Thomson Jr. wrote:
> > On Thursday, November 3, 2016 9:14:56 AM EDT William Hubbs wrote:
> I have posted about this subject before, and I'll go and dust off the
> proposal with the last changes added, when I have time soon hopefully.
> 
> > > I am also in favor of the metadata approach.
> > The only downfall is you end up with lots of package/developer specific 
> > policies which may become complex and a nuisance. It is likely better to 
> > have 
> > more of a global policy.
> Sure, global policies help (as a sane default), but being able to tell
> people the most common cases is important:
> 1. Yes, touch it, but please ask me (DEFAULT, including timeout value)
> 2. Yes, go ahead and touch this package, and don't ask me
> 3. danger will robinson! this is fragile!
> 
> I'm going to set #2 on the great majority of the 200+ packages that I
> directly maintain.
> 
> Make it easy to open a package up to MORE changes, and hard to restrict.
 
Looks like a reasonable approach. Probably it is worth to set
global policy describing these options and setting default
value. Should this issue be discussed with the council now?

As for implementation, repoman checks accepting this field should
be added, and skel.metadata.xml may be updated. I see no other
required changes, though I may miss something.

Best regards,
Andrew Savchenko


pgpzGLRY74dlQ.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Userkit.eclass

A couple more links, I should have provided initially as they better support 
the argument.

First from Debian, I cannot find a list, but it is clearly mentioned.

"0-99:
Globally allocated by the Debian project, the same on every Debian system"
https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2

This is even better, what Gentoo lacks, and could build upon.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/
Deployment_Guide/s1-users-groups-standard-users.html

Also carries to CentOS of course
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-users-groups-standard-users.html

Per previous links installing some RPMs that have fixed UID/GID will result in 
problems of other things are using it

"The vdsm user however is fixed to a UID of 36 and the kvm group is fixed to a 
GID of 36.
If UID 36 or GID 36 is already used by another account on the system then a 
conflict will arise during installation of the vdsm and qemu-kvm-rhev 
packages."

https://access.redhat.com/documentation/en-US/
Red_Hat_Enterprise_Virtualization/3.5/html/Installation_Guide/sect-
System_Accounts.html

-- 
William L. Thomson Jr.


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

Re: [gentoo-dev] Step on my toes, please.

On Wed, 30 Nov 2016 17:53:54 +0300 Andrew Savchenko wrote:
> On Thu, 3 Nov 2016 11:15:07 +0100 Jason A. Donenfeld wrote:
[...]
> > (Sometimes it's even
> > me who's doing the touching!) My instinctive reaction is always,
> > "can't everybody calm down and be happy somebody is doing your work
> > for you?" The answer to this question is, of course, that it depends
> > who the developer is and how competent you are.
> > 
> > So, nothing new here. I don't want to bikeshed about it. Business as usual.
> > 
> > I thought I'd do something loose and informal to rectify the problem.
> > See my package-policy.txt on my developer space:
> > 
> > http://dev.gentoo.org/~zx2c4/package-policy.txt
> 
> It is likely that nobody will read this file. If you want to allow
> people to modify your stuff faster than the policy above says, put
> this somewhere in ebuilds as a comment. If you want to deny people
> to touch your stuff when they are within the rules, you can't do
> that (e.g. if you will go AWOL, your packages will still need care).

A field in metadata.xml was suggested in another thread [1]. Looks
like proper way to go.

[1] 
https://archives.gentoo.org/gentoo-dev/message/fb62556cfad6b19739e071e4502a27ba

Best regards,
Andrew Savchenko


pgp8_n7BpIqLp.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] linux-info.eclass: get_version: remove useless readlink -f

2016-11-30 Thread Michael Orlitzky

On 11/26/2016 12:47 PM, Mike Gilbert wrote:
> The values get clobbered immediately afterward, so why bother?
> ...
>   qeinfo "Determining the location of the kernel source code"
> - [ -h "${KERNEL_DIR}" ] && KV_DIR="$(readlink -f ${KERNEL_DIR})"
>   [ -d "${KERNEL_DIR}" ] && KV_DIR="${KERNEL_DIR}"
>  

This changes the behavior if $KERNEL_DIR is a symbolic link to a
nonexistent directory, doesn't it?

Re: [gentoo-dev] Step on my toes, please.

Sorry I had to lighten things up a bit

On Wednesday, November 30, 2016 5:53:54 PM EST Andrew Savchenko wrote:
> Hi,
> 
> On Thu, 3 Nov 2016 11:15:07 +0100 Jason A. Donenfeld wrote:
> > Hey guys,
> > 
> > Every other day on IRC, I see people arguing about touching each
> > others packages, despite our policies against it.
> 
> We don't have policies against it, we do have the policy regulating
> it. See section "Touching other developers ebuilds" in the
> devmanual:
> https://devmanual.gentoo.org/ebuild-maintenance/index.html

What about policies for "Developers touching other Developers..." :)
Or staff members.

I was touched at LWE a few times back in the day. Think there is even photo 
evidence of such. I guess I should have filed some complaints. Not sure if my 
toes got stepped on, but I am pretty short, better chance of being run over.

Rather not get into any discussions on if touching was wanted or liked :)

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] [PATCH] linux-info.eclass: get_version: remove useless readlink -f

On Wed, Nov 30, 2016 at 11:28 AM, Michael Orlitzky  wrote:
> On 11/26/2016 12:47 PM, Mike Gilbert wrote:
>> The values get clobbered immediately afterward, so why bother?
>> ...
>>   qeinfo "Determining the location of the kernel source code"
>> - [ -h "${KERNEL_DIR}" ] && KV_DIR="$(readlink -f ${KERNEL_DIR})"
>>   [ -d "${KERNEL_DIR}" ] && KV_DIR="${KERNEL_DIR}"
>>
>
> This changes the behavior if $KERNEL_DIR is a symbolic link to a
> nonexistent directory, doesn't it?

Yes, I suppose it does. Do you anticipate that will cause a problem?

Re: [gentoo-dev] RFC: Userkit.eclass

2016-11-30 Thread james

On 11/30/2016 10:23 AM, William L. Thomson Jr. wrote:

A couple more links, I should have provided initially as they better support
the argument.

First from Debian, I cannot find a list, but it is clearly mentioned.

"0-99:
Globally allocated by the Debian project, the same on every Debian system"
https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2

This is even better, what Gentoo lacks, and could build upon.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/
Deployment_Guide/s1-users-groups-standard-users.html

Also carries to CentOS of course
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-users-groups-standard-users.html

Per previous links installing some RPMs that have fixed UID/GID will result in
problems of other things are using it

"The vdsm user however is fixed to a UID of 36 and the kvm group is fixed to a
GID of 36.
If UID 36 or GID 36 is already used by another account on the system then a
conflict will arise during installation of the vdsm and qemu-kvm-rhev
packages."

https://access.redhat.com/documentation/en-US/
Red_Hat_Enterprise_Virtualization/3.5/html/Installation_Guide/sect-
System_Accounts.html

I appreciate all the discussion on uid-gid as it is central to cluster
provisioning work.

Some Background::

My specific area of development is heterogeneous (hardware) gentoo
clusters with a specific focus on "uni-kernels' (UK). I define UK as a
minimized, optimized hardened kernel that are specifically tuned to a
minimized and optimize framework for a specific problem or specific
category of problem for High Performance Computing (HPC) needs. In fact
the need to benchmark and compare a myriad of codes, such as openstack
on RHEL vs a skinny gentoo solution, on the exact same hardware will
necessitate provisioning from bare metal up to full stack online and
thus require numerous boot cycles. uid/gid symmetry would be a keen
component of to my solutions. One of the challenges I have not worked on
yet, is a systematic and automated solution for a variety of uid-gid
differences between the systems I need to test and compare.

I am not certain that an ebuild or PMS level solution will work for
comparing images(canned solutions from various sources) to a minimized
and optimized gentoo solution. Furthermore, I'd definitely appreciated
any advice and templates/profiles/scripts/etc that facilitate the
automation of uid/gid compatibility for as wide a variety of
kernels+OS+framework at least within gentoo. Note: for me a 'framework'
is vary similar to the world-file. On other distros, a framework is the
sum of additional codes on top of a basic installation of that distro.
Applicability to other major distros, such as *bunu, RH, debian, and
arch derivatives would be keenly useful for my research and development
needs. Furthermore, I believe that docker is just killing the cluster
competition with uni-kernels and a minimized distro such as Alpine. This
is an embarrassment to Gentoo that docker+alpine is 'killing it' in a
space that is natural for Gentoo to dominate, imho.

This is a complex issue, as most of what has already been posted to this
thread are all impactfully true. So flexibility is paramount, imho. In
fact if there is a way, I'd suggest that a multitude of scenarios are
supported to the point that for my work there could easily be hundreds
of variants. The keyword, 'profiles' comes to mind, but that has
additional connotations within gentoo. Surely a robust and automated way
to deal with differences in uid/gid between differing systems (same
distro or not) would be an excellent project. If this is or is not
possible, regardless of whether other distros use this capability, it
would certainly aid folks in migrating other systems
from different distros to gentoo; so that bring enormous value to gentoo
as a distro.

More specifically::

One thing is for sure, uni-kernels are just killing 'canned cluster'
solutions for specific types of problems, particular defined by HPC. I
strongly believe that all of that pioneering work on HPC clustering will
definitely impact routine web/admin/processing venues, eventually.
A given organization will be able to find the optimal images for their
needs and then easily migrate their needs to a wide variety of
datacenters for peak or scale-up. Unikernels in a wide variety of forms,
will enable hybrid clusters and ease the migration of business, web and
other needs between clusters, in a seamless fashion.

A robust and flexible way to automate, orchestrate (overused term I
know) and provision thousands of systems is desperately needed, imo,

and a tool to transparently handle uid/gid differences would be keen.

I want to thank you, for introducing this topic and I tremendously
appreciate all of the comments folks are interjecting, even the terse
comments from admins that need a way to 'turn off' these features.
Ultimately, CoreOS has an automated provis

Re: [gentoo-dev] [PATCH] linux-info.eclass: get_version: remove useless readlink -f

2016-11-30 Thread Michael Orlitzky

On 11/30/2016 11:45 AM, Mike Gilbert wrote:
> On Wed, Nov 30, 2016 at 11:28 AM, Michael Orlitzky  wrote:
>> On 11/26/2016 12:47 PM, Mike Gilbert wrote:
>>> The values get clobbered immediately afterward, so why bother?
>>> ...
>>>   qeinfo "Determining the location of the kernel source code"
>>> - [ -h "${KERNEL_DIR}" ] && KV_DIR="$(readlink -f ${KERNEL_DIR})"
>>>   [ -d "${KERNEL_DIR}" ] && KV_DIR="${KERNEL_DIR}"
>>>
>>
>> This changes the behavior if $KERNEL_DIR is a symbolic link to a
>> nonexistent directory, doesn't it?
> 
> Yes, I suppose it does. Do you anticipate that will cause a problem?
> 

*shrug*

There's a bug there, but who knows what the code was supposed to do. The
docs say that KV_DIR is

   ...a string containing the kernel source directory, will be null if
   KERNEL_DIR is invalid

To me, that makes the "readlink" line the bug, because KV_DIR will be
set even if KERNEL_DIR points nowhere. But then why is the readlink
there? Should KERNEL_DIR support symlinks? (Probably, yes.) If so, the
second test should be something like

  [ ! -d "${KV_DIR}" ] && KV_DIR=""

to undo the previous line when KERNEL_DIR didn't lead anywhere. A better
fix would avoid setting KV_DIR entirely in that case.

Re: [gentoo-dev] RFC: Userkit.eclass

2016-11-30 Thread Michael Mol

On Tuesday, November 29, 2016 04:49:24 PM William L. Thomson Jr. wrote:
> On Tuesday, November 29, 2016 10:40:20 AM EST Michael Mol wrote:
> > Highly detailed lists like that--used as a broad standard--are a bad idea.
> > They represent a single synchronization point that everyone must adhere
> > to.
> 
> That is a statement based on opinion.

Of course. And then I gave examples as to why.

> You say it is a bad idea. I say it is
> necessary and needed. Otherwise wrt to Gentoo ebuilds can stomp on each
> other. Using same GID or UID in more than one ebuild causing problems.
> There has to be something know so others do not use ones others are
> already.

If Gentoo wants to do it internally, that's one thing. But I would recommend 
against inviting other distributions to use Gentoo's list, which was something 
you seemed to be suggesting. Doing so asks that Gentoo shoulder the 
bureaucratic load from other distributions that want things added to Gentoo's 
list.

> 
> > That means that every prospective adjustment to the list requires active
> > maintenance. That means that for every new daemon someone writes, they
> > have
> > to go through an admissions process. For every contentious fork of a
> > project, you risk conflict over who the designated contact for the
> > assignment should be.
> 
> If they package such in Gentoo someone is making a call as to what UID and
> GID should be used. If you think about it from packaging said new daemon in
> Gentoo, it is a MUST.
> 
> If it does not exist, should it be entirely random from the packager
> perspective? What if they use a GID/UID specific to them and not others.
> 
> There has to be some standard some consistency in Gentoo.

If you want to tie this specifically to Gentoo packaging, that's fine. Though 
I'd recommend you put the user and group allocation in the ebuild. Then your 
"list" is trivially generable by parsing portage. Further, you can *enforce* 
these allocations when calculating the dependency tree. If you're not 
enforcing them, what's the point? Is there a benefit without said enforcement?

> 
> > It adds a large bureaucratic load on everyone. Every itch some developer
> > thinks about scratching has to be weighed against engaging with some
> > process- laden entity. Maybe they'll participate, but they likely won't.
> 
> Gentoo shines at bureaucratic load. That may be one of the only things
> Gentoo is really good at, needless bureaucratic loads that just slow things
> down and fracture the community, exherbo, funtoo, and likely others...

I was under the impression that Gentoo was chronically undermanned for even 
the workload it has.

> 
> This is not needless bureaucracy , this is necessary.

Opinion. Why is it necessary? What is it necessary for?

> 
> > Have you watched the IANA ports assignment registry over the years?
> > Consider how many services and tools you've seen that *don't* respect it.
> 
> Yes, how often to ports < 1024 change? Hardly ever Proving the exact
> point why this is needed. People can change them themselves but 99% of the
> time its to some other port > 1024.
> 
> Why is there IANA port assignment registry in the first place? Likely for a
> similar reason.

How relevant even *is* the <1024 distinction any longer? Once upon a time, the 
idea was you had to have special privileges to open those ports. Now, there is 
really no reason for anyone to care; capabilities-oriented permissions 
completely obviated the need, and I can only think of ssh, telnet and ftp and 
as server services that should require special host privileges to 
operate...and that's only because they may need to be able to call setuid().

And because the <1024 port privilege distinction has been so restrictive and 
bureaucratically sloggish, applications adapted to use ports above 1024. 
Games? Sync utilities? Proxy servers? Far more commonly-observed ports are 
above 1024 than below it, and many (most?) don't even get added to IANA's 
list. *That's* why the <1024 ports don't change much; the feature is obsolete, 
and users don't bother.

As an example, I just checked on Syncthing, to see if its three ports were on 
IANA's list. They're not, and I stumbled across a Github issue where the devs 
flatly stated they didn't care.

The IANA ports list is, by and large, obsolete. It became obsolete because it 
was too much a hassle for people to participate in.

> 
> > All of this is why we use identity management tools like LDAP in the first
> > place. Heck, it's why we have passwd and group files for mapping names to
> > ids and didn't simply hardcode system IDs decades ago.
> 
> LDAP typical manages user accounts not system. If the LDAP server is not
> reachable you would make a system completely nonfunctional if it relied on
> LDAP for system accounts.

That's fair. Although I really like how one LDAP alternative operates over 
DNS, permitting local caching. (I can't for the life of me remember the name 
of that system, though.)

> 
> Also needed f

Re: [gentoo-dev] RFC: Userkit.eclass

On Wednesday, November 30, 2016 1:22:07 PM EST Michael Mol wrote:
>
> 
> If Gentoo wants to do it internally, that's one thing. 

This list is about Gentoo internal things

> But I would recommend
> against inviting other distributions to use Gentoo's list, which was
> something you seemed to be suggesting. Doing so asks that Gentoo shoulder
> the bureaucratic load from other distributions that want things added to
> Gentoo's list.

Gentoo cannot force others to do anything. If Gentoo is leading in a 
direction, others choose to follow or not. Gentoo does not set standards that 
would be up to LSB and/or POSIX.

My point is Gentoo should do its own thing, lead the way. Ideally others 
follow and it becomes a standard either in LSB or POSIX. Hopefully that will 
clarify my position.

> If you want to tie this specifically to Gentoo packaging, that's fine.

Which is why it is being discussed on a Gentoo development list and not 
others.

> Though I'd recommend you put the user and group allocation in the ebuild.
> Then your "list" is trivially generable by parsing portage. Further, you
> can *enforce* these allocations when calculating the dependency tree. If
> you're not enforcing them, what's the point? Is there a benefit without
> said enforcement?

As stated, enewuser/enewgroup would utilize such a list/database directly. In 
addition to repoman so issues are prevented before ebuilds are committed.

> > This is not needless bureaucracy , this is necessary.
> 
> Opinion. Why is it necessary? What is it necessary for?

It is necessary so Gentoo base system installs are consistent from one system 
to the next, Just as RHEL and Debian, and likely others. When working with 
large amounts of installs, You want them all to be the same or as close to 
identical as possible. Thus the rise of Docker, CoreOS, etc.

> Oh, I understand the problem, but you haven't explained why your solution is
> the necessary solution to it, or how you would cope with the plethora of
> edge cases I brought up. It would seem there are already many established
> workarounds for the status quo, unstable-UID/GID in a cross-system context.

My solution is to avoid such issues. I start with a common base image. I try 
to ensure anything else installed beyond that, which adds new users/groups is 
the same. At times I will re-image and use that as well for other similar 
systems. Rather than mess with doing the same install to many and trying to 
sync UID/GID.

Think cloning rather than installing.

> But trying to set up a list for everyone to move in lockstep with seems to
> me like a bad way to go.

See my other post, other distros already do this for core system accounts.

> Less bad if you intend to keep it unique to
> Gentoo, but the broader you make the scope, the more strain you'll put on
> the ecosystem as a whole. 

Standards need to exist so there is consistency. In the absence of said 
standard, next best thing you can do is look to what others are doing and do 
the same. Thus I tend to say go with RedHat UID/GID over say Arch, maybe even 
Debian.   But those two likely have larger install bases than most any other 
distro. If the UID/GID are the same between RedHat and Debian, that already 
makes a good deal of systems consistent now.

> More daemons will be build that are intended to
> run as local users. More software will be pushed into opaque blobs a la
> Snap and Flatpack.

I am talking about core system accounts

> As a general rule, the bigger the hassle you make something, the less people
> will want to engage.

When standards exist, others will follow, ideally. When standards do not 
exist, everyone is left to their own way of doing things. IMHO it is less of a 
hassle to comply with standards than all the various ways of doing something.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] RFC: Userkit.eclass

2016-11-30 Thread Michael Mol

On Wednesday, November 30, 2016 01:41:24 PM William L. Thomson Jr. wrote:
> On Wednesday, November 30, 2016 1:22:07 PM EST Michael Mol wrote:
> > If Gentoo wants to do it internally, that's one thing.
> 
> This list is about Gentoo internal things

Here, let me bring up a bit of recent history from your Message-ID 
, which had a signature of 
iEYEABECAAYFAlg8iAQACgkQTXGypIOqM1A2EgCglmZkNYaJ16qQkSxezTqCtI4/
PwoAnR2dW0XUFZk8QUmgrVwu+3OpRxS+
=tuat, which my client indicated matched the key 
0xC47A576A663995BADF1B54724D71B2A483AA3350, but I don't have your key trusted, 
so whatever:

> I believe the main reason such is the case is a lack of any such list or 
> database for others to adhere to. Once again an area Gentoo could be
> leading. 
> Had Gentoo done this years ago others might have adopted.

> IMHO it is something that should be  a part of LSB. If not POSIX in general. 
> One cannot really change the past or current state of things. But can make 
the future better.

> For now who cares about other OS or distros. If Gentoo gets its house in
> order 
> others may follow.

I will note that it's this point when I first replied; that was the point when 
you chose to expand the scope outside Gentoo.

> 
> > But I would recommend
> > against inviting other distributions to use Gentoo's list, which was
> > something you seemed to be suggesting. Doing so asks that Gentoo shoulder
> > the bureaucratic load from other distributions that want things added to
> > Gentoo's list.
> 
> Gentoo cannot force others to do anything.

I didn't say force. I said invite.

> If Gentoo is leading in a
> direction, others choose to follow or not. Gentoo does not set standards
> that would be up to LSB and/or POSIX.
> 
> My point is Gentoo should do its own thing, lead the way. Ideally others
> follow and it becomes a standard either in LSB or POSIX. Hopefully that will
> clarify my position.

As you noted, Arch appeared to attempt this, and others did not follow.

> 
> > If you want to tie this specifically to Gentoo packaging, that's fine.
> 
> Which is why it is being discussed on a Gentoo development list and not
> others.

That's fine. As I pointed out, I only started chiming in when you began 
advocating exporting Gentoo's list to a broader ecosystem.

[snip]

> > > This is not needless bureaucracy , this is necessary.
> > 
> > Opinion. Why is it necessary? What is it necessary for?
> 
> It is necessary so Gentoo base system installs are consistent from one
> system to the next, Just as RHEL and Debian, and likely others. When
> working with large amounts of installs, You want them all to be the same or
> as close to identical as possible. Thus the rise of Docker, CoreOS, etc.

If RHEL and Debian are consistent from one system to the next, obviously it's 
sensical to use their list. But why don't they use each others? Or am I 
missing something, and that's exactly what they're doing?

> 
> > Oh, I understand the problem, but you haven't explained why your solution
> > is the necessary solution to it, or how you would cope with the plethora
> > of edge cases I brought up. It would seem there are already many
> > established workarounds for the status quo, unstable-UID/GID in a
> > cross-system context.
> My solution is to avoid such issues. I start with a common base image. I try
> to ensure anything else installed beyond that, which adds new users/groups
> is the same. At times I will re-image and use that as well for other
> similar systems. Rather than mess with doing the same install to many and
> trying to sync UID/GID.
> 
> Think cloning rather than installing.

Sure. But if you clone a seed node, does it matter that a second from-scratch 
install may not have the same mapping?

[snip]

> > Less bad if you intend to keep it unique to
> > Gentoo, but the broader you make the scope, the more strain you'll put on
> > the ecosystem as a whole.
> 
> Standards need to exist so there is consistency. In the absence of said
> standard, next best thing you can do is look to what others are doing and do
> the same. Thus I tend to say go with RedHat UID/GID over say Arch, maybe
> even Debian.   But those two likely have larger install bases than most any
> other distro. If the UID/GID are the same between RedHat and Debian, that
> already makes a good deal of systems consistent now.

If UID/GID are consistent between RH and Debian, then yeah, what you have is a 
de facto standard, and it would be reasonable to conform, if there are people 
who actually have a need for that cross-system mirroring.

> 
> > More daemons will be build that are intended to
> > run as local users. More software will be pushed into opaque blobs a la
> > Snap and Flatpack.
> 
> I am talking about core system accounts

Who decides what qualifies as a core system account?

If there's any trend I've been able to clearly observe over the last fifteen 
years, it's the grinding of such boundaries into finer and finer granularity. 
Heck, I think there was a thre

Re: [gentoo-dev] RFC: Userkit.eclass

On Wednesday, November 30, 2016 3:08:30 PM EST Michael Mol wrote:
>
> > IMHO it is something that should be  a part of LSB. If not POSIX in
> > general. One cannot really change the past or current state of things.
> > But can make
> the future better.
> 
> > For now who cares about other OS or distros. If Gentoo gets its house in
> > order
> > others may follow.
> 
> I will note that it's this point when I first replied; that was the point
> when you chose to expand the scope outside Gentoo.

Stop making things into something they are not. Re-read the above I said it 
should be part of official standards. I also said others MAY follow...

> > Gentoo cannot force others to do anything.
> 
> I didn't say force. I said invite.

I never typed the word invite. I never mentioned Gentoo being proactive about 
pushing its specific things on others. Please stop making stuff up and going 
way off topic.

> As you noted, Arch appeared to attempt this, and others did not follow.

Arch themselves never got it squared away. It was just a concept. If Arch does 
not implement it how can others? I hardly consider Arch a leading distro like 
RHEL or Debian, which both have derivatives in wide use, Fedora, CentOS and 
Ubuntu.

That right there likely covers over 50% of all Linux installs.

> That's fine. As I pointed out, I only started chiming in when you began
> advocating exporting Gentoo's list to a broader ecosystem.

You are reading things I never typed, and coming up with some far fetched 
scenarios. Nothing you are saying is anywhere near what I wrote.

> If RHEL and Debian are consistent from one system to the next, obviously
> it's sensical to use their list. But why don't they use each others? Or am
> I missing something, and that's exactly what they're doing?

Going back to my first point about this being part of LSB or POSIX. Because it 
is part of neither RedHat and Debian do things differently.

Why does RedHat not use deb format over rpm. Why does Debian use deb instead 
of RPM. These are different distros with different approaches. If their UID/
GID are the same, its likely per legacy reasons. Though they may be looking at 
each other.

Debian at this time does not produce a list. The only I found were RedHat and 
Arch, with Archs' being unofficial and never adopted.

> Sure. But if you clone a seed node, does it matter that a second
> from-scratch install may not have the same mapping?

Yes if they are to be added to the same fleet or cluster of systems. In that 
event it would likely start a new from scratch base image. But that is pretty 
rare. I do update base images, though rarely do system UID/GID change from 
initial install.

> If UID/GID are consistent between RH and Debian, then yeah, what you have is
> a de facto standard, and it would be reasonable to conform, if there are
> people who actually have a need for that cross-system mirroring.

If Gentoo does the same, that would make one other and moving all more in the 
direction of a standard.

> > > More daemons will be build that are intended to
> > > run as local users. More software will be pushed into opaque blobs a la
> > > Snap and Flatpack.
> > 
> > I am talking about core system accounts
> 
> Who decides what qualifies as a core system account?

This is pretty silly now and way off topic. I will leave it to others to 
decide. I would prefer to go beyond just system so it is Gentoo wide. Arch was 
not limited to system stuff, like RedHat and Debian.

Really up to Gentoo Developers to decide it all.

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Developer GitHub usernames

2016-11-30 Thread Michał Górny

On Wed, 30 Nov 2016 01:33:24 -0800
Daniel Campbell  wrote:

> On 11/26/2016 01:08 AM, Michał Górny wrote:
> > On Sat, 26 Nov 2016 00:03:59 -0800
> > Daniel Campbell  wrote:
> >   
> >> 
> >> A funny deficiency of GitHub is it doesn't allow for open conversations.
> >> You're always forced to talk about something directly related to the
> >> code, like an Issue or a Commit. Gists can be somewhat analogous to an
> >> open discussion, but that strikes me as abuse of the medium.
> >> Additionally, it's not a threaded format so it's hard to guess which
> >> branch of conversation you're on.
> >>
> >> Of course sometimes you *want* to focus strictly on the code, but that's
> >> not how real-world organizations work. They're made of people, and most
> >> people end up talking about things *around* the code that are still
> >> important, like the various RFCs that we post here on the ML. None of
> >> what GitHub offers is suitable for that imo.
> >>   
> > 
> > GitHub is a code hosting and review tool, not a forum. It's not
> > a replacement for everything ever invented.
> >   
> The GitHub guys seem to disagree with you; unless you consider custom
> emoji support (and reactions, thumbs-up counts, etc) integral to the
> code review process.

Excuse me but how are your visual feelings even remotely related to
the topic at hand? If you want to troll GitHub, please find
an appropriate forum to do so, and don't spam the mailing list.

> Since you didn't address it, what tone was intended by the quip about
> others "pretending" to not use GitHub?

I'm not going to reply to your provocation.

-- 
Best regards,
Michał Górny



pgpz48AX2rV_J.pgp
Description: OpenPGP digital signature

[gentoo-dev] Please retain authorship of contributed patches

2016-11-30 Thread Andrey Utkin

I'm quite sure this angry rant won't be pleasant to read for anybody,
but still I believe this post serves the good of Gentoo and this issue
is technical enough to be discussed on gentoo-dev. Also gentoo-pr list
seems retired anyway.

This is a second time I've got into a situation when a new ebuild
submitted by me gets to mainline with minimal changes but not retaining
my authorship at all.

First time it was here: https://github.com/gentoo/gentoo/pull/361 and my
rant was endorsed by monsieurp and the committer made excuses.

This time the discussion between me and the committer has never
happened.

My PR: https://github.com/gentoo/gentoo/pull/2765

My bugzilla ticket linked to it:
https://bugs.gentoo.org/show_bug.cgi?id=599088

After my pull request from Nov 6, the following commit gets into mainline:

commit e19f46dfca967f4195eedf3f37a7882fbb37b796
Author: Matthew Thode 
Date:   Tue Nov 15 13:55:17 2016 -0600

dev-python/secretstorage: adding for keyring

Package-Manager: portage-2.3.0


The difference between my submission and final variant by Matthew is big
in number of lines, but is trivial in content as you can see below, so I
don't believe that Matthew has written his variant from scratch on his
own (he hasn't given any note on tickets on bugs.g.o or github), it
seems more like intentional swapping and amending original lines
retaining identical outcome.

Not that authorship of one or two commits is so crucial for me, or that
I'm the most ambitious wannabe-contributor. Hell, there's not much of
code at all in the ebuild - it's trivial; but also not much is needed
here to give credit. I have contributed to quite some FOSS projects, and
have run into theft of my patches a couple of times, and it never was by
pure accident.

I beg affiliated Gentoo developers to stay sane and be thinking not just
about numbers of your commits, but also about community spirit and
relationships. Of course inexperienced contributor gets things not right
first. In such cases, great maintainers fix that and retain original
authorship; good maintainers request for changes and resubmission.

In no way I'm going to drift away from Gentoo because of this issue, no
alternatives around. (I even have a gradually maturing idea to become
Gentoo contributor on regular basis.)

Just for record, a list of projects I've contributed to: FFmpeg, Linux
kernel, VLC, GStreamer, Kamailio, Mcabber, Gajim, v4l-utils.


diff --git a/336a45f661 b/98c5361d66
index 336a45f661..98c5361d66 100644
--- a/336a45f661
+++ b/98c5361d66
@@ -1,19 +1,27 @@
-# Copyright 2016 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
-EAPI="6"
-PYTHON_COMPAT=( python2_7 python3_{3,4,5} )
+EAPI=6
+PYTHON_COMPAT=( python{2_7,3_4,3_5} )
 
 inherit distutils-r1
 
-DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API"
-HOMEPAGE="http://pypi.python.org/pypi/SecretStorage";
-SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
+MY_PN="SecretStorage"
+
+DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API."
+HOMEPAGE="https://github.com/mitya57/secretstorage 
https://pypi.python.org/pypi/SecretStorage";
+SRC_URI="mirror://pypi/S/${MY_PN}/${MY_PN}-${PV}.tar.gz"
 
 LICENSE="BSD"
 SLOT="0"
-KEYWORDS="~amd64 ~x86"
+KEYWORDS="amd64 ~arm64 x86 ~amd64-linux ~x86-linux"
+IUSE=""
+
+DEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"
+
+RDEPEND="
+   dev-python/cryptography[${PYTHON_USEDEP}]
+   dev-python/dbus-python[${PYTHON_USEDEP}]"
 
-RDEPEND="dev-python/dbus-python[${PYTHON_USEDEP}]
-   dev-python/cryptography[${PYTHON_USEDEP}]"
+S="${WORKDIR}/${MY_PN}-${PV}"

Re: [gentoo-dev] RFC: Userkit.eclass

2016-11-30 Thread Michael Mol

On Wednesday, November 30, 2016 03:25:21 PM William L. Thomson Jr. wrote:
> On Wednesday, November 30, 2016 3:08:30 PM EST Michael Mol wrote:
> > > IMHO it is something that should be  a part of LSB. If not POSIX in
> > > general. One cannot really change the past or current state of things.
> > > But can make
> > 
> > the future better.
> > 
> > > For now who cares about other OS or distros. If Gentoo gets its house in
> > > order
> > > others may follow.
> > 
> > I will note that it's this point when I first replied; that was the point
> > when you chose to expand the scope outside Gentoo.
> 
> Stop making things into something they are not. Re-read the above I said it
> should be part of official standards. I also said others MAY follow...

Honestly, that sounded to me like advocacy; "a benefit of doing this is that 
others may follow." If that's not the spirit in which it was intended, I 
apologize.

> 
> > > Gentoo cannot force others to do anything.
> > 
> > I didn't say force. I said invite.
> 
> I never typed the word invite. I never mentioned Gentoo being proactive
> about pushing its specific things on others. Please stop making stuff up
> and going way off topic.

As I note above, I interpreted what you said as advocacy.

> 
> > As you noted, Arch appeared to attempt this, and others did not follow.
> 
> Arch themselves never got it squared away. It was just a concept. If Arch
> does not implement it how can others? I hardly consider Arch a leading
> distro like RHEL or Debian, which both have derivatives in wide use,
> Fedora, CentOS and Ubuntu.
> 
> That right there likely covers over 50% of all Linux installs.
> 
> > That's fine. As I pointed out, I only started chiming in when you began
> > advocating exporting Gentoo's list to a broader ecosystem.
> 
> You are reading things I never typed, and coming up with some far fetched
> scenarios. Nothing you are saying is anywhere near what I wrote.

Again, read above. If that's not how it was intended, I apologize.

> 
> > If RHEL and Debian are consistent from one system to the next, obviously
> > it's sensical to use their list. But why don't they use each others? Or am
> > I missing something, and that's exactly what they're doing?
> 
> Going back to my first point about this being part of LSB or POSIX. Because
> it is part of neither RedHat and Debian do things differently.

You're asserting that Red Hat and Debian do things differently because there's 
nobody to force them to do things the same way. It can't be because there's no 
reference for them to look at; for sure, the second into market could simply 
have looked at the first. It's probable they did.

I know Debian starts their non-system UIDs at 1000, while RH, once upon a 
time, started theirs at 500. Why the difference? Dunno. RH came before Debian, 
so I imagine Debian wanted a bit more headroom to work with. Are there static 
UIDs in the 500-999 range on Debian? That would be why RH doesn't use Debian's 
set; they'd have a UID conflict on their hands.

Staring at a CentOS7 live environment in front of me, it looks like RH now 
starts at 1000.

It's probable they could settle on a common spec now, but there would still be 
a great number of legacy systems out there to support., and you've still got a 
very limited namespace to work with.

> 
> Why does RedHat not use deb format over rpm. Why does Debian use deb instead
> of RPM. 

Well, RPM was developed to be a better alternative to the tarball. Debian 
thought the RPM format was lacking, and developed their own spec. For sure, 
nobody likes to do work for no reason. Even hugely disruptive changes have 
motivations behind them.

I'm sorry, was that a rhetorical question? I just realized...

> These are different distros with different approaches. If their
> UID/ GID are the same, its likely per legacy reasons. Though they may be
> looking at each other.
> 
> Debian at this time does not produce a list. The only I found were RedHat
> and Arch, with Archs' being unofficial and never adopted.

I'll note I'm treating the concept of a list as very abstract; if things are 
consistent, then there's de facto a consistent state that could be distilled 
deterministically into a listing.

> 
> > Sure. But if you clone a seed node, does it matter that a second
> > from-scratch install may not have the same mapping?
> 
> Yes if they are to be added to the same fleet or cluster of systems. In that
> event it would likely start a new from scratch base image. But that is
> pretty rare. I do update base images, though rarely do system UID/GID
> change from initial install.

You know, I would expect for a system of that scale, that you'd have 
standardized and preseeded your passwd and group files with your site standard 
enumerations. It would be trivial to do in any Gentoo install; copy your files 
into place before your initial chroot. All of which you should have scripted 
at this point. If you'd like, I'll send you a link to mine; you can use i

Re: [gentoo-dev] Please retain authorship of contributed patches

2016-11-30 Thread Rich Freeman

On Wed, Nov 30, 2016 at 4:23 PM, Andrey Utkin  wrote:
>
> I beg affiliated Gentoo developers to stay sane and be thinking not just
> about numbers of your commits, but also about community spirit and
> relationships. Of course inexperienced contributor gets things not right
> first. In such cases, great maintainers fix that and retain original
> authorship; good maintainers request for changes and resubmission.
>

++

I'd have to hunt for where it is written down, but it can't be said
enough.  We should definitely be trying to acknowledge the
contributions of others whenever possible.  It is really the only
recognition a lot of "external" contributors get, and it is the least
we can do.  This isn't about copyright or policy or anything like
that, but just a nice thing to do, and there is no "threshold" that
external contributors need to make.

I wouldn't ascribe to malice what is probably just the result of
oversight, but it is a good reminder whatever the case may be...

-- 
Rich

Re: [gentoo-dev] Please retain authorship of contributed patches

2016-11-30 Thread Mart Raudsepp

Ühel kenal päeval, K, 30.11.2016 kell 21:23, kirjutas Andrey Utkin:
> My PR: https://github.com/gentoo/gentoo/pull/2765
> 
> My bugzilla ticket linked to it:
> https://bugs.gentoo.org/show_bug.cgi?id=599088
> 
> After my pull request from Nov 6, the following commit gets into
> mainline:
> 
> commit e19f46dfca967f4195eedf3f37a7882fbb37b796
> Author: Matthew Thode 
> Date:   Tue Nov 15 13:55:17 2016 -0600
> 
> dev-python/secretstorage: adding for keyring
> 
> Package-Manager: portage-2.3.0
> 
> 
> The difference between my submission and final variant by Matthew is
> big
> in number of lines, but is trivial in content as you can see below,
> so I
> don't believe that Matthew has written his variant from scratch on
> his
> own (he hasn't given any note on tickets on bugs.g.o or github), it
> seems more like intentional swapping and amending original lines
> retaining identical outcome.

The diff posted shows almost the maximum amount of differences possible
for an ebuild of this kind imho. There literally is nothing else than
usage of eclasses and listing of depends, and all the spacing and some
order is different even there. If I go and create an ebuild from
scratch without being aware at all of any other ebuild for it being
there and never having looked at either, it would probably be either
identical to yours, or identical to Matthew's.
So I would say it is entirely possible he simply did not know of the
existing work and just created a simple ebuild from scratch.
This work itself is something I wouldn't even consider copyrightable
(as mentioned in some other threads on that topic).

That said, if the existing work was being based on, attribution should
have been done, but that's something only he knows if he looked at your
work or not. He seems to have had to add it as a keyring dep; given
it's simplicity, might have just done the ebuild from scratch in 5
minutes.
At least after (or rather before) doing the work, searching for
existing bugzilla bugs for that package would have been nice.

The first occurrence seems to have more merit for concern, as it is a
recorded fact that your work was looked upon for doing it. However it
does give credit in the commit message (even summary), just no
authorship information towards you in git metadata, as your ideas were
taken and rewritten (new authorship) on top of existing release ebuild
and credited as a link to the PR. For perfection, a Thanks tag or some
other tag towards you (Cc?) by name and e-mail would have been nice,
though.

Overall, it is very appreciated you are contributing, and it does bring
up a topic we should be more careful about in general. Maybe some
documentation and part of quizzes for push access even.
Though the individual cases here brought as example seem not a big
point of concern (in one case a credit was given, in a way; in the
other it might have been very well individual work), but I do think
there could very easily be cases of developers taking someone's work
and not thinking of proper attribution, even if just from not thinking
about it.



Thanks for your contributions!


Mart

Re: [gentoo-dev] RFC: Userkit.eclass

On Wednesday, November 30, 2016 4:38:57 PM EST Michael Mol wrote:
> 
> You're asserting that Red Hat and Debian do things differently because
> there's nobody to force them to do things the same way. It can't be because
> there's no reference for them to look at; for sure, the second into market
> could simply have looked at the first. It's probable they did.

I would recommend doing some research on LSB. If Debian gave up deb for RPM, 
then you would see more unification. Ultimately the two had different origins, 
purposes, and thus can only align on some things but not all.

You can only push standards so far. When you have two different opposing ways 
of doing something. A call has to be made as to which to standardize unless 
you do both. It is impossible to please everyone all the time when it comes to 
consensus stuff. People have different ideas and will accomplish the same 
things in different ways.

Look at the whole systemd thing that came out of RedHat and took over the 
Linux world. It damn near fractured Debian, and did create a fork. Most other 
distros including Debian gave in.

Gentoo is one of the few still offering an alternative OpenRC. Much like the 
UID/GID thing I blame Gentoo for OpenRC not being adopted more widely and 
giving room for things like systemd to take over with little alternative for 
most.

This kind of thing will happen again and again. Though if other distros do not 
start leading. It will become more and more a RedHat lead Linux world. Though 
some things go the other way. RedHat seems to have adopted Debians 
alternatives system, which is basically eselect, and related tools *-config.

But we are way off topic to the userkit.eclass and UID/GID. New thread, but I 
am past the discussion. Thanks!

-- 
William L. Thomson Jr.

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

Re: [gentoo-dev] Please retain authorship of contributed patches

2016-11-30 Thread Sam Jorna

On Wed, Nov 30, 2016 at 09:23:56PM +, Andrey Utkin wrote:
> The difference between my submission and final variant by Matthew is big
> in number of lines, but is trivial in content as you can see below, so I
> don't believe that Matthew has written his variant from scratch on his
> own (he hasn't given any note on tickets on bugs.g.o or github), it
> seems more like intentional swapping and amending original lines
> retaining identical outcome.
> 
> Not that authorship of one or two commits is so crucial for me, or that
> I'm the most ambitious wannabe-contributor. Hell, there's not much of
> code at all in the ebuild - it's trivial; but also not much is needed
> here to give credit. I have contributed to quite some FOSS projects, and
> have run into theft of my patches a couple of times, and it never was by
> pure accident.

Though I wasn't involved in these commits, I have seen how easy and
accidental it is to lose authorship information on a commit. That being
said, finding where to draw the line on authorship can be difficult.

I'm not sure how many others are aware of this, but I'll mention it just
in case: provided it's done before pushing commits, the commit metadata
and message can be amended locally with

  git commit --amend --author="Joe Smith "

This will update the Author tag but leave the Committer tag untouched
(and will allow fixing any problems with the commit message itself).
Amending commits that are not the tip of your local clone will probably
need an interactive rebase though (but I could be wrong about that).

-- 
Sam Jorna (wraeth)
GPG ID: 0xD6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] Please retain authorship of contributed patches

On Wed, 30 Nov 2016 17:17:16 -0500 Rich Freeman wrote:
> On Wed, Nov 30, 2016 at 4:23 PM, Andrey Utkin  
> wrote:
> >
> > I beg affiliated Gentoo developers to stay sane and be thinking not just
> > about numbers of your commits, but also about community spirit and
> > relationships. Of course inexperienced contributor gets things not right
> > first. In such cases, great maintainers fix that and retain original
> > authorship; good maintainers request for changes and resubmission.
> >
> 
> ++
> 
> I'd have to hunt for where it is written down, but it can't be said
> enough.  We should definitely be trying to acknowledge the
> contributions of others whenever possible.  It is really the only
> recognition a lot of "external" contributors get, and it is the least
> we can do.  This isn't about copyright or policy or anything like
> that, but just a nice thing to do, and there is no "threshold" that
> external contributors need to make.
> 
> I wouldn't ascribe to malice what is probably just the result of
> oversight, but it is a good reminder whatever the case may be...
 
One more reason to use merge commits for pull requests: original
author commits with proper authorship will be retained.

Yes, I know that some people are unhappy with non-linear history,
but this is how git works, so there is nothing wrong with merge
commits for user-contributed changes.

Best regards,
Andrew Savchenko


pgpcYPgLN8pRY.pgp
Description: PGP signature

Re: [gentoo-dev] Developer GitHub usernames

On Mon, 21 Nov 2016 10:01:47 +0100 Michał Górny wrote:
> Hi, everyone.
> 
> I've finally found a little time to work on syncing our teams to
> GitHub. For this reason, I've prepared a mapping from Gentoo developer
> names to GitHub usernames:
> 
> https://github.com/mgorny/dev2github/blob/master/devs.json

Error 404 here.
 
> I've filled it based on people in our GitHub developers team. Some of
> the developers are certainly missing there. Since some of our people
> don't want to admit they're using GitHub or otherwise want to pretend
> they're not, and some of the developers are already retiring I didn't
> go forward attempting to find more people.
> 
> Please ping me if you're mapped to an empty string (i.e. no GitHub
> account) and would like to get added to teams on GitHub. I'll invite
> you to the developers team then and add you to the list. Thanks.
> 


Best regards,
Andrew Savchenko


pgpG9PBTxGVyd.pgp
Description: PGP signature

Re: [gentoo-dev] Please retain authorship of contributed patches

2016-11-30 Thread Matthew Thode

On 11/30/2016 03:23 PM, Andrey Utkin wrote:
> I'm quite sure this angry rant won't be pleasant to read for anybody,
> but still I believe this post serves the good of Gentoo and this issue
> is technical enough to be discussed on gentoo-dev. Also gentoo-pr list
> seems retired anyway.
> 
> This is a second time I've got into a situation when a new ebuild
> submitted by me gets to mainline with minimal changes but not retaining
> my authorship at all.
> 
> First time it was here: https://github.com/gentoo/gentoo/pull/361 and my
> rant was endorsed by monsieurp and the committer made excuses.
> 
> This time the discussion between me and the committer has never
> happened.
> 
> My PR: https://github.com/gentoo/gentoo/pull/2765
> 
> My bugzilla ticket linked to it:
> https://bugs.gentoo.org/show_bug.cgi?id=599088
> 
> After my pull request from Nov 6, the following commit gets into mainline:
> 
> commit e19f46dfca967f4195eedf3f37a7882fbb37b796
> Author: Matthew Thode 
> Date:   Tue Nov 15 13:55:17 2016 -0600
> 
> dev-python/secretstorage: adding for keyring
> 
> Package-Manager: portage-2.3.0
> 
> 
> The difference between my submission and final variant by Matthew is big
> in number of lines, but is trivial in content as you can see below, so I
> don't believe that Matthew has written his variant from scratch on his
> own (he hasn't given any note on tickets on bugs.g.o or github), it
> seems more like intentional swapping and amending original lines
> retaining identical outcome.
> 
> Not that authorship of one or two commits is so crucial for me, or that
> I'm the most ambitious wannabe-contributor. Hell, there's not much of
> code at all in the ebuild - it's trivial; but also not much is needed
> here to give credit. I have contributed to quite some FOSS projects, and
> have run into theft of my patches a couple of times, and it never was by
> pure accident.
> 
> I beg affiliated Gentoo developers to stay sane and be thinking not just
> about numbers of your commits, but also about community spirit and
> relationships. Of course inexperienced contributor gets things not right
> first. In such cases, great maintainers fix that and retain original
> authorship; good maintainers request for changes and resubmission.
> 
> In no way I'm going to drift away from Gentoo because of this issue, no
> alternatives around. (I even have a gradually maturing idea to become
> Gentoo contributor on regular basis.)
> 
> Just for record, a list of projects I've contributed to: FFmpeg, Linux
> kernel, VLC, GStreamer, Kamailio, Mcabber, Gajim, v4l-utils.
> 
> 
> diff --git a/336a45f661 b/98c5361d66
> index 336a45f661..98c5361d66 100644
> --- a/336a45f661
> +++ b/98c5361d66
> @@ -1,19 +1,27 @@
> -# Copyright 2016 Gentoo Foundation
> +# Copyright 1999-2016 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  # $Id$
>  
> -EAPI="6"
> -PYTHON_COMPAT=( python2_7 python3_{3,4,5} )
> +EAPI=6
> +PYTHON_COMPAT=( python{2_7,3_4,3_5} )
>  
>  inherit distutils-r1
>  
> -DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API"
> -HOMEPAGE="http://pypi.python.org/pypi/SecretStorage";
> -SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
> +MY_PN="SecretStorage"
> +
> +DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API."
> +HOMEPAGE="https://github.com/mitya57/secretstorage 
> https://pypi.python.org/pypi/SecretStorage";
> +SRC_URI="mirror://pypi/S/${MY_PN}/${MY_PN}-${PV}.tar.gz"
>  
>  LICENSE="BSD"
>  SLOT="0"
> -KEYWORDS="~amd64 ~x86"
> +KEYWORDS="amd64 ~arm64 x86 ~amd64-linux ~x86-linux"
> +IUSE=""
> +
> +DEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"
> +
> +RDEPEND="
> + dev-python/cryptography[${PYTHON_USEDEP}]
> + dev-python/dbus-python[${PYTHON_USEDEP}]"
>  
> -RDEPEND="dev-python/dbus-python[${PYTHON_USEDEP}]
> - dev-python/cryptography[${PYTHON_USEDEP}]"
> +S="${WORKDIR}/${MY_PN}-${PV}"
> 

While I did see your PR and bug if I remember correctly I didn't
actually use your commit or your ebuild to source it.  I added it based
on the bug iirc (which is still waiting on the link it seems).  I should
have mentioned that bug at the very least though and/or worked with you
on the ebuild.

Generally if committing from the community I will cherry-pick, which
does retain authorship.

Again, sorry about not updating the bug or waiting to work with you on
the PR.  If there's something else I can do for this let me know.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Please retain authorship of contributed patches

2016-11-30 Thread Andrey Utkin

On Thu, Dec 01, 2016 at 02:27:17AM +0300, Andrew Savchenko wrote:
> One more reason to use merge commits for pull requests: original
> author commits with proper authorship will be retained.
> 
> Yes, I know that some people are unhappy with non-linear history,
> but this is how git works, so there is nothing wrong with merge
> commits for user-contributed changes.

Hi Andrew,

I don't see this subject as valid reason to prefer merge commits over
rebases. Personally I prefer linear history and rebases.

I had a commercial project in my practice which was based on Github, and
other developers submitted pull requests. My workflow was to rebase the
proposed changes onto mainline branch (which of course preserves
authorship data), push the updated mainline branch to central repo, and
close the PR manually. Not much of work, linear history, git metadata
preserved.

Re: [gentoo-dev] Please retain authorship of contributed patches

On Wednesday, November 30, 2016 9:23:56 PM EST Andrey Utkin wrote:
> I'm quite sure this angry rant won't be pleasant to read for anybody,
> but still I believe this post serves the good of Gentoo and this issue
> is technical enough to be discussed on gentoo-dev. Also gentoo-pr list
> seems retired anyway.
> 
> This is a second time I've got into a situation when a new ebuild
> submitted by me gets to mainline with minimal changes but not retaining
> my authorship at all.

IMHO this is someone Recruiting should be tracking and getting in touch with. 
Recruiting should be proactively looking for contributors and encouraging them 
to become Developers. That way there is no need to proxy and any potential 
issues that can arise from such.

Less contributors, more developers :)

-- 
William L. Thomson Jr.

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

[gentoo-dev] [RESEND PATCH 1/1] kernel-2.eclass: Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.

2016-11-30 Thread Mike Pagano

Round 3. As per mgorny's additional advice, fix eapply_user as per PMS
spec and execute in src_prepare. Support older EAPIs with epatch_user.
export src_prepare only for supported EAPI versions.

---
 eclass/kernel-2.eclass | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 3f5fb3b..547153c 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -90,12 +90,18 @@
 # If you do change them, there is a chance that we will not fix
resulting bugs;
 # that of course does not mean we're not willing to help.

-has "${EAPI:-0}" 0 1 2 3 4 5 || die "kernel-2.eclass is unsupported for
EAPI ${EAPI}"
-
 PYTHON_COMPAT=( python{2_6,2_7} )

 inherit eutils toolchain-funcs versionator multilib python-any-r1
-EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install
pkg_preinst pkg_postinst pkg_postrm
+case ${EAPI:-0} in
+   0|1)
+   EXPORT_FUNCTIONS src_{unpack,compile,install,test} \
+   pkg_{setup,preinst,postinst,postrm} ;;
+   2|3|4|5)
+   EXPORT_FUNCTIONS src_{unpack,prepare,compile,install,test} \
+   pkg_{setup,preinst,postinst,postrm} ;;
+   *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
+esac

 # Added by Daniel Ostrow 
 # This is an ugly hack to get around an issue with a 32-bit userland on
ppc64.
@@ -1260,12 +1266,9 @@ kernel-2_src_unpack() {
# we run misc `make` functions below
[[ $(type -t kernel-2_hook_premake) == "function" ]] &&
kernel-2_hook_premake

-   debug-print "Applying any user patches"
-   # apply any user patches
-case ${EAPI:-0} in
-0|1|2|3|4|5) epatch_user ;;
-6) eapply_user ;;
-esac
+   case ${EAPI:-0} in
+   0|1) kernel-2_src_prepare ;;
+   esac

debug-print "Doing unpack_set_extraversion"

@@ -1305,6 +1308,20 @@ kernel-2_src_unpack() {
fi
 }

+# @FUNCTION: kernel-2_src_prepare
+# @DESCRIPTION:
+# Apply any user patches
+kernel-2_src_prepare() {
+
+   debug-print "Applying any user patches"
+
+   # apply any user patches
+   case ${EAPI:-0} in
+   0|1|2|3|4|5) epatch_user ;;
+   6) eapply_user ;;
+   esac
+}
+
 kernel-2_src_compile() {
cd "${S}"
[[ ${ETYPE} == headers ]] && compile_headers
-- 
2.7.3




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 4

On Wed, Nov 30, 2016 at 8:35 PM, Mike Gilbert  wrote:
> On Wed, Nov 30, 2016 at 7:11 AM, konsolebox  wrote:
 I also prefer some things this way:

 - Indent the contents of the first `if` block for consistency's sake,
 and less confusion.
>>>
>>> I disagree; indenting the entire eclass is silly and does not really
>>> improve readability. Also, this is a very common pattern found in
>>> other eclasses.
>>
>> I prefer following consistency before anything else.  And it's just
>> uncommon and odd, but it's not silly.  Imagine if you use another `if`
>> block on the second level where more functions are defined.  Would you
>> also not indent that?
>
> That first "if" is a bit of a special case; it's only there to prevent
> the code from being executed more than once in global scope. This
> provides a minor speed boost when the eclass gets sourced more than
> once, and makes sure that any global variables are only set once.

OT: inherit() should have already been able to have a non-hacky
solution of making sure that eclass files are loaded only once.  Bash
4.2 has already supported global declaration of variables with -g (in
case the flag variable would need to be declared inside a function),
and associative arrays with -A.  Even older versions of Bash (<4.0)
can make use of multiple variables with a common prefix to imitate
associative arrays if compatibility is needed.  It could just check
BASH_VERSINFO if it has to downgrade to a less-efficient method.

Besides no longer having to rely on a special `if` block, it probably
would also make loading of ebuilds faster since script codes that are
referenced multiple times wouldn't have to be re-parsed again and
again by bash.  It's scary to imagine how it happens in all ebuilds
that's read in portage, but maybe repeated loading of eclass files
doesn't always happen, who knows.  (I think it's still significant
even if the dependencies are already cached.)

> I think of it as being similar to pre-processor statement you would
> find in a C header file; one does not generally indent all the code
> within a C header file, because it just introduces a big chunk of
> whitespace that does not improve code readability.

I did as well, but I'll still prefer to have it indented, because it
avoids trying to know what the last lone `fi` is for, if you haven't
seen the first `if` condition yet.  If they are indented, your mind is
automatically set to know that they are within a conditional block,
and no surprise happens.  Maybe that's not the case if people are
already used to seeing those setup, like in eclass files, but I'm not,
so it does help improve readability in my case.

To be honest I find it painful to see anything inside a block to be
not indented, no matter what the reason is.  You can say that they
look like preprocessors in C, and preprocessors don't make codes
indent, but preprocessors are not (functional) codes, and they are
naturally recognized to have their own "indentation space" or
patterns, unlike the shell's `if`.

But anyway, I think I find it understandable now, in the context of
eclass files.

-- 
konsolebox

Re: [gentoo-dev] [RFC] New version constraints: variant one