Dnia 2014-01-01, o godz. 23:28:54
Ulrich Mueller u...@gentoo.org napisał(a):
LICENSE=licenses of installed stuff
srcdist? ( licenses of unused stuff in distfiles )
This idea was discussed within the licenses team, and the overall
reaction was positive.
What do you
On Wed, 1 Jan 2014, Rich Freeman wrote:
On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky m...@gentoo.org
wrote:
I think a better solution here, since these files are *installed*,
is to introduce a new local flag (e.g. unfreeblobs) for the kernel
that would append to LICENSE by the
On Wed, 1 Jan 2014 23:28:54 +0100
Ulrich Mueller u...@gentoo.org wrote:
Hi,
According to GLEP 23 [1], the LICENSE variable regulates the software
that is installed on a system. There is however some ambiguity in
this: should it cover the actual files installed on the system, or
everything
On Thu, 2 Jan 2014 06:50:06 -0600
Ryan Hill dirtye...@gentoo.org wrote:
I've always believed that when it comes down to it all Gentoo basically does
is provide a link to some source code and a script to build and install it.
Unless we violate someone's license by redistributing that source
On Thu, 2 Jan 2014, Michał Górny wrote:
How does this interact with other flags? Say, I have:
LICENSES=A utils? ( B )
Do I do:
LICENSES=A utils? ( B ) srcdist? ( B )
Yes.
if they both are in the same tarball? Similarly, what if they come
from different tarball, with tarball B
On Wed, 01 Jan 2014, Michael Orlitzky wrote:
As I said in another reply, more license metadata is good and we
should make it available. But a USE flag that changes the meaning of
an important global variable is a little hacky, especially if it
doesn't solve a real problem within
On Thu, 2 Jan 2014, Ryan Hill wrote:
I've always believed that when it comes down to it all Gentoo
basically does is provide a link to some source code and a script
to build and install it. Unless we violate someone's license by
redistributing that source then we really don't have to worry
On 3 January 2014 01:50, Ryan Hill dirtye...@gentoo.org wrote:
Maybe we could add RESTRICT=srcdist which would cause ebuilds to save
their distfiles in a separate directory controlled by PORTDIR_NODIST or
something. If the variable is unset then it's business as usual.
I was going to
On 3 January 2014 02:18, Ulrich Mueller u...@gentoo.org wrote:
Maybe we could add RESTRICT=srcdist which would cause ebuilds to
save their distfiles in a separate directory controlled by
PORTDIR_NODIST or something. If the variable is unset then it's
business as usual.
Interesting idea,
On 01/02/2014 07:54 AM, Ulrich Mueller wrote:
On Wed, 01 Jan 2014, Michael Orlitzky wrote:
As I said in another reply, more license metadata is good and we
should make it available. But a USE flag that changes the meaning of
an important global variable is a little hacky, especially if it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/01/14 07:50 AM, Ryan Hill wrote:
Maybe we could add RESTRICT=srcdist which would cause ebuilds to
save their distfiles in a separate directory controlled by
PORTDIR_NODIST or something. If the variable is unset then it's
business as
On Thu, Jan 2, 2014 at 10:25 AM, Michael Orlitzky m...@gentoo.org wrote:
If you think the transition period for that is long, how long do you
think it will take for people to become aware of the magic USE flag and
begin populating the other-LICENSE-contained-within-LICENSE variable?
How long
On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius a...@gentoo.org wrote:
..or we could just do this, using the existing RESTRICT=mirror
that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR,
NODISTCACHEDIR defaults to DISTDIR; if RESTRICT=mirror then
distfiles are saved to
On 3 January 2014 05:28, Luis Ressel ara...@aixah.de wrote:
@Kent: Why do you think another distinction for RESTRICT=fetch is
neccessary? If it really is, it could also be integrated into this
solution, but I don't get the point -- either you're allowed to
redistribute it, or you're not.
On Thu, 2 Jan 2014, Luis Ressel wrote:
IMHO, this is the best solution proposed so far. It doesn't need a
new USE flag duplicating information which is already in RESTRICT
(or am I missing some corner cases here?), and it doesn't bother
those who don't care about this issue with new
On Fri, 3 Jan 2014 05:37:33 +1300
Kent Fredric kentfred...@gmail.com wrote:
Fair point. I was more seeing a pattern emerging and exploring where
that might lead.
Though I figure it a useful distinction for convenience sake.
Consider if you wanted to archive some files to make a subsequent
On Thu, 2 Jan 2014 17:53:45 +0100
Ulrich Mueller u...@gentoo.org wrote:
RESTRICT is somewhat complementary to LICENSE and cannot provide as
much information. Especially, RESTRICT=mirror doesn't say under
what license the restricted pieces are, and doesn't allow for
ACCEPT_LICENSE filtering.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/01/14 11:28 AM, Luis Ressel wrote:
On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius
a...@gentoo.org wrote:
..or we could just do this, using the existing RESTRICT=mirror
that's already in ebuilds -- have a DISTDIR and a
On Thu, 2 Jan 2014, Luis Ressel wrote:
RESTRICT is somewhat complementary to LICENSE and cannot provide as
much information. Especially, RESTRICT=mirror doesn't say under
what license the restricted pieces are, and doesn't allow for
ACCEPT_LICENSE filtering.
But is this detailed
On Thu, 02 Jan 2014 12:13:47 -0500
Ian Stakenvicius a...@gentoo.org wrote:
RESTRICT=fetch requires the user to do their own fetching; since
they're doing that, it should be pretty obvious that the distfile is
restricted somehow. Of course, they are still able to do whatever
they want, but I
On Thu, Jan 2, 2014 at 1:17 PM, Ulrich Mueller u...@gentoo.org wrote:
This is not primarily about distfiles mirroring, about about giving
users a choice what distfiles they will accept on their systems (for
whatever reasons, e.g. legal or philosophical). Besides, not all users
are under the
On Thu, 2 Jan 2014, Ulrich Mueller wrote:
This is not primarily about distfiles mirroring, about about giving
s/about about/but about/
users a choice what distfiles they will accept on their systems (for
whatever reasons, e.g. legal or philosophical). Besides, not all
users are under the
On Thu, 2 Jan 2014 19:17:50 +0100
Ulrich Mueller u...@gentoo.org wrote:
On Thu, 2 Jan 2014, Luis Ressel wrote:
RESTRICT is somewhat complementary to LICENSE and cannot provide as
much information. Especially, RESTRICT=mirror doesn't say under
what license the restricted pieces are, and
On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius a...@gentoo.org wrote:
On 02/01/14 07:50 AM, Ryan Hill wrote:
Maybe we could add RESTRICT=srcdist which would cause ebuilds to
save their distfiles in a separate directory controlled by
PORTDIR_NODIST or something. If the variable is
On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill dirtye...@gentoo.org wrote:
That's only possible if we enumerate every license in every distfile we
distribute, which I don't think is a good idea. Or at least not on the
basis of a theoretic user that might not actually exist.
Why would we need to do
On Thu, 2 Jan 2014 16:20:09 -0500
Rich Freeman ri...@gentoo.org wrote:
On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill dirtye...@gentoo.org wrote:
That's only possible if we enumerate every license in every distfile we
distribute, which I don't think is a good idea. Or at least not on the
basis
On Thu, 2 Jan 2014 16:07:22 -0600
Ryan Hill dirtye...@gentoo.org wrote:
On Thu, 2 Jan 2014 16:20:09 -0500
Rich Freeman ri...@gentoo.org wrote:
Personally I don't have any use for ACCEPT_LICENSE at all, and having
to specify the LICENSE for every single package in the tree is a lot
more
On Thu, 2 Jan 2014, Ryan Hill wrote:
In case it's helpful here's what FOSSology[1] has to say about some
common packages that people have uploaded to their demo server.
I don't get your point here. The licenses of a package have to be
checked in any case. Why would it be more complicated to
On Wed, 1 Jan 2014 23:14:11 +0100
sebastianlut...@gmx.de wrote:
+ slot.operator.missing: The ebuild depends on package with several...
^ a
--
Ryan Hillpsn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @
From: Sebastian Luther sebastianlut...@gmx.de
---
bin/repoman | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/bin/repoman b/bin/repoman
index d1542e9..cb1d620 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -78,7 +78,7 @@ from portage.output import
Changes:
* restrict check to runtime dependencies
* don't skip the check for atoms with slots, but only for slot+sub-slot
* fix typo found by Ryan
31 matches
Mail list logo
