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] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Kent Fredric]

On Tue, 25 Oct 2016 09:25:52 +0200
Ulrich Mueller  wrote:

> And I guess that even most ebuilds for new
> packages aren't written from scratch, but will be based on an existing
> ebuild or on some template like skel.ebuild.

You could probably argue that subsequently, every ebuild is essentially
a derived work of the first ebuild, and thus, a derived work of
Gentoo's copyright.

The format is so regularised 2 people could independently create the
same ebuild.

Not because there's any real rules to how we order things, but because
people take their advice at how to write ebuilds by copying other
existing ones.



pgpZ37xxxUZ8r.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Mon, 24 Oct 2016 07:45:56 -0400
Rich Freeman  wrote:

> 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 problem is that the COMMITTER and AUTHOR headers don't actually
reflect the "I tested it and made sure its OK" metadata.

If for example, a commit made to Gentoo was replicated to another
repository by cherry-pick, the default mechanic would result in
COMMITTER changing to the person who performed the cherry-pick.

Thus, it makes the assumption that everyone who performed a COMMIT
action or an AUTHOR action verified the nature of the commit in some
manner.

However, the AUTHOR is the least qualified to verify the commit as
"Good".

and the COMMITTER value changes arbitrarily if you try to cherry-pick or
rebase the commit sequence.

And people who rebase commit sequences are typically not firing up
review engines for every commit they rebased.

Granted, this is not a very common problem in Gentoo.

But IME, this is the sort of use-case that the header is useful for.

If we deem this header useless, then we should probably consider
dropping the Portage Version and Repoman Flags headers that repoman
adds.

Because they're also made entirely irrelevant in very short times,
because it only indicates "Authored with", it doesn't indicate anything
that happened since then.

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

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.

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

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

It just means we have to find some other way of doing this which is
standard, but the stock git commands lack any such mechanism.


pgpocxPgRq2WX.pgp
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 25/10/16 18:27, William Hubbs wrote:
> On Tue, Oct 25, 2016 at 06:07:51PM +0100, James Le Cuirot wrote:
>> On Tue, 25 Oct 2016 12:01:06 -0500
>> 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.
>> "Inportant" typo in the title.
>>
>> Even before you posted this, I was wondering why this is a problem now?
> This was changed in baselayout git years ago [1], and someone hit a race
> condition caused by not making the changes in their fstab [2].
>
> The "new" syntax is device-manager agnostic, and supported by both
> util-linux and busybox, so imo it is the best route to take.
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=496562
> [2] https://bugs.gentoo.org/show_bug.cgi?id=596346
+2



signature.asc
Description: OpenPGP digital signature

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

[Benda Xu]

Nick Vinson  writes:

> arguably gcc should also excluded, under that definition, so the wiki
> might not be 100% correct

This is not true regarding libgcc* runtime libraries.

Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] LLVM News item

[Joakim Tjernlund]

On Tue, 2016-10-25 at 16:07 -0400, Ian Stakenvicius wrote:
> On 25/10/16 04:02 PM, Joakim Tjernlund wrote:
> > 
> > On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
> > > 
> > > On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
> > > > 
> > > > 
> > > > On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
> > > > > 
> > > > > 
> > > > > On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
> > > > > > 
> > > > > > 
> > > > > > On Tue, 25 Oct 2016 17:32:22 +
> > > > > > Joakim Tjernlund  wrote:
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item 
> > > > > > > and read:
> > > > > > > ..
> > > > > > > In order to enable all targets, add the following to your
> > > > > > > /etc/portage/package.use or equivalent file:
> > > > > > > 
> > > > > > >   sys-devel/llvm LLVM_TARGETS: *
> > > > > > >   sys-devel/clang LLVM_TARGETS: *
> > > > > > > ...
> > > > > > > 
> > > > > > > I would like to control such variables(LLVM_TARGETS) through the 
> > > > > > > profile as
> > > > > > > well but it seems not supported?
> > > > > > 
> > > > > > Why not? We're already setting the defaults in profiles, and you 
> > > > > > can do
> > > > > > whatever you want in your own profile. The news item is focused on
> > > > > > regular users, so it covers the usual configuration files rather 
> > > > > > than
> > > > > > creating custom profiles.
> > > > > > 
> > > > > 
> > > > > How? in my profile(which inherits 
> > > > > gentoo:default/linux/amd64/13.0/desktop) I just tested to add:
> > > > > # > svn diff
> > > > > Index: package.use
> > > > > ===
> > > > > --- package.use   (revision 1087)
> > > > > +++ package.use   (working copy)
> > > > > @@ -1,3 +1,6 @@
> > > > > +sys-devel/llvm LLVM_TARGETS: *
> > > > > +sys-devel/clang LLVM_TARGETS: *
> > > > > 
> > > > > Then I get:
> > > > > # > emerge -aNDuv world
> > > > > --- Invalid USE flag for 'sys-devel/llvm' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > 'LLVM_TARGETS:'
> > > > > --- Invalid USE flag for 'sys-devel/llvm' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > '*'
> > > > > --- Invalid USE flag for 'sys-devel/clang' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > 'LLVM_TARGETS:'
> > > > > --- Invalid USE flag for 'sys-devel/clang' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > '*'
> > > > > 
> > > > 
> > > > Syntax error:
> > > > 
> > > > sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
> > > > sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..
> > 
> > This is standard USE flags, not the VAR: x y z syntax
> > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > You can't specify wildcards to enable groups of use flags.
> > > > 
> > > > 
> > > 
> > > Correction, the earlier syntax *is* supposed to work (and tested that
> > > it works here, with VIDEO_CARDS)..  If I had to guess this probably
> > > relates to an issue with the transmode overlay.
> > > 
> > 
> > Hmm, are you saying that you can write:
> >   x11-base/xorg-drivers VIDEO_CARDS: intel radeon
> > in your profile?
> > 
> > Any idea what my issue might be?
> > 
> >  Jocke
> > 
> 
> In my profile as in /etc/portage/package.use/  , yes. Specifically I
> tested VIDEO_CARDS: *

I thought it was obvious that I was referring to a custom profile
as in eselect profile ..

> 
> I *didn't* try to mess with my in-repo profile though.  Given that
> repositories may well need to follow PMS, and the USE_EXPAND: * syntax
> is a portage'ism, this is why they are being rejected in the
> transmode-overlay case.  I certainly can't find an example of this
> syntax in the gentoo repo.

Portage supports lots more than PMS as is, should we remove that?
Just because something is supported in portage, you don't have to use it
in official repos. Our overlay is used to maintain all the linux computers
we have here and /etc/portage is the individual using a particular computer.

It would be nice if portage, in general, supported the same features/syntax as
/etc/portage does.

  Jocke

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

[Matthias Maier]

> please make also clear that UUID=... syntax will still work, one for all I
> don't like labels and will gladly continu to use this format:
> UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime  1 2

+1

Slightly revising the example given later on by simply showing one
example for LABELs and one for UUIDs should be enough.

Best,
Matthias

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

[Ian Stakenvicius]

On 25/10/16 05:12 PM, Michał Górny wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> William Hubbs  wrote:
> 
>> Title: Inportant fstab update
>> Author: William Hubbs 
>> Content-Type: text/plain
>> Posted: 2016-10-28
>> Revision: 1
>> News-Item-Format: 1.0
>>
>> If you are not using /dev/disk/by-* paths in fstab, you do not need to
>> take any action for this news item.
>>
>> If you are, it is very critical that you update fstab AS SOON AS
>> POSSIBLE. Your system will become unbootable in the future if you do
>> not  do so.
> 
> I don't think this is a good way to start any text. You should start
> with a short introduction on what's happening, when and how.
> 
> Right now the news item sounds like the world is going to suddenly fall
> apart for no specific reason. Reading it, I don't know what's changing,
> and how to check if it impacts me already (i.e. if it's 'do not
> reboot' kind of problem) and if it will impact me at all.
> 
>> You need to replace the /dev/disk/by-* paths in your fstab with the
>> equivalent information from the output of the blkid utility.
> 
> This is at least unclear, if not misguiding. I read it as 'blkid will
> give you fs info'. However, you're not telling me which of those
> information I can use and how. I should also point out that blkid
> supports multiple output formats.
> 
> I think it would be better if you explicitly listed the thingies
> supported by mount(1).
> 

Reading mgorny's response, I'm wondering if a news item really makes
any sense at all for this.  What's being done here is essentially a
warning/recommendation for users to act so they don't run into a
problem that's sort-of already there (at least in ~arch)...

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.





signature.asc
Description: OpenPGP digital signature

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

[Michał Górny]

On Tue, 25 Oct 2016 12:01:06 -0500
William Hubbs  wrote:

> Title: Inportant fstab update
> Author: William Hubbs 
> Content-Type: text/plain
> Posted: 2016-10-28
> Revision: 1
> News-Item-Format: 1.0
> 
> If you are not using /dev/disk/by-* paths in fstab, you do not need to
> take any action for this news item.
>
> If you are, it is very critical that you update fstab AS SOON AS
> POSSIBLE. Your system will become unbootable in the future if you do
> not  do so.

I don't think this is a good way to start any text. You should start
with a short introduction on what's happening, when and how.

Right now the news item sounds like the world is going to suddenly fall
apart for no specific reason. Reading it, I don't know what's changing,
and how to check if it impacts me already (i.e. if it's 'do not
reboot' kind of problem) and if it will impact me at all.

> You need to replace the /dev/disk/by-* paths in your fstab with the
> equivalent information from the output of the blkid utility.

This is at least unclear, if not misguiding. I read it as 'blkid will
give you fs info'. However, you're not telling me which of those
information I can use and how. I should also point out that blkid
supports multiple output formats.

I think it would be better if you explicitly listed the thingies
supported by mount(1).

> For example, here is out from blkid on my system:
> 
> # blkid
> 
> /dev/sda2: LABEL="boot" UUID="371432e9-7e6c-4205-9d4e-b23f6212e54b" 
> TYPE="ext2" PARTLABEL="boot" PARTUUID="2451c4a9-0405-425e-8d53-4567beae8651"
> /dev/sda3: LABEL="swap" UUID="d579b037-615c-441f-8f83-03e3c4919c21" 
> TYPE="swap" PARTLABEL="swap" PARTUUID="14c0d838-6dc5-4fdb-9a9d-c9523acdadc7"
> /dev/sda4: LABEL="root" UUID="5c496429-c836-4b23-9b11-7efd609c7cde" 
> TYPE="ext4" PARTLABEL="rootfs" PARTUUID="8a9765a4-7a20-4fa4-87e2-7a64d782e0d0"
> /dev/sda5: LABEL="home" UUID="bb63928e-67c0-4522-b4a0-66be507c2c2f" 
> TYPE="ext4" PARTLABEL="home" PARTUUID="000848d8-b51b-4671-8754-6d3b0c8df465"
> /dev/sda6: LABEL="var" UUID="fcb8046b-283b-45c0-a2c0-ae1001bebf82" 
> TYPE="ext4" PARTLABEL="var" PARTUUID="e1d8ccf6-3523-4c13-baae-e674ee0b43bf"
> /dev/sda1: PARTLABEL="grub" PARTUUID="700e8338-399f-4d33-9e15-73c85b136f3d"
> 
> My fstab can use any of the labels or ids, so I use labels:
> 
> LABEL=boot/boot   ext2defaults1 2
> LABEL=swapnoneswapsw  0 0
> LABEL=root/   ext4defaults
> 0 1
> LABEL=home/home   ext4defaults
> 0 1
> LABEL=var /varext4defaults
> 0 1

I'm afraid those examples are not really readable. Furthermore, I don't
see much point in pasting the whole fstab if all entries use LABEL=.
Try to keep them below 72 (or 80?) chars, skip blkid or paste just one
entry (wrapped), paste a minimal fstab just as example how the tags can
be used.

-- 
Best regards,
Michał Górny



pgpviFoJ7bTNB.pgp
Description: OpenPGP digital signature

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

[Francesco Riosa]

2016-10-25 19:15 GMT+02:00 William Hubbs :

> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> > On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
> wrote:
> > > If you are not using /dev/disk/by-* paths in fstab, you do not need to
> > take any action for this news item.
> > >
> > > If you are, it is very critical that you update fstab AS SOON AS
> > POSSIBLE. Your system will become unbootable in the future if you do
> > not  do so.
> >
> > Err, what is changing that will make systems unbootable?
> >
> > I am fairly certain systems running systemd will continue to work
> > properly with either syntax.
>
>  They probably will.
>
> > If this is about the udev-settle issue for OpenRC, I would urge you to
> > reconsider that.
>
>  There isn't anything to reconsider afaik. The problem is that
>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>  works regardless of which device manager  you use, so this is the safer
>  route.
>

please make also clear that UUID=... syntax will still work, one for all I
don't like labels and will gladly continu to use this format:
UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime  1 2



>
>  William
>
>

Re: [gentoo-dev] LLVM News item

[Michał Górny]

On Tue, 25 Oct 2016 20:02:26 +
Joakim Tjernlund  wrote:

> On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
> > On 25/10/16 03:32 PM, Ian Stakenvicius wrote:  
> > > 
> > > On 25/10/16 03:08 PM, Joakim Tjernlund wrote:  
> > > > 
> > > > On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:  
> > > > > 
> > > > > On Tue, 25 Oct 2016 17:32:22 +
> > > > > Joakim Tjernlund  wrote:
> > > > >   
> > > > > > 
> > > > > > 
> > > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and 
> > > > > > read:
> > > > > > ..
> > > > > > In order to enable all targets, add the following to your
> > > > > > /etc/portage/package.use or equivalent file:
> > > > > > 
> > > > > >   sys-devel/llvm LLVM_TARGETS: *
> > > > > >   sys-devel/clang LLVM_TARGETS: *
> > > > > > ...
> > > > > > 
> > > > > > I would like to control such variables(LLVM_TARGETS) through the 
> > > > > > profile as
> > > > > > well but it seems not supported?  
> > > > > 
> > > > > Why not? We're already setting the defaults in profiles, and you can 
> > > > > do
> > > > > whatever you want in your own profile. The news item is focused on
> > > > > regular users, so it covers the usual configuration files rather than
> > > > > creating custom profiles.
> > > > >   
> > > > 
> > > > How? in my profile(which inherits 
> > > > gentoo:default/linux/amd64/13.0/desktop) I just tested to add:
> > > > # > svn diff
> > > > Index: package.use
> > > > ===
> > > > --- package.use (revision 1087)
> > > > +++ package.use (working copy)
> > > > @@ -1,3 +1,6 @@
> > > > +sys-devel/llvm LLVM_TARGETS: *
> > > > +sys-devel/clang LLVM_TARGETS: *
> > > > 
> > > > Then I get:
> > > > # > emerge -aNDuv world
> > > > --- Invalid USE flag for 'sys-devel/llvm' in 
> > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > 'LLVM_TARGETS:'
> > > > --- Invalid USE flag for 'sys-devel/llvm' in 
> > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > '*'
> > > > --- Invalid USE flag for 'sys-devel/clang' in 
> > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > 'LLVM_TARGETS:'
> > > > --- Invalid USE flag for 'sys-devel/clang' in 
> > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > '*'
> > > >   
> > > 
> > > Syntax error:
> > > 
> > > sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
> > > sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..  
> 
> This is standard USE flags, not the VAR: x y z syntax
> 
> > > 
> > > 
> > > You can't specify wildcards to enable groups of use flags.
> > > 
> > >   
> > 
> > Correction, the earlier syntax *is* supposed to work (and tested that
> > it works here, with VIDEO_CARDS)..  If I had to guess this probably
> > relates to an issue with the transmode overlay.
> >   
> 
> Hmm, are you saying that you can write:
>   x11-base/xorg-drivers VIDEO_CARDS: intel radeon
> in your profile?
> 
> Any idea what my issue might be?

I don't know, it might be supported in portage-2 profile format. You
can use the long syntax, or set LLVM_TARGETS in profile's
make.defaults. Look through the Portage manuals.

-- 
Best regards,
Michał Górny



pgpBvhCet6wOp.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Ian Stakenvicius]

On 25/10/16 04:02 PM, Joakim Tjernlund wrote:
> On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
>> On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
>>>
>>> On 25/10/16 03:08 PM, Joakim Tjernlund wrote:

 On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
>
> On Tue, 25 Oct 2016 17:32:22 +
> Joakim Tjernlund  wrote:
>
>>
>>
>> Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
>> ..
>> In order to enable all targets, add the following to your
>> /etc/portage/package.use or equivalent file:
>>
>>   sys-devel/llvm LLVM_TARGETS: *
>>   sys-devel/clang LLVM_TARGETS: *
>> ...
>>
>> I would like to control such variables(LLVM_TARGETS) through the profile 
>> as
>> well but it seems not supported?
>
> Why not? We're already setting the defaults in profiles, and you can do
> whatever you want in your own profile. The news item is focused on
> regular users, so it covers the usual configuration files rather than
> creating custom profiles.
>

 How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) 
 I just tested to add:
 # > svn diff
 Index: package.use
 ===
 --- package.use(revision 1087)
 +++ package.use(working copy)
 @@ -1,3 +1,6 @@
 +sys-devel/llvm LLVM_TARGETS: *
 +sys-devel/clang LLVM_TARGETS: *

 Then I get:
 # > emerge -aNDuv world
 --- Invalid USE flag for 'sys-devel/llvm' in 
 '/var/lib/layman/transmode/profiles/gentoo64/package.use':
 'LLVM_TARGETS:'
 --- Invalid USE flag for 'sys-devel/llvm' in 
 '/var/lib/layman/transmode/profiles/gentoo64/package.use':
 '*'
 --- Invalid USE flag for 'sys-devel/clang' in 
 '/var/lib/layman/transmode/profiles/gentoo64/package.use':
 'LLVM_TARGETS:'
 --- Invalid USE flag for 'sys-devel/clang' in 
 '/var/lib/layman/transmode/profiles/gentoo64/package.use':
 '*'

>>>
>>> Syntax error:
>>>
>>> sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
>>> sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..
> 
> This is standard USE flags, not the VAR: x y z syntax
> 
>>>
>>>
>>> You can't specify wildcards to enable groups of use flags.
>>>
>>>
>>
>> Correction, the earlier syntax *is* supposed to work (and tested that
>> it works here, with VIDEO_CARDS)..  If I had to guess this probably
>> relates to an issue with the transmode overlay.
>>
> 
> Hmm, are you saying that you can write:
>   x11-base/xorg-drivers VIDEO_CARDS: intel radeon
> in your profile?
> 
> Any idea what my issue might be?
> 
>  Jocke
> 

In my profile as in /etc/portage/package.use/  , yes. Specifically I
tested VIDEO_CARDS: *

I *didn't* try to mess with my in-repo profile though.  Given that
repositories may well need to follow PMS, and the USE_EXPAND: * syntax
is a portage'ism, this is why they are being rejected in the
transmode-overlay case.  I certainly can't find an example of this
syntax in the gentoo repo.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Joakim Tjernlund]

On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
> On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
> > 
> > On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
> > > 
> > > On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
> > > > 
> > > > On Tue, 25 Oct 2016 17:32:22 +
> > > > Joakim Tjernlund  wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and 
> > > > > read:
> > > > > ..
> > > > > In order to enable all targets, add the following to your
> > > > > /etc/portage/package.use or equivalent file:
> > > > > 
> > > > >   sys-devel/llvm LLVM_TARGETS: *
> > > > >   sys-devel/clang LLVM_TARGETS: *
> > > > > ...
> > > > > 
> > > > > I would like to control such variables(LLVM_TARGETS) through the 
> > > > > profile as
> > > > > well but it seems not supported?
> > > > 
> > > > Why not? We're already setting the defaults in profiles, and you can do
> > > > whatever you want in your own profile. The news item is focused on
> > > > regular users, so it covers the usual configuration files rather than
> > > > creating custom profiles.
> > > > 
> > > 
> > > How? in my profile(which inherits 
> > > gentoo:default/linux/amd64/13.0/desktop) I just tested to add:
> > > # > svn diff
> > > Index: package.use
> > > ===
> > > --- package.use   (revision 1087)
> > > +++ package.use   (working copy)
> > > @@ -1,3 +1,6 @@
> > > +sys-devel/llvm LLVM_TARGETS: *
> > > +sys-devel/clang LLVM_TARGETS: *
> > > 
> > > Then I get:
> > > # > emerge -aNDuv world
> > > --- Invalid USE flag for 'sys-devel/llvm' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > 'LLVM_TARGETS:'
> > > --- Invalid USE flag for 'sys-devel/llvm' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > '*'
> > > --- Invalid USE flag for 'sys-devel/clang' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > 'LLVM_TARGETS:'
> > > --- Invalid USE flag for 'sys-devel/clang' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > '*'
> > > 
> > 
> > Syntax error:
> > 
> > sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
> > sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..

This is standard USE flags, not the VAR: x y z syntax

> > 
> > 
> > You can't specify wildcards to enable groups of use flags.
> > 
> > 
> 
> Correction, the earlier syntax *is* supposed to work (and tested that
> it works here, with VIDEO_CARDS)..  If I had to guess this probably
> relates to an issue with the transmode overlay.
> 

Hmm, are you saying that you can write:
  x11-base/xorg-drivers VIDEO_CARDS: intel radeon
in your profile?

Any idea what my issue might be?

 Jocke

Re: [gentoo-dev] LLVM News item

[Ian Stakenvicius]

On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
> On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
>> On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
>>> On Tue, 25 Oct 2016 17:32:22 +
>>> Joakim Tjernlund  wrote:
>>>

 Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
 ..
 In order to enable all targets, add the following to your
 /etc/portage/package.use or equivalent file:

   sys-devel/llvm LLVM_TARGETS: *
   sys-devel/clang LLVM_TARGETS: *
 ...

 I would like to control such variables(LLVM_TARGETS) through the profile as
 well but it seems not supported?
>>>
>>> Why not? We're already setting the defaults in profiles, and you can do
>>> whatever you want in your own profile. The news item is focused on
>>> regular users, so it covers the usual configuration files rather than
>>> creating custom profiles.
>>>
>>
>> How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) I 
>> just tested to add:
>> # > svn diff
>> Index: package.use
>> ===
>> --- package.use  (revision 1087)
>> +++ package.use  (working copy)
>> @@ -1,3 +1,6 @@
>> +sys-devel/llvm LLVM_TARGETS: *
>> +sys-devel/clang LLVM_TARGETS: *
>>
>> Then I get:
>> # > emerge -aNDuv world
>> --- Invalid USE flag for 'sys-devel/llvm' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>> 'LLVM_TARGETS:'
>> --- Invalid USE flag for 'sys-devel/llvm' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
>> --- Invalid USE flag for 'sys-devel/clang' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>> 'LLVM_TARGETS:'
>> --- Invalid USE flag for 'sys-devel/clang' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
>>
> 
> Syntax error:
> 
> sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
> sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..
> 
> 
> You can't specify wildcards to enable groups of use flags.
> 
> 

Correction, the earlier syntax *is* supposed to work (and tested that
it works here, with VIDEO_CARDS)..  If I had to guess this probably
relates to an issue with the transmode overlay.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Ian Stakenvicius]

On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
> On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
>> On Tue, 25 Oct 2016 17:32:22 +
>> Joakim Tjernlund  wrote:
>>
>>>
>>> Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
>>> ..
>>> In order to enable all targets, add the following to your
>>> /etc/portage/package.use or equivalent file:
>>>
>>>   sys-devel/llvm LLVM_TARGETS: *
>>>   sys-devel/clang LLVM_TARGETS: *
>>> ...
>>>
>>> I would like to control such variables(LLVM_TARGETS) through the profile as
>>> well but it seems not supported?
>>
>> Why not? We're already setting the defaults in profiles, and you can do
>> whatever you want in your own profile. The news item is focused on
>> regular users, so it covers the usual configuration files rather than
>> creating custom profiles.
>>
> 
> How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) I 
> just tested to add:
> # > svn diff
> Index: package.use
> ===
> --- package.use   (revision 1087)
> +++ package.use   (working copy)
> @@ -1,3 +1,6 @@
> +sys-devel/llvm LLVM_TARGETS: *
> +sys-devel/clang LLVM_TARGETS: *
> 
> Then I get:
> # > emerge -aNDuv world
> --- Invalid USE flag for 'sys-devel/llvm' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> 'LLVM_TARGETS:'
> --- Invalid USE flag for 'sys-devel/llvm' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
> --- Invalid USE flag for 'sys-devel/clang' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> 'LLVM_TARGETS:'
> --- Invalid USE flag for 'sys-devel/clang' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
> 

Syntax error:

sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..


You can't specify wildcards to enable groups of use flags.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Joakim Tjernlund]

On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
> On Tue, 25 Oct 2016 17:32:22 +
> Joakim Tjernlund  wrote:
> 
> > 
> > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
> > ..
> > In order to enable all targets, add the following to your
> > /etc/portage/package.use or equivalent file:
> > 
> >   sys-devel/llvm LLVM_TARGETS: *
> >   sys-devel/clang LLVM_TARGETS: *
> > ...
> > 
> > I would like to control such variables(LLVM_TARGETS) through the profile as
> > well but it seems not supported?
> 
> Why not? We're already setting the defaults in profiles, and you can do
> whatever you want in your own profile. The news item is focused on
> regular users, so it covers the usual configuration files rather than
> creating custom profiles.
> 

How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) I 
just tested to add:
# > svn diff
Index: package.use
===
--- package.use (revision 1087)
+++ package.use (working copy)
@@ -1,3 +1,6 @@
+sys-devel/llvm LLVM_TARGETS: *
+sys-devel/clang LLVM_TARGETS: *

Then I get:
# > emerge -aNDuv world
--- Invalid USE flag for 'sys-devel/llvm' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use':
'LLVM_TARGETS:'
--- Invalid USE flag for 'sys-devel/llvm' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
--- Invalid USE flag for 'sys-devel/clang' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use':
'LLVM_TARGETS:'
--- Invalid USE flag for 'sys-devel/clang' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'

Re: [gentoo-dev] LLVM News item

[Michał Górny]

On Tue, 25 Oct 2016 17:32:22 +
Joakim Tjernlund  wrote:

> Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
> ..
> In order to enable all targets, add the following to your
> /etc/portage/package.use or equivalent file:
> 
>   sys-devel/llvm LLVM_TARGETS: *
>   sys-devel/clang LLVM_TARGETS: *
> ...
> 
> I would like to control such variables(LLVM_TARGETS) through the profile as
> well but it seems not supported?

Why not? We're already setting the defaults in profiles, and you can do
whatever you want in your own profile. The news item is focused on
regular users, so it covers the usual configuration files rather than
creating custom profiles.

-- 
Best regards,
Michał Górny



pgp8S00hj7mdu.pgp
Description: OpenPGP digital signature

[gentoo-dev] LLVM News item

[Joakim Tjernlund]

Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
..
In order to enable all targets, add the following to your
/etc/portage/package.use or equivalent file:

  sys-devel/llvm LLVM_TARGETS: *
  sys-devel/clang LLVM_TARGETS: *
...

I would like to control such variables(LLVM_TARGETS) through the profile as
well but it seems not supported?

 Jocke

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

[William Hubbs]

On Tue, Oct 25, 2016 at 06:07:51PM +0100, James Le Cuirot wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> 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.
> 
> "Inportant" typo in the title.
> 
> Even before you posted this, I was wondering why this is a problem now?

This was changed in baselayout git years ago [1], and someone hit a race
condition caused by not making the changes in their fstab [2].

The "new" syntax is device-manager agnostic, and supported by both
util-linux and busybox, so imo it is the best route to take.

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=496562
[2] https://bugs.gentoo.org/show_bug.cgi?id=596346


signature.asc
Description: Digital signature

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

[Mike Gilbert]

On Tue, Oct 25, 2016 at 1:15 PM, William Hubbs  wrote:
> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
>> > If you are not using /dev/disk/by-* paths in fstab, you do not need to
>> take any action for this news item.
>> >
>> > If you are, it is very critical that you update fstab AS SOON AS
>> POSSIBLE. Your system will become unbootable in the future if you do
>> not  do so.
>>
>> Err, what is changing that will make systems unbootable?
>>
>> I am fairly certain systems running systemd will continue to work
>> properly with either syntax.
>
>  They probably will.
>
>> If this is about the udev-settle issue for OpenRC, I would urge you to
>> reconsider that.
>
>  There isn't anything to reconsider afaik. The problem is that
>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>  works regardless of which device manager  you use, so this is the safer
>  route.

People do not randomly switch device managers. If the symlinks
currently work for them, they can/should continue to work in the
future.

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

[William Hubbs]

On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
> > If you are not using /dev/disk/by-* paths in fstab, you do not need to
> take any action for this news item.
> >
> > If you are, it is very critical that you update fstab AS SOON AS
> POSSIBLE. Your system will become unbootable in the future if you do
> not  do so.
> 
> Err, what is changing that will make systems unbootable?
> 
> I am fairly certain systems running systemd will continue to work
> properly with either syntax.
 
 They probably will.

> If this is about the udev-settle issue for OpenRC, I would urge you to
> reconsider that.
 
 There isn't anything to reconsider afaik. The problem is that
 /dev/disk/by-* are only created by udev/eudev, but the other syntax
 works regardless of which device manager  you use, so this is the safer
 route.

 William



signature.asc
Description: Digital signature

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

[Ian Stakenvicius]

On 25/10/16 01:10 PM, Mike Gilbert wrote:
> 
> If this is about the udev-settle issue for OpenRC, I would urge you to
> reconsider that.
> 

+1



signature.asc
Description: OpenPGP digital signature

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

[Mike Gilbert]

On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
> I do have a question about the newsitem -- how do I make it display only
> for Linux users?

Once >=sys-apps/portage-2.3.2 is stable, you could use the new
Display-If-Profile wildcard syntax to display it only for
default/linux/*.

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

[Ian Stakenvicius]

On 25/10/16 01:07 PM, James Le Cuirot wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> 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.
> 
> "Inportant" typo in the title.
> 
> Even before you posted this, I was wondering why this is a problem now?
> 

Openrc's localmount doesn't wait for udev to finish anymore (partially
because udev doesn't 'settle' by default), and so instead of adding a
'use udev-settle' WilliamH decided to notify people to just not use
udev-triggered symlinks.

The LABEL= or UUID= syntax in /etc/fstab is more robust so it makes
sense for users to use that instead of these symlinks anyhow.




signature.asc
Description: OpenPGP digital signature

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

[Mike Gilbert]

On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
> If you are not using /dev/disk/by-* paths in fstab, you do not need to
take any action for this news item.
>
> If you are, it is very critical that you update fstab AS SOON AS
POSSIBLE. Your system will become unbootable in the future if you do
not  do so.

Err, what is changing that will make systems unbootable?

I am fairly certain systems running systemd will continue to work
properly with either syntax.

If this is about the udev-settle issue for OpenRC, I would urge you to
reconsider that.

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

[James Le Cuirot]

On Tue, 25 Oct 2016 12:01:06 -0500
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.

"Inportant" typo in the title.

Even before you posted this, I was wondering why this is a problem now?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

[gentoo-dev] newsitem: important fstab update

[William Hubbs]

All,

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?

Thanks,

William

Title: Inportant fstab update
Author: William Hubbs 
Content-Type: text/plain
Posted: 2016-10-28
Revision: 1
News-Item-Format: 1.0

If you are not using /dev/disk/by-* paths in fstab, you do not need to
take any action for this news item.

If you are, it is very critical that you update fstab AS SOON AS
POSSIBLE. Your system will become unbootable in the future if you do
not  do so.

You need to replace the /dev/disk/by-* paths in your fstab with the
equivalent information from the output of the blkid utility.

For example, here is out from blkid on my system:

# blkid

/dev/sda2: LABEL="boot" UUID="371432e9-7e6c-4205-9d4e-b23f6212e54b" TYPE="ext2" 
PARTLABEL="boot" PARTUUID="2451c4a9-0405-425e-8d53-4567beae8651"
/dev/sda3: LABEL="swap" UUID="d579b037-615c-441f-8f83-03e3c4919c21" TYPE="swap" 
PARTLABEL="swap" PARTUUID="14c0d838-6dc5-4fdb-9a9d-c9523acdadc7"
/dev/sda4: LABEL="root" UUID="5c496429-c836-4b23-9b11-7efd609c7cde" TYPE="ext4" 
PARTLABEL="rootfs" PARTUUID="8a9765a4-7a20-4fa4-87e2-7a64d782e0d0"
/dev/sda5: LABEL="home" UUID="bb63928e-67c0-4522-b4a0-66be507c2c2f" TYPE="ext4" 
PARTLABEL="home" PARTUUID="000848d8-b51b-4671-8754-6d3b0c8df465"
/dev/sda6: LABEL="var" UUID="fcb8046b-283b-45c0-a2c0-ae1001bebf82" TYPE="ext4" 
PARTLABEL="var" PARTUUID="e1d8ccf6-3523-4c13-baae-e674ee0b43bf"
/dev/sda1: PARTLABEL="grub" PARTUUID="700e8338-399f-4d33-9e15-73c85b136f3d"

My fstab can use any of the labels or ids, so I use labels:

LABEL=boot  /boot   ext2defaults1 2
LABEL=swap  noneswapsw  0 0
LABEL=root  /   ext4defaults
0 1
LABEL=home  /home   ext4defaults
0 1
LABEL=var   /varext4defaults
0 1


signature.asc
Description: Digital signature

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

[Michał Górny]

On Tue, 25 Oct 2016 11:47:05 -0400
Mike Gilbert  wrote:

> On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson  wrote:
> > That definition definitely excludes automake and autoconf (arguably gcc
> > should also excluded, under that definition, so the wiki might not be
> > 100% correct).  
> 
> gcc provides libstdc++.so.6, which is a necessary runtime component on
> most systems.

...for packages built with libstdc++ runtime. Unless you want to have
USE flags for that on every package, you just have to assume that
the user will keep the runtime for his compiler installed.

-- 
Best regards,
Michał Górny



pgpSjQoKypgdA.pgp
Description: OpenPGP digital signature

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

[Rich Freeman]

On Tue, Oct 25, 2016 at 11:53 AM, Ulrich Mueller  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

[Ulrich Mueller]

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

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

Ulrich


pgphv0JiErk6N.pgp
Description: PGP signature

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

[Mike Gilbert]

On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson  wrote:
> That definition definitely excludes automake and autoconf (arguably gcc
> should also excluded, under that definition, so the wiki might not be
> 100% correct).

gcc provides libstdc++.so.6, which is a necessary runtime component on
most systems.

Re: [gentoo-dev] need for autotools

[Kristian Fiskerstrand]

On 10/25/2016 05:35 PM, Ian Stakenvicius wrote:
> I forgot to mention that autotools.eclass brings in these dependencies
> as-needed, though, so I agree that they definitely are not required in
> the @system set.

Also keep in mind, they are already not part of @system, the question is
whether to remove the commented out lines to clean up the packages file.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] need for autotools

[Ian Stakenvicius]

On 25/10/16 11:34 AM, Ian Stakenvicius wrote:
> On 25/10/16 11:05 AM, Nick Vinson wrote:
>> On 10/25/2016 07:11 AM, Raymond Jennings wrote:
>>> Don't you need autoconf and automake to build a lot of packages?
>>
>> Theoretically no.  When autotools is used correctly, the release tarball
>> has no dependency on either.  That said, many people don't generate /
>> distribute a release tarball.
>>
>> 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".
>>
>> That definition definitely excludes automake and autoconf (arguably gcc
>> should also excluded, under that definition, so the wiki might not be
>> 100% correct).
>>
>> -Nicholas Vinson
>>
> 
> Unless you need to patch the build system, in which case you need to
> re-run autoconf/automake/etc (usually via 'eautoreconf').  And there's
> -plenty- of instances of that around as well.
> 

I forgot to mention that autotools.eclass brings in these dependencies
as-needed, though, so I agree that they definitely are not required in
the @system set.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] need for autotools (was: Commented packages in the @system set)

[Ian Stakenvicius]

On 25/10/16 11:05 AM, Nick Vinson wrote:
> On 10/25/2016 07:11 AM, Raymond Jennings wrote:
>> Don't you need autoconf and automake to build a lot of packages?
> 
> Theoretically no.  When autotools is used correctly, the release tarball
> has no dependency on either.  That said, many people don't generate /
> distribute a release tarball.
> 
> 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".
> 
> That definition definitely excludes automake and autoconf (arguably gcc
> should also excluded, under that definition, so the wiki might not be
> 100% correct).
> 
> -Nicholas Vinson
> 

Unless you need to patch the build system, in which case you need to
re-run autoconf/automake/etc (usually via 'eautoreconf').  And there's
-plenty- of instances of that around as well.





signature.asc
Description: OpenPGP digital signature

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

[Alexis Ballier]

On Tue, 25 Oct 2016 10:15:09 -0400
Rich Freeman  wrote:

> On Tue, Oct 25, 2016 at 9:56 AM, Alexis Ballier 
> wrote:
> > On Tue, 25 Oct 2016 09:17:08 -0400
> > Rich Freeman  wrote:
> >  
> >> 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?  
> >
> > 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.


This has nothing to do with APIs nor what it contains. This has to do
whether your program still does what you claim it does if you remove
the GPL parts.

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



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.

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

[Nick Vinson]

Theoretically no.  When autotools is used correctly, the release tarball
has no dependency on either.  That said, many people don't generate /
distribute a release tarball.

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

That definition definitely excludes automake and autoconf (arguably gcc
should also excluded, under that definition, so the wiki might not be
100% correct).

-Nicholas Vinson

On 10/25/2016 07:11 AM, Raymond Jennings wrote:
> Don't you need autoconf and automake to build a lot of packages?
> 
> On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand  > wrote:
> 
> On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> > On Mon, 24 Oct 2016 20:43:44 -0400
> > Michael Orlitzky mailto:m...@gentoo.org>> wrote:
> >
> >> Looking at profiles/base/packages, I see a bunch of lines that are
> >> commented out. For example,
> >>
> >>   *sys-apps/which
> >>   #*sys-devel/autoconf
> >>   #*sys-devel/automake
> >>   *sys-devel/binutils
> >>   #*sys-devel/bison
> >>   #*sys-devel/flex
> >>   *sys-devel/gcc
> >>
> >> Does anyone know why those are commented as opposed to just.. not
> >> there?
> >
> >
> > Those used to be in @system and were dropped at some point once ebuilds
> > had proper deps. My guess would be ppl wanted to keep them commented
> > out just in case it appeared to be a bad idea to drop them and be able
> > to "revert" easily. Nowadays, we can probably assume it was ok :)
> >
> 
> Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
> or QA has any objections.
> 
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> 
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> 



signature.asc
Description: OpenPGP digital signature

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

[Raymond Jennings]

Don't you need autoconf and automake to build a lot of packages?

On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand 
wrote:

> On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> > On Mon, 24 Oct 2016 20:43:44 -0400
> > Michael Orlitzky  wrote:
> >
> >> Looking at profiles/base/packages, I see a bunch of lines that are
> >> commented out. For example,
> >>
> >>   *sys-apps/which
> >>   #*sys-devel/autoconf
> >>   #*sys-devel/automake
> >>   *sys-devel/binutils
> >>   #*sys-devel/bison
> >>   #*sys-devel/flex
> >>   *sys-devel/gcc
> >>
> >> Does anyone know why those are commented as opposed to just.. not
> >> there?
> >
> >
> > Those used to be in @system and were dropped at some point once ebuilds
> > had proper deps. My guess would be ppl wanted to keep them commented
> > out just in case it appeared to be a bad idea to drop them and be able
> > to "revert" easily. Nowadays, we can probably assume it was ok :)
> >
>
> Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
> or QA has any objections.
>
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

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

[Alexis Ballier]

On Tue, 25 Oct 2016 07:11:48 -0700
Raymond Jennings  wrote:

> Don't you need autoconf and automake to build a lot of packages?

A lot. Once they're built, you dont need these anymore.

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

[Rich Freeman]

On Tue, Oct 25, 2016 at 9:56 AM, Alexis Ballier  wrote:
> On Tue, 25 Oct 2016 09:17:08 -0400
> Rich Freeman  wrote:
>
>> 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?
>
> 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] Commented packages in the @system set

[Kristian Fiskerstrand]

On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> On Mon, 24 Oct 2016 20:43:44 -0400
> Michael Orlitzky  wrote:
> 
>> Looking at profiles/base/packages, I see a bunch of lines that are
>> commented out. For example,
>>
>>   *sys-apps/which
>>   #*sys-devel/autoconf
>>   #*sys-devel/automake
>>   *sys-devel/binutils
>>   #*sys-devel/bison
>>   #*sys-devel/flex
>>   *sys-devel/gcc
>>
>> Does anyone know why those are commented as opposed to just.. not
>> there?
> 
> 
> Those used to be in @system and were dropped at some point once ebuilds
> had proper deps. My guess would be ppl wanted to keep them commented
> out just in case it appeared to be a bad idea to drop them and be able
> to "revert" easily. Nowadays, we can probably assume it was ok :)
> 

Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
or QA has any objections.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Alexis Ballier]

On Mon, 24 Oct 2016 20:43:44 -0400
Michael Orlitzky  wrote:

> Looking at profiles/base/packages, I see a bunch of lines that are
> commented out. For example,
> 
>   *sys-apps/which
>   #*sys-devel/autoconf
>   #*sys-devel/automake
>   *sys-devel/binutils
>   #*sys-devel/bison
>   #*sys-devel/flex
>   *sys-devel/gcc
> 
> Does anyone know why those are commented as opposed to just.. not
> there?


Those used to be in @system and were dropped at some point once ebuilds
had proper deps. My guess would be ppl wanted to keep them commented
out just in case it appeared to be a bad idea to drop them and be able
to "revert" easily. Nowadays, we can probably assume it was ok :)


Alexis.

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

[Alexis Ballier]

On Tue, 25 Oct 2016 09:17:08 -0400
Rich Freeman  wrote:

> 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?


The concept is "derived work": If your script cannot work without the
GPL binary, then it is derived work.


Alexis.

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

[Ulrich Mueller]

> On Tue, 25 Oct 2016, Rich Freeman wrote:

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

Having different licenses for ebuilds in the main tree would be a
nightmare, IMHO. It would make exchange of code between different
ebuilds much harder, if not impossible. Think of global issues like
the multilib conversion where similar code is used in many places.

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.

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

Ulrich


pgphH7C4pmqfQ.pgp
Description: PGP signature

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

[Rich Freeman]

On Tue, Oct 25, 2016 at 6:49 AM, Paweł Hajdan, Jr.
 wrote:
> On 25/10/2016 01:03, Rich Freeman wrote:
>> 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.
>
> How should that permission be documented?
>
> Is a statement the original author consents sufficient?
>

I suspect that the DCO is probably sufficient under the proposed new
policy.  If the Linux Foundation can stick code written by full-time
employees of the likes of Oracle into their repository with nothing
more than a Signed-off-by saying that whoever contributed it is sure
it is fine, we should probably consider that this ought to be good
enough for that.

Reading the DCO clauses b/c are designed to cover code from 3rd parties.

If you're asking about the current policy, I doubt we have anything so
formal in writing (which was one of the reasons I started the draft of
the new policy).  I'd suggest working with the license team or the
Trustees before bringing any code of questionable copyright status
into the tree.

-- 
Rich

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

[Paweł Hajdan , Jr .]

On 25/10/2016 01:03, Rich Freeman wrote:
> 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.

How should that permission be documented?

Is a statement the original author consents sufficient?

Paweł




signature.asc
Description: OpenPGP digital signature

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] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Kristian Fiskerstrand]

On 10/25/2016 01:28 AM, Rich Freeman wrote:
> On Mon, Oct 24, 2016 at 7:25 PM, William L. Thomson Jr.
>  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.
> 
+1

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Ulrich Mueller]

> On Mon, 24 Oct 2016, Rich Freeman wrote:

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

I disagree. Most of the time, the creation time of an ebuild is
meaningless, because they are usually copied from an earlier version
of the same package. And I guess that even most ebuilds for new
packages aren't written from scratch, but will be based on an existing
ebuild or on some template like skel.ebuild.

Because of this I also doubt if we could accurately trace authorship
of individual ebuilds. Maybe adding an AUTHORS files for the whole
tree would make more sense.

Ulrich


pgpV3QCozcCnV.pgp
Description: PGP signature