[gentoo-dev] [PATCH] db-use.eclass: add support for EAPI 8, die on unknown EAPI
Add support for EAPI 8 and drop support for EAPIs < 5. Also explicitly
die on unknown EAPI values. Note that this is a deviation from the
currenty approach that the eclass uses since 86416d2c4bf1 ("eclass:
db-use - Update to eapi7-ver"). But I argue that it is confusing that
your static ananlysis tools (pkgcheck, repoman) complain about an
unsupported EAPI in an eclass, while the ebuild works just fine. While I
also think it is likely that this eclass will support future EAPI
versions without any modifications, my conclusion is that this is actually
an argument to die on unknown EAPIs, since it is trivial to bump, while
on the other hand, you never know if it really works.
---
eclass/db-use.eclass | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
index d23b08d19996..6a3aa8bbd36a 100644
--- a/eclass/db-use.eclass
+++ b/eclass/db-use.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# This is a common location for functions that aid the use of sys-libs/db
#
@@ -8,16 +8,17 @@
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Paul de Vrieze
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: This is a common location for functions that aid the use of
sys-libs/db
# @DESCRIPTION:
# This eclass is designed to provide helpful functions for depending on
# sys-libs/db.
# multilib is used for get_libname in all EAPI
-case "${EAPI:-0}" in
- 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
- *) inherit multilib ;;
+case ${EAPI} in
+ [56]) inherit eapi7-ver ;& # fallthrough
+ [78]) inherit multilib ;;
+ *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
esac
#Convert a version to a db slot
@@ -40,7 +41,6 @@ db_ver_to_slot() {
#Find the version that correspond to the given atom
db_findver() {
- has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
if [ $# -ne 1 ]; then
eerror "Function db_findver needs one argument" >&2
eerror "args given:" >&2
@@ -68,7 +68,6 @@ db_findver() {
# to test for, it will aim to find the library corresponding to it.
db_includedir() {
- has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
if [ $# -eq 0 ]; then
VER="$(db_findver sys-libs/db)" || return 1
VER="$(db_ver_to_slot "$VER")"
@@ -102,7 +101,6 @@ db_includedir() {
# packages to test for, it will aim to find the library corresponding to it.
db_libname() {
- has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
if [ $# -eq 0 ]; then
VER="$(db_findver sys-libs/db)" || return 1
if [ -e
"${EPREFIX}/usr/$(get_libdir)/libdb-${VER}$(get_libname)" ]; then
--
2.34.1
[gentoo-dev] [PATCH v2] db-use.eclass: add support for EAPI 8, die on unknown EAPI
Add support for EAPI 8 and drop support for EAPIs < 5. Also explicitly
die on unknown EAPI values. Note that this is a deviation from the
currenty approach that the eclass uses since 86416d2c4bf1 ("eclass:
db-use - Update to eapi7-ver"). But I argue that it is confusing that
your static ananlysis tools (pkgcheck, repoman) complain about an
unsupported EAPI in an eclass, while the ebuild works just fine. While I
also think it is likely that this eclass will support future EAPI
versions without any modifications, my conclusion is that this is actually
an argument to die on unknown EAPIs, since it is trivial to bump, while
on the other hand, you never know if it really works.
Signed-off-by: Florian Schmaus
---
eclass/db-use.eclass | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
index d23b08d19996..55e72286fda4 100644
--- a/eclass/db-use.eclass
+++ b/eclass/db-use.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# This is a common location for functions that aid the use of sys-libs/db
#
@@ -8,16 +8,17 @@
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Paul de Vrieze
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: This is a common location for functions that aid the use of
sys-libs/db
# @DESCRIPTION:
# This eclass is designed to provide helpful functions for depending on
# sys-libs/db.
# multilib is used for get_libname in all EAPI
-case "${EAPI:-0}" in
- 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
- *) inherit multilib ;;
+case ${EAPI} in
+ 5|6) inherit eapi7-ver ;& # fallthrough
+ 7|8) inherit multilib ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
#Convert a version to a db slot
@@ -40,7 +41,6 @@ db_ver_to_slot() {
#Find the version that correspond to the given atom
db_findver() {
- has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
if [ $# -ne 1 ]; then
eerror "Function db_findver needs one argument" >&2
eerror "args given:" >&2
@@ -68,7 +68,6 @@ db_findver() {
# to test for, it will aim to find the library corresponding to it.
db_includedir() {
- has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
if [ $# -eq 0 ]; then
VER="$(db_findver sys-libs/db)" || return 1
VER="$(db_ver_to_slot "$VER")"
@@ -102,7 +101,6 @@ db_includedir() {
# packages to test for, it will aim to find the library corresponding to it.
db_libname() {
- has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
if [ $# -eq 0 ]; then
VER="$(db_findver sys-libs/db)" || return 1
if [ -e
"${EPREFIX}/usr/$(get_libdir)/libdb-${VER}$(get_libname)" ]; then
--
2.34.1
[gentoo-dev] Last rites: dev-java/log4j
# Volkmar W. Pogatzki (2022-04-03) # Java library without consumers. # Multiple vulnerabilities (bug #719146). # Removal in 30 days. dev-java/log4j - Flow
[gentoo-dev] Last rites: net-misc/jrdesktop
# Volkmar W. Pogatzki (2022-04-04) # Last upstream activities in 2009. # Fails to compile with java 11 or higher (bug #831262). # Removal in 30 days. net-misc/jrdesktop - Flow
Re: [gentoo-dev] [PATCH] rebar.eclass: depend on slotted rebar2
On 10/04/2022 15.33, Matthew Smith wrote:
Depend on the Rebar 2 slot in preparation for the addition of rebar:3.
Signed-off-by: Matthew Smith
---
eclass/rebar.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
index 17ae8e0d765..e7a64bb7a7e 100644
--- a/eclass/rebar.eclass
+++ b/eclass/rebar.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: rebar.eclass
@@ -35,7 +35,7 @@ EXPORT_FUNCTIONS src_prepare src_compile src_test
src_install
RDEPEND="dev-lang/erlang:="
DEPEND="${RDEPEND}"
BDEPEND="
- dev-util/rebar
+ dev-util/rebar:0
>=sys-apps/gawk-4.1
"
if [[ ${EAPI} == 6 ]]; then
lgtm
- Flow
Re: [gentoo-dev] [PATCH] java-utils-2.eclass: remove ebegin calls that lack eend calls
On 15/04/2022 17.43, Yuan Liao (Leo) wrote: noting is, unlike compilation of a C/C++ program, where each compiler […] a single invocation of javac usually involves putting _all_ Java source files' names into the command-line arguments. We do use javac's @argfiles, e.g., @sources.lst, some places (probably not in all). Otherwise, where @argfiles are not used, I think it is more likely that you run into an exec() argument length issue with a large source file count before the emerge output becomes an issue. That said, I am sympathetic to the concerns you raised. Ideally the build.log should include the full command while only a shortened version is printed to the console. However, I am not aware that this is possible with portage. And if it is not (yet) possible, then I lean towards capturing the whole command line. - Flow
Re: [gentoo-dev] Re: [PATCH 1/1] edo.eclass: add new eclass
On 16/04/2022 10.38, Ulrich Mueller wrote:
On Sat, 16 Apr 2022, Sam James wrote:
+# @FUNCTION: edo
Just a remark: A similar command existed a long time ago under the
name "try". [1]
It was executed under "env" [2], should we also do that?
+# @USAGE: command [arg1 [arg2 ...]]
should be in angle brackets, if we follow the usual
convention. Maybe even " [arg]..."
+# @DESCRIPTION:
+# Executes 'command' with any given arguments and exits on failure unless
+# called under 'nonfatal'.
+edo() {
+ elog "$@"
+ "$@" || die -n "Failed to run command: $@ failed"
+}
Maybe add an ebegin/eend variant?
+1
edobe() {
nit: I'd personally would use 'edob', as shorter is sometimes better
plus every begin needs an end, so no need to explicitly state that there
is an end.
ebegin "Running $@"
"$@"
eend $? || die -n "$@ failed" > return $?
I think this return statement can be omitted since it will always be
invoked with 0 as argument, and this is the default behavior of implicit
function return (IIRC).
- Flow
Re: [gentoo-dev] [PATCH v2 1/1] edo.eclass: add new eclass
On 16/04/2022 20.14, Sam James wrote:
Bug: https://bugs.gentoo.org/744880
Signed-off-by: Sam James
---
eclass/edo.eclass | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 eclass/edo.eclass
diff --git a/eclass/edo.eclass b/eclass/edo.eclass
new file mode 100644
index ..7b4ae04c43ab
--- /dev/null
+++ b/eclass/edo.eclass
@@ -0,0 +1,46 @@
+# Copyright 2022 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: edo.class
+# @MAINTAINER:
+# QA Team
+# @AUTHOR:
+# Sam James
+# @SUPPORTED_EAPIS: 7 8
+# @BLURB: Convenience function to run commands verbosely and die on failure
+# @DESCRIPTION:
+# This eclass provides the 'edo' command, and an 'edob' variant for
ebegin/eend,
+# which dies (exits) on failure and logs the command used verbosely.
+#
+
+case ${EAPI:-0} in
+ 7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_EDO_ECLASS} ]] ; then
+ _EDO_CLASS=1
typo: s/_CLASS/_ECLASS/
+
+# @FUNCTION: edo
+# @USAGE: [...]
+# @DESCRIPTION:
+# Executes 'command' with any given arguments and exits on failure unless
+# called under 'nonfatal'.
+edo() {
+ elog "$@"
+ "$@" || die -n "Failed to run command: $@ failed"
+}
+
+# @FUNCTION: edob
+# @USAGE: [...]
+# @DESCRIPTION:
+# Executes 'command' with ebegin & eend with any given arguments and exits
+# on failure unless called under 'nonfatal'.
Maybe mention that 'command' should be "short". I do not know if we want
or can provide a concrete value that determines shortness.
+# Intended for single commands, otherwise regular ebegin/eend should be used.
I think it is obvious that it can be only used for single commands. If I
am not mistaken, using multiple commands within ebegin/eend also means
that those commands, or, at least all commands after the first, can not
(or at least "should not") be printed/logged, as I assume that it would
break eend()'s positioning.
With multiple commands (e.g., cmd1, cmd2, cmd3), I'd probably suggest to
edo cmd1
edo cmd2
edo cmd3
since I personally like to avoid the inflationary usage of ebegin/eend
and instead recommend to use ebegin/eend only for a few long-running
milestone commands in the ebuild (if any).
Hence I don't like that the description line above redirects the user to
ebegin/eend. It can probably simply be dropped.
+edob() {
+ ebegin "Running $@"
+ "$@"
+ eend $? || die -n "$@ failed"
+}
+
+fi
Like ionen, I also wondered if this could be an argument to edo, but I
believe this would clutter edo's implementation with argument parsing
and additional logic. Hence I believe having two separate functions, as
in this patch, is the way to go.
Thanks Sam!
- Flow
[gentoo-dev] Last rites: unused java EAPI=6 libraries
# Volkmar W. Pogatzki (2022-04-17) # Unused java libraries. Removal in 30 days. dev-java/boot-bin dev-java/eclipsito dev-java/gcj-jdk dev-java/japitools dev-java/jboss-marshalling dev-java/jdbc-mssqlserver dev-java/jsr250 dev-java/maven-hawtjni-plugin dev-java/mimepull dev-java/oracle-javamail dev-java/xjavac - Flow
[gentoo-dev] Last rites: app-text/jabref
# Volkmar W. Pogatzki (2022-04-19) # Release of the source-based ebuild is from 2014. At the moment # impossible to provide source-based ebuild for the current version. # Up-to-date binary package exists. Removal on 2022-05-30 app-text/jabref dev-java/glazedlists dev-java/jempbox dev-java/microba dev-java/spin - Flow
Re: [gentoo-dev] Stabilization request - what instruction to follow
On 22/04/2022 10.42, Vlastimil Krejčíř wrote: Hi all, Hi Vlastimil, I'd like to send a stabilization request for a package (I'm not a maintainer of the package, I just sent a new ebuild a month and half ago). I have found at least two guides: https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide#Request_stabilization Gentoo *users* want to follow this guide. https://devmanual.gentoo.org/keywording/index.html#moving-from-arch-to-arch As this is part of Gentoo's devmanual (Developer Manual), it is targeted at developers. Your case sounds like you simply want to fill a bug report requesting stabilization. - Flow
[gentoo-dev] [PATCH] java-utils-2.eclass: introduce JAVA_TEST_RUNNER_EXTRA_ARGS
Also add special handling wrt -usedfaultlisteners for TestNG, see
bug #801694.
Signed-off-by: Florian Schmaus
Co-authored-by: Miroslav Šulc
Bug: https://bugs.gentoo.org/801694
---
eclass/java-utils-2.eclass | 49 +++---
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 2a649942550c..6303895885df 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -139,6 +139,20 @@ JAVA_PKG_ALLOW_VM_CHANGE=${JAVA_PKG_ALLOW_VM_CHANGE:="yes"}
# )
# @CODE
+# @ECLASS-VARIABLE: JAVA_TEST_RUNNER_EXTRA_ARGS
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Array of extra arguments that should be passed to the test runner when
running tests.
+# It is useful when you need to pass an extra argument to the test runner.
+#
+# It is used only when running tests.
+#
+# @CODE
+# JAVA_TEST_RUNNER_EXTRA_ARGS=(
+# -verbose 3
+# )
+# @CODE
+
# @ECLASS_VARIABLE: JAVA_PKG_DEBUG
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -1807,8 +1821,18 @@ ejunit_() {
if [[ "${junit}" == "junit-4" ]] ; then
runner=org.junit.runner.JUnitCore
fi
- debug-print "Calling: java -cp \"${cp}\" -Djava.io.tmpdir=\"${T}\"
-Djava.awt.headless=true ${JAVA_TEST_EXTRA_ARGS[@]} ${runner} ${@}"
- java -cp "${cp}" -Djava.io.tmpdir="${T}/" -Djava.awt.headless=true
${JAVA_TEST_EXTRA_ARGS[@]} ${runner} "${@}" || die "Running junit failed"
+
+ local args=(
+ -cp ${cp}
+ -Djava.io.tmpdir="${T}"
+ -Djava.awt.headless=true
+ ${JAVA_TEST_EXTRA_ARGS[@]}
+ ${runner}
+ ${JAVA_TEST_RUNNER_EXTRA_ARGS[@]}
+ ${@}
+ )
+ debug-print "Calling: java ${args[@]}"
+ java "${args[@]}" || die "Running junit failed"
}
# @FUNCTION: ejunit
@@ -1886,12 +1910,21 @@ etestng() {
tests+="${test},"
done
- debug-print "java -cp \"${cp}\" -Djava.io.tmpdir=\"${T}\""\
- "-Djava.awt.headless=true ${JAVA_TEST_EXTRA_ARGS[@]} ${runner}"\
- "-usedefaultlisteners false -testclass ${tests}"
- java -cp "${cp}" -Djava.io.tmpdir=\"${T}\" -Djava.awt.headless=true
${JAVA_TEST_EXTRA_ARGS[@]}\
- ${runner} -usedefaultlisteners false -testclass ${tests}\
- || die "Running TestNG failed."
+ local args=(
+ -cp ${cp}
+ -Djava.io.tmpdir="${T}"
+ -Djava.awt.headless=true
+ ${JAVA_TEST_EXTRA_ARGS[@]}
+ ${runner}
+ ${JAVA_TEST_RUNNER_EXTRA_ARGS[@]}
+ )
+
+ [[ ! "${JAVA_TEST_RUNNER_EXTRA_ARGS[@]}" =~ "-usedefaultlisteners" ]]
&& args+=( -usedefaultlisteners false )
+
+ args+=( -testclass ${tests} )
+
+ debug-print "java ${args[@]}"
+ java ${args[@]} || die "Running TestNG failed."
}
# @FUNCTION: java-utils-2_src_prepare
--
2.35.1
[gentoo-dev] Last rites: dev-java/jgraph
# Volkmar W. Pogatzki (2022-04-22) # Unused java library. Removal on 2022-05-24. dev-java/jgraph - Flow
[gentoo-dev] Last rites: dev-util/checkstyle and app-emacs/jde
# Volkmar W. Pogatzki (2022-04-22) # Blocks removal of vulnerable dev-java/guava:20, bug #833309. # Removal on 2022-05-30 dev-util/checkstyle app-emacs/jde - Flow
[gentoo-dev] [PATCH] eclass/java-utils-2.eclass: drop gnu-classpath
From: "Volkmar W. Pogatzki"
Bug: https://bugs.gentoo.org/786093
Package-Manager: Portage-3.0.18, Repoman-3.0.2
Signed-off-by: Volkmar W. Pogatzki
Closes: https://github.com/gentoo/gentoo/pull/21218
Signed-off-by: Florian Schmaus
---
eclass/java-utils-2.eclass | 45 +++---
1 file changed, 8 insertions(+), 37 deletions(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 6303895885df..5b4783f350f2 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -43,21 +43,6 @@ has test ${JAVA_PKG_IUSE} && RESTRICT+=" !test? ( test )"
JAVA_PKG_E_DEPEND=">=dev-java/java-config-2.2.0-r3"
has source ${JAVA_PKG_IUSE} && JAVA_PKG_E_DEPEND="${JAVA_PKG_E_DEPEND} source?
( app-arch/zip )"
-# @ECLASS_VARIABLE: JAVA_PKG_WANT_BOOTCLASSPATH
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# The version of bootclasspath the package needs to work. Translates to a
proper
-# dependency. The bootclasspath can then be obtained by
java-ant_rewrite-bootclasspath
-if [[ -n "${JAVA_PKG_WANT_BOOTCLASSPATH}" ]]; then
- if [[ "${JAVA_PKG_WANT_BOOTCLASSPATH}" == "1.5" ]]; then
- JAVA_PKG_E_DEPEND="${JAVA_PKG_E_DEPEND}
>=dev-java/gnu-classpath-0.98-r1:0.98"
- else
- eerror "Unknown value of JAVA_PKG_WANT_BOOTCLASSPATH"
- # since die in global scope doesn't work, this will make
repoman fail
- JAVA_PKG_E_DEPEND="${JAVA_PKG_E_DEPEND}
BAD_JAVA_PKG_WANT_BOOTCLASSPATH"
- fi
-fi
-
# @ECLASS_VARIABLE: JAVA_PKG_ALLOW_VM_CHANGE
# @DESCRIPTION:
# Allow this eclass to change the active VM?
@@ -76,9 +61,9 @@ JAVA_PKG_ALLOW_VM_CHANGE=${JAVA_PKG_ALLOW_VM_CHANGE:="yes"}
#
# Should only be used for testing and debugging.
#
-# Example: use sun-jdk-1.5 to emerge foo:
+# Example: use openjdk-11 to emerge foo:
# @CODE
-# JAVA_PKG_FORCE_VM=sun-jdk-1.5 emerge foo
+# JAVA_PKG_FORCE_VM=openjdk-11 emerge foo
# @CODE
# @ECLASS_VARIABLE: JAVA_PKG_WANT_BUILD_VM
@@ -103,9 +88,9 @@ JAVA_PKG_ALLOW_VM_CHANGE=${JAVA_PKG_ALLOW_VM_CHANGE:="yes"}
#
# Should generally only be used for testing and debugging.
#
-# Use 1.4 source to emerge baz
+# Use 1.8 source to emerge baz
# @CODE
-# JAVA_PKG_WANT_SOURCE=1.4 emerge baz
+# JAVA_PKG_WANT_SOURCE=1.8 emerge baz
# @CODE
# @ECLASS_VARIABLE: JAVA_PKG_WANT_TARGET
@@ -118,9 +103,9 @@ JAVA_PKG_ALLOW_VM_CHANGE=${JAVA_PKG_ALLOW_VM_CHANGE:="yes"}
#
# Should generally only be used for testing and debugging.
#
-# emerge bar to be compatible with 1.3
+# emerge bar to be compatible with 1.8
# @CODE
-# JAVA_PKG_WANT_TARGET=1.3 emerge bar
+# JAVA_PKG_WANT_TARGET=1.8 emerge bar
# @CODE
# @ECLASS_VARIABLE: JAVA_TEST_EXTRA_ARGS
@@ -1387,7 +1372,7 @@ java-pkg_register-environment-variable() {
# @DESCRIPTION:
# Returns classpath of a given bootclasspath-providing package version.
#
-# @param $1 - the version of bootclasspath (e.g. 1.5), 'auto' for bootclasspath
+# @param $1 - the version of bootclasspath (e.g. 1.8), 'auto' for bootclasspath
# of the current JDK
java-pkg_get-bootclasspath() {
local version="${1}"
@@ -1397,9 +1382,6 @@ java-pkg_get-bootclasspath() {
auto)
bcp="$(java-config -g BOOTCLASSPATH)"
;;
- 1.5)
- bcp="$(java-pkg_getjars --build-only
gnu-classpath-0.98)"
- ;;
*)
eerror "unknown parameter of java-pkg_get-bootclasspath"
die "unknown parameter of java-pkg_get-bootclasspath"
@@ -2580,20 +2562,9 @@ java-pkg_setup-vm() {
debug-print-function ${FUNCNAME} $*
local vendor="$(java-pkg_get-vm-vendor)"
- if [[ "${vendor}" == "sun" ]] && java-pkg_is-vm-version-ge "1.5" ; then
- addpredict "/dev/random"
- elif [[ "${vendor}" == "ibm" ]]; then
- addpredict "/proc/self/maps"
- addpredict "/proc/cpuinfo"
- addpredict "/proc/self/coredump_filter"
- elif [[ "${vendor}" == "oracle" ]]; then
+ if [[ "${vendor}" == icedtea* ]] && java-pkg_is-vm-version-ge "1.8" ;
then
addpredict "/dev/random"
addpredict "/proc/self/coredump_filter"
- elif [[ "${vendor}" == icedtea* ]] && java-pkg_is-vm-version-ge "1.7" ;
then
- addpredict "/dev/random"
- addpredict "/proc/self/coredump_filter"
- elif [[ "${vendor}" == "jrockit" ]]; then
- addpredict "/proc/cpuinfo"
fi
}
--
2.35.1
[gentoo-dev] [PATCH] ltprune.eclass: restrict find to regular files in example code
Akin to the (pending) change of the policy guide [1], adjust the example
code to restrict find to regular files.
1: https://github.com/gentoo/policy-guide/pull/24
Signed-off-by: Florian Schmaus
---
eclass/ltprune.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/ltprune.eclass b/eclass/ltprune.eclass
index e7d8cd2c4f92..5a36647d1d1c 100644
--- a/eclass/ltprune.eclass
+++ b/eclass/ltprune.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: ltprune.eclass
@@ -12,7 +12,7 @@
#
# Discouraged. Whenever possible, please use much simpler:
# @CODE
-# find "${ED}" -name '*.la' -delete || die
+# find "${ED}" -type f -name '*.la' -delete || die
# @CODE
if [[ -z ${_LTPRUNE_ECLASS} ]]; then
--
2.35.1
[gentoo-dev] [PATCH] java-pkg-simple.eclass: eqawarn if module-info.java is not compiled
In preperation of this ewarn part becoming 'die' (bug #842447), switch
it to eqawarn to improve catching the affected packages.
Bug: https://bugs.gentoo.org/796875
Bug: https://bugs.gentoo.org/842447
Signed-off-by: Florian Schmaus
---
eclass/java-pkg-simple.eclass | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass
index eab56460eef6..47499c7870a9 100644
--- a/eclass/java-pkg-simple.eclass
+++ b/eclass/java-pkg-simple.eclass
@@ -1,4 +1,4 @@
-# Copyright 2004-2021 Gentoo Authors
+# Copyright 2004-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: java-pkg-simple.eclass
@@ -17,7 +17,8 @@
# directory before calling the src_compile function of this eclass.
case ${EAPI:-0} in
- [5678]) ;;
+ 5|6) inherit eutils ;; # eutils for eqawarn
+ 7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -393,8 +394,8 @@ java-pkg-simple_src_compile() {
JAVA_PKG_WANT_SOURCE=${tmp_source}
JAVA_PKG_WANT_TARGET=${tmp_target}
else
- ewarn "Need at least JDK 9 to compile module-info.java
in src_compile,"
- ewarn "see https://bugs.gentoo.org/796875";
+ eqawarn "Need at least JDK 9 to compile
module-info.java in src_compile."
+ eqawarn "Please adjust DEPEND accordingly. See
https://bugs.gentoo.org/796875#c3";
fi
fi
--
2.35.1
Re: [gentoo-dev] [PATCH] java-pkg-simple.eclass: eqawarn if module-info.java is not compiled
On 04/05/2022 07.57, Ulrich Mueller wrote:
On Wed, 04 May 2022, Florian Schmaus wrote:
+ 5|6) inherit eutils ;; # eutils for eqawarn
Adding eutils in 2022 seems a little backwards. Maybe make the output
command conditional instead? Something like this:
# conditional needed in EAPIs 5 and 6
local eqawarn=eqawarn
declare -F eqawarn >/dev/null || eqawarn=ewarn
${eqawarn} ...
Alternatively, port the few remaining EAPI 5 and 6 consumers to a newer
EAPI. :)
This is being worked on.
That said, I am not sure if a ewarn fallback is sensible. I was told
eqawarn can be used to trigger tinderbox bugs, and that is exactly what
we want, to see if there are any affected packages that we did not
identify yet. And some of those potential packages are EAPI < 7.
- Flow
[gentoo-dev] Last rites: java-virtuals/jms & Co.
# Volkmar W. Pogatzki (2022-05-04) # Unused java libraries and useless java-virtual. Removal on 2022-06-04 dev-java/glassfish-jms-api dev-java/sun-jms java-virtuals/jms - Flow
[gentoo-dev] Last rites: dev-java/commons-jxpath
# Volkmar W. Pogatzki (2022-05-06) # Unused java library. Removal on 2022-06-06 dev-java/commons-jxpath - Flow
[gentoo-dev] Last rites:net-analyzer/{greenbone-security-assistant,ospd}
# Florian Schmaus (2022-05-10) # Was split by upstream (and us) into # net-analyzer/gsa and net-analyzer/gsad. # Removal on 2022-06-10. net-analyzer/greenbone-security-assistant # Florian Schmaus (2022-05-10) # Functionality now in net-analyzer/ospd-openvas. # Removal on 2022-06-10. net-analyzer/ospd - Flow
Re: [gentoo-dev] Should we join the which hunt?
On 13/05/2022 09.11, Ulrich Mueller wrote: So, should we join the "which hunt", with the goal of removing sys-apps/which from the system set and from stage1? Yes, please. If there is a equally powerful bash builtin, and even a POSIX shell function, that performs the same task as the external command, than the shell builtins should be used. Since ebuilds are bash, it seems safe to use "type -p" in them. Would it be possible to add a QA check to portage that detects invalid usages of 'which' and flags them to be replaced with "type -p"? I think that would be a good first step. - Flow
Re: [gentoo-dev] [PATCH] eclass/ruby-fakegem.eclass: depend on virtual/pkgconfig
On 20.05.22 09:17, Hans de Graaff wrote:
Many C extensions depend on pkgconfig during their configure phase and
this is easy to mis in the ebuild. Handle this in the eclass instead
even though the dependency will not be needed for all extensions.
Closes: https://bugs.gentoo.org/845393
Signed-off-by: Hans de Graaff
---
eclass/ruby-fakegem.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index 358fff1be753..754b48f82fa9 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -210,6 +210,11 @@ case ${EAPI} in
;;
esac
+# Many (but not all) extensions use pkgconfig in src_configure.
+if [ ${#RUBY_FAKEGEM_EXTENSIONS[@]} -ge 1 ]; then
+ BDEPEND+=" virtual/pkgconfig "
+fi
+
Not sure if we have a policy on this, but how about using bash's
extended test syntax, i.e., [[ … ]] (which the eclass already uses in a
few places).
- Flow
[gentoo-dev] About EGO_SUM
EGO_SUM is marked as 'deprecated' in go-module.eclass [1, 2]. I
acknowledge that there are packages where the usage of EGO_SUM is very
problematic. However, I wonder if there are packages where using
dependency tarballs is problematic while using EGO_SUM would be not.
Take for example an ebuild containing
SRC_URI="
https://salsa.debian.org/baz/${PN}/-/archive/v${PV}/${PN}-v${PV}.tar.bz2
-> ${P}.tar.bz2
https://personal.site/files/gentoo/${P}-vendor.tar.xz
"
where ${P}-vendor.tar.xz is a Go dependency tarball, containing only a
few Go modules. Hence EGO_SUM would contain only a few entries in this case.
I see multiple issues of using dependency tarballs in such cases.
First, my trust in a tarball created by someone and hosted somewhere is
lower than the contents of the artifacts hosted on an official hub.
Next, if anyone takes the time to review the contents of the dependency
tarball, it may only benefit Gentoo. On the other hand, if someone
reviews EGO_SUM artifacts, the whole Go ecosystem will benefit.
I may not know Gentoo's mirror system in detail, but I believe using
EGO_SUM facilitates cross-package distfile sharing. While dependency
tarballs will increase the space requirements, and, probably more
importantly, the load on the mirrors.
Even more problematic are that dependency tarballs require additional
steps that would not be required when EGO_SUM is used. While those steps
appear simple, behavioral theory shows that even the tiniest additional
steps have a huge impact (e.g., online shops loose a relative large
share of customers if for each an additional checkout step). If we force
dependency tarballs for Go software, then packaging Go software just
become a little bit harder.
This leads me to the question why are we actually deprecating EGO_SUM?
It seems like a nice alternative for Go packaging that we may want to
keep. But maybe I am missing something?
- Flow
1:
https://github.com/gentoo/gentoo/blob/9fec686abf789fdff36a90c3763d9558203cbf9a/eclass/go-module.eclass#L108
2:
https://github.com/gentoo/gentoo/blob/9fec686abf789fdff36a90c3763d9558203cbf9a/eclass/go-module.eclass#L349-L352
[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...
On 05/06/2022 10.28, Joonas Niilola wrote: sys-block/hpssacli I grabbed this one. - Flow
[gentoo-dev] [PATCH] java-vm-2.eclass: add BDEPEND="app-arch/unzip"
Closes: https://bugs.gentoo.org/850415
Reported-by: Joonas Niilola
Signed-off-by: Florian Schmaus
---
eclass/java-vm-2.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/java-vm-2.eclass b/eclass/java-vm-2.eclass
index 7c63e63fad76..c0aea3e9ea4a 100644
--- a/eclass/java-vm-2.eclass
+++ b/eclass/java-vm-2.eclass
@@ -24,6 +24,11 @@ RDEPEND="
app-eselect/eselect-java
"
DEPEND="${RDEPEND}"
+BDEPEND="app-arch/unzip"
+
+if [[ ${EAPI} == 6 ]]; then
+ DEPEND+="${BDEPEND}"
+fi
export WANT_JAVA_CONFIG=2
--
2.35.1
[gentoo-dev] Proposal to undeprecate EGO_SUM
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa
[gentoo-dev] [PATCH] go-module.eclass: undeprecate EGO_SUM
Following the gentoo-dev@ mailing list discussion [1], this
un-deprecates EGO_SUM.
1:
https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa
Signed-off-by: Florian Schmaus
---
eclass/go-module.eclass | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index a5dafb45cab8..2e0b7dc1726d 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -25,7 +25,9 @@
#
# If the software has a directory named vendor in its
# top level directory, the only thing you need to do is inherit the
-# eclass. If it doesn't, you need to also create a dependency tarball and
+# eclass. If it doesn't, then you either 1) populate EGO_SUM in the ebuild and
+# call go-module_set_globals as discussed below or 2) you need to create a
+# dependency tarball and
# host it somewhere, for example in your dev space.
#
# Here is an example of how to create a dependency tarball.
@@ -52,9 +54,14 @@
#
# inherit go-module
#
+# EGO_SUM=(
+# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
+# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
+# )
+#
+# go-mdoule_set_globals
# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
-# Add this line if you have a dependency tarball.
-# SRC_URI+=" ${P}-deps.tar.xz"
+# SRC_URI+=" ${EGO_SUM_SRC_URI}"
#
# @CODE
@@ -105,11 +112,7 @@ QA_FLAGS_IGNORED='.*'
RESTRICT+=" strip"
# @ECLASS_VARIABLE: EGO_SUM
-# @DEPRECATED: none
# @DESCRIPTION:
-# This is replaced by a dependency tarball, see above for how to create
-# one.
-#
# This array is based on the contents of the go.sum file from the top
# level directory of the software you are packaging. Each entry must be
# quoted and contain the first two fields of a line from go.sum.
@@ -153,7 +156,6 @@ RESTRICT+=" strip"
# go.sum copy of the Hash1 values during building of the package.
# @ECLASS_VARIABLE: _GOMODULE_GOPROXY_BASEURI
-# @DEPRECATED: none
# @DESCRIPTION:
# Golang module proxy service to fetch module files from. Note that the module
# proxy generally verifies modules via the Hash1 code.
@@ -176,7 +178,6 @@ RESTRICT+=" strip"
: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
# @ECLASS_VARIABLE: _GOMODULE_GOSUM_REVERSE_MAP
-# @DEPRECATED: none
# @DESCRIPTION:
# Mapping back from Gentoo distfile name to upstream distfile path.
# Associative array to avoid O(N*M) performance when populating the GOPROXY
@@ -206,7 +207,6 @@ ego() {
}
# @FUNCTION: go-module_set_globals
-# @DEPRECATED: none
# @DESCRIPTION:
# Convert the information in EGO_SUM for other usage in the ebuild.
# - Populates EGO_SUM_SRC_URI that can be added to SRC_URI
@@ -297,7 +297,6 @@ go-module_set_globals() {
}
# @FUNCTION: go-module_setup_proxy
-# @DEPRECATED: none
# @DESCRIPTION:
# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
# this function in src_unpack.
@@ -341,14 +340,11 @@ go-module_setup_proxy() {
# @FUNCTION: go-module_src_unpack
# @DESCRIPTION:
# If EGO_SUM is set, unpack the base tarball(s) and set up the
-# local go proxy. Also warn that this usage is deprecated.
+# local go proxy.
# - Otherwise, if EGO_VENDOR is set, bail out.
# - Otherwise do a normal unpack.
go-module_src_unpack() {
if [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
- eqawarn "This ebuild uses EGO_SUM which is deprecated"
- eqawarn "Please migrate to a dependency tarball"
- eqawarn "This will become a fatal error in the future"
_go-module_src_unpack_gosum
elif [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
eerror "${EBUILD} is using EGO_VENDOR which is no longer
supported"
@@ -359,7 +355,6 @@ go-module_src_unpack() {
}
# @FUNCTION: _go-module_src_unpack_gosum
-# @DEPRECATED: none
# @DESCRIPTION:
# Populate a GOPROXY directory hierarchy with distfiles from EGO_SUM and
# unpack the base distfiles.
@@ -405,7 +400,6 @@ _go-module_src_unpack_gosum() {
}
# @FUNCTION: _go-module_gosum_synthesize_files
-# @DEPRECATED: none
# @DESCRIPTION:
# Given a path & version, populate all Goproxy metadata files which aren't
# needed to be downloaded directly.
@@ -433,7 +427,6 @@ _go-module_gosum_synthesize_files() {
}
# @FUNCTION: _go-module_src_unpack_verify_gosum
-# @DEPRECATED: none
# @DESCRIPTION:
# Validate the Go modules declared by EGO_SUM are sufficient to cover building
# the package, without actually building it yet.
@@ -482,7 +475,6 @@ go-module_live_vendor() {
}
# @FUNCTION: _go-module_gomod_encode
-# @DEPRECATED: none
# @DESCRIPTION:
# Encode the name(path) of a Golang module in the format expected by Goproxy.
#
--
2.35.1
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 13/06/2022 10.29, Michał Górny wrote: On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa "We've been rehashing the discussion until all opposition got tired and stopped replying, then we claim everyone agrees". I understand this comment so that there was already a discussion about deprecating and removing EGO_SUM. I usually try to follow what's going on Gentoo and I remember the discussion about introducing dependency tarballs. But I apparently have missed the part where EGO_SUM was slated for removal. And it appears I am not the only one, at least Ionen also wrote "Missed bits and pieces but was never quite sure why this went toward full deprecation, just discouraged may have been fair enough, …". In any case, I am sorry for bringing this discussion up again. But since I started rehashing this, no arguments why EGO_SUM should be removed have been provided. And so far, I failed to find the old discussions where I'd hope to find some rationale behind the deprecation of EGO_SUM. :/ - Flow
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 13/06/2022 10.49, Ulrich Mueller wrote: On Mon, 13 Jun 2022, Michał Górny wrote: On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa Can this be done without requesting changes to package managers? What is 'this' here? The patchset does not make changes to any package manager, just the go-module eclass. Note that this is not about finding about an alternative to dependency tarballs. It is just about re-allowing EGO_SUM in addition to dependency tarballs for packaging Go software in Gentoo. - Flow
Re: [gentoo-dev] [PATCH] go-module.eclass: undeprecate EGO_SUM
On 13/06/2022 11.49, Andrew Ammerlaan wrote: On 13/06/2022 09:44, Florian Schmaus wrote: Following the gentoo-dev@ mailing list discussion [1], this un-deprecates EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa Signed-off-by: Florian Schmaus --- eclass/go-module.eclass | 30 +++--- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass index a5dafb45cab8..2e0b7dc1726d 100644 --- a/eclass/go-module.eclass +++ b/eclass/go-module.eclass @@ -25,7 +25,9 @@ # # If the software has a directory named vendor in its # top level directory, the only thing you need to do is inherit the -# eclass. If it doesn't, you need to also create a dependency tarball and +# eclass. If it doesn't, then you either 1) populate EGO_SUM in the ebuild and +# call go-module_set_globals as discussed below or 2) you need to create a +# dependency tarball and # host it somewhere, for example in your dev space. # # Here is an example of how to create a dependency tarball. I agree that EGO_SUM shouldn't have been completely deprecated following the previous discussion. It is not always possible or practical to host a dependency tarball, especially for people who aren't Gentoo developers. However, from what I remember from the previous discussion there actually were some good arguments against using EGO_SUM, mainly relating to the size of the ebuilds and manifests. What's wrong with an ebuild using an EGO_SUM with a few entries in ::gentoo? - Florian
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 14/06/2022 11.37, Michał Górny wrote: On Mon, 2022-06-13 at 10:29 +0200, Michał Górny wrote: On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa "We've been rehashing the discussion until all opposition got tired and stopped replying, then we claim everyone agrees". First of all, I am sorry for my tone. No worries and no offense taken. I can easily see how this could be considered rehashing a old discussion, but the truth is simply that the deprecation of EGO_SUM cough me by surprise. I have been thinking about it and I was wrong to oppose this change. I have been conflating two problem: EGO_SUM and Manifest sizes. However, while EGO_SUM might be an important factor contributing to the latter, I think we shouldn't single it out and instead focus on addressing the actual problem. Exactly my line of though. Especially since it is not unlikely that we will run into this problem with other programming language ecosystems too (where the "dependency tarball" solution may not be easily viable). That said, I believe it's within maintainer's right to decide what API to deprecate and what API to support. So I'd suggest getting William's approval for this rather than changing the supported API of that eclass via drive-by commits. That was never my intention, hence the subject starts with "Proposal to" and I explicitly but William in CC. I believed that one week after the discussion around my initial gentoo-dev@ post, which gave me the impression that un-deprecating EGO_SUM has some supporters and no opposer, it was time to post a concrete proposal in form of a suggested code change. Looking forward to William's take on this. :) - Flow
Re: [gentoo-dev] Re: Proposal to undeprecate EGO_SUM
On 14.06.22 18:33, Holger Hoffstätte wrote: So my idea here is: instead of chucking EGO_SUM (automatically generated declarative dependency management) out the window, can we not separate the two and instead of uploading the tarball upload the dependency set instead? I think that this idea that has been pitched already (see for example Robin's post [1]), although in a broader non-Go-specific sense and it is one obvious way to move forward. An, and probably the largest, obstacle is that this can not be implemented in an eclass alone. Due the sandboxing during the build process, fetching distfiles, which is what we are talking about, is the package managers job and hence, I believe, this would require adustments to the package manager and package manager specification (PMS). The basic idea, at least to my understanding (or how I would propose it), is to have a new top-level ebuild variable SRC_URI_FILE="https://example.org/manifests/restic-0.13.1.files"; where restic-0.13.1.files contains lines like [] which is, as you nicely demonstrated on the restic ebuild, where the bytes contributing to the ebuild size bloat originate from. Those bytes are now outsourced from ::gentoo, can be fetched on-demand, allowing the package manager to download the individual distfiles into DISTDIR, where an, e.g., the go eclass can process them further within the constraints of the security sandbox. - Flow 1: https://archives.gentoo.org/gentoo-dev/message/8e2a4002bfc6258d65dcf725db347cb9
[gentoo-dev] [PATCH] java-vm-2.eclass: use "eselect java-vm update" if available
Thanks to Mike Gilbert (floppym) for valuable feedback.
Closes: https://bugs.gentoo.org/853928
Closes: https://github.com/gentoo/gentoo/pull/26069
Signed-off-by: Florian Schmaus
---
eclass/java-vm-2.eclass | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/eclass/java-vm-2.eclass b/eclass/java-vm-2.eclass
index 8196b1cdc72a..dc0d87f4caf5 100644
--- a/eclass/java-vm-2.eclass
+++ b/eclass/java-vm-2.eclass
@@ -25,6 +25,7 @@ RDEPEND="
"
DEPEND="${RDEPEND}"
BDEPEND="app-arch/unzip"
+IDEPEND="app-eselect/eselect-java"
if [[ ${EAPI} == 6 ]]; then
DEPEND+=" ${BDEPEND}"
@@ -88,14 +89,35 @@ java-vm-2_pkg_postinst() {
xdg_desktop_database_update
}
+# @FUNCTION: has_eselect_java-vm_update
+# @INTERNAL
+# @DESCRIPTION:
+# Checks if an eselect-java version providing "eselect java-vm update"
+# is available.
+# @RETURN: 0 if >=app-eselect/eselect-java-0.5 is installed, 1 otherwise.
+has_eselect_java-vm_update() {
+ local has_version_args="-b"
+ if [[ ${EAPI} == 6 ]]; then
+ has_version_args="--host-root"
+ fi
+
+ has_version "${has_version_args}" ">=app-eselect/eselect-java-0.5"
+}
# @FUNCTION: java-vm-2_pkg_prerm
# @DESCRIPTION:
# default pkg_prerm
#
-# Warn user if removing system-vm.
+# Does nothing if eselect-java-0.5 or newer is available. Otherwhise,
+# warn user if removing system-vm.
java-vm-2_pkg_prerm() {
+ if has_eselect_java-vm_update; then
+ # We will potentially switch to a new Java system VM in
+ # pkg_postrm().
+ return
+ fi
+
if [[ $(GENTOO_VM= java-config -f 2>/dev/null) == ${VMHANDLE} && -z
${REPLACED_BY_VERSION} ]]; then
ewarn "It appears you are removing your system-vm! Please run"
ewarn "\"eselect java-vm list\" to list available VMs, then use"
@@ -108,10 +130,14 @@ java-vm-2_pkg_prerm() {
# @DESCRIPTION:
# default pkg_postrm
#
-# Update mime database.
+# Invoke "eselect java-vm update" if eselect-java 0.5, or newer, is
+# available. Also update the mime database.
java-vm-2_pkg_postrm() {
xdg_desktop_database_update
+ if has_eselect_java-vm_update; then
+ eselect --root="${EROOT}" java-vm update
+ fi
}
--
2.35.1
Re: [gentoo-dev] [PATCH] java-vm-2.eclass: use "eselect java-vm update" if available
On 27/06/2022 21.39, Georgy Yakovlev wrote:
On Mon, 2022-06-27 at 21:21 +0200, Florian Schmaus wrote:
Thanks to Mike Gilbert (floppym) for valuable feedback.
Closes: https://bugs.gentoo.org/853928
Closes: https://github.com/gentoo/gentoo/pull/26069
Signed-off-by: Florian Schmaus
---
eclass/java-vm-2.eclass | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/eclass/java-vm-2.eclass b/eclass/java-vm-2.eclass
index 8196b1cdc72a..dc0d87f4caf5 100644
--- a/eclass/java-vm-2.eclass
+++ b/eclass/java-vm-2.eclass
@@ -25,6 +25,7 @@ RDEPEND="
"
DEPEND="${RDEPEND}"
BDEPEND="app-arch/unzip"
+IDEPEND="app-eselect/eselect-java"
IDEPEND here will not do anything to current jdk source ebuilds.
Right, this is specified providently. I've updated the commit message of
the change in the according pull request to make this more clear.
Also note that PMS does not guarantee that IDEPEND dependencies will be
available in pkg_*rm phases.
But ultimately, declaring IDEPEND on eselect-java is the best thing we
can do here.
openjdk source ebuilds are EAPI7 at the moment and can't be updated to
EAPI8 due to econf unconditionally passing '--disable-static'
I remember running into this when I tried to bump the JDK ebuilds to EAPI 8.
- Flow
Re: [gentoo-dev] [PATCH] eclass/java-utils-2.eclass: testng print verbose output
On 28/06/2022 19.04, Volkmar W. Pogatzki wrote:
Bug: https://bugs.gentoo.org/801694
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-utils-2.eclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index e5a2b611d11..cfe04d631a0 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -1901,7 +1901,9 @@ etestng() {
${JAVA_TEST_RUNNER_EXTRA_ARGS[@]}
)
- [[ ! "${JAVA_TEST_RUNNER_EXTRA_ARGS[@]}" =~ "-usedefaultlisteners" ]] && args+=( -usedefaultlisteners false )
+ if [[ ! "${JAVA_TEST_RUNNER_EXTRA_ARGS[@]}" =~ "-usedefaultlisteners"
]]; then
+ args+=( -verbose 3 -usedefaultlisteners true )
+ fi
args+=( -testclass ${tests} )
LGTM, but I would split the args value in multiple lines, which makes it
clear what the argument name and the argument value is and hence makes
it easier to read:
args+=(
-verbose 3
-usedefaultlisteners true
)
- Flow
[gentoo-dev] Re: Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
On 29/06/2022 09.15, Joonas Niilola wrote: Packages up for grabs: … sys-libs/liburing I'd take this one. Co-maintainers welcome :) - Flow
[gentoo-dev] [PATCH] java-pkg-simple.eclass: invoke einstalldocs
On EAPI 6, or newer, invoke einstalldocs in
java-pkg-simple_src_install.
Closes: https://bugs.gentoo.org/789582
Signed-off-by: Florian Schmaus
---
eclass/java-pkg-simple.eclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass
index 47499c7870a9..1e101a828c40 100644
--- a/eclass/java-pkg-simple.eclass
+++ b/eclass/java-pkg-simple.eclass
@@ -424,7 +424,7 @@ java-pkg-simple_src_compile() {
# @DESCRIPTION:
# src_install for simple single jar java packages. Simply installs
# ${JAVA_JAR_FILENAME}. It will also install a launcher if
-# ${JAVA_MAIN_CLASS} is set.
+# ${JAVA_MAIN_CLASS} is set. Also invokes einstalldocs.
java-pkg-simple_src_install() {
local sources=sources.lst classes=target/classes apidoc=target/api
@@ -455,6 +455,12 @@ java-pkg-simple_src_install() {
fi
java-pkg_dosrc ${srcdirs}
fi
+
+ if [[ ${EAPI} == 5 ]]; then
+ # einstalldocs is only available on EAPI >= 6.
+ return
+ fi
+ einstalldocs
}
# @FUNCTION: java-pkg-simple_src_test
--
2.35.1
[gentoo-dev] proposal
I'd like to propose a new metadata XML element for packages: Maintainers can signal to other developers (and of course contributors in general) that they are happy with others to make changes to the ebuilds without prior consultation of the maintainer. Of course, this is not a free ticket to always make changes to packages that you do not maintain without prior consultation of the maintainer. I would expect people to use their common sense to decide if a change may require maintainer attention or not. In general, it is always a good idea to communicate changes in every case. The absence of the flag does not automatically allow the conclusion that the maintainer is opposed to non-maintainer commits. It just means that the maintainer's stance is not known. I do not believe that we need a flag, but if the need arises, we could always consider adding one. Although, in my experience, people mostly like to communicate the "non-maintainer commits welcome" policy with others. WDYT? - Flow
Re: [gentoo-dev] proposal
On 04/07/2022 17.27, David Seifert wrote: Ultimately, all these things really matter when only the defaults change. Turn-right-on-red in the US is such a thing, because unless otherwise stated, it's the norm. Knowing our devbase, with roughly 75% mostly AWOL and barely reading the MLs, I don't think this idea will bring about the desired change. This sounds like you assume that the majority of Gentoo devs are OK with other people making changes to their packages. This very well could be true, but without an indication you never know if the maintainer feels this way. Instead, we should really just go for the tag, because my feeling is that the default will be that most maintainers don't mind non-maintainer commits, except a select few territorial ones. It appears that we have at least two options here: A) Establish that the default is non-maintainer-commits-welcome, and introduce a metadata element. B) Declare the default to be unspecified and introduce two metadata elements: and . I think you are proposing A) here, but please correct me if I am wrong. Personally I would tend to B). But I have no strong opinion on this, as long as some kind of signalling is established. How do others feel about this? - Flow
Re: [gentoo-dev] proposal
On 07.07.22 09:45, Michal Prívozník wrote: I think that rejecting a contribution (regardless of the flag) should be based on technical merit, rather than individual maintainers personal preferences. I do understand some packages are like your babies, you watch them grow, fine tune everything. But in the end, if somebody finds a bug in the ebuild/eclass/... and is even willing to provide a fix, we should have a discussion about the proposed fix rather than refer to a flag (or lack of thereof) when closing the MR (unmerged). It was never the intention to create a scenario where maintainers reject a contribution based on such a flag. Gentoo, being free and open source software, if fully aligned with the spirit of FOSS, which *everyone* can use, study, share and *improve*. With the replies in mind, I gave this some more thought. I think the best default is "everyone can propose changes to the maintainer, on which the maintainer has to act within a reasonable amount of time". However, there are maybe cases where trivial fixes for low-maintenance packages are for some reason not merged into ::gentoo and the maintainer is unresponsive. If those packages where flagged with , then I would be less reluctant to commit them to ::gentoo. After committing, I would always inform the maintainer. On the other hand, there is the situation where seemingly innocent changes could cause some fallout, because this is the kind of package where you assume you know what is going on from reading the ebuild and playing with it, but you actually don't. Such packages could carry a flag indicating that all changes require review by the maintainer. It appears that gives the wrong impression, so maybe ? - Flow
Re: [gentoo-dev] [PATCH v3 0/2] Add esed.eclass for modifying with checks for no-op
FWIW: In an idealistic, but naive attempt, I've submitted a patch to upstream sed that adds an --error-if-unmodifed option [1]. Fellow Gentoo developers where quick to point out in #gentoo-dev that this patch barley scratches the surface of the sphere where sed could mutate state. It appears that --error-if-unmodifed in sed can only be reliable implemented if --inplace is used, by basically mimicking what Ionen's esed class does/did. This made me wonder if fixing this in sed is really the ideal solution. However, Ionen also closed the PR due to "having seconds thoughts" [2]. I guess this leaves us with qa-sed from app-portage/iwdevtools. Which is probably not the worst outcome. - Flow 1: https://lists.gnu.org/archive/html/sed-devel/2022-07/msg1.html 2: https://github.com/gentoo/gentoo/pull/25662#issuecomment-1165265901
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 15/07/2022 23.34, William Hubbs wrote: On Mon, Jun 27, 2022 at 01:43:19AM +0200, Zoltan Puskas wrote: In summary, IMHO the EGO_SUM way of handling of go packages has more benefits than drawbacks compared to the vendor tarballs. EGO_SUM can cause portage to break; that is the primary reason support is going away. We attempted another solution that was refused, so the only option we have currently is to build the dependency tarballs. That reads as if you wrote it under the assumption that we can only either use dependency tarballs or use EGO_SUM. At the same time, I have not seen an argument why we can not simply do *both*. EGO_SUM has numerous advantages over dependency tarballs, but can not be used if the size of the EGO_SUM value crosses a threshold. So why not mandate dependency tarballs if a point is crossed and otherwise allow EGO_SUM? That way, we could have the best of both worlds. - Flow
Keeping unused acct-{user,group} packages. Was: Re: [gentoo-dev] Last rites: sys-cluster/slurm
On 15/08/2022 09.31, Ionen Wolkens wrote:
On Mon, Aug 15, 2022 at 08:56:51AM +0200, Ulrich Mueller wrote:
On Mon, 15 Aug 2022, John Helmert wrote:
# John Helmert III (2022-08-14)
# Many vulnerabilities (including code execution and root privilege
# escalation), effectively unmaintained. Removal in 30 days, bugs
# #631552, #790296, #842789
sys-cluster/slurm
This will leave acct-{user,group}/slurm without reverse dependencies.
Last-rite them, too?
Aren't we still stuck on what to do with [1]?
[1] https://bugs.gentoo.org/781881
FWIW, I am not sure why we should keep the unused acct-{user,group}
packages. At least I don't see how removing them would cause any issues
or confusion? The bug appears to be light on arguments in favor of
keeping them. Quite contrary, I think keeping them could cause some
confusion, as users may start looking for the according actual package
and hope to find it.
But maybe I am missing something?
Needless to say that I am only talking about the acct-{user,group}
packages, the uid-gid.txt reservation should stay for obvious reasons.
And this also rules out that the IDs are re-assigned.
- Flow
Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
On 22/08/2022 20.10, Kenton Groombridge wrote: Hi everyone, I noticed that there are many systemd units which are shipped by various packages which could be hardened, some further than they are currently and some that could use some hardening in general. Yes, please. Nevertheless, as others have already pointed out, this is an upstream issue and should be treated as such. That is, please feel encouraged and encourage others to submit patches upstream that adds hardening measurements to their systemd units. I usually find https://ruderich.org/simon/notes/systemd-service-hardening a good starting point when I want to harden a service. By addressing this upstream, everyone benefits, and potential issues caused by the hardening measurements are fixed faster (as they affect a more extensive user base). - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
On 25/08/2022 15.25, Kenton Groombridge wrote: I think the best way to address this is to have packages ship unit override files instead of unit files themselves which enable these options. For example, instead of Gentoo shipping a modified miniflux.service unit file, we can instead install a file to /etc/system/miniflux.service.d/00gentoo.conf using the existing systemd_install_serviced helper in systemd.eclass which enables these options. Wouldn't the proper place for overrides installed by a distributions package manager be /usr/lib/systemd/system/miniflux.service.d/gentoo.conf - Flow
Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
On 25/08/2022 17.03, Michał Górny wrote: On Thu, 2022-08-25 at 16:06 +0200, Florian Schmaus wrote: On 25/08/2022 15.25, Kenton Groombridge wrote: I think the best way to address this is to have packages ship unit override files instead of unit files themselves which enable these options. For example, instead of Gentoo shipping a modified miniflux.service unit file, we can instead install a file to /etc/system/miniflux.service.d/00gentoo.conf using the existing systemd_install_serviced helper in systemd.eclass which enables these options. Wouldn't the proper place for overrides installed by a distributions package manager be /usr/lib/systemd/system/miniflux.service.d/gentoo.conf These files are meant to be modifiable by the sysadmin, so they don't belong in /usr. While then can not be modified, settings made in /usr/lib/systemd/system can be overridden by the sysadmin by placing a file in /etc/systemd/system. I am not aware of a reason why a package manger should install systemd configuration files under /etc. - Flow
Re: [gentoo-dev] Registering media types for Gentoo files
On 06.09.22 11:33, Michał Górny wrote: Hi, everyone. Since we've been standardizing some things in Gentoo lately, I was thinking we could try to get some media types registered with IANA. Particularly, I'm thinking of registering our Manifest format [1] as: text/vnd.gentoo.manifest and our new binary package container format [2] as: application/vnd.gentoo.gpkg However, the process is non-trivial and I'm not sure if the latter really qualifies, given we're only specifying the container and not the complete data format. To be honest, the specs are quite huge and I'd really appreciate some help grasping all of this. Perhaps ebuilds and eclasses would also qualify for registration. WDYT? If you are happy to put in the effort, then I would go for it. Some (most?) IANA registries are relatively easy to get in. I have some, but somewhat little, experience with IANA due my XMPP background and I am happy to assist. - Flow
Re: [gentoo-dev] [PATCH 2/3] glep-0074: Specify supported hash algorithms
On 11/09/2022 15.14, Michał Górny wrote: +.. table:: Table 1. Defined hash algorithms + :widths: auto + :class: table table-bordered table-striped + + === === === + NameSpecification Bits Enc. Notes + === === === + ``BLAKE2B`` RFC 7693 [#RFC7693]_512 Hex Recommended + ``BLAKE2S`` ditto 256 Hex + ``MD5`` RFC 1321 [#RFC1321]_128 Hex Deprecated + ``RMD160`` RIPEMD-160 [#RMD160]_ 160 Hex Deprecated + ``SHA1``FIPS 180-4 [#SHS]_ 160 Hex Deprecated + ``SHA256`` ditto 256 Hex + ``SHA512`` ditto 512 Hex Recommended + ``SHA3_256``FIPS 202 [#SHA3]_ 256 Hex + ``SHA3_512``ditto 512 Hex + ``STREEBOG256`` RFC 6986 [#RFC6986]_256 Hex + ``STREEBOG512`` ditto 512 Hex + ``WHIRLPOOL`` Whirlpool [#WHIRLPOOL]_ 512 Hex + === === === Personally, I would slightly prefer repeating the source specification, instead of using "ditto". - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
I would like to continue discussing whether we should entirely deprecate EGO_SUM without the desire to offend anyone. We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic is a very popular backup software written in Go. The PR drops EGO_SUM in favor of a vendor tarball created by the proxied maintainer. However, I am unaware of any tool that lets you practically audit the 35 MiB source contained in the tarball. And even if such a tool exists, this would mean another manual step is required, which is, potentially, skipped most of the time, weakening our user's security. This is because I believe neither our tooling, e.g., go-mod.eclass, nor any Golang tooling, does authenticate the contents of the vendor tarball against upstream's go.sum. But please correct me if I am wrong. I wonder if we can reach consensus around un-depreacting EGO_SUM, but discouraging its usage in certain situations. That is, provide EGO_SUM as option but disallow its use if 1.) *upstream* provides a vendor tarball 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer maintains the package 3.) the number of EGO_SUM entries exceeds 1500 and a proxied maintainer maintains the package In case of 3, I would encourage proxy maintainers to create and provide the vendor tarball. The suggested EGO_SUM limits result from a histogram that I created analyzing ::gentoo at 2022-01-01, i.e., a few months before EGO_SUM was deprecated. - Flow 1: https://github.com/gentoo/gentoo/pull/27050
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 28/09/2022 23.23, John Helmert III wrote: On Wed, Sep 28, 2022 at 05:28:00PM +0200, Florian Schmaus wrote: I would like to continue discussing whether we should entirely deprecate EGO_SUM without the desire to offend anyone. We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic is a very popular backup software written in Go. The PR drops EGO_SUM in favor of a vendor tarball created by the proxied maintainer. However, I am unaware of any tool that lets you practically audit the 35 MiB source contained in the tarball. And even if such a tool exists, this would mean another manual step is required, which is, potentially, skipped most of the time, weakening our user's security. This is because I believe neither our tooling, e.g., go-mod.eclass, nor any Golang tooling, does authenticate the contents of the vendor tarball against upstream's go.sum. But please correct me if I am wrong. I wonder if we can reach consensus around un-depreacting EGO_SUM, but discouraging its usage in certain situations. That is, provide EGO_SUM as option but disallow its use if 1.) *upstream* provides a vendor tarball 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer maintains the package 3.) the number of EGO_SUM entries exceeds 1500 and a proxied maintainer maintains the package I'm not sure I agree on these limits, given the authenticity problem exists regardless of how many dependencies there are. It's not really about authentication, you always have to trust upstream to some degree (unless you audit every line of code). But I believe that code distributed via official channels is viewed by more eyes and significantly more secure. EGO_SUM entries are directly fetched from the official distribution channels of Golang. Hence, there is a higher chance that malicious code in one of those is detected faster, simply because they are consumed by more entities. Compared to the dependency tarball that is just used by Gentoo. In contrast to the official sources, "nobody" is looking at the code inside the tarball. For proxied packages, where the dependency tarball is published by the proxied maintainer, the tarball also allows another entity to inject code into the final result of the package. And compared to a few small patches in FILESDIR, such a dependency tarball requires more effort to review. This further weakens security in comparison to EGO_SUM. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 30/09/2022 02.36, William Hubbs wrote: On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: On Wed, 28 Sep 2022, Florian Schmaus wrote: 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer maintains the package 3.) the number of EGO_SUM entries exceeds 1500 and a proxied maintainer maintains the package These numbers seem quite large, compared to the mean number of 3.4 distfiles for packages in the Gentoo repository. (The median and the 99-percentile are 1 and 22, respectively.) The numbers may appear large when compared to the whole tree, but I think a fair comparison would be within the related programming language ecosystem, e.g., Golang or Rust. For example, analyzing ::gentoo yields the following histogram for 2022-01-01: https://dev.gentoo.org/~flow/ego_sum_entries_histogram-2020-01-01.png To stay with your example, restic has a 300k manifest, multiple 30k+ ebuilds and897 distfiles. I'm thinking the limit would have to be much lower. Say, around 256 entries in EGO_SUM_SRC_URI. A limit of 256 appears to be to low to be of any use. It is slightly above the 50th percentile, half of the packages could not use it. We have to realize that programming language ecosystems that only build static binaries tend to produce software projects that have a large number of dependencies. For example, app-misc/broot, a tool written in Rust, has currently 310 entries in its Manifest. Why should we threat one programming language different from another? Will be see voices that ask for banning Rust packages in ::gentoo in the future? With the rising popularity of Golang and Rust, we will (hopefully) only ever see an increase of such packages in ::gentoo. And most existing packages in this category will at best keep their dependency count constant, but are also likely to accumulate further dependencies over time. And quite frankly, I don't see a problem with "large" Manifests and/or ebuilds. Yes, it means our FTPs are hosting many files, in some cases even many small files. And yes, it means that in some cases ebuild parsing takes a bit longer. But I spoke with a few developers in the past few months and was not presented with any real world issues that EGO_SUM caused. If someone wants to fill in here, then now is a good time to speak up. But my impression is that the arguments against EGO_SUM are mostly of cosmetic nature. Again, please correct me if I am wrong. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 30/09/2022 16.36, Jaco Kroon wrote: Hi All, This doesn't directly affect me. Nor am I familiar with the mechanisms. Perhaps it's worthwhile to suggest that EGO_SUM itself may be externalized. I don't know what goes in here, and this will likely require help from portage itself, so may not be directly viable. What if portage had a feature whereby a SRC_URI list could be downloaded as a SRC_URI itself? In other words: SRC_URI_INDIRECT="https://wherever/lists_for_some_go_package.txt"; That idea pops-up every time this is discussed. I don't see something like that anytime soon implemented in portage (please correct me if wrong) and it means that the ebuild development workflow requires some adjustments, to keep it as convenient as it currently is (but nothing couldn't be abstracted away by good tooling, i.e., pkgdev). jkroon@plastiekpoot ~ $ du -sh /var/db/repos/gentoo/ 644M /var/db/repos/gentoo/ I'm not against exploding this by another 200 or even 300 MB personally, but I do agree that pointless bloat is bad, and ideally we want to shrink the size requirements of the portage tree rather than enlarge. What is the problem if it is 400 MB more? ? What if we double the size? Would something break for you? Does that mean we should not add more packages to ::gentoo? Where do you draw the line? Would you rather have interested persons contribute to Gentoo or drive them away due the struggle that the EGO_SUM deprecation causes? - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 30/09/2022 21.49, Alec Warner wrote:
On Fri, Sep 30, 2022 at 7:53 AM Florian Schmaus wrote:
And quite frankly, I don't see a problem with "large" Manifests and/or
ebuilds. Yes, it means our FTPs are hosting many files, in some cases
even many small files. And yes, it means that in some cases ebuild
parsing takes a bit longer. But I spoke with a few developers in the
past few months and was not presented with any real world issues that
EGO_SUM caused. If someone wants to fill in here, then now is a good
time to speak up. But my impression is that the arguments against
EGO_SUM are mostly of cosmetic nature. Again, please correct me if I am
wrong.
I thought the problem was that EGO_SUM ends up in SRC_URI, which ends
up in A. A ends up in the environment, and then exec() fails with
E2BIG because there is an imposed limit on environment variables (and
also command line argument length.)
Did this get fixed?
https://bugs.gentoo.org/719202
Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It
appears that the ebuild had more than 6000 entries in SRC_URI [1], from
which A is generated from. Hence even a EGO_SUM limit of 3000 entries
should provide enough safety margin to avoid any Golang ebuild running
into this.
- Flow
1: Estimated via
curl
https://raw.githubusercontent.com/gentoo-mirror/gentoo/39474128bc64d6d4738c9647dbd3b0d1c1268fc4/metadata/md5-cache/dev-texlive/texlive-latexextra-2020
| grep SRC_URI | awk -F" " '{print NF-1}'
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 01/10/2022 18.36, Ulrich Mueller wrote: On Sat, 01 Oct 2022, Florian Schmaus wrote: Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It appears that the ebuild had more than 6000 entries in SRC_URI [1], That includes double counting and must be divided by the number of developers in TEXLIVE_DEVS. AFAICS that number was two in 2020. So 3000 is more realistic as a number there. That may be very well the case. I'd appreciate if you would elaborate on the double counting. If someone knows a good and easy way to compute A for an ebuild, then please let me know. That would help to get more meaningful data. from which A is generated from. Hence even a EGO_SUM limit of 3000 entries should provide enough safety margin to avoid any Golang ebuild running into this. See above, with 3000 entries there may be zero safety margin. It also depends on total filename length, because the limit is the Linux kernel's MAX_ARG_STRLEN (which is 128 KiB). Of course, this is a rough estimation assuming that the filename length is roughly the same on average. That said, my proposed limit for EGO_SUM is 1500, which is still half of 3000 and should still provide enough safety margin. - Flow
Re: [gentoo-dev] [PATCH] java-pkg-simple.eclass: improve MANIFEST.MF manipulation
On 04/10/2022 21.19, Volkmar W. Pogatzki wrote:
For adding Main-class and/or Automatic-module-name to MANIFEST.MF it
seems better to use "jar" functionality at the end of compilation.
This does the necessary checks and issues warnings in case of duplicate
entries.
Closes: https://bugs.gentoo.org/874924
Signed-off-by: Volkmar W. Pogatzki
---
eclass/java-pkg-simple.eclass | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass
index 7a9582393dd..5f691571e53 100644
--- a/eclass/java-pkg-simple.eclass
+++ b/eclass/java-pkg-simple.eclass
@@ -415,15 +415,6 @@ java-pkg-simple_src_compile() {
fi
# package
- [[ ! -d ${classes}/META-INF ]] && mkdir ${classes}/META-INF
- if [[ -v JAVA_AUTOMATIC_MODULE_NAME ]]; then
- echo "Automatic-Module-Name: ${JAVA_AUTOMATIC_MODULE_NAME}" \
- >> ${classes}/META-INF/MANIFEST.MF || die "adding module
name failed"
- fi
- if [[ -v JAVA_MAIN_CLASS ]]; then
- echo "Main-Class: ${JAVA_MAIN_CLASS}" \
- >> ${classes}/META-INF/MANIFEST.MF || die "adding main class
failed"
- fi
local jar_args
if [[ -e ${classes}/META-INF/MANIFEST.MF ]]; then
jar_args="cfm ${JAVA_JAR_FILENAME}
${classes}/META-INF/MANIFEST.MF"
@@ -431,6 +422,18 @@ java-pkg-simple_src_compile() {
jar_args="cf ${JAVA_JAR_FILENAME}"
fi
jar ${jar_args} -C ${classes} . || die "jar failed"
+ if [[ -v JAVA_AUTOMATIC_MODULE_NAME ]]; then
+ echo "Automatic-Module-Name: ${JAVA_AUTOMATIC_MODULE_NAME}" \
+ >> "${T}/add-to-MANIFEST.MF" || die "adding module name
failed"
+ fi
+ if [[ -v JAVA_MAIN_CLASS ]]; then
+ echo "Main-Class: ${JAVA_MAIN_CLASS}" \
+ >> "${T}/add-to-MANIFEST.MF" || die "adding main class
failed"
+ fi
+ if [[ -e ${T}/add-to-MANIFEST.MF ]]; then
Quote T and use -f
if [[ -f "${T}"/add-to-MANIFEST.MF ]]; then
+ jar ufmv ${JAVA_JAR_FILENAME} "${T}/add-to-MANIFEST.MF" \
+ || die "updating MANIFEST.MF failed"
+ fi
}
# @FUNCTION: java-pkg-simple_src_install
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] RFC: check A's size in go-module.eclass
This is a first suggestion in an effort to reach a compromise that allows EGO_SUM to be un-depracted. I have decided to check the size of A, instead of counting the entries in EGO_SUM, because that seemed more sensible given that as A's size caused functional issues in the past (bug #719202 [1]). 1: https://bugs.gentoo.org/719202
[gentoo-dev] [PATCH] go-module.eclass: ensure that A is less than 112 KiB
Packages with a large number of EGO_SUM entries, i.e., many thousands,
cause SRC_URI, and in turn A, to become quite large. Prevent issues that
are caused by large environment variables, e.g., execve() errors (see
bug #719203), by ensuring that A stays below a reasonable size.
Signed-off-by: Florian Schmaus
---
eclass/go-module.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 8047d498b08d..88414b7e9459 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -377,6 +377,15 @@ _go-module_src_unpack_gosum() {
die "go-module_set_globals must be called in global scope"
fi
+ local -i a_size="${#A}"
+ # Environment variables must not exceed MAX_ARG_STRLEN (128 KiB) on
+ # Linux, or otherwise execve() may fail. Ensure that A stays below
+ # this value. See also https://bugs.gentoo.org/719202#c16
+ if [[ ${a_size} -gt 114688 ]]; then
+ # A is larger than 112 KiB.
+ die "Size of A variable (${a_size} bytes) is too large. Please
use a dependency tarball instead of EGO_SUM."
+ fi
+
local goproxy_dir="${GOPROXY/file:\/\//}"
mkdir -p "${goproxy_dir}" || die
--
2.35.1
Re: [gentoo-dev] [PATCH] go-module.eclass: ensure that A is less than 112 KiB
On 11/10/2022 17.26, Mike Gilbert wrote: On Tue, Oct 11, 2022 at 6:06 AM Florian Schmaus wrote: Packages with a large number of EGO_SUM entries, i.e., many thousands, cause SRC_URI, and in turn A, to become quite large. Prevent issues that are caused by large environment variables, e.g., execve() errors (see bug #719203), by ensuring that A stays below a reasonable size. This code will never be reached: if the A environment variable is too large, portage will fail to execute /bin/bash, and the phase function will not be executed. I believe the code will never be reached if A is > 128 KiB (aka MAX_ARG_STRLEN). If A is (112, 128] KiB, then the code will be reached and run into the 'die'. If A is <= 112 KiB, then the code will be reached and continue without die'ing. That said, I could also live with your suggestion to un-deprecate EGO_SUM without any size limitation (besides limitations not within Gentoo's direct control, like MAX_ARG_STRLEN). In this case, we should probably, at one point, improve portage's error reporting, so that, for example, execve() fails, portages tries to determine the culprit. For example, portage printing out environment variables that are too large. Which appear to be nice to have irregardless of the current EGO_SUM discussion. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 17/06/2022 18.27, William Hubbs wrote: On Mon, Jun 13, 2022 at 12:26:43PM +0200, Ulrich Mueller wrote: On Mon, 13 Jun 2022, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa Can this be done without requesting changes to package managers? What is 'this' here? Undeprecating EGO_SUM. The patchset does not make changes to any package manager, just the go-module eclass. Note that this is not about finding about an alternative to dependency tarballs. It is just about re-allowing EGO_SUM in addition to dependency tarballs for packaging Go software in Gentoo. Like I said on my earlier reply, there have been packages that break using EGO_SUM. Those packages can't obviously use EGO_SUM, but this should *not* mean that we generally ban EGO_SUM. The most pressing concern about EGO_SUM is that it can make portage crash because of the size of SRC_URI, so it definitely should not be preferred over dependency tarballs. I think an approach like my posted patch, which makes go-modules.eclass invoke 'die' if A exceeds a certain threshold, should make developers in most situations aware that it is time to switch their package to use a dependency tarball instead of EGO_SUM. The remaining situations are the ones where a package initially exceeds the MAX_ARG_STRLEN limit, and where a certain USE-flag combination causes the limit to be exceeded. The former should not be real issue, as such ebuilds should never been committed, as they could never work. The later can be solved by exhaustive testing of all possible USE flag combinations. - Flow
Re: [gentoo-dev] [PATCH] git-r3.eclass: Add checkout dirs as "safe" directories
On 06.11.22 12:03, Michał Górny wrote:
Mark all checkout directories as "safe" to avoid dubious ownership
errors with newer git versions when the checkout directory is accessed
from src_install().
Bug: https://bugs.gentoo.org/879353
Signed-off-by: Michał Górny
---
eclass/git-r3.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 59d4f9a0038f..bdb28565e2f9 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -887,6 +887,11 @@ git-r3_checkout() {
cp "${orig_repo}"/packed-refs "${GIT_DIR}"/packed-refs
|| die
fi
+ # mark this directory as "safe" so that src_install() can access it
+ # https://bugs.gentoo.org/879353
+ git config --global --add safe.directory \
+ "$(cd "${out_dir}" && echo "${PWD}")" || die
I guess there is no way we can avoid the --global and use --local instead?
- Flow
Re: [gentoo-dev] [PATCH] git-r3.eclass: Add checkout dirs as "safe" directories
On 06.11.22 12:38, Michał Górny wrote:
On Sun, 2022-11-06 at 12:19 +0100, Florian Schmaus wrote:
On 06.11.22 12:03, Michał Górny wrote:
Mark all checkout directories as "safe" to avoid dubious ownership
errors with newer git versions when the checkout directory is accessed
from src_install().
Bug: https://bugs.gentoo.org/879353
Signed-off-by: Michał Górny
---
eclass/git-r3.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 59d4f9a0038f..bdb28565e2f9 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -887,6 +887,11 @@ git-r3_checkout() {
cp "${orig_repo}"/packed-refs "${GIT_DIR}"/packed-refs
|| die
fi
+ # mark this directory as "safe" so that src_install() can access it
+ # https://bugs.gentoo.org/879353
+ git config --global --add safe.directory \
+ "$(cd "${out_dir}" && echo "${PWD}")" || die
I guess there is no way we can avoid the --global and use --local instead?
safe.directory works only in protected scoeps, i.e. system, global and
command. See git-config(1).
That said, the check wouldn't really make sense if the repository were
able to declare itself safe.
Fair point, and I suspected as much.
Am I right that this does modify ~portage/.gitconfig (so usually
/var/lib/portage/home/.gitconfig)? If so, I wonder if this could be
avoided, e.g., by setting XDG_CONFIG_HOME to $T/.config. But I guess
that has the potential to break other things. And having some eclass
modifying the home directory of the portage user is not probably
something we could live with. It would just we be nice if the
save.directory setting would be just temporary during the emerge, e.g.,
set somewhere under T.
- Flow
Re: [gentoo-dev] [PATCH] git-r3.eclass: Add checkout dirs as "safe" directories
On 06.11.22 16:52, Michał Górny wrote: On Sun, 2022-11-06 at 16:08 +0100, Florian Schmaus wrote: Fair point, and I suspected as much. Am I right that this does modify ~portage/.gitconfig (so usually /var/lib/portage/home/.gitconfig)? If so, I wonder if this could be avoided, e.g., by setting XDG_CONFIG_HOME to $T/.config. But I guess that has the potential to break other things. And having some eclass modifying the home directory of the portage user is not probably something we could live with. It would just we be nice if the save.directory setting would be just temporary during the emerge, e.g., set somewhere under T. HOME All Ditto The full path to an appropriate temporary directory for use by any programs invoked by the ebuild that may read or modify the home directory. [1] Nice, I wasn't aware that PMS mandates HOME being set. - Flow
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 08.09, Michał Górny wrote: Hi, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. While I do not strictly oppose that change, I like the UNCONFIRMED / CONFIRMED states. I don't know how 1. is an argument for removing it. Quite the contrary, the statement itself says that the feature is used. Furthermore, it is not my observation that only a handful of developers use it. Most open bugs are in the CONF state [1], so I would conclude that most use the feature. Of course, that depends on your definition of "used in a meaningful way". For me, CONFIRMED was always about someone, usually a -dev, acknowledging that the bug reports a valid issue that needs to be addressed (either by Gentoo or upstream). Is that using it in a meaningful way? And 2. doesn't appear to be a solution but helps disguise the underlying issue. We should instead educate users that Gentoo, like most volunteer-driven FOSS projects, is short on the workforce. Therefore users can only expect that some bugs will be handled immediately, while others may lay dormant for an extended period (for different reasons). Ultimately, the central angle to tackle this issue is e to empower users to fix the problems themselves or at least provide minimal reproducers and debugging information. We already put in much effort (and we are IMHO quite good at it already), but it requires continuous effort… - Flow 1: https://bugs.gentoo.org/buglist.cgi?component=Current%20packages&list_id=6623145&product=Gentoo%20Linux&resolution=--- OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 12.34, Michał Górny wrote: On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote: On 03/12/2022 08.09, Michał Górny wrote: Hi, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. While I do not strictly oppose that change, I like the UNCONFIRMED / CONFIRMED states. I don't know how 1. is an argument for removing it. Quite the contrary, the statement itself says that the feature is used. Furthermore, it is not my observation that only a handful of developers use it. Most open bugs are in the CONF state [1], so I would conclude that most use the feature. Of course, that depends on your definition of "used in a meaningful way". For me, CONFIRMED was always about someone, usually a -dev, acknowledging that the bug reports a valid issue that needs to be addressed (either by Gentoo or upstream). Is that using it in a meaningful way? Does that imply that bugs that are UNCONFIRMED are not worth our effort? No, not all. Could you elaborate how you derive this implication? I had always assumed that UNCONFIRMED means that nobody (as in, no dev) looked at the issue report and vetted its validity. Nothing more, nothing less. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 13.20, Michał Górny wrote: On Sat, 2022-12-03 at 13:10 +0100, Florian Schmaus wrote: On 03/12/2022 12.34, Michał Górny wrote: On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote: On 03/12/2022 08.09, Michał Górny wrote: Hi, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. While I do not strictly oppose that change, I like the UNCONFIRMED / CONFIRMED states. I don't know how 1. is an argument for removing it. Quite the contrary, the statement itself says that the feature is used. Furthermore, it is not my observation that only a handful of developers use it. Most open bugs are in the CONF state [1], so I would conclude that most use the feature. Of course, that depends on your definition of "used in a meaningful way". For me, CONFIRMED was always about someone, usually a -dev, acknowledging that the bug reports a valid issue that needs to be addressed (either by Gentoo or upstream). Is that using it in a meaningful way? Does that imply that bugs that are UNCONFIRMED are not worth our effort? No, not all. Could you elaborate how you derive this implication? I had always assumed that UNCONFIRMED means that nobody (as in, no dev) looked at the issue report and vetted its validity. Nothing more, nothing less. I'm trying to understand what actual value this has. Unless it's data for the sake of having data. That is a valid concern. I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and other (affected) persons, to decide if they need to "chase" the issue's assigned entity. Assume looking at the open bugs list of a developer. If the developer has old bugs in UNCONFIRMED state, you may want to issue a friendly ping. Sure, strictly speaking, this would require all bugs to drop back to UNCONFIMRED when the bug assignee changes. But even without such an implicit mechanism, those two states provide some value. A similar case can be made for IN_PROGRESS. However, I see how one could argue that IN_PROGRESS provides more value than UNCONFIRMED / CONFIRMED. As I said, I do not strictly oppose this change. But since this is a RFC, I commented. :) Maybe it is just me being used to bug transition states being NEW / UNCONFIRMED → CONFIRMED → IN_PROGRESS → CLOSED (with intermediate states being optional) - Flow
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 03/12/2022 14.50, Michał Górny wrote: On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote: I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and other (affected) persons, to decide if they need to "chase" the issue's assigned entity. Assume looking at the open bugs list of a developer. If the developer has old bugs in UNCONFIRMED state, you may want to issue a friendly ping. Sure, strictly speaking, this would require all bugs to drop back to UNCONFIMRED when the bug assignee changes. But even without such an implicit mechanism, those two states provide some value. I don't understand how UNCONFIRMED/CONFIRMED makes any difference here. If I file a bug against some package, it is CONFIRMED by default. If an unprivileged user files it, it's UNCONFIRMED. In both cases the assignee didn't do anything. The assignee not doing anything keeps the bug UNCONFIRMED if it is filled by an unprivileged user. That makes the bug distinguishable from a bug that got "verified" by the assignee. Yes, if *you* (as dev) fill a bug, then it is implicitly CONFIRMED (whether or not that is sensible is a different discussion). I do not see how this would invalidate my case, though. - Flow
[gentoo-dev] Current portage will now truncate your repo's git history to 1
This is a public service announcement that the recently stabilized portage version will truncate you repo's git history to 1. While this is a good thing for the majority of Gentoo users, it affects developers that develop in a git known to portage (like me). If I understand the portage maintainers vision correctly, then future portage will assume full control over its configured repositories and potentially perform destructive operations on them, for example "git clean" [1]. I personally would prefer portage simply adjusting its behavior based on the owner of the repository. That is, if it's the 'portage' user then assume full control, and if it is a different user, then fall back to a preserving, conservative mode of operation. Unfortunately, for me, this idea was received skeptically at best in a recent discussion in #gentoo-portage. So this is a heads up for fellow developers using a similar workflow like me, that they are probably required to change their workflow to use PORTDIR_OVERLAY and multiple repositories on their system: a system-wide, managed by portage, and a dev repository (in your HOME), scoped in via PORTDIR_OVERLAY. As everyone knows, there is nothing better than to change the workflow that has served you well over multiple years. But apparently the PORTDIR_OVERLAY approach works well for others, so I am confident that I (and others) will be able to make the transition with a minimal amount of ranting. ;) - Flow 1: https://github.com/gentoo/portage/pull/939
[gentoo-dev] Re: Current portage will now truncate your repo's git history to 1
On 15/12/2022 20.22, Florian Schmaus wrote: As everyone knows, there is nothing better than to change the workflow that has served you well over multiple years. But apparently the PORTDIR_OVERLAY approach works well for others, so I am confident that I (and others) will be able to make the transition with a minimal amount of ranting. ;) As it was pointed out that some consider my wording here inappropriate and/or rude, I want to apologize to everyone who was offended by the prior paragraph. I had https://xkcd.com/1172/ in mind when writing it. I was also criticized for not providing a rationale for the behavior change in portage. The motivation is driven by the noble goal to make portage more user friendly and robust. Which I fully support. Just like I support shallow clones per default. I just believe portage should do a better job figuring out if it potentially messes with a "user-owned" repository and adjust its behavior accordingly. In a similar spirit I submitted https://github.com/gentoo/portage/pull/960 - Flow
Re: [gentoo-dev] Current portage will now truncate your repo's git history to 1
On 15/12/2022 21.10, Toralf Förster wrote: On 12/15/22 20:22, Florian Schmaus wrote: o use PORTDIR_OVERLAY and multiple repositories on their system: a system-wide, managed by portage, and a dev repository (in your HOME), scoped in via PORTDIR_OVERLAY. Isn't this covered by /etc/portage/repos.conf/* Absolutely, but this requires a manual intervention from the user. And, of course, you can totally opt-out from portage managing (syncing) the repository, but then you have to take care of syncing yourself. The point is that with the new portage release, portage's behavior changes. And I would argue that portage should not, in its effort to become more user friendly, disregard ebuild-developer friendliness. Assuming it is achievable with a reasonable amount of additional code complexity. - Flow
Re: [gentoo-dev] Current portage will now truncate your repo's git history to 1
On 17.12.22 06:42, Sam James wrote: On 15 Dec 2022, at 19:22, Florian Schmaus wrote: I personally would prefer portage simply adjusting its behavior based on the owner of the repository. That is, if it's the 'portage' user then assume full control, and if it is a different user, then fall back to a preserving, conservative mode of operation. Unfortunately, for me, this idea was received skeptically at best in a recent discussion in #gentoo-portage. This wouldn't work for Prefix and also FEATURES="-usersync". Simply do not apply the approach on Prefix. That should be fine. I am not sure how usersync being disabled (or enabled) plays a role here, though. I believe something like this would make everyone happy: if volatile_explicitly_configured: volatile = explicitly_configured_volatile_value else if prefix volatile = false else if Path(repo_dir).user != (root|portage) # Or, if uid >= 1000 volatile = true else volatile = false Assuming that the "if target repo is not shallow, then no shallow clone (unless explicitly requested)" check is only applied if volatile=true, then you even have the desired effect that users get their repo automatically converted to shallow ones. Which makes you happy. And the above logic would make me happy, since the "if Path(repo_dir).uid >= 1000" branch would be taken for me. That sounds like a win/win to me. - Flow
[gentoo-dev] Last rites: net-p2p/vuze
# Volkmar W. Pogatzki (2022-12-29) # Upstream is dead, last activity in Nov 2017. Does not # work with newer log4j, bug #857663. Use net-p2p/biglybt # instead. Removal on 2023-02-29. net-p2p/vuze net-p2p/vuze-coreplugins - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] eclass/dune.eclass: introduce edune and dune-compile (v2)
On 03/01/2023 00.19, Maciej Barć wrote:
edune is a thin wrapper for dune, which will help to run special,
uncommon dune commands;
dune-compile is a function to selectively pick which packages will be
compiled "for-release" (as dune call it);
dune-compile without any arguments replaces the current dune_src_compile
Signed-off-by: Maciej Barć
---
eclass/dune.eclass | 49 +-
1 file changed, 44 insertions(+), 5 deletions(-)
diff --git a/eclass/dune.eclass b/eclass/dune.eclass
index 4bc73eda8..384908a40 100644
--- a/eclass/dune.eclass
+++ b/eclass/dune.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: dune.eclass
@@ -29,7 +29,7 @@ _DUNE_ECLASS=1
# Set before inheriting the eclass.
: ${DUNE_PKG_NAME:=${PN}}
-inherit multiprocessing
+inherit edo multiprocessing
# Do not complain about CFLAGS etc since ml projects do not use them.
QA_FLAGS_IGNORED='.*'
@@ -44,15 +44,54 @@ BDEPEND="
dev-ml/dune
"
+# @FUNCTION: edune
+# @USAGE: ...
+# @DESCRIPTION:
+# A thin wrapper for the `dune` command.
+# Runs `dune` with given arguments and dies on failure.
+#
+# Example use:
+# @CODE
+# edune clean
+# @CODE
+edune() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ edo dune "${@}"
+}
+
+# @FUNCTION: dune-compile
+# @USAGE: [package] ...
+# @DESCRIPTION:
+# Compiles either all of packages sources in current directory or selected
+# packages. In case of all packages the package detection is done via dune
+# itself.
+#
+# Example use:
+# @CODE
+# dune-compile menhir menhirLib menhirSdk
+# @CODE
+dune-compile() {
+ local -a myduneopts=(
+ -j $(makeopts_jobs)
+ --profile release
+ )
+ if [[ -n "${1}" ]] ; then
+ myduneopts+=( --for-release-of-packages="$(IFS="," ; echo
"${*}")" )
+ fi
+
+ edune build @install "${myduneopts[@]}"
+}
+
dune_src_compile() {
ebegin "Building"
- dune build @install -j $(makeopts_jobs) --profile release
+ dune-compile
eend $? || die
}
dune_src_test() {
ebegin "Testing"
- dune runtest -j $(makeopts_jobs) --profile release
+ edune runtest -j $(makeopts_jobs) --profile release
eend $? || die
}
@@ -80,7 +119,7 @@ dune-install() {
local pkg
for pkg in "${pkgs[@]}" ; do
ebegin "Installing ${pkg}"
- dune install ${myduneopts[@]} ${pkg}
+ edune install ${myduneopts[@]} ${pkg}
eend $? || die
# Move docs to the appropriate place.
It appears there is additional output between the ebegin / eend. You may
want to consider dropping ebegin and eend. In general, the pattern
ebegin, edo, eend should probably be avoided.
- Flow
Re: [gentoo-dev] [PATCH] eclass/dune.eclass: introduce edune and dune-compile (v2)
On 03/01/2023 15.51, Maciej Barć wrote: It appears there is additional output between the ebegin / eend. You may want to consider dropping ebegin and eend. In general, the pattern ebegin, edo, eend should probably be avoided. I would like to keep the "Building ... [ OK ]" (made by ebegin) output as it was before the change. The reason the ebegin/edo/eend pattern should be avoided is that the output will not be Building ... [ OK ] instead it will be Building ... dune foo bar [ OK ] so the expectation that [ OK ] is on the right hand side is not fulfilled. Note that edo.eclass also provides edob(), which can be used if it is known that the command does not produce output. For example edob dune foo bar should result in Running dune foo bar [ OK ] - Flow
[gentoo-dev] RFC: new gradle.eclass
Happy new year everyone! I'd like to as for a review of an initial eclass for gradle. This is my first eclass, so I am sure there is plenty to find. ;) The related github PR is https://github.com/gentoo/gentoo/pull/28986 - Flow
[gentoo-dev] [PATCH] gradle.eclass: add new eclass
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
new file mode 100644
index ..a321262612d0
--- /dev/null
+++ b/eclass/gradle.eclass
@@ -0,0 +1,149 @@
+# Copyright 2021-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: gradle.eclass
+# @MAINTAINER:
+# Gentoo Java Project
+# @AUTHOR:
+# Florian Schmaus
+# @BLURB: Utility functions for the gradle build system.
+# @DESCRIPTION:
+# Utility functions for the gradle build system.
+
+case ${EAPI} in
+ 7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_GRADLE_ECLASS} ]] ; then
+_GRADLE_ECLASS=1
+
+inherit edo
+
+# @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.
+
+# @ECLASS_VARIABLE: EGRADLE_PARALLEL
+# @DESCRIPTION:
+# Set to the 'true', the default, to invoke gradle with --parallel. Set
+# to 'false' to disable parallel gradle builds.
+: "${EGRADLE_PARALLEL=true}"
+
+# @ECLASS_VARIABLE: EGRADLE_USER_HOME
+# @DESCRIPTION:
+# Directroy used as the user's home directory by gradle. Defaults to
+# ${T}/gradle_user_home
+: "${EGRADLE_USER_HOME="${T}/gradle_user_home"}"
+
+# @ECLASS_VARIABLE: EGRADLE_OVERWRITE
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# User-specified overwrite of the used gradle binary.
+
+# @FUNCTION: gradle-set_EGRADLE
+# @DESCRIPTION:
+# Set the EGRADLE environment variable.
+gradle-set_EGRADLE() {
+ [[ -n ${EGRADLE} ]] && return
+
+ if [[ -n ${EGRADLE_OVERWRITE} ]]; then
+ export EGRADLE="${EGRADLE_OVERWRITE}"
+ return
+ fi
+
+ local candidates candidate selected selected_ver
+
+ candidates=$(compgen -c gradle-)
+ for candidate in ${candidates}; do
+ if [[ ! ${candidate} =~ gradle(-bin)?-([.0-9]+) ]]; then
+ continue
+ fi
+
+ local ver
+ if (( ${#BASH_REMATCH[@]} == 3 )); then
+ ver="${BASH_REMATCH[2]}"
+ else
+ ver="${BASH_REMATCH[1]}"
+ fi
+
+ if [[ -n ${EGRADLE_EXACT_VER} ]]; then
+ ver_test "${ver}" -ne "${EGRADLE_EXACT_VER}" && continue
+
+ selected="${candidate}"
+ selected_ver="${ver}"
+ break
+ fi
+
+ if [[ -n ${EGRADLE_MIN} ]] \
+ && ver_test "${ver}" -lt "${EGRADLE_MIN}"; then
+ # Candidate does not satisfy EGRADLE_MIN condition.
+ continue
+ fi
+
+ if [[ -n ${EGRADLE_MAX_EXCLUSIVE} ]] \
+ && ver_test "${ver}" -ge "${EGRADLE_MAX_EXCLUSIVE}";
then
+ # Candidate does not satisfy EGRADLE_MAX_EXCLUSIVE
condition.
+ continue
+ fi
+
+ if [[ -n ${selected_ver} ]] \
+ && ver_test "${selected_ver}" -gt "${ver}"; then
+ # Candidate is older than the currently selected
candidate.
+ continue
+ fi
+
+ selected="${candidate}"
+ selected_ver="${ver}"
+ done
+
+ if [[ -z ${selected} ]]; then
+ die "Could not find (suitable) gradle installation in PATH"
+ fi
+
+ export EGRADLE="${selected}"
+ export EGRADLE_VER="${ver}"
+}
+
+# @FUNCTION: egradle
+# @USAGE: [gradle-args]
+# @DESCRIPTION:
+# Invoke gradle with the optionally provided arguments.
+egradle() {
+ gradle-set_EGRADLE
+
+ local gradle_args=(
+ --console=plain
+ --info
+ --stacktrace
+ --no-daemon
+ --offline
+ --no-build-cache
+ --gradle-user-home "${EGRADLE_USER_HOME}"
+ --project-cache-dir "${T}/gradle_project_cache"
+ )
+
+ if $EGRADLE_PARALLEL; then
+ gradle_args+=( --parallel )
+ fi
+
+ local -x JAVA_TOOL_OPTIONS="-Duser.home=\"$T\""
+
Re: [gentoo-dev] RFC: new gradle.eclass
On 06/01/2023 19.52, Yuan Liao (Leo) wrote:
While I warmly appreciate and welcome any effort to improve support
for Java build systems on Gentoo, I also wonder what functionality
ebuild authors who are creating a Java package might expect from an
eclass called "gradle.eclass".
It is not strictly forbidden for an eclass to serve multiple use cases.
However, there is an argument to separate the concerns into different
eclasses (as we do already with other ecosystems). But we don't have
those different concerns implemented right now. And there is IMHO a good
reason this eclass should be called gradle.eclass: it provides basic
functionality to discover a suitable gradle version and invoke gradle
with sane defaults and in the idiomatic Gentoo way ("egradle ").
I'm not doubting this eclass's usefulness -- to me, it looks like a
convenient eclass when a Gradle project's dependencies are vendored
and included in SRC_URI.
The PR I mentioned migrates an openjfx ebuild from using its own gradle
installation to the eclass [1]. And ::java has a ghidra ebuild [2] that
uses gradle.eclass. Which was based on ::pentoo's ghidra ebuild with
minor modifications to use the eclass. I recommend to look at the diff
between the ::java version and ::pentoo version of the ghidra ebuild too.
And the eclass, as is, is currently not only used for sideloaded
dependencies. If you look at the openjfx ebuild then you will find that
it consumes java libraries that are installed as Gentoo package
(stringtemplate and hamcrest-core) and injects it into the Gradle build.
Specialized eclasses are totally fine as
we've already got plenty of them in the tree. But I think what an
average Java ebuild author often wants is an eclass with which they
can just declare all dependencies of the Gradle project in *DEPEND
variables, and rely on the default pkg_* and src_* functions from the
eclass to do the rest, with no or only minimal overrides necessary.
They might trust the eclass to introduce any Java dependencies
installed by Portage to Gradle, invoke the build system, and finally
install the JARs built.
Yeah, that is what I also would prefer. And, in fact, this is done for
many existing Java ebuilds. However, reality is that it is often not
feasible to do so with modern Java build systems, as they switch from
consuming Jar files to consuming Maven artifacts with POMs. I'd love to
see an effort to remedy the situation and I actually believe the
gradle.eclass provides basic functionality towards this, but the cruel
reality is that we are far away from that (as far as I can tell) and
currently do not have the manpower to make it happen. I would be happy
to be proven wrong, though.
Furthermore, the approach that the openjfx ebuild uses to inject
libraries in the Gradle build is not generally applicable. IMHO the
perfect solution would consists of a system-wide Maven repository, where
Java ebuilds install their Jar files. And a robust way to tell Gradle
(and Maven, …) to consume artifacts from such a system-wide Maven
repository and a way to tell the build system to not perform any network
activity.
I think thin would be beneficial not only to Gentoo, but to other
distributions too. But, again, it is a long way to get there.
Maybe we will be lucky enough to have such an eclass in the future.
But should we add a remark to the eclass's description to warn that
this might not be the generalized "gradle.eclass" suitable for
packaging most Gradle-based projects, if that is what people would
believe a "gradle.eclass" would do for them?
I am not sure what such a warning is going to acomplish. But certainly,
if "better" approaches are implemented, then our documentation should
point them out.
- Flow
1:
https://github.com/gentoo/gentoo/pull/28986/commits/808197948074c1582d3e3c7877d68cb9a6fa2f72
2:
https://github.com/gentoo/java-overlay/blob/master/dev-util/ghidra/ghidra-10.2.2-r2.ebuild
Re: [gentoo-dev] [PATCH] gradle.eclass: add new eclass
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
[gentoo-dev] Last rites: net-dns/dnswalk, dev-games/cardpics, dev-games/mercator, dev-games/wfmath
# Michael Mair-Keimberger (2023-01-08) # Broken since many years, no reverse dependencies, last release from # 2000. Bug #678518. Removal on 2023-02-08. net-dns/dnswalk # Michael Mair-Keimberger (2023-01-08) # EAPI=6, Installs only card pictures and has no reverse dependencies. # Bug #805278. Removal on 2023-02-08. dev-games/cardpics # Michael Mair-Keimberger (2023-01-08) # Dependencies of games-server/cyphesis, which got removed ~4 years ago, # no other reverse dependencies. Bug #728230 # Removal on 2023-02-08. dev-games/mercator dev-games/wfmath - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-java/core-specs-alpha dev-java/spec-alpha
# Florian Schmaus (2013-01-27) # Previous dependencies of dev-lang/clojure, now part of the clojure # ebuild and no longer needed. # Removal on 2023-02-27. dev-java/core-specs-alpha dev-java/spec-alpha - Flow
Re: [gentoo-dev] dev-python/ package naming policy?
On 28/01/2023 17.38, Michał Górny wrote: To improve consistency and make packages easier to find, I'd like to propose going forward that when packages are published on PyPI, we use their official PyPI names. This also means preserving the case for the few packages that use CamelCase names and similar. Consistency is generally a good thing. So +1 FTR, I think this should probably be applied in general in such situations, and not just for the Python ecosystem. - Flow
[gentoo-dev] Last rites: acct-(user|group)/jabber
# Florian Schmaus (2023-02-09) # Leftovers from net-im/jabber-base. Unused and obsolete. # Removal on 2023-03-09. acct-user/jabber acct-group/jabber - Flow
[gentoo-dev] Last rites: dev-erlang/(iconv|p1_xmlrpc|riak_pb)
# Florian Schmaus (2023-02-10) # Previous dependencies of ejabberd, now no longer needed. # Removal on 2023-03-10. dev-erlang/iconv dev-erlang/p1_xmlrpc dev-erlang/riak_pb - Flow
Re: [gentoo-dev] [PATCH] New pre-GLEP: TEST_SUITE_PRESENT variable
On 19/02/2023 18.32, Michał Górny wrote: +Abstract + + +A new ``TEST_SUITE_PRESENT`` variable is introduced to indicate whether +the package features a test suite. I wonder if we could not simply use IUSE="test" for this purpose? That is, allow declaring the 'test' use flag, even though it is not used in a USE conditional, to indicate that the package has a test suite. With that said, I don't have any strong objections against this proposal. But I'd like to mention that with RESTRICT="test", IUSE="test" and then TEST_SUITE_PRESENT="true", we end up with an awful lot of test related metadata and complexity, which potentially contributes to confusion. - Flow
[gentoo-dev] Packages up for grabs: sys-firmware/broadcom-bt-firmware
I've dropped sys-firmware/broadcom-bt-firmware to maintainer needed, as I do not longer have compatible hardware. From a security perspective, the firmware in this package could be considered dubious. Personally, I would recommend users to by newer bluetooth hardware [1]. The package has one open bug, requesting USE=savedconfig support: https://bugs.gentoo.org/buglist.cgi?quicksearch=broadcom-bt-firmware - Flow 1: I now have a TP-Link UB500, and I am quite happy with it. OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] .editorconfig: add
On 24/03/2023 05.46, Ulrich Mueller wrote: On Fri, 24 Mar 2023, Sam James wrote: I'm slightly confused. What repository is this intended for? gentoo.git. Then it looks wrong, conceptually. Or would it be o.k. if I committed ebuild-mode.el to the top-level directory of the Gentoo repository? I do not think the comparison with ebuild-mode.el is sound: ebuild-mode.el appears imperative, while .editorconfig is declarative. Furthermore, and more importantly, ebulid-mode.el is (more or less) editor-specific, while .editorconfig is editor agnostic. That said, given how coupled ebuild-mode is with gentoo.git, I personally would not mind if it where managed in the same repository. (with ebuild-mode not being shipped to the users as part of "emerge --sync"). One could imagine that if a major ebuild style change is rolled out, it is done in a single commit that affects all ebuilds and ebuild-mode. In any case, I am a fan of .editorconfig. Hence +1 from me for adding it to gentoo.git. - Flow
Re: [gentoo-dev] [PATCH 1/4] toolchain-autoconf.eclass: Add option to disable Info slotting
On 26/03/2023 22.30, Arsen Arsenović wrote:
Closes: https://bugs.gentoo.org/902461
Signed-off-by: Arsen Arsenović
---
eclass/toolchain-autoconf.eclass | 46 +---
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/eclass/toolchain-autoconf.eclass b/eclass/toolchain-autoconf.eclass
index 2ba27638468e..140ee4c9b5eb 100644
--- a/eclass/toolchain-autoconf.eclass
+++ b/eclass/toolchain-autoconf.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: toolchain-autoconf.eclass
@@ -18,6 +18,20 @@ esac
if [[ -z ${_TOOLCHAIN_AUTOCONF_ECLASS} ]]; then
_TOOLCHAIN_AUTOCONF_ECLASS=1
+# @ECLASS_VARIABLE: TC_AUTOCONF_BREAK_INFOS
+# @DESCRIPTION:
+# Enables slotting logic on the installed info pages. This includes
+# mangling the pages in order to include a version number. Empty by
+# default, and only exists for existing ebuild revisions to use. Set
Referring to "existing ebuild revisions" becomes confusing in the
future, when there are existing ebuilds that do not use this variable.
Maybe "and only set by legacy ebuilds to phase out the broken slotting
logic. New ebuilds should not set this variable."
- Flow
Re: [gentoo-dev] [PATCH 4/4] sys-devel/automake: Fix installing broken Info pages
On 26/03/2023 22.30, Arsen Arsenović wrote:
This commit replaces the Info page slotting mechanism with simple
INFOPATH setting.
Closes: https://bugs.gentoo.org/902461
Signed-off-by: Arsen Arsenović
---
sys-devel/automake/automake-1.11.6-r4.ebuild | 84 +
sys-devel/automake/automake-1.16.5-r1.ebuild | 119 +++
sys-devel/automake/automake-.ebuild | 48 +++-
3 files changed, 220 insertions(+), 31 deletions(-)
create mode 100644 sys-devel/automake/automake-1.11.6-r4.ebuild
create mode 100644 sys-devel/automake/automake-1.16.5-r1.ebuild
diff --git a/sys-devel/automake/automake-1.11.6-r4.ebuild
b/sys-devel/automake/automake-1.11.6-r4.ebuild
new file mode 100644
index ..4e0857012d71
--- /dev/null
+++ b/sys-devel/automake/automake-1.11.6-r4.ebuild
@@ -0,0 +1,84 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+DESCRIPTION="Used to generate Makefile.in from Makefile.am"
+HOMEPAGE="https://www.gnu.org/software/automake/";
+SRC_URI="mirror://gnu/${PN}/${P}.tar.xz"
+
+LICENSE="GPL-2"
+# Use Gentoo versioning for slotting.
+SLOT="${PV:0:4}"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv
~s390 ~sparc ~x86"
+IUSE=""
+RESTRICT="test"
+
+RDEPEND=">=dev-lang/perl-5.6
+ >=sys-devel/automake-wrapper-10
+ >=sys-devel/autoconf-2.69:*
+ sys-devel/gnuconfig"
+DEPEND="${RDEPEND}
+ sys-apps/help2man"
+BDEPEND="app-arch/gzip"
+
+PATCHES=(
+ "${FILESDIR}"/${PN}-1.10-perl-5.16.patch #424453
+ "${FILESDIR}"/${PN}-1.11-install-sh-avoid-low-risk-race-in-tmp.patch
+ "${FILESDIR}"/${PN}-1.13-perl-escape-curly-bracket-r1.patch
+)
+
+src_prepare() {
+ default
+ export WANT_AUTOCONF=2.5
+ export HELP2MAN=true
+ sed -i -e "/APIVERSION=/s:=.*:=${SLOT}:" configure || die
+ export TZ="UTC" #589138
+}
+
+src_compile() {
+ # Also used in install.
+ infopath="${EPREFIX}/usr/share/automake-${PV}/info"
Not sure if we have a style policy on this, but I read lowercase
variables as local-function variables. However, 'infopath', as is, is
used in a subsequent ebuild phase function. So maybe
s/infopath/INFOPATH/ or maybe even MY_INFOPATH or AUTOMAKE_INFOPATH?
- Flow
[gentoo-dev] Last rites: acct-{user,grou}/abrt sec-policy/selinux-abrt
# Florian Schmaus (2023-04-05)
# Packages that became orphaned leaf packages with the removal of
# app-admin/abrt. See
# - eea6958136ef ("profiles: Mask abrt software for removal")
# - 8aedf444c3a5 ("app-admin/abrt: treeclean")
# Removal on 2023-04-20
acct-user/abrt
acct-group/abrt
sec-policy/selinux-abrt
[gentoo-dev] EGO_SUM
I want to continue the discussion to re-instate EGO_SUM, potentially leading to a democratic vote on whether EGO_SUM should be re-instated or deprecated. For the past months, I tried to find *technical reasons*, e.g., reasons that affect end-users, that justify the deprecation of EGO_SUM. However, I was unable to find any. The closest thing I could find was portage being unable to process an ebuild due to its large environment (bug 830187). However, as this happens while developing an ebuild, it should never affect users. Obviously this is a situation where EGO_SUM can not be used. Fortunately, it does not affect most Go packages, as seen in my previous analysis of Go packages in ::gentoo and their EGO_SUM size. Furthermore, newer portage versions, with USE=gentoo-dev, will proactively warn you if the environment caused by the ebuild becomes large. All further arguments for the deprecation of EGO_SUM where of cosmetic nature. However, the deprecation of EGO_SUM is harmful to Gentoo and its users. To briefly re-iterate the reasons: The EGO_SUM alternatives - do not have the same level of trust and therefore have a negative impact on security (a dubious tarball someone put somewhere, especially when proxy-maint) - are not easily verifiable - require additional effort when developing ebuilds - hinder the packaging and Gentoo's adoption of Go-based projects, which is worrisome as Go is very popular - prevent Go modules from being shared as DISTFILES on the mirrors across various packages Last but not least, we have the same situation in the Rust ecosystem, but we allow the EGO_SUM "equivalent" there. So with portage checking the environment of ebuilds and warning if it becomes too large, and with the arguments above, I do not see any reason we should outlaw EGO_SUM. - Flow Previous discussions: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa https://archives.gentoo.org/gentoo-dev/message/d78af7f168cef24bfa302f7f75c3ef11 OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Add Makefile to run eclass tests
The eclass tests, found under eclass/tests, are currently not run automatically. This yields the danger that the tests rot and decay over time. In fact, I believe this already started to happen. Ideally the eclass tests are automatically run with the normal QA checks for ::gentoo. A single entry point to run the eclass testsuite is a prerequisite for this. This patch adds, in form of a Makefile, such an entry point. Driving the tests via Make allows us to exploit Make's built-in features, like potentially running the tests in parallel.
[gentoo-dev] [PATCH] eclass/tests: add Makefile to run eclass tests
Signed-off-by: Florian Schmaus --- eclass/tests/.gitignore | 2 ++ eclass/tests/Makefile | 27 +++ 2 files changed, 29 insertions(+) create mode 100644 eclass/tests/.gitignore create mode 100644 eclass/tests/Makefile diff --git a/eclass/tests/.gitignore b/eclass/tests/.gitignore new file mode 100644 index ..4df21cab8f5f --- /dev/null +++ b/eclass/tests/.gitignore @@ -0,0 +1,2 @@ +/*.sh.ok +/.eclasssum diff --git a/eclass/tests/Makefile b/eclass/tests/Makefile new file mode 100644 index ..f53f74cfc1af --- /dev/null +++ b/eclass/tests/Makefile @@ -0,0 +1,27 @@ +SH_FILES := $(wildcard *.sh) +TEST_FILES := $(filter-out tests-common.sh, $(SH_FILES)) +TEST_OK_FILES := $(patsubst %.sh, .%.sh.ok,$ $(TEST_FILES)) + +# We cache a successful test result if the testfile itself did not +# change (%.sh) and the contents of the eclass/ directory did not +# change (.eclasssum). +.%.sh.ok: %.sh .eclasssum + ./$< + touch $@ + +.PHONY: test +test: $(TEST_OK_FILES) + +.PHONY: force +.ONESHELL: +.eclasssum: SHELL = /bin/bash +.eclasssum: force + set -euo pipefail + find .. -maxdepth 1 -type f -name "*.eclass" |\ + xargs stat --format="%n %y" |\ + sort |\ + xxhsum - > $@.cur + trap "rm -f $@.cur" EXIT + if ! cmp --silent $@.cur $@; then + mv $@.cur $@ + fi -- 2.39.2
[gentoo-dev] Last rites: acct-group/resin
# Volkmar W. Pogatzki (2023-04-22) # Unused acct-group. Removal on 2023-05-22 # The server was removed on 2021-08-24 with commit # 7a1e8a90fa8a09a84741dc8ef5f774d92ae8433c acct-group/resin
[gentoo-dev] Re: EGO_SUM
I like to ask the Gentoo council to vote on whether EGO_SUM should be
reinstated ("un-deprecated") or not.
EGO_SUM is a project-comprehensive matter, as it affects not only
Go-lang packaging but also the proxy-maint and GURU projects.
Furthermore, as I have mentioned in my previous emails, the deprecation
of EGO_SUM has a significant negative impact on our users and is,
therefore, a global Gentoo issue.
Asking for council involvement should be a last resort and only be done
in essential conflicts. But, unfortunately, I was unable to convince the
relevant maintainer with arguments that the deprecation of EGO_SUM is
harmful. And this matter is significant enough to proceed with this.
Most voices on the related mailing-list threads expressed support for
reinstating EGO_SUM. At least, that is my impression. While the
arguments used to deprecate EGO_SUM were mostly of esthetic nature.
I want to state what should be common sense. Namely, asking for a
democratic vote is not a personal attack against any involved person. I
contacted the council because of a design dispute about what is best for
Gentoo and its users. Furthermore, I tried to create the best
preconditions to reinstate EGO_SUM by working on portage. For example,
making portage emit a warning if an ebuild process environment grows
unreasonably large. And after advocating for reinstating EGO_SUM for a
long time, I seek closure with that request to the council.
- Flow
On 17/04/2023 09.37, Florian Schmaus wrote:
I want to continue the discussion to re-instate EGO_SUM, potentially
leading to a democratic vote on whether EGO_SUM should be re-instated or
deprecated.
For the past months, I tried to find *technical reasons*, e.g., reasons
that affect end-users, that justify the deprecation of EGO_SUM. However,
I was unable to find any. The closest thing I could find was portage
being unable to process an ebuild due to its large environment (bug
830187). However, as this happens while developing an ebuild, it should
never affect users. Obviously this is a situation where EGO_SUM can not
be used. Fortunately, it does not affect most Go packages, as seen in my
previous analysis of Go packages in ::gentoo and their EGO_SUM size.
Furthermore, newer portage versions, with USE=gentoo-dev, will
proactively warn you if the environment caused by the ebuild becomes large.
All further arguments for the deprecation of EGO_SUM where of cosmetic
nature.
However, the deprecation of EGO_SUM is harmful to Gentoo and its users.
To briefly re-iterate the reasons:
The EGO_SUM alternatives
- do not have the same level of trust and therefore have a negative
impact on security (a dubious tarball someone put somewhere, especially
when proxy-maint)
- are not easily verifiable
- require additional effort when developing ebuilds
- hinder the packaging and Gentoo's adoption of Go-based projects, which
is worrisome as Go is very popular
- prevent Go modules from being shared as DISTFILES on the mirrors
across various packages
Last but not least, we have the same situation in the Rust ecosystem,
but we allow the EGO_SUM "equivalent" there.
So with portage checking the environment of ebuilds and warning if it
becomes too large, and with the arguments above, I do not see any reason
we should outlaw EGO_SUM.
- Flow
Previous discussions:
https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa
https://archives.gentoo.org/gentoo-dev/message/d78af7f168cef24bfa302f7f75c3ef11
[gentoo-dev] Re: EGO_SUM
Hi Sam,
thanks for your feedback. I am glad for everyone who engages in this
discussion and shares their views and new information.
On 24/04/2023 22.28, Sam James wrote:
Florian Schmaus writes:
[CCing williamh@ as go-module.eclass & dev-lang/go maintainer.]
I like to ask the Gentoo council to vote on whether EGO_SUM should be
reinstated ("un-deprecated") or not > In the various previous discussions, the
need
for _some_ limit to be implemented (derived from EGO_SUM) was clear from
the QA team and others.
Asking to impose an artificial limit is based on the same unfounded
belief under which EGO_SUM was deprecated in the first place. I am
worried that if we follow this, then a potential next step is to argue
about adding packages to ::gentoo.
Voting on the matter now would be reopening the issue which led EGO_SUM
to be deprecated in the first place, with only a partial mitigation
(the Portage warning).
I am sorry, but I do not follow. I think this is partly because it is
not clear "what" (else) to mitigate.
The discussion would be more productive if someone who is supporting the
EGO_SUM deprecation could rationally summarize the main arguments why we
deprecated EGO_SUM.
Any such limit should be supported by pkgcheck, allow using EGO_SUM
for most packages, but exclude the pathological cases which we're
unlikely to want in ::gentoo.
(Limit-per-ebuild rather than per-package is one option of many,
too.)
As you probably noticed, I am not aware why we should impose such a
limit. Especially a per-package limit confines the ability to provide
the user with multiple versions of a package, which sometimes comes in
handy [1].
Most voices on the related mailing-list threads expressed support for
reinstating EGO_SUM. At least, that is my impression. While the
arguments used to deprecate EGO_SUM were mostly of esthetic nature.
I want to state what should be common sense. Namely, asking for a
democratic vote is not a personal attack against any involved
person.
[...]
I agree this is an important issue that affects the practicality
of using Gentoo for some, and for contributing to Gentoo to others.
Same data point: Just in the last few days, multiple users reported in
#-guru issues they wouldn't have had if EGO_SUM was not deprecated.
- Flow
1: From my experience, this is also something Gentoo is praised for.
[gentoo-dev] Re: EGO_SUM
On 26/04/2023 18.12, Matt Turner wrote: On Wed, Apr 26, 2023 at 11:31 AM Florian Schmaus wrote: The discussion would be more productive if someone who is supporting the EGO_SUM deprecation could rationally summarize the main arguments why we deprecated EGO_SUM. You're requesting the changes. It's on you to read the previous threads and try to understand. It's not others' responsibilities to justify the status quo to you, but tl;dr is Manifest files grew to insane sizes for golang packages with many dependencies, and the Manifest size is a cost all Gentoo users pay regardless of whether they use the package. I am sorry. I did try to understand the reasoning in the previous threads. However, I do not conclude that the "cost" users must pay for EGO_SUM justifies EGO_SUM's deprecation. It is the other way around: EGO_SUM's advantages do not explain its deprecation, even if users have to pay a cost. You write that the "Manifest sizes grew to insane sizes"? At which boundary does a package size, the total size of the package's directory, become insane? Disk space is cheap. Currently, ::gentoo, without metadata, is around 470 MiB. If you add 10 Go packages with a whopping 200 KiB each, then this adds 2 MiB to that. I need someone to explain how this constitutes an issue with disk space. Even if we add 100 Go packages, probably roughly the number of Go packages we have in ::gentoo, then those 20 MiB are not significant. Needless to say that the average size of a Go package is less than the 200 KiB uses in this calculation. Network traffic, while also being cheap, may be more of an issue. Currently, gentoo-latest.tar.xz is ~41 MiB. So on a conservative approximation ::gentoo compresses to 1/10. So, the 10 Go-packages cause 200 KiB of additional traffic. Even when using a low-bandwidth connection, say 12 KiB/s, this only adds 17 extra seconds to the transfer duration. Moreover, the rate of change would be a better metric if we want to quantify the cost of a package. For example, a user who syncs daily is more affected by a package with 1 KiB of daily changes than a 200 KiB package that changes once per year. The "cost" for EGO_SUM is negligible. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: EGO_SUM
On 27/04/2023 11.24, Ulrich Mueller wrote: On Thu, 27 Apr 2023, Florian Schmaus wrote: Network traffic, while also being cheap, may be more of an issue. Currently, gentoo-latest.tar.xz is ~41 MiB. So on a conservative approximation ::gentoo compresses to 1/10. So, the 10 Go-packages cause 200 KiB of additional traffic. Even when using a low-bandwidth connection, say 12 KiB/s, this only adds 17 extra seconds to the transfer duration. Manifest files contain binary hashes which don't compress to 1/10. A factor of 1/2 may be more realistic (since a byte is represented by two hex digits). You are right, Manifests compress roughly to half their size. I did not consider that. Thanks for pointing it out. This does not affect the argument regarding the rate of change, though. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: EGO_SUM
On 27/04/2023 14.54, Michał Górny wrote: On Thu, 2023-04-27 at 09:58 +0200, Florian Schmaus wrote: Disk space is cheap. No, it's not. Gentoo supports more hardware than your average PC with beefy hard drive and/or possibility of installing one. Let's not forget that you need a ::gentoo checkout even on a system running purely on binary packages. You are right. Gentoo supports a broad range of hardware in many dimensions, e.g., architecture, release date, and composition. You seem to suggest that are Gentoo systems that can not handle the additional disk space consumption of EGO_SUM Go-packages? I can not imagine systems that are able to deal with the ~500 MiB ::gentoo repository, but would break if the same repository would contain 100 additional Go-packages with 200 KiB each. Even under a "worst-case" assumption, where we would have 256 Go-packages with each having a 1 MiB package-directory size, any system that can handle the current state of ::gentoo should be able to take the additional 256 MiB (+ metadata). Network traffic, while also being cheap, may be more of an issue. Again, you're making assumption based on living in a well-developed area and discriminating against users who have shoddy Internet connectivity. That said, this all was discussed in the past. I really wish you would humble down and try to find a solution that would work for everyone instead of showing arrogance and lack of concern for users outside your "majority" view of Gentoo. I am sorry. I will work on my humbleness. I am only pursuing the modest request to legitimize any decision regarding EGO_SUM by a democratic vote. As far as I can tell, there was never a democratic vote regarding EGO_SUM. But please correct me if I am wrong. And I never said that I believe in representing the majority's opinion. That said, I prefer to have this voted on by an all-developer vote than a council vote. Then we would know what the majority voted for. Is that possible? - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: EGO_SUM
On 28/04/2023 16.34, Michał Górny wrote: On Fri, 2023-04-28 at 08:59 +0200, Florian Schmaus wrote: And I never said that I believe in representing the majority's opinion. That said, I prefer to have this voted on by an all-developer vote than a council vote. Then we would know what the majority voted for. Is that possible? There's the General Resolution but it's supposed to be used only to override Council decisions, so you should go with a Council vote first. Could we temporarily re-purpose Gentoo's election infrastructure to hold an all-developer opinion poll? I imagine a poll asking for opinions, nothing binding. Furthermore, since Gentoo's voting infrastructure uses the Condorcet method, we could have multiple options. A poll-preceding phase where voters can submit options for the poll would help to take everyone's position into account. And then, performing a poll where everyone can rank the available options should allow us to get a pretty good idea about what the community of Gentoo developers thinks about this topic. @gentoo-elections: would you be willing to assist in such a venture? - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: EGO_SUM
On 27/04/2023 23.16, Sam James wrote: Florian Schmaus writes: [[PGP Signed Part:Undecided]] On 26/04/2023 18.12, Matt Turner wrote: On Wed, Apr 26, 2023 at 11:31 AM Florian Schmaus wrote: The discussion would be more productive if someone who is supporting the EGO_SUM deprecation could rationally summarize the main arguments why we deprecated EGO_SUM. You're requesting the changes. It's on you to read the previous threads and try to understand. It's not others' responsibilities to justify the status quo to you, but tl;dr is Manifest files grew to insane sizes for golang packages with many dependencies, and the Manifest size is a cost all Gentoo users pay regardless of whether they use the package. I am sorry. I did try to understand the reasoning in the previous threads. However, I do not conclude that the "cost" users must pay for EGO_SUM justifies EGO_SUM's deprecation. It is the other way around: EGO_SUM's advantages do not explain its deprecation, even if users have to pay a cost. You write that the "Manifest sizes grew to insane sizes"? At which boundary does a package size, the total size of the package's directory, become insane? Disk space is cheap. Currently, ::gentoo, without metadata, is around 470 MiB. If you add 10 Go packages with a whopping 200 KiB each, then this adds 2 MiB to that. I need someone to explain how this constitutes an issue with disk space. Even if we add 100 Go packages, probably roughly the number of Go packages we have in ::gentoo, then those 20 MiB are not significant. Needless to say that the average size of a Go package is less than the 200 KiB uses in this calculation. The numbers you've used here suggest you've missed some of the big problematic cases from the past: - https://bugs.gentoo.org/833478 (1.1MB manifest) - https://bugs.gentoo.org/833477 (1.6MB manifest) Thanks for pointing those bugs out. But please allow me to clarify that I did not miss those "problematic" cases from the past. I performed a tree-wide analysis regarding EGO_SUM and IIRC published the results in my previous post about EGO_SUM last year. https://dev.gentoo.org/~flow/ego_sum-2022-01-01.txt shows the analysis results for ::gentoo as of 2022-01-01 (I've recently updated the file to contain the Manifest-size too). Minikube (#833478) and k3s (#833477) appear there, too, with package-directory sizes over one MiB. However, those packages are under the top five of packages using EGO_SUM by package-directory size. They do not represent the average Go package. The mean size of a Manifest of a package using EGO_SUM was 186 KiB, and the median was even lower at 84 KiB. Only a tiny percentage of packages, below 5%, had a Manifest-size above one MiB. It appears that some feel like the EGO_SUM size consumption is wasteful. I am always sympathetic toward optimization efforts that save resources. Be it bytes-at-rest, transferred bytes, or CPU cycles. Often those can make a difference, or at least, they are evidence of engineering skills. But even if all Go-packages using EGO_SUM had one-MiB-sized Manifests, it is unclear what the actual issue is. Both bugs ask for action without describing the negative impact of those larger than 1 MiB Manifests. For example, there is no mention of someone being negatively affected by those bugs nor any observed reduction in functionality. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
