Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Mike Gilbert]

On Sat, Aug 25, 2018 at 10:11 PM Andrew Savchenko  wrote:
>
> On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> > PMS does not specify that behavior (skipping src_test with USE=-test).
> > It is better to define the requrement explicitly rather than relying
> > on a Portage-specific behavior.
>
> Then PMS should be fixed. Putting useless code in thousands
> of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> conformance to the PMS is good, but common sense should still be
> considered.

I disagree with your opinion. Adding one line of code to many ebuilds
is not a crazy idea, and it doesn't need to happen overnight. Adding
RESTRICT="!test? ( test )" is certainly not harmful.

The advice given in the devmanual should agree with PMS. I think PMS
is unlikely to change; if it does, the devmanual can be updated to
match.

Personally, I would not like to see a change in PMS in this regard. I
think controlling tests via USE conditionals in RESTRICT is a nice way
to avoid hard-coding the meaning of individual USE flags into PMS.
It also gives the ebuild author more flexibility. For example, he
could put something like this in RESTRICT if some exotic "foo" feature
causes tests to fail:

RESTRICT="foo ( test )"

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Mike Gilbert]

On Sun, Aug 26, 2018 at 3:28 AM Zac Medico  wrote:
>
> On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> > On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> >> On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  
> >> wrote:
> >>>
> >>> On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
>  ---
>   general-concepts/dependencies/text.xml | 38 ++
>   1 file changed, 38 insertions(+)
> 
>  diff --git a/general-concepts/dependencies/text.xml 
>  b/general-concepts/dependencies/text.xml
>  index 2f10380..64be9dc 100644
>  --- a/general-concepts/dependencies/text.xml
>  +++ b/general-concepts/dependencies/text.xml
>  @@ -578,6 +578,44 @@ valid.
>   
>   
> 
>  +
>  +Test Dependencies
>  +
>  +
>  +
>  +Packages often have optional dependencies that are needed only when 
>  running
>  +tests. These should be specified in DEPEND behind a USE flag. Often, the
>  +'test' USE flag is used for this purpose.
>  +
>  +
>  +
>  +Since testing will likely fail when test dependencies are not 
>  installed, the
>  +test phase should be disabled in this case. This may be accomplished 
>  via USE
>  +conditionals in the RESTRICT variable.
>  +
>  +
>  +
>  +If other optional features must be enabled/disabled when testing, 
>  REQUIRED_USE
>  +may be set to express this.
>  +
>  +
>  +
>  +# Define some USE flags
>  +IUSE="debug test"
>  +
>  +# Disable test phase when test USE flag is disabled
>  +RESTRICT="!test? ( test )"
> >>>
> >>> I do not understand why we need this useless code. If test USE flag
> >>> is disabled, tests must be disabled as well. It is PM's job and
> >>> there is no need to put this obvious stuff into each ebuild with
> >>> tests and extra deps. I see no reason to support running src_test()
> >>> with USE="-test".
> >>
> >> PMS does not specify that behavior (skipping src_test with USE=-test).
> >> It is better to define the requrement explicitly rather than relying
> >> on a Portage-specific behavior.
> >
> > Then PMS should be fixed. Putting useless code in thousands
> > of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> > conformance to the PMS is good, but common sense should still be
> > considered.
>
> Since PMS doesn't specify the behavior of FEATURES, I suppose we could
> make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
> drawbacks to that?

I think that's a nice idea from a usability standpoint, at least while
most ebuilds in the tree do not set it explicitly.

I still think adding an explicit RESTRICT="!test? ( test )" to ebuilds
is a good idea though. My fear is that certain people would start
rejecting patches or reverting commits as "useless changes".

[gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michał Górny]

Hi,

It seems that we suffer a major problem of developers wrongly
attributing *GPL-[23] licenses to ebuilds, when the correct variant is
*GPL-[23]+.  In proxy-maint, every second new package with LICENSE=GPL-
[23] is plain wrong.  I suspect part of the problem is that GitHub has
poor man's license recognition that does not distinguish between 'vN
only' and 'vN or newer' license variants, and similarly that a number of
contributors don't bother checking the license beyond COPYING/README.

Another part of the problem is that we don't have a really good way of
distinguishing verified correct uses of *GPL-[23].  So in the end, I end
up verifying the same packages over and over again unless I remember
that I've verified them.

Therefore, I would like to suggest the following:

1. introducing additional *-only licenses that explicitly indicate that
a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.

2. annotating the unsuffixed licenses with a warning that they may mean
either x-only or x+ due to frequent mistake.

3. make repoman warn whenever non-specific variant is used, telling
developers to verify whether it's x-only or x+.

4. start migrating packages to x-only or x+ appropriately.

5. eventually, remove the non-specific licenses and make repoman error
out with clear explanation.

What do you think?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Mart Raudsepp]

Ühel kenal päeval, P, 26.08.2018 kell 12:39, kirjutas Michał Górny:
> Hi,
> 
> It seems that we suffer a major problem of developers wrongly
> attributing *GPL-[23] licenses to ebuilds, when the correct variant
> is
> *GPL-[23]+.  In proxy-maint, every second new package with
> LICENSE=GPL-
> [23] is plain wrong.  I suspect part of the problem is that GitHub
> has
> poor man's license recognition that does not distinguish between 'vN
> only' and 'vN or newer' license variants, and similarly that a number
> of
> contributors don't bother checking the license beyond COPYING/README.
> 
> Another part of the problem is that we don't have a really good way
> of
> distinguishing verified correct uses of *GPL-[23].  So in the end, I
> end
> up verifying the same packages over and over again unless I remember
> that I've verified them.
> 
> Therefore, I would like to suggest the following:
> 
> 1. introducing additional *-only licenses that explicitly indicate
> that
> a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
> 
> 2. annotating the unsuffixed licenses with a warning that they may
> mean
> either x-only or x+ due to frequent mistake.
> 
> 3. make repoman warn whenever non-specific variant is used, telling
> developers to verify whether it's x-only or x+.
> 
> 4. start migrating packages to x-only or x+ appropriately.
> 
> 5. eventually, remove the non-specific licenses and make repoman
> error
> out with clear explanation.
> 
> What do you think?

The common issue here is that upstream COPYING files really do only
talk about one of the versions. And then you get to validate or source
files to be sure that they do have a "or later" clause in them. And
then on each bump you ideally should validate it again, etc, that no
sources without "or later" allowance are in there...
In many cases you can trust upstreams that do make it explicit
somewhere though (toplevel meson.build, README.md, CONTRIBUTING.md,
etc).
Otherwise good idea, but I'm not sure how we are supposed to keep up
with monitoring non-"or later" sources creeping in in new upstream
versions.

There are plenty of wrong LICENSE tags in this regard under my co-
maintenance too, and it's a pain to validate all the source files, and
it's just a best effort of "hopefully my grep magic covered it and they
haven't used a non-standard file copyright header".


Mart

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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan , Jr .]

On 26/08/2018 12:53, Mart Raudsepp wrote:
> The common issue here is that upstream COPYING files really do only
> talk about one of the versions. And then you get to validate or source
> files to be sure that they do have a "or later" clause in them. And
> then on each bump you ideally should validate it again, etc, that no
> sources without "or later" allowance are in there...

Yup, precise tracking of license metadata can be a pain.

I'm not really sure if that level of it is worth for us as a distro. For
_importing_ other project's source code directly into one's project
precise license compatibility matters a lot. That's not the scenario
we're in. I see LICENSES as mostly a mechanism for end users to accept
or reject EULAs etc, and I'm curious what are other common scenarios.

Michał, could you elaborate on why not distinguishing more precisely
between these GPL variants in LICENSES is a _problem_ ? I can certainly
see the information is not always accurate, but it's not obvious to me
how severe is the downside, what are the consequences in practice.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michał Górny]

On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> On 26/08/2018 12:53, Mart Raudsepp wrote:
> > The common issue here is that upstream COPYING files really do only
> > talk about one of the versions. And then you get to validate or source
> > files to be sure that they do have a "or later" clause in them. And
> > then on each bump you ideally should validate it again, etc, that no
> > sources without "or later" allowance are in there...
> 
> Yup, precise tracking of license metadata can be a pain.
> 
> I'm not really sure if that level of it is worth for us as a distro. For
> _importing_ other project's source code directly into one's project
> precise license compatibility matters a lot. That's not the scenario
> we're in. I see LICENSES as mostly a mechanism for end users to accept
> or reject EULAs etc, and I'm curious what are other common scenarios.
> 
> Michał, could you elaborate on why not distinguishing more precisely
> between these GPL variants in LICENSES is a _problem_ ? I can certainly
> see the information is not always accurate, but it's not obvious to me
> how severe is the downside, what are the consequences in practice.
> 

I'm not aware of any major implications.  However, I think that if we
provide for the distinction, the distinction should be used correctly.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Andrew Savchenko]

On Sun, 26 Aug 2018 00:28:16 -0700 Zac Medico wrote:
> On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> > On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> >> On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  
> >> wrote:
> >>>
> >>> On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
>  ---
>   general-concepts/dependencies/text.xml | 38 ++
>   1 file changed, 38 insertions(+)
> 
>  diff --git a/general-concepts/dependencies/text.xml 
>  b/general-concepts/dependencies/text.xml
>  index 2f10380..64be9dc 100644
>  --- a/general-concepts/dependencies/text.xml
>  +++ b/general-concepts/dependencies/text.xml
>  @@ -578,6 +578,44 @@ valid.
>   
>   
> 
>  +
>  +Test Dependencies
>  +
>  +
>  +
>  +Packages often have optional dependencies that are needed only when 
>  running
>  +tests. These should be specified in DEPEND behind a USE flag. Often, the
>  +'test' USE flag is used for this purpose.
>  +
>  +
>  +
>  +Since testing will likely fail when test dependencies are not 
>  installed, the
>  +test phase should be disabled in this case. This may be accomplished 
>  via USE
>  +conditionals in the RESTRICT variable.
>  +
>  +
>  +
>  +If other optional features must be enabled/disabled when testing, 
>  REQUIRED_USE
>  +may be set to express this.
>  +
>  +
>  +
>  +# Define some USE flags
>  +IUSE="debug test"
>  +
>  +# Disable test phase when test USE flag is disabled
>  +RESTRICT="!test? ( test )"
> >>>
> >>> I do not understand why we need this useless code. If test USE flag
> >>> is disabled, tests must be disabled as well. It is PM's job and
> >>> there is no need to put this obvious stuff into each ebuild with
> >>> tests and extra deps. I see no reason to support running src_test()
> >>> with USE="-test".
> >>
> >> PMS does not specify that behavior (skipping src_test with USE=-test).
> >> It is better to define the requrement explicitly rather than relying
> >> on a Portage-specific behavior.
> > 
> > Then PMS should be fixed. Putting useless code in thousands
> > of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> > conformance to the PMS is good, but common sense should still be
> > considered.
> 
> Since PMS doesn't specify the behavior of FEATURES, I suppose we could
> make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
> drawbacks to that?

IMO no. This is what everyone expects from the test feature.

Best regards,
Andrew Savchenko


pgpy8U5vziMny.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Roy Bamford]

On 2018.08.26 12:15, Michał Górny wrote:
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > On 26/08/2018 12:53, Mart Raudsepp wrote:
> > > The common issue here is that upstream COPYING files really do
> only
> > > talk about one of the versions. And then you get to validate or
> source
> > > files to be sure that they do have a "or later" clause in them.
> And
> > > then on each bump you ideally should validate it again, etc, that
> no
> > > sources without "or later" allowance are in there...
> > 
> > Yup, precise tracking of license metadata can be a pain.
> > 
> > I'm not really sure if that level of it is worth for us as a distro.
> For
> > _importing_ other project's source code directly into one's project
> > precise license compatibility matters a lot. That's not the scenario
> > we're in. I see LICENSES as mostly a mechanism for end users to
> accept
> > or reject EULAs etc, and I'm curious what are other common
> scenarios.
> > 
> > Michał, could you elaborate on why not distinguishing more precisely
> > between these GPL variants in LICENSES is a _problem_ ? I can
> certainly
> > see the information is not always accurate, but it's not obvious to
> me
> > how severe is the downside, what are the consequences in practice.
> > 
> 
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.
> 
> -- 
> Best regards,
> Michał Górny
> 

Michał,

How far do you want to dig?
Every upstream file or do you trust the upstream top level licence?

What about bundled libs?
Do you trust upstream to have that that right too?

It looks like a lot of work for what is at most, a convenience to users.

What matters most is the licensing for things we distribute as binaries.
That would make an interesting and more manageable test case.

As has already been pointed out. Fixing it is one thing, keeping it fixed
is another.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgplAdhXytuo_.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Rich Freeman]

On Sun, Aug 26, 2018 at 7:15 AM Michał Górny  wrote:
>
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > On 26/08/2018 12:53, Mart Raudsepp wrote:
> > > The common issue here is that upstream COPYING files really do only
> > > talk about one of the versions. And then you get to validate or source
> > > files to be sure that they do have a "or later" clause in them. And
> > > then on each bump you ideally should validate it again, etc, that no
> > > sources without "or later" allowance are in there...
> >
> > Yup, precise tracking of license metadata can be a pain.
> >
> > I'm not really sure if that level of it is worth for us as a distro. For
> > _importing_ other project's source code directly into one's project
> > precise license compatibility matters a lot. That's not the scenario
> > we're in. I see LICENSES as mostly a mechanism for end users to accept
> > or reject EULAs etc, and I'm curious what are other common scenarios.
> >
> > Michał, could you elaborate on why not distinguishing more precisely
> > between these GPL variants in LICENSES is a _problem_ ? I can certainly
> > see the information is not always accurate, but it's not obvious to me
> > how severe is the downside, what are the consequences in practice.
> >
>
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.
>

IMO QA policy ought to be that the license is correct.

How much time/effort goes into policing the policy in the case of
2/3/2+/3+ is a different matter.  If people want to do it, great, but
IMO it isn't adding tremendous value.  I doubt we have any users
relying on license filtering to distinguish between GPL2/2+.  If
somebody files a bug pointing out an incorrect license it should be
fixed as a matter of policy, but I'm not sure more than that is
necessary in this particular case.  If we were talking about nonfree
licenses being missed that would be more critical.

-- 
Rich

[gentoo-dev] Last rites: net-analyzer/check_mk

[Michał Górny]

# Michał Górny  (26 Aug 2018)
# mod_python removal caused it to be reduced to agent-only, which is
# apparently redundant to net-analyzer/check_mk_agent.  The package
# is unmaintained and potentially vulnerable.  Bug #632648.
# Removal in 30 days.
net-analyzer/check_mk

-- 
Best regards,
Michał Górny


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

[gentoo-dev] Last rites: net-im/hangups

[Michał Górny]

# Michał Górny  (26 Aug 2018)
# Live ebuild only.  Dependencies can no longer be satisfied by ::gentoo
# packages.  Bug #664658.  Removal in 30 days.
net-im/hangups

-- 
Best regards,
Michał Górny


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

[gentoo-dev] Last rites: media-plugins/vdr-admin

[Joerg Bornkessel]

media-plugins/vdr-admin:
removal from the tree, as the plugin is written to manage the vdr2gentoo
distribution,
useless in gentoo
#bug 664670

-- 
Joerg Bornkessel 
GnuPG Key: 0x93EB5F4DAA5832A1
Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan , Jr .]

On 26/08/2018 13:15, Michał Górny wrote:
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.

Makes sense.

Note that this might also be an argument for _not_ providing such
fine-grained distinction (unless there's corresponding value in it).

If in doubt, at least my intuition is to err on the side of simplicity.

I also like Rich's opinion on this,


Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: net-misc/cocaine-core

[Michał Górny]

# Patrice Clement  (12 Dec 2017)
# Masked due to a hard dependency on an ancient versions of dev-libs/msgpack
# (<0.6) that have been punted from the tree.
# Michał Górny  (26 Aug 2018)
# Removal in 30 days.  Bug #664662.
net-misc/cocaine-core

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Mart Raudsepp]

Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
> One thing where this would fail would be e.g.:
> 
>   LICENSE="GPL-2+
> bar? ( GPL-2 )
> foo? ( GPL-3+ )" ^ you can't put a comment on the right line

LICENSE="GPL-2+ "
LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
LICENSE+="foo? ( GPL-3+ )"


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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Francesco Riosa]

please ignore my previous email

>

[gentoo-dev] Last rites: media-plugins/vdr-arghdirector

[Joerg Bornkessel]

media-plugins/vdr-arghdirector: masked for removal
- do not work anymore since paytv provider provider has changed to paytv
provider sky
- no converted to gettext handling
- old makefile handling
- dead on upstream since years..
#bug 664672

-- 
Joerg Bornkessel 
GnuPG Key: 0x93EB5F4DAA5832A1
Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[M. J. Everitt]

On 26/08/18 19:14, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
>> One thing where this would fail would be e.g.:
>>
>>   LICENSE="GPL-2+
>> bar? ( GPL-2 )
>> foo? ( GPL-3+ )" ^ you can't put a comment on the right line
> LICENSE="GPL-2+ "
> LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
> LICENSE+="foo? ( GPL-3+ )"
.. and [then] enforce the ensuing format change via Repoman ..



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: java-virtuals/jdk-with-com-sun

[James Le Cuirot]

# James Le Cuirot  (26 Aug 2018)
# Unused Java virtual from the days when the JDK was proprietary. Now
# we assume that com.sun is always available. Removal in 30 days.
java-virtuals/jdk-with-com-sun

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpCVY0hjFTV8.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last-rites: dev-java/spring-*

[James Le Cuirot]

# James Le Cuirot  (26 Aug 2018)
# Although the Spring Framework is very much alive, our packages are
# ancient and our infrastructure is not ready to update it any time
# soon. If you want this then join the Java team and be prepared to do
# a lot of work. Removal in 30 days.
dev-java/spring-aop
dev-java/spring-beans
dev-java/spring-core
dev-java/spring-expression
dev-java/spring-instrument

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpFzxRUXQ2zh.pgp
Description: OpenPGP digital signature

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-08-26 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2018-08-26 23:59 UTC.

Removals:
dev-python/django-celery 20180821-10:15 vdupras   ad53622488b

Additions:
app-emulation/containers-storage 20180825-04:24 zmedico   02b10f2a44b
app-misc/imgurbash2  20180802-00:10 mgornyd773c7c200e
dev-libs/aws-sdk-cpp 20180820-12:37 monsieurp af872979c69
dev-util/glib-utils  20180818-01:24 leio  719d166fdbc
media-gfx/dmtx-utils 20180805-18:21 mgorny91071e948b7
media-sound/whipper  20180810-11:38 mgorny8c290a104b5
net-wireless/jackit  20180822-21:05 zerochaos 3221492f967
net-wireless/mousejack   20180822-20:47 zerochaos 6af528a12f3
net-wireless/sdrplay 20180825-18:30 idl0r 92df2f31ca6
net-wireless/soapyremote 20180826-10:00 idl0r f5d04b2d993
net-wireless/soapysdrplay20180825-19:21 idl0r 03133d5c73f
sci-physics/geant-vmc20180205-23:17 amadioff01e7c6bcc
sys-fs/fragview  20180801-23:11 mgorny1dfcc35bd4f
sys-process/usbtop   20180824-03:55 zerochaos 5092d2c6d71
virtual/resolvconf   20180824-17:32 alonblb53a8ddd0bb

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
dev-python/django-celery,removed,vdupras,20180821-10:15,ad53622488b
Added Packages:
net-wireless/soapyremote,added,idl0r,20180826-10:00,f5d04b2d993
net-wireless/soapysdrplay,added,idl0r,20180825-19:21,03133d5c73f
net-wireless/sdrplay,added,idl0r,20180825-18:30,92df2f31ca6
app-emulation/containers-storage,added,zmedico,20180825-04:24,02b10f2a44b
virtual/resolvconf,added,alonbl,20180824-17:32,b53a8ddd0bb
sys-process/usbtop,added,zerochaos,20180824-03:55,5092d2c6d71
sci-physics/geant-vmc,added,amadio,20180205-23:17,ff01e7c6bcc
media-sound/whipper,added,mgorny,20180810-11:38,8c290a104b5
net-wireless/jackit,added,zerochaos,20180822-21:05,3221492f967
net-wireless/mousejack,added,zerochaos,20180822-20:47,6af528a12f3
sys-fs/fragview,added,mgorny,20180801-23:11,1dfcc35bd4f
app-misc/imgurbash2,added,mgorny,20180802-00:10,d773c7c200e
dev-libs/aws-sdk-cpp,added,monsieurp,20180820-12:37,af872979c69
media-gfx/dmtx-utils,added,mgorny,20180805-18:21,91071e948b7
dev-util/glib-utils,added,leio,20180818-01:24,719d166fdbc

Done.

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Ulrich Mueller]

> On Sun, 26 Aug 2018, Matija Šuklje wrote:

> It is worth noting that the SPDX standard (since 3.0) has indeed changed 
> for the *GPL family of licenses

> from
> • GPL-2.0, and 
> • GPL-2.0+

> to
> • GPL-2.0-only, and
> • GPL-2.0-or-later

> This was done by request and in coordination with the FSF.

> To quote from  (under “Deprecated Licenses” 
> header):

>> Release 3.0 replaced previous Identifiers for GNU licenses with more 
>> explicit Identifiers to reflect the "this version only" or "any later 
>> version" option specific to those licenses. As such, the previously 
>> used Identifiers for those licenses are deprecated as of v3.0.

> Note: for all other licenses ‘+’ does the same as before.

So it's "-or-later" for the GPL family but "+" for all others?
That doesn't look like a consistent format to me.

Also, what does "GPL-2.0-or-later" mean? There is no version 2.0 of the
GPL, and by version ordering rules (ours, as well as GNU strverscmp(3)),
"2" is less than "2.0". So GPL version 2 is not matched by it.

> So, if we plan to the latest SPDX spec, we would need to introduce the 
> “-only” and ”-or-later” suffixes regardless.

Ulrich

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Ulrich Mueller]

> On Mon, 27 Aug 2018, Robin H Johnson wrote:

> I've been wondering if we can switch outright to using SPDX-based
> expressions inside our USE-flag conditionals. 

> For the entries we have in licenses/ that are not presently covered by
> SPDX licenses or exceptions, we'll need additions*, but it will shrink
> the licenses directory significantly.

How so? We currently have 740 licenses, but only 18 named *exception*.
That's not much potential for saving, to start with.

> * We have some open-source exceptions & closed-source licenses that
> are not in SPDX

You've answered your own question. :-) The SPDX list has only incomplete
coverage. So in any case, we will need our own labels for a large
fraction of licenses.

Also, what would we do if a license is added to the SPDX list later, but
with a label different from ours? Do we change all our ebuilds then?
What if they change their label between versions of their standard?
They've just proven that their labels aren't guaranteed to be stable,
not even for major licenses like the GPL.

Ulrich


signature.asc
Description: PGP signature

[gentoo-dev] RFC: removal of keyword arm-linux

[Benda Xu]

Hi,

As the Perl Team raised the issue of "arm-linux" keywords in the
ebuilds[1], I think it is a good chance to completely remove them from
our tree.

What is "arm-linux" keyword?  Gentoo Prefix has 2 kinds of profiles.  An
libc profile builds glibc in a Prefix and uses implicit keywords, while
An rpath profile uses host glibc and uses explicit keywords
"${ARCH}-linux".  Therefore arm-linux represents rpath flavor of arm
Prefix.

In the profiles/, however, we use "arm-linux" to represent Prefix in
arch.list and profiles.desc.  And that bears no relation with keywords
in the ebuilds.


How did "arm-linux" appear?  Around 2013, both the ARM Arch Team and the
Prefix Team were interested in supporting Prefix on ARM.  In the Prefix
Team, a debate of implicit vs explicit keywording was on-going.  At the
same time, the ARM Arch Team went ahead to plant arm-linux into the
tree.

What is the status of "arm-linux" keywords?  They are unmaintained and
has not been touched for 5+ years.  At present, the Prefix Project is
phasing out Linux rpath profiles and using libc profiles as default.
There has been no commit in the gentoo.git history regarding "arm-linux"
keyword. The gentoo-x86 CVS history shows the commit author was mainly
Zac (zmedico).

What is recommended?  Just use the "arm" keyword, it has been proven to
work well as an implicit ARM Prefix keyword by the Android Project[2].


"arm-linux" is considered deprecated, unmaintained and easily replaced
by "arm".  I propose removing it from gentoo.git completely.

Yours,
Benda


1. https://bugs.gentoo.org/664598
2. https://wiki.gentoo.org/wiki/Android/Devices

Re: [gentoo-dev] RFC: removal of keyword arm-linux

[Zac Medico]

On 08/26/2018 08:52 PM, Benda Xu wrote:
> The gentoo-x86 CVS history shows the commit author was mainly
> Zac (zmedico).

I have an arm prefix that I have used on chromebooks, and I'd be happy
to use the arm keyword instead of arm-linux.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: media-plugins/vdr-videosystem

[Joerg Bornkessel]

media-plugins/vdr-videosystem: pmasked for removal
- no converted to gettext handling
- use old makefile handling
- no upstream
- dead since years
# Bug 664678

-- 
Joerg Bornkessel 
GnuPG Key: 0x93EB5F4DAA5832A1
Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rides: media-plugins/vdr-rotor

[Joerg Bornkessel]

media-plugins/vdr-rotor: pmasked for removal
- full integrated in core vdr
- useless...
#bug 664674

-- 
Joerg Bornkessel 
GnuPG Key: 0x93EB5F4DAA5832A1
Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: media-plugins/vdr-browse

[Joerg Bornkessel]

media-plugins/vdr-browse: pmasked for removal
- full integrated in core vdr
- dead on upstream thince years
- useless
#bug 664676

-- 
Joerg Bornkessel 
GnuPG Key: 0x93EB5F4DAA5832A1
Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Jonas Stein]

>> 3. make repoman warn whenever non-specific variant is used, telling
>> developers to verify whether it's x-only or x+.

> Repoman could check for a comment in the LICENSE line as well, I guess?

There are already tools to guess licenses in sourcetrees see
"How other projects work with licenses" on
https://wiki.gentoo.org/wiki/Project:Licenses

Such a tool could help a lot to list the potentially wrong LICENSES.
It would be great, if we do not have to invent the wheel again.

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Robin H. Johnson]

On Sun, Aug 26, 2018 at 09:43:03PM +0200, Matija Šuklje wrote:
> It is worth noting that the SPDX standard (since 3.0) has indeed changed 
> for the *GPL family of licenses
I've been wondering if we can switch outright to using SPDX-based
expressions inside our USE-flag conditionals. 

For the entries we have in licenses/ that are not presently covered by
SPDX licenses or exceptions, we'll need additions*, but it will shrink
the licenses directory significantly.

* We have some open-source exceptions & closed-source licenses that are not in 
SPDX
-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation 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] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Ulrich Mueller]

> On Sun, 26 Aug 2018, Michał Górny wrote:

> 1. introducing additional *-only licenses that explicitly indicate
> that a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.

I don't like this at all, because LICENSE="GPL-2" means exactly the
above, namely GPL version 2, no later version. Therefore, "GPL-2-only"
would be completely redundant to it.

What we could do (and what already exists in several ebuilds) is to add
a *comment* to the LICENSE line, like "# GPL-2 only". This could be
required for every new ebuild.

> 2. annotating the unsuffixed licenses with a warning that they may
> mean either x-only or x+ due to frequent mistake.

I don't think that's a good idea either. Also we're not allowed to
change the license documents:
"Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed."

> 3. make repoman warn whenever non-specific variant is used, telling
> developers to verify whether it's x-only or x+.

Repoman could check for a comment in the LICENSE line as well, I guess?

> 4. start migrating packages to x-only or x+ appropriately.

See above. We could instead migrate ebuilds with "GPL-2" to either:
LICENSE="GPL-2+"
or:
LICENSE="GPL-2" # GPL-2 only

Optionally, the comment can be removed once all ebuilds have been
converted.

> 5. eventually, remove the non-specific licenses and make repoman error
> out with clear explanation.

Ulrich


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: media-video/nvidia-settings

[Michał Górny]

# Jeroen Roovers  (12 Jan 2017)
# Use x11-drivers/nvidia-drivers[tools] instead.
# Michał Górny  (26 Aug 2018)
# Removal in 30 days.  Bug #664638.
media-video/nvidia-settings

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Zac Medico]

On 08/24/2018 04:56 PM, Francesco Riosa wrote:
> 
> 
> Il giorno sab 25 ago 2018 alle ore 01:45 Zac Medico  > ha scritto:
> 
> On 08/24/2018 04:14 PM, Francesco Riosa wrote:
> >
> > Il 24/08/18 19:08, Mike Gilbert ha scritto:
> >> On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric  > wrote:
> >>> On Fri, 24 Aug 2018 10:27:01 -0400
> >>> Mike Gilbert mailto:flop...@gentoo.org>> wrote:
> >>>
>  If you want to define behavior that can be relied upon in
> ebuilds, it
>  should be specified in PMS. PMS does not define any meaning for the
>  "test" USE flag.
> >>> We should eschew idealism about how the world *should* behave,
> and avoid
> >>> making portage a steaming garbage heap in order to comply with a
> >>> terrible PMS specification of a heavily used feature.
> >> Portage still works just fine for most people who would enable
> >> FEATURES=test. Stop exaggerating.
> >>
> > People enabling FEATURES=test on most but not all packages had some
> > troubles and they need to disable them in both package.{env,use}
> > I'd like to have a flag to reinstate the previous portage
> behaviour, but
> > that's probably too late
> 
> Would a FEATURES setting that implies RESTRICT="!test? ( test )" for all
> ebuilds do what you want?
> 
> 
> "want" is too much,
> but it would have been pleasant to have something to keep portage
> dependancies working as before.
> "testrespectuse" or "usetestrespectfeatures" come to mind or another
> command line option.

Maybe you are not using the latest version of portage? The current
behavior with sys-apps/portage-2.3.48 seems pretty sane to me, for
example see this behavior with dev-python/setuptools-40.0.0 which has
empty RESTRICT:

$ emerge -pvq --nodeps setuptools
[ebuild   R   ] dev-python/setuptools-40.0.0  USE="-test" PYTHON_TARGETS="pypy 
pypy3 python2_7 python3_4 python3_5 python3_6 python3_7" 
$ FEATURES=test emerge -pvq --nodeps setuptools
[ebuild   R   ] dev-python/setuptools-40.0.0  USE="test*" PYTHON_TARGETS="pypy 
pypy3 python2_7 python3_4 python3_5 python3_6 python3_7" 
$ FEATURES=test USE=-test emerge -pvq --nodeps setuptools
[ebuild   R   ] dev-python/setuptools-40.0.0  USE="-test" PYTHON_TARGETS="pypy 
pypy3 python2_7 python3_4 python3_5 python3_6 python3_7" 
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: app-crypt/simp_le

[Michał Górny]

# Michał Górny  (26 Aug 2018)
# Live ebuild only.  Dependencies can no longer be satisfied by ::gentoo
# packages.  Unmaintained.  Bug #659370.  Removal in 30 days.
app-crypt/simp_le

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Zac Medico]

On 08/26/2018 12:39 AM, Michał Górny wrote:
> On Sun, 2018-08-26 at 00:28 -0700, Zac Medico wrote:
>> On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
>>> On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
 On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  
 wrote:
>
> On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
>> ---
>>  general-concepts/dependencies/text.xml | 38 ++
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/general-concepts/dependencies/text.xml 
>> b/general-concepts/dependencies/text.xml
>> index 2f10380..64be9dc 100644
>> --- a/general-concepts/dependencies/text.xml
>> +++ b/general-concepts/dependencies/text.xml
>> @@ -578,6 +578,44 @@ valid.
>>  
>>  
>>
>> +
>> +Test Dependencies
>> +
>> +
>> +
>> +Packages often have optional dependencies that are needed only when 
>> running
>> +tests. These should be specified in DEPEND behind a USE flag. Often, the
>> +'test' USE flag is used for this purpose.
>> +
>> +
>> +
>> +Since testing will likely fail when test dependencies are not 
>> installed, the
>> +test phase should be disabled in this case. This may be accomplished 
>> via USE
>> +conditionals in the RESTRICT variable.
>> +
>> +
>> +
>> +If other optional features must be enabled/disabled when testing, 
>> REQUIRED_USE
>> +may be set to express this.
>> +
>> +
>> +
>> +# Define some USE flags
>> +IUSE="debug test"
>> +
>> +# Disable test phase when test USE flag is disabled
>> +RESTRICT="!test? ( test )"
>
> I do not understand why we need this useless code. If test USE flag
> is disabled, tests must be disabled as well. It is PM's job and
> there is no need to put this obvious stuff into each ebuild with
> tests and extra deps. I see no reason to support running src_test()
> with USE="-test".

 PMS does not specify that behavior (skipping src_test with USE=-test).
 It is better to define the requrement explicitly rather than relying
 on a Portage-specific behavior.
>>>
>>> Then PMS should be fixed. Putting useless code in thousands
>>> of ebuilds due to bureaucratic reasons is ridiculous. Having strict
>>> conformance to the PMS is good, but common sense should still be
>>> considered.
>>
>> Since PMS doesn't specify the behavior of FEATURES, I suppose we could
>> make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
>> drawbacks to that?
> 
> Except for Portage once again silently letting developers pass with non-
> PMS behavior, and making other PMs fail with the ebuilds?

Is it really sane for other PMs to behave that way though?

In PMS it says src_test "may be disabled by user too, using a
PM-specific mechanism", which doesn't explicitly rule out behavior based
on USE settings.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Michał Górny]

On Sun, 2018-08-26 at 00:58 -0700, Zac Medico wrote:
> On 08/26/2018 12:39 AM, Michał Górny wrote:
> > On Sun, 2018-08-26 at 00:28 -0700, Zac Medico wrote:
> > > On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> > > > On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> > > > > On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  
> > > > > wrote:
> > > > > > 
> > > > > > On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
> > > > > > > ---
> > > > > > >  general-concepts/dependencies/text.xml | 38 
> > > > > > > ++
> > > > > > >  1 file changed, 38 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/general-concepts/dependencies/text.xml 
> > > > > > > b/general-concepts/dependencies/text.xml
> > > > > > > index 2f10380..64be9dc 100644
> > > > > > > --- a/general-concepts/dependencies/text.xml
> > > > > > > +++ b/general-concepts/dependencies/text.xml
> > > > > > > @@ -578,6 +578,44 @@ valid.
> > > > > > >  
> > > > > > >  
> > > > > > > 
> > > > > > > +
> > > > > > > +Test Dependencies
> > > > > > > +
> > > > > > > +
> > > > > > > +
> > > > > > > +Packages often have optional dependencies that are needed only 
> > > > > > > when running
> > > > > > > +tests. These should be specified in DEPEND behind a USE flag. 
> > > > > > > Often, the
> > > > > > > +'test' USE flag is used for this purpose.
> > > > > > > +
> > > > > > > +
> > > > > > > +
> > > > > > > +Since testing will likely fail when test dependencies are not 
> > > > > > > installed, the
> > > > > > > +test phase should be disabled in this case. This may be 
> > > > > > > accomplished via USE
> > > > > > > +conditionals in the RESTRICT variable.
> > > > > > > +
> > > > > > > +
> > > > > > > +
> > > > > > > +If other optional features must be enabled/disabled when 
> > > > > > > testing, REQUIRED_USE
> > > > > > > +may be set to express this.
> > > > > > > +
> > > > > > > +
> > > > > > > +
> > > > > > > +# Define some USE flags
> > > > > > > +IUSE="debug test"
> > > > > > > +
> > > > > > > +# Disable test phase when test USE flag is disabled
> > > > > > > +RESTRICT="!test? ( test )"
> > > > > > 
> > > > > > I do not understand why we need this useless code. If test USE flag
> > > > > > is disabled, tests must be disabled as well. It is PM's job and
> > > > > > there is no need to put this obvious stuff into each ebuild with
> > > > > > tests and extra deps. I see no reason to support running src_test()
> > > > > > with USE="-test".
> > > > > 
> > > > > PMS does not specify that behavior (skipping src_test with USE=-test).
> > > > > It is better to define the requrement explicitly rather than relying
> > > > > on a Portage-specific behavior.
> > > > 
> > > > Then PMS should be fixed. Putting useless code in thousands
> > > > of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> > > > conformance to the PMS is good, but common sense should still be
> > > > considered.
> > > 
> > > Since PMS doesn't specify the behavior of FEATURES, I suppose we could
> > > make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
> > > drawbacks to that?
> > 
> > Except for Portage once again silently letting developers pass with non-
> > PMS behavior, and making other PMs fail with the ebuilds?
> 
> Is it really sane for other PMs to behave that way though?
> 
> In PMS it says src_test "may be disabled by user too, using a
> PM-specific mechanism", which doesn't explicitly rule out behavior based
> on USE settings.

It doesn't rule out disabling based on the phase of the moon either, or
my mood which is degrading badly with this discussion.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Michał Górny]

On Sun, 2018-08-26 at 01:43 -0700, Zac Medico wrote:
> On 08/26/2018 01:08 AM, Michał Górny wrote:
> > On Sun, 2018-08-26 at 00:58 -0700, Zac Medico wrote:
> > > On 08/26/2018 12:39 AM, Michał Górny wrote:
> > > > On Sun, 2018-08-26 at 00:28 -0700, Zac Medico wrote:
> > > > > On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> > > > > > On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> > > > > > > On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko 
> > > > > > >  wrote:
> > > > > > > > 
> > > > > > > > On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
> > > > > > > > > ---
> > > > > > > > >  general-concepts/dependencies/text.xml | 38 
> > > > > > > > > ++
> > > > > > > > >  1 file changed, 38 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git a/general-concepts/dependencies/text.xml 
> > > > > > > > > b/general-concepts/dependencies/text.xml
> > > > > > > > > index 2f10380..64be9dc 100644
> > > > > > > > > --- a/general-concepts/dependencies/text.xml
> > > > > > > > > +++ b/general-concepts/dependencies/text.xml
> > > > > > > > > @@ -578,6 +578,44 @@ valid.
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > > 
> > > > > > > > > +
> > > > > > > > > +Test Dependencies
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +Packages often have optional dependencies that are needed 
> > > > > > > > > only when running
> > > > > > > > > +tests. These should be specified in DEPEND behind a USE 
> > > > > > > > > flag. Often, the
> > > > > > > > > +'test' USE flag is used for this purpose.
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +Since testing will likely fail when test dependencies are 
> > > > > > > > > not installed, the
> > > > > > > > > +test phase should be disabled in this case. This may be 
> > > > > > > > > accomplished via USE
> > > > > > > > > +conditionals in the RESTRICT variable.
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +If other optional features must be enabled/disabled when 
> > > > > > > > > testing, REQUIRED_USE
> > > > > > > > > +may be set to express this.
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +# Define some USE flags
> > > > > > > > > +IUSE="debug test"
> > > > > > > > > +
> > > > > > > > > +# Disable test phase when test USE flag is disabled
> > > > > > > > > +RESTRICT="!test? ( test )"
> > > > > > > > 
> > > > > > > > I do not understand why we need this useless code. If test USE 
> > > > > > > > flag
> > > > > > > > is disabled, tests must be disabled as well. It is PM's job and
> > > > > > > > there is no need to put this obvious stuff into each ebuild with
> > > > > > > > tests and extra deps. I see no reason to support running 
> > > > > > > > src_test()
> > > > > > > > with USE="-test".
> > > > > > > 
> > > > > > > PMS does not specify that behavior (skipping src_test with 
> > > > > > > USE=-test).
> > > > > > > It is better to define the requrement explicitly rather than 
> > > > > > > relying
> > > > > > > on a Portage-specific behavior.
> > > > > > 
> > > > > > Then PMS should be fixed. Putting useless code in thousands
> > > > > > of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> > > > > > conformance to the PMS is good, but common sense should still be
> > > > > > considered.
> > > > > 
> > > > > Since PMS doesn't specify the behavior of FEATURES, I suppose we could
> > > > > make FEATURES=test imply RESTRICT="!test? ( test )". Would there be 
> > > > > any
> > > > > drawbacks to that?
> > > > 
> > > > Except for Portage once again silently letting developers pass with non-
> > > > PMS behavior, and making other PMs fail with the ebuilds?
> > > 
> > > Is it really sane for other PMs to behave that way though?
> > > 
> > > In PMS it says src_test "may be disabled by user too, using a
> > > PM-specific mechanism", which doesn't explicitly rule out behavior based
> > > on USE settings.
> > 
> > It doesn't rule out disabling based on the phase of the moon either, or
> > my mood which is degrading badly with this discussion.
> 
> Well, using package.use for this doesn't really make sense within the
> context of ebuilds that don't have IUSE=test, which is an argument for
> people to use package.env as a consistent means to selectively disable
> unit tests.

...and this is how it was supposed to work, and AFAIU how it works right
now.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Zac Medico]

On 08/26/2018 12:14 AM, Zac Medico wrote:
> On 08/24/2018 04:56 PM, Francesco Riosa wrote:
>>
>>
>> Il giorno sab 25 ago 2018 alle ore 01:45 Zac Medico > > ha scritto:
>>
>> On 08/24/2018 04:14 PM, Francesco Riosa wrote:
>> >
>> > Il 24/08/18 19:08, Mike Gilbert ha scritto:
>> >> On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric > > wrote:
>> >>> On Fri, 24 Aug 2018 10:27:01 -0400
>> >>> Mike Gilbert mailto:flop...@gentoo.org>> wrote:
>> >>>
>>  If you want to define behavior that can be relied upon in
>> ebuilds, it
>>  should be specified in PMS. PMS does not define any meaning for the
>>  "test" USE flag.
>> >>> We should eschew idealism about how the world *should* behave,
>> and avoid
>> >>> making portage a steaming garbage heap in order to comply with a
>> >>> terrible PMS specification of a heavily used feature.
>> >> Portage still works just fine for most people who would enable
>> >> FEATURES=test. Stop exaggerating.
>> >>
>> > People enabling FEATURES=test on most but not all packages had some
>> > troubles and they need to disable them in both package.{env,use}
>> > I'd like to have a flag to reinstate the previous portage
>> behaviour, but
>> > that's probably too late
>>
>> Would a FEATURES setting that implies RESTRICT="!test? ( test )" for all
>> ebuilds do what you want?
>>
>>
>> "want" is too much,
>> but it would have been pleasant to have something to keep portage
>> dependancies working as before.
>> "testrespectuse" or "usetestrespectfeatures" come to mind or another
>> command line option.
> 
> Maybe you are not using the latest version of portage? The current
> behavior with sys-apps/portage-2.3.48 seems pretty sane to me, for
> example see this behavior with dev-python/setuptools-40.0.0 which has
> empty RESTRICT:
> 
> $ emerge -pvq --nodeps setuptools
> [ebuild   R   ] dev-python/setuptools-40.0.0  USE="-test" 
> PYTHON_TARGETS="pypy pypy3 python2_7 python3_4 python3_5 python3_6 python3_7" 
> $ FEATURES=test emerge -pvq --nodeps setuptools
> [ebuild   R   ] dev-python/setuptools-40.0.0  USE="test*" 
> PYTHON_TARGETS="pypy pypy3 python2_7 python3_4 python3_5 python3_6 python3_7" 
> $ FEATURES=test USE=-test emerge -pvq --nodeps setuptools
> [ebuild   R   ] dev-python/setuptools-40.0.0  USE="-test" 
> PYTHON_TARGETS="pypy pypy3 python2_7 python3_4 python3_5 python3_6 python3_7" 

Oh, I see that src_test runs even with USE=-test there, so I see why
people are complaining. Anyway, an implicit RESTRICT="!test? ( test )"
setting would solve that.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Zac Medico]

On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
>> On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  wrote:
>>>
>>> On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
 ---
  general-concepts/dependencies/text.xml | 38 ++
  1 file changed, 38 insertions(+)

 diff --git a/general-concepts/dependencies/text.xml 
 b/general-concepts/dependencies/text.xml
 index 2f10380..64be9dc 100644
 --- a/general-concepts/dependencies/text.xml
 +++ b/general-concepts/dependencies/text.xml
 @@ -578,6 +578,44 @@ valid.
  
  

 +
 +Test Dependencies
 +
 +
 +
 +Packages often have optional dependencies that are needed only when 
 running
 +tests. These should be specified in DEPEND behind a USE flag. Often, the
 +'test' USE flag is used for this purpose.
 +
 +
 +
 +Since testing will likely fail when test dependencies are not installed, 
 the
 +test phase should be disabled in this case. This may be accomplished via 
 USE
 +conditionals in the RESTRICT variable.
 +
 +
 +
 +If other optional features must be enabled/disabled when testing, 
 REQUIRED_USE
 +may be set to express this.
 +
 +
 +
 +# Define some USE flags
 +IUSE="debug test"
 +
 +# Disable test phase when test USE flag is disabled
 +RESTRICT="!test? ( test )"
>>>
>>> I do not understand why we need this useless code. If test USE flag
>>> is disabled, tests must be disabled as well. It is PM's job and
>>> there is no need to put this obvious stuff into each ebuild with
>>> tests and extra deps. I see no reason to support running src_test()
>>> with USE="-test".
>>
>> PMS does not specify that behavior (skipping src_test with USE=-test).
>> It is better to define the requrement explicitly rather than relying
>> on a Portage-specific behavior.
> 
> Then PMS should be fixed. Putting useless code in thousands
> of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> conformance to the PMS is good, but common sense should still be
> considered.

Since PMS doesn't specify the behavior of FEATURES, I suppose we could
make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
drawbacks to that?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Michał Górny]

On Sun, 2018-08-26 at 00:28 -0700, Zac Medico wrote:
> On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> > On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
> > > On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  
> > > wrote:
> > > > 
> > > > On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
> > > > > ---
> > > > >  general-concepts/dependencies/text.xml | 38 
> > > > > ++
> > > > >  1 file changed, 38 insertions(+)
> > > > > 
> > > > > diff --git a/general-concepts/dependencies/text.xml 
> > > > > b/general-concepts/dependencies/text.xml
> > > > > index 2f10380..64be9dc 100644
> > > > > --- a/general-concepts/dependencies/text.xml
> > > > > +++ b/general-concepts/dependencies/text.xml
> > > > > @@ -578,6 +578,44 @@ valid.
> > > > >  
> > > > >  
> > > > > 
> > > > > +
> > > > > +Test Dependencies
> > > > > +
> > > > > +
> > > > > +
> > > > > +Packages often have optional dependencies that are needed only when 
> > > > > running
> > > > > +tests. These should be specified in DEPEND behind a USE flag. Often, 
> > > > > the
> > > > > +'test' USE flag is used for this purpose.
> > > > > +
> > > > > +
> > > > > +
> > > > > +Since testing will likely fail when test dependencies are not 
> > > > > installed, the
> > > > > +test phase should be disabled in this case. This may be accomplished 
> > > > > via USE
> > > > > +conditionals in the RESTRICT variable.
> > > > > +
> > > > > +
> > > > > +
> > > > > +If other optional features must be enabled/disabled when testing, 
> > > > > REQUIRED_USE
> > > > > +may be set to express this.
> > > > > +
> > > > > +
> > > > > +
> > > > > +# Define some USE flags
> > > > > +IUSE="debug test"
> > > > > +
> > > > > +# Disable test phase when test USE flag is disabled
> > > > > +RESTRICT="!test? ( test )"
> > > > 
> > > > I do not understand why we need this useless code. If test USE flag
> > > > is disabled, tests must be disabled as well. It is PM's job and
> > > > there is no need to put this obvious stuff into each ebuild with
> > > > tests and extra deps. I see no reason to support running src_test()
> > > > with USE="-test".
> > > 
> > > PMS does not specify that behavior (skipping src_test with USE=-test).
> > > It is better to define the requrement explicitly rather than relying
> > > on a Portage-specific behavior.
> > 
> > Then PMS should be fixed. Putting useless code in thousands
> > of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> > conformance to the PMS is good, but common sense should still be
> > considered.
> 
> Since PMS doesn't specify the behavior of FEATURES, I suppose we could
> make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
> drawbacks to that?

Except for Portage once again silently letting developers pass with non-
PMS behavior, and making other PMs fail with the ebuilds?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"

[Zac Medico]

On 08/26/2018 01:08 AM, Michał Górny wrote:
> On Sun, 2018-08-26 at 00:58 -0700, Zac Medico wrote:
>> On 08/26/2018 12:39 AM, Michał Górny wrote:
>>> On Sun, 2018-08-26 at 00:28 -0700, Zac Medico wrote:
 On 08/25/2018 07:11 PM, Andrew Savchenko wrote:
> On Sat, 25 Aug 2018 14:24:02 -0400 Mike Gilbert wrote:
>> On Sat, Aug 25, 2018 at 1:41 AM Andrew Savchenko  
>> wrote:
>>>
>>> On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote:
 ---
  general-concepts/dependencies/text.xml | 38 ++
  1 file changed, 38 insertions(+)

 diff --git a/general-concepts/dependencies/text.xml 
 b/general-concepts/dependencies/text.xml
 index 2f10380..64be9dc 100644
 --- a/general-concepts/dependencies/text.xml
 +++ b/general-concepts/dependencies/text.xml
 @@ -578,6 +578,44 @@ valid.
  
  

 +
 +Test Dependencies
 +
 +
 +
 +Packages often have optional dependencies that are needed only when 
 running
 +tests. These should be specified in DEPEND behind a USE flag. Often, 
 the
 +'test' USE flag is used for this purpose.
 +
 +
 +
 +Since testing will likely fail when test dependencies are not 
 installed, the
 +test phase should be disabled in this case. This may be accomplished 
 via USE
 +conditionals in the RESTRICT variable.
 +
 +
 +
 +If other optional features must be enabled/disabled when testing, 
 REQUIRED_USE
 +may be set to express this.
 +
 +
 +
 +# Define some USE flags
 +IUSE="debug test"
 +
 +# Disable test phase when test USE flag is disabled
 +RESTRICT="!test? ( test )"
>>>
>>> I do not understand why we need this useless code. If test USE flag
>>> is disabled, tests must be disabled as well. It is PM's job and
>>> there is no need to put this obvious stuff into each ebuild with
>>> tests and extra deps. I see no reason to support running src_test()
>>> with USE="-test".
>>
>> PMS does not specify that behavior (skipping src_test with USE=-test).
>> It is better to define the requrement explicitly rather than relying
>> on a Portage-specific behavior.
>
> Then PMS should be fixed. Putting useless code in thousands
> of ebuilds due to bureaucratic reasons is ridiculous. Having strict
> conformance to the PMS is good, but common sense should still be
> considered.

 Since PMS doesn't specify the behavior of FEATURES, I suppose we could
 make FEATURES=test imply RESTRICT="!test? ( test )". Would there be any
 drawbacks to that?
>>>
>>> Except for Portage once again silently letting developers pass with non-
>>> PMS behavior, and making other PMs fail with the ebuilds?
>>
>> Is it really sane for other PMs to behave that way though?
>>
>> In PMS it says src_test "may be disabled by user too, using a
>> PM-specific mechanism", which doesn't explicitly rule out behavior based
>> on USE settings.
> 
> It doesn't rule out disabling based on the phase of the moon either, or
> my mood which is degrading badly with this discussion.

Well, using package.use for this doesn't really make sense within the
context of ebuilds that don't have IUSE=test, which is an argument for
people to use package.env as a consistent means to selectively disable
unit tests.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc

[Mart Raudsepp]

Ühel kenal päeval, P, 26.08.2018 kell 05:19, kirjutas Andrew Savchenko:
> On Fri, 24 Aug 2018 23:06:46 +0300 Mart Raudsepp wrote:
> > USE=doc has a very overloaded meaning.
> > Meson doesn't ship pre-generated gtk-docs like autotools did, thus
> > developers writing GLib/GTK+ apps may want to keep them around, as
> > libraries move from autotools to meson. gtk-doc is integrated into
> > various IDEs and standalone devhelp viewer, giving a concrete case
> > when
> > one might want to globally enable this (if using those IDEs until
> > they
> > don't have online gtk-doc support that's still in the works,
> > offline
> > developer docs, or matching system versions docs on purpose).
> > Per-package USE=doc is rather inconvenient to manage.
> > 
> > Suggested description for global gtk-doc USE:
> > Build and install gtk-doc based developer documentation
> > 
> > Longer version idea:
> > Build and install gtk-doc based developer documentation for dev-
> > util/devhelp, IDE and offline use
> > 
> > 
> > As the "Build" in the description suggests, this is only for when a
> > generation is needed. In practice this means that it shouldn't be
> > used
> > for autotools based builds from tarballs, where the gtk-doc is
> > already
> > shipped - for those you just want a dev-util/gtk-doc-am build dep,
> > which will make gtkdoc-rebase available that the standard gtk-doc
> > autotools rules call to make the pre-generated docs pretty much
> > equal
> > to what you'd get from regenerating (mainly local offline links).
> > In
> > those aforementioned autotools cases, it's often questionable to
> > have a
> > USE flag (doc) at all for this when using proper tarballs.
> > 
> > Most GNOME libraries have converted to using meson, thus building
> > them
> > is necessary to keep local developer docs available and thus keep
> > IDE
> > integration useful. Just always building gtk-doc would be
> > distasteful
> > to some, hence this global USE flag proposal. There will be dozens
> > of
> > consumers as I bump libraries for GNOME 3.26 and even more so 3.28
> > and
> > 3.30 soon enough afterwards. Some are already there (including some
> > not
> > from GNOME), which currently use USE=doc for this.
> > Instead of supporting disted tarballs with meson, they plan to do
> > aforementioned online docs support for the API docs integrations,
> > but
> > I haven't heard about any progress on that, plus offline use use
> > case
> > will remain anyways.
> 
> Looks like we have a larger issue here. USE=doc covers all types of
> documentation outside of man, info pages and maybe some small text
> files. Such additional documentation often includes API reference
> manual and people may want to have it if they are using it during
> development or may want to disable it, but keep user-level
> documentation, because API docs often take quite some time to
> build. Such cases cover html docs, doxygen docs, gtk-doc and so on.
> 
> So what about some new flag for API reference and other huge
> development documentation? E.g. USE="apidoc"?

According to global description examples (API, Javadoc, etc), that's
already sort of the case, but is used more broadly. So sure, it can be
an option to more clearly and easily differentiate programmer docs from
other docs, but that doesn't cover the use case I'm after.
These other USE="apidoc" won't be usable by gtk-doc and still the
inability to easily enable only gtk-docs - which will be usable in my
IDE, unlike the rest.

Basically I'm after a concrete purpose flag here, like e.g.
USE=handbook is, so it's not that there isn't already prior art of
differing from USE=doc and having a separate flag.


Mart

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

Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc

[Mart Raudsepp]

Ühel kenal päeval, P, 26.08.2018 kell 01:08, kirjutas David Haller:
> Hello,
> 
> On Fri, 24 Aug 2018, Mart Raudsepp wrote:
> [..]
> > Suggested description for global gtk-doc USE:
> > Build and install gtk-doc based developer documentation
> 
> Mentioning gtk-doc, what about:
> https://bugs.gentoo.org/646850
> 
> Ready-made patch since 2018-02-07, and then what?

This is not relevant to this thread. I was not able to track all
bugzilla things at that time, and this looks to be a problem with local
usage of gtk-doc, not for out of the box packages without EXTRA_ECONF
(I'm not aware of packages using gtkdoc-mkpdf for PDFs - they are all
doing just HTML, as the default configure argument for PDF docs is to
disable them). I suspect this particular case just could use a gtk-doc
package bump for upstream, but that involves an upstream rewrite
towards python iirc, and I haven't exactly rushed with bumping that,
because the old version works and there are more important bumps to
work on (nothing has required the newer gtk-doc).

I'm sorry that some bugs fall through the cracks, but I don't mind
pings on bugs (especially those that have concrete fixes waiting), or
pings on IRC or private mail about them. Not this particular thread
though.
There are many other bugs to catch up on, but currently my focus has
been to bring GNOME 3.26 and 3.28 to our users finally. This thread is
a side-product of that.


Mart

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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michał Górny]

On Sun, 2018-08-26 at 17:50 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 26 Aug 2018, Michał Górny wrote:
> > 1. introducing additional *-only licenses that explicitly indicate
> > that a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
> 
> I don't like this at all, because LICENSE="GPL-2" means exactly the
> above, namely GPL version 2, no later version. Therefore, "GPL-2-only"
> would be completely redundant to it.
> 
> What we could do (and what already exists in several ebuilds) is to add
> a *comment* to the LICENSE line, like "# GPL-2 only". This could be
> required for every new ebuild.

Sure, I suppose that would work.

> > 2. annotating the unsuffixed licenses with a warning that they may
> > mean either x-only or x+ due to frequent mistake.
> 
> I don't think that's a good idea either. Also we're not allowed to
> change the license documents:
> "Everyone is permitted to copy and distribute verbatim copies
> of this license document, but changing it is not allowed."

I don't think adding an annotation on top or bottom is equal to changing
it.

> 
> > 3. make repoman warn whenever non-specific variant is used, telling
> > developers to verify whether it's x-only or x+.
> 
> Repoman could check for a comment in the LICENSE line as well, I guess?

Proper handling of comments would be rather hard, especially given that
by definition they have no specific form and therefore users can use
them in weird ways.

> 
> > 4. start migrating packages to x-only or x+ appropriately.
> 
> See above. We could instead migrate ebuilds with "GPL-2" to either:
> LICENSE="GPL-2+"
> or:
> LICENSE="GPL-2" # GPL-2 only

One thing where this would fail would be e.g.:

  LICENSE="GPL-2+
bar? ( GPL-2 )
foo? ( GPL-3+ )" ^ you can't put a comment on the right line

> 
> Optionally, the comment can be removed once all ebuilds have been
> converted.
> 
> > 5. eventually, remove the non-specific licenses and make repoman error
> > out with clear explanation.
> 
> Ulrich

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Francesco Riosa]

Il giorno dom 26 ago 2018 alle ore 20:15 Mart Raudsepp  ha
scritto:

> Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
> > One thing where this would fail would be e.g.:
> >
> >   LICENSE="GPL-2+
> > bar? ( GPL-2 )
> > foo? ( GPL-3+ )" ^ you can't put a comment on the right line
>
> LICENSE="GPL-2+ "
> LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
> LICENSE+="foo? ( GPL-3+ )"
>

Wouldn't this break metadata cache?