[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

Team,

Trustee nominations close at the end of Saturday, 27-Jun-26 UTC. 
That's about 36 hours from the time of writing.

So far, we have one acceptance and two other nominations for the three
seats this year.

Nominating and accepting yourself is acceptable.

-- 
Regards,

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 525 bytes --]

[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]

"Andreas K. Huettel" <dilfridge@gentoo.org> writes:

> Looks like noone is willing to step up, so here is a news item for removal of the
> 32bit stuff.
>
> =================
> Title: Gentoo drops 32bit S390 support

32-bit s390 support dropped

> Author: Andreas K. Hüttel <dilfridge@gentoo.org>
> Posted: 2026-07-03
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/s390/23.0
> Display-If-Profile: default/linux/s390/23.0/systemd
> Display-If-Profile: default/linux/s390/23.0/split-usr
> Display-If-Profile: default/linux/s390/23.0/time64
> Display-If-Profile: default/linux/s390/23.0/time64/systemd
> Display-If-Profile: default/linux/s390/23.0/time64/split-usr
>
> The legacy 32bit ABI support for IBM S390 mainframes is on the way out just
> about everywhere:
> * Pure 32bit hardware is by now nonexistent (64bit support exists since 2002).
> * Full 32bit kernel support is gone since 2014.
> * The 32bit ABI userspace emulation layer has been dropped in the kernel since
>   version 6.19.
> * glibc will drop 32bit ABI support in version 2.44.

GCC 17 will drop support too, and it is not in a good state in 16 at
least either.

> As a consequence, Gentoo will also drop support for it, effective immediately.
> There will be no stage builds anymore. The 32bit profiles will be marked
> deprecated and experimental, not receive any testing anymore, and be removed
> in the next profile version. Corresponding bug reports may get ignored or
> closed immediately. If you are still using this configuration, we urge you to
> find an alternative.
>
> This does *not* affect the 64bit code ("s390x", CHOST=s390x-ibm-linux-gnu)
> with its profiles and stages.

LGTM with title tweak. Thanks for doing it.

> =================
>
>
>
>
> Am Donnerstag, 18. Juni 2026, 21:14:29 Japanische Normalzeit schrieb Andreas K. Huettel:
>> Hello everyone, 
>> 
>> the 31bit ABI support for s390 mainframes is on the way out just about everywhere.
>> 
>> * Pure 31bit hardware is by now nonexistent (64bit support exists since 2002)
>> * Full 31bit kernel support is gone since 2014
>> * The 31bit ABI userspace emulation layer has been dropped in the kernel recently 
>>   (I think in 6.19)
>> * glibc will drop 31bit support in 2.44
>> 
>> So far I tried to keep things running as far as @system and the stage builds
>> are concerned, but I have no personal investment in the 31bit s390 support, and
>> the effort seems not worthwhile anymore. The S390 project consists currently of
>> me (mostly for releng), Sam (mostly for toolchain), and Ago (mostly for...?).
>> 
>> Unless someone dedicated to s390 and maintaining a legacy userspace steps up, I
>> would suggest now really dropping support of that ABI (CHOST=s390-ibm-linux-gnu) 
>> for good.
>> 
>> This does *not* affect the 64bit code (CHOST=s390x-ibm-linux-gnu), profiles, and
>> stages.
>> 
>> Cheers,
>> Andreas
>> 
>> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

>>>>> On Fri, 26 Jun 2026, Andreas K Huettel wrote:

> Looks like noone is willing to step up, so here is a news item for
> removal of the 32bit stuff.

> =================
> Title: Gentoo drops 32bit S390 support
> Author: Andreas K. Hüttel <dilfridge@gentoo.org>
> Posted: 2026-07-03
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/s390/23.0
> Display-If-Profile: default/linux/s390/23.0/systemd
> Display-If-Profile: default/linux/s390/23.0/split-usr
> Display-If-Profile: default/linux/s390/23.0/time64
> Display-If-Profile: default/linux/s390/23.0/time64/systemd
> Display-If-Profile: default/linux/s390/23.0/time64/split-usr

> The legacy 32bit ABI support for IBM S390 mainframes is on the way out just
> about everywhere:
> * Pure 32bit hardware is by now nonexistent (64bit support exists since 2002).
> * Full 32bit kernel support is gone since 2014.
> * The 32bit ABI userspace emulation layer has been dropped in the kernel since
>   version 6.19.
> * glibc will drop 32bit ABI support in version 2.44.
> As a consequence, Gentoo will also drop support for it, effective immediately.
> There will be no stage builds anymore. The 32bit profiles will be marked
> deprecated and experimental, not receive any testing anymore,

"no longer receive any testing"?

>                                                               and be removed
> in the next profile version. Corresponding bug reports may get ignored or
> closed immediately. If you are still using this configuration, we urge you to
> find an alternative.

> This does *not* affect the 64bit code ("s390x", CHOST=s390x-ibm-linux-gnu)
> with its profiles and stages.
> =================

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]

Looks like noone is willing to step up, so here is a news item for removal of the
32bit stuff.

=================
Title: Gentoo drops 32bit S390 support
Author: Andreas K. Hüttel <dilfridge@gentoo.org>
Posted: 2026-07-03
Revision: 1
News-Item-Format: 2.0
Display-If-Profile: default/linux/s390/23.0
Display-If-Profile: default/linux/s390/23.0/systemd
Display-If-Profile: default/linux/s390/23.0/split-usr
Display-If-Profile: default/linux/s390/23.0/time64
Display-If-Profile: default/linux/s390/23.0/time64/systemd
Display-If-Profile: default/linux/s390/23.0/time64/split-usr

The legacy 32bit ABI support for IBM S390 mainframes is on the way out just
about everywhere:
* Pure 32bit hardware is by now nonexistent (64bit support exists since 2002).
* Full 32bit kernel support is gone since 2014.
* The 32bit ABI userspace emulation layer has been dropped in the kernel since
  version 6.19.
* glibc will drop 32bit ABI support in version 2.44.
As a consequence, Gentoo will also drop support for it, effective immediately.
There will be no stage builds anymore. The 32bit profiles will be marked
deprecated and experimental, not receive any testing anymore, and be removed
in the next profile version. Corresponding bug reports may get ignored or
closed immediately. If you are still using this configuration, we urge you to
find an alternative.

This does *not* affect the 64bit code ("s390x", CHOST=s390x-ibm-linux-gnu)
with its profiles and stages.
=================




Am Donnerstag, 18. Juni 2026, 21:14:29 Japanische Normalzeit schrieb Andreas K. Huettel:
> Hello everyone, 
> 
> the 31bit ABI support for s390 mainframes is on the way out just about everywhere.
> 
> * Pure 31bit hardware is by now nonexistent (64bit support exists since 2002)
> * Full 31bit kernel support is gone since 2014
> * The 31bit ABI userspace emulation layer has been dropped in the kernel recently 
>   (I think in 6.19)
> * glibc will drop 31bit support in 2.44
> 
> So far I tried to keep things running as far as @system and the stage builds
> are concerned, but I have no personal investment in the 31bit s390 support, and
> the effort seems not worthwhile anymore. The S390 project consists currently of
> me (mostly for releng), Sam (mostly for toolchain), and Ago (mostly for...?).
> 
> Unless someone dedicated to s390 and maintaining a legacy userspace steps up, I
> would suggest now really dropping support of that ABI (CHOST=s390-ibm-linux-gnu) 
> for good.
> 
> This does *not* affect the 64bit code (CHOST=s390x-ibm-linux-gnu), profiles, and
> stages.
> 
> Cheers,
> Andreas
> 
> 


-- 
PD Dr. Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Experience has shown that having auto-formatting enabled by default
is more of a nuisance than it is helpful. Since greadme allows
creating the readme file via Bash here-docs, ebuild authors typically
control the exact formatting and line breaks themselves rather than
wanting to rely on the external 'fmt' tool.

To address this, EAPI 9 changes the default behavior to disable
auto-formatting. The formatting feature is still fully supported,
but it is now strictly opt-in via the new GREADME_AUTOFORMAT variable.

For backwards compatibility, EAPI 8 retains the old behavior and
defaults to auto-formatting (opt-out via GREADME_DISABLE_AUTOFORMAT).

Additionally, the eapi9-pipestatus inherit is now conditionally
restricted to EAPI 8, as pipestatus is provided by EAPI 9.

Signed-off-by: Florian Schmaus <flow@gentoo.org>
---
 eclass/greadme.eclass | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
index 6c1e1fd57458..7e3f715fffa8 100644
--- a/eclass/greadme.eclass
+++ b/eclass/greadme.eclass
@@ -4,7 +4,7 @@
 # @ECLASS: greadme.eclass
 # @MAINTAINER:
 # Florian Schmaus <flow@gentoo.org>
-# @SUPPORTED_EAPIS: 8
+# @SUPPORTED_EAPIS: 8 9
 # @BLURB: install a doc file, that will be conditionally shown via elog messages
 # @DESCRIPTION:
 # An eclass for installing a README.gentoo doc file with important
@@ -45,6 +45,7 @@ _GREADME_ECLASS=1
 
 case ${EAPI} in
 	8) inherit eapi9-pipestatus ;;
+	9) ;;
 	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
@@ -61,7 +62,14 @@ _GREADME_REL_PATH="/usr/share/doc/${PF}/README.gentoo"
 # @ECLASS_VARIABLE: GREADME_DISABLE_AUTOFORMAT
 # @DEFAULT_UNSET
 # @DESCRIPTION:
-# If non-empty, the readme file will not be automatically formatted.
+# If non-empty, the readme file will not be automatically formatted if
+# EAPI < 9.
+
+# @ECLASS_VARIABLE: GREADME_AUTOFORMAT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, the readme file will be automatically formatted if
+# EAPI >= 9.
 
 # @FUNCTION: greadme_stdin
 # @USAGE: [--append]
@@ -113,7 +121,19 @@ _greadme_install_doc() {
 	debug-print-function ${FUNCNAME} "$@"
 
 	local greadme="${_GREADME_TMP_FILE}"
-	if [[ ! ${GREADME_DISABLE_AUTOFORMAT} ]]; then
+
+	local autoformat
+	if [[ ${EAPI} == 8 ]]; then
+		# Older EAPI default is to auto-format.
+		autoformat=1
+		[[ ${GREADME_DISABLE_AUTOFORMAT} ]] && autoformat=
+	else
+		# The modern default is not to auto-format.
+		autoformat=
+		[[ ${GREADME_AUTOFORMAT} ]] && autoformat=1
+	fi
+
+	if [[ ${autoformat} ]]; then
 		greadme="${_GREADME_TMP_FILE}".formatted
 
 		# Use fold, followed by a sed to strip trailing whitespace.
-- 
2.53.0

Adjust _bash_completion-r1_get_bashdir() to not respect pkg-config
files to obtain the completion directory in EAPI 9 to avoid
inconsitent installations.

Signed-off-by: Florian Schmaus <flow@gentoo.org>
---
 eclass/shell-completion.eclass | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/eclass/shell-completion.eclass b/eclass/shell-completion.eclass
index acbc850ced2a..f1281f6d2a4c 100644
--- a/eclass/shell-completion.eclass
+++ b/eclass/shell-completion.eclass
@@ -23,27 +23,31 @@ esac
 if [[ -z ${_SHELL_COMPLETION_ECLASS} ]]; then
 _SHELL_COMPLETION_ECLASS=1
 
+if [[ ${EAPI} != 9 ]]; then
 inherit toolchain-funcs
+fi
 
 # @FUNCTION: _bash-completion-r1_get_bashdir
 # @INTERNAL
 # @DESCRIPTION:
 # First argument is name of the string in bash-completion.pc
 # Second argument is the fallback directory if the string is not found
+# Note that the first argument is only used on EAPI < 9.
 # @EXAMPLE:
 # _bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion
 _bash-completion-r1_get_bashdir() {
 	debug-print-function ${FUNCNAME} "$@"
 
-	if $(tc-getPKG_CONFIG) --exists bash-completion &>/dev/null; then
+	if [[ ${EAPI} != 9 ]] && $(tc-getPKG_CONFIG) --exists bash-completion &>/dev/null; then
 		local path
 		path=$($(tc-getPKG_CONFIG) --variable="${1}" bash-completion) || die
 		# we need to return unprefixed, so strip from what pkg-config returns
 		# to us, bug #477692
 		echo "${path#"${EPREFIX}"}"
-	else
-		echo "${2}"
+		return
 	fi
+
+	echo "${2}"
 }
 
 # @FUNCTION: _bash-completion-r1_get_bashcompdir
-- 
2.53.0

To avoid duplicated code, replace the body of
bash-completion-r1.eclass wit

    inherit shell-completion

since everything is now in shell-completion.elcass.

Signed-off-by: Florian Schmaus <flow@gentoo.org>
---
 eclass/bash-completion-r1.eclass | 115 +------------------------------
 1 file changed, 2 insertions(+), 113 deletions(-)

diff --git a/eclass/bash-completion-r1.eclass b/eclass/bash-completion-r1.eclass
index 580f7f85911f..02425859d712 100644
--- a/eclass/bash-completion-r1.eclass
+++ b/eclass/bash-completion-r1.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # mgorny@gentoo.org
 # @SUPPORTED_EAPIS: 7 8
+# @PROVIDES: shell-completion
 # @BLURB: A few quick functions to install bash-completion files
 # @DESCRIPTION:
 # This eclass provides functions to install bash-completion files.
@@ -29,118 +30,6 @@
 if [[ -z ${_BASH_COMPLETION_R1_ECLASS} ]]; then
 _BASH_COMPLETION_R1_ECLASS=1
 
-inherit toolchain-funcs
-
-case ${EAPI} in
-	7|8) ;;
-	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
-esac
-
-# @FUNCTION: _bash-completion-r1_get_bashdir
-# @INTERNAL
-# @DESCRIPTION:
-# First argument is name of the string in bash-completion.pc
-# Second argument is the fallback directory if the string is not found
-# @EXAMPLE:
-# _bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion
-_bash-completion-r1_get_bashdir() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	if $(tc-getPKG_CONFIG) --exists bash-completion &>/dev/null; then
-		local path
-		path=$($(tc-getPKG_CONFIG) --variable="${1}" bash-completion) || die
-		# we need to return unprefixed, so strip from what pkg-config returns
-		# to us, bug #477692
-		echo "${path#"${EPREFIX}"}"
-	else
-		echo "${2}"
-	fi
-}
-
-# @FUNCTION: _bash-completion-r1_get_bashcompdir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed bash-completion completions directory.
-_bash-completion-r1_get_bashcompdir() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	_bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion/completions
-}
-
-# @FUNCTION: _bash-completion-r1_get_bashhelpersdir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed bash-completion helpers directory.
-_bash-completion-r1_get_bashhelpersdir() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	_bash-completion-r1_get_bashdir helpersdir /usr/share/bash-completion/helpers
-}
-
-# @FUNCTION: get_bashcompdir
-# @DESCRIPTION:
-# Get the bash-completion completions directory.
-get_bashcompdir() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	echo "${EPREFIX}$(_bash-completion-r1_get_bashcompdir)"
-}
-
-# @FUNCTION: get_bashhelpersdir
-# @INTERNAL
-# @DESCRIPTION:
-# Get the bash-completion helpers directory.
-get_bashhelpersdir() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	echo "${EPREFIX}$(_bash-completion-r1_get_bashhelpersdir)"
-}
-
-# @FUNCTION: dobashcomp
-# @USAGE: <file> [...]
-# @DESCRIPTION:
-# Install bash-completion files passed as args. Has EAPI-dependent failure
-# behavior (like doins).
-dobashcomp() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	(
-		insopts -m 0644
-		insinto "$(_bash-completion-r1_get_bashcompdir)"
-		doins "${@}"
-	)
-}
-
-# @FUNCTION: newbashcomp
-# @USAGE: <file> <newname>
-# @DESCRIPTION:
-# Install bash-completion file under a new name. Has EAPI-dependent failure
-# behavior (like newins).
-newbashcomp() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	(
-		insopts -m 0644
-		insinto "$(_bash-completion-r1_get_bashcompdir)"
-		newins "${@}"
-	)
-}
-
-# @FUNCTION: bashcomp_alias
-# @USAGE: <basename> <alias>...
-# @DESCRIPTION:
-# Alias <basename> completion to one or more commands (<alias>es).
-bashcomp_alias() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	[[ ${#} -lt 2 ]] && die "Usage: ${FUNCNAME} <basename> <alias>..."
-	local base=${1} f
-	shift
-
-	for f; do
-		dosym "${base}" "$(_bash-completion-r1_get_bashcompdir)/${f}" \
-			|| return
-	done
-}
+inherit shell-completion
 
 fi
-- 
2.53.0

The shell-completion.eclass will soon be inherited by
bash-completion-r1.eclass, which supports EAPI 7. In preperation for
this, mark shell-completion.eclass to also support EAPI 7.

Signed-off-by: Florian Schmaus <flow@gentoo.org>
---
 eclass/shell-completion.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/shell-completion.eclass b/eclass/shell-completion.eclass
index 5390f317cad3..acbc850ced2a 100644
--- a/eclass/shell-completion.eclass
+++ b/eclass/shell-completion.eclass
@@ -8,7 +8,7 @@
 # mgorny@gentoo.org
 # @AUTHOR:
 # Alfred Wingate <parona@protonmail.com>
-# @SUPPORTED_EAPIS: 8 9
+# @SUPPORTED_EAPIS: 7 8 9
 # @BLURB: a few quick functions to install various shell completion files
 # @DESCRIPTION:
 # This eclass provides a standardised way to install shell completions
@@ -16,7 +16,7 @@
 # 'bash-completion-r1', thus extending on its functionality.
 
 case ${EAPI} in
-	8|9) ;;
+	7|8|9) ;;
 	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported"
 esac
 
-- 
2.53.0

Signed-off-by: Florian Schmaus <flow@gentoo.org>
---
 eclass/bash-completion-r1.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/bash-completion-r1.eclass b/eclass/bash-completion-r1.eclass
index 9fffbbe4bb6f..580f7f85911f 100644
--- a/eclass/bash-completion-r1.eclass
+++ b/eclass/bash-completion-r1.eclass
@@ -6,6 +6,9 @@
 # mgorny@gentoo.org
 # @SUPPORTED_EAPIS: 7 8
 # @BLURB: A few quick functions to install bash-completion files
+# @DESCRIPTION:
+# This eclass provides functions to install bash-completion files.
+# For EAPI 9 or newer, use shell-completion.eclass instead.
 # @EXAMPLE:
 #
 # @CODE
-- 
2.53.0

Signed-off-by: Florian Schmaus <flow@gentoo.org>
---
 eclass/shell-completion.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/shell-completion.eclass b/eclass/shell-completion.eclass
index 225db4123f16..5390f317cad3 100644
--- a/eclass/shell-completion.eclass
+++ b/eclass/shell-completion.eclass
@@ -8,7 +8,7 @@
 # mgorny@gentoo.org
 # @AUTHOR:
 # Alfred Wingate <parona@protonmail.com>
-# @SUPPORTED_EAPIS: 8
+# @SUPPORTED_EAPIS: 8 9
 # @BLURB: a few quick functions to install various shell completion files
 # @DESCRIPTION:
 # This eclass provides a standardised way to install shell completions
@@ -16,7 +16,7 @@
 # 'bash-completion-r1', thus extending on its functionality.
 
 case ${EAPI} in
-	8) ;;
+	8|9) ;;
 	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported"
 esac
 
-- 
2.53.0

Include the functions of bash-completion-r1.eclass instead of
inheriting bash-completion-r1.eclass. The idea is to phase out
bash-completion-r1.eclass in favor of shell-completion.eclass with
EAPI 9.

Signed-off-by: Florian Schmaus <flow@gentoo.org>
---
 eclass/shell-completion.eclass | 114 +++++++++++++++++++++++++++++++--
 1 file changed, 110 insertions(+), 4 deletions(-)

diff --git a/eclass/shell-completion.eclass b/eclass/shell-completion.eclass
index caccdee7b19b..225db4123f16 100644
--- a/eclass/shell-completion.eclass
+++ b/eclass/shell-completion.eclass
@@ -1,14 +1,14 @@
-# Copyright 2023-2024 Gentoo Authors
+# Copyright 2023-2026 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: shell-completion.eclass
 # @MAINTAINER:
 # Jonas Frei <freijon@pm.me>
 # Florian Schmaus <flow@gentoo.org>
+# mgorny@gentoo.org
 # @AUTHOR:
 # Alfred Wingate <parona@protonmail.com>
 # @SUPPORTED_EAPIS: 8
-# @PROVIDES: bash-completion-r1
 # @BLURB: a few quick functions to install various shell completion files
 # @DESCRIPTION:
 # This eclass provides a standardised way to install shell completions
@@ -23,8 +23,114 @@ esac
 if [[ -z ${_SHELL_COMPLETION_ECLASS} ]]; then
 _SHELL_COMPLETION_ECLASS=1
 
-# Extend bash-completion-r1
-inherit bash-completion-r1
+inherit toolchain-funcs
+
+# @FUNCTION: _bash-completion-r1_get_bashdir
+# @INTERNAL
+# @DESCRIPTION:
+# First argument is name of the string in bash-completion.pc
+# Second argument is the fallback directory if the string is not found
+# @EXAMPLE:
+# _bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion
+_bash-completion-r1_get_bashdir() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	if $(tc-getPKG_CONFIG) --exists bash-completion &>/dev/null; then
+		local path
+		path=$($(tc-getPKG_CONFIG) --variable="${1}" bash-completion) || die
+		# we need to return unprefixed, so strip from what pkg-config returns
+		# to us, bug #477692
+		echo "${path#"${EPREFIX}"}"
+	else
+		echo "${2}"
+	fi
+}
+
+# @FUNCTION: _bash-completion-r1_get_bashcompdir
+# @INTERNAL
+# @DESCRIPTION:
+# Get unprefixed bash-completion completions directory.
+_bash-completion-r1_get_bashcompdir() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	_bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion/completions
+}
+
+# @FUNCTION: _bash-completion-r1_get_bashhelpersdir
+# @INTERNAL
+# @DESCRIPTION:
+# Get unprefixed bash-completion helpers directory.
+_bash-completion-r1_get_bashhelpersdir() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	_bash-completion-r1_get_bashdir helpersdir /usr/share/bash-completion/helpers
+}
+
+# @FUNCTION: get_bashcompdir
+# @DESCRIPTION:
+# Get the bash-completion completions directory.
+get_bashcompdir() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	echo "${EPREFIX}$(_bash-completion-r1_get_bashcompdir)"
+}
+
+# @FUNCTION: get_bashhelpersdir
+# @INTERNAL
+# @DESCRIPTION:
+# Get the bash-completion helpers directory.
+get_bashhelpersdir() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	echo "${EPREFIX}$(_bash-completion-r1_get_bashhelpersdir)"
+}
+
+# @FUNCTION: dobashcomp
+# @USAGE: <file> [...]
+# @DESCRIPTION:
+# Install bash-completion files passed as args. Has EAPI-dependent failure
+# behavior (like doins).
+dobashcomp() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	(
+		insopts -m 0644
+		insinto "$(_bash-completion-r1_get_bashcompdir)"
+		doins "${@}"
+	)
+}
+
+# @FUNCTION: newbashcomp
+# @USAGE: <file> <newname>
+# @DESCRIPTION:
+# Install bash-completion file under a new name. Has EAPI-dependent failure
+# behavior (like newins).
+newbashcomp() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	(
+		insopts -m 0644
+		insinto "$(_bash-completion-r1_get_bashcompdir)"
+		newins "${@}"
+	)
+}
+
+# @FUNCTION: bashcomp_alias
+# @USAGE: <basename> <alias>...
+# @DESCRIPTION:
+# Alias <basename> completion to one or more commands (<alias>es).
+bashcomp_alias() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	[[ ${#} -lt 2 ]] && die "Usage: ${FUNCNAME} <basename> <alias>..."
+	local base=${1} f
+	shift
+
+	for f; do
+		dosym "${base}" "$(_bash-completion-r1_get_bashcompdir)/${f}" \
+			|| return
+	done
+}
 
 # @FUNCTION: _shell-completion_get_fishcompdir
 # @INTERNAL
-- 
2.53.0

On Tue, Jun 23, 2026 at 11:35:55AM -0400, Michael Orlitzky wrote:
> On 2026-06-23 14:18:37, James Le Cuirot wrote:
> > 
> > You seem to be saying that ACCT_USER_HOME_OWNER shouldn't go away entirely, and
> > therefore the fix still makes sense? I think your argument makes sense, but I'd
> > never heard of ACCT_USER_HOME_OWNER before I hit this issue, so I think someone
> > else should decide what to do.
> > 
> 
> There may be extreme cases where it is useful, but with only
> 
>   $ grep -rl ACCT_USER_HOME_OWNER acct-user | wc -l
>   14
> 
> examples (half of which are obvious mistakes), I guess I am hoping
> that we could review them first. If they're all bugs, then we don't
> need to add code to the eclass that would make future bugs easier.

I had a look at some cases, and it's a mixed bag. qmail.eclass is setting
ownership on directories within the HOME, but not on the HOME itself, as far as
I can see. anacron calls `diropts -o root -g cron` followed by `keepdir` on the
HOME. monkeysphere doesn't appear to set any ownership at all.

While cases like monkeysphere could be handled outside of acct-user, qmail and
cron have multiple consumers, so handling ownership within acct-user seems like
a good thing, as long as it's not done anywhere else.

On that basis, I think ACCT_USER_HOME_OWNER should stay, and I will merge the
fix now, but I am happy to go with whatever the eclass maintainers eventually
decide.

On 2026-06-23 14:18:37, James Le Cuirot wrote:
> 
> You seem to be saying that ACCT_USER_HOME_OWNER shouldn't go away entirely, and
> therefore the fix still makes sense? I think your argument makes sense, but I'd
> never heard of ACCT_USER_HOME_OWNER before I hit this issue, so I think someone
> else should decide what to do.
> 

There may be extreme cases where it is useful, but with only

  $ grep -rl ACCT_USER_HOME_OWNER acct-user | wc -l
  14

examples (half of which are obvious mistakes), I guess I am hoping
that we could review them first. If they're all bugs, then we don't
need to add code to the eclass that would make future bugs easier.

On Tue, Jun 23, 2026 at 6:43 AM James Le Cuirot <chewi@gentoo.org> wrote:
>
> Some acct-user packages were manually adding these dependencies but most
> were not, sometimes causing failures at installation time.
>
> Signed-off-by: James Le Cuirot <chewi@gentoo.org>
> ---
>  eclass/acct-user.eclass | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index a62a10c7d3ed..d4ef8993fe90 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 2019-2025 Gentoo Authors
> +# Copyright 2019-2026 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>
>  # @ECLASS: acct-user.eclass
> @@ -19,7 +19,7 @@
>  # on the package providing it.
>  #
>  # The ebuild needs to call acct-user_add_deps after specifying
> -# ACCT_USER_GROUPS.
> +# ACCT_USER_GROUPS or ACCT_USER_HOME_OWNER.
>  #
>  # Example:
>  # If your package needs user 'foo' belonging to same-named group, you
> @@ -152,8 +152,8 @@ S=${WORKDIR}
>
>  # @FUNCTION: acct-user_add_deps
>  # @DESCRIPTION:
> -# Generate appropriate RDEPEND from ACCT_USER_GROUPS.  This must be
> -# called if ACCT_USER_GROUPS are set.
> +# Generate appropriate RDEPEND from ACCT_USER_GROUPS and
> +# ACCT_USER_HOME_OWNER.  This must be called if one of these are set.
>  acct-user_add_deps() {
>         debug-print-function ${FUNCNAME} "$@"
>
> @@ -165,6 +165,23 @@ acct-user_add_deps() {
>         fi
>
>         RDEPEND+=${ACCT_USER_GROUPS[*]/#/ acct-group/}
> +
> +       local user group
> +       case ${ACCT_USER_HOME_OWNER} in
> +               *:*)
> +                       user=${ACCT_USER_HOME_OWNER%:*}
> +                       group=${ACCT_USER_HOME_OWNER#*:} ;;
> +               *)
> +                       user=${ACCT_USER_HOME_OWNER}
> +                       group= ;;
> +       esac
> +
> +       # Add ACCT_USER_HOME_OWNER dependencies if necessary.
> +       [[ -n ${user} && ${user} != "${ACCT_USER_NAME}" ]] &&
> +               RDEPEND+=" acct-user/${user}"
> +       [[ -n ${group} ]] && ! has "${group}" "${ACCT_USER_GROUPS[@]}" &&
> +               RDEPEND+=" acct-group/${group}"
> +
>         _ACCT_USER_ADD_DEPS_CALLED=1
>  }
>
> --
> 2.54.0
>

The patch looks ok to me.

Please validate that this does not cause any dependency errors for
existing ebuilds; a PR on codeberg or github should do the trick.

On Tue, Jun 23, 2026 at 10:00:53AM -0400, Michael Orlitzky wrote:
> On 2026-06-23 11:43:04, James Le Cuirot wrote:
> > Some acct-user packages were manually adding these dependencies but most
> > were not, sometimes causing failures at installation time.
> 
> Setting ACCT_USER_HOME_OWNER is almost always a mistake. The package
> manager doesn't manage directories, so it's possible for two different
> packages to "claim" the same directory, and obviously not great if two
> different packages fight over the ownership of and permissions on an
> important directory.
> 
> Choosing a random example (sorry whoever maintains this, I didn't look),
> 
>   $ grep -C 2 ACCT_USER_HOME_OWNER unbound/unbound-0-r3.ebuild
>   ACCT_USER_ID=391
>   ACCT_USER_HOME="/etc/${PN}"
>   ACCT_USER_HOME_OWNER="root:${PN}"
>   ACCT_USER_HOME_PERMS=0750
>   ACCT_USER_GROUPS=( ${PN} )
> 
> This is a mistake because ownership and permissions on /etc/unbound
> should be set in the ebuild... in fact, the ebuild already does this:
> 
>   # Create space for auto-trust-anchor-file eventually
>   # downloaded by unbound-anchor
>   keepdir /etc/unbound/var
>   fowners root:unbound /etc/unbound/var
>   fperms 0770 /etc/unbound/var
> 
> But now we have two packages fighting over the permissions on
> /etc/unbound. If one of them gets out of sync we can wind up with a
> security issue.
> 
> tl;dr if the package needs special permissions and ownership on any
> directories, the ebuild should do that, and the acct-user package
> should use some other directory entirely to avoid chmod/chown clashes.
> 
> About half of the examples in the tree are of the type above. Some
> others look sketchy, like acct-user/{nobody,sshd} both setting
> ownership and permissions on /var/empty. The legitimate cases probably
> fit on one hand.

You seem to be saying that ACCT_USER_HOME_OWNER shouldn't go away entirely, and
therefore the fix still makes sense? I think your argument makes sense, but I'd
never heard of ACCT_USER_HOME_OWNER before I hit this issue, so I think someone
else should decide what to do.

On 2026-06-23 11:43:04, James Le Cuirot wrote:
> Some acct-user packages were manually adding these dependencies but most
> were not, sometimes causing failures at installation time.

Setting ACCT_USER_HOME_OWNER is almost always a mistake. The package
manager doesn't manage directories, so it's possible for two different
packages to "claim" the same directory, and obviously not great if two
different packages fight over the ownership of and permissions on an
important directory.

Choosing a random example (sorry whoever maintains this, I didn't look),

  $ grep -C 2 ACCT_USER_HOME_OWNER unbound/unbound-0-r3.ebuild
  ACCT_USER_ID=391
  ACCT_USER_HOME="/etc/${PN}"
  ACCT_USER_HOME_OWNER="root:${PN}"
  ACCT_USER_HOME_PERMS=0750
  ACCT_USER_GROUPS=( ${PN} )

This is a mistake because ownership and permissions on /etc/unbound
should be set in the ebuild... in fact, the ebuild already does this:

  # Create space for auto-trust-anchor-file eventually
  # downloaded by unbound-anchor
  keepdir /etc/unbound/var
  fowners root:unbound /etc/unbound/var
  fperms 0770 /etc/unbound/var

But now we have two packages fighting over the permissions on
/etc/unbound. If one of them gets out of sync we can wind up with a
security issue.

tl;dr if the package needs special permissions and ownership on any
directories, the ebuild should do that, and the acct-user package
should use some other directory entirely to avoid chmod/chown clashes.

About half of the examples in the tree are of the type above. Some
others look sketchy, like acct-user/{nobody,sshd} both setting
ownership and permissions on /var/empty. The legitimate cases probably
fit on one hand.

This is handled by the eclass.

Signed-off-by: James Le Cuirot <chewi@gentoo.org>
---
 acct-user/vdradmin/vdradmin-0-r3.ebuild | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/acct-user/vdradmin/vdradmin-0-r3.ebuild b/acct-user/vdradmin/vdradmin-0-r3.ebuild
index c16cb6cea5b1..74be05a59d3b 100644
--- a/acct-user/vdradmin/vdradmin-0-r3.ebuild
+++ b/acct-user/vdradmin/vdradmin-0-r3.ebuild
@@ -1,4 +1,4 @@
-# Copyright 2020-2024 Gentoo Authors
+# Copyright 2020-2026 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
@@ -11,6 +11,3 @@ ACCT_USER_ID=453
 ACCT_USER_GROUPS=( vdradmin )
 
 acct-user_add_deps
-
-DEPEND+=" acct-group/vdradmin "
-RDEPEND+=" acct-group/vdradmin "
-- 
2.54.0

This is handled by the eclass.

Signed-off-by: James Le Cuirot <chewi@gentoo.org>
---
 acct-user/kismet/kismet-0-r3.ebuild | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/acct-user/kismet/kismet-0-r3.ebuild b/acct-user/kismet/kismet-0-r3.ebuild
index c725ddcc3986..cd7a7765b15a 100644
--- a/acct-user/kismet/kismet-0-r3.ebuild
+++ b/acct-user/kismet/kismet-0-r3.ebuild
@@ -1,4 +1,4 @@
-# Copyright 2020-2024 Gentoo Authors
+# Copyright 2020-2026 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
@@ -10,6 +10,3 @@ ACCT_USER_ID="388"
 ACCT_USER_GROUPS=( kismet )
 
 acct-user_add_deps
-
-DEPEND+=" acct-group/kismet "
-RDEPEND+=" acct-group/kismet "
-- 
2.54.0

This is handled by the eclass.

Signed-off-by: James Le Cuirot <chewi@gentoo.org>
---
 acct-user/duende/duende-0-r3.ebuild | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/acct-user/duende/duende-0-r3.ebuild b/acct-user/duende/duende-0-r3.ebuild
index 68d5b8c3c0de..90f3498f9d00 100644
--- a/acct-user/duende/duende-0-r3.ebuild
+++ b/acct-user/duende/duende-0-r3.ebuild
@@ -1,4 +1,4 @@
-# Copyright 2019-2024 Gentoo Authors
+# Copyright 2019-2026 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
@@ -9,6 +9,3 @@ ACCT_USER_ID=66
 ACCT_USER_GROUPS=( "maradns" )
 
 acct-user_add_deps
-
-DEPEND+=" acct-group/maradns "
-RDEPEND+=" acct-group/maradns "
-- 
2.54.0

This is now handled by the eclass.

Signed-off-by: James Le Cuirot <chewi@gentoo.org>
---
 acct-user/nobody/nobody-0-r2.ebuild | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/acct-user/nobody/nobody-0-r2.ebuild b/acct-user/nobody/nobody-0-r2.ebuild
index 7b8132b4d816..1921cbcef0e0 100644
--- a/acct-user/nobody/nobody-0-r2.ebuild
+++ b/acct-user/nobody/nobody-0-r2.ebuild
@@ -1,4 +1,4 @@
-# Copyright 2020-2024 Gentoo Authors
+# Copyright 2020-2026 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
@@ -13,5 +13,3 @@ ACCT_USER_HOME_PERMS=0755
 ACCT_USER_GROUPS=( nobody )
 
 acct-user_add_deps
-
-RDEPEND+=" acct-user/root"
-- 
2.54.0

This is now handled by the eclass.

Signed-off-by: James Le Cuirot <chewi@gentoo.org>
---
 acct-user/alias/alias-0-r3.ebuild | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/acct-user/alias/alias-0-r3.ebuild b/acct-user/alias/alias-0-r3.ebuild
index cb182ce2d9d6..0895d39ac5d3 100644
--- a/acct-user/alias/alias-0-r3.ebuild
+++ b/acct-user/alias/alias-0-r3.ebuild
@@ -1,4 +1,4 @@
-# Copyright 2019-2024 Gentoo Authors
+# Copyright 2019-2026 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
@@ -13,6 +13,3 @@ ACCT_USER_HOME_PERMS=02755
 ACCT_USER_GROUPS=( nofiles )
 
 acct-user_add_deps
-
-DEPEND+=" acct-group/qmail "
-RDEPEND+=" acct-group/qmail "
-- 
2.54.0

Some acct-user packages were manually adding these dependencies but most
were not, sometimes causing failures at installation time.

Signed-off-by: James Le Cuirot <chewi@gentoo.org>
---
 eclass/acct-user.eclass | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index a62a10c7d3ed..d4ef8993fe90 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -1,4 +1,4 @@
-# Copyright 2019-2025 Gentoo Authors
+# Copyright 2019-2026 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: acct-user.eclass
@@ -19,7 +19,7 @@
 # on the package providing it.
 #
 # The ebuild needs to call acct-user_add_deps after specifying
-# ACCT_USER_GROUPS.
+# ACCT_USER_GROUPS or ACCT_USER_HOME_OWNER.
 #
 # Example:
 # If your package needs user 'foo' belonging to same-named group, you
@@ -152,8 +152,8 @@ S=${WORKDIR}
 
 # @FUNCTION: acct-user_add_deps
 # @DESCRIPTION:
-# Generate appropriate RDEPEND from ACCT_USER_GROUPS.  This must be
-# called if ACCT_USER_GROUPS are set.
+# Generate appropriate RDEPEND from ACCT_USER_GROUPS and
+# ACCT_USER_HOME_OWNER.  This must be called if one of these are set.
 acct-user_add_deps() {
 	debug-print-function ${FUNCNAME} "$@"
 
@@ -165,6 +165,23 @@ acct-user_add_deps() {
 	fi
 
 	RDEPEND+=${ACCT_USER_GROUPS[*]/#/ acct-group/}
+
+	local user group
+	case ${ACCT_USER_HOME_OWNER} in
+		*:*)
+			user=${ACCT_USER_HOME_OWNER%:*}
+			group=${ACCT_USER_HOME_OWNER#*:} ;;
+		*)
+			user=${ACCT_USER_HOME_OWNER}
+			group= ;;
+	esac
+
+	# Add ACCT_USER_HOME_OWNER dependencies if necessary.
+	[[ -n ${user} && ${user} != "${ACCT_USER_NAME}" ]] &&
+		RDEPEND+=" acct-user/${user}"
+	[[ -n ${group} ]] && ! has "${group}" "${ACCT_USER_GROUPS[@]}" &&
+		RDEPEND+=" acct-group/${group}"
+
 	_ACCT_USER_ADD_DEPS_CALLED=1
 }
 
-- 
2.54.0

Hi,

On 2026/06/23 04:18, Michael Orlitzky wrote:
> On 2026-06-22 20:55:39, Jaco Kroon wrote:
>> Hi All,
>>
>> Just naming but a few:
>>
>> apache2, php-fpm uses configtest
>> haproxy, sshd, syslog-ng, dovecot uses checkconfig
>>
>> I'd like to suggest that we at least encourage use of the latter, if not
>> make it a standard function (which just outputs "not supported" if the
>> function isn't found).
> If it's possible to check the config for errors, doing so should be
> baked in to (re)start/reload:
>
> https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#dont-restartreload-with-a-broken-config
>
> Then we don't have to worry about remembering a nonstandard name, or
> at least it becomes a lot less important.

Fully agree with that, and reload/restart *should* peform those checks 
as per the link.

In many cases my workflow given a list of changes that needs to be made 
is something like:


foreach (changelist as change) {
   make_change($change);
   while (!validate_config()) /* aka /etc/init.d/$service checkconfig */
     fix_config();
}
reload/restart();

Thus exposing this checkconfig as a mechanism would help simplify that 
process overall, and I'm sure others do similar.  Also, having this as a 
standard function means that the boilerplate to invoke that during 
{start,stop}_pre also goes away and can become part of the standard 
openrc process.

Other scenarios include preparing a configuration for scheduled 
reload/restart, where the change is configured during office hours, but 
a reload/restart may only occur outside of office hours (often at hours 
when people should be sleeping, and fixing things take longer than it 
should).

Kind regards,
Jaco

On 2026-06-22 20:55:39, Jaco Kroon wrote:
> Hi All,
> 
> Just naming but a few:
> 
> apache2, php-fpm uses configtest
> haproxy, sshd, syslog-ng, dovecot uses checkconfig
> 
> I'd like to suggest that we at least encourage use of the latter, if not 
> make it a standard function (which just outputs "not supported" if the 
> function isn't found).

If it's possible to check the config for errors, doing so should be
baked in to (re)start/reload:

https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#dont-restartreload-with-a-broken-config

Then we don't have to worry about remembering a nonstandard name, or
at least it becomes a lot less important.

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

>>>>> On Mon, 22 Jun 2026, Michał Górny wrote:

> To be honest, I was thinking how to fit SC into all of this.  In the
> end, what we want people to do is to follow the SC.  What I really
> dislike about the current system is that we're doing one sign-off for
> one policy, and then adding GitHub pull request templates to have them
> sign off on another policy.

> Admittedly, this changes very little, so perhaps it makes no sense.  I
> honestly doubt most of the contributors even realize what they're
> signing off on -- given that --signoff is pretty much a standard for
> contributing to many projects these days.

Most of the time, a Signed-off-by line is attached to something very
similar to the Linux DCO; our GCO is pretty similar to it (in fact, it's
laxer because of the provision for license files).

I'd rather not attach additional (stricter) meanings to it that are only
indirectly related to copyright law. It might even weaken our position,
because contributors will have the excuse that they inadvertently signed
off on something they didn't expect.

So, it's well into territory where I would feel uneasy without
consulting a lawyer.

> I'll withdraw the patch.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 544 bytes --]