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

[Rich Freeman]

On Sat, Feb 4, 2017 at 1:40 AM, Christopher Head  wrote:
>
> Why? It’s just another dependency. Why does DEPEND="dev-libs/bar" work
> so beautifully but DEPEND="dev-libs/bar[baz]" work so horribly? If I
> haven’t explicitly said I want baz, and I haven’t explicitly said I
> *don’t* want baz, and enabling baz doesn’t conflict with any other
> packages I have installed, Portage should just rebuild dev-libs/bar
> with USE=+baz. If I eventually uninstall app-cat/foo, something like
> depclean should reinstall dev-libs/bar with USE=-baz. Just like all the
> other dependencies, if I don’t care to make a manual choice, it should
> be automatic and dynamic.

Yup:

https://archives.gentoo.org/gentoo-dev/message/9049ca48351170013f9b373b5f256e27

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 9:06 PM, Michael Orlitzky  wrote:
> On 02/02/2017 09:00 PM, Sam Jorna wrote:
>>
>> Consider: a new user, coming from Ubuntu or Fedora or Windows, starts
>> building their system. They start installing packages they want, only to
>> find that half of the package isn't there because no USE flags were
>> enabled. They have to enable these flags for almost every package they
>> want because there's no defaults, you must manually specify anything
>> that's not a direct dependency or forced by profile.
>
> Desktop profile!! We have a desktop profile!!! Why is the base
> profile a better location for new-user-with-a-desktop defaults than the
> **desktop** profile?
>

The desktop profile is going to do things like enable X11 support by
default.  It isn't going to do things like enable bzip support in
ffmpeg (but not the new experimental codec that causes it to crash 25%
of the time, but which apparently works great if you use libav
instead), or tools support in tripwire, or e2fsprogs support in
libarchive, or threads support in beecrypt, or any of a million other
things that aren't desktop-specific.  Sure, you can do this with a
bazillion package-specific profile settings, but that is a ton of
cruft for every profile except a minimal profile.

USE settings aren't in some kind of natural heirarchy where desktop
users want them all on and embedded users want them all off.  There
are a million often-orthogonal choices, and anybody could potentially
need any of them, or not want any of them.

Take threads support.as a random example.  There are lots of packages
that default it on, and lots that default it off, and as far as I can
tell none of the profiles change it either way, other than for the odd
package where the preference is arch-specific.  This probably reflects
the feature not being equally stable in all packages, or maybe in some
cases it pulls in heavyweight dependencies where it isn't worth the
tradeoff for a typical user.  Just setting the flag on/off globally
loses all that nuance, which package maintainers have apparently taken
the time to create.  And threads support has nothing to do with
whether you want desktop vs server vs embedded for the most part,
except where it pulls in heavy dependencies, and again that requires
nuance.

I get that there are many people who run Gentoo because it lets them
strip down their systems.  I want to support that as best we can.  I
just don't think that we can just abandon the more typical use case
(IMO) of upstream defaults just to make setting that up a little
easier.  Gentoo enables all kinds of exotic configurations, but it
does so starting from a baseline that is reasonably close to something
like Arch or Debian.  That is a pretty sane place to build off of, but
Gentoo lets you get a lot further away from that faster if that is
what you want.  That is why we use openrc+bash as our starting point
and not busybox.  There are users who swear by busybox mdev and if
they're willing to write the wiki pages to make that work more power
to them, and I'm fine with having that in a virtual/etc to make life
easier on them when that makes sense.  I just think as a baseline it
makes more sense to start out close to where everybody else starts.

If this were just about a few global USE flags in the desktop profile,
that would be a different matter.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 8:40 PM, Michael Orlitzky <m...@gentoo.org> wrote:
> On 02/02/2017 01:01 PM, Rich Freeman wrote:
>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <m...@gentoo.org> wrote:
>>>
>>> If (base == minimal), then all of the upstream defaults need to be added
>>> to package.use for the upstream-defaults profile. That's bad,
>>
>> I'll go further and say that it is unacceptably bad.
>>
>
> Only if anyone wants an upstream-defaults profile. But nobody's asked
> for one, in contrast with the large number of users who want minimal.
>

People already have one effectively, so they're not going to ask.

But, if it makes you happier, I'll ask for one.  :)

If Gentoo didn't have a reasonable way to get mostly upstream
defaults, I probably wouldn't be using Gentoo.

>
>> I still think that we shouldn't encourage users to lightly deviate
>> from all the upstream defaults.
>
> Deviating from upstream defaults is why we have USE flags in the first
> place. No one really wants the upstream defaults, they want
>
>   (nothing) + (what their profile provides) + (what they enable),

Well, I'm somebody, and I want:

(upstream defaults) + (profile settings) + (what I enable) - (what I disable)

I certainly don't set USE=-*, even on my containers.

>
> If dropping an IUSE default hurts some profile, then stick the default
> in that profile. Nothing breaks, and it's not too much work

There are probably thousands of package+USE combinations in IUSE
statements.  Putting these all into a profile is anything but
straightforward.

I don't want globally-enabled/disabled USE flags in my base profile.
I want the settings that make sense for each specific package, which
requires taking the time to evaluate each package.  This is time that
maintainers have already invested.

I personally have zero-interest in minimal systems.  If others want to
set USE=-* that's great for them, and if somebody wants to create a
profile that sets USE=-* and has some per-package exceptions to fix a
few things, that is also great.  If there are cases where we can do
things a little differently to make life easier on these sorts of
users, we should do that.  However, limiting IUSE defaults just to
settings minimally necessary to get a package to build just makes it
impossible to use Gentoo practically without reviewing a bazillion USE
flags.

There is no reason everybody can't have their own way, but IMO it is
much simpler to do this with a minimal profile.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 6:28 PM, james <gar...@verizon.net> wrote:
> On 02/02/2017 04:05 PM, Rich Freeman wrote:
>>
>> The problem is the new user experience.  When somebody is new to
>> Gentoo and not super-knowledgeable the first thing they're going to do
>> is set up a desktop.  Now, they might not call it a desktop.  They
>> might not even run X11 on it.  But, they're basically falling into
>> that desktop user experience where whatever they do install "just
>> works" and is feature-complete.
>
> Nobody give a damn about the
> gentoo noob; that's why it is gentoo policy not to have an installer.
>

No such policy exists, as far as I'm aware.  If one does could you
cite it so that we can strike it down?

As far as I'm aware there is no Gentoo policy about hosting any
particular kind of software, as long as we can legally host it.

> I just do not see your 'either or scenario' as the only possibility.

Then let me clarify that I wasn't proposing anything as an exclusive
option.  I merely think that it makes more sense to specify default
package-specific USE flags in the packages and not in the profiles.
As I posted earlier I'm open to better ways of doing that.

> All I really need is a minimized (a least or very low set of
> packages) profile that is not so concerned with most of the upstream
> projects and the noise found therein.

Sure, and that was basically how I suggested going about it.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 3:35 PM, james  wrote:

>
> I think that unikernels are something everyone should be aware of
> as they purport to be the latest trend in securing all sorts of systems.
> (a brief read).
>

Not really for all sorts, more for servers.  Otherwise I get it, and
at this point now that I run almost everything in containers I tend to
be more inclined to run different distros in those containers.

> This is only the case because profiles are in general in a mess and there
> are little in the way of conventions. What is so sacrosanct about upstream
> for a truly embedded gentoo system or a gentoo based IoT device?

Nothing, in that space.

The problem is the new user experience.  When somebody is new to
Gentoo and not super-knowledgeable the first thing they're going to do
is set up a desktop.  Now, they might not call it a desktop.  They
might not even run X11 on it.  But, they're basically falling into
that desktop user experience where whatever they do install "just
works" and is feature-complete.

It is true that we also attract advanced users who are looking for
something different.  They have no issues getting any distro to dance
for them, and they're picking Gentoo because it is best suited for
their specific need.  These users are much more likely to be
interested in minimal configurations, embedded systems, the hardened
profiles, and so on.

However, the problem is that if we optimize mainly for the second
group we basically lose the first group entirely, and I suspect that
is overall going to be the bigger group.

If what you want is a "unikernel profile" for Gentoo then you're going
to be changing a LOT of assumptions.  Forget openrc vs systemd, there
is no reason to have any init implementation on the thing.  Forget
linux vs bsd, there is also no reason to have a kernel in a container.
We don't need any editor because you're probably going to do any
config file editing from outside of the container.  And that @system
set that has all that bootstrapping stuff is probably way overkill if
all you ultimately need is a single package to work (and maybe not all
of that package).  Heck, your overall install approach also should be
questioned.  Rather than build your unikernel from inside its own
container, you should be building from a more complete image and just
installing the minimum RDEPENDs in the production container (as with
catalyst or the chromiumos builds).  And you probably wouldn't be
upgrading such things in place either, you'd just be creating newer
instances and cutting over from the old.

I don't question that it would be great for Gentoo to support all of
this stuff.  I just think that we need to be careful not to destroy
the experience of somebody who just wants a "typical" install in order
to do it.  Somebody who doesn't want to take the time to tweak how
their java implementation works probably wants the default install to
be something that meets the Oracle standard.  Now, somebody who is
into tailoring can look at their application and tweak the living
daylights out of it, but that shouldn't be what you get when you run
"emerge icedtea" or whatever.

Sure, you could do all that with a profile, but the problem is:
1.  Maintainers aren't going to necessarily invest in that profile.
2.  New users won't necessarily use that new profile.

And when those things doesn't happen users look at Gentoo as the OS
that nothing works right on.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky  wrote:
>
> If (base == minimal), then all of the upstream defaults need to be added
> to package.use for the upstream-defaults profile. That's bad,

I'll go further and say that it is unacceptably bad.

> but if
> (base == upstream-defaults), then the important IUSE defaults need to be
> copy/pasted from our ebuilds into the minimal profile. The latter is
> more spiritually damning =)
>

So, I'll admit I've never been one that cared a great deal about
minimalism so I appreciate that I may not be the best one to judge
this, so let's go ahead and embrace your statement for the purpose of
debate.

Is there a better way we can have our cake and eat it too?  I'll admit
that a huge package.use on the minimal profile isn't a whole lot
better than a huge package.use on all the other profiles.

Do we need another form of syntax in individual ebuilds to try to
separate out the various cases you cite?  Does anybody care to
actually suggest one?

I still think that we shouldn't encourage users to lightly deviate
from all the upstream defaults.  There are of course legitimate
reasons for doing so, and you and I can probably appreciate when we
should do this, but for somebody starting out we're giving them a lot
of rope to hang themselves with.  It is like building a kernel
answering no to the largest number of questions possible while still
actually building something.  I'd actually be curious as to what that
kernel would even be capable of doing (there are a lot of fairly
essential things you can turn off in the kernel).

In the same way, we shouldn't be too quick to deviate from upstream
defaults ourselves (#4 in your example), beyond actual integration
work.

I'll admit the current state is a bit of a compromise, but I don't
think we should change it unless we're changing it to something
significantly better.  This is a pretty big-impact change.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 10:59 AM, Michael Orlitzky  wrote:
>
> The upstream defaults would
> build on top of the minimal base profile, in plain old package.use. In
> the profile is exactly where the upstream defaults belong in an
> "upstream defaults" profile.
>
> I think (base == minimal) is the simpler way to allow both possibilities.
>

Which is simpler, a minimal profile that sets USE=-* and then lists a
few exceptions where that breaks in package.use, or an upstream
defaults profile (which becomes the basis for all the other profiles)
that has a 5000 line package.use file that specifies the upstream
defaults for every package in the repository?

Profiles like desktop/server/etc seem far more likely to end up being
based on the upstream defaults profile than on the minimal profile, so
calling the minimal profile "base" also seems a bit wrong.

It just seems easier to start with an elegantly created set of
reasonable defaults and apply a sledgehammer to it, than start with a
barren wasteland and then try to carefully create a lot of detail on
top.

Also, as has been pointed out in the other subthread, a lot of this
stuff becomes use-case-specific.  I get that people don't want stuff
they don't want, but it often isn't actually based on whether they're
running desktop vs server or embedded vs traditional and so on (which
is also the issue with server profiles in general).  If you want to go
down that road I think mix-ins make far more sense so that you can
have a million very-specific use cases addressed with specific
solutions rather than having everybody arguing endlessly about whether
a "server" needs imagemagick or apache.

-- 
Rich

Re: [gentoo-dev] Guidelines for IUSE defaults

[Rich Freeman]

On Thu, Feb 2, 2017 at 10:36 AM, Michael Orlitzky  wrote:
>
> Why does dev-java/icedtea try to pull in GTK (and thus X)
> on a headless server? That stuff belongs in a desktop profile, not in
> the base one.

The base profile isn't "headless server" - it is just generic.

Somebody could create a headless server profile that set USE=-X and
the necessary tweaks when necessary to handle specific packages.
Having mix-ins would help with this by reducing the costs of adding
profiles so that we can offer more choices like this.

Users can of course set USE=-* if they really want a minimal system,
and build up from there.  However, a minimal profile would probably be
a better solution if somebody wanted to create one.

The problem is that if you treat the base profile as "minimal" then
you lose the ability to maintain an upstream-default profile (unless
you end up with a huge package.use.force/mask file which IMO is the
wrong place to put stuff like this).  I think that upstream-defaults
is a more sensible base than something intended to be minimal.  It is
far easier to let all the packages specify defaults individually and
then make large-scale adjustments (up or down) to these, than to try
to achieve a "default" position from one that just has everything
turned off.

-- 
Rich

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Rich Freeman]

On Tue, Jan 31, 2017 at 9:29 PM, Kent Fredric  wrote:
>
> And we should be keeping the @system essentials set required for new 
> installations
> to be as minimal as possible without losing functionality.
>

Keep in mind that it is pretty safe to put openrc in package.provided,
well, as long as you create one symlink for all the broken packages
that still reference the wrong path for functions.sh.

/me ducks

-- 
Rich

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

[Rich Freeman]

On Sat, Jan 28, 2017 at 8:56 PM, Michael Orlitzky <m...@gentoo.org> 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.
>>
>
> 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.

Honestly, I really will say "so what" here.  :)

Sure, it isn't a perfect solution, but it costs you nothing, and the
fallback is just random UIDs, which as we've already established
aren't a huge problem.  For new installs things will be more
consistent.

It is of course possible to remap UIDs, but I don't think we should
ever try to do this automatically, because only the user can know if
every filesystem that might contain the old UIDs is actually mounted,
or if they mind find killing their drives at the moment, or if
anything important is running under the old uid.

I'm sure somebody will end up offering up a script at some point that
will remap an existing Gentoo install in single user mode to the new
defaults if somebody wishes to do so.

The bottom line is that I think at least picking some defaults is
going to result in a typical new install having matching uids, which
is going to make life easier for small-scale multi-host setups (NFS,
containers, etc).  No, it will never work at the enterprise scale (for
starters, other distros will probably come into play), and it doesn't
matter for a standalone box.  However, just putting a stick in the mud
will give 95% of the benefit for zero additional work.  And the
fallback to random IDs is already implemented anyway.

So, don't try to fix the decades-old boxes.  By now everybody who has
them has beards gray enough to deal with any issues, and they'll have
to have been dealing with them all along anyway.

-- 
Rich

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

[Rich Freeman]

On Sat, Jan 28, 2017 at 2:32 PM, 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.

As far as I can tell there is no Gentoo-specific documentation for
doing this, and from what I have read setting up NFSv4 is a PITA
(perhaps that has changed in recent years).  There are also use cases
that don't involve NFS, such as containers.  From the docs I have
found on idmapd there wasn't actually a lot of detail, it wasn't clear
if it "just works" without any specific configuration, perhaps it
does.

In any case, would it be that hard to set reasonable defaults?

-- 
Rich

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

[Rich Freeman]

On Fri, Jan 27, 2017 at 9:37 PM, Patrick McLean  wrote:
>
> I don't think we need to have stable UIDs/GIDs in the "normal" case of
> standalone users with a single Gentoo system at home.

Of course, but as you point out the enterprise case has more
sophisticated solutions.  I think the case of somebody running in a
home setting or a very small server setting is the main issue.

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.

If it fails, it fails...

-- 
Rich

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

[Rich Freeman]

On Fri, Jan 27, 2017 at 3:09 PM, Michael Orlitzky  wrote:
> My first impression is that any package that doesn't care
> about its UID should default to "first available", but if that causes
> problems, then that's exactly the sort of use case I'm looking for.
>

The ones I listed before were filesystems shared by multiple hosts,
such as with nfs, containers, and chroots.  Granted, there are ways to
deal with this sort of thing, but if you want to share your /var/www
across a bunch of apache servers it would be nice if they all had the
same UID for apache.

-- 
Rich

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

[Rich Freeman]

On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky <m...@gentoo.org> wrote:
> On 01/27/2017 01:52 PM, Rich Freeman wrote:
>>
>> This doesn't really seem like a problem though.  Just have a table
>> somewhere (wiki?) to track who is using what UID/GID and encode those
>> defaults into the ebuild that creates those users.
>>
>
> It should be possible to have two different users with the same UID in
> the tree, just like we can have two different packages that install the
> same file. Eventually somebody will notice a file collision, and then we
> add a blocker per usual.
>

I'm not saying we can't have random assignment for things where it
doesn't matter, or fall back to random assignment, but it seems rather
silly to go to all the trouble to have blockers when it would be just
as easy to not have a conflict in the first place.  Now, if we have
some longstanding issue from the past that might be another matter,
but what's wrong with just picking an unused ID (again, for stuff that
needs it)?

Telling users that they can't have postfix and apache on the same box
because nobody can be bothered to pick IDs that don't collide seems
like an arbitrary imposition.  Sometimes upstream creates conflicts
that are just hard to work around (same SONAME, different ABI or even
API, and so on).  And if we were talking about some binary-only
upstream package that relies on hardcoded UIDs I guess blockers might
be our only option, and users will just have to be happy that we're
able to support it at all.  However, we shouldn't be the ones creating
these kinds of conflicts.

-- 
Rich

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

[Rich Freeman]

On Fri, Jan 27, 2017 at 12:54 PM, Michael Orlitzky  wrote:
>
> You don't really have to care what UID/GID is assigned, because each
> user/group will only be created once and referenced by name (as $PN). By
> default, we could pick the first available UID in most packages.

I might be not following correctly, but due to how filesystems/etc
work it is probably desirable to have consistent UID/GIDs as much as
reasonably possible.  Things like NFS, chroots, containers, and so on
can be a bit simpler if these are consistent, because they involve one
system having visibility into a filesystem hosted on another, and
usually in these cases the UID/GID is what is kept constant, not the
name.  (IMO UID/GID namespace is one of those areas where
Linux/POSIX/etc has some weaknesses.)

This doesn't really seem like a problem though.  Just have a table
somewhere (wiki?) to track who is using what UID/GID and encode those
defaults into the ebuild that creates those users.

Overall I like your proposal.

-- 
Rich

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Rich Freeman]

On Fri, Jan 27, 2017 at 7:06 AM, Dirkjan Ochtman  wrote:
>
> On Fri, Jan 27, 2017 at 8:26 AM, Michał Górny  wrote:
>> I should point out that:
>>
>> 1) CI is detecting this kind of issues much faster than you are,
>> and reporting them both to the committer and to a *dedicated* mailing
>> list, so your mail is completely redundant and delayed.
>
> That sounds like a somewhat better solution, although sometimes it can
> make sense to send email to where the developers are already, rather
> than putting the onus on them to join a separate mailing list.
>

I don't think the idea is to put the onus on people to join a separate
list so much as to give people the freedom to NOT join that list.

Why is it necessary to notify every developer that somebody has not
run repoman?  For everybody who does what they're supposed to do,
there is no lesson to learn, and it is just noise.

For people interested in building tree-wide QA tools or who are
interested in overall trends, then they can mine the list archives.
If they have significant observations they can always post here or on
planet or whatever, and that would have a much higher S/N ratio.

>> 2) Spamming the developer mailing list is completely unprofessional
>> here. If you are unhappy about those mails, just disable them, and stop
>> blaming people for your misery. Trying to prove others incompetent
>> helps nobody.
>
> Come on... I think it's fair game to share news about people breaking
> things on the gentoo-dev mailing list. Naming & shaming can be useful
> sometimes.

I think naming and shaming is a short-term game.  It might have
immediate effects, but it tends to create a culture where nobody wants
to get involved, because they don't want to be the person getting
named and shamed.

We should certainly provide information to people about their errors
so that they can fix them.  We should certainly have this information
available to people making tools that can help people avoid errors,
since error is human nature.  There is no need to hide this
information, but we shouldn't have a culture where we're making it an
emphasis so that we can all go around pointing fingers.

If somebody is a consistent problem and is impervious to attempts to
work with them (whatever the ultimate reason), we don't need to make
them a social pariah until they decide to quit.  We just need to have
QA revoke their commit rights.

I'm a little concerned that stuff like this starts to end up working
like collective punishment.  Fred over here broke the tree, so nobody
gets to have desert or recess today; you all know what to do with Fred
when he's looking to sit next to somebody at lunch and when the bus
drops you off at home later today.

I don't think that was the original motivation; I think frustration
with this being a frequent problem is more the issue and is quite
understandable.  I just don't think this is the right solution.

-- 
Rich

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

[Rich Freeman]

On Mon, Jan 23, 2017 at 4:23 AM, Michał Górny  wrote:
>
> I've written a short proposal that aims to provide basic infrastructure
> for defining mix-in profiles in Gentoo. I've tried to keep it simple,
> and backwards compatible. The main goal is to be able to start defining
> some mix-ins without having to reinvent the whole profile tree.
>

Would it actually make sense to reinvent more of the profile tree
while we're at it?  So, have a few categories of mixins like kernel,
arch, and some category that covers really invasive stuff like
hardened/libc/etc?

Those might be 1-of-n selections.

Then we could have the fluff that sits on top and just set some rules
about what they can do.

Part of me wonders if some of this could also fit in with the use of
virtuals (think foo-meta virtuals but bigger).  A virtual can of
course pull in USE dependencies, and a lot of other stuff.  We could
have convenience virtuals that all the profiles pull in by default but
which gets stuff like openssh out of @system.

I'm only suggesting the last bit to the extent where we see tie-ins to
improve the initial mix-in implementation.  A lot of that is probably
an expansion in scope, and to that extent I'm not suggesting that it
needs to be addressed.  I just want to think about it broadly at first
to make sure we're not missing something.

-- 
Rich

Re: [gentoo-dev] Announce e-mail sending nonsense (Was: Last rites: x11-libs/gtk+:1)

[Rich Freeman]

On Sat, Jan 7, 2017 at 2:41 PM, Mart Raudsepp <l...@gentoo.org> wrote:
> Ühel kenal päeval, L, 07.01.2017 kell 14:18, kirjutas Rich Freeman:
>>
>> Not all replies to gentoo-dev-announce should go to gentoo-dev.  Some
>> belong on gentoo-project, or maybe even gentoo-nfp or some other less
>> common list.  Hence the need to set a reply-to.
>
> 1) It is called gentoo-DEV-announce; there is gentoo-announce for the
> other stuff already.

Actually, gentoo-dev-announce is completely appropriate for things
like Council meeting agenda notices (where discussion goes on
-project), or elections, and so on.  Not all of it is purely
development-related.

>
> Thanks for the history lesson. It is interesting you know that stuff
> about that this was on -core prior to -dev-announce, considering you
> became a developer in December 2007, while gentoo-dev-announce was
> created in July 2007 and the last rites have went there since then.
> (And I have sent last rites since early 2007 at least). Though I'm
> pretty sure this information about last rites to -core is wrong, but my
> memory fades and my old -core is archived up somewhere offline :D
>

Lastrites were on -dev previously I believe.

Many years ago over-use of -core was one of our larger hot-button
topics, and a lot of effort was made to move this sort of traffic
elsewhere.  A lot of it pre-dates my time on the Council.  I don't
personally have archives of what was on -core prior to becoming a dev,
but there had been plenty of discussion around it in general and of
course correct mailing list topics was a subject for new dev quizzes
and such way back then as well.  Gentoo tends to have flares of drama
every couple of years and there had been a bit of a changing of the
guard right before I became a dev, though I was fairly involved well
before then as an AT and general user (think Duncan, who goes back
probably about as far, perhaps further).

As with today a lot gets said in private that doesn't make it onto the
lists, so list archives only really tell part of the story, though
again as with today you can read a lot of it between the lines.

-- 
Rich

Re: [gentoo-dev] Announce e-mail sending nonsense (Was: Last rites: x11-libs/gtk+:1)

[Rich Freeman]

On Sat, Jan 7, 2017 at 2:05 PM, Mart Raudsepp  wrote:
>
> If gentoo-dev feel the need to set Reply-To in my place, then gentoo-
> dev-announce should do the same and not throw my mail into /dev/null,
> but into some regular moderation rules after setting the Reply-To
> itself then.
>

Not all replies to gentoo-dev-announce should go to gentoo-dev.  Some
belong on gentoo-project, or maybe even gentoo-nfp or some other less
common list.  Hence the need to set a reply-to.

Perhaps it should just be called gentoo-announce, though it is mostly
aimed at developers.  In the past people used to send stuff like this
to -core, but that led to a lot of over-use of -core which is private
to devs only.  Now -core is only used very rarely and for the sorts of
things it was intended for (exchanging phone numbers at conferences,
etc), so in that it was a pretty big success and it makes us more
open.

-- 
Rich

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Fri, Jan 6, 2017 at 12:14 PM, Alec Warner  wrote:
>
> So my understanding of the status quo is that maintainers get to make the
> call with regard to what is reasonable to keep or drop. I'm loathe to add
> additional policy here; mostly because the expectation is that the
> maintainer has the most state here. That doesn't mean you can't:
>

I think the main concern is with unmaintained packages.


-- 
Rich

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric  wrote:
>
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
>
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for the purpose of repoman checks, and so packages that depend on
> specific version ranges of packages with BUGS= fields are invalid,
> and need their own BUGS= fields.
>

So, while I'm not sure if this is the best way to go about it, I think
what it does point to is there being possible benefit in creating a
closer link between our repository and bug trackers.

We've seen this come up in managing stable requests as well (having
users be able to vote on things, having automated testing, etc).

With the recent stable changes we have bugs being tagged with "atoms."
 With your proposal we have ebuilds being tagged with bugs.

I can see benefits to having a single way to associate bugs and
ebuilds, and making those associations available to bug trackers and
package managers.

I think the question is:
1.  What is the best way to go about this?
2.  Is anybody actually going to make use of this?

The intended use cases in #2 probably will influence #1.  However, it
doesn't make sense to have multiple ways of doing these associations,
because bugzilla doesn't know anything about the repo, and portage
doesn't know anything about bugzilla.  Having one place to store the
associations and tools to make that information accessible elsewhere
makes more sense.

-- 
Rich

Re: [gentoo-dev] Re: The changes about the stabilization process

[Rich Freeman]

On Tue, Jan 3, 2017 at 6:28 PM, Kent Fredric  wrote:
>
> In that, by making the submitter resolve it all, its either "good" or "bad"
>
> Instead of leaving the person doing the testing in a confused state about 
> which packages
> are expected to be used.
>

Well, assuming that a human is actually the one figuring it out.

But, yes, I agree with your general point the way we do things today...

-- 
Rich

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Tue, Jan 3, 2017 at 11:09 AM, Michael Mol  wrote:
>
> Ideas like this is one reason I'm looking for a corpus of pros and cons for
> treecleaning. I don't see it as black and white. But having ideas like these
> brought up is at least useful.
>

Sure, and almost any rule has its exceptions.  My throwing out my
opinion should be viewed as intended to add to the conversation, not
halt it.  I do think we should have a policy to keep stuff unless
there is a good reason to remove it, but perhaps those reasons extend
beyond the examples I gave.

-- 
Rich

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Rich Freeman]

On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol  wrote:
>
> For security's sake, even mature software needs, at minimum, routine auditing.
> Unless someone's doing that work, the package should be considered for
> removal. (Call that reason #π, in honor of TeX.)
>

Are you suggesting that we should ban any package from the tree if we
don't have evidence of it having recently being subjected to a
security audit?  We might literally have 3 packages left in the tree
in that case, probably not including the kernel (forget the GNU/Linux
debate, we might be neither).

The fact that a project gets 47 commits and 100 list posts a week
doesn't mean that it is being security audited, or that security is
any kind of serious consideration in how their workflow operates.

I tend to be firmly in the camp that a package shouldn't be removed
unless there is evidence of a serious bug (and that includes things
blocking other Gentoo packages).  If somebody wants to come up with a
"curated" overlay or some way of tagging packages that are considered
extra-secure that would be a nice value-add, but routine auditing is
not a guarantee we provide to our users.  The lack of such an audit
should not be a reason to treeclean.

-- 
Rich

Re: [gentoo-dev] Re: The changes about the stabilization process

[Rich Freeman]

On Mon, Jan 2, 2017 at 12:59 PM, M. J. Everitt <m.j.ever...@iee.org> wrote:
> On 02/01/17 17:49, Rich Freeman wrote:
>> On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric <ken...@gentoo.org> wrote:
>>> On Thu, 29 Dec 2016 17:23:58 +
>>> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
>>>
>>>> Because it isn't... Are set names atoms? Are package names without an
>>>> associated category atoms?
>>> Sets /are/ still dependency specifications, in that reading, just like
>>> || ( ) groups are dependency specifications, and lists of atoms are 
>>> dependency specifications.
>>>
>>> Hence, this is an example of in my mind why "atom" is a *better* descriptor 
>>> than "dependency specification"
>>>
>>> Because it rules out sets and all the other shenanigans.
>> However, in this case why would we want to rule out sets, "and all the
>> other shenanigans?"  We've already established that a single stable
>> request bug can apply to multiple package-versions, so why not allow
>> full dependency specifications?  If there is a set that describes what
>> needs to be stabilized in an atomic operation, then what is the value
>> in breaking it down into a million separate =-only atoms?
>>
>> If the process becomes further aided by automated tools then using the
>> same dependency specifications as PMS/etc would allow the same code to
>> be used to identify candidate PVs to stabilize.
>>
>> Of course in the most typical case you're stabilizing exactly one PV,
>> but I'm not sure we need to limit the syntax simply because that is
>> all that is required in the most common case.
>>
> I don't think we're writing new tools to do this, we're simply using the
> existing ones better. So, a list of explicit ebuilds by
> Category/Package-Version is what's desired (I believe). But I'll defer
> to kensington/ago who are the ones really using this system in anger ...
>

Even if you don't write new tools, I don't see how sets would cause a
problem.  A set is just a list of dependency specifications, which is
what we're otherwise storing.  There is no rule against putting 100
specific package versions in either.  If you have a set that describes
something like a KDE stabilization I'd think that this would be
preferable to listing all the KDE packages in the box.

But, if somebody can see a problem this would cause I'm all ears.

-- 
Rich

Re: [gentoo-dev] Re: The changes about the stabilization process

[Rich Freeman]

On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric  wrote:
> On Thu, 29 Dec 2016 17:23:58 +
> Ciaran McCreesh  wrote:
>
>> Because it isn't... Are set names atoms? Are package names without an
>> associated category atoms?
>
> Sets /are/ still dependency specifications, in that reading, just like
> || ( ) groups are dependency specifications, and lists of atoms are 
> dependency specifications.
>
> Hence, this is an example of in my mind why "atom" is a *better* descriptor 
> than "dependency specification"
>
> Because it rules out sets and all the other shenanigans.

However, in this case why would we want to rule out sets, "and all the
other shenanigans?"  We've already established that a single stable
request bug can apply to multiple package-versions, so why not allow
full dependency specifications?  If there is a set that describes what
needs to be stabilized in an atomic operation, then what is the value
in breaking it down into a million separate =-only atoms?

If the process becomes further aided by automated tools then using the
same dependency specifications as PMS/etc would allow the same code to
be used to identify candidate PVs to stabilize.

Of course in the most typical case you're stabilizing exactly one PV,
but I'm not sure we need to limit the syntax simply because that is
all that is required in the most common case.

-- 
Rich

Re: [gentoo-dev] The changes about the stabilization process

[Rich Freeman]

On Mon, Dec 26, 2016 at 5:05 AM, Andrew Savchenko  wrote:
> On Mon, 26 Dec 2016 20:49:02 +1300 Kent Fredric wrote:
>> On Sun, 25 Dec 2016 22:55:27 +0300
>> Andrew Savchenko  wrote:
>>
>> > 
>> >   Description how to test this package...
>> > 
>>
>> Alternatively, why not have a metatag that just
>> permits a valid URL that points to testing instructions?
>
> Sounds good, as long as it is not mandatory, so if dev wants to put
> instructions in this block (e.g. they are small or can't be shared
> with other packages).
>

Well, test instructions would never be mandatory, and if you wanted to
recycle them I think the best move is to put them on the wiki and just
post the URL in metadata.

The advantage here would be that automated tools would know where to
find them.  Maybe one day they could be auto-linked in bugs,
integrated into some keywording non-bugzilla tool, into portage/gatt,
and so on.

-- 
Rich

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Rich Freeman]

On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt  wrote:
>
> I do, but only usually if its the last package of an emerge because
> otherwise its lost many many thousands of lines upwards. Thank goodness
> for portage's savelog feature. - Actually that reminds me .. someone
> mentioned a useful tweak to that, with an appropriate FEATURES switch,
> it would categorise the output of the logging system .. must look that
> one up again, or poke the wiki team ...
>

IMO, emailing elogs to root should probably be the default.  By all
means let people turn it off, but I bet a lot of people don't realize
it is an option.

This goes in all my make.conf files:
PORTAGE_ELOG_CLASSES="warn error log"
PORTAGE_ELOG_SYSTEM="save mail"
PORTAGE_ELOG_MAILURI="a...@a.com smtp.server.address"
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"

Yes, some packages are a bit spammy and this should be fixed, but in
general it has prevented more headaches than it has caused.

-- 
Rich

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Rich Freeman]

On Sun, Dec 4, 2016 at 11:24 PM, A. Wilcox  wrote:
>
> The original intention wasn't to guess, but I see how PMS is more for
> things that are determined at run-time by the package manager rather
> than static variables.
>

To be clear, PMS is more about package manager behavior, and what
you're defining is more of a repository convention.  You don't need
any special behavior in the package manager to handle these cases, it
is more a matter of repository QA.  It isn't just stuff that is
determined at run-time, but anything that directly impacts the package
manager (such as *DEPEND and so on, which isn't usually set at runtime
but which obviously impacts what gets installed).

A GLEP would be a great way to formalize this IMO, though I'm not
certain it is essential.

Here is a separate thought.  Would it make sense in any way to try to
have a more established way to communicate with our downstream distros
about stuff like this, like a gentoo-derivatives mailing list or such?
 I wouldn't restrict access or anything like that, but participants
would be expected to stay on-topic (it isn't another gentoo-dev or
gentoo-user/project).  Changes could still make their way onto the
main lists.  I was just thinking that we don't really have any
official way to notify downstream distros of changes like these.

-- 
Rich

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[Rich Freeman]

On Sat, Dec 3, 2016 at 5:09 PM, William L. Thomson Jr.
 wrote:
> There is also the charitable donation and write off aspect. Which they may be
> able to do. But since Gentoo has never received official 501c6 status or any
> from the IRS. I am not sure if companies or anyone can actually write off a
> Gentoo donation. May be moot for individuals, but not for large businesses
> with stringent accounts and standards to meet.
>

Actually, it is the opposite.  When you spend money as an individual
in the US it normally doesn't lower your taxes unless there is some
special tax deduction for it, such as the mortgage interest deduction.
One of those deductions is donations to 501c3/etc status.  So, there
is a benefit to an individual when donating to a 501c3 organization
(or other deductible classes) because it lowers their tax burden.

On the other hand, businesses are only taxed on their profits at the
federal level.  So, if a business takes in $500 and spends $400 then
it is taxed on $100.  That $400 could be spent on almost anything as
far as I'm aware.

So, money given to Gentoo by a private business is the same as money
spent on toilet paper or money thrown in the furnace as far as tax
liability goes.  It increases expenses which means it decreases
profits.

Now, where 501c3/etc status does start mattering for businesses is
internal compliance controls.  Most publicly traded companies have
standards for how money can be spent, because that money belongs to
the shareholders.  I work for a publicly traded company and I can't
just treat myself to a new car and expense it, because that deprives
the shareholders of their profits, even if the US government wouldn't
otherwise have a problem with it from a tax perspective (as long as I
declare the value of that car on my own taxes as income).  In order to
keep things simple companies often use 501c3 status as a requirement
for donations.  This eliminates debates about whether a particular
cause is or isn't a valid charity to donate to for the purposes of
goodwill/etc because the IRS acts as an unbiased filter.  501c3 also
implies financial controls on how the money gets spent, so there is
less of a risk that somebody is directing money towards a recipient
who ultimately is going to offer some kind of kickback, because that
would be illegal for the 501c3 and the IRS would enforce that (from a
tax perspective the kickback probably isn't illegal for the original
donor company, but from a shareholder responsibility standpoint it is
a misuse of funds for employees to basically be giving money to
themselves).

So, if your goal is to be the beneficiary of corporate philanthropy,
then I'm sure 501c3 status will help.

Another source of donations might be other 501c3 foundations.  The FSF
might give money to a FOSS-only linux distro, for example.  In such
situations they're almost always going to donate purely to other 501c3
organizations, because they need to ensure the money is spent on
charitable purposes to meet their own IRS requirements.

Now, companies probably also make investments that aren't intended to
be philanthropic.  A company might give money to a trade association
in exchange for some kind of benefit, or it might just give money to
an association to support their which which somehow benefits the
company.  I suspect a business that benefits from Gentoo more directly
probably wouldn't care so much about the tax-exempt status because the
donations are being justified on the basis of being a business
investment of sorts.

So, yes, the status matters, but not actually for tax reasons
themselves in most cases.  It is more of a marker of how the money
gets spent.

I used the term 501c3 just to keep this simple, but there are other
classifications in the tax code which could also apply to an
organization like Gentoo and generally be treated similarly.

If somebody is a corporate tax accountant and wants to offer a finer
explanation it is welcome, but this is the gist of it as I understand
things.

-- 
Rich

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Rich Freeman]

On Sat, Dec 3, 2016 at 9:47 AM, William L. Thomson Jr.
 wrote:
> On Saturday, December 3, 2016 9:33:00 AM EST Michael Orlitzky wrote:
>> On 12/03/2016 09:25 AM, William L. Thomson Jr. wrote:
>> >> This is generally considered infeasible:
>> > I would not think such, just need a wrapper to run around each package
>> > that
>> > would get its USE flags and re-emerge it a few times.
>>
>> If a package has 10 USE flags, and if each can be set on/off with no
>> constraints, then that gives you 2^10 different ways to emerge it.
>
> May make the requirements of the host system larger or take more time.  I am
> sure processing power could handle that load.
>
> Would be nice if someone like Google would sponsor such efforts. They have
> enough hardware and cloud services to make such feasible.
>

Have you given thought to how long it would take the largest
supercomputer in the world to rebuild libreoffice once for each of the
2^28 USE flag combinations it has (not including USE_EXPAND)?

It is certainly possible, but I doubt that you're going to get it
dedicated to Gentoo for a few weeks whenever one of its deps changes.

This is not a reason to give up on tinderboxing.  This is just a
reason to be realistic about just what it will do.

-- 
Rich

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[Rich Freeman]

On Sat, Dec 3, 2016 at 9:20 AM, William L. Thomson Jr.
 wrote:
>
> Which was one of the last articles Gentoo mentioned in on Distro watch, till I
> believe the OnHub router. Based around that topic, quoting Ciaran.
>
> http://distrowatch.com/weekly.php?issue=20070312#future
>
> Most interesting about that article. If you read the last two paragraphs. I
> think some of that could be said about the state of things still.
>

Sure, and it probably will be the state of things 20 years from now,
with Gentoo still having "little chance that even the minimum of
release and bug-fixing goals will be met" and suffering a "rapid
downfall of the distribution" :)

The predictions of those paragraphs have not in fact come to pass.

Would you agree that "if a person who repeatedly engages in personal
attacks against other developers is permitted to remain with the
project, then there is something wrong with the way the distribution
is managed?"

I find it a bit interesting that half of this article is about a
failure to enforce a Code of Conduct that you don't actually think we
ought to have, and that drobbins left in part because it wasn't being
enforced.

Sometimes forks exist because individuals don't get along or have
strong ideas for how things should work to the exclusion of other
ideas of how things should work.  That's fine, there is nothing wrong
with forks.

The current meta-structure of Gentoo is structured around the vision
that Gentoo is a place where people can make what they want of it, and
the governance bodies of Gentoo are mostly about dealing with
conflicting goals, not picking winners.  Sure, the Council could take
a much more pro-active stance and say "Gentoo needs to be the best
distro for xyz so we should get rid of all this Java crap" but that
would be silly because the two aren't mutually exclusive and telling
people to not work on Java isn't going to magically inspire them to
work on something else instead.

-- 
Rich

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Rich Freeman]

On Sat, Dec 3, 2016 at 9:08 AM, William L. Thomson Jr.
 wrote:
> On Friday, December 2, 2016 2:10:27 PM EST Michał Górny wrote:
>> Hi, everyone.
>>
>> I've heard multiple times about various tinderbox projects being
>> started by individuals in Gentoo. In fact, so many different projects
>> that I've forgotten who was working on most of them.
>
> Did any of the tinderboxes test all the various USE flag combinations or just
> the defaults?
>

This is generally considered infeasible:

https://blog.flameeyes.eu/2009/06/a-tinderbox-is-not-enough-reprise/

I think continuous integration with tinderboxing is a really solid
idea.  However, I'm not under any illusions that it will involve
testing every package with every possible set of USE flags.  IMO
testing with the defaults of a few common profiles is probably
sufficient, and mgorny's CI approach of just doing repoman checks is
already a value add.  I can't remember the last time I ran into a
silly lack-of-repoman issue because they don't exist in the tree I
sync from, but it is obvious that many users still run into them
because this is not present in the official rsync mirrors (at least
the manifest issues have been sorted out).

-- 
Rich

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[Rich Freeman]

On Sat, Dec 3, 2016 at 9:00 AM, William L. Thomson Jr.
 wrote:
> OT, who runs Gentoo
> On Saturday, December 3, 2016 12:21:55 AM EST Daniel Campbell wrote:
>
>> There's also our downstream neighbors: Funtoo, Pentoo, Sabayon,
>> Calculate, Exherbo, etc
>
> Two of those are more of a splinter of the Gentoo community, Exherbo and
> Funtoo. IMHO those communities should be reunited into Gentoo. Allot of talent
> got driven way that is still out there working on other stuff.
>

Uh, you do realize that the main force behind one of those projects
left because of the main force behind the other project?

https://lwn.net/Articles/225060/

-- 
Rich

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

[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] Re: Stabilisation procedure

[Rich Freeman]

On Sun, Nov 27, 2016 at 5:56 AM, Raymond Jennings  wrote:
> On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi  wrote:
>>
>> What about maintainers that are away without writing it in their
>> maintainer bug ?
>> After how many days of no replay can be fair to touch their package ?
>
> If a developer lapses long enough and doesn't use devaway properly to mark
> any waylaid packages as touchable...then that's probably an example of an
> even bigger fish to fry that undertakers would handle anyway.

A maintainer can be actively doing other work and still not respond to
a stable request bug.  The only thing the undertakers could do about
it is get rid of them, which stops the work they were actively doing
and doesn't make the situation with the bug they were ignoring any
better.

Are devs supposed to ignore stable request bugs?  No.  Has anybody
come up with a way to make them not do it?  Unfortunately not.  Part
of the issue is that some devs are just somewhat antisocial and prefer
to do their own thing.  For the most part as long as they're not
actually actively making trouble for others we tend to accept this,
since the only visible change to getting rid of them is less stuff
getting done (the stuff they passively ignored still ends up being
passively ignored).

This is why we tend to favor procedures that don't block progress by
default.  Just set a timeout.  If the maintainer doesn't respond
within x days then stabilization can proceed.  Maybe make an exception
for @system.  We do similar things when devs want to touch each
other's packages; if you don't get a response the assumption is that
you can just go ahead.

-- 
Rich

Re: [gentoo-dev] rsync.gentoo.org rsync modules: ChangeLogs dropped from gentoo-portage

[Rich Freeman]

On Thu, Nov 17, 2016 at 4:48 PM, Kent Fredric  wrote:
> On Thu, 17 Nov 2016 20:57:26 +
> "Robin H. Johnson"  wrote:
>
>>  - eg metadata.xml (nothing for user systems is impacted by it, other
>>than to give output about packages).
>
> Idle thought: Given there are classes of vulnerabilities related to XML
> parsing and decoding, any systems that attempt to read this file should
> ensure a it "good" before doing so.
>
> But I don't really know the specifics of XXE vulns, only that I saw a
> few in the last few months.

Keep in mind that at some point it is vulnerabilities all the way down.

How do we make sure the xml file is good?  Well, lets read the hashes
from a manifest, and check them.  Except, that means parsing a
manifest file using a parser that might have a vulnerability, and it
requires calculating a hash on a file and the hash utility might have
a vulnerability.  Oh, and how do you know those helper programs are
still intact? Better check their hashes against a manifest too, which
just requires parsing a manifest file and using a hash utility...  :)

I'm not against file integrity checks, of course, but at some point if
you have an xml parser with a vulnerability you're probably going to
want to fix that...

-- 
Rich

Re: [gentoo-dev] Re: tmpfiles virtual

[Rich Freeman]

On Thu, Nov 17, 2016 at 4:58 PM, Martin Vaeth  wrote:
>
> For instance, the systemd-tmpfiles implementation has some
> features concerning btrfs which are not (yet) supported by
> opentmpfiles. Some users might want to use that features.
>

Well, this was the main reason I suggested that we could just use
systemd-tmpfiles.  It is essentially everybody's reference
implementation already.  But, if somebody wants to re-implement it
that is their right, and certainly the virtual is the way to go about
it.

-- 
Rich

Re: [gentoo-dev] tmpfiles virtual

[Rich Freeman]

On Thu, Nov 17, 2016 at 3:07 PM, Ian Stakenvicius  wrote:
>
> Realistically, software should ensure the directories it needs at
> runtime are created through their own code, but upstreams are lazy and
> so they don't bother because, hey, we can have this tmpfiles.d *.conf
> file to have the system do it for us!

This isn't really being lazy.  This is just not re-inventing the
wheel.  If there is a standard way to ensure that directories are set
up correctly (especially if they're volatile, or you have a
first-time-every-time scenario like a container) then why not use it?

It certainly makes more sense than a bunch of shell code in a unit
file (which then must be duplicated in an init.d script), or having
the program run as root, create directories, and then drop privs.

It was less of an issue when things were less volatile.  However the
trend in servers especially has been towards volatility.  Every boot
basically is the first boot.  A lot more stuff ends up on a tmpfs as
well.

> In those cases, we'd need that rdepend.

I tend to agree with this thinking.  If the package needs these
directories at runtime, and the tmpfiles.d config is the mechanism to
create it, then the package has a runtime dependency on a program that
will do what it says.

That said, I'm not 100% on this as this is a bit of an unusual
situation.  This is generally boot-time configuration so you have a
package run-time dependency on a package being there at boot time.  It
isn't exactly the typical sort of requirement.


-- 
Rich

Re: [gentoo-dev] Re: Stabilisation procedure

[Rich Freeman]

On Thu, Nov 17, 2016 at 8:13 AM, Michael Palimaka  wrote:
>
> Just to be clear, I'm not advocating banning runtime testing. I just
> think that, considering the state of the stable tree, we should consider
> very careful in which situations we actually gain value from it. That's
> for another thread, however. I deliberately worded the document so that
> the final decision on the exact level of testing required (runtime or
> otherwise) is between the person filing the stabilisation request and
> the person actioning it.
>

++

-- 
Rich

Re: [gentoo-dev] Re: Stabilisation procedure

[Rich Freeman]

On Thu, Nov 17, 2016 at 4:37 AM, Michael Palimaka <kensing...@gentoo.org> wrote:
> On 17/11/16 20:16, Rich Freeman wrote:
>> On Thu, Nov 17, 2016 at 2:16 AM, Michael Palimaka <kensing...@gentoo.org> 
>> wrote:
>>> * A leaf package such as {{package|kde-apps/kcalc}} may not require any
>>> runtime testing at all
>>
>> I'm not really a big fan of this, but if we REALLY didn't want to do
>> any runtime testing on a package then we should have some way to tag
>> the package as such, and then have some way to do automated
>> build-test-only stabilization.  If you aren't doing runtime testing
>> then manual stabilization adds zero value.
>
> How much value do you think we gain from runtime testing a package like
> kcalc as part of the stabilisation process, considering that it already
> sat in ~arch for at least 30 days?

We ensure that it actually runs at all with non-~arch dependencies?

The 30 days spent in ~arch tells you very little about whether the
package works with stable dependencies, since only those running mixed
keywords would be testing that.

>
> Also, based on conversations with various arch team members, my
> understanding is that a lot of stabilisations that happen right now are
> already build-only.
>

Certainly this isn't the documented process and it is the first I've
heard of this.

I think one of two things make sense:

1.  Manual runtime testing followed by stabilization.
2.  Automated build testing followed by stabilization, with no human involved.

What doesn't make sense is manual build testing.  The person is adding
zero value.

>>
>> Overall though the writeup was good and maybe it will trigger some
>> discussion.  I tend to think that if we want to do things like testing
>> permutations and such then automated build-only tools might be the way
>> to address this.  Manual effort should be focused on things like
>> runtime testing where it adds the most value.  This also strikes me as
>> the sort of thing that could probably be assigned out to volunteers
>> who do not have commit access.
>
> There's a few tools for this out there already. I've personally been
> working to update app-portage/tatt for git - see
> https://asciinema.org/a/cqsy983t9jimszvypcjr3zg5m for a demo.
>

Assuming we decide we don't care about runtime testing (which I'm not
sure I'm a fan of), it sounds like the only thing this is missing is:
1.  Running as a service on Gentoo infra without any person at the keyboard.
2.  Automatically monitoring the bug queue for anything that can be
stabilized, taking into account blockers/dependencies/etc.
3.  Posting failures to the bug, and then removing that bug from the
queue until somebody marks it as ready to go back in.
4.  If there is a success updating the bug (including closing if the
last arch) and doing the commit using an infra account.

However, I'd be interested in metrics on failures discovered in
runtime testing and so on, or missed with a lack of runtime testing.
I'll admit that a lot of runtime testing tends to be fairly shallow,
but I do think there is something to be said for doing some kind of
runtime testing.

I think we need to think about why we actually have a stable branch.
Does it offer any value if all we do is build testing, when I'm sure
the maintainers at least build their packages in ~arch before they
commit them?

-- 
Rich

Re: [gentoo-dev] Stabilisation procedure

[Rich Freeman]

On Thu, Nov 17, 2016 at 2:16 AM, Michael Palimaka  wrote:
>
> In cases where all USE flags combinations are not being tested, it is
> still recommended to test:
> * with all USE flags enabled
> * with all USE flags disabled
> * the default USE flag settings
>

I imagine that in practice only the last of these really tends to get tested.

> * A leaf package such as {{package|kde-apps/kcalc}} may not require any
> runtime testing at all

I'm not really a big fan of this, but if we REALLY didn't want to do
any runtime testing on a package then we should have some way to tag
the package as such, and then have some way to do automated
build-test-only stabilization.  If you aren't doing runtime testing
then manual stabilization adds zero value.

Overall though the writeup was good and maybe it will trigger some
discussion.  I tend to think that if we want to do things like testing
permutations and such then automated build-only tools might be the way
to address this.  Manual effort should be focused on things like
runtime testing where it adds the most value.  This also strikes me as
the sort of thing that could probably be assigned out to volunteers
who do not have commit access.

It really seems like the sort of thing that could be managed by
something other than bugzilla.  Some tool finds out about packages
that ought to be stabilized (probably via multiple methods), then it
triggers the automated build tests/etc that do a lot of the low-level
QA, and if the package looks good it gets queued for runtime testing.
Then volunteers report in on status and when whatever criteria we
establish is met then the tool stabilizes the package, probably in a
dependency-aware fashion.  Obviously this would require some care for
coordinated packages like xorg/DEs/etc, and it might not be the
preferred approach for many system packages.

-- 
Rich

Re: [gentoo-dev] tmpfiles virtual

[Rich Freeman]

On Wed, Nov 16, 2016 at 6:45 PM, Ian Stakenvicius  wrote:
> On 16/11/16 06:25 PM, William Hubbs wrote:
>> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>>> On 16/11/16 06:16 PM, William Hubbs wrote:
 On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
> On 16/11/16 03:21 PM, William Hubbs wrote:
>>
>> I can make the service scripts call the systemd-tmpfiles service if it
>> is available or if not call the opentmpfiles implementation.
>>
>> I'm not sure whether it is worth having a separate package for the
>> service scripts in this case.
>
> That would depend on where the service scripts are sitting, I guess --
> do you mean here that openrc will keep its current tmpfiles.dev and
> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
> RDEPEND or PDEPEND on virtual/tmpfiles ?

 No, those scripts will be removed from OpenRC. If you grep through
 OpenRC, you will see that once they are removed, they are never actually
 referred to by any other services that are part of OpenRC.

 The scripts will be put in opentmpfiles and that ebuild will install
 them.

 William

>>>
>>> Then we're back to the exact same issue.  opentmpfiles won't be
>>> installed if systemd is installed, so the scripts won't get installed.
>>
>>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>>  same way udev-init-scripts is.
>
> Wait, so you're going to require systemd have a PDEPEND on
> opentmpfiles, so that OpenRC doesn't need to have one, when it's
> openrc that needs the script files that opentmpfiles installs??
>

I agree, this doesn't make sense.

If systemd-tmpfiles can work when systemd isn't running I could see an
argument for having systemd install init.d scripts to run it (it seems
strange, but it wouldn't be so strange if it weren't bundled).  Of
course you still run into a collision with opentmpfiles if both are
installed at once, unless they use different script, or the init.d
scripts can run either and are installed in a split package.

But, it definitely doesn't make sense to have systemd depend on opentmpfiles.

But, if systemd-tmpfiles can run without systemd I don't get why
everybody is in such a rush to basically re-implement it.  That isn't
really a problem though, if somebody wants to code another 
that isn't a problem.

-- 
Rich

Re: [gentoo-dev] tmpfiles virtual

[Rich Freeman]

On Tue, Nov 15, 2016 at 10:49 AM, Dustin C. Hatch  wrote:
> On 2016-11-14 23:09, Michał Górny wrote:
>> On Mon, 14 Nov 2016 18:23:10 -0600
>> William Hubbs  wrote:
>>
>>> Hi all,
>>>
>>> I have been working on splitting the tmpfiles functionality out of
>>> OpenRC [1], and I believe the new package is about to enter the tree.
>>>
>>> OpenRC itself doesn't need this package to boot since it doesn't use
>>> tmpfiles.d files, but other software does need it.
>>>
>>> This brings up a couple of questions.
>>>
>>> Since we now will have two different ways to process tmpfiles, is
>>> virtual/tmpfiles appropriate, with the default being opentmpfiles?
>>
>> Yes. Virtual will allow us to control list of supported implementations
>> easily. We can also use it to control different versions of tmpfiles
>> format.
>>
>>> Once opentmpfiles is in the tree and stable, should virtual/tmpfiles
>>> be added to @system, or should we have the packages that need it rdepend
>>> on it directly? I tend to lean toward the second option.
>>
>> We will RDEPEND on it via tmpfiles.eclass. I think floppym has a draft
>> somewhere. In case that draft uses DEPEND, it just occurred to me that
>> we need RDEPEND for pkg_postinst().
>>
>
> What about administrator-specified temporary files in /etc/tmpfiles.d?
> It would be rather unfortunate to have stuff suddenly stop working
> because an OpenRC got updated and stopped creating these temporary files.
>

Does it create them today?  I thought this was a new feature addition.
If it does then news should cover that situation, and the admin can
just add either the virtual or the preferred implementation to their
@world.

-- 
Rich

Re: [gentoo-dev] tmpfiles: call for testers

[Rich Freeman]

On Wed, Nov 9, 2016 at 8:30 AM, Mike Gilbert <flop...@gentoo.org> wrote:
> On Wed, Nov 9, 2016 at 2:11 AM, Zac Medico <zmed...@gentoo.org> wrote:
>> On 11/08/2016 10:44 PM, Daniel Campbell wrote:
>>> On 11/08/2016 05:02 PM, Rich Freeman wrote:
>>>> On Tue, Nov 8, 2016 at 7:54 PM, Patrick McLean <chutz...@gentoo.org> wrote:
>>>>> On Tue, 8 Nov 2016 17:41:02 -0600
>>>>> William Hubbs <willi...@gentoo.org> wrote:
>>>>>>
>>>>>> The plan, once the first release is out, is to rewrite this utility
>>>>>> in a better language. I'm considering C, but if I am comfortable by
>>>>>> that time in Go or Rust, I may use one of them.
>>>>>>
>>>>>
>>>>> For a low-level utility that is likely going to be in the default
>>>>> @system set, please use C. Adding dependencies on the go or rust
>>>>> compilers for this is not very nice.
>>>>>
>>>>
>>>> Assuming I'm looking at the right sources, the actual systemd
>>>> implementation is only 2342 lines of C.  Glancing at the includes, I'm
>>>> not convinced it even requires systemd to run.
>>>>
>>>> You might want to take a look at either just creating a split ebuild,
>>>> or tweaking it to work standalone if necessary.
>>>>
>>> Is that including any headers and/or libraries shared by the systemd
>>> umbrella?
>>>
>>
>> It has a huge list of includes for internal libraries, from acl-util.h
>> to util.h:
>>
>> https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c
>
> Also, it is linked against libsystemd-shared.so, which is a 2.1 M blob
> on my system. For comparison, libc-2.23.so is 1.7 M.
>

My understanding is that this is a once-and-done executable, not a
daemon.  I won't debate that it probably could be refactored or redone
in a smaller overall package.  However, the only real cost to it being
large is disk space use, a miniscule amount of additional load time
(we are talking about an rc solution coded in bash, which has tons of
load time penalties), and a few MB or RAM during the short time that
it is running.

Don't get me wrong.  I don't have a problem if somebody wants to take
the time to basically rewrite it.  But, you're probably going to spend
a lot of time chasing edge cases with compatibility with an upstream
moving target.  I'm sure a lot of the tmpfiles.d features are rarely
used, but do you really want to end up hosting debates over whether
you really need btrfs subvolume support, POSIX ACL support, xattr
support, age-checking and cleanup, support for machine IDs, and so on?

In any case, my goal was to toss the option out there, either as a
short-term or long-term solution.  You have a working implementation
that probably could get the job done with minimal effort to adapt it,
and it is the same implementation virtually every other distro is
using and which is well-maintained upstream.  Now, I haven't tried to
run it under openrc and there could be some fatal flaw in the
suggestion. But, I probably wouldn't be deterred by a couple of
libraries.

-- 
Rich

Re: [gentoo-dev] tmpfiles: call for testers

[Rich Freeman]

On Tue, Nov 8, 2016 at 7:54 PM, Patrick McLean  wrote:
> On Tue, 8 Nov 2016 17:41:02 -0600
> William Hubbs  wrote:
>>
>> The plan, once the first release is out, is to rewrite this utility
>> in a better language. I'm considering C, but if I am comfortable by
>> that time in Go or Rust, I may use one of them.
>>
>
> For a low-level utility that is likely going to be in the default
> @system set, please use C. Adding dependencies on the go or rust
> compilers for this is not very nice.
>

Assuming I'm looking at the right sources, the actual systemd
implementation is only 2342 lines of C.  Glancing at the includes, I'm
not convinced it even requires systemd to run.

You might want to take a look at either just creating a split ebuild,
or tweaking it to work standalone if necessary.

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab update

[Rich Freeman]

On Fri, Nov 4, 2016 at 11:48 PM, Christopher Head <ch...@chead.ca> wrote:
> On Thu, 27 Oct 2016 10:25:39 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>
>> It would be nice if standards like USB incorporated some kind of GUID.
>> I ended up having to write a udev rule for a pl2303 RS232 adapter to
>> tie it to a specific USB port precisely so that I could have more than
>> one and know which one talked to which device.
>>
>> I'd argue that the udev network interface names were a better (if
>> painful to transition to) solution to a problem created by somebody
>> else.  Being able to use wildcards in configuration files is probably
>> an adequate solution for those who are using a single device.
>>
>
> You mean like a device serial number? Which is totally part of the USB
> standard, but many devices don’t bother to include one because they
> would have to be serially programmed in the factory? If your device has
> a serial number, you can generally see it as a udev attribute and use
> it to set up meaningful persistent names for multiple
> otherwise-identical devices.

++
Though stuff like this is why sometimes it makes sense to make things
a required part of the standard.  If the device had access to some
source of randomness perhaps it could at least flash one on first
powerup.  Of course the only thing that would be worse than not having
a unique ID would be having a unique ID that isn't unique...

-- 
Rich

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Rich Freeman]

On Fri, Nov 4, 2016 at 8:30 PM, M. J. Everitt  wrote:
> Apologies, getting ahead of myself here .. there must be a portage
> utility, but I've forgotten which one interrogates metadata .. I'll
> defer to a more authoritative source ...
>

There might be a command line utility if you're doing things the shell way.

But, from that python script I linked the relevant part is:

from portage.xml.metadata import MetaDataXML

metxml = path+"/"+category+"/"+pkgname+"/metadata.xml"
maints=[]
try:
  pkg_md = MetaDataXML(metxml,"/usr/portage/metadata/herds.xml")
  for maint in pkg_md.maintainers():
  maints.append(maint.email)
except IOError: pass

Just feed that api call with a metadata.xml.  Hopefuly it works with
the projects.xml syntax as herds.xml is of course defunct.I'd
check the portage API docs as there might be some improvements there.

The portage api is actually fairly powerful and far superior to a lot
of stuff that gets done with grep.  It just needs a bit of time
getting used to it since there aren't a lot of docs/examples/etc
floating around.  The script that came out of was designed to find
packages that depend on packages that expose subslots but which don't
define slot operator deps.  Granted, not everything in that list
should be using them, and by now I imagine it is almost entirely false
positives, but it shows the sort of thing you can do with a couple of
lines of python that would be an incredible pain to do any other way.
I believe paludis also exposes some APIs that probably could also be
used.

-- 
Rich

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Rich Freeman]

On Fri, Nov 4, 2016 at 7:54 PM, Jonas Stein  wrote:
>
> If you maintain one of these packages, please fix the SRC_URI and
> HOMEPAGE variables.
>

It would probably be better if the output included the maintainer.
Hopefully this isn't using anything deprecated, but you should be able
to steal from this:
https://github.com/rich0/finddepslotops/blob/master/finddepslotops.py

Somebody else might have something more up-to-date to use.

-- 
Rich

Re: [gentoo-dev] Optimizing toe stepping

[Rich Freeman]

On Thu, Nov 3, 2016 at 5:36 PM, William L. Thomson Jr.
 wrote:
> On Thursday, November 3, 2016 9:14:56 AM EDT William Hubbs wrote:
>>
>> I am also in favor of the metadata approach.
>
> Also it may start inching things towards restricting areas of the tree to said
> members of teams etc. Which starts to go in the opposite direction of Gentoo's
> roots of wide open access.

Actually, the default right now is somewhat restrictive.  I advocate
this mainly because it will probably tend to open things up.  By
default today you aren't supposed to just go touching things without
pinging somebody, and that is probably a reasonable default, but
having an easy way to open things up where it makes sense is a good
idea.

-- 
Rich

Re: [gentoo-dev] Revisiting version-related tree policies

[Rich Freeman]

On Thu, Nov 3, 2016 at 1:44 PM, Ian Stakenvicius <a...@gentoo.org> wrote:
> On 03/11/16 01:20 PM, Rich Freeman wrote:
>>
>> Let's just hope nobody starts using tex version numbering and so on.
>> Dates might be used in cases where upstream doesn't publish sane
>> revisions (in fact, texlive versions are dates, albeit at the year
>> level).
>>
>> I'm not saying this isn't a good idea, I just could see where it might
>> crash into reality at some point.
>>
>
> This is just the revision portion though, that's not part of the
> version number from upstream.  IIRC, the revision is meant to only be
> used for gentoo ebuild changes, isn't it?
>

Correct, I intended to comment on the version, not revision.  However,
the 18 digit limit could still become an issue there with pathological
cases like Tex (which basically communicates 1 bit of information in
each digit it adds).  I still don't think it makes sense to design
things around seemingly-clever converging numbering schemes.

-- 
Rich

Re: [gentoo-dev] Revisiting version-related tree policies

[Rich Freeman]

On Thu, Nov 3, 2016 at 12:11 PM, Michał Górny  wrote:
>
> 1. Revision number must be no longer than :
> 1a. to make <=X-r reliable,
> 1b. to prevent pathological uses of revision as date.
>

Let's just hope nobody starts using tex version numbering and so on.
Dates might be used in cases where upstream doesn't publish sane
revisions (in fact, texlive versions are dates, albeit at the year
level).

I'm not saying this isn't a good idea, I just could see where it might
crash into reality at some point.

-- 
Rich

Re: [gentoo-dev] Optimizing toe stepping

[Rich Freeman]

On Thu, Nov 3, 2016 at 9:45 AM, Ian Stakenvicius  wrote:
>
>
> Although metadata.xml is one way to do this, since it is more of a social 
> thing than a technical one I think it might be better to wikify it instead -- 
> each dev can list their "please fix my package" preferences in a per package 
> or per anything-with-them-as-maintainer spec in one location.
>

I tend to think that metadata is the right place for a couple of reasons:

1.  Somebody who discovers an ebuild with an issue/etc is probably
sitting right in the directory with the metadata file, so the
information is readily at hand.
2.  If somebody was going to have to reach out to the maintainer, the
metadata file would tell them who the maintainer is (both in terms of
projects and individuals).
3.  The file could potentially contain package-specific maintenance
information.  Sure, you can stick a page on a wiki that says "for
rich0 in general feel free to touch anything, but be aware that mythtv
upstream is picky about xyz, and be aware that the android sdk has
issue xyz, ..."  For somebody with their fingers on a lot of packages
you could end up either writing a book, or just leaving it all out
which could result in people making the same mistakes over and over,
or devs might just opt out of having others touch their stuff because
it is too much of a PITA to explain it all.  With the metadata
approach you only define package-level detail.  So, if one package is
hands-off, then you simply state so or fail to give permission to
touch it.  You could provide other background that is relevant to the
specific package.

I think the main issue is where to put it in the schema.  For the
proponents I'd suggest just putting a stick in the mud and see if
anybody complains.

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 2

[Rich Freeman]

On Tue, Nov 1, 2016 at 2:44 PM, William Hubbs <willi...@gentoo.org> wrote:
> On Tue, Nov 01, 2016 at 02:14:43PM -0400, Rich Freeman wrote:
>> On Tue, Nov 1, 2016 at 1:53 PM, William Hubbs <willi...@gentoo.org> wrote:
>> > On Tue, Nov 01, 2016 at 01:30:56PM -0400, Mike Gilbert wrote:
>> >> On Tue, Nov 1, 2016 at 1:22 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> >> > On Tue, Nov 1, 2016 at 12:52 PM, William Hubbs <willi...@gentoo.org> 
>> >> > wrote:
>> >> >>
>> >> >> here is the new version of this news item.
>> >> >>
>> >> >
>> >> > Shouldn't this be conditional based on openrc being installed?  I
>> >> > don't think other rc implementations are impacted.
>> >> >
>> >>
>> >> +1
>> >>
>> >> It would also be nice if the title had "OpenRC" in it, so that people
>> >> booting with systemd can more easily ignore it.
>> >
>> > Well, this is sort of a gray area, because the recommendation to use the
>> > new fstab syntax is in the fstab man page as well as being in the newest
>> > baselayout example fstab, so it really applies everywhere [1].
>> >
>>
>> The man page does not suggest that this is a preference over using
>> udev device names.  It only says they're preferred over the
>> traditional device names which are subject to change, which is
>> obviously good advice.
>>
>> It makes sense that they wouldn't mention udev device names since
>> those are udev-specific.  It doesn't mention recommendations for lvm
>> either, which makes sense since that would be udev-specific most
>> likely.
>
> I was wrong in the man page I mentioned. Check out the mount man page.
> I don't see there where it says that tags are only preferred over
> traditional device names.
> But, it is sort of unclear I suppose. It says that the preferred
> setup is the tags (UUID=, LABEL=, etc, but in the same paragraph it says
> that mount internally uses the udev symlinks if they are there. What it
> doesn't explain is what mount does if they aren't there, but I know it
> does work either way.

Well, considering that it goes on to say that it just uses the udev
names anyway, I'd say that the result is the same either way.

It seems that the mount manpage authors seem to prefer the UUID=
syntax and so on.  I don't think systemd even runs the mount binary; I
believe it just uses the system calls. So, I don't think it is really
all that relevant.

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 2

[Rich Freeman]

On Tue, Nov 1, 2016 at 1:53 PM, William Hubbs <willi...@gentoo.org> wrote:
> On Tue, Nov 01, 2016 at 01:30:56PM -0400, Mike Gilbert wrote:
>> On Tue, Nov 1, 2016 at 1:22 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> > On Tue, Nov 1, 2016 at 12:52 PM, William Hubbs <willi...@gentoo.org> wrote:
>> >>
>> >> here is the new version of this news item.
>> >>
>> >
>> > Shouldn't this be conditional based on openrc being installed?  I
>> > don't think other rc implementations are impacted.
>> >
>>
>> +1
>>
>> It would also be nice if the title had "OpenRC" in it, so that people
>> booting with systemd can more easily ignore it.
>
> Well, this is sort of a gray area, because the recommendation to use the
> new fstab syntax is in the fstab man page as well as being in the newest
> baselayout example fstab, so it really applies everywhere [1].
>

The man page does not suggest that this is a preference over using
udev device names.  It only says they're preferred over the
traditional device names which are subject to change, which is
obviously good advice.

It makes sense that they wouldn't mention udev device names since
those are udev-specific.  It doesn't mention recommendations for lvm
either, which makes sense since that would be udev-specific most
likely.

I haven't really seen anything that suggests that using udev device
names is in any way a deprecated behavior.  It just doesn't work
reliably by default with openrc.  And that is fine, but this hardly
seems like a util-linux issue.

The simple solution is to have it display only if openrc is installed
and make mention that this pertains to users of openrc.  In practice
the former won't help as much until we fix the functions.sh bugs but
it still makes sense to do it.

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 2

[Rich Freeman]

On Tue, Nov 1, 2016 at 12:52 PM, William Hubbs  wrote:
>
> here is the new version of this news item.
>

Shouldn't this be conditional based on openrc being installed?  I
don't think other rc implementations are impacted.

-- 
Rich

Re: [gentoo-dev] Gentoo on Android stage3

[Rich Freeman]

On Sat, Oct 29, 2016 at 12:22 PM, Benda Xu  wrote:
>
> Homework received.  I have little experience blogging though.
>
> I will need first to set up a blog and then draft a writeup.
>
> Any hints?

Gentoo can set them up, or you can just use Wordpress or whatever
(Gentoo wasn't taking new blog request when I set it up).  I suggest
keeping it simple.

If you need help with proofreading/etc you can always ask pr@, or one
of us I'm sure.

-- 
Rich

Re: [gentoo-dev] Gentoo on Android stage3

[Rich Freeman]

On Sat, Oct 29, 2016 at 11:42 AM, M. J. Everitt  wrote:
> On 29/10/16 16:35, Benda Xu wrote:
>> No SD slot on Nexus.  We will stress the internal NAND flash with
>> millions of ebuilds and rsync :)
>>
>> That makes me think of squashdelta sync, but probably after gaining
>> control of linux kernels to manage the squashfs module.
>>
> Completely out of my depth here, but can you cross-compile and is there
> some way of leveraging the USB-C connection on the Nexus 6P .. or are we
> talking super-complex then?!
>

Well, that would be a different approach, but I imagine you could
build for prefix-style install using something like Catalyst and
cross-compile.  I have no idea how much tweaking that would require.
The main issue is that unless you use qemu you're only going to get
one pass.  If you are going to use qemu then you could just build it
all in an emulator and copy it over.

You definitely could create a squashfs of /usr/portage and then just
mount that on your phone.  You could also nfs mount it I suppose, or
use something like iSCSI (you might need kernel modules for both).  Or
use something like sshfs.  I've also used a compressed ram filesystem
for this purpose in the past (basically like a tmpfs only compressed,
often used as a high-priority swap).

And of course if you can spare the RAM you can build in tmpfs.

So, there are definitely some "easy" options though some of them will
cost performance.

Another option might be USB OTG.  I think the 6P supports that with
the right drivers.  As long as it isn't noexec I'd think you could
install Prefix on that.

-- 
Rich

Re: [gentoo-dev] Gentoo on Android stage3

[Rich Freeman]

On Sat, Oct 29, 2016 at 11:18 AM, M. J. Everitt  wrote:
> On 29/10/16 16:14, M. J. Everitt wrote:
>> On 29/10/16 16:09, Benda Xu wrote:
>>>
>>> This is an announcement of the latest Gentoo on Android stage3 tarball,
>
> Actually .. given my nosiness in -pr matters lately, anyone done a
> write-up for Planet.g.o or suchlike that we can post up to social media?
> From my own stand-point it might be something the wider community would
> be interested in, and didn't know was a 'thing'?
>

It would be a good thing, especially since this relies on Gentoo
Prefix (I think), which is a fairly unique capability I've yet to see
in any other distro.

-- 
Rich

Re: [gentoo-dev] GLEP RFC: Third-party contributions

[Rich Freeman]

On Fri, Oct 28, 2016 at 12:49 AM, Daniel Campbell  wrote:
> On 10/27/2016 06:13 AM, Michał Górny wrote:
>>
>> So yes, it would probably be enough to put such a simple statement
>> somewhere. The problem is: where? ;-) GLEP seemed like a
>> straightforward solution to make it global.
>>
>
> Could it be relevant on the git workflow page? I consult that on a
> regular basis (it's even in my watch list), and accepting/pushing
> contributions seems like it's right in line with our expected git workflow.
>

I think that the git workflow page is probably a good place to
consolidate developer-focused (or serious-contributor-focused)
information.  I don't think it is a great place to point outside
contributors.

An external contribution has a few parts:
1.  External contributor submits contribution.
2.  Somebody makes sure it is good.
3.  The contribution makes it into a repository official branch.

Part 3 and possibly part 2 might belong on that git workflow page.  I
think part 1 really needs to be on a "how to contribute" page that is
really focused on outsiders.

Of course, having an overall git workflow that is inclusive of both
internal and external contributions where it comes to the actual
Gentoo dev doing the commits seems like a good idea.

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab update

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:23 PM, Gregory Woodbury  wrote:
>
> This is not unlike the kerfufle that occurred when systemD was introduced
> not so long ago. To use it folks had to make major changes to their systems
> that took several months to iron out the kinks.  Additionally, some of the
> folks
> pusing the change seemed to have a bad attitude about not caring that what
> they did had unintended consequences. (Enough so that Linus had some bad
> words for them!)

Are you maybe referring to some of the udev changes like persistent
network interface names?  Systemd was never pushed out as a default
and switching over to it isn't a huge ordeal but it is certainly a
VERY deliberate one.

The exchange between Linus and Kay concerned an issue that only
happened when you were actually running systemd.  It certainly
wouldn't impact any Gentoo user who didn't intentionally switch, or
users of just udev.

As far as I'm aware the udev changes were very well communicated using
news, and users were given options both for adapting to the change or
blocking the change from taking place.  This is a fairly typical way
of handling something like this in Gentoo; we've never really been a
distro that automatically takes care of things if you don't read news.

Other distros can be a bit more auto-magic because they restrict the
user's options.  When I set up a Gentoo box I need to pick my
preferred network manager and configure it.  When I go installing some
other distro the interfaces all come up auto-magically, but if I want
to tweak something I end up having to hunt endlessly to figure out how
that distro does things, and try to make my tweaks in a way such that
the package manager won't revert it on the next update.  I also
suspect that after I'm done all my tweaks the next time the distro
does some auto-magic updates (such as after something like the udev
change) I'll end up having to re-tweak things as it steps all over me.

And that is the benefit and cost of using Gentoo.  You get to do
things your way, and we know you're going to do it your way, so we try
to warn you and equip you when things change and not step all over
you.  However, it does limit the sorts of things we can automatically
update for you, because we have no idea how you've set it all up.  We
give you the tools when you install your system, and we give you the
tools when it is time for renovations...

-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:27 PM, Kent Fredric <ken...@gentoo.org> wrote:
> On Thu, 27 Oct 2016 09:21:06 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>
>> I'm not saying you can completely avoid the need for having some kind
>> of bootstrapping stage1.  I'm just saying we should separate that need
>> from the issue of fully specifying dependencies, at least in an ideal
>> world where we're unconcerned with the effort of specifying
>> dependencies.
>
> I think you could partially solve this by having gentoo-built binaries
> of things that are needed for bootstrap shipped as sys-devel/gcc-bin,
> or similar.

Well, for gcc that would probably work, though I think it would make
more sense to just have a binary package of gcc and not a different
package under a different name.  I'd actually extend that to other
-bin packages we already have, like libreoffice-bin (assuming we build
that ourselves).  For the case of an upstream binary the distinction
is probably worthwhile, but for a package we build ourselves it makes
a lot more sense to just let portage build a binary package and
install it.

However, this still wouldn't eliminate the need for a stage1 set
because just to install a binary package you do need a small number of
components, like portage, bash, glibc, tar, bzip2, and so on.

I believe the way catalyst works is that it uses the host system to
build the stage1 packages and install them into the chroot.  Then from
there it can run inside the chroot to build stage2 and stage3.  All
the packages are built fresh, but the stage1 is built in the host
environment, not the target environment.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 8:08 PM, Daniel Campbell  wrote:
>
> With a DCO, it greatly complicates things. Would my right to keep my
> contributions in an overlay be infringed upon? What would change if we
> switch to this?
>

The DCO doesn't change your rights at all, or change the status of the
copyright.  It is simply a declaration that the code is
redistributable under the appropriate license.  While we don't have a
DCO in place currently, it is already policy that devs are supposed to
check the license.

The FLA does change the status of the copyright/licensing situation.
However, this will be voluntary, so if it concerns anybody they simply
can choose to sign it.  However, under the FLA if you do assign
copyright to Gentoo then in accordance with the agreement Gentoo will
give you the right to redistribute your code in perpetuity without
restriction (if I'm reading it correctly).  Essentially you'd be
giving Gentoo the right to re-license the code under another FOSS
license or pursue copyright claims, but you still will be able to do
most of the things you could do if you had retained copyright.

Both practices are actually very standard in the FOSS world.  The DCO
is used by Linux and numerous other projects and is generally
considered a best practice for any project.  The FLA is less commonly
used, but I know that KDE uses it.  It is probably more common in
community products especially in Europe, since it is designed to
handle the German case.  I'd say that a CLA is a more common practice,
especially in projects that are dual-licensed with a commercial
backer.  The CLA is a much stronger transfer of the rights of the
contributor to the project and usually gives the project a blank check
to do whatever they want with the code, such as making it exclusively
closed-source in the future.  This is obviously desirable to
corporate-backed projects as it gives them more options to extract
money from the code.

The DCO basically is an extra assurance that our copyrights are sound.
The FLA is a way to give Gentoo more options for relicensing code and
such, but in a way that is more compatible with our social contract
and which probably also makes us a less attractive hostile takeover
target (since the FLA would limit the sorts of bad things somebody
could do with our copyrights if they managed to seize them).

Honestly, I think the policy actually does simplify things for the
most part by making a lot of things explicit where currently they are
vague and where a variety of opinions prevail.  However,
simplification was never really the main goal of the policy.  It is
more about not getting sued and being more flexible the next time
somebody decides to fork something like udev without starting a
fiasco.

Since she hasn't promoted it herself, I'll point out that alicef has
wikified the policy here:
https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy

I'll go ahead and make some of the tweaks mentioned in the thread, and
maybe try to improve the attribution overhead which I think is the
only real downside.  I think if it were implemented the contents of
that page would probably be split up a bit as it combines very static
information (the policy) with things like the table of licenses which
obviously will be updated frequently.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 11:21 AM, Ulrich Mueller  wrote:
>
> I would conclude that the intention is that the whole of the Linux
> kernel can be distributed under the GPL, version 2, unless noted
> otherwise.
>

Stepping back, I'd just like to comment that while I hold an opinion
on this that is likely different from gregkh, and possibly the Linux
Foundation, I suspect this is going to be moot since as far as I can
tell we aren't modifying the DCO and don't really think we need to.
So, it is probably simpler to avoid controversy by just incorporating
it by reference under their original name, which is certainly the
intention of the Linux Foundation in promoting it.

I think it is an interesting discussion/debate as to whether the Linux
Foundation has or hasn't effectively released the DCO under the GPL
with no further restrictions.  However, I don't think it ultimately is
going to drive what we do.  So, we can just have our private opinions
here, and I do get Greg's arguments (and I acknowledge that he is a
bit of an expert in this space).

I'll just note that tempest in a teapot actually drives home the
importance of explicit copyright and license notices, since it is the
absence of any such notice in this file that is in part driving this
controversy.  Some of the potential ambiguities with our own current
policy could create similar issues, and they have in fact gotten
people upset when code was brought into a Gentoo repository without a
good policy on how to handle the copyright notices.

Authorship and ownership matter to people.  A good copyright policy is
about respecting the rights of others as much as preserving our own.

(And, as always, everything above is just my personal opinion...)

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 11:02 AM, Matthias Maier <tam...@gentoo.org> wrote:
>
> On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman <ri...@gentoo.org> wrote:
>
>> I'd think that the title of a legal document falls more under
>> trademark law than copyright law.  That is why the FSF publishes the
>> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
>> LICENSE."  The former has far more trademark protection than the
>> latter.
>
> What?
>
> No, this is *not* how it works.
>
> A license text is an original piece of work that falls under copyright
> protection.

We're not talking about the text of the license in the paragraph
above.  We're talking about the title of the license.

> In this case the copyright holder is the
>
>   »The Linux Foundation and its contributors«.

Well, there is no statement of copyright in this file:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches

But, I don't dispute that the Linux Foundation and its contributors
hold the copyright.

>
> The terms of distribution are
>
>   »Everyone is permitted to copy and distribute verbatim copies of this
>   license document, but changing it is not allowed.«
>

That text does not appear anywhere in the file I linked.

The GPL does, however.

>
> You cannot simply copy a substantial amount of text into your work (no
> matter what it is) if you do not have the right to do so.
>

I agree.  I certainly wouldn't do it if the Linux Foundation hadn't
published it under the GPL.

>> The Linux Foundation published a version of their DCO under the GPL,
>> which we would of course abide by.
>
> I highly doubt that, see my previous e-mail.
>

I just linked it, and it was linked in the draft policy.

The fact that they published it elsewhere under a different license
just means that it is effectively dual-licensed.  It doesn't diminish
any rights conferred under the GPL.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 10:55 AM, Greg KH <gre...@gentoo.org> wrote:
> On Thu, Oct 27, 2016 at 10:11:45AM -0400, Rich Freeman wrote:
>> On Thu, Oct 27, 2016 at 9:29 AM, Greg KH <gre...@gentoo.org> wrote:
>> >
>> > You can't change the text of a license and call it the same thing,
>>
>> I'd think that the title of a legal document falls more under
>> trademark law than copyright law.  That is why the FSF publishes the
>> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
>> LICENSE."  The former has far more trademark protection than the
>> latter.
>
> Do you see that term trademarked anywhere?  I will go file for one if
> you really insist on it, but really, think this through please.

The term "GNU" is trademarked as far as I'm aware.  Or, if not it
would probably be trademarkable in this context, since it is fairly
unique.  The term "General Public License" seems rather, well,
general.

When your title for something is generic it is generally very
difficult to enforce a trademark against it.

If you called it the "Linux DCO" then you'd probably have a strong
recourse against anybody also using the term "Linux DCO" since Linux
is a strong mark (it is a word that Linus invented as far as I'm
aware).

Look at Microsoft's attempts to enforce trademarks against "windows"
for an example of why generic words don't make good marks.

>
>> > which
>> > is why that wording is there (same wording is in the GPL), so don't
>> > think that by pointing at the one in the kernel source tree that changes
>> > anything...
>>
>> The Linux Foundation published a version of their DCO under the GPL,
>> which we would of course abide by.  The fact that they published it
>> elsewhere with a different license doesn't mean that we can't re-use
>> the version published under the GPL.
>
> How well does "plain text" work under the GPL?  Go on, I've been down
> that path before, it's well-worn, we'll be here when you get back... :)

Well, whether the GPL is a good license for text is a separate matter,
but it is a license.

>
>> If we aren't changing anything that does raise the question of why not
>> just use the Linux DCO, v1.1 or whatever it is at, incorporated by
>> reference.  I do think we have the legal right to fork it since it was
>> effectively published by the Linux Foundation under the GPL, but that
>> doesn't require us to fork it.
>
> Please just use the one as-published.
>

Seems like a logical approach.

-- 
Rich

Re: [gentoo-dev] GLEP RFC: Third-party contributions

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:55 AM, Michał Górny <mgo...@gentoo.org> wrote:
> On Thu, 27 Oct 2016 09:42:22 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>>
>> I do think that this is one of the areas where hasufell's concept of
>> making the 3rd-party workflow the main workflow could have helped.
>> Right now the people with commit rights mostly do things in a way that
>> it is awkward to feed 3rd-party contributions into.
>
> You are really going off-topic, you know?

No argument.  I meant it more as a tangential comment.  I wasn't
suggesting that this somehow had to be incorporated into the solution.

>
> But then, I don't really want to pursue this further. I'll leave it for
> others to decide where to put the ideas I've put into words in that
> GLEP draft.

Well, hopefully I didn't scare you off.  Ultimately though it probably
does need somebody who is really passionate about pull requests or
whatever to try to push it through.  There are certainly those of us
on these lists with interests just as perverse as that...

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab update

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:59 AM, Michał Górny  wrote:
>
> Neither were network device names. But now they are! As long as you
> predict to which USB port the dongle will be plugged ;-).
>

It would be nice if standards like USB incorporated some kind of GUID.
I ended up having to write a udev rule for a pl2303 RS232 adapter to
tie it to a specific USB port precisely so that I could have more than
one and know which one talked to which device.

I'd argue that the udev network interface names were a better (if
painful to transition to) solution to a problem created by somebody
else.  Being able to use wildcards in configuration files is probably
an adequate solution for those who are using a single device.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:29 AM, Greg KH  wrote:
>
> You can't change the text of a license and call it the same thing,

So is the objection mainly to calling it a "Developer Certificate of Origin?"

I'd think that the title of a legal document falls more under
trademark law than copyright law.  That is why the FSF publishes the
"GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
LICENSE."  The former has far more trademark protection than the
latter.

> which
> is why that wording is there (same wording is in the GPL), so don't
> think that by pointing at the one in the kernel source tree that changes
> anything...

The Linux Foundation published a version of their DCO under the GPL,
which we would of course abide by.  The fact that they published it
elsewhere with a different license doesn't mean that we can't re-use
the version published under the GPL.

If the FSF published the GPL under the GPL then people would be free
to redistribute modified versions of it as well.  I don't think they
would disagree with that.

> And I would _strongly_ not recomment changing the wording without
> consulting with a license lawyer, you can mess things up really quickly
> by changing stuff.

No argument there.  I don't think we're actually changing anything at
the moment.

If we aren't changing anything that does raise the question of why not
just use the Linux DCO, v1.1 or whatever it is at, incorporated by
reference.  I do think we have the legal right to fork it since it was
effectively published by the Linux Foundation under the GPL, but that
doesn't require us to fork it.

-- 
Rich

Re: [gentoo-dev] GLEP RFC: Third-party contributions

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:13 AM, Michał Górny <mgo...@gentoo.org> wrote:
> On Thu, 27 Oct 2016 07:07:20 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>
>>
>> I think this reflects reality.  You can submit all the patches you
>> want via bugzilla but it isn't like we punish developers for not
>> getting around to accepting them, unless they're completely inactive
>> Gentoo-wide.
>
> I disagree here. I dare say that Bugzilla is obligatory for all
> developers (they get an account there during recruitment, after all).
> I agree they aren't required to accept patches but if a developer
> outright ignores all attempts of communication, you know what needs to
> be done.
>

Recruit more maintainers or treeclean the package if it is a blocker?

While I don't really care for the whole passive-aggressive thing that
some seem to enjoy, mere inaction by a volunteer in certain areas is a
hard problem to deal with, because if they're making positive
contributions in others it is hard to demand that they make a positive
contribution in an area that we choose.

I get that being met with silence is highly frustrating, and I've been
on the receiving end of it.  Still, often the best solution isn't to
try to force somebody to do things our way, but to try to encourage
others to join in so that we have somebody to work with who is willing
to do it our way.

That is of course what this GLEP is all about.

>
> To be honest, after writing it all down, I started to get the feeling
> it isn't necessary after all. The initial idea (and what motivation was
> supposed to mean) was that all previous attempts failed because they
> either tried to be too specific, force too many style rules or just
> never got necessary 'global' to reach all affected parties.
>
> I'd dare say this GLEP ended up confirming 'third party contributions'
> are not that special, we don't need special teams to handle them or
> special rules to cover them.
>
> So yes, it would probably be enough to put such a simple statement
> somewhere. The problem is: where? ;-) GLEP seemed like a
> straightforward solution to make it global.
>

I think that is a completely fair question.

I wouldn't be hesitant to strongly promote a specific style,
especially if it isn't mandatory.  Convention over configuration and
all that.

As far as promotion goes, I think something on this page might help:
https://gentoo.org/get-involved/contribute/

Right now that is fairly bugzilla-centric.  I think expanding it to
offer bugzilla as one option among many could be helpful.  The current
page doesn't even mention gentoo-proxy-maintainers.

I do think that this is one of the areas where hasufell's concept of
making the 3rd-party workflow the main workflow could have helped.
Right now the people with commit rights mostly do things in a way that
it is awkward to feed 3rd-party contributions into.

So, maybe instead of a GLEP we need something in the style of a
contributor and committer workflow/guide that work very tightly
together.  Then we generate some excitement on the committer side of
that so that people who stick their toes in the water don't have a bad
experience, and then we promote it to the public.

-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol  wrote:
>
> I want to +1 this, but I do see one problem: If all dependencies are defined,
> how does "emerge --with-bdeps=y --emptytree @world" work? Defining all
> dependencies means the graph is completely cyclic.

Well, we'll need to define some kind of stage1 set no matter what we
do because of the bootstrapping problem.  Perhaps this can be
leveraged when breaking cyclical dependencies (optimize as much as you
can, allow parallel builds, but do the stuff in the stage1 set first
and don't treat circular deps as show-stoppers).

And I don't think portage actually breaks today with circular deps as
long as some start out satisfied.  If a depends on b and b depends on
a, and both have an upgrade, but the dependencies are unversioned,
then I think portage just does them in arbitrary order.  Now, if both
have circular versioned dependencies and you don't have at least one
installed, you're stuck (maybe a really clever portage might find
earlier intermediate versions with relaxed dependencies that break
this cycle, but I'd be surprised if that works today).

> Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree
> @world twice' if you want to ensure every package is rebuilt with its newest
> available build dependencies.

Well, if your goal is completely consistent rebuilds you can't avoid
the need to rebuild the stage1 set twice because of the bootstrapping
problem (which I believe is why we have stage2).  A solution would be
to first emerge the stage1 set, then do the emerge @world.  However,
in practice I don't think there are many situations where you really
need to do a rebuild of this scale.

I'm not saying you can completely avoid the need for having some kind
of bootstrapping stage1.  I'm just saying we should separate that need
from the issue of fully specifying dependencies, at least in an ideal
world where we're unconcerned with the effort of specifying
dependencies.


-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Thu, Oct 27, 2016 at 8:35 AM, Mart Raudsepp <l...@gentoo.org> wrote:
> Ühel kenal päeval, N, 27.10.2016 kell 07:21, kirjutas Rich Freeman:
>>
>> Actually, that isn't allowed, and was the very issue that kicked off
>> the entire matter.  You can't just take somebody else's code and
>> change the copyright to "Gentoo project and contributors" if the
>> Gentoo project's only contribution to the file is changing the
>> copyright notice.  From my reading on the topic you generally need to
>> list the largest contributor on the copyright line, which may or may
>> not be the Gentoo Foundation.
>
> "and contributors" covers that, and I didn't specify "Foundation".

Well, legally there is no entity called the "Gentoo project."

> The copyright headers purpose is:
>
> "Contrary to popular belief, providing a copyright notice or
> registering the work with the USCO is not necessary to obtain basic
> copyright protections. But there are some steps that can be taken to
> enhance the creator's ability to sue or stop others from copying:"
>
> Place a copyright notice on a published work. (...) Placing this notice
> on a published work (...) prevents others from claiming that they did
> not know that the work was covered by copyright. This can be important
> if the author is forced to file a lawsuit to enforce the copyright,
> since it is much easier to recover significant money damages from a
> deliberate (as opposed to innocent) copyright infringer."
>
> The copyright header has NO LEGAL meaning. IANAL.

You do realize that the text you quoted isn't the entirety of the law
concerning copyright.

Changing a copyright notice could be construed as slander of title if
the resulting statement isn't accurate.

>
> The copyright header has no meaning on who holds the copyright.

Does writing "Copyright 2016 Richard Freeman" on a retail box of
Microsoft Windows give me any copyright over Microsoft Windows?  No.

Is that statement making an incorrect factual statement as to who owns
the copyright?  Yes.  Can you get in trouble for putting incorrect
factual statements in print?  Yes, depending on the circumstances.
However, things like copyright ownership are the sorts of areas where
people get touchy.

I think you'd be hard-pressed to find a lawyer with expertise on
copyright who would say that we shouldn't have any concern about who
we should name in our copyright notices.

>From what I've read the recommended practice is to list the largest
contributor "and others."  I don't think it is a good idea to simply
copy the work of others and change the notice to "Gentoo and others"
or something like that if Gentoo doesn't hold the copyrights on the
majority.

In any case, however, I'm not attempting to defend the status quo.  I
wouldn't have drafted the new proposal if I thought what we were doing
today was adequate.  I'm just concerned that dismissing the issue
isn't the right solution either.

-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Thu, Oct 27, 2016 at 7:00 AM, Mart Raudsepp  wrote:
>
> Projects that want explicit copyright or copyright assignments or CLAs
> are those that want to be able to re-license the code without getting
> permissions from everyone (some of whom might not be possible to
> contact at a future date) or be able to sue someone for license
> violations without the original developers of the affected parts having
> to be involved. Are we pursuing those option, or why do we care?

These are useful options to have available.  The ability to pursue
violators would not require 100% signing of FLAs to work.  Relicensing
probably would, or close to it, so that might not ever be practical
unless FLA acceptance is very widespread.

> We don't need bogus or
> non-bogus copyright headers, just a "Gentoo project and contributors"
> copyright notice or optionally allowing explicit ones to those that
> want it, together with a license notice.

Actually, that isn't allowed, and was the very issue that kicked off
the entire matter.  You can't just take somebody else's code and
change the copyright to "Gentoo project and contributors" if the
Gentoo project's only contribution to the file is changing the
copyright notice.  From my reading on the topic you generally need to
list the largest contributor on the copyright line, which may or may
not be the Gentoo Foundation.

>
> And yes, the headers are currently completely bogus. You can consider
> it to be as such to any file I have contributed copyrightable work to,
> and the Gentoo Foundation does not have copyright to such work of mine.

If you don't think your contributions are copyrighted by the Gentoo
Foundation, you probably shouldn't be putting that statement in the
files you commit.  I don't see why your commits are any less legally
binding on you than your statements in emails like the one above.

And this is why improving the policy in this space is important.

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab update

[Rich Freeman]

On Thu, Oct 27, 2016 at 7:01 AM, Roy Bamford  wrote:
> On 2016.10.25 22:52, Ian Stakenvicius wrote:
>>
>> Personally I'd rather see us go the other way, ensure udev settles
>> before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
>> or something.  Leave the migration away from these paths to general
>> education of system setup, since they technically are valid, just not
>> ideal.
>>
>>
> +1
>
> Add udev-settle now.
> Have an advisory news item that says why its been done and what
> users can do if they don't like it or don't need it, and what will happen
> long term.


That seems sensible.

> At the same time, depreciate the use of udev symlinks in fstab.
>
> Some time later, remove udev-settle and have another news item.
> By now, users will have reacted to the first news item or sympathy
> can be minimal.

Why ever remove udev-settle, or deprecate the udev symlinks?  Is there
something wrong with them, other than a bug when you try to mount
things before they are created?

If anything the udev syntax seems a lot more "standard" since it
follows the normal device, mountpoint, etc syntax in fstab.

Nothing would prevent users from using the other syntax and removing
the settle step if they desire.  It just seems odd to not support a
fairly standard syntax in OpenRC, unless this is part of some larger
trend where udev itself is moving away from it, etc.

-- 
Rich

Re: [gentoo-dev] GLEP RFC: Third-party contributions

[Rich Freeman]

On Thu, Oct 27, 2016 at 3:01 AM, Michał Górny  wrote:
>
> Please review the following draft:
>
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:TPC
>

Regarding this paragraph: "Gentoo project provides a specific set of
official channels of contribution in which all project members are
required to participate. The exact list of these channels is outside
the scope of this specification."

i'm not actually certain that the first sentence is true.  I think the
only "official channel" of any kind that project members are required
to participate in is gentoo-dev-announce, and maybe gentoo-core.  I
don't think devs are actually required to either file or look at or
resolve bugs, for example.  Obviously it is encouraged.

I'd suggest just rewording this section to something like:
"Contributions can be accepted via any channel (whether official or
unofficial), as long as there is at least one project member willing
to support the particular channel and either commit or proxy the
contributions appropriately."

I think this reflects reality.  You can submit all the patches you
want via bugzilla but it isn't like we punish developers for not
getting around to accepting them, unless they're completely inactive
Gentoo-wide.

I do think the copyright issues belong in their own policy for the most part.

Part of me wonders if this really needs to be a GLEP (a mostly
inward-facing policy document) when it mostly documents existing
practices and policies.  Maybe what is needed is a more outward-facing
document, or some workflow documents?  The motivation states "Multiple
developers have noted various suggestions on Gentoo git workflow but
it never became an official policy," but I don't see any kind of
workflow really being solidified here either.

I guess my question on that front is what is the actual gap today, and
does this GLEP close it, and if not, is there either a better way, or
can we make the GLEP stronger to actually close the gap?  Just because
a workflow is optional doesn't mean that we can't standardize how it
is done.

-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes  wrote:
> On Thu, Oct 27, 2016 at 01:10:10AM +, Peter Stuge wrote
>> waltd...@waltdnes.org wrote:
>> > For a build-from-source distro like Gentoo, gcc and associated
>> > tools are a vital part of the distro.
>>
>> A stage4 created (and updated) on a catalyst build farm doesn't need
>> to have gcc, but may still need libstdc++.
>
>   That just moves the requirement for gcc+tools to the catalyst build
> farm.  OK, let's get specific... a *STANDALONE* Gentoo machine requires
> gcc+tools.

This is why I think "@system" oversimplifies all of this.  IMO we
should just specify all dependencies for everything (and those could
include some virtuals for convenience, like the C toolchain), and then
have different sets or virtuals for convenience.  By all means give a
user with a default install that sticks virtual/common-packages or
something in their @world.  Nobody is arguing that the typical Gentoo
user doesn't want gcc, or that we should force people to explicitly
install it.

Fixing the dependencies means that system packages can take advantage
of parallel builds, which means faster updates for everybody.  We can
still have sets for bootstraping (and I suspect that having more
virtuals or sets would allow stage1/2 definition to be simplified).

It is a bit like license groups.  We give everybody a default set of
license groups that generally makes sense.  But, if you want you can
easily edit your make.conf to exclude anything that is copyleft from
your system.

The main downside to this is it is a bit more of a hassle for
developers to maintain the dependency lists, since invariably you end
up with a lot of mundane stuff in there.  And of course it is a lot of
change to implement, though it could be done gradually.  And of course
the upside for the typcal user is somewhat limited, since most people
aren't dying to uninstall openssh or gcc.

-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Wed, Oct 26, 2016 at 4:15 PM, Denis Dupeyron  wrote:
>
> That said, we could always make it possible for the developer to
> voluntarily assign copyright to the foundation if (s)he so desires.
> And I would certainly do that for myself.
>

The envisioned approach was being able to voluntarily sign the FLA.
The wording of the FLA "...assigns to Gentoo the Copyright in computer
programs and other copyrightable material world-wide, or in countries
where such an assignment is not possible, grants an exclusive
licence..."
https://dev.gentoo.org/~rich0/fla.pdf   (.tex extension also at this URL)

It also has some copyleft style protections so it isn't the universal
handover of rights typically associated with a CLA.  It is based on an
FSFe template.

I think it is worth better understanding some of the personal legal
risks you bring up.  Obviously if you don't have any personal
"property" in the copyrights there is less incentive to go after you
as an individual, though more incentive to go after the Foundation.
The copyleft provisions might act as a poison pill to deter going
after either (to truly seize the copyrights you might actually have to
successfully sue both parties, possibly in different countries, and if
you want to seize the entire distro's copyrights you could have to sue
hundreds of people).  We just need to make sure we don't tick off the
RIAA...

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Tue, Oct 25, 2016 at 9:39 PM, Kent Fredric  wrote:
>
> Under this interpretation, developers using this header to add other
> peoples work to tree is making our use of DCO pointless.
>
> Because DCO has to be the person who *authored* the commit, not the
> person who merely added it to tree.

That actually isn't true.  Read the DCO.  Clauses b/c are designed
specifically for cases where the committer isn't the author.

It is apparently good enough for the Linux Foundation.  They don't
require any direct interaction with the author of code to accept it
into the kernel.  They merely require that whoever submits the code
makes the certification that they've done their due diligence.

>
> And Pram should stop adding it everywhere post-haste, because its
> inferring things that aren't true.
>

I did suggest that we probably should ban this header until we
actually have a DCO because it blurs the lines.  However, it isn't
really inferring something that isn't true right now because we don't
assign any legal meaning to the header right now.  The bigger concern
is that it blurs the lines after we have a DCO because people can
argue the use of the header was accidental or meant something else.

Whether or not we proactively ban the header, it would probably make
sense that if we do institute a new copyright policy including a DCO
that we ask all devs to explicitly ack the policy and the meaning of
the signed-off-by header somehow (maybe issue a gpg signed statement
from a template).  It could also be made a part of the ebuild quiz or
such so that all new devs ack it.

I don't think we need to go nuts with it.  Simply getting everybody to
ack the policy makes it unambiguous that people understand what the
header means.

But, new policy or not the DCO really represents a practice that we
should all be doing already.  Nobody should be sticking code in a
Gentoo repository without ensuring the licenses are compatible and so
on.  The DCO just represents a best practice that didn't exist when
Gentoo started and which most projects now embrace in some form.  It
isn't that we didn't care about copyright in the past, we just care
enough to be a little more formal about it in the future.

> But this doesn't change the fact there is a desire to communicate other
> properties of commits, like the audit trail for QA purposes.

Sure.  The repository should always make it clear who made each
commit, when, and why (with appropriate bug x-refs and so on).
Ideally it should somehow capture both who authored the code and who
put it into the repository.  I think for the most part we're already
doing all of this, but I'm sure there is room for improvement (having
a bug header in the default repoman commit template probably wouldn't
hurt - then they all look the same and you can always delete it or
leave it blank if it doesn't apply).

-- 
Rich

Re: [gentoo-dev] newsitem: important fstab update

[Rich Freeman]

On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
>
> this item is about an important fstab update. In short, people need to
> move away from /dev/disk-by/* in their fstab vfiles.
>
> I do have a question about the newsitem -- how do I make it display only
> for Linux users?
>

Presumably you'd also only want it to show for openrc users.  Other
mounting tools handle the udev names fine as far as I'm aware.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 11:53 AM, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>> On Tue, 25 Oct 2016, Rich Freeman wrote:
>
>>> Also, calling eclass functions could be considered linking. It is not
>>> entirely clear to me if e.g. a binpkg built with a CDDL licensed
>>> ebuild calling GPL licensed eclasses would be distributable at all.
>
>> Honestly, I think the GPL linking argument is a difficult one at best,
>> but setting that aside I think it is even harder to consider calling a
>> function in an interpreted language "linking."  Is it a violation of
>> the GPL to execute a GPL binary from a bash script that is
>> GPL-incompatible?  Heck, is it a violation of the other license for
>> the GPL bash interpreter to read and execute the non-GPL lines in the
>> script?
>
> Generally, the user can execute any combination of such functions on
> his system, without violating their licenses. The question is if a
> combined work containing parts of the ebuild and of the eclass can be
> distributed.

Sure, I'll buy that much.

> Now a Gentoo binary package contains an xpak part, which in turn
> contains a file named environment.bz2 where you will find functions
> originating both from the ebuild and from its inherited eclasses.

Sure, and I wasn't really speaking to the ability to redistribute
binary packages.  I was concerned more with the ebuilds themselves,
and the on-disk packages.

However, other distros do actually consider their binary packages to
be combinations of incompatible licenses in some cases, and they argue
that this is mere aggregation.  In this case we're talking about
aggregating ebuild and eclass functions and that is probably a step
further down the line from what other distros are likely doing.

> Certainly the xpak is a derived work of ebuild _and_ eclasses, so for
> distributing the binpkg both CDDL (to come back to the original
> example) and GPL-2 would have to be honoured. Which is not possible
> because these two licenses are incompatible.

Maybe.  They're aggregated, but whether this prevents redistribution
is another matter.  You could provide the source for the whole, and
tell the recipient that the various functions in the package are
redistributable under their original licenses.  It is trivial to split
an environment file back into its component functions.

Again, I wasn't really considering binary packages and I tend to agree
that mixed licenses do complicate this situation.

-- 
Rich

Re: [gentoo-dev] Commented packages in the @system set

[Rich Freeman]

On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson  wrote:
>
> However, I don't think this is the criterion used to determine what
> should be in @system.  The wiki defines the system set as the set that
> "contains the software packages required for a standard Gentoo Linux
> installation to run properly".
>

IMO that is a pretty poor definition, and we aren't really forced to
stick with it regardless of how it got there.

But, I tend to be an advocate of a minimal @system.  Really, I'd
prefer if it were split and renamed @bootstrap and @common or
something like that, and if it was only used by catalyst and could not
be relied upon as being installed by default.  My all means stick it
in the default /var/lib/portage/world for convenience, but users
shouldn't get scary warnings when they uninstall openssh.


-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 11:17 AM, Alexis Ballier  wrote:
>
> If I write a QT gui that forks/exec x264 cli and want to sell it as the
> best H264 encoder on the market, then I have to comply with x264
> license since it won't do what I claim once x264 is removed.

The QT gui could be distributed under any license you care to, since
it doesn't contain anything from x264.  It might not actually do
anything without the x264 binary, but it can be legally redistributed
on its own under your choice of license (if you're the author).

Now, if you want to redistribute the x264 binary then of course you
need to comply the with the x264 license.

Running a program from a script doesn't make your script a derivative
work of that program.  They each have their own license, and can be
independently redistributed.

> If I want to sell the same program as a QT gui for x264 cli, then it is
> far less clear whether it is derivative work, but I'll certainly have
> more difficulties in selling it :)

I don't really see how marketing changes something's status as a
derivative work.  Certainly I'm not aware of any court decision to
this effect, or any law.

> Back to the subject, a CDDL ebuild is a CDDL script to install a
> program. If you can't install the program without the GPL parts (that
> are distributed inside the same binpkg iirc), then it is derivative
> work.

I disagree.  We in fact allow GPL ebuilds in the Gentoo repository
that install proprietary software which is subject to licenses which
are GPL-incompatible.  The fact that your script automates running a
bunch of proprietary code doesn't change the fact that your script
itself is completely free software, governed by its own license.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 9:56 AM, Alexis Ballier <aball...@gentoo.org> wrote:
> On Tue, 25 Oct 2016 09:17:08 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>
>> On Tue, Oct 25, 2016 at 8:54 AM, Ulrich Mueller <u...@gentoo.org>
>> wrote:
>> >
>> > Also, calling eclass functions could be considered linking. It is
>> > not entirely clear to me if e.g. a binpkg built with a CDDL licensed
>> > ebuild calling GPL licensed eclasses would be distributable at
>> > all.
>>
>> Honestly, I think the GPL linking argument is a difficult one at best,
>> but setting that aside I think it is even harder to consider calling a
>> function in an interpreted language "linking."  Is it a violation of
>> the GPL to execute a GPL binary from a bash script that is
>> GPL-incompatible?  Heck, is it a violation of the other license for
>> the GPL bash interpreter to read and execute the non-GPL lines in the
>> script?
>
> The concept is "derived work": If your script cannot work without the
> GPL binary, then it is derived work.
>

I don't think any well-recognized organization argues that scripts are
derived works of the binaries they call.  Besides, literally the only
thing about the binary that a script contains is the name of the
binary, and some command line options.  This seems like it is going
even further than suggesting that APIs be copyrightable.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 8:54 AM, Ulrich Mueller  wrote:
>
> Also, calling eclass functions could be considered linking. It is not
> entirely clear to me if e.g. a binpkg built with a CDDL licensed
> ebuild calling GPL licensed eclasses would be distributable at all.

Honestly, I think the GPL linking argument is a difficult one at best,
but setting that aside I think it is even harder to consider calling a
function in an interpreted language "linking."  Is it a violation of
the GPL to execute a GPL binary from a bash script that is
GPL-incompatible?  Heck, is it a violation of the other license for
the GPL bash interpreter to read and execute the non-GPL lines in the
script?

To me linking and word processing are actually on a continuum and I
think it is hard to draw a line and say that the GPL prohibits one and
not the other, but if you are going to try to draw a line I think
interpreted languages are going to fall on the safe side of it.

I guess it comes down to what are the essential elements of linking
that leads one to believe that it constitutes a violation of copyright
to do it without explicit permission?  If there is agreement on that
(which I think is harder to achieve than some seem to think), then the
question becomes whether calling a function in an interpreted language
contains those elements.

>
> So can we be strict there, please? Contributed ebuilds should have our
> standard copyright header, or they will be rejected.
>

Certainly this is the current policy.  The draft policy envisions a
table of licenses for each project, and we of course can make that
table as restrictive or free as desired.  I do think it makes sense to
whitelist licenses individually by project for the very sorts of
reasons that you bring up.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 12:48 AM, Daniel Campbell  wrote:
> This made me think of another scenario; let's say I have my own fork of
> Gentoo, maintained in an overlay complete with docs, etc, under an MIT
> or BSD license, but as a Gentoo developer, I must copyright under GPL.
> Could I do such dual licensing on a case-by-case basis because (in this
> hypothetical) I'm the original author of the ebuilds?

Well, you could certainly dual-license anything you're the author of.
A complete fork of Gentoo under the BSD license would probably be
impractical though since you'd have to rewrite everything.

>
> If so, then Matt's coworker could offer the same ebuild under a
> Gentoo-friendly license and maintain copyright on Google's overlay. The
> only question at that point would be Google's own copyright policy and
> whether or not its employees own any of what they produce on company time.

The chromiumos ebuilds are already under a friendly license.  The only
issue is what to put in the copyright header.  Under the proposed new
policy the ebuilds could just be copied into the tree wholesale, since
they're already under the correct license and the chromiumos headers
would be fine under the new policy, perhaps just with the addition of
"and others" as soon as any changes get made.

If they were under a non-compatible license like the CDDL then it
would depend on whether the authors have the right to dual-license it
under the GPL, or whether Gentoo is willing to accept CDDL-licensed
ebuilds into the repository.  Part of the draft policy is that every
Gentoo project/repository have a list of accepted licenses.  Off the
top of my head I can't think of any issues with allowing incompatible
but similar copyleft licenses into the main tree.  The files
themselves are standalone, and I'm not sure to what degree the actual
built binaries inherit their copyright.  Perhaps there are some
situations where you could have bindist issues, but I suspect they
would be isolated.

I was actually chatting with somebody about the issue of package
licensing vs upstream licensing (which is an issue we don't have as
many problems with since we don't aggregate package metadata with the
actual package contents).  We didn't really talk about the licensing
of the final on-system binary which is mainly upstream-controlled but
whose installation details are influenced by the distro.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:47 PM, Matt Turner <matts...@gentoo.org> wrote:
> On Mon, Oct 24, 2016 at 4:43 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> I personally tend to favor a mandatory DCO (we absolutely need to know
>> the copyright status of our code), and a voluntary FLA (which I tend
>> to prefer to outright assignment as I think it lines up well with our
>> always-free social contract).
>
> Do you have any ideas about how that might work for previous
> contributions? Plenty of developers have come and gone (and died!)
> since gentoo began accepting commits.
>

Existing copyright headers would be grandfathered as-is unless
somebody comes forward with a specific concern.  Over time the tree
just improves.  That is my suggestion at least, it is certainly no
worse than we are today, and a decade from now the really old stuff
will be gone.

-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:32 PM, Gordon Pettey  wrote:
> On Mon, Oct 24, 2016 at 5:40 PM, Ciaran McCreesh
>  wrote:
>>
>> On Mon, 24 Oct 2016 15:34:14 -0700
>> Matt Turner  wrote:
>> > In order to contribute to GNU projects, one must sign a copyright
>> > assignment statement.
>> >
>> > Gentoo doesn't have anything similar as far as I'm aware, which makes
>> > me question the legitimacy of "Gentoo Foundation" copyrights.
>
>
> That style makes no sense to begin with. Something is copyrighted as of the
> date it is created (whether originally or as an updated edited work), from
> that date until X years in the future depending on what country you're in.
> At worst, that range implies "This file was created in 1999 but in 20xx
> we're making it public domain". Assuming Gentoo still exists in 200 years
> and a certain mouse doesn't extend copyright durations again, a header that
> says "1999-2216" would be quite invalid. Just use the single year as of the
> date of editing. See http://www.copyright.gov/fls/fl100.html.

The end date (which is the one that matters the most) is only updated
when the file is changed.  Legally somebody could use an earlier
version of the file when its copyright expired, but they could only
use the latest version when its later copyright expires.

I do tend to agree that we should probably make the start date in each
file depend on when that file was created, but I'm not sure that
legally the start date really matters as much.

You'll see plenty of ebuilds in the tree with pre-2016 copyright end
dates.  Repoman will issue a warning if they're modified to warn devs
to update the date, which is completely appropriate legally (setting
aside the issue of who owns the copyright).

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:31 PM, Matt Turner  wrote:
>
> Yeah, it seems to be painful no matter what you do (CLA, copyright
> assignment, listing copyright holders) just in different ways :)
>

Well, the advantage of assignment is that it does simplify copyright
tracking, since you own the copyright on everything.

The problem is that it potentially cuts out a lot of contributions.
There is also the problem of nations that do not allow assignment
(though that could also be fixed in theory by just ending the Gentoo
German conspiracy).

I personally tend to favor a mandatory DCO (we absolutely need to know
the copyright status of our code), and a voluntary FLA (which I tend
to prefer to outright assignment as I think it lines up well with our
always-free social contract).

The issue remains of what to do with the copyright notice.  I
suggested just having enough names on the line to account for 51% of
the code, which as far as I can tell is completely legal.  That
doesn't preclude just listing all the names (which is ugly, but
administratively simple).  But, that does help cover us in cases where
we have some ebuild where we can only account for 60% of it.  It also
allows us to borrow anything from any other project that already has
its copyrights well-documented.

FYI, one of the original sparks that drove some of this thinking was
the eudev copyright fiasco (which like a lot of systemd-related stuff
was blown out of proportion IMO with things being attributed to malice
which were simply a lack of thinking things through).  This was the
first time Gentoo really forked and internalized a major external
project, and there was a clash between our previous practices designed
for dev-written code and the large import of external code.  Under the
draft copyright policy we'd have just maintained the previous
copyright headers, perhaps just reformatting them to the top of the
file per our convention if they weren't already there (which is
completely legal).  If at some point enough code in a file got
rewritten to have majority-FLA authorship we'd have the option to
change it to Gentoo and others, though we wouldn't have to.

-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:25 PM, William L. Thomson Jr.
<wlt...@o-sinc.com> wrote:
> On Monday, October 24, 2016 7:07:41 PM EDT Rich Freeman wrote:
>>
>> I think you could make an argument that voluntarily placing that header on
>> your work is an assignment of copyright.
>
> For the original author. That is not the case if adding another's ebuild to
> tree. Which seems to be the problem in the other thread.
>

Completely true, which is why devs aren't supposed to add ebuilds they
don't hold copyright on without permission.  A DCO would probably help
with this, which is why that is generally considered a best practice.

-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:21 PM, Matthias Maier  wrote:
>> I think you could make an argument that voluntarily placing that
>> header on your work is an assignment of copyright.
>
> I very much doubt that.
>

Well, like I said you can argue it either way.  Everybody is going to
have an opinion, but the only ones that matter are those of the
various top-level courts internationally, especially the US Supreme
Court (since US law tends to get enforced extra-judicially).

>
> And I see absolutely no harm in explicitly annotating the actual
> copyright in gentoo ebuilds.
>

Well, depending on how this is done the main harm is in administrative
overhead, unless this is automated, or we use a simplistic approach of
just continuing to append names.

-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:10 PM, Matt Turner <matts...@gentoo.org> wrote:
> On Mon, Oct 24, 2016 at 4:07 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> On Mon, Oct 24, 2016 at 6:34 PM, Matt Turner <matts...@gentoo.org> wrote:
>>> In order to contribute to GNU projects, one must sign a copyright
>>> assignment statement.
>>>
>>> Gentoo doesn't have anything similar as far as I'm aware, which makes
>>> me question the legitimacy of "Gentoo Foundation" copyrights.
>>>
>>> What is the story?
>>>
>>
>> The story of what?
>>
>> Are you asking whether they're legally binding?  You'd have to sue
>> somebody to find out, because as far as I'm aware the matter is
>> untested in court.  I think you could make an argument that
>> voluntarily placing that header on your work is an assignment of
>> copyright.  You could also argue otherwise.  A court would decide who
>> wins.
>
> I'm asking whether we're just cargo-culting it along, or if we have
> (had) some kind of system in place to assign copyright. I think Ciaran
> answered: we used to but not anymore.
>

As I said, you could debate whether the present system already assigns
copyright.  I don't think it is ideal.  It certainly isn't backed by
any court decisions that I'm aware of.  That doesn't necessarily mean
that it wouldn't be upheld if it did go to court.  There is really no
way to be certain without trying it.

But, it is better to rely upon methods that are already proven in
court over ones that have yet to be proven.  I'm not disputing that.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:12 PM, Matt Turner <matts...@gentoo.org> wrote:
> On Mon, Oct 24, 2016 at 4:03 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> You cannot currently commit anything with a different copyright notice
>> to gentoo.git
>
> According to whom or what?
>

https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
Under ebuild header.

This is a Gentoo policy.  Repoman will complain if you violate this.
It will get noticed and treecleaned if you ignore repoman.  Devs who
violate the policy will be warned, etc.

The policy could be changed, and there have been discussions around
improvements:
https://dev.gentoo.org/~rich0/copyrightpolicy.xml

The main issue I'm aware of with that draft is that it is painful to
track who has copyright on what to put the proper copyright notice on
each file.  Suggestions are welcome.

-- 
Rich

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Rich Freeman]

On Mon, Oct 24, 2016 at 6:34 PM, Matt Turner  wrote:
> In order to contribute to GNU projects, one must sign a copyright
> assignment statement.
>
> Gentoo doesn't have anything similar as far as I'm aware, which makes
> me question the legitimacy of "Gentoo Foundation" copyrights.
>
> What is the story?
>

The story of what?

Are you asking whether they're legally binding?  You'd have to sue
somebody to find out, because as far as I'm aware the matter is
untested in court.  I think you could make an argument that
voluntarily placing that header on your work is an assignment of
copyright.  You could also argue otherwise.  A court would decide who
wins.

Personally I'd rather move to an explicit system.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 6:29 PM, Matt Turner  wrote:
> A former co-worker of mine is now at Google and wants to contribute
> ebuilds he wrote for ChromeOS to Gentoo. They add packages necessary
> for Vulkan (new 3D graphics API).
>
> For instance: 
> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/vulkan-loader/vulkan-loader-1.0.24.0.ebuild
>
> The copyright header says "Copyright 2016 The Chromium OS Authors. All
> rights reserved." All ebuilds in gentoo.git say "Copyright 1999-20xx
> Gentoo Foundation".
>
> Can I add ebuilds copyrighted by others to gentoo.git?
>

As long as you have their permission to change the copyright notice.
You cannot currently commit anything with a different copyright notice
to gentoo.git, and you cannot legally change it without permission.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Mon, Oct 24, 2016 at 3:21 AM, Daniel Campbell (zlg)  wrote:
>
> On October 23, 2016 11:29:49 PM PDT, "Michał Górny"  wrote:
>>Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell
>> napisał(a):
>>>On 10/19/2016 02:10 AM, Ulrich Mueller wrote:
 Maybe I have missed something, but why would one use --signoff for
 a Gentoo commit?

 For Linux (the kernel), the meaning of the line is that the
 contributor certifies the DCO (Developer's Certificate of Origin)
>>>[1].
 As we don't have a Gentoo DCO, it is not at all clear to me what the
 meaning of a Signed-off-by: line would be in the context of the
>>>gentoo
 tree.

 Even worse, I see commits having Signed-off-by: lines with obvious
 pseudonyms instead of a real name, which would be meaningless even
>>if
 one would say that the Linux rules apply. (Also, we have the rule
>>>that
 real names must be provided for all developers, with no exceptions
>>to
 be made for people doing copyrightable work [2].)

 [1]
>>>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428
 [2]
>>>https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F

>>>The way I understood "signed off by" for Gentoo is "I am a developer
>>>who
>>>looked at the code and tested it, confirming it works on my system".
>>If
>>>an AT signs off, they are certifying that it passes their test muster.
>>>
>>>It's a more formal "looks good to me", and provides a point of
>>>accountability if the commit _isn't_ up to par.
>>
>>How about Gentoo developers stopping to reuse things that have
>>well-defined meaning for something completely different?
>
> I did say "to my understanding". I wasn't aware of DCOs. Regardless, 
> practices and workflows differ between projects, and it doesn't surprise me 
> to see projects that use the same words differently. Not that we should, of 
> course. What would you call what I decribed, though; Acked?

I don't think we need a git header for the purpose of saying that
something looks good to somebody else.  If you commit something and it
doesn't work, we'll ask you to stop doing it.  If you keep doing it
we'll take away your commit access.  This is purely an internal
problem.

The purpose of a DCO is to withstand external scrutiny.  It helps
protect Gentoo in the event that somebody else's copyrighted code
makes it into the distro.  The audience for a signed-off-by header
isn't Comrel or QA, but rather a court of law.  It makes it harder to
contribute something to Gentoo and then argue that you didn't intend
for Gentoo to redistribute it under the GPL, or that now that you've
had a falling out you'd prefer that Gentoo remove all your past
contributions.

However, it has absolutely no meaning at all if it isn't 100% clear
what is being signed.  And if we have a long history of people adding
the header when it doesn't mean anything legally then it will probably
make it harder to argue that it suddenly means something when the
policy changes.

For example, suppose we institute a DCO tomorrow.  Then zlg ragequits
in 2 years and claims he never gave us permission to redistribute his
code under the GPL.  We point to his signed-off-by headers but he says
he never heard of the DCO policy and that it was just some default
setting in his config, and that he was adding the headers long before
the policy went into effect.  I don't think it would stick but it
really isn't an out we want to give people.  IMO infra should reject
commits with this header until we have a DCO, and then it should
reject commits without this header.  Alternatively, we could skip the
first part but require all existing devs to ack the new copyright
policy whenever it happens.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Sat, Oct 22, 2016 at 10:47 AM, Greg KH <gre...@gentoo.org> wrote:
> On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote:
>>
>> The last draft DCO was:
>> Gentoo DCO 1.0 By making a contribution to this project, I certify
>> that: (a) The contribution was created in whole or in part by me and I
>> have the right to submit it under the open source license indicated in
>> the file; or (b) The contribution is based upon previous work that, to
>> the best of my knowledge, is covered under an appropriate open source
>> license and I have the right under that license to submit that work
>> with modifications, whether created in whole or in part by me, under
>> the same open source license (unless I am permitted to submit under a
>> different license), as indicated in the file; or (c) The contribution
>> was provided directly to me by some other person who certified (a),
>> (b) or (c) and I have not modified it. (d) I understand and agree that
>> this project and the contribution are public and that a record of the
>> contribution (including all personal information I submit with it,
>> including my sign-off) is maintained indefinitely and may be
>> redistributed consistent with this project or the open source
>> license(s) involved.
>>
>> This is from the last policy draft:
>> https://dev.gentoo.org/~rich0/copyrightpolicy.xml
>
> Why redraft the already-useful DCO that is out there for you to use
> as-is:
> http://developercertificate.org/

To be honest I don't remember.  The last time I touched it was years
ago and maybe there was a reason to fork it at the time, but I can't
see a reason for it now.

>
> As you copied the text, be sure to give proper reference to who owns the
> copyright of that text please, you just can't rename it and claim it as
> your own :)
>

Makes sense.  I'd suggest copying it into the policy and attributing
it vs just incorporating it by reference, since the original might go
away (though we've already demonstrated that our own guidexml has not
lasted as long as that hosted text file).

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Wed, Oct 19, 2016 at 8:32 AM, Kent Fredric  wrote:
>
> So if this commit was to get teleported to a different repo,
> --signoff by would be preserved, as an intermediate between these two.
>
> So I think the intent for this is "X reviewed these changes for Gentoo
> and takes responsibility for them"
>
> what text you use to convey that is irrelevant, as long as its used
> consistently and everyone understands what the text means.
>

Actually, the text matters a great deal, which is why projects that
care about copyright tend to have an explicit DCO.  One for Gentoo was
in the works but has stalled somewhat (to be fair, it was stalled
originally because we were waiting for git to come along).  It
probably makes sense to at least get that into effect even if we don't
have a long-term strategy around copyright attribution and so on.

The last draft DCO was:
Gentoo DCO 1.0 By making a contribution to this project, I certify
that: (a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license indicated in
the file; or (b) The contribution is based upon previous work that, to
the best of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that work
with modifications, whether created in whole or in part by me, under
the same open source license (unless I am permitted to submit under a
different license), as indicated in the file; or (c) The contribution
was provided directly to me by some other person who certified (a),
(b) or (c) and I have not modified it. (d) I understand and agree that
this project and the contribution are public and that a record of the
contribution (including all personal information I submit with it,
including my sign-off) is maintained indefinitely and may be
redistributed consistent with this project or the open source
license(s) involved.

This is from the last policy draft:
https://dev.gentoo.org/~rich0/copyrightpolicy.xml

(And of course you get to read the raw xml these days...)

The main issue with the overall copyright policy was the issue with
tracking authorship and who goes on the copyright line.

-- 
Rich

Re: [gentoo-dev] Local workarounds with no reported bugs

[Rich Freeman]

On Mon, Oct 17, 2016 at 9:09 AM, Raymond Jennings  wrote:
>
> Changing the status quo may require some adjustment though, but I suppose we
> could start by openly documenting a bug if we find a workaround that does
> not already have a bug number associated with it.  I've seen several ebuilds
> where workarounds are applied, but the workaround also has a bug number in
> the comment.

The other side of this is being approachable so that people don't feel
like they're about to demonstrate their incompetence by filing a bug.
FOSS tends to be a meritocracy, and I think people sometimes work in
their own little corner because they're afraid of being shamed for not
"getting it."  In reality having mistakes exposed shouldn't be
unpleasant, and we should be able to use it to grow.

I can see how a new developer might be reluctant to suggest that some
very experienced developer has made a mistake in an eclass.  Of
course, that doesn't make this OK.  We should be speaking up when we
see mistakes, and we should be gracious both when our mistakes are
pointed out or somebody doing so has made a mistake themselves.

-- 
Rich

Re: [gentoo-dev] rfc: the demise of grub:0

[Rich Freeman]

On Tue, Oct 4, 2016 at 9:57 PM, Kent Fredric <ken...@gentoo.org> wrote:
> On Tue, 4 Oct 2016 22:22:12 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>
>> How do you generate your grub-0 config files?
>
> I didn't, it came as a stock example file with comments which I edited
> in a minimal fashion until it worked.
>

Not a surprise, that is how most did it.

>>
>> You can just use the same method to generate the grub-2 ones...
>
> No, I regenerated it with mkconfig, replacing the file.

And that is my point.

In the past you were given a template file and some instructions and
simply edited it.

Now you're given a fancy file-generator tool which you don't like.
So, instead of a template file you ask for another simpler
file-generator tool, which I think is the wrong approach.

What you really want is another template file.

I'm happy with mkconfig, but I did hand-roll my config files before
that.  The docs are out there.  However, for whatever reason, it is
very hard to find examples of simple config files online.  The
official docs try to point you in the direction of mkconfig, and since
99% of linux users don't configure their own grub there isn't much
alternative documentation (and when a distro's solution does break the
solution usually is based on mkconfig anyway).

Unfortunately, I deleted the last copy of my manually-generated config
files eons ago, otherwise I'd happily post one.  The syntax is ALMOST
identical to grub-0, but not quite.  The syntax is documented though,
and you can get a sense for how it works in the mkconfig-generated
ones, but I'll go ahead and point out that 99% of the stuff in those
is unnecessary.  The essential elements are basically the same as they
were before.

-- 
Rich

Re: [gentoo-dev] rfc: the demise of grub:0

[Rich Freeman]

On Tue, Oct 4, 2016 at 9:29 PM, Kent Fredric  wrote:
>
> Hence, a more sensible default instead of mkconfig that emits a config
> file that mortals can sensibly edit ( including relevant inline comments
> describing what is done ) would be a smart move that would go a long
> way.
>

How do you generate your grub-0 config files?

You can just use the same method to generate the grub-2 ones...

-- 
Rich