[gentoo-dev] Packages up for grabs: patool, mkstage4, dev-python/{prov,pydotplus,ratelimit}

[John Helmert III]

The following packages are up for grabs due to the retirement of their
proxied maintainer:

app-arch/patool
app-backup/mkstage4
dev-python/prov
dev-python/pydotplus
dev-python/ratelimit


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH v2] distutils-r1.eclass: support nonfatal in test

[Sam James]

> On 6 Jan 2023, at 16:31, Michał Górny  wrote:
> 
> On Fri, 2023-01-06 at 16:27 +0100, Toralf Förster wrote:
>> On 1/6/23 01:20, alexey+gen...@asokolov.org wrote:
>>> If the test fails with "die", Xvfb keeps running forever; but it's
>>> cleaned up correctly with die -n
>> 
>> At my tinderbox I do experience sometimes a running dirmngr process
>> solely running since days. /me wonders if that's the result of a similar
>> scenario?
>> 
> 
> Normally it shouldn't be happening since Portage uses PID namespace to
> kill all leftover processes.
> 

Yeah, this is mainly an issue on e.g. prefix or containers.


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] [PATCH v2] distutils-r1.eclass: support nonfatal in test

[Michał Górny]

On Fri, 2023-01-06 at 00:20 +, alexey+gen...@asokolov.org wrote:
> From: Alexey Sokolov 
> 
> Rationale:
> 
> src_test() {
>   virtx distutils-r1_src_test
> }
> 
> If the test fails with "die", Xvfb keeps running forever; but it's
> cleaned up correctly with die -n
> 
> Signed-off-by: Alexey Sokolov 
> ---
>  eclass/distutils-r1.eclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 371d52bcb7e..8896768d3ce 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2022 Gentoo Authors
> +# Copyright 1999-2023 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: distutils-r1.eclass
> @@ -1559,7 +1559,7 @@ distutils-r1_python_test() {
>   esac
>  
>   if [[ ${?} -ne 0 ]]; then
> - die "Tests failed with ${EPYTHON}"
> + die -n "Tests failed with ${EPYTHON}"
>   fi
>  }
>  

Merged now.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] gradle.eclass: add new eclass

[Florian Schmaus]

On 07/01/2023 05.29, Sam James wrote:




On 6 Jan 2023, at 17:20, Florian Schmaus  wrote:

Signed-off-by: Florian Schmaus 
---
eclass/gradle.eclass   | 149 +
eclass/tests/gradle.sh |  62 +
2 files changed, 211 insertions(+)
create mode 100644 eclass/gradle.eclass
create mode 100755 eclass/tests/gradle.sh

diff --git a/eclass/gradle.eclass b/eclass/gradle.eclass
[...]



+
+# @ECLASS_VARIABLE: EGRADLE_MIN
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Minimum required gradle version.
+
+# @ECLASS_VARIABLE: EGRADLE_MAX_EXCLUSIVE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# First gradle version that is not supported.
+
+# @ECLASS_VARIABLE: EGRADLE_EXACT_VER
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The exact required gradle version.
+


It feels a pity to not use the now-somewhat standard
PYTHON_COMPAT/LUA_COMPAT-style API.

Is there a reason not to?

If it doesn't fit how Gradle versioning works / the
number of targets is likely to be far too high,
It's fine as-is.


The _COMPAT-style API would work for Java LTS versions, but not for fast 
moving targets like Gradle versions.


Gradle has overall a good compatibility story, breaking changes are 
typically just introduced in new major versions. But sometimes you need 
a particular Gradle version range, like [6.2,6.8) due the mixins of 
Gradle plugins.


I expect that the number of Java projects that use Gradle will continue 
to grow. Because of that we probably need to provide a diverse range of 
Gradle versions.


- Flow