Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Completely ban external commands in global scope

[Ulrich Mueller]

> On Fri, 8 Sep 2017, Robin H Johnson wrote:

> On Thu, Aug 31, 2017 at 10:45:42PM +0200, Michał Górny wrote:
>> +export PATH=/dev/null
> Minor nitpick: The Single UNIX spec says that PATH is a set of
> prefixes, and that they're treated as directories.
> http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html

> I think it might be good to use either a non-existing path, or a
> known empty directory (/var/empty), rather than /dev/null which DOES
> exist.

Is /var/empty standard? On my system here, it belongs to
net-misc/openssh.

Also any /dev/null/foo is guaranteed not to exist, so I don't see how
pathname resolution could possibly succeed when PATH is /dev/null.

Ulrich


pgpVY9QRev455.pgp
Description: PGP signature

Re: [gentoo-dev] Server hardaware give away (misc archs)

[Brendan Horan]

- On 7 Sep, 2017, at 10:53 PM, William L. Thomson Jr. wlt...@o-sinc.com 
wrote:

> 
> In an ideal sense, equipment like this would go to something like OSU
> OSL or some other hosting provider. Though there is the cost of
> bandwidth, power, and man power to service hardware issues. Not to
> mention rack, provision, etc.
> 
> Donate gear to Gentoo to be used/accessed by any dev, and maybe some
> others. I think Gentoo should have more internal resources available
> for developers to use. Then again I had lots of ideas for Gentoo
> 
> --
> William L. Thomson Jr.


Its all well and good to ask, I don't mind.
However systems like this need good , caring owners not a "board/trust " group.
I don't mean that in a disrespecting way.
They just need a little more attention and up keep.

A quick update :
j6750 has now been claimed by  : foxit

I am going to see if I can ship the j6750 and the power6 together.

Thanks everyone :)

Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[R0b0t1]

On Fri, Sep 8, 2017 at 2:57 PM, Alon Bar-Lev  wrote:
> On 8 September 2017 at 22:44, R0b0t1  wrote:
>>
>> On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev  wrote:
>> > Complex build system, hard to maintain, no dependencies in tree, upstream
>> > does not cooperate (Bug#630420).
>> > Removal in 30 days.
>> >
>>
>> I don't have any reason to disagree with this but I expected a
>> citation for those things to be in the bug you referenced. They're
>> not, and I don't see any bugs on the tracker.
>
> The effort of upgrade per each version is becoming greater.
> Previous and next versions required significant work, issues reported
> to upstream with the hope of a change, but most is rejected.
> The build system is so complex that is specific to gcc/ld and
> hard-coded dependencies locations and cflags/ldflags magic.
> Unless we have a very good reason (important dependency), my
> suggestion is to drop it.
> Do we have such a reason?
>

I don't think so. That is a very good description of a valid reason.

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[R0b0t1]

On Fri, Sep 8, 2017 at 8:33 PM, R0b0t1  wrote:
> On Fri, Sep 8, 2017 at 10:56 AM, Kent Fredric  wrote:
>> On Fri, 8 Sep 2017 10:11:51 -0500
>> R0b0t1  wrote:
>>
>>> Then I'm quite confused as to why people seem to be extremely attentive to
>>> copyright infringement (besides an immediate payout). In the US they cite
>>> the reasoning I gave, from memory.
>>>
>>> Maybe that was for trademarks?
>>
>> This is one of those problems where the nebulous term "IP" has infected
>> our thinking.
>>
>> Yes, US is very *copyright* infringement zealous.
>>
>> But Trademark and Copyright are very different beasts.
>>
>> Trademarks (read: brands, company names, company symbols, etc)  do
>> expire much shorter, but that's due to other reasons. Namely, that if
>> your company ceases to be doing business for 10 years, nobody is harmed
>> by people using a name of a company that doesn't exist, because
>> "Trademark protection" is largely a device to prevent competitors
>> claiming they're you, and to prevent competitors selling products
>> claiming you made them.
>>
>> Copyright (read: the right to publish, distribute, and sell) has a much
>> longer life as the results of that can be inheritable, eg: profits from
>> sale copyrighted works can go towards the estate of the author of those
>> works after the death of that author.
>>
>> There are documented *exceptions* to this, but they don't apply to us
>> as they apply to public institutions such as archives and libraries.
>>
>> And there are exceptions in cases of "fair use", which Gentoo does not
>> fall under.
>>
>> So, even though it is true that copyright expires, copy right expiry
>> dates are currently such that most juristictions don't have any
>> software that could conceivably exist that expires.
>>
>> If the expiry period is 50 years, and there's no software in
>> circulation older than 30, its kindof a moot point to argue software
>> that is less than 10 years old might have expired.
>>
>
> There's nothing in this though that says a copyright couldn't be
> weakened by failure to enforce claims against infringers. However, it
> happens that copyright law allows selective enforcement.
>
>>> >> Sir, please see my above comment about building ballistic missiles.
>>> >> It may be important for the Gentoo Foundation to add a disclaimer
>>> >> similar to the one I mentioned. I would hate for the Foundation or
>>> >> any of its administrators or contributors to be found guilty of
>>> >> aiding and abetting terrorists.
>>> >
>>> > Yeah. Stop trolling, please.
>>> >
>>>
>>> I am being completely serious. You can find such a clause in the iTunes
>>> license.
>>>
>>> If it seems ridiculous please reconsider the subject in question.
>>
>> I'm not sure how enforceable that clause is as a License.
>>
>> As a Warranty, sure.
>>
>
> The point isn't to be practically enforceable. If someone put their
> mind to using iTunes to make an ICBM I'm sure no one could stop them.
> The point is that Apple has now disclaimed liability for terrorist
> acts associated with iTunes in a very legally important way, which I
> believe is related to export restrictions (the item of interest likely
> being the cryptography portions of the digital restrictions management
> code).
>
>> "if you use it for this, don't blame us if bad things happen, we told
>> you not to"
>>
>
> There's a myriad of laws that duplicate the intent of the basic laws
> against property damage and taking life.
>

My apologies. In my dimwittedness I forgot to finish this section.

There's a lot of overlapping laws that duplicate things already in
existence. Likewise, people keep attempting to disclaim whatever
liability the law tells them they have in shrinkwrap contracts.

A good example is Li-Ion batteries. Did you know you're supposed to
watch them and not let them out of your sight while charging? If you
leave them out of your sight or do not take additional precautions
that no reasonable person I know would take, then the manufacturer
claims they are not responsible for property damage (read: fires) due
to their product's defects.

However, in fairly recent memory, the fires cause by Samsung phones
were being blamed on Samsung, and other smaller suits have been won
against battery manufacturers.

>> Also, those are typically things that fall under "National Laws" and it
>> doesn't really make sense to have to explicitly articulate in a
>> software license that its intended use is to be done within the scope
>> of your local governing laws.
>>
>> You're bound to follow local law regardless of whether you accept or
>> reject a given license. So, its kinda moot.
>>
>
> It is my understanding that this realization supports the view that
> the link should be left in. It's up to the user of the software, radio
> broadcasting kit, car, etc, to use the item in a responsible manner.
>
> I am worried about ceding rights where it is not necessary to do so. A
> good analogue to 

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[R0b0t1]

On Fri, Sep 8, 2017 at 10:56 AM, Kent Fredric  wrote:
> On Fri, 8 Sep 2017 10:11:51 -0500
> R0b0t1  wrote:
>
>> Then I'm quite confused as to why people seem to be extremely attentive to
>> copyright infringement (besides an immediate payout). In the US they cite
>> the reasoning I gave, from memory.
>>
>> Maybe that was for trademarks?
>
> This is one of those problems where the nebulous term "IP" has infected
> our thinking.
>
> Yes, US is very *copyright* infringement zealous.
>
> But Trademark and Copyright are very different beasts.
>
> Trademarks (read: brands, company names, company symbols, etc)  do
> expire much shorter, but that's due to other reasons. Namely, that if
> your company ceases to be doing business for 10 years, nobody is harmed
> by people using a name of a company that doesn't exist, because
> "Trademark protection" is largely a device to prevent competitors
> claiming they're you, and to prevent competitors selling products
> claiming you made them.
>
> Copyright (read: the right to publish, distribute, and sell) has a much
> longer life as the results of that can be inheritable, eg: profits from
> sale copyrighted works can go towards the estate of the author of those
> works after the death of that author.
>
> There are documented *exceptions* to this, but they don't apply to us
> as they apply to public institutions such as archives and libraries.
>
> And there are exceptions in cases of "fair use", which Gentoo does not
> fall under.
>
> So, even though it is true that copyright expires, copy right expiry
> dates are currently such that most juristictions don't have any
> software that could conceivably exist that expires.
>
> If the expiry period is 50 years, and there's no software in
> circulation older than 30, its kindof a moot point to argue software
> that is less than 10 years old might have expired.
>

There's nothing in this though that says a copyright couldn't be
weakened by failure to enforce claims against infringers. However, it
happens that copyright law allows selective enforcement.

>> >> Sir, please see my above comment about building ballistic missiles.
>> >> It may be important for the Gentoo Foundation to add a disclaimer
>> >> similar to the one I mentioned. I would hate for the Foundation or
>> >> any of its administrators or contributors to be found guilty of
>> >> aiding and abetting terrorists.
>> >
>> > Yeah. Stop trolling, please.
>> >
>>
>> I am being completely serious. You can find such a clause in the iTunes
>> license.
>>
>> If it seems ridiculous please reconsider the subject in question.
>
> I'm not sure how enforceable that clause is as a License.
>
> As a Warranty, sure.
>

The point isn't to be practically enforceable. If someone put their
mind to using iTunes to make an ICBM I'm sure no one could stop them.
The point is that Apple has now disclaimed liability for terrorist
acts associated with iTunes in a very legally important way, which I
believe is related to export restrictions (the item of interest likely
being the cryptography portions of the digital restrictions management
code).

> "if you use it for this, don't blame us if bad things happen, we told
> you not to"
>

There's a myriad of laws that duplicate the intent of the basic laws
against property damage and taking life.

> Also, those are typically things that fall under "National Laws" and it
> doesn't really make sense to have to explicitly articulate in a
> software license that its intended use is to be done within the scope
> of your local governing laws.
>
> You're bound to follow local law regardless of whether you accept or
> reject a given license. So, its kinda moot.
>

It is my understanding that this realization supports the view that
the link should be left in. It's up to the user of the software, radio
broadcasting kit, car, etc, to use the item in a responsible manner.

I am worried about ceding rights where it is not necessary to do so. A
good analogue to the situation at hand is crowdfunded electronics
projects that try to be FCC compliant, or delay shipping to obtain FCC
compliance. They don't need to. They're almost always a product not
intended for end users or an incomplete product. This makes me afraid,
sir, because it may be the case in the future I can not produce any
electronic equipment on my own.

Likewise, being unable to tell someone where to download something is
another situation that makes me afraid.

> If your government goes and uses your software for military
> applications despite your license saying "don't", I'm not really sure
> you'll have much in the way of recourse.
>

I'm pretty sure it would be one of the rare times, at least in the US,
that the government does not have sovereign immunity.

> If it was that simple I'd just start putting license terms that
> prohibits people from using software I wrote as part of a state
> approved mass surveillance platform
>

If you did this the military 

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Kristian Fiskerstrand]

On 09/08/2017 11:19 PM, Rich Freeman wrote:
> FYI - if anybody does want to make any comments on the proposed
> devmanual changes to implement the new tags please comment at:
> 
> https://github.com/gentoo/devmanual.gentoo.org/pull/72
> 
> For that matter, if you want to even know what the proposed changes
> are you should also visit the link.

This violates the gentoo social contract, please keep the discussion on
the mailing list

-- 
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-portage-dev] [PATCH] ebuild.sh: Completely ban external commands in global scope

[Robin H. Johnson]

On Thu, Aug 31, 2017 at 10:45:42PM +0200, Michał Górny wrote:
> + export PATH=/dev/null
Minor nitpick: The Single UNIX spec says that PATH is a set of prefixes,
and that they're treated as directories.
http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html

I think it might be good to use either a non-existing path, or a known
empty directory (/var/empty), rather than /dev/null which DOES exist.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] New eclass vim-runtime

[Vadim A. Misbakh-Soloviov]

DEPENDS part and "binary" function makes me sad panda:
they assumes there are no "vims" exist, while there is at least `vim-qt` 
(well, actually that one is dropped from gentoo) and `neovim-qt` (and that one 
is in overlays, but anyway), and so on.

I think, it'd be nice to somehow avoid exact binary names matching (just as 
exact package names), or, uhm... make it extendable somehow?

[gentoo-dev] [RFC] New eclass vim-runtime

[Aric Belsito]

This is really messy at the moment because I'm not sure whether the vim
team is interested, and I didn't want to put in the effort if it's just
going to be rejected, but I'm posting what I have here to start some
kind of discussion.

At the moment functions/other things need to be described, among other
issues. I have not yet tested to see if everything is still working with
vim, though I believe it works with neovim.

I'm also adding a patch file for vim-plugin.eclass, vim-doc.eclass and
vim-spell.eclass

I have a bug open on the bugtracker as well:
https://bugs.gentoo.org/612644

-- 
Aric Belsito
>From 08411b7ade20df1138c28b9a70679b7acf350f87 Mon Sep 17 00:00:00 2001
From: Aric Belsito 
Date: Tue, 5 Sep 2017 14:21:08 -0700
Subject: [PATCH] vim-runtime.eclass: new eclass

Gentoo-Bug: https://bugs.gentoo.org/612644
---
 eclass/vim-doc.eclass | 40 
 eclass/vim-plugin.eclass  | 31 +--
 eclass/vim-spell.eclass   |  8 ++--
 4 files changed, 39 insertions(+), 40 deletions(-)
 create mode 100644 eclass/vim-runtime.eclass

diff --git a/eclass/vim-doc.eclass b/eclass/vim-doc.eclass
index 5f281eba25f2..c4fa9ed22a44 100644
--- a/eclass/vim-doc.eclass
+++ b/eclass/vim-doc.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2011 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 #
 # This eclass is used by vim.eclass and vim-plugin.eclass to update
@@ -10,22 +10,28 @@
 # DEPEND in vim-plugin or by whatever version of vim is being
 # installed by the eclass.
 
+inherit vim-runtime
+
+run_helptags() {
+	# Update tags; need a vim binary for this
+	if [[ -n "$1" ]]; then
+		einfo "Updating documentation tags in $2"
+		DISPLAY= $1 -u NONE -n \
+			'+set nobackup nomore' \
+			"+helptags $2/doc" \
+			'+qa!' /dev/null
+	fi
+}
 
 update_vim_helptags() {
 	has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
 	local vimfiles vim d s
 
 	# This is where vim plugins are installed
-	vimfiles="${EROOT}"/usr/share/vim/vimfiles
+	vimfiles="${EPREFIX}$(vimfiles_directory)"
 
 	if [[ $PN != vim-core ]]; then
-		# Find a suitable vim binary for updating tags :helptags
-		vim=$(type -P vim 2>/dev/null)
-		[[ -z "$vim" ]] && vim=$(type -P gvim 2>/dev/null)
-		[[ -z "$vim" ]] && vim=$(type -P kvim 2>/dev/null)
-		if [[ -z "$vim" ]]; then
-			ewarn "No suitable vim binary to rebuild documentation tags"
-		fi
+		vim="$(vim_binary)"
 	fi
 
 	# Make vim not try to connect to X. See :help gui-x11-start
@@ -59,14 +65,16 @@ update_vim_helptags() {
 		fi
 
 		# Update tags; need a vim binary for this
-		if [[ -n "$vim" ]]; then
-			einfo "Updating documentation tags in $d"
-			DISPLAY= $vim -u NONE -U NONE -T xterm -X -n -f \
-'+set nobackup nomore' \
-"+helptags $d/doc" \
-'+qa!' /dev/null
-		fi
+		run_helptags $vim $d
 	done
 
+	# For neovim, just run :helptags on the tag directory
+	if use nvim ; then
+		[[ -d $vimfiles/doc ]] || break
+
+		# Update tags; need a vim binary for this
+		run_helptags $vim $vimfiles
+	fi
+
 	[[ -n "${vim}" && -f "${vim}" ]] && rm "${vim}"
 }
diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
index cdc24a15cf6f..f99693aeeb11 100644
--- a/eclass/vim-plugin.eclass
+++ b/eclass/vim-plugin.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2016 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: vim-plugin.eclass
@@ -7,18 +7,13 @@
 # @BLURB: used for installing vim plugins
 # @DESCRIPTION:
 # This eclass simplifies installation of app-vim plugins into
-# /usr/share/vim/vimfiles.  This is a version-independent directory
+# $(vimfiles_directory).  This is a version-independent directory
 # which is read automatically by vim.  The only exception is
 # documentation, for which we make a special case via vim-doc.eclass.
 
-inherit vim-doc
+inherit vim-doc vim-runtime
 EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm
 
-VIM_PLUGIN_VIM_VERSION="${VIM_PLUGIN_VIM_VERSION:-7.3}"
-
-DEPEND="|| ( >=app-editors/vim-${VIM_PLUGIN_VIM_VERSION}
-	>=app-editors/gvim-${VIM_PLUGIN_VIM_VERSION} )"
-RDEPEND="${DEPEND}"
 if [[ ${PV} != * ]] ; then
 	SRC_URI="mirror://gentoo/${P}.tar.bz2
 		https://dev.gentoo.org/~radhermit/vim/${P}.tar.bz2;
@@ -27,7 +22,7 @@ SLOT="0"
 
 vim-plugin_src_install() {
 	has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
-	local f
+	local f vimfiles="${EPREFIX}$(vimfiles_directory)"
 
 	if use !prefix && [[ ${EUID} -eq 0 ]] ; then
 		ebegin "Fixing file permissions"
@@ -59,11 +54,11 @@ vim-plugin_src_install() {
 
 	# Install remainder of plugin
 	cd "${WORKDIR}"
-	dodir /usr/share/vim
-	mv "${S}" "${ED}"/usr/share/vim/vimfiles
+	dodir "$(dirname $vimfiles)"
+	mv "${S}" "${D%/}$vimfiles"
 
 	# Fix remaining bad permissions
-	chmod -R -x+X "${ED}"/usr/share/vim/vimfiles/ || die "chmod failed"
+	chmod -R -x+X "${D%/}$vimfiles" || die 

[gentoo-dev] Re: [PATCH] toolchain-funcs: Respect host vars for tc-getBUILD* when not cross

[Sergei Trofimovich]

On Fri,  8 Sep 2017 10:33:11 +0200
Michał Górny  wrote:

> Make tc-getBUILD* functions respect host variables (CC & co.) when
> not cross-compiling. This removes the necessity of overriding BUILD_*
> along with the regular variables on the systems that are not concerned
> about cross-compilation, and does not change the behavior for those
> which are.
> 
> Closes: https://bugs.gentoo.org/630282
> ---
>  eclass/toolchain-funcs.eclass | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index aeb6f7c70299..75fa638efff3 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -40,7 +40,13 @@ _tc-getPROG() {
>   export ${var}="${prog[*]}"
>   echo "${!var}"
>  }
> -tc-getBUILD_PROG() { _tc-getPROG CBUILD "BUILD_$1 $1_FOR_BUILD HOST$1" 
> "${@:2}"; }
> +tc-getBUILD_PROG() {
> + local vars="BUILD_$1 $1_FOR_BUILD HOST$1"
> + # respect host vars if not cross-compiling
> + # https://bugs.gentoo.org/630282
> + tc-is-cross-compiler || vars+=" $1"
> + _tc-getPROG CBUILD "${vars}" "${@:2}"
> +}
>  tc-getPROG() { _tc-getPROG CHOST "$@"; }
>  
>  # @FUNCTION: tc-getAR
> -- 
> 2.14.1
> 

Looks good. Worth adding actual ebuild name that failed for you.


-- 

  Sergei


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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Rich Freeman]

On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny  wrote:
>
> What do you think about it? Is there anything else that needs being
> covered?
>

FYI - if anybody does want to make any comments on the proposed
devmanual changes to implement the new tags please comment at:

https://github.com/gentoo/devmanual.gentoo.org/pull/72

For that matter, if you want to even know what the proposed changes
are you should also visit the link.

List replies seem to be discouraged.

I realize that some prefer to limit comments to media that are purely
open source.  I guess the FOSS Linux kernel provided /dev/null still
exists as an alternative.  Honestly, I'm not sure which of the options
are more likely to get read.

-- 
Rich

Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[Alon Bar-Lev]

On 8 September 2017 at 22:44, R0b0t1  wrote:
>
> On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev  wrote:
> > Complex build system, hard to maintain, no dependencies in tree, upstream
> > does not cooperate (Bug#630420).
> > Removal in 30 days.
> >
>
> I don't have any reason to disagree with this but I expected a
> citation for those things to be in the bug you referenced. They're
> not, and I don't see any bugs on the tracker.

The effort of upgrade per each version is becoming greater.
Previous and next versions required significant work, issues reported
to upstream with the hope of a change, but most is rejected.
The build system is so complex that is specific to gcc/ld and
hard-coded dependencies locations and cflags/ldflags magic.
Unless we have a very good reason (important dependency), my
suggestion is to drop it.
Do we have such a reason?

Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[R0b0t1]

On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev  wrote:
> Complex build system, hard to maintain, no dependencies in tree, upstream
> does not cooperate (Bug#630420).
> Removal in 30 days.
>

I don't have any reason to disagree with this but I expected a
citation for those things to be in the bug you referenced. They're
not, and I don't see any bugs on the tracker.

[gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[Alon Bar-Lev]

Complex build system, hard to maintain, no dependencies in tree, upstream
does not cooperate (Bug#630420).
Removal in 30 days.

[gentoo-dev] sys-auth/pam_pkcs11 masked for removal in 30 days

[Alon Bar-Lev]

Upstream no longer maintain (Bug#628908).
Removal in 30 days.

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Completely ban external commands in global scope

[Alec Warner]

Must be old age setting in :(

Thanks,

-A

On Fri, Sep 8, 2017 at 2:54 PM, Michał Górny  wrote:

> W dniu pią, 08.09.2017 o godzinie 14∶48 -0400, użytkownik Alec Warner
> napisał:
> > Why PATH=/dev/null vs export PATH=""
>
> +  # note: we can't use empty because it implies current directory
>
> >
> > On Thu, Sep 7, 2017 at 3:36 AM, Michał Górny  wrote:
> >
> > > Dnia 31 sierpnia 2017 22:45:42 CEST, "Michał Górny"  >
> > > napisał(a):
> > > > Set PATH to /dev/null when sourcing the ebuild for dependency
> > > > resolution
> > > > in order to prevent shell from finding external commands via PATH
> > > > lookup. While this does not prevent executing programs via full path,
> > > > it
> > > > should catch the majority of accidental uses.
> > > >
> > > > Closes: https://github.com/gentoo/portage/pull/199
> > > >
> > > > // Note: this can't be merged right now since we still have ebuilds
> > > > // calling external commands; see:
> > > > // https://bugs.gentoo.org/show_bug.cgi?id=629222
> > >
> > > Update: gentoo is green now
> > >
> > > > ---
> > > > bin/ebuild.sh | 6 +-
> > > > bin/isolated-functions.sh | 4 
> > > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/bin/ebuild.sh b/bin/ebuild.sh
> > > > index c23561651..94a44d534 100755
> > > > --- a/bin/ebuild.sh
> > > > +++ b/bin/ebuild.sh
> > > > @@ -80,8 +80,12 @@ else
> > > >   done
> > > >   unset funcs x
> > > >
> > > > +  # prevent the shell from finding external executables
> > > > +  # note: we can't use empty because it implies current
> directory
> > > > +  _PORTAGE_ORIG_PATH=${PATH}
> > > > +  export PATH=/dev/null
> > > >   command_not_found_handle() {
> > > > -  die "Command not found while sourcing ebuild: ${*}"
> > > > +  die "External commands disallowed while sourcing
> ebuild:
> > >
> > > ${*}"
> > > >   }
> > > > fi
> > > >
> > > > diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
> > > > index e320f7132..b28e44f18 100644
> > > > --- a/bin/isolated-functions.sh
> > > > +++ b/bin/isolated-functions.sh
> > > > @@ -121,6 +121,10 @@ __helpers_die() {
> > > > }
> > > >
> > > > die() {
> > > > +  # restore PATH since die calls basename & sed
> > > > +  # TODO: make it pure bash
> > > > +  [[ -n ${_PORTAGE_ORIG_PATH} ]] && PATH=${_PORTAGE_ORIG_PATH}
> > > > +
> > > >   set +x # tracing only produces useless noise here
> > > >   local IFS=$' \t\n'
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Michał Górny (by phone)
> > >
> > >
>
> --
> Best regards,
> Michał Górny
>
>
>

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Completely ban external commands in global scope

[Michał Górny]

W dniu pią, 08.09.2017 o godzinie 14∶48 -0400, użytkownik Alec Warner
napisał:
> Why PATH=/dev/null vs export PATH=""

+  # note: we can't use empty because it implies current directory

> 
> On Thu, Sep 7, 2017 at 3:36 AM, Michał Górny  wrote:
> 
> > Dnia 31 sierpnia 2017 22:45:42 CEST, "Michał Górny" 
> > napisał(a):
> > > Set PATH to /dev/null when sourcing the ebuild for dependency
> > > resolution
> > > in order to prevent shell from finding external commands via PATH
> > > lookup. While this does not prevent executing programs via full path,
> > > it
> > > should catch the majority of accidental uses.
> > > 
> > > Closes: https://github.com/gentoo/portage/pull/199
> > > 
> > > // Note: this can't be merged right now since we still have ebuilds
> > > // calling external commands; see:
> > > // https://bugs.gentoo.org/show_bug.cgi?id=629222
> > 
> > Update: gentoo is green now
> > 
> > > ---
> > > bin/ebuild.sh | 6 +-
> > > bin/isolated-functions.sh | 4 
> > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/bin/ebuild.sh b/bin/ebuild.sh
> > > index c23561651..94a44d534 100755
> > > --- a/bin/ebuild.sh
> > > +++ b/bin/ebuild.sh
> > > @@ -80,8 +80,12 @@ else
> > >   done
> > >   unset funcs x
> > > 
> > > +  # prevent the shell from finding external executables
> > > +  # note: we can't use empty because it implies current directory
> > > +  _PORTAGE_ORIG_PATH=${PATH}
> > > +  export PATH=/dev/null
> > >   command_not_found_handle() {
> > > -  die "Command not found while sourcing ebuild: ${*}"
> > > +  die "External commands disallowed while sourcing ebuild:
> > 
> > ${*}"
> > >   }
> > > fi
> > > 
> > > diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
> > > index e320f7132..b28e44f18 100644
> > > --- a/bin/isolated-functions.sh
> > > +++ b/bin/isolated-functions.sh
> > > @@ -121,6 +121,10 @@ __helpers_die() {
> > > }
> > > 
> > > die() {
> > > +  # restore PATH since die calls basename & sed
> > > +  # TODO: make it pure bash
> > > +  [[ -n ${_PORTAGE_ORIG_PATH} ]] && PATH=${_PORTAGE_ORIG_PATH}
> > > +
> > >   set +x # tracing only produces useless noise here
> > >   local IFS=$' \t\n'
> > > 
> > 
> > 
> > --
> > Best regards,
> > Michał Górny (by phone)
> > 
> > 

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Gordon Pettey]

On Fri, Sep 8, 2017 at 11:15 AM, Ciaran McCreesh <
ciaran.mccre...@googlemail.com> wrote:

> On Fri, 8 Sep 2017 11:10:54 -0500
> Gordon Pettey  wrote:
> > And this is all irrelevant since the copyright applies to the
> > software, not the location you obtain it from. Nobody commits
> > copyright infringement by buying a used book from their neighbour
> > instead of buying it at Half Price Books.
> > Distribution licenses are another thing, but if the original SRC_URI
> > from the ebuild wasn't RESTICT="fetch", what makes anybody think that
> > would suddenly change with a new SRC_URI?
>
> Are you a lawyer, and does this constitute legal advice? I ask, because
> the lawyers I've spoken to about a similar issue seemed to think it
> wasn't that simple.
>

Since - just like you - I'm not lawyer, I have no obligation whatsoever to
say whether or not anything I say is legal advice. And so you can avoid
this the-sky-is-falling legal nonsense, here's yet another SRC_URI from the
author himself:
https://onedrive.live.com/download?resid=14984242E2F69941!25302=!AEUh_81RXMobRbo=file%2cexe
See http://www.familyofadam.com/mod/nwn_downloads.aspx

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Kent Fredric]

On Fri, 8 Sep 2017 11:10:54 -0500
Gordon Pettey  wrote:

> Distribution licenses are another thing, but if the original SRC_URI from
> the ebuild wasn't RESTICT="fetch", what makes anybody think that would
> suddenly change with a new SRC_URI?

I've seen terms that state people aren't allowed to re-host anything,
and may only obtain a resource from a specified URL
( including details of how people should link to the resource )

Its a bit contorted, but fits the bill.



pgp9EHkMlbR5x.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Ciaran McCreesh]

On Fri, 8 Sep 2017 11:10:54 -0500
Gordon Pettey  wrote:
> And this is all irrelevant since the copyright applies to the
> software, not the location you obtain it from. Nobody commits
> copyright infringement by buying a used book from their neighbour
> instead of buying it at Half Price Books.
> Distribution licenses are another thing, but if the original SRC_URI
> from the ebuild wasn't RESTICT="fetch", what makes anybody think that
> would suddenly change with a new SRC_URI?

Are you a lawyer, and does this constitute legal advice? I ask, because
the lawyers I've spoken to about a similar issue seemed to think it
wasn't that simple.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Gordon Pettey]

And this is all irrelevant since the copyright applies to the software, not
the location you obtain it from. Nobody commits copyright infringement by
buying a used book from their neighbour instead of buying it at Half Price
Books.
Distribution licenses are another thing, but if the original SRC_URI from
the ebuild wasn't RESTICT="fetch", what makes anybody think that would
suddenly change with a new SRC_URI?

On Fri, Sep 8, 2017 at 11:05 AM, Ciaran McCreesh <
ciaran.mccre...@googlemail.com> wrote:

> On Sat, 9 Sep 2017 03:56:38 +1200
> Kent Fredric  wrote:
> > > >> Sir, please see my above comment about building ballistic
> > > >> missiles. It may be important for the Gentoo Foundation to add a
> > > >> disclaimer similar to the one I mentioned. I would hate for the
> > > >> Foundation or any of its administrators or contributors to be
> > > >> found guilty of aiding and abetting terrorists.
> > > >
> > > > Yeah. Stop trolling, please.
> > > >
> > >
> > > I am being completely serious. You can find such a clause in the
> > > iTunes license.
> > >
> > > If it seems ridiculous please reconsider the subject in question.
> >
> > I'm not sure how enforceable that clause is as a License.
>
> Until recently, there was a clause in the Nauty licence prohibiting use
> in "military applications". This was sufficient for the highly paid
> lawyers who looked at it to recommend not redistributing Nauty as part
> of the GAP computer algebra system, because computer algebra could
> conceivably be used for blowing stuff up.
>
> --
> Ciaran McCreesh
>
>

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Ciaran McCreesh]

On Sat, 9 Sep 2017 03:56:38 +1200
Kent Fredric  wrote:
> > >> Sir, please see my above comment about building ballistic
> > >> missiles. It may be important for the Gentoo Foundation to add a
> > >> disclaimer similar to the one I mentioned. I would hate for the
> > >> Foundation or any of its administrators or contributors to be
> > >> found guilty of aiding and abetting terrorists.
> > >
> > > Yeah. Stop trolling, please.
> > >
> > 
> > I am being completely serious. You can find such a clause in the
> > iTunes license.
> > 
> > If it seems ridiculous please reconsider the subject in question.  
> 
> I'm not sure how enforceable that clause is as a License.

Until recently, there was a clause in the Nauty licence prohibiting use
in "military applications". This was sufficient for the highly paid
lawyers who looked at it to recommend not redistributing Nauty as part
of the GAP computer algebra system, because computer algebra could
conceivably be used for blowing stuff up.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Kent Fredric]

On Fri, 8 Sep 2017 10:11:51 -0500
R0b0t1  wrote:

> Then I'm quite confused as to why people seem to be extremely attentive to
> copyright infringement (besides an immediate payout). In the US they cite
> the reasoning I gave, from memory.
> 
> Maybe that was for trademarks?

This is one of those problems where the nebulous term "IP" has infected
our thinking.

Yes, US is very *copyright* infringement zealous.

But Trademark and Copyright are very different beasts.

Trademarks (read: brands, company names, company symbols, etc)  do
expire much shorter, but that's due to other reasons. Namely, that if
your company ceases to be doing business for 10 years, nobody is harmed
by people using a name of a company that doesn't exist, because
"Trademark protection" is largely a device to prevent competitors
claiming they're you, and to prevent competitors selling products
claiming you made them.

Copyright (read: the right to publish, distribute, and sell) has a much
longer life as the results of that can be inheritable, eg: profits from
sale copyrighted works can go towards the estate of the author of those
works after the death of that author.

There are documented *exceptions* to this, but they don't apply to us
as they apply to public institutions such as archives and libraries.

And there are exceptions in cases of "fair use", which Gentoo does not
fall under.

So, even though it is true that copyright expires, copy right expiry
dates are currently such that most juristictions don't have any
software that could conceivably exist that expires.

If the expiry period is 50 years, and there's no software in
circulation older than 30, its kindof a moot point to argue software
that is less than 10 years old might have expired.

> >> Sir, please see my above comment about building ballistic missiles.
> >> It may be important for the Gentoo Foundation to add a disclaimer
> >> similar to the one I mentioned. I would hate for the Foundation or
> >> any of its administrators or contributors to be found guilty of
> >> aiding and abetting terrorists.  
> >
> > Yeah. Stop trolling, please.
> >  
> 
> I am being completely serious. You can find such a clause in the iTunes
> license.
> 
> If it seems ridiculous please reconsider the subject in question.

I'm not sure how enforceable that clause is as a License.

As a Warranty, sure. 

"if you use it for this, don't blame us if bad things happen, we told
you not to"

Also, those are typically things that fall under "National Laws" and it
doesn't really make sense to have to explicitly articulate in a
software license that its intended use is to be done within the scope
of your local governing laws.

You're bound to follow local law regardless of whether you accept or
reject a given license. So, its kinda moot.

If your government goes and uses your software for military
applications despite your license saying "don't", I'm not really sure
you'll have much in the way of recourse.

If it was that simple I'd just start putting license terms that
prohibits people from using software I wrote as part of a state
approved mass surveillance platform



pgpR8fTo1LFd2.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[R0b0t1]

On Friday, September 8, 2017, Ulrich Mueller  wrote:
>> On Thu, 7 Sep 2017, R0b0t1  wrote:
>
>> Downloading does not imply committing a felony. As far as anyone can
>> tell it is impossible to prosecute someone for downloading something
>> they already own (regardless of what any EULA has claimed).
>
> Sure, if the user already has rightfully obtained the software then
> nothing can stop him from downloading it again.
>
>> Further, copyrights lapse if not enforced. Depending on how long
>> that download has been up the original rightsholder has forfeited
>> their claim to their work.
>
> Copyright expires no sooner than 50 years after the author's death:
> https://en.wikipedia.org/wiki/Berne_Convention
> In most countries that term is even longer, e.g. 70 years in the
> European Union.
>
> Also contrary to popular belief, there is no such concept as
> "abandonware". In some legislations, there are some provisions to
> allow archiving of orphan works, but only for public institutions
> (e.g. in the EU, museums and digital archives).
>

Then I'm quite confused as to why people seem to be extremely attentive to
copyright infringement (besides an immediate payout). In the US they cite
the reasoning I gave, from memory.

Maybe that was for trademarks?

>> Sir, please see my above comment about building ballistic missiles.
>> It may be important for the Gentoo Foundation to add a disclaimer
>> similar to the one I mentioned. I would hate for the Foundation or
>> any of its administrators or contributors to be found guilty of
>> aiding and abetting terrorists.
>
> Yeah. Stop trolling, please.
>

I am being completely serious. You can find such a clause in the iTunes
license.

If it seems ridiculous please reconsider the subject in question.

R0b0t1.

Re: [gentoo-dev] Categories for GUI stuff x11 and wayland

[William L. Thomson Jr.]

On Wed, 30 Aug 2017 14:01:08 -0400
"William L. Thomson Jr."  wrote:

> This is more food for thought to start a discussion on new category
> names. With Wayland becoming more of a reality every day. I think some
> of the x11-* categories may need to change. Stuff in there may not be
> bound to X and can run on Wayland or X.
> 
> Examples
> x11-libs/gtk+
> x11-terms/terminology
> 
> Not sure what better "universal" category names would be. But seems it
> maybe time for a discussion on such and some new categories and
> package moves. Given thus stuff can run under X or Wayland. Not sure
> x11 makes sense anymore.

One thing I forgot to mention, the x11-* would not go away just shrink.

General stuff that is for say X11 or Wayland would go into the "new"
categories. Anything that is X specific, like xorg, drivers, xephyr, etc
would remain in the location and category it presently resides.

This would reduce the amount of package moves, but still would be fair
amount. With some being pretty major like moving GTK+. EFL ended up in
dev-libs, and I am not sure if that is the proper location, though it
does cross many categories. GTK+ and  FLTK are in x11-libs. I think EFL
ended up in dev-libs due to Wayland situation.

P.S.
I myself am not super excited about wayland. I see reliving a lot of
the problems of the past. Not to mention wayland supporting what X can
do now, today. Many things still in the works for most any
supporting Wayland, dual display, different resolutions etc. I gave it
a nickname  "Waitland" as you have to WAIT for wayland to support this
or that Either way it seems inevitable... Even if years off from
being the daily driver.

-- 
William L. Thomson Jr.


pgp3CaqGR0WTn.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Ulrich Mueller]

> On Fri, 8 Sep 2017, Ciaran McCreesh wrote:

> On Fri, 08 Sep 2017 14:54:10 +0200
> Michał Górny  wrote:
>> It only explains how the functions parse stuff (except for ver_test
>> which uses PMS rules). They are by definition supposed to work with
>> random upstream versions.

> This sounds like the sort of thing that could go horribly wrong...
> I didn't design versionator to work with arbitrary messy stuff since
> the main use is in manipulating Gentoo PV versions.

If we would strictly follow PMS wording there, then for _alpha, _beta,
_p, etc. the underscore would be part of the component. Also in a
suffix like _p2, _p and 2 would be separate components. However, with
versionator.eclass:

   get_version_components 3.0_p2 -> 3 0 p2

So even there, the underscore is taken as a separator. I don't say
that this behaviour is bad, only that it doesn't strictly follow PMS
rules.

> Where are these other versions coming from?

They occur as output of those functions, and I think that e.g.
splitting 1.2_rc3 into components "1", "2", "rc", and "3" with
separators ".", "_", and "" makes more sense than treating "_rc" as an
atomic block.

Ulrich


pgp5MBdlalyKO.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Ulrich Mueller]

> On Fri, 8 Sep 2017, Michał Górny wrote:

> +# A version component can either consist purely of digits ([0-9]+) or
> +# purely of uppercase and lowercase letters ([a-zA-Z]+). Any other
> +# character is treated as a version separator.

Minor documentation nitpick (sorry for not noticing this earlier):
A version separator is not necessarily a single character. So the
wording should be along the lines of:

# A version component can either consist purely of digits ([0-9]+) or
# purely of uppercase and lowercase letters ([A-Za-z]+).  A version
# separator is either a string of any other characters ([^A-Za-z0-9]+),
# or it occurs at the transition between a sequence of letters and a
# sequence of digits, or vice versa.  In the latter case, the version
# separator is an empty string.

Ulrich


pgpZ8Fezt6h0N.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Ciaran McCreesh]

On Fri, 08 Sep 2017 14:54:10 +0200
Michał Górny  wrote:
> W dniu pią, 08.09.2017 o godzinie 12∶48 +, użytkownik Martin Vaeth
> napisał:
> > Michał Górny  wrote:  
> > > +#   1.2b-alpha4 -> 1 . 2 '' b - alpha '' 4  
> > 
> > Is this only to explain the syntax or are there plans to
> > extend the allowed versions for pms?
> 
> It only explains how the functions parse stuff (except for ver_test
> which uses PMS rules). They are by definition supposed to work with
> random upstream versions.

This sounds like the sort of thing that could go horribly wrong... I
didn't design versionator to work with arbitrary messy stuff since the
main use is in manipulating Gentoo PV versions. Where are these other
versions coming from?

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Michał Górny]

W dniu pią, 08.09.2017 o godzinie 12∶48 +, użytkownik Martin Vaeth
napisał:
> Michał Górny  wrote:
> > +#   1.2b-alpha4 -> 1 . 2 '' b - alpha '' 4
> 
> Is this only to explain the syntax or are there plans to
> extend the allowed versions for pms?
> 

It only explains how the functions parse stuff (except for ver_test
which uses PMS rules). They are by definition supposed to work with
random upstream versions.

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libclc/

[Michał Górny]

W dniu pią, 08.09.2017 o godzinie 12∶38 +, użytkownik Chí-Thanh
Christopher Nguyễn napisał:
> commit: 87929d9f6bfe62770cb13547583425e6f2755a59
> Author: Chí-Thanh Christopher Nguyễn  gentoo  org>
> AuthorDate: Fri Sep  8 12:38:21 2017 +
> Commit: Chí-Thanh Christopher Nguyễn  gentoo  org>
> CommitDate: Fri Sep  8 12:38:21 2017 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=87929d9f
> 
> dev-libs/libclc: depend on compatible llvm versions
> 
> Bug: https://bugs.gentoo.org/show_bug.cgi?id=612258
> 
> Package-Manager: Portage-2.3.6, Repoman-2.3.1
> 
>  dev-libs/libclc/libclc-0.2.0_pre20160209.ebuild | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/dev-libs/libclc/libclc-0.2.0_pre20160209.ebuild 
> b/dev-libs/libclc/libclc-0.2.0_pre20160209.ebuild
> index f496187c41d..d25125f957c 100644
> --- a/dev-libs/libclc/libclc-0.2.0_pre20160209.ebuild
> +++ b/dev-libs/libclc/libclc-0.2.0_pre20160209.ebuild
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2016 Gentoo Foundation
> +# Copyright 1999-2017 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
>  EAPI=5
> @@ -28,8 +28,10 @@ KEYWORDS="amd64 x86"
>  IUSE=""
>  
>  RDEPEND="
> - >=sys-devel/clang-3.7
> - >=sys-devel/llvm-3.7"
> + >=sys-devel/clang-3.7:*
> + >=sys-devel/llvm-3.7:*
> +  +   DEPEND="${RDEPEND}
>   ${PYTHON_DEPS}"
>  
> 

Now you've explicitly told Portage to install two different slots. Use
:0 instead (<4 is not slotted).

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Martin Vaeth]

Michał Górny  wrote:
> +#   1.2b-alpha4 -> 1 . 2 '' b - alpha '' 4

Is this only to explain the syntax or are there plans to
extend the allowed versions for pms?

There is a reason why pms currently does not allow "-" as separators
within versions (with the exception of -r):

With this general syntax, you would have a hard time to split
into name and version for e.g.
media-fonts/font-bitstream-75dpi-1.0.3

(Currently the version starts at the latest /-[0-9]/ match.)

Also the ordering needs a discussion when version strings are
allowed which are not covered by PMS. Note that e.g.
02 > 1 while 1.02 < 1.1
Is it still "correct" to have 1-02 < 1-1?

[gentoo-dev] [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Michał Górny]

EAPI 7 is introducing new version manipulation and comparison functions
that aim to replace versionator.eclass. This eclass provides an 'early
adopter' versions of those routines.

It serves two goals:

a. getting wider review and some real-life testing before
the specification is set in stone, and

b. making it possible to adapt ebuilds to the new routines early,
reducing the future work of EAPI 7 porting.

For more details on the new logic, please see the eclass documentation.
Long story short, we are introducing three functions:

1. ver_cut -- to get substrings of the version string,

2. ver_rs -- to replace version separators via indices,

3. ver_test -- to compare two version numbers.

The third function is not implemented in the eclass. It's meant to reuse
the algorithms from the package manager, and the final implementation
will most likely reuse the code from the package manager (e.g. via IPC).
---
 eclass/eapi7-ver.eclass | 181 
 eclass/tests/eapi7-ver.sh   |  65 +
 eclass/tests/eapi7-ver:benchmark.sh |  76 +++
 3 files changed, 322 insertions(+)
 create mode 100644 eclass/eapi7-ver.eclass
 create mode 100755 eclass/tests/eapi7-ver.sh
 create mode 100755 eclass/tests/eapi7-ver:benchmark.sh

diff --git a/eclass/eapi7-ver.eclass b/eclass/eapi7-ver.eclass
new file mode 100644
index ..c82da6192c94
--- /dev/null
+++ b/eclass/eapi7-ver.eclass
@@ -0,0 +1,181 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: eapi7-ver.eclass
+# @MAINTAINER:
+# PMS team 
+# @AUTHOR:
+# Ulrich Müller 
+# Michał Górny 
+# @BLURB: Testing implementation of EAPI 7 version manipulators
+# @DESCRIPTION:
+# A stand-alone implementation of the version manipulation functions
+# aimed for EAPI 7. Intended to be used for wider testing of
+# the proposed functions and to allow ebuilds to switch to the new
+# model early, with minimal change needed for actual EAPI 7.
+#
+# https://bugs.gentoo.org/482170
+#
+# Note: version comparison function is not included currently.
+#
+# Version strings
+# ===
+# The functions support arbitrary version strings consisting of version
+# components interspersed with (possibly empty) version separators.
+#
+# A version component can either consist purely of digits ([0-9]+) or
+# purely of uppercase and lowercase letters ([a-zA-Z]+). Any other
+# character is treated as a version separator.
+#
+# The version is processed left-to-right, and each successive component
+# is assigned numbers starting with 1. The components are either split
+# on version separators or on boundaries between digits and letters
+# (in which case the separator between the components is empty).
+# Version separators are assigned numbers starting with 1 for
+# the separator between 1st and 2nd components. As a special case,
+# if the version string starts with a separator, it is assigned index 0.
+#
+# Examples:
+#
+#   1.2b-alpha4 -> 1 . 2 '' b - alpha '' 4
+#  c s c s  c s c s  c
+#  1 1 2 2  3 3 4 4  5
+#
+#   .11.-> . 11 .
+#  s c  s
+#  0 1  1
+#
+# Ranges
+# ==
+# A range can be specified as 'm' for m-th version component, 'm-'
+# for all components starting with m-th or 'm-n' for components starting
+# at m-th and ending at n-th (inclusive). If the range spans outside
+# the version string, it is truncated silently.
+
+case ${EAPI:-0} in
+   0|1|2|3|4|5)
+   die "${ECLASS}: EAPI=${EAPI:-0} not supported";;
+   6)
+   ;;
+   *)
+   die "${ECLASS}: EAPI=${EAPI} unknown";;
+esac
+
+# @FUNCTION: _ver_parse_range
+# @INTERNAL
+# @USAGE:  
+# @DESCRIPTION:
+# Parse the range string , setting 'start' and 'end' variables
+# to the appropriate bounds.  and  specify the appropriate
+# lower and upper bound for the range; the user-specified value is
+# truncated to this range.
+_ver_parse_range() {
+   local range=${1}
+   local max=${2}
+
+   [[ ${range} == [0-9]* ]] || die "${FUNCNAME}: range must start with a 
number"
+   start=${range%-*}
+   [[ ${range} == *-* ]] && end=${range#*-} || end=${start}
+   if [[ ${end} ]]; then
+   [[ ${start} -le ${end} ]] || die "${FUNCNAME}: end of range 
must be >= start"
+   [[ ${end} -le ${max} ]] || end=${max}
+   else
+   end=${max}
+   fi
+}
+
+# @FUNCTION: _ver_split
+# @INTERNAL
+# @USAGE: 
+# @DESCRIPTION:
+# Split the version string  into separator-component array.
+# Sets 'comp' to an array of the form: ( s_0 c_1 s_1 c_2 s_2 c_3... )
+# where s_i are separators and c_i are components.
+_ver_split() {
+   local v=${1} LC_ALL=C
+
+   comp=()
+
+   # get separators and components
+   local s c
+   while [[ ${v} ]]; do
+   # cut the 

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Rich Freeman]

On Fri, Sep 8, 2017 at 6:09 AM, Ulrich Mueller  wrote:
>
> Quoting from "all-rights-reserved":
>
> | This package has an explicit "all rights reserved" clause, or comes
> | without any license, or only with a disclaimer. This means that you
> | have only the rights that are granted to you by law. If you have
> | lawfully acquired a copy of the program (e.g., by buying it or by
> | downloading it from the author's site) then in many legislations you
> | are allowed to compile it, run it, make a backup, and to patch it as
> | necessary, without permission from the copyright holder.
>
> Note that it explicitly says "downloading from the author's site".

It also explicitly says "e.g."  This means that this is merely one way
of lawfully acquiring a copy of the program, and that other ways may
exist.  It sounds pedantic but this is the whole reason that "e.g."
exists as opposed to "i.e." and courts certainly would read the policy
in this way because lawyers distinguish between the two all the time.

> I still think that we should handle this in a restrictive way, and
> permit only sites where we can be reasonably certain that they
> distribute the software with the copyright holder's approval.

Sure, that's you opinion, and I have a different opinion, and kentnl
has another opinion.

This is why we have processes to turn those opinions into documented
policies so that we can be consistent.  Failing to do this can cause
all kinds of problems.  Suppose we remove this package.  Suppose we
don't remove some other package with the same problem.  In the absence
of a written policy one way or another somebody could cite your
statement as a concession.

>
> Why not follow kentnl's suggestion? If you don't want to figure out
> what the connection between the author and the download site is, then
> make the ebuild fetch restricted, and have the user download the
> file manually. I'd also suggest to put only the file's basename in
> SRC_URI then.
>

It would be inconvenient for the user.  That's why we don't
fetch-restrict every package in the tree, even though doing so would
lower our risk of getting sued.  Maybe the Linux foundation
redistributes something it shouldn't.  I doubt it, but it could
happen.  If we fetch-restricted the kernel then we'd be covered if
another SCO comes along.  But, that would be ridiculous.  We don't
even do that with things like libcss which are higher risk.

-- 
Rich

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Ulrich Mueller]

> On Thu, 7 Sep 2017, Rich Freeman wrote:

> On Thu, Sep 7, 2017 at 5:18 PM, Michał Górny  wrote:
>> W dniu czw, 07.09.2017 o godzinie 16∶42 -0400, użytkownik Rich Freeman
>> napisał:
>>> Are you saying it is sufficient to just point the SRC_URI at the
>>> new URL and remove the mask? As far as I can tell that is all that
>>> needs to be done. Per the policy the license is readily apparent,
>>> so there is no need to contact the authors.

Huh? The very problem here is that the package has *no* license.

The LICENSE variable was always mandatory, so originally a package
without a license (like the one mentioned in the subject) could
not be added to the tree. Or, devs would tag it with the infamous
"as-is" license label. Cleaning up the resulting mess was quite a
nightmare [1].

Later it was noticed that there is a specific class of software where
there is no license, but that are up for download at their author's
site. Examples were dev-libs/djb and other packages related to qmail.
We then came up with the "all-rights-reserved" license label [2], in
order to permit such software in the tree. (You should be aware of
this, because you were a trustee back then).

Quoting from "all-rights-reserved":

| This package has an explicit "all rights reserved" clause, or comes
| without any license, or only with a disclaimer. This means that you
| have only the rights that are granted to you by law. If you have
| lawfully acquired a copy of the program (e.g., by buying it or by
| downloading it from the author's site) then in many legislations you
| are allowed to compile it, run it, make a backup, and to patch it as
| necessary, without permission from the copyright holder.

Note that it explicitly says "downloading from the author's site".
I still think that we should handle this in a restrictive way, and
permit only sites where we can be reasonably certain that they
distribute the software with the copyright holder's approval.

>> I don't know what is sufficient. It's your business as the new
>> maintainer to figure it out and take the responsibility. If there's
>> nobody willing to do that, then we don't get to keep the package.
>> Simple as that.

> And how would I figure it out, considering that simply asking on the
> list doesn't seem to yield a straight answer?  Do you really need me
> to put it on the Council agenda?  Or do we unmask it, let QA mask it
> 10 minutes later, then go back and forth for a month, and THEN put it
> on the Council agenda?

Why not follow kentnl's suggestion? If you don't want to figure out
what the connection between the author and the download site is, then
make the ebuild fetch restricted, and have the user download the
file manually. I'd also suggest to put only the file's basename in
SRC_URI then.

Ulrich


[1] https://bugs.gentoo.org/436214
[2] https://bugs.gentoo.org/24


pgpfrj8f19GzK.pgp
Description: PGP signature

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Rich Freeman]

On Fri, Sep 8, 2017 at 2:52 AM, Michał Górny  wrote:
>
> Maybe find yourself a lawyer, and ask him. We're all volunteers,

I've already done the research.  There is no legal requirement to
contact the authors before changing the SRC_URI.

> and we're no in way obligated to give legal advices to you or anyone
> in particular.

I'm not asking for legal advice.

Somebody suggested a solution.  ulm objected to that solution.  I'm
merely asking that those trying to stop a problem from being solved to
point to a written policy, because that is how virtually every
organization on the planet works.  If you don't put the impetus on the
person trying to block action, then nothing gets done, because posting
an objection on a mailing list costs nothing.

> Especially if it all started with the tone 'how dare you
> remove this?!'
>

I certainly never objected to the removal of the package.  It didn't
fetch and was unmaintained.  Of course it should have been
treecleaned.  Maybe somebody else had that tone, and if that concerns
you I suggest you take it up with them.

-- 
Rich

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Ulrich Mueller]

> On Thu, 7 Sep 2017, R0b0t1  wrote:

> Downloading does not imply committing a felony. As far as anyone can
> tell it is impossible to prosecute someone for downloading something
> they already own (regardless of what any EULA has claimed).

Sure, if the user already has rightfully obtained the software then
nothing can stop him from downloading it again.

> Further, copyrights lapse if not enforced. Depending on how long
> that download has been up the original rightsholder has forfeited
> their claim to their work.

Copyright expires no sooner than 50 years after the author's death:
https://en.wikipedia.org/wiki/Berne_Convention
In most countries that term is even longer, e.g. 70 years in the
European Union.

Also contrary to popular belief, there is no such concept as
"abandonware". In some legislations, there are some provisions to
allow archiving of orphan works, but only for public institutions
(e.g. in the EU, museums and digital archives).

> Sir, please see my above comment about building ballistic missiles.
> It may be important for the Gentoo Foundation to add a disclaimer
> similar to the one I mentioned. I would hate for the Foundation or
> any of its administrators or contributors to be found guilty of
> aiding and abetting terrorists.

Yeah. Stop trolling, please.

Ulrich


pgpnabBWWiRtr.pgp
Description: PGP signature

[gentoo-dev] [PATCH] toolchain-funcs: Respect host vars for tc-getBUILD* when not cross

[Michał Górny]

Make tc-getBUILD* functions respect host variables (CC & co.) when
not cross-compiling. This removes the necessity of overriding BUILD_*
along with the regular variables on the systems that are not concerned
about cross-compilation, and does not change the behavior for those
which are.

Closes: https://bugs.gentoo.org/630282
---
 eclass/toolchain-funcs.eclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index aeb6f7c70299..75fa638efff3 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -40,7 +40,13 @@ _tc-getPROG() {
export ${var}="${prog[*]}"
echo "${!var}"
 }
-tc-getBUILD_PROG() { _tc-getPROG CBUILD "BUILD_$1 $1_FOR_BUILD HOST$1" 
"${@:2}"; }
+tc-getBUILD_PROG() {
+   local vars="BUILD_$1 $1_FOR_BUILD HOST$1"
+   # respect host vars if not cross-compiling
+   # https://bugs.gentoo.org/630282
+   tc-is-cross-compiler || vars+=" $1"
+   _tc-getPROG CBUILD "${vars}" "${@:2}"
+}
 tc-getPROG() { _tc-getPROG CHOST "$@"; }
 
 # @FUNCTION: tc-getAR
-- 
2.14.1

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Michał Górny]

W dniu czw, 07.09.2017 o godzinie 17∶56 -0400, użytkownik Rich Freeman
napisał:
> On Thu, Sep 7, 2017 at 5:18 PM, Michał Górny  wrote:
> > W dniu czw, 07.09.2017 o godzinie 16∶42 -0400, użytkownik Rich Freeman
> > napisał:
> > > On Thu, Sep 7, 2017 at 4:36 PM, Michał Górny  wrote:
> > > > W dniu czw, 07.09.2017 o godzinie 06∶21 -0700, użytkownik Rich Freeman
> > > > napisał:
> > > > > On Thu, Sep 7, 2017 at 6:04 AM, Ulrich Mueller  
> > > > > wrote:
> > > > > > > > > > > On Thu, 7 Sep 2017, Rich Freeman wrote:
> > > > > > 
> > > > > > Don't you think there is a difference between downloading a package
> > > > > > that has a known upstream and that is also carried by other distros,
> > > > > > and downloading a license-less package from a random location on the
> > > > > > internet?
> > > > > 
> > > > > Most upstreams do not do much checking about the ownership of their 
> > > > > sources.
> > > > > 
> > > > > Gentoo certainly doesn't - we don't even require developers to submit 
> > > > > a DCO.
> > > > > 
> > > > > Other projects like the Linux kernel require signing a DCO for each
> > > > > commit, but do not do any checking beyond this.  I have no doubt that
> > > > > they would remove offending sources if they were contacted, but they
> > > > > do not actively go out and confirm authorship.
> > > > > 
> > > > > > 
> > > > > > > > The package in question doesn't come with any license though, 
> > > > > > > > which
> > > > > > > > means that only the copyright holder has the right to distribute
> > > > > > > > it. So I believe that some extra care is justified, especially 
> > > > > > > > when
> > > > > > > > the upstream location of the distfile has changed.
> > > > > > > 
> > > > > > > Why?  We don't redistribute anything that is copyrighted.
> > > > > > 
> > > > > > Users download the file, and I think that we are responsible to have
> > > > > > only such SRC_URIs in our ebuilds from where they can obtain the
> > > > > > package without being exposed to potential legal issues.
> > > > > 
> > > > > I'm not aware of any court rulings that have found downloading
> > > > > something like this to be illegal.
> > > > > 
> > > > > > 
> > > > > > > Perhaps if we want to enforce a policy like this we should take 
> > > > > > > the
> > > > > > > time to actually write the policy down.  As far as I can tell 
> > > > > > > Gentoo
> > > > > > > has no such policy currently.
> > > > > > 
> > > > > > The old Games Ebuild Howto [1] has this:
> > > > > > 
> > > > > > > LICENSE
> > > > > > > 
> > > > > > > The license is an important point in your ebuild. It is also a
> > > > > > > common place for making mistakes. Try to check the license on any
> > > > > > > ebuild that you submit. Often times, the license will be in a
> > > > > > > COPYING file, distributed in the package's tarball. If the license
> > > > > > > is not readily apparent, try contacting the authors of the package
> > > > > > > for clarification. [...]
> > > > > > 
> > > > > > I propose to add the paragraph above to the devmanual's licenses
> > > > > > section.
> > > > > > 
> > > > > 
> > > > > We already know there isn't a license for redistribution.  This
> > > > > doesn't speak about requiring us to ensure that those distributing our
> > > > > source files have the rights to do so.  It merely says to check the
> > > > > license.  We understand the license already.  I don't see how this
> > > > > paragraph pertains to this situation.
> > > > 
> > > > AFAIK you're a developer. So if you want to keep this package, then
> > > > please do the needful and take care of it yourself instead of
> > > > complaining and demanding others to do the work you want done.
> > > > 
> > > 
> > > Are you saying it is sufficient to just point the SRC_URI at the new
> > > URL and remove the mask?  As far as I can tell that is all that needs
> > > to be done.  Per the policy the license is readily apparent, so there
> > > is no need to contact the authors.
> > > 
> > 
> > I don't know what is sufficient. It's your business as the new
> > maintainer to figure it out and take the responsibility. If there's
> > nobody willing to do that, then we don't get to keep the package. Simple
> > as that.
> > 
> 
> And how would I figure it out, considering that simply asking on the
> list doesn't seem to yield a straight answer?  Do you really need me
> to put it on the Council agenda?  Or do we unmask it, let QA mask it
> 10 minutes later, then go back and forth for a month, and THEN put it
> on the Council agenda?

Maybe find yourself a lawyer, and ask him. We're all volunteers,
and we're no in way obligated to give legal advices to you or anyone
in particular. Especially if it all started with the tone 'how dare you
remove this?!'

-- 
Best regards,
Michał Górny