[gentoo-dev] Packages up for grabs: dev-libs/cgreen, gnome-extra/nautilus-dropbox, sys-apps/thunderbolt-software-user-space

[Florian Schmaus]

Due the retirement of the proxied maintainer, the following packages are 
up for grabs:


dev-libs/cgreen
gnome-extra/nautilus-dropbox
sys-apps/thunderbolt-software-user-space

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: dev-lang/scala, dev-lang/mozart, dev-lang/mozart-stdlib, app-emacs/scala-mode

[Florian Schmaus]

On 27/07/2024 12.30, Maciej Barć wrote:

app-emacs/scala-mode


I would be against removing this pkg except that it is true that it 
depends on a Scala interpreter on runtime, very weird design choice.


FYI: app-emacs/scala-ts-mode may be an alternative.

@Volkmar: You may want to adjust the last-rite message so that it points 
out app-emacs/scala-ts-mode as alternative to app-emacs/scala-mode.


- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] java-utils-2.eclass: select java-config binary, prefer java-config over java-config-2

[Florian Schmaus]

This prepares the eclass for the transition from /usr/bin/java-config-2
to /usr/bin/java-config.

Starting with dev-java/java-config-2.3.3, the java-config utility is
installed as java-config and the java-config-2 compatibility symlink
will only be installed if the 'compat' USE flag is enabled (currently
the default).

Signed-off-by: Florian Schmaus 
---
 eclass/java-utils-2.eclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 8a062f2ad87e..559342068cc0 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -2723,7 +2723,13 @@ java-pkg_build-vm-from-handle() {
fi
 
for vm in ${JAVA_PKG_WANT_BUILD_VM}; do
-   if java-config-2 --select-vm=${vm} 2>/dev/null; then
+   local java_config
+   for java_config in java-config{,-2}; do
+   type -p ${java_config} >/dev/null && break
+   done
+   [[ -z ${java_config} ]] && die "No java-config binary in PATH"
+
+   if ${java_config} --select-vm=${vm} 2>/dev/null; then
echo ${vm}
return 0
fi
-- 
2.44.2

Re: [gentoo-dev] [PATCH v5] greadme.eclass: new eclass

[Florian Schmaus]

On 21/07/2024 10.26, Ulrich Mueller wrote:

On Tue, 16 Jul 2024, Florian Schmaus wrote:



Notes:
 - also show readme contents if FEATURES=nodoc


Good. :)


Thanks for your review.



--- /dev/null
+++ b/eclass/greadme.eclass
@@ -0,0 +1,257 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 


"Author:" is redundant when there's only a single author.


Applied locally.



+# @SUPPORTED_EAPIS: 8
+# @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
+# information for the user.  The content of README.gentoo will shown be
+# via elog messages either on fresh installations or if the contents of
+# the file have changed.  Furthermore, the README.gentoo file will be
+# installed under /usr/share/doc/${PF} for later consultation.
+#
+# This eclass was inspired by readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it only displays the doc file
+# contents if they have changed (unless GREADME_SHOW is set).
+# Secondly, it provides a convenient API to install the doc file via
+# stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   ...
+#   greadme_stdin <<-EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   ...
+#   if use foo; then
+# greadme_stdin --append <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# If the ebuild overrides the default pkg_preinst or respectively
+# pkg_postinst, then it must call greadme_pkg_preinst and
+# greadme_pkg_postinst explicitly.
+
+if [[ -z ${_GREADME_ECLASS} ]]; then
+_GREADME_ECLASS=1
+
+case ${EAPI} in
+   8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_REL_PATH="/usr/share/doc/${PF}/${_GREADME_FILENAME}"


These are internal variables and they're never set to anything else.
I also think that it is unlikely that "README.gentoo" would ever be
changed to anything else.

IMHO hardcoding it would improve readability. ("README.gentoo" makes it
immediately clear what is happening, while with ${_GREADME_FILENAME} one
must look up what the variable is.)


Applied locally.



+# @ECLASS_VARIABLE: GREADME_SHOW
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set to "yes" then unconditionally show the contents of the readme
+# file in pkg_postinst via elog. If set to "no", then do not show the
+# contents of the readme file, even if they have changed.
+
+# @ECLASS_VARIABLE: GREADME_AUTOFORMATTING_DISABLED


It is an input variable, so make it a (grammatical) command, e.g.
GREADME_DISABLE_AUTOFORMAT?


Applied locally.



+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, the readme file will not be automatically formatted.
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append
+   while [[ -n ${1} ]] && [[ ${1} == --* ]]; do
+   case ${1} in
+   --append)
+   append=1
+   shift
+   ;;
+   esac
+   done


Simply check for either no option, or one option that must be exactly
"--append". Everything else should be an error, i.e. not silent ignoring
of parameters. Something like this:

[[ ${1} = --append ]] && { append=1; shift; }
[[ $# -eq 0 ]] || die "${FUNCNAME[0]}: Bad parameters: $*"


Applied locally.



+
+   if [[ -n ${append} ]]; then
+   if [[ ! -f ${_GREADME_TMP_FILE} ]]; then
+   die "Gentoo README does not exist when trying to append to 
it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+greadme_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z ${input_doc_file} ]]; then
+   die "No file specified"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: _greadme_install_doc
+# @INTERNAL
+# @DESCRIPTION:
+# Installs the readme file from the temp directory into the im

[gentoo-dev] [PATCH 2/2] rebar3.eclass: add new eclass

[Florian Schmaus]

Add a new eclass for dev-util/rebar:3, based on the work of Anna
Vyalkova in ::guru (thanks!).

The Erlang/OTP ecosystem is moving to Rebar3. Upstreams start to drop
support for Rebar2, or at least consider it.

Signed-off-by: Florian Schmaus 
---
 eclass/rebar3.eclass | 194 +++
 1 file changed, 194 insertions(+)
 create mode 100644 eclass/rebar3.eclass

diff --git a/eclass/rebar3.eclass b/eclass/rebar3.eclass
new file mode 100644
index ..f6383b9c8cdd
--- /dev/null
+++ b/eclass/rebar3.eclass
@@ -0,0 +1,194 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: rebar3.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Amadeusz Żołnowski 
+# Anna (cybertailor) Vyalkova 
+# @SUPPORTED_EAPIS: 8
+# @PROVIDES: rebar-utils
+# @BLURB: Build Erlang/OTP projects using dev-util/rebar:3.
+# @DESCRIPTION:
+# An eclass providing functions to build Erlang/OTP projects using
+# dev-util/rebar:3.
+#
+# rebar is a tool which tries to resolve dependencies itself which is by
+# cloning remote git repositories. Dependent projects are usually expected to
+# be in sub-directory 'deps' rather than looking at system Erlang lib
+# directory. Projects relying on rebar usually don't have 'install' make
+# targets. The eclass workarounds some of these problems. It handles
+# installation in a generic way for Erlang/OTP structured projects.
+
+case ${EAPI} in
+   8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_REBAR3_ECLASS} ]]; then
+_REBAR3_ECLASS=1
+
+inherit edo rebar-utils
+
+RDEPEND="dev-lang/erlang:="
+DEPEND="${RDEPEND}"
+BDEPEND="
+   dev-util/rebar:3
+   >=sys-apps/gawk-4.1
+"
+
+# @ECLASS_VARIABLE: REBAR_PROFILE
+# @DESCRIPTION:
+# Rebar profile to use. Defaults to
+# 'default'.
+: "${REBAR_PROFILE:=default}"
+
+# @FUNCTION: _rebar_find_dep
+# @INTERNAL
+# @USAGE: 
+# @RETURN: 0 success, 1 dependency not found, 2 multiple versions found
+# @DESCRIPTION:
+# Find a Erlang package/project by name in Erlang lib directory. Project
+# directory is usually suffixed with version. It is matched to ''
+# or '-*'.
+_rebar_find_dep() {
+   local pn="${1}"
+   local p
+   local result
+
+   pushd "${EPREFIX}$(get_erl_libs)" >/dev/null || return 1
+   for p in ${pn} ${pn}-*; do
+   if [[ -d ${p} ]]; then
+   # Ensure there's at most one matching.
+   [[ ${result} ]] && return 2
+   result="${p}"
+   fi
+   done
+   popd >/dev/null || die
+
+   [[ ${result} ]] || return 1
+   echo "${result}"
+}
+
+# @FUNCTION: erebar3
+# @USAGE: 
+# @DESCRIPTION:
+# Run rebar with verbose flag. Die on failure.
+erebar3() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   (( $# > 0 )) || die "${FUNCNAME}: at least one target is required"
+
+   case ${1} in
+   eunit|ct)
+   local -x ERL_LIBS="." ;;
+   *)
+   local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)" ;;
+   esac
+
+   local -x HEX_OFFLINE=true
+   edo rebar3 "$@"
+}
+
+# @FUNCTION: rebar3_src_prepare
+# @DESCRIPTION:
+# Prevent rebar3 from fetching and compiling dependencies. Set version in
+# project description file if it's not set.
+#
+# Existence of rebar.config is optional, but file description file must exist
+# at 'src/${PN}.app.src'.
+rebar3_src_prepare() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   default
+   rebar_set_vsn
+
+   if [[ -f rebar.lock ]]; then
+   rm rebar.lock || die
+   fi
+
+   if [[ -f rebar.config ]]; then
+   rebar_disable_coverage
+   rebar_remove_deps
+   fi
+}
+
+# @FUNCTION: rebar3_src_configure
+# @DESCRIPTION:
+# Configure with ERL_LIBS set.
+rebar3_src_configure() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
+   default
+}
+
+# @FUNCTION: rebar3_src_compile
+# @DESCRIPTION:
+# Compile project with rebar3.
+rebar3_src_compile() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   erebar3 as "${REBAR_PROFILE}" release --all
+}
+
+# @FUNCTION: rebar3_src_test
+# @DESCRIPTION:
+# Run unit tests.
+rebar3_src_test() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   erebar3 eunit -v
+}
+
+# @FUNCTION: rebar3_install_lib
+# @USAGE: 
+# @DESCRIPTION:
+# Install BEAM files, include headers and native libraries.
+#
+# Function expects that project conforms to Erlang/OTP structure.
+rebar3_install_lib() {
+   debug-print-function ${FUNCNAME} "$

[gentoo-dev] [PATCH 1/2] rebar.eclass: factor out common functions into rebar-utils.eclass

[Florian Schmaus]

In preperation for rebar3.eclass, factor out common functions into 
rebar-utils.eclass.

Signed-off-by: Florian Schmaus 
---
 eclass/rebar-utils.eclass | 160 ++
 eclass/rebar.eclass   | 112 +-
 2 files changed, 163 insertions(+), 109 deletions(-)
 create mode 100644 eclass/rebar-utils.eclass

diff --git a/eclass/rebar-utils.eclass b/eclass/rebar-utils.eclass
new file mode 100644
index ..5657908eb8e9
--- /dev/null
+++ b/eclass/rebar-utils.eclass
@@ -0,0 +1,160 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: rebar-utils.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Amadeusz Żołnowski 
+# @SUPPORTED_EAPIS: 7 8
+# @BLURB: Auxiliary functions for using dev-util/rebar.
+# @DESCRIPTION:
+# This eclass provides a set of axiliary functions commonly needed
+# when building Erlang/OTP packages with rebar.
+
+case ${EAPI} in
+   7|8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_REBAR_UTILS_ECLASS} ]]; then
+_REBAR_UTILS_ECLASS=1
+
+# @ECLASS_VARIABLE: REBAR_APP_SRC
+# @DESCRIPTION:
+# Relative path to .app.src description file. Defaults to
+# 'src/${PN}.app.src'.
+: "${REBAR_APP_SRC:=src/${PN}.app.src}"
+
+# @FUNCTION: get_erl_libs
+# @RETURN: the path to Erlang lib directory
+# @DESCRIPTION:
+# Get the full path without EPREFIX to Erlang lib directory.
+get_erl_libs() {
+   echo "/usr/$(get_libdir)/erlang/lib"
+}
+
+# @FUNCTION: _rebar_find_dep
+# @INTERNAL
+# @USAGE: 
+# @RETURN: 0 success, 1 dependency not found, 2 multiple versions found
+# @DESCRIPTION:
+# Find a Erlang package/project by name in Erlang lib directory. Project
+# directory is usually suffixed with version. It is matched to ''
+# or '-*'.
+_rebar_find_dep() {
+   local pn="${1}"
+   local p
+   local result
+
+   pushd "${EPREFIX}$(get_erl_libs)" >/dev/null || return 1
+   for p in ${pn} ${pn}-*; do
+   if [[ -d ${p} ]]; then
+   # Ensure there's at most one matching.
+   [[ ${result} ]] && return 2
+   result="${p}"
+   fi
+   done
+   popd >/dev/null || die
+
+   [[ ${result} ]] || return 1
+   echo "${result}"
+}
+
+# @FUNCTION: rebar_disable_coverage
+# @USAGE: []
+# @DESCRIPTION:
+# Disable coverage in rebar.config. This is a workaround for failing coverage.
+# Coverage is not relevant in this context, so there's no harm to disable it,
+# although the issue should be fixed.
+rebar_disable_coverage() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local rebar_config="${1:-rebar.config}"
+
+   sed -e 's/{cover_enabled, true}/{cover_enabled, false}/' \
+   -i "${rebar_config}" \
+   || die "failed to disable coverage in ${rebar_config}"
+}
+
+# @FUNCTION: rebar_fix_include_path
+# @USAGE:  []
+# @DESCRIPTION:
+# Fix path in rebar.config to 'include' directory of dependent project/package,
+# so it points to installation in system Erlang lib rather than relative 'deps'
+# directory.
+#
+#  is optional. Default is 'rebar.config'.
+#
+# The function dies on failure.
+rebar_fix_include_path() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local pn="${1}"
+   local rebar_config="${2:-rebar.config}"
+   local erl_libs="${EPREFIX}$(get_erl_libs)"
+   local p
+
+   p="$(_rebar_find_dep "${pn}")" \
+   || die "failed to unambiguously resolve dependency of '${pn}'"
+
+   gawk -i inplace \
+   -v erl_libs="${erl_libs}" -v pn="${pn}" -v p="${p}" '
+/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
+   pattern = "\"(./)?deps/" pn "/include\"";
+   if (match($0, "{i,[[:space:]]*" pattern "[[:space:]]*}")) {
+   sub(pattern, "\"" erl_libs "/" p "/include\"");
+   }
+   print $0;
+   next;
+}
+1
+' "${rebar_config}" || die "failed to fix include paths in ${rebar_config} for 
'${pn}'"
+}
+
+# @FUNCTION: rebar_remove_deps
+# @USAGE: []
+# @DESCRIPTION:
+# Remove dependencies list from rebar.config and deceive build rules that any
+# dependencies are already fetched and built. Otherwise rebar tries to fetch
+# dependencies and compile them.
+#
+#  is optional. Default is 'rebar.config'.
+#
+# The function dies on failure.
+rebar_remove_deps() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local rebar_config="${1:-rebar.config}&q

[gentoo-dev] [PATCH v5] greadme.eclass: new eclass

[Florian Schmaus]

This new eclass includes various improvements over the existing
readme.gentoo-r1.eclass.

First, the content of README.gentoo will only be shown on new
installations or if it has changed between updates.

Second, it allows the composition of readme via bash's heredoc.

And finally, the eclass exports phase functions, which helps to reduce
the boilerplate code in many cases.

I would like to thank ulm for assistance with the eclass' code.

Signed-off-by: Florian Schmaus 
---

Notes:
- also show readme contents if FEATURES=nodoc

 eclass/greadme.eclass | 257 ++
 1 file changed, 257 insertions(+)
 create mode 100644 eclass/greadme.eclass

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
new file mode 100644
index ..4f0534200c1e
--- /dev/null
+++ b/eclass/greadme.eclass
@@ -0,0 +1,257 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 
+# @SUPPORTED_EAPIS: 8
+# @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
+# information for the user.  The content of README.gentoo will shown be
+# via elog messages either on fresh installations or if the contents of
+# the file have changed.  Furthermore, the README.gentoo file will be
+# installed under /usr/share/doc/${PF} for later consultation.
+#
+# This eclass was inspired by readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it only displays the doc file
+# contents if they have changed (unless GREADME_SHOW is set).
+# Secondly, it provides a convenient API to install the doc file via
+# stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   ...
+#   greadme_stdin <<-EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   ...
+#   if use foo; then
+# greadme_stdin --append <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# If the ebuild overrides the default pkg_preinst or respectively
+# pkg_postinst, then it must call greadme_pkg_preinst and
+# greadme_pkg_postinst explicitly.
+
+if [[ -z ${_GREADME_ECLASS} ]]; then
+_GREADME_ECLASS=1
+
+case ${EAPI} in
+   8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_REL_PATH="/usr/share/doc/${PF}/${_GREADME_FILENAME}"
+
+# @ECLASS_VARIABLE: GREADME_SHOW
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set to "yes" then unconditionally show the contents of the readme
+# file in pkg_postinst via elog. If set to "no", then do not show the
+# contents of the readme file, even if they have changed.
+
+# @ECLASS_VARIABLE: GREADME_AUTOFORMATTING_DISABLED
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, the readme file will not be automatically formatted.
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append
+   while [[ -n ${1} ]] && [[ ${1} == --* ]]; do
+   case ${1} in
+   --append)
+   append=1
+   shift
+   ;;
+   esac
+   done
+
+   if [[ -n ${append} ]]; then
+   if [[ ! -f ${_GREADME_TMP_FILE} ]]; then
+   die "Gentoo README does not exist when trying to append 
to it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+greadme_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z ${input_doc_file} ]]; then
+   die "No file specified"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: _greadme_install_doc
+# @INTERNAL
+# @DESCRIPTION:
+# Installs the readme file from the temp directory into the image.
+_greadme_install_doc() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local greadme="${_GREADME_TMP_FILE}"
+   if [[ ! "${GREADME_AUTOFORMATTING_DISABLED}" ]]; then
+   greadme="${_GREADME_TMP_FILE}".formatted
+
+   # Use fold, followed by a sed to s

[gentoo-dev] [PATCH 0/2] Introduce rebar3.eclass

[Florian Schmaus]

[This patchset was initially send with the wrong 'from' address to gentoo-dev@ 
and therefore never arrived at this mailing list]

The Erlang/OTP ecosystem, or at least parts of it, are moving away
from Rebar2 and towards Rebar3. While Rebar3 is packaged in Gentoo as
dev-util/rebar:3, the current rebar.eclass only supports building
projects with Rebar2.

This is becoming more and more of a problem.

For example, Ejabberd upstream is so kind to support building with
Rebar2 and Rebar3. However, I've been told by upstream that sooner or
later, probably sooner rather than later, support for Rebar2 will be
dropped.

We should prepare for this future and support Rebar3 via an eclass.

Fortunately, ::guru already has a rebar3.eclass, which was used as
starting point for this patchset. Not much needed to be changed, and
tests in an overlay showed that, for example, ejabberd could be simply
build by swapping rebar.eclass with rebar3.eclass (no further changes
where necessary).

I briefly considered adding support for Rebar3 to rebar.eclass,
however, after examining the eclass' code and considering the
consequences of doing so, I concluded that a new rebar3.eclass is the
best approach.

Florian Schmaus (2):
  rebar.eclass: factor out common functions into rebar-utils.eclass
  rebar3.eclass: add new eclass

 eclass/rebar-utils.eclass | 154 
 eclass/rebar.eclass   |  99 +-
 eclass/rebar3.eclass  | 204 ++
 3 files changed, 361 insertions(+), 96 deletions(-)
 create mode 100644 eclass/rebar-utils.eclass
 create mode 100644 eclass/rebar3.eclass

-- 
2.44.2

[gentoo-dev] [PATCH] texlive-common.eclass: Add TEXLIVE_SCRIPTS_W_FILE_EXT variable

[Florian Schmaus]

Some scripts are supposed to be installed with file extensions [1, 2]. Add
support for declaring those scripts in a new elcass variable
TEXLIVE_SCRIPTS_W_FILE_EXT.

Also use pure-bash functions to retrieve the basename and strip the file
extensions. And use "declare -l" to lowercase the value of 'trg',
instead of 'tr' [3].

1: https://tug.org/pipermail/tldistro/2024q3/000485.html
2: 
https://github.com/TeX-Live/texlive-source/blob/c087bab35570b1d5cb0afd272611a7a4ec3c9e38/texk/texlive/linked_scripts/Makefile.am#L332-L333
3: 
https://github.com/TeX-Live/texlive-source/blob/c087bab35570b1d5cb0afd272611a7a4ec3c9e38/texk/texlive/linked_scripts/Makefile.am#L330

Bug: https://bugs.gentoo.org/934975
Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 072581dde78e..36b90a327fde 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -42,6 +42,13 @@ _TEXLIVE_COMMON_ECLASS=1
 # @CODE
 : "${CTAN_MIRROR_URL:="https://mirrors.ctan.org"}";
 
+# @ECLASS_VARIABLE: TEXLIVE_SCRIPTS_W_FILE_EXT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set, contains a space separated list of script names that should be
+# linked including their file extensions, i.e., without stripping
+# potentially existing filename extensions from the link's name.
+
 # @FUNCTION: texlive-common_handle_config_files
 # @DESCRIPTION:
 # Has to be called in src_install after having installed the files in ${D}
@@ -160,8 +167,17 @@ etexlinks() {
 # Called by app-text/epspdf and texlive-module.eclass.
 dobin_texmf_scripts() {
while [[ ${#} -gt 0 ]] ; do
-   local trg
-   trg=$(basename "${1}" | sed 's,\.[^/]*$,,' | tr '[:upper:]' 
'[:lower:]')
+   # -l: TexLive target links are always lowercase.
+   local -l trg
+
+   # Get the basename of the script.
+   trg="${1##*/}"
+
+   # Only strip the filename extensions if trg is not listed in 
TEXLIVE_SCRIPTS_W_FILE_EXT.
+   if ! has "${trg}" ${TEXLIVE_SCRIPTS_W_FILE_EXT}; then
+   trg="${trg%.*}"
+   fi
+
einfo "Installing ${1} as ${trg} bin wrapper"
[[ -x ${ED}/usr/share/${1} ]] || die "Trying to install a non 
existing or non executable symlink to /usr/bin: ${1}"
dosym "../share/${1}" "/usr/bin/${trg}"
-- 
2.44.2

Re: [gentoo-dev] Re: [PATCH 2/2] rebar3.eclass: add new eclass

[Florian Schmaus]

On 15/07/2024 04.39, Eli Schwartz wrote:

On 7/10/24 11:38 PM, Anna (cybertailor) Vyalkova wrote:

On 2024-07-10 09:19, Florian Schmaus wrote:

From: Florian Schmaus 

Add a new eclass for dev-util/rebar:3, based on the work of Anna
Vyalkova in ::guru (thanks!).


There's also rebar3.eclass in lanodanOverlay, hereby CC-ing Haelwenn on
this.


The Erlang/OTP ecosystem is moving to Rebar3. Upstreams start to drop
support for Rebar2, or at least consider it.


I can't find the first part of this email thread, including the actual
submission of the eclass for review to the mailing list. Was this a
private conversation?


No it wasn't a private conversation. But unfortunately I've used the 
wrong 'from' address, my personal one instead of the @gentoo.org 
address, so the mails did not went through. However, I didn't notice it, 
since the mails appeared in my inbox (due to me being CC'ed).


I'll resend the patchset again, probably the first thing I'll do 
tomorrow. Sorry for the inconvenience.




I notice that it *has* been committed by Flow to ::gentoo already, and
your request for Haelwenn's feedback hasn't yet been answered.


I looked at the rebar3.eclass from the lanodanOverlay before pushing the 
new eclass, there seem to be no relevant differences from the one in 
::guru/::gentoo. Judging from the commit history of rebar3.eclass in 
lanodanOverlay and in ::guru, it appears that the one in ::guru used 
lanodanOverlay's rebar3.eclass as starting point.


- Flow





OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function

[Florian Schmaus]

On 16/06/2024 00.22, James Le Cuirot wrote:

On Sat, 2024-06-15 at 17:56 -0400, Ionen Wolkens wrote:

On Sat, Jun 15, 2024 at 08:14:34PM +0200, Florian Schmaus wrote:

On 13/06/2024 17.03, James Le Cuirot wrote:

Several Cargo-based ebuilds cannot use cargo_src_install for various
reasons and manually install binaries from within the target directory
instead. It is common to see `target/$(usex debug debug release)`, but
this lacks the target ABI when cross-compiling, so provide a helper
function.


Glad that someone is working on better cross-compilation support for
rust. :)

That said, many rust ebuilds generate shell completions by invoking the
just compiled binary in src_install(). This does not work out of the box
when cross-compiling.

Is there anything we can or should do about it (besides binfmt_misc)?
For example, asking the according projects to implement a mechanism to
extract the completions files from the binary without running it, or
have the build system generate the completion files as result of the build?


All I can think of without changing entirely how they're generated is:
1. (worst) either make a 2nd build using CBUILD (yeah no), or BDEPEND
on same-version self with a USE only when cross compiling
2. (lazy) skip completions w/ ewarn if tc-is-cross-compiler, just so
it at least won't break cross over completion files that the user
may not even care much about
3. generate them yourself with each releases and ship in a tarball,
works out for users but extra burden for maintainer over little
4. ask upstream to provide proper release tarballs if not already and
include pre-generated completions/docs/etc... so it's otherwise
only a problem with arbitrary git checkouts
(3+4 may possibly be more complicated if cargo features / USE change
  cli options and thus completion files)

For one of my ebuilds I went with better-than-nothing #2.


I've been doing this work for Flatcar, which doesn't use any of the packages
affected by this, but it does still concern me a little. Unfortunately, none
of the options are great.

I've seen #2 in one or two cases, and thanks for doing that.


FYI, it turns out that at least clap-rs has support to generate the 
completion files as part of the build process:


https://docs.rs/clap_complete/latest/clap_complete/generator/fn.generate_to.html

Maybe we could encourage projects to simply adjust their build.rs to 
generate the completion files. This would avoid inconsistent (Gentoo) 
package contents when cross compiling.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Arch Status and Future Plans

[Florian Schmaus]

Hi Arthur,

thanks for taking the time to write this mail.

On 25/06/2024 19.33, Arthur Zamarin wrote:

 x86 

Stable 32-bit arch. I'll be honest, I don't believe at all this should
be stable arch anymore.


I have the impression as well. The time to drop stable keywords for x86 
probably has come. But I always wonder if there is a x86 use-case we are 
not aware of. Therefore, if there is a group of x86 Gentoo users out 
there, then they should speak now and ideally elaborate a bit on their 
use case.




 hppa 

Sigh. Stable 64-bit arch. Out main Gentoo devbox died, and the second
one is always stuck compiling gcc for stage3 (a compilation takes 7
days). Here we have a fight in Arch Team. I prefer to destable it, Sam
prefers to stable it. This one is tough.


It's not a fight, just a disagreement, or is it? ;)

Probably time would be better invested in other architectures. However, 
I remember sam saying that he has a special interested in hppa and there 
is nothing better than working on stuff that you care about. So maybe 
just give stable hppa a try and re-evaluate the situation in a year or so?




 riscv 

Dev arch. I don't have much info on it, but I heard some mess with
riscv32 and riscv64, so maybe time to split it? I leave it to riscv arch
team, which works quite well, but I'll be happy to open discussion for it.


IMHO should be split into 32- and 64-bit keywords. Ideally we would also 
consider renaming the 'riscv' keyword to 'riscv64', but maybe this ship 
has sailed?


What about (64-bit) RISC-V becoming stable? Not sure if they time for it 
has already come, but it certainly will come. I might gain access to a 
64-core RISC-V system (Milk-V Pioneer), so I could probably help with 
riscv stabilization.


- Flow




OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] java-utils-2.eclass: add --runtime-only argument to java-pkg_getjars

[Florian Schmaus]

Some packages only need the jar at runtime, not at compile time. For
example https://bugs.gentoo.org/934659#c2

Bug: https://bugs.gentoo.org/934659
Signed-off-by: Florian Schmaus 
---
 eclass/java-utils-2.eclass | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index adbc5242053a..3c2d190c4c15 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -1137,7 +1137,7 @@ java-pkg_jarfrom() {
 }
 
 # @FUNCTION: java-pkg_getjars
-# @USAGE: [--build-only] [--with-dependencies] [,...]
+# @USAGE: [--build-only] [--runtime-only] [--with-dependencies] 
[,...]
 # @DESCRIPTION:
 # Get the classpath provided by any number of packages
 # Among other things, this can be passed to 'javac -classpath' or 'ant -lib'.
@@ -1157,6 +1157,7 @@ java-pkg_jarfrom() {
 # Parameters:
 #  --build-only - makes the jar(s) not added into package.env DEPEND line.
 #(assumed automatically when called inside src_test)
+#  --runtime-only - marks the jar(s) not added into package.env RDEPEND 
line.
 #  --with-dependencies - get jars also from requested package's 
dependencies
 #transitively.
 # $1 - list of packages to get jars from
@@ -1165,6 +1166,7 @@ java-pkg_jarfrom() {
 java-pkg_getjars() {
debug-print-function ${FUNCNAME} $*
 
+   local dep_constraint
local build_only=""
local deep=""
 
@@ -1173,6 +1175,9 @@ java-pkg_getjars() {
while [[ "${1}" == --* ]]; do
if [[ "${1}" = "--build-only" ]]; then
build_only="build"
+   dep_constraint="build"
+   elif [[ "${1}" = "--runtime-only" ]]; then
+   dep_constraint="runtime"
elif [[ "${1}" = "--with-dependencies" ]]; then
deep="--with-dependencies"
else
@@ -1191,7 +1196,7 @@ java-pkg_getjars() {
debug-print "${pkgs}:${jars}"
 
for pkg in ${pkgs//,/ }; do
-   java-pkg_ensure-dep "${build_only}" "${pkg}"
+   java-pkg_ensure-dep "${dep_constraint}" "${pkg}"
done
 
for pkg in ${pkgs//,/ }; do
@@ -1808,7 +1813,6 @@ java-pkg_ant-tasks-depend() {
fi
 }
 
-
 # @FUNCTION: ejunit_
 # @INTERNAL
 # @DESCRIPTION:
-- 
2.44.2

Re: [gentoo-dev] [PATCH 1/5] gui-libs/gtk: add a "poison" macro support to disable X/wayland

[Florian Schmaus]

On 23/06/2024 19.35, Eli Schwartz wrote:

Many packages perform automagic dependencies on gdk's backend
implementations by checking if the macro is defined and then using the
code it unlocks, rather than having a buildsystem option such as
-Dwayland=true.

It's unfeasible to patch every such package's source code to add
configure options and respect them. Instead add a truly filthy hack and
permit gtk itself to selectively show or hide the windowing system in
use.

Bug: https://bugs.gentoo.org/624960
Signed-off-by: Eli Schwartz 
---
  ...-poison-macro-to-hide-GDK_WINDOWING_.patch | 25 ++-
  gui-libs/gtk/gtk-4.12.5-r1.ebuild |  7 ++
  ...-4.12.5-r1.ebuild => gtk-4.12.5-r2.ebuild} |  9 ++-
  ...gtk-4.14.4.ebuild => gtk-4.14.3-r1.ebuild} |  7 ++
  ...gtk-4.14.3.ebuild => gtk-4.14.4-r1.ebuild} |  7 ++
  5 files changed, 42 insertions(+), 13 deletions(-)
  copy {x11-libs/gtk+ => 
gui-libs/gtk}/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch (86%)
  copy gui-libs/gtk/{gtk-4.12.5-r1.ebuild => gtk-4.12.5-r2.ebuild} (94%)
  rename gui-libs/gtk/{gtk-4.14.4.ebuild => gtk-4.14.3-r1.ebuild} (96%)
  rename gui-libs/gtk/{gtk-4.14.3.ebuild => gtk-4.14.4-r1.ebuild} (96%)

diff --git 
a/x11-libs/gtk+/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch 
b/gui-libs/gtk/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch
similarity index 86%
copy from 
x11-libs/gtk+/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch
copy to 
gui-libs/gtk/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch
index 9bba12f8445b..4e078610f8cb 100644
--- 
a/x11-libs/gtk+/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch
+++ 
b/gui-libs/gtk/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch
@@ -1,4 +1,4 @@
-From 25bdad805bb9e16032baf4480e9c1e432ddef49b Mon Sep 17 00:00:00 2001
+From 0537043f72ea1a634b101efa9e11cc0a22baaf71 Mon Sep 17 00:00:00 2001
  From: Eli Schwartz 
  Date: Wed, 19 Jun 2024 21:28:31 -0400
  Subject: [PATCH] gdk: add a "poison" macro to hide GDK_WINDOWING_*
@@ -34,10 +34,10 @@ Signed-off-by: Eli Schwartz 
   3 files changed, 15 insertions(+)
  
  diff --git a/gdk/gdkconfig.h.meson b/gdk/gdkconfig.h.meson

-index 7db19e0470..6bee207e94 100644
+index d5b48f3184..22baab52ae 100644
  --- a/gdk/gdkconfig.h.meson
  +++ b/gdk/gdkconfig.h.meson
-@@ -10,9 +10,16 @@
+@@ -10,10 +10,17 @@
   G_BEGIN_DECLS
   
   
@@ -46,21 +46,22 @@ index 7db19e0470..6bee207e94 100644

  +#endif
  +
   #mesondefine GDK_WINDOWING_BROADWAY
+ #mesondefine GDK_WINDOWING_MACOS
  +
  +#ifndef GENTOO_GTK_HIDE_WAYLAND
   #mesondefine GDK_WINDOWING_WAYLAND
  +#endif
  +
   #mesondefine GDK_WINDOWING_WIN32
- #mesondefine GDK_WINDOWING_QUARTZ
   
+ #mesondefine GDK_RENDERING_CAIRO

  diff --git a/gdk/wayland/gdkwayland.h b/gdk/wayland/gdkwayland.h
-index 2b79295add..5f0e9cfa81 100644
+index 846445910e..5d84619295 100644
  --- a/gdk/wayland/gdkwayland.h
  +++ b/gdk/wayland/gdkwayland.h
-@@ -25,6 +25,10 @@
- #ifndef __GDK_WAYLAND_H__
- #define __GDK_WAYLAND_H__
+@@ -24,6 +24,10 @@
+
+ #pragma once
   
  +#ifdef GENTOO_GTK_HIDE_WAYLAND

  +  #error "A Gentoo ebuild has hidden wayland and it cannot be used in this 
compilation unit. Please file a bug if you see this error."


Maybe this (and the other) should state where the bug is supposed to be 
filled, so that user's don't fill bugs at the wrong venue.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] readme.gentoo-r1.eclass: fix description of DISABLE_AUTOFORMATTING by s/fmt/fold/

[Florian Schmaus]

The autoformatting tool was switched from fmt to fold in
3f9cdecb18c6 ("Change formatting tool as discussed with Ulrich Müller in
bug #460050, thanks a lot to him for his help.") but the description of
the DISABLE_AUTOFORMATTING variable still talks about fmt being used.

See also https://bugs.gentoo.org/460050#c7

Signed-off-by: Florian Schmaus 
---
 eclass/readme.gentoo-r1.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
index 202ba31f4f70..35c3d3748550 100644
--- a/eclass/readme.gentoo-r1.eclass
+++ b/eclass/readme.gentoo-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: readme.gentoo-r1.eclass
@@ -34,8 +34,8 @@ esac
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # If non-empty, DOC_CONTENTS information will be strictly respected,
-# not getting it automatically formatted by fmt. If empty, it will
-# rely on fmt for formatting and 'echo -e' options to tweak lines a bit.
+# not getting it automatically formatted by fold. If empty, it will
+# rely on fold for formatting and 'echo -e' options to tweak lines a bit.
 
 # @ECLASS_VARIABLE: FORCE_PRINT_ELOG
 # @DEFAULT_UNSET
-- 
2.44.2

Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass

[Florian Schmaus]

On 19/06/2024 10.32, Ulrich Mueller wrote:

On Tue, 18 Jun 2024, Florian Schmaus wrote:



Any preference regarding the auto-formatting tool? The
readme.gentoo-r1.eclass uses fold, but fmt (both are in coreutils)
would probably also be an option (and has a --uniform-spacing option
;)).


readme.gentoo.eclass originally had fmt, but then switched to fold
following discussion in bug 460050 [1].


'fold' it is then. See

https://gitlab.com/flow/flow-s-ebuilds/-/commit/a9215c903a5434a65df1f2cae8409750d94eec74

Note that thanks to greadme.eclass *not* using a variable like 
DOC_CONTENTS, we can avoid some shell trickery that 
readme.gentoo-r1.eclass has to do [1].


- Flow

1: 
https://github.com/gentoo/gentoo/blob/f10decf0ec3bdf75618124534057df0a14b8c61b/eclass/readme.gentoo-r1.eclass#L63-L68


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass

[Florian Schmaus]

On 18/06/2024 20.21, Arthur Zamarin wrote:

On 18/06/2024 17.53, Florian Schmaus wrote:

Thanks for pointing this out. I think I understand now what arthur is
asking for:

src_install() {
     ...
     local DOC_CONTENTS="My README.Gentoo contents"
     readme.gentoo_create_doc
}

@arthur: is that right?


yes, exactly. Please, I suggest going over the existing eclass, you
might get surprised how much is supported already.


Given that I have been working on this for some time, I became very 
familiar with readme.gentoo-r1.eclass' implementation.




If so, then we could always add such an API to greadme.eclass too.
However, it appears that it simply would duplicate what can already be
done via greadme_stdin. Is there a compelling reason for such an API
that I am missing?

In any case, I wouldn't be opposed to implement something like this if
somebody asks for it.


I think you are looking at it from the wrong side. Thinking in this
"impl" possible now, I think *you* are duplicating work stuff which was
supported in readme.gentoo-r1. […]


Oh, greadme.eclass definitely duplicates functionality of 
readme.gentoo-r1.eclass…




What I'm trying to push you into, is understanding if you really need a
new eclass.


Yes, we have been there. Please look at the discussion in the thread 
"Improve readme.gentoo-r1.eclass" from two weeks ago, where it was 
attempted to do it without a new eclass.


The outcome was that here is no sensible way to implement all of the 
suggested behavior, that is now provided by greadme.eclass, into 
readme.gentoo-r1.eclass.


For this reason it became a new eclass. And again, I have no desire to 
bikeshed if the new eclass' name is greadme.eclass or 
readme.gentoo-r2.eclass. However, I do have a preference towards 
greadme.eclass, for the reasons explained before.


- Flow




OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass

[Florian Schmaus]

On 18/06/2024 16.02, Ulrich Mueller wrote:

On Tue, 18 Jun 2024, Florian Schmaus wrote:

Finally, unlike readme.gentoo-r1.elcass, this eclass does not need
to store the content of the readme in an environment variable. Not
having to store the content in an environment variable reduces the
pollution of the environment (sadly, this only refers to the process
environment).



I'll be honest, I never felt this is really needed? From looking at
the current -r1 eclass, you could define DOC_CONTENTS just before
invoking readme.gentoo_create_doc, so you could for example modify as
you want the message and use `local DOC_CONTENTS="..."`.



readme.gentoo-r1.eclass requires DOC_CONTENTS to be part of the
package's environment to show it later in readme.gentoo_print_elog(),
which is typically invoked in pkg_postinst(). If DOC_CONTENTS is local
to readme.gentoo_create_doc(), then it wont be able in pkg_postinst()
and can potentially not be obtained from the README.gentoo file
because that file may be compressed.



For greadme.eclass, the file is no longer compressed, therefore
greadme.eclass does not need to carry a variable in the package's
environment.


These are two different variables that must not be confused

>[DOC_CONTENTS vs README_GENTOO_DOC_VALUE].

Thanks for pointing this out. I think I understand now what arthur is 
asking for:


src_install() {
...
local DOC_CONTENTS="My README.Gentoo contents"
readme.gentoo_create_doc
}

@arthur: is that right?

If so, then we could always add such an API to greadme.eclass too. 
However, it appears that it simply would duplicate what can already be 
done via greadme_stdin. Is there a compelling reason for such an API 
that I am missing?


In any case, I wouldn't be opposed to implement something like this if 
somebody asks for it.




BTW, I like readme.gentoo-r1's autoformatting, because the message may
contain variables (like paths containing EPREFIX) that can expand to
different lengths.


Happy to add it.

Any preference regarding the auto-formatting tool? The 
readme.gentoo-r1.eclass uses fold, but fmt (both are in coreutils) would 
probably also be an option (and has a --uniform-spacing option ;)).



- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass

[Florian Schmaus]

Hi Arthur,

thanks for your mail.

On 16/06/2024 20.15, Arthur Zamarin wrote:

On 16/06/2024 18.51, Florian Schmaus wrote:

This new eclass includes various improvements over the existing
readme.gentoo-r1.eclass.


So, some weird question from me - why is it called greadme? I can
understand why you don't want to modify existing eclass, but why not
call it "readme.gentoo-r2.eclass"? This should make it a little less
confusing (cause I imagine folks asking - which to use. With -r2 we all
know which one is better).



It was already pointed out, but let me quote from my previous mail:

"""
Note that I choose greadme.eclass as the name for the new eclass for
aesthetic reasons. I find readme.gentoo-r2 a mouthful, and it leads to
an ugly combination of dot, hyphen, and underscores. However, if
anyone wants to have function names like
'readme.gentoo-r2_pkg_postinst', then we can go with that.
"""

Personally, I think it is better to have a forward pointer from the old 
elcass to the new eclass via @DEPRECATED, compared to going with 
readme.gentoo-r2. But it is certainly not a hill I want to die on.




First, the content of README.gento will only be shown on new
installations or if it has changed between updates.

Second, it allows the composition of readme via bash's heredoc.


Is it common usage you think? I've never felt the need for that.


It can't be common usage, because it is not directly supported yet. :)

And yes, I feel the need for that. Short heredocs have the advantage 
over stuff in FILESDIR that one can not forget about cleaning up 
references files in FILESDIR.


Using heredocs also makes it easier to conditionally compose the 
contents of README.gentoo. See the eclass' @CODE example.


But yes, the same would be possible with by composing the content via a 
variable. In the end, it is probably subjective what you prefer.




Third, it exports phase functions, which helps to reduce the boilerplate
code in many cases.


That actually sounds nice, but there is a caveat - if someone inherits
that eclass after other eclass phases, it might shadow those eclass
phase functions. There was a Check Request for pkgcheck to catch such
shadowed phase functions, but this still wasn't easy to implement, so we
still miss it. So I'm afraid this eclass being inherited last, causing
shadowed phases.


You are right, exported phase functions have their quirks in the 
multi-inherit case you describe.


But I am sorry, I am not sure how this is related to greadme exporting 
phase functions.


A dozen other eclasses also export phase functions. And this is, I 
presume, because even considering those quirks, exported phase functions 
are otherwise a sensible approach to reduce boilerplate.


In any case, if we want to decide that exporting phase functions is now 
an anti-pattern, then this would warrant a larger discussion and ideally 
some democratic vote.




Finally, unlike readme.gentoo-r1.elcass, this eclass does not need to
store the content of the readme in an environment variable. Not having
to store the content in an environment variable reduces the pollution of
the environment (sadly, this only refers to the process environment).


I'll be honest, I never felt this is really needed? From looking at the
current -r1 eclass, you could define DOC_CONTENTS just before invoking
readme.gentoo_create_doc, so you could for example modify as you want
the message and use `local DOC_CONTENTS="..."`.


readme.gentoo-r1.eclass requires DOC_CONTENTS to be part of the 
package's environment to show it later in readme.gentoo_print_elog(), 
which is typically invoked in pkg_postinst(). If DOC_CONTENTS is local 
to readme.gentoo_create_doc(), then it wont be able in pkg_postinst() 
and can potentially not be obtained from the README.gentoo file because 
that file may be compressed.


For greadme.eclass, the file is no longer compressed, therefore 
greadme.eclass does not need to carry a variable in the package's 
environment.




I'm not saying directly I'm against, don't understand me incorrectly.
What I want to see a current way to use -r1 eclass, which is
bad/ugly/boilerplate, and the new way with your eclass which is nicer. A
nice thing I took from mgorny's eclass changes, is giving an example
diff for a package, showing the new usage, diff, and "win points".



While for me personally, being able to use heredoc is a major advantage 
in the eclass' API design. This, and the reduced boilerplate due to 
exported phase function are the major improvements API wise.


So one could argue that, while there are improvements in the API, they 
are not that dramatic.


The actual big "win point" of greadme.eclass is that the content of the 
README.gentoo will be shown on new installations or *if the content 
changed*.


That means, if README.gentoo changes, probably due to new,

[gentoo-dev] [PATCH v4] greadme.eclass: new eclass

[Florian Schmaus]

This new eclass includes various improvements over the existing
readme.gentoo-r1.eclass.

First, the content of README.gento will only be shown on new
installations or if it has changed between updates.

Second, it allows the composition of readme via bash's heredoc.

Third, it exports phase functions, which helps to reduce the boilerplate
code in many cases.

Finally, unlike readme.gentoo-r1.elcass, this eclass does not need to
store the content of the readme in an environment variable. Not having
to store the content in an environment variable reduces the pollution of
the environment (sadly, this only refers to the process environment).

Signed-off-by: Florian Schmaus 
---
 eclass/greadme.eclass | 240 ++
 1 file changed, 240 insertions(+)
 create mode 100644 eclass/greadme.eclass

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
new file mode 100644
index ..ddbcc8e9858d
--- /dev/null
+++ b/eclass/greadme.eclass
@@ -0,0 +1,240 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 
+# @SUPPORTED_EAPIS: 8
+# @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
+# information for the user.  The content of README.gentoo will shown be
+# via elog messages either on fresh installations or if the contents of
+# the file have changed.  Furthermore, the README.gentoo file will be
+# installed under /usr/share/doc/${PF} for later consultation.
+#
+# This eclass was inspired by readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it only displays the doc file
+# contents if they have changed (unless GREADME_SHOW is set).
+# Secondly, it provides a convenient API to install the doc file via
+# stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   ...
+#   greadme_stdin <<-EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   ...
+#   if use foo; then
+# greadme_stdin --append <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# If the ebuild overrides the default pkg_preinst or respectively
+# pkg_postinst, then it must call greadme_pkg_preinst and
+# greadme_pkg_postinst explicitly.
+
+if [[ -z ${_GREADME_ECLASS} ]]; then
+_GREADME_ECLASS=1
+
+case ${EAPI} in
+   8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_REL_PATH="/usr/share/doc/${PF}/${_GREADME_FILENAME}"
+
+# @ECLASS_VARIABLE: GREADME_SHOW
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set to "yes" then unconditionally show the contents of the readme
+# file in pkg_postinst via elog. If set to "no", then do not show the
+# contents of the readme file, even if they have changed.
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append
+   while [[ -n ${1} ]] && [[ ${1} == --* ]]; do
+   case ${1} in
+   --append)
+   append=1
+   shift
+   ;;
+   esac
+   done
+
+   if [[ -n ${append} ]]; then
+   if [[ ! -f ${_GREADME_TMP_FILE} ]]; then
+   die "Gentoo README does not exist when trying to append 
to it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   if [[ -f ${_GREADME_TMP_FILE} ]]; then
+   die "Gentoo README already exists while trying to 
create it"
+   fi
+
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+greadme_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z ${input_doc_file} ]]; then
+   die "No file specified"
+   fi
+
+   if [[ -f ${_GREADME_TMP_FILE} ]]; then
+   die "Gentoo README already exists"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: _greadme_install_doc
+# @INTERNAL
+# @DESCRIPTION:
+# Installs the readme file from the temp directory into the image.
+_greadme_install_doc() {
+   debug-print-function ${FUNCNAME

Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function

[Florian Schmaus]

On 13/06/2024 17.03, James Le Cuirot wrote:

Several Cargo-based ebuilds cannot use cargo_src_install for various
reasons and manually install binaries from within the target directory
instead. It is common to see `target/$(usex debug debug release)`, but
this lacks the target ABI when cross-compiling, so provide a helper
function.


Glad that someone is working on better cross-compilation support for 
rust. :)


That said, many rust ebuilds generate shell completions by invoking the 
just compiled binary in src_install(). This does not work out of the box 
when cross-compiling.


Is there anything we can or should do about it (besides binfmt_misc)? 
For example, asking the according projects to implement a mechanism to 
extract the completions files from the binary without running it, or 
have the build system generate the completion files as result of the build?


- Flow





OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v3 0/1] greadme.eclass: new eclass

[Florian Schmaus]

On 13/06/2024 13.59, Ionen Wolkens wrote:

On Thu, Jun 13, 2024 at 10:39:24AM +0200, Florian Schmaus wrote:

Following up on the discussion of the last patchset, this
- moves the functionally into a new eclass, as adjusting the existing
   eclass to export new phase functions is not viable.
- excludes the README.gentoo from decompression, as all other
   presented approaches add complexity and cause additional disk space
   consumption. While on the other hand, README.gentoo files are
   typically very small because they should be suitable as pkg_postinst
   output, so ther is often not much gained by compressing them.
- adds a GREADME_SHOW show option, to manually override the behavior
   (as requested by ionen).


I don't recall requesting anything, or was it something i said on
IRC that I forgot about?


No, that seems to be a misunderstanding then. You wrote about the 
maintainer being able to choose when the readme is worth showing again 
and that a comparison would also "display it for minor style or typo

fixes.".

I thought that this was asking for a manual override. I am sorry, seems 
that I got that wrong.




Also I assume GREADME_SHOW is actually GREADME_FORCE?


It's actually the other way around. Latest HEAD of greadme.eclass has

# @ECLASS_VARIABLE: GREADME_SHOW
# @DEFAULT_UNSET
# @DESCRIPTION:
# If set to "yes" then unconditionally show the contents of the readme
# file in pkg_postinst via elog. If set to "no", then do not show the
# contents of the readme file, even if they have changed.

- Flow

Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

[Florian Schmaus]

On 13/06/2024 11.31, Ulrich Mueller wrote:

On Thu, 13 Jun 2024, Florian Schmaus wrote:

+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 
+# @SUPPORTED_EAPIS: 8
+# @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
+# information for the user.  The content of README.gentoo will shown be
+# via elog messages either on fresh installations or if the contents of
+# the file have changed.  Furthermore, the README.gentoo file will be
+# installed under /usr/share/doc/${PF} for later consultation.
+#
+# This eclass was inspired by readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it only displays the doc file
+# contents if they have changed (unless GREADME_FORCE_SHOW is set).
+# Secondly, it provides a convenient API to install the doc file via
+# stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   …


I'm not a big fan of using non-ASCII characters in places where they
aren't strictly necessary. Is there any particular advantage of "…"
over "..."? The latter is also less awkwardly spaced in teletype fonts.


Switched to "..."




+#   greadme_stdin <<-EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   …
+#   if use foo; then
+# greadme_stdin --apend <<-EOF


Typo?


Fixed, thanks!



+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# If the ebuild overrides the default pkg_preinst or respectively
+# pkg_postinst, then it must call greadme_pkg_preinst and
+# greadme_pkg_postinst explicitly.
+
+if [[ -z ${_GREADME_ECLASS} ]]; then
+_GREADME_ECLASS=1
+
+case ${EAPI} in
+   8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_DOC_DIR="usr/share/doc/${PF}"


It is somewhat unusual to call insinto or docompress with a relative
path. I'd use "/usr/share/doc/${PF}" here.


+_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}"


Why must this be a relative path? AFAICS it could be an absolute path in
everywhere it is used. (You even add an explicit slash in places like
${ED}/${_GREADME_REL_PATH}).


My idea was to denote relative paths by not including an initial slash 
(/). This allows to write "${ED}/${_GREADME_REL_PATH}" without a 
duplicate slash in the middle. I find


${ED}/${_GREADME_REL_PATH}"

more readable when compared to

${ED}${_GREADME_REL_PATH}"

which seems to be in-line with 
https://mgorny.pl/articles/the-ultimate-guide-to-eapi-7.html#d-ed-root-eroot-no-longer-have-a-trailing-slash


But maybe I misunderstand what you are suggesting. You want

_GREADME_DOC_DIR="/usr/share/doc/${PF}"

instead of

_GREADME_DOC_DIR="usr/share/doc/${PF}"

right? Then I'd also have to change to ${ED}${_GREADME_REL_PATH}", to 
avoid the double slash. :(




+
+# @ECLASS_VARIABLE: GREADME_FORCE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set, then uncondiionally show the contents of the readme file in
+# pkg_postinst via elog.
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append=false
+   while [[ -n ${1} ]] && [[ ${1} =~ --* ]]; do


$ [[ foo-bar =~ --* ]]; echo $?
0

This is not what is intended here, I guess?


Good catch, switched to [[ ${1} == --* ]].



+   case ${1} in
+   --append)
+   append=true
+   shift
+   ;;
+   esac
+   done
+
+   if $append; then


Please use the conventional coding style, i.e. ${append}.


Changed to [[ -n ${append} ]]





+   if [[ ! -f "${_GREADME_TMP_FILE}" ]]; then


Quotation marks inside [[ ]] are generally not necessary (also several
times below).


Dropped quotation marks inside [[ ]] everywhere.



+   die "Gentoo README does not exist when trying to append to 
it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists while trying to create 
it"
+   fi
+
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESC

Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

[Florian Schmaus]

On 13/06/2024 12.42, Ulrich Mueller wrote:

On Thu, 13 Jun 2024, Florian Schmaus wrote:

+_GREADME_DOC_DIR="usr/share/doc/${PF}"

It is somewhat unusual to call insinto or docompress with a relative
path. I'd use "/usr/share/doc/${PF}" here.


+_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}"

Why must this be a relative path? AFAICS it could be an absolute
path in
everywhere it is used. (You even add an explicit slash in places like
${ED}/${_GREADME_REL_PATH}).



My idea was to denote relative paths by not including an initial slash
(/). This allows to write "${ED}/${_GREADME_REL_PATH}" without a
duplicate slash in the middle. I find



${ED}/${_GREADME_REL_PATH}"



more readable when compared to



${ED}${_GREADME_REL_PATH}"


I think the variable would be renamed in that case, i.e.
${ED}${_GREADME_PATH} or ${ED}${_GREADME_ABS_PATH}.


which seems to be in-line with
https://mgorny.pl/articles/the-ultimate-guide-to-eapi-7.html#d-ed-root-eroot-no-longer-have-a-trailing-slash


This has examples like ${D}${EPREFIX}/usr/share/foo: All path variables
start with a slash, _don't_ end with a slash, and no slash between them
when concatenating.


But maybe I misunderstand what you are suggesting. You want



_GREADME_DOC_DIR="/usr/share/doc/${PF}"



instead of



_GREADME_DOC_DIR="usr/share/doc/${PF}"



right?


Correct.


Then I'd also have to change to ${ED}${_GREADME_REL_PATH}", to avoid
the double slash. :(


I see no problem with this.


Will change accordingly then.



+   while read -r line; do elog "${line}"; done < 
"${EROOT}/${_GREADME_REL_PATH}"

It is not guaranteed that the file exists in ${EROOT} at this point.
See FEATURES="nodoc" in make.conf(5).



Fair point. Fixed.


Well, it still won't display anything with FEATURES=nodoc. IIUC
readme.gentoo-r1.eclass works around the problem by saving the file
contents in an environment variable. (However, I see the problem that
even then you couldn't compare old vs new file contents.)


I'd assume this is readme.gentoo-r1.eclass working around the readme 
file being compressed, and by doing so, coincidentally being able to 
display the readme even if FEATURES=nodoc.


It appears we have now two options:
A) Just like readme.gentoo-r1, store the content in an environment
   variable , to be able to show the content (unconditionally) in case
   of FEATURES=nodoc
B) Live with the fact that we will not be able to show the content on
   FEATURES=nodoc (but document this accordingly).

I have no strong opinion, therefore I am happy about hearing peoples 
thoughts on this.


- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH v3 0/1] greadme.eclass: new eclass

[Florian Schmaus]

Following up on the discussion of the last patchset, this
- moves the functionally into a new eclass, as adjusting the existing
  eclass to export new phase functions is not viable.
- excludes the README.gentoo from decompression, as all other
  presented approaches add complexity and cause additional disk space
  consumption. While on the other hand, README.gentoo files are
  typically very small because they should be suitable as pkg_postinst
  output, so ther is often not much gained by compressing them.
- adds a GREADME_SHOW show option, to manually override the behavior
  (as requested by ionen).

Note that I choose greadme.eclass as the name for the new eclass for
aesthetic reasons. I find readme.gentoo-r2 a mouthful, and it leads to
an ugly combination of dot, hyphen, and underscores. However, if
anyone wants to have function names like
'readme.gentoo-r2_pkg_postinst', then we can go with that.

Florian Schmaus (1):
  greadme.eclass: new eclass

 eclass/greadme.eclass | 223 ++
 1 file changed, 223 insertions(+)
 create mode 100644 eclass/greadme.eclass

-- 
2.44.2

[gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

[Florian Schmaus]

This new eclass includes various improvements over the existing
readme.gentoo-r1.eclass.

First, the content of README.gento will only be shown on new
installations or if it has changed between updates.

Second, it allows the composition of readme via bash's heredoc.

Third, it exports phase functions, which helps to reduce the boilerplate
code in many cases.

Finally, unlike readme.gentoo-r1.elcass, this eclass does not need to
store the content of the readme in an environment variable. Not having
to store the content in an environment variable reduces the pollution of
the environment (sadly, this only refers to the process environment).

Signed-off-by: Florian Schmaus 
---
 eclass/greadme.eclass | 223 ++
 1 file changed, 223 insertions(+)
 create mode 100644 eclass/greadme.eclass

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
new file mode 100644
index ..f26e939df206
--- /dev/null
+++ b/eclass/greadme.eclass
@@ -0,0 +1,223 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 
+# @SUPPORTED_EAPIS: 8
+# @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
+# information for the user.  The content of README.gentoo will shown be
+# via elog messages either on fresh installations or if the contents of
+# the file have changed.  Furthermore, the README.gentoo file will be
+# installed under /usr/share/doc/${PF} for later consultation.
+#
+# This eclass was inspired by readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it only displays the doc file
+# contents if they have changed (unless GREADME_FORCE_SHOW is set).
+# Secondly, it provides a convenient API to install the doc file via
+# stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   …
+#   greadme_stdin <<-EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   …
+#   if use foo; then
+# greadme_stdin --apend <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# If the ebuild overrides the default pkg_preinst or respectively
+# pkg_postinst, then it must call greadme_pkg_preinst and
+# greadme_pkg_postinst explicitly.
+
+if [[ -z ${_GREADME_ECLASS} ]]; then
+_GREADME_ECLASS=1
+
+case ${EAPI} in
+   8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_DOC_DIR="usr/share/doc/${PF}"
+_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}"
+
+# @ECLASS_VARIABLE: GREADME_FORCE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set, then uncondiionally show the contents of the readme file in
+# pkg_postinst via elog.
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append=false
+   while [[ -n ${1} ]] && [[ ${1} =~ --* ]]; do
+   case ${1} in
+   --append)
+   append=true
+   shift
+   ;;
+   esac
+   done
+
+   if $append; then
+   if [[ ! -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README does not exist when trying to append 
to it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists while trying to 
create it"
+   fi
+
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+greadme_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z "${input_doc_file}" ]]; then
+   die "No file specified"
+   fi
+
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: _greadme_install_doc
+# @INTERNAL
+# @DESCRIPTION:
+# Installs the readme file from the temp directory into the image.
+_greadme_install_doc() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+  

Re: [gentoo-dev] TeX Live 2023 stabilization imminent

[Florian Schmaus]

On 10/06/2024 17.01, matoro wrote:
Hi Flow, I went ahead and started reviewing this bug for the remaining 
arches.  However when I ran it, I discovered that tests do not seem to 
run on the 2023 version, where they were previously being run on the 
2021 version.

Thanks for pointing this out.

Looks like we accidentally broke src_test() in the 2023 versions. Now 
fixed. All, but the three zapped tests, are green for me (or 
automatically skipped).


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] TeX Live 2023 stabilization imminent

[Florian Schmaus]

After many months of work, the stabilization of TeX Live 2023 is imminent.

I would first like to thank everyone who contributed, reported bugs, and 
helped to make this happen. Special thanks goes to negril for providing 
the initial prototype ebuilds that helped to get this going.


TeX Live 2023 got a major overhaul and new tooling. User-facing 
highlights include

- all binlinks and binscripts are now properly installed and in PATH
- all manpages are now installed (due to upstream's design, only if USE=doc)
- tlmgr is now available (but forced into user mode, as done by other 
distributions)

- the tlpdb is dynamically created, texdoc works (if USE=doc)

While I do not have any reason to believe that there are remaining 
issues lurking in TeX Live 2023, I would like to use this as opportunity 
to encourage advanced users to switch to TeX Live 2023 right now. Please 
report issues that come up.


The re-keywording of TeX Live 2023 is ongoing in
 https://bugs.gentoo.org/932752.
Unfortunately two stable arches are lacking: arm and hppa. It would be 
great If the respective arch teams could prioritize the keywording. 
Otherwise, the arches may missing out on the upcoming stabilization request.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)

[Florian Schmaus]

On 04/06/2024 19.45, Ulrich Mueller wrote:

On Tue, 04 Jun 2024, Florian Schmaus wrote:



Both is fine with me.



That said, many filesystem support inline data. If I am not mistaken,
then its even enabled by default for xfs (which we recommend in the
handbook) and btrfs. Also some README.gentoo files become suitable for
inlining after compression (btrfs' limit is 2048 bytes).


I see 48 README.gentoo* files on my system here, and the _uncompressed_
size of the largest of them (belonging to www-client/firefox) is 1238
bytes. So, by your metric all of them could be inlined even without
compressing them. 14 of the 48 files aren't even compressed because
their size is below Portage's size limit (which is 128 bytes IIRC).


Fair point. On your system all README.gentoo could be inlined by btrfs.

You also say that compression does not make a difference for all files 
on your system, as a whole 4 KiB block will likely be used anyway. We 
agree in the point that most README.gentoo files are small, because they 
should be suitable as output in pkg_postinst.


Doesn't this tell us that excluding README.gentoo from compression we be 
ok-ish?




Considering this, the 4-byte hash file is superior under the right
circumstances when compared to excluding README.gentoo from
compression. And I could imagine that the circumstances are right for
many of our users.


I very much doubt this.

In any case, the above size considerations aren't important. My main
point is that the code is getting way too complicated for the simple
task of printing a few lines in pkg_postinst.


Agreed. Even though you oversimplify the task. It's not just printing 
and installing a readme file. It's also comparing the contents of the 
current file with the new one.


And yes, "docompress -x README.gentoo" would make the code mch 
simpler. And, as additional benefit, would help us get rid of storing 
the whole content of the readme in a environment variable (which is what 
readme.gentoo-r1.elcass currently does). Hence this is what was 
previously suggested, until people complained about it.


It seems like we are going in circles… :(

- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)

[Florian Schmaus]

On 02/06/2024 20.24, Ulrich Mueller wrote:

Installing another file just for the sake of avoiding "docompress -x"
doesn't solve the problem but makes it worse, IMHO. Rather don't
compress README.gentoo then.


Both is fine with me.

That said, many filesystem support inline data. If I am not mistaken, 
then its even enabled by default for xfs (which we recommend in the 
handbook) and btrfs. Also some README.gentoo files become suitable for 
inlining after compression (btrfs' limit is 2048 bytes).


Considering this, the 4-byte hash file is superior under the right 
circumstances when compared to excluding README.gentoo from compression. 
And I could imagine that the circumstances are right for many of our users.




(Also, I still don't understand the argument about different compress
programs. That's not likely to happen very often. You could go for best
effort there, and if it fails, consider the files as different. There's
no need for exact science when the only thing that can happen is
additional output.)


I fear this would open a can of worms. Which compressions algorithms do 
you support? What if someone wants to add another compression algorithm? 
What if there are multiple candidates that can be used to decompress the 
file? How large do we want the opportunistic decompression function 
allow to grow?


Last but not least, opportunistic approaches are fine if you have no 
other choice. But we have the option to make it reliable.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)

[Florian Schmaus]

On 02/06/2024 18.28, Ulrich Mueller wrote:

On Sun, 02 Jun 2024, Eli Schwartz wrote:



Per the commit message, the old readme and the new readme can have the
same contents, but be compressed by different compressors on the live
system vs the image, and/or a compressor with unstable algorithms,
and/or one that isn't installed at the time of merging.



Given you've explicitly rejected disabling compression, I don't quite
see how you can have your cake and eat it too.


How is installing another file (4 KiB on many file systems) an
improvement over disabling compression for README.gentoo itself?


The hash file's size is constant, unlike README.gentoo, which even could 
theoretically be bigger than 4 KiB.  And, as you indicated, some 
filesystems will even inline the 4-bytes into the inode.


But actually, I would rather simply exclude README.gentoo from 
decompression. This would make the eclass simpler. Many (most?) 
README.gentoo files are below 4 KiB uncompressed, hence the same 
argument could be made that compressing those files does not buy us much 
usable disk space.


However, you argued against using "docompress -x" in your mail from 
2024-10-01.


Frankly, I don't care much. But I am a little bit tired of reading the 
same elog output over and over again. Nearly daily I go through all elog 
messages on my machines, and a large fraction is just repetitive, mainly 
caused by readme.gentoo-r1.eclass (and others who should be using 
readme.gentoo-r1.eclass but do not).


I have a hard time not limiting myself to ewarn and higher messages. 
Quite likely other Gentoo users are in the same situation. 
Unfortunately, it seems likely that I would then miss valuable information.


Therefore we should take action. Which is either not showing 
GENTOO.readme upon updates *or* only showing it only if it changes when 
updating a package.


The latter is what this patchset tries to achieve.

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] Improve readme.gentoo-r1.eclass

[Florian Schmaus]

On 02/06/2024 18.40, Ulrich Mueller wrote:

On Sun, 02 Jun 2024, Florian Schmaus wrote:



IMHO that's a very bad idea and will probably break ebuilds that rely
on the current behaviour.



I pondered about this and its one of the reasons I'd rather start with
a fresh eclass.



That said, worst case scenario I could came up with is that the elog
message is printed twice. And this is also only the case if the ebuild
has readme.gentoo_print_elog *not* in pkg_postinst. However, the
readme.gentoo-r1.eclass documentation suggests you to put it in
pkg_postinst.



And if an ebuild has readme.gentoo_print_elog *in* pkg_postinst, which
should be true for nearly all ebuilds currently inheriting
readme.gentoo-r1, then you don't use the newly exported pkg_postinst
function (and the outcome of the exproted pkg_preinst is simply
ignored).



Bottom line is: exporting the functions should do no harm.


It would break most ebuilds that inherit elisp and readme.gentoo-r1,
because elisp_pkg_postinst would no longer be called.


You are right. I had not considered this case. Interesting.

We could maybe define a pre-inherit variable 
README_GENTOO_EXPORT_PHASE_FUNCS to opt-in to the new behavior. Is there 
any prior art regarding this?


However, it feels like my hunch was right and this is just another 
argument why it should be a new eclass.


But if you have any suggestions on how to best deal with this, then 
please let me know.


- Flow




OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)

[Florian Schmaus]

On 02/06/2024 17.34, Ulrich Mueller wrote:

On Sun, 02 Jun 2024, Florian Schmaus wrote:



+   (
+   insinto "${_GREADME_DOC_DIR}"
+
+   doins "${_GREADME_TMP_FILE}"
+   cksum --raw "${_GREADME_TMP_FILE}" | newins - 
"${_GREADME_HASH_FILENAME}"
+   assert
+   )


Why do you need that hash file? The old README file exists on the
system, so couldn't you just compare the new one with it?


As Eli wrote and as I tried to make clear in the commit message (but 
probably failed), there is unfortunately no reliable way to decompress 
the two, most likely, compressed README.gentoo files in pkg_preinst. 
Nothing guarantees that the decompressor is available at the time 
pkg_preinst runs.


And even if we would ignore that, and try to opportunistically 
decompress the files, then it is far from trivial to select the right 
decompressor. I've looked in unpacker.eclass, which has some magic for 
that, but only for the algorithms not required by PMS.


Hence I am glad we came up (I think it was mostly Sam) with the 
hash-based approach, as it avoids having to deal with decompressing the 
files.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] Improve readme.gentoo-r1.eclass

[Florian Schmaus]

On 02/06/2024 17.25, Ulrich Mueller wrote:

On Sun, 02 Jun 2024, Florian Schmaus wrote:



Note that this changes readme.gentoo-r1.eclass to export phase
functions when it previously did not.


IMHO that's a very bad idea and will probably break ebuilds that rely
on the current behaviour.


I pondered about this and its one of the reasons I'd rather start with a 
fresh eclass.


That said, worst case scenario I could came up with is that the elog 
message is printed twice. And this is also only the case if the ebuild 
has readme.gentoo_print_elog *not* in pkg_postinst. However, the 
readme.gentoo-r1.eclass documentation suggests you to put it in 
pkg_postinst.


And if an ebuild has readme.gentoo_print_elog *in* pkg_postinst, which 
should be true for nearly all ebuilds currently inheriting 
readme.gentoo-r1, then you don't use the newly exported pkg_postinst 
function (and the outcome of the exproted pkg_preinst is simply ignored).


Bottom line is: exporting the functions should do no harm.


> (Also, readme.gentoo.eclass used to export phase functions, which was
> removed in -r1. So you should have a good rationale for reverting this.)

I talked with pacho about this. The background back then was 
https://bugs.gentoo.org/520094, but this about src_install. At the end 
of the discussion with pacho, we both came to the conclusion that 
exporting pkg_preinst and pkg_postinst is not a problem.


Bottom line here is: eclasses exporting phase functions is not uncommon. 
I do not see any issue in this case, do you?


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 4/4] readme.gentoo-r1.eclass: add readme.gentoo_file()

[Florian Schmaus]

The new readme.gentoo_file() function provided more flexibility from
where the readme file is obtained, compared to the existing methods.

Signed-off-by: Florian Schmaus 
---
 eclass/readme.gentoo-r1.eclass | 21 +
 1 file changed, 21 insertions(+)

diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
index db7fa0c47077..619f3eaa8fbf 100644
--- a/eclass/readme.gentoo-r1.eclass
+++ b/eclass/readme.gentoo-r1.eclass
@@ -110,6 +110,27 @@ readme.gentoo_stdin() {
readme.gentoo_create_doc
 }
 
+# @FUNCTION: readme.gentoo_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+readme.gentoo_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z "${input_doc_file}" ]]; then
+   die "No file specified"
+   fi
+
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die "Failed to copy 
${input_doc_file}"
+
+   readme.gentoo_create_doc
+}
+
 # @FUNCTION: readme.gentoo_create_doc
 # @DESCRIPTION:
 # Create doc file with ${DOC_CONTENTS} variable (preferred) and, if not set,
-- 
2.44.1

[gentoo-dev] [PATCH 3/4] readme.gentoo-r1.eclass: add readme.gentoo_stdin()

[Florian Schmaus]

Add a new function readme.gentoo_stdin() that consumes the content of
README.gentoo from stdin. In many cases, this is a supperiour method to
construct readme, compared to the eclass' DOC_CONTENTS approach.

Signed-off-by: Florian Schmaus 
---
 eclass/readme.gentoo-r1.eclass | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
index 078077241944..db7fa0c47077 100644
--- a/eclass/readme.gentoo-r1.eclass
+++ b/eclass/readme.gentoo-r1.eclass
@@ -14,6 +14,22 @@
 # shown at first package installation and a file for later reviewing will be
 # installed under /usr/share/doc/${PF}
 #
+# @CODE
+# inherit readme.gentoo-r1
+#
+# src_install() {
+#   …
+#   readme.gentoo_stdin <<-EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   …
+#   if use foo; then
+# readme.gentoo_stdin --apend <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
 #
 # You need to call readme.gentoo_create_doc in src_install phase if you
 # use DOC_CONTENTS or obtain the readme from FILESIDR.
@@ -59,6 +75,41 @@ _GREADME_DOC_DIR="usr/share/doc/${PF}"
 _GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}"
 _GREADME_HASH_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_HASH_FILENAME}"
 
+# @FUNCTION: readme.gentoo_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+readme.gentoo_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append=false
+   while [[ -n ${1} ]] && [[ ${1} =~ --* ]]; do
+   case ${1} in
+   --append)
+   append=true
+   shift
+   ;;
+   esac
+   done
+
+   if $append; then
+   if [[ ! -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README does not exist when trying to append 
to it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists while trying to 
create it"
+   fi
+
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   readme.gentoo_create_doc
+}
+
 # @FUNCTION: readme.gentoo_create_doc
 # @DESCRIPTION:
 # Create doc file with ${DOC_CONTENTS} variable (preferred) and, if not set,
-- 
2.44.1

[gentoo-dev] [PATCH 2/4] readme.gentoo-r1.eclass: use _GREADME_TMP_FILE in existing code

[Florian Schmaus]

The previous commit introduced _GREADME_TMP_FILE. This commit changes
the existing code to use this variable.

Signed-off-by: Florian Schmaus 
---
 eclass/readme.gentoo-r1.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
index 2a79911cafbf..078077241944 100644
--- a/eclass/readme.gentoo-r1.eclass
+++ b/eclass/readme.gentoo-r1.eclass
@@ -70,20 +70,20 @@ readme.gentoo_create_doc() {
 
if [[ -n "${DOC_CONTENTS}" ]]; then
if [[ -n "${DISABLE_AUTOFORMATTING}" ]]; then
-   echo "${DOC_CONTENTS}" > "${T}"/README.gentoo || die
+   echo "${DOC_CONTENTS}" > "${_GREADME_TMP_FILE}" || die
else
local saved_flags=$-
set -f  # disable filename 
expansion in echo arguments
echo -e ${DOC_CONTENTS} | fold -s -w 70 \
-   | sed 's/[[:space:]]*$//' > "${T}"/README.gentoo
+   | sed 's/[[:space:]]*$//' > 
"${_GREADME_TMP_FILE}"
assert
set +f -${saved_flags}
fi
elif [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]]; then
-   cp "${FILESDIR}/README.gentoo-${SLOT%/*}" "${T}"/README.gentoo 
|| die
+   cp "${FILESDIR}/README.gentoo-${SLOT%/*}" 
"${_GREADME_TMP_FILE}" || die
elif [[ -f "${FILESDIR}/README.gentoo${README_GENTOO_SUFFIX}" ]]; then
-   cp "${FILESDIR}/README.gentoo${README_GENTOO_SUFFIX}" 
"${T}"/README.gentoo || die
-   else
+   cp "${FILESDIR}/README.gentoo${README_GENTOO_SUFFIX}" 
"${_GREADME_TMP_FILE}" || die
+   elif [[ ! -f "${_GREADME_TMP_FILE}" ]]; then
die "You are not specifying README.gentoo contents!"
fi
 
-- 
2.44.1

[gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)

[Florian Schmaus]

Improve the user experience of readme.gentoo-r1.eclass by reducing the
number of messages presented to the user upon emerge. We reduce the
number of messages by only showing the contents of README.gentoo *if
they have changed* (or on fresh installations).

To be able to detect if the content has changed, the eclass now records
the 4-byte CRC value of README.gentoo. Upon installation, this 4-byte
value is compared. It is necessary to indirectly compare the content, as
README.gentoo is installed via dodoc, which is subject to docdir
compression, and there is no guarantee that we will be able to
uncompress the live system's version of README.gentoo (let alone that it
is not trivial to find a suitable decompressor candidate).

Signed-off-by: Florian Schmaus 
---
 eclass/readme.gentoo-r1.eclass | 124 -
 1 file changed, 108 insertions(+), 16 deletions(-)

diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
index 202ba31f4f70..2a79911cafbf 100644
--- a/eclass/readme.gentoo-r1.eclass
+++ b/eclass/readme.gentoo-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: readme.gentoo-r1.eclass
@@ -14,8 +14,11 @@
 # shown at first package installation and a file for later reviewing will be
 # installed under /usr/share/doc/${PF}
 #
-# You need to call readme.gentoo_create_doc in src_install phase and
-# readme.gentoo_print_elog in pkg_postinst
+#
+# You need to call readme.gentoo_create_doc in src_install phase if you
+# use DOC_CONTENTS or obtain the readme from FILESIDR.
+#
+# Note that this eclass exports pkg_preinst and pkg_postinst functions.
 
 if [[ -z ${_README_GENTOO_ECLASS} ]]; then
 _README_GENTOO_ECLASS=1
@@ -47,6 +50,15 @@ esac
 # If you want to specify a suffix for README.gentoo file please export it.
 : "${README_GENTOO_SUFFIX:=""}"
 
+_GREADME_FILENAME="README.gentoo"
+_GREADME_HASH_FILENAME=".${_GREADME_FILENAME}.hash"
+
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+
+_GREADME_DOC_DIR="usr/share/doc/${PF}"
+_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}"
+_GREADME_HASH_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_HASH_FILENAME}"
+
 # @FUNCTION: readme.gentoo_create_doc
 # @DESCRIPTION:
 # Create doc file with ${DOC_CONTENTS} variable (preferred) and, if not set,
@@ -75,11 +87,20 @@ readme.gentoo_create_doc() {
die "You are not specifying README.gentoo contents!"
fi
 
-   ( # subshell to avoid pollution of calling environment
-   docinto .
-   dodoc "${T}"/README.gentoo
-   ) || die
-   README_GENTOO_DOC_VALUE=$(< "${T}/README.gentoo")
+   # subshell to avoid pollution of calling environment
+   (
+   insinto "${_GREADME_DOC_DIR}"
+
+   doins "${_GREADME_TMP_FILE}"
+   cksum --raw "${_GREADME_TMP_FILE}" | newins - 
"${_GREADME_HASH_FILENAME}"
+   assert
+   )
+
+   # Save the readme contents in an variable, so that it can be shown ins 
pkg_postinst().
+   _GREADME_CONTENTS=$(< "${_GREADME_TMP_FILE}")
+
+   # Exclude the 4-byte hash file from compression.
+   docompress -x "${_GREADME_HASH_REL_PATH}"
 }
 
 # @FUNCTION: readme.gentoo_print_elog
@@ -96,15 +117,86 @@ readme.gentoo_create_doc() {
 readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} "${@}"
 
-   if [[ -z "${README_GENTOO_DOC_VALUE}" ]]; then
-   die "readme.gentoo_print_elog invoked without matching 
readme.gentoo_create_doc call!"
-   elif ! [[ -n "${REPLACING_VERSIONS}" ]] || [[ -n "${FORCE_PRINT_ELOG}" 
]]; then
-   echo -e "${README_GENTOO_DOC_VALUE}" | while read -r ELINE; do 
elog "${ELINE}"; done
-   elog ""
-   elog "(Note: Above message is only printed the first time 
package is"
-   elog "installed. Please look at 
${EPREFIX}/usr/share/doc/${PF}/README.gentoo*"
-   elog "for future reference)"
+   if ! [[ -n "${REPLACING_VERSIONS}" ]] || [[ -n "${FORCE_PRINT_ELOG}" 
]]; then
+   _GREADME_SHOW="force"
+   readme.gentoo-r1_pkg_postinst
fi
 }
 
+# @FUNCTION: readme.gentoo_pkg_preinst
+# @DESCRIPTION:
+# Performs checks like comparing the readme doc from the image with a
+# potentially existing one in the live system.
+readme.gentoo-r1_pkg_preinst() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   if [[ -z ${REPLACING_VERSIONS} ]]; then
+   _GREADME_SHOW="fresh-install"
+   return
+   fi
+
+   l

[gentoo-dev] [PATCH 0/4] Improve readme.gentoo-r1.eclass

[Florian Schmaus]

Following up on the comments of the last patchset, this revision
incorporates the functionality of the initially proposed
greadme.eclass into the existing readme.gentoo-r1.eclass. While this
misses the chance to get rid of some ballast of the existing eclass,
people asked to extend the existing eclass instead of starting fresh.

As a quick reminder, those changes aim to improve the user experience
of readme.gentoo-r1.eclass by reducing the amount of messages
presented to the user upon emerge. This is achieved by only showing
the contents of README.gentoo *if they have changed* (or on fresh
installations).

The previous revision was criticized for using "docompress -x
README.gentoo", i.e., excluding README.gentoo from being
compressed. However, exclusion from compression is necessary to
reliably detect if the contents have changed.

After discussing this with others, we came up with the following
compromise that should be acceptable by everyone.

Instead of excluding the whole README.eclass from compression, we use
chksum to create the 4-byte CRC value of the file. The eclass then
uses the existing 4-byte value and compares it with the 4-byte value
in the package's image directory to determine if the contents of
README.gentoo have changed.

I would like to thank Sam for the helpful comments that led to the
resulting design.

Note that this changes readme.gentoo-r1.eclass to export phase
functions when it previously did not.
Finally, I'd like to (restate) my concern that updating the existing
eclass, instead of starting fresh with a new eclass, misses the chance
to eliminate some ballast.


Florian Schmaus (4):
  readme.gentoo-r1.eclass: display readme if content changed (or fresh
install)
  readme.gentoo-r1.eclass: use _GREADME_TMP_FILE in existing code
  readme.gentoo-r1.eclass: add readme.gentoo_stdin()
  readme.gentoo-r1.eclass: add readme.gentoo_file()

 eclass/readme.gentoo-r1.eclass | 206 +
 1 file changed, 185 insertions(+), 21 deletions(-)

-- 
2.44.1

[gentoo-dev] [PATCH] 2024-06-05-texlive-2023-bump: add news item

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 .../2024-06-05-texlive-2023-bump.en.txt   | 34 +++
 1 file changed, 34 insertions(+)
 create mode 100644 
2024-06-05-texlive-2023-bump/2024-06-05-texlive-2023-bump.en.txt

diff --git a/2024-06-05-texlive-2023-bump/2024-06-05-texlive-2023-bump.en.txt 
b/2024-06-05-texlive-2023-bump/2024-06-05-texlive-2023-bump.en.txt
new file mode 100644
index ..2c821e01a66c
--- /dev/null
+++ b/2024-06-05-texlive-2023-bump/2024-06-05-texlive-2023-bump.en.txt
@@ -0,0 +1,34 @@
+Title: Upgrading to TeX Live 2023
+Author: Florian Schmaus 
+Posted: 2024-06-05
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: =app-text/texlive-2023'
+[only proceed if texlive update is available]
+2. emerge --unmerge --deselect=n 'dev-texlive/*'
+3. emerge '>=app-text/texlive-2023'
+
+The steps above are equivalent to the following bash snippet:
+
+if emerge -p '>=app-text/texlive-2023'; then
+emerge --unmerge --deselect=n 'dev-texlive/*'
+emerge '>=app-text/texlive-2023'
+fi
-- 
2.44.1

Re: [gentoo-dev] Imminent Python 3.12 switch reminder

[Florian Schmaus]

On 29/05/2024 11.30, Martin Dummer wrote:

Am 28.05.24 um 08:24 schrieb Michał Górny:

If you're up for some more quick porting, right now's the time!

https://github.com/gentoo/gentoo/pull/36502 laying around for ~ 1 Month



Unfortunately it happens that proxy-maint PRs slip through the cracks. 
If this happens, like it seems to have been the case with your PR, then 
please ping us proxy maintainers. Ideally simply by mentioning PRs that 
need attention of proxy maintainers in #gentoo-proxy-maint (Libera IRC).


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 3/3] texlive-module.eclass: include PIPESTATUS in die message

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-module.eclass | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index 7d40bfc58994..98c28f578216 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -539,11 +539,12 @@ texlive-module_src_install() {
find texmf-dist/doc/man -type f -name '*.[0-9n]' -print 
|
grep -v "${grep_expressions[@]}" |
xargs -d '\n' --no-run-if-empty nonfatal doman
+   local pipestatus="${PIPESTATUS[*]}"
# The grep in the middle of the pipe may return 1 in 
case
# everything from the input is dropped.
# See https://bugs.gentoo.org/931994
-   [[ "${PIPESTATUS[*]}" == "0 "[01]" 0" ]]
-   eend $? || die "error installing man pages"
+   [[ "${pipestatus}" == "0 "[01]" 0" ]]
+   eend $? || die "error installing man pages (pipestatus: 
${pipestatus})"
 
# Delete all man pages under texmf-dist/doc/man
find texmf-dist/doc/man -type f -name '*.[0-9n]' 
-delete ||
-- 
2.44.1

[gentoo-dev] [PATCH 2/3] texlive-module.eclass: invoke doman with nonfatal

[Florian Schmaus]

In case doman fails, we do not want to die immediatly as it would
"break" the ebegin/eend combination. Instead, the exit status is passed
through xargs. It will then subsequently appear in PIPESTATUS, where it
is processed by eend || die.

Signed-off-by: Florian Schmaus 
Suggested-by: Ulrich Müller 
---
 eclass/texlive-module.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index b202a0188b66..7d40bfc58994 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -538,7 +538,7 @@ texlive-module_src_install() {
ebegin "Installing man pages"
find texmf-dist/doc/man -type f -name '*.[0-9n]' -print 
|
grep -v "${grep_expressions[@]}" |
-   xargs -d '\n' --no-run-if-empty doman
+   xargs -d '\n' --no-run-if-empty nonfatal doman
# The grep in the middle of the pipe may return 1 in 
case
# everything from the input is dropped.
# See https://bugs.gentoo.org/931994
-- 
2.44.1

[gentoo-dev] [PATCH 1/3] texlive-module.eclass: do not treat grep returning 1 as error

[Florian Schmaus]

In case every man page of the dev-texlive/* package is filtered, because
the man pages are already installed by texlive-core, grep returns an
exit status of 1, which we must not treat as an error condition.

Adjust the PIPESTATUS comparison accordingly.

Closes: https://bugs.gentoo.org/931994
Signed-off-by: Florian Schmaus 
---
 eclass/texlive-module.eclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index 0daca41961ff..b202a0188b66 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -539,7 +539,10 @@ texlive-module_src_install() {
find texmf-dist/doc/man -type f -name '*.[0-9n]' -print 
|
grep -v "${grep_expressions[@]}" |
xargs -d '\n' --no-run-if-empty doman
-   [[ "${PIPESTATUS[*]}" =~ ^0(" 0")*$ ]]
+   # The grep in the middle of the pipe may return 1 in 
case
+   # everything from the input is dropped.
+   # See https://bugs.gentoo.org/931994
+   [[ "${PIPESTATUS[*]}" == "0 "[01]" 0" ]]
eend $? || die "error installing man pages"
 
# Delete all man pages under texmf-dist/doc/man
-- 
2.44.1

[gentoo-dev] Obtaining values for --jobs and --load-average

[Florian Schmaus]

On 12/05/2024 20.21, Michał Górny wrote:

On Sun, 2024-05-12 at 19:22 +0200, Florian Schmaus wrote:

On 12/05/2024 04.26, Michał Górny wrote:

+   if [[ ${PKGBUMPING} != ${PVR} ]]; then
+   pushd "${DISTDIR}" >/dev/null || die
+
+   ebegin "Unpacking crates"
+   printf '%s\0' "${crates[@]}" |
+   xargs -0 -P "$(makeopts_jobs)" -n 1 -- \


Consider using get_makeopts_jobs instead of makeopts_jobs, as it
searches more variables for --jobs.

I'm sorry, I was wrong.

I thought I remembered that we only extended the new get_makeopts_* 
functions so that they also search other relevant variables besides 
MAKEOPTS for --jobs/--load-avgerage. This is wrong, the already existing 
makeopts_* functions were also changed at that time so that they take 
GNUMAKEFLAGS & Co. into account.


As a reminder, this change was due to newer Portage versions setting 
reasonable default values for --jobs and --load-average. And 
GNUMAKEFLAGS is used for --load-average.


The problem is that the order of the parameters of the makeopts_* 
functions is unfavorable. First comes the (optional) opts/flags string, 
then the (optional) default value. This means that as soon as you want 
to specify the default value explicitly, you also have to specify the 
opts/flags string. As a result, it can easily happen that only $MAKEOPTS 
is specified, which can lead to the default value set by portage not 
being taken into account, especially --load-average. This is, for 
example, the case with app-i18n/mozc and dev-qt/qtwebengine.


The get_makeopts_* functions do not suffer from this issue.


> My suggestion would be for the person who introduced new methods
> and implicitly claimed the old methods to be "legacy" to put an actual
> effort to migrate consumers.

That is probably sensible and I believe also possible.

I could only find a single ebuild where makeopts_ was used with a custom 
make opts/flags string: sci-libs/vtk which has some logic for NINJAOPTS.


However, I wonder if it is ever sensible to specify other make 
opts/flags besides what _get_all_makeopts() from multiprocessing.eclass 
considers.


If your make.conf contains

NINJAOPS="-j 4 -l 4 "

then you most likely always also want to set

MAKEOPTS="-j 4"

otherwise, only ninja builds are done with "-j 4".

Of course, we could also simply add $NINJAOPTS to _get_all_makeopts(). 
Consequentially this raises the question if other similar variables 
should also be added (SAMUFLAGS, maybe?).


I'd love to hear some opinions on this.

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cargo.eclass: Optimize crate unpacking

[Florian Schmaus]

On 12/05/2024 20.21, Michał Górny wrote:

On Sun, 2024-05-12 at 19:22 +0200, Florian Schmaus wrote:

On 12/05/2024 04.26, Michał Górny wrote:

+   if [[ ${PKGBUMPING} != ${PVR} ]]; then
+   pushd "${DISTDIR}" >/dev/null || die
+
+   ebegin "Unpacking crates"
+   printf '%s\0' "${crates[@]}" |
+   xargs -0 -P "$(makeopts_jobs)" -n 1 -- \


Consider using get_makeopts_jobs instead of makeopts_jobs, as it
searches more variables for --jobs.


Whose bright idea was to add a second similarly named function that does
roughly the same thing but apparently differently?  It can hardly get
more confusing.


You are absolutely right, it sucks that we have two very similar methods.

You are invited to suggest how the situation can be improved. However, 
rambling without presenting alternatives is not helpful in any way.


Potentially, you will either discover that there is a reason why things 
are the way they are, or find a better solution.


- Flow

Re: [gentoo-dev] [PATCH] cargo.eclass: Optimize crate unpacking

[Florian Schmaus]

On 12/05/2024 04.26, Michał Górny wrote:

Unpack crates in parallel using xargs to utilize multicore systems
better.  Perform checksumming via a single sha256sum invocation.

For dev-python/watchfiles, this speeds up unpacking on my machine
from 2.6 s to 0.75 s (warm cache).

Signed-off-by: Michał Górny 
---
  eclass/cargo.eclass | 56 ++---
  1 file changed, 33 insertions(+), 23 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 0f2da982f60c..5a16d3a30528 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -329,40 +329,50 @@ _cargo_gen_git_config() {
  cargo_src_unpack() {
debug-print-function ${FUNCNAME} "$@"
  
-	mkdir -p "${ECARGO_VENDOR}" || die

-   mkdir -p "${S}" || die
+   mkdir -p "${ECARGO_VENDOR}" "${S}" || die
  
  	local archive shasum pkg

+   local crates=()
for archive in ${A}; do
case "${archive}" in
*.crate)
-   # when called by pkgdiff-mg, do not unpack 
crates
-   [[ ${PKGBUMPING} == ${PVR} ]] && continue
-
-   ebegin "Loading ${archive} into Cargo registry"
-   tar -xf "${DISTDIR}"/${archive} -C 
"${ECARGO_VENDOR}/" || die
-   # generate sha256sum of the crate itself as 
cargo needs this
-   shasum=$(sha256sum "${DISTDIR}"/${archive} | 
cut -d ' ' -f 1)
-   pkg=$(basename ${archive} .crate)
-   cat <<- EOF > 
${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json
-   {
-   "package": "${shasum}",
-   "files": {}
-   }
-   EOF
-   # if this is our target package we need it in 
${WORKDIR} too
-   # to make ${S} (and handle any revisions too)
-   if [[ ${P} == ${pkg}* ]]; then
-   tar -xf "${DISTDIR}"/${archive} -C 
"${WORKDIR}" || die
-   fi
-   eend $?
+   crates+=( "${archive}" )
;;
*)
-   unpack ${archive}
+   unpack "${archive}"
;;
esac
done
  
+	if [[ ${PKGBUMPING} != ${PVR} ]]; then

+   pushd "${DISTDIR}" >/dev/null || die
+
+   ebegin "Unpacking crates"
+   printf '%s\0' "${crates[@]}" |
+   xargs -0 -P "$(makeopts_jobs)" -n 1 -- \


Consider using get_makeopts_jobs instead of makeopts_jobs, as it 
searches more variables for --jobs.


N.B.: If this where asking for a load-average limit, then using 
get_makeopts_loadavg would be the ideal way to pick up portage's default 
wrt --load-average. Therefore we should IMHO encourage using the 
get_makeopts_* functions over the (legacy?) non-get_ variants.



+   tar -x -C "${ECARGO_VENDOR}" -f
+   assert
+   eend $?
+
+   while read -d '' -r shasum archive; do
+   pkg=${archive%.crate}
+   cat <<- EOF > 
${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json || die
+   {
+   "package": "${shasum}",
+   "files": {}
+   }
+   EOF
+
+   # if this is our target package we need it in 
${WORKDIR} too
+   # to make ${S} (and handle any revisions too)
+   if [[ ${P} == ${pkg}* ]]; then
+   tar -xf "${archive}" -C "${WORKDIR}" || die
+   fi
+   done < <(sha256sum -z "${crates[@]}" || die)
+
+   popd >/dev/null || die
+   fi
+
cargo_gen_config
  }
  




OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 2/2] eftmutil-sys: use edob

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 15d475799a88..072581dde78e 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -22,6 +22,8 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
+inherit edo
+
 if [[ -z ${_TEXLIVE_COMMON_ECLASS} ]]; then
 _TEXLIVE_COMMON_ECLASS=1
 
@@ -199,9 +201,9 @@ etexmf-update() {
 efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/bin/fmtutil-sys ]] ; 
then
-   einfo "Rebuilding formats"
-   "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null ||
-   die -n "fmtutil-sys returned non-zero exit 
status ${?}"
+   edob -m "Rebuilding TexLive formats" \
+-l fmtutils-sys-all \
+"${EPREFIX}"/usr/bin/fmtutil-sys --all
else
ewarn "Cannot run fmtutil-sys for some reason."
ewarn "Your formats might be inconsistent with your 
installed ${PN} version"
-- 
2.43.2

[gentoo-dev] [PATCH 1/2] edo.eclass: enhace edob for usage with nosiy commands

[Florian Schmaus]

Normally, edob can, or rather should, not be used with noisy commands,
i.e., commands that produce an output. This is because the output
destroys the concept of ebegin and eend, where the eend marker is shown
on the same line that is produced by ebegin.

However, it sometimes would be nice to use edob with noisy commands, but
this means to redirect stdout and stderr of those commands. Instead of
redirecting the output to /dev/null, we save the output in a log file
under T. This allows us to present the output to the user in case the
command fails, making it futhermore part of the build.log, which we
expect users to attach to bug reports.

Signed-off-by: Florian Schmaus 
---
 eclass/edo.eclass | 66 ---
 1 file changed, 56 insertions(+), 10 deletions(-)

diff --git a/eclass/edo.eclass b/eclass/edo.eclass
index c2e7ed60083f..0d410719675c 100644
--- a/eclass/edo.eclass
+++ b/eclass/edo.eclass
@@ -1,4 +1,4 @@
-# Copyright 2022 Gentoo Authors
+# Copyright 2022-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: edo.eclass
@@ -12,10 +12,14 @@
 # This eclass provides the 'edo' command, and an 'edob' variant for 
ebegin/eend,
 # which logs the command used verbosely and dies (exits) on failure.
 #
-# This eclass should be used only where needed to give a more verbose log, e.g.
-# for invoking non-standard ./configure scripts, or building objects/binaries
-# directly within ebuilds via compiler invocations. It is NOT to be used
-# in place of generic 'command || die' where verbosity is unnecessary.
+# The 'edo' command should be used only where needed to give a more verbose 
log,
+# e.g. for invoking non-standard ./configure scripts, or building
+# objects/binaries directly within ebuilds via compiler invocations.  It is NOT
+# to be used in place of generic 'command || die' where verbosity is
+# unnecessary.
+#
+# The 'edob' command should be used if its output is not of general interest,
+# as it will be only shown if the command returns a non-zero exit status.
 case ${EAPI} in
7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
@@ -35,14 +39,56 @@ edo() {
 }
 
 # @FUNCTION: edob
-# @USAGE:  [...]
+# @USAGE: [-m ] [-l ]  [...]
 # @DESCRIPTION:
 # Executes 'command' with ebegin & eend with any given arguments and exits
-# on failure unless called under 'nonfatal'.
+# on failure unless called under 'nonfatal'.  This function redirects
+# stdout and stderr to a log file.  The content of the log file is shown
+# if the command returns with a non-zero exit status.
+#
+# If -m  is provided, then invokes ebegin with , otherwise
+# a default message is used.  If -l  is provided, then  is
+# used to construct the name of the log file where stdout and stderr of the
+# command is redirected to.
 edob() {
-   ebegin "Running $@"
-   "$@"
-   eend $? || die -n "Failed to run command: $@"
+   local message
+   local log_name
+
+   while true; do
+   case "${1}" in
+   -m|-n)
+   [[ $# -lt 2 ]] && die "Must provide an argument 
to ${1}"
+   case "${1}" in
+   -m)
+   message="${2}"
+   ;;
+   -n)
+   log="${2}"
+   ;;
+   esac
+   shift 2
+   ;;
+   *)
+   break
+   ;;
+   esac
+   done
+
+   [[ -z ${message} ]] && message="Running $@"
+   [[ -z ${log_name} ]] && log_name="$(basename ${1})"
+
+   local log_file="${T}/${log_name}.log"
+   [[ -f ${log_file} ]] && die "Log file ${log_file} exists. Consider 
using \"edob -l\""
+
+   ebegin "${message}"
+
+   "$@" &> "${log_file}"
+   local ret=$?
+
+   if ! eend $ret; then
+   cat "${log_file}"
+   die -n "Command \"$@\" failed with exit status $ret"
+   fi
 }
 
 fi
-- 
2.43.2

[gentoo-dev] [PATCH 0/2] edo.eclass: enhace edob for usage with nosiy commands

[Florian Schmaus]

The motivation for this change is to allow edob to be used with noisy
commands, i.e., commands that produce a lot of output, in cases where
the output is in general not of interest. However, if the command
fails, the output should be shown and appear in build.log.

We do this by simply redirecting the output to a file in $T, and show
this file if the command returned a non-zero exit status.

We already have a few cases in ::gentoo where such output is simply
redirected to /dev/null, hindering post-mortem analysis. Those could
be converted to edob with its new behavior.

PR at https://github.com/gentoo/gentoo/pull/36117

Florian Schmaus (2):
  edo.eclass: enhace edob for usage with nosiy commands
  eftmutil-sys: use edob

 eclass/edo.eclass| 54 
 eclass/texlive-common.eclass |  8 --
 2 files changed, 53 insertions(+), 9 deletions(-)

-- 
2.43.2

[gentoo-dev] [PATCH v2] texlive-module.eclass: install man pages in right location

[Florian Schmaus]

The TeX Live packages under dev-texlive/* currently do not install the
man pages in the right location. They are under
/usr/share/texmf-dist/doc/man.

Install them at the right location using doman.

Having dev-texlive/* packages installing man pages requires that we
filter man pages already installed by app-text/texlive-core to avoid
file collisions. As a consequence, unfortunately, we have to hard code
the list of man pages installed by texlive-core. Or, at least, folks
from #-tex and myself could not come up with a solution that does not
require hard coding that list.

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-module.eclass | 186 +++
 1 file changed, 186 insertions(+)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index 401b75bc4d11..293b6591a6b1 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -359,6 +359,192 @@ texlive-module_src_install() {
if [[ -d texmf-doc ]]; then
cp -pR texmf-doc "${ED}/usr/share/" || die
fi
+
+   if ver_test -ge 2023 && [[ ${CATEGORY} == dev-texlive ]]; then
+   local texlive_core_man_pages=(
+   afm2pl.1
+   aleph.1
+   allcm.1
+   allec.1
+   allneeded.1
+   amstex.1
+   autosp.1
+   axohelp.1
+   bibtex.1
+   chkdvifont.1
+   chktex.1
+   chkweb.1
+   ctangle.1
+   ctie.1
+   ctwill.1
+   ctwill-refsort.1
+   ctwill-twinx.1
+   cweave.1
+   cweb.1
+   detex.1
+   devnag.1
+   deweb.1
+   disdvi.1
+   dt2dv.1
+   dv2dt.1
+   dvi2fax.1
+   dvi2tty.1
+   dvibook.1
+   dviconcat.1
+   dvicopy.1
+   dvidvi.1
+   dvihp.1
+   dvilj.1
+   dvilj2p.1
+   dvilj4.1
+   dvilj4l.1
+   dvilj6.1
+   dvilualatex-dev.1
+   dviluatex.1
+   dvipdfm.1
+   dvipdfmx.1
+   dvipdft.1
+   dvipos.1
+   dvired.1
+   dviselect.1
+   dvispc.1
+   dvitodvi.1
+   dvitomp.1
+   dvitype.1
+   e2pall.1
+   ebb.1
+   eptex.1
+   euptex.1
+   extractbb.1
+   fmtutil.1
+   fmtutil.cnf.5
+   fmtutil-sys.1
+   fontinst.1
+   gftodvi.1
+   gftopk.1
+   gftype.1
+   gsftopk.1
+   hishrink.1
+   histretch.1
+   hitex.1
+   inimf.1
+   initex.1
+   kpsepath.1
+   kpsetool.1
+   kpsewhere.1
+   kpsexpand.1
+   lacheck.1
+   latex.1
+   latex-dev.1
+   luahbtex.1
+   luajittex.1
+   lualatex-dev.1
+   luatex.1
+   makeindex.1
+   makejvf.1
+   mendex.1
+   mf.1
+   mf-nowin.1
+   mft.1
+   mkindex.1
+   mkocp.1
+   mkofm.1
+   mktexfmt.1
+   mktexlsr.1
+

[gentoo-dev] [PATCH] texlive-module.eclass: install man pages in right location

[Florian Schmaus]

The TeX Live packages under dev-texlive/* currently do not install the
man pages in the right location. They are under
/usr/share/texmf-dist/doc/man.

Install them at the right location using doman.

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-module.eclass | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index 401b75bc4d11..11d869a7fa7b 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -79,7 +79,7 @@ esac
 if [[ -z ${_TEXLIVE_MODULE_ECLASS} ]]; then
 _TEXLIVE_MODULE_ECLASS=1
 
-inherit texlive-common
+inherit estack texlive-common
 
 HOMEPAGE="https://www.tug.org/texlive/";
 
@@ -359,6 +359,16 @@ texlive-module_src_install() {
if [[ -d texmf-doc ]]; then
cp -pR texmf-doc "${ED}/usr/share/" || die
fi
+
+   if ver_test -ge 2023 && [[ ${CATEGORY} == dev-texlive ]]; then
+   eshopts_push -s nullglob
+   local man_page
+   for man_page in texmf-dist/doc/man/man[1-8]/*.[1-8]; do
+   doman "${man_page}"
+   rm "${man_page}" || die
+   done
+   eshopts_pop
+   fi
else
if [[ -d texmf-dist/doc ]]; then
rm -rf texmf-dist/doc || die
-- 
2.43.2

Re: [gentoo-dev] [PATCH] texlive-common.eclass: add newline between tlbobj entries in tlpdb

[Florian Schmaus]

On 28/04/2024 14.13, Ulrich Mueller wrote:

On Sun, 28 Apr 2024, Florian Schmaus wrote:



--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -270,10 +270,18 @@ texlive-common_update_tlpdb() {
touch "${new_tlpdb}" || die

if [[ -d "${tlpobj}" ]]; then
-   find "${tlpobj}" -maxdepth 1 -type f -name "*.tlpobj" -print0 |
-   sort -z |
-   xargs -0 --no-run-if-empty cat >> "${new_tlpdb}"
-   assert "generating tlpdb failed"
+   all_tlpobjs() {
+   find "${tlpobj}" -maxdepth 1 -type f -name "*.tlpobj" 
-print0 |
+   sort -z
+   assert "Error enumerating all tlpobj files"
+   }
+   (
+   while IFS="" read -d $'\0' -r f; do
+   cat "${f}" || die "Failed to read ${f}"
+   # Ensure there is an empty line between every 
tlpobj entry.
+   echo
+   done < <(all_tlpobjs)
+   ) >> "${new_tlpdb}"
fi

if [[ -f ${tlpdb} ]]; then


Looks complicated. AFAICS a one-line change like the following would
also do the job:

-   xargs -0 --no-run-if-empty cat >> "${new_tlpdb}"
+   xargs -0 --no-run-if-empty sed -s '$G' >> "${new_tlpdb}"


That is exactly the feedback I was hoping for.

Thanks ulm.



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] texlive-common.eclass: add newline between tlbobj entries in tlpdb

[Florian Schmaus]

We previously created the texlive.tlpdb by concatenating all tlpobj
files. This means that the entries will be right after another.

As it turns out, some TeX Live tools require a newline (e.g., tlmgr)
between the entries, while others do not (e.g., texdoc). And the
"official" tlpdb also has the entries separated by newlines. Therefore
this changes texlive-common_update_tlpdb() to also add them.

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index b32ea2af1121..929062c0444a 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -270,10 +270,18 @@ texlive-common_update_tlpdb() {
touch "${new_tlpdb}" || die
 
if [[ -d "${tlpobj}" ]]; then
-   find "${tlpobj}" -maxdepth 1 -type f -name "*.tlpobj" -print0 |
-   sort -z |
-   xargs -0 --no-run-if-empty cat >> "${new_tlpdb}"
-   assert "generating tlpdb failed"
+   all_tlpobjs() {
+   find "${tlpobj}" -maxdepth 1 -type f -name "*.tlpobj" 
-print0 |
+   sort -z
+   assert "Error enumerating all tlpobj files"
+   }
+   (
+   while IFS="" read -d $'\0' -r f; do
+   cat "${f}" || die "Failed to read ${f}"
+   # Ensure there is an empty line between every 
tlpobj entry.
+   echo
+   done < <(all_tlpobjs)
+   ) >> "${new_tlpdb}"
fi
 
if [[ -f ${tlpdb} ]]; then
-- 
2.43.2

Re: [gentoo-dev] Update on the 23.0 profiles

[Florian Schmaus]

On 06/04/2024 17.06, Andreas K. Huettel wrote:

Hi all,

so here's a small update on the state of the 23.0 profiles:


Thanks for the update and the work on the 23.0 profiles. :)



Most 17.x profiles have been downgraded to "exp".


I could imagine there is a reason to downgrade those back to 'exp', 
could you elaborate a bit on that?


Isn't it bit strange that a 'stable' profiles gets downgraded back to 
'exp'? Then again, I am not sure about the implications of this nor 
about the rationale behind it.


However, I also notice that there is a outstanding PR that reverts that 
[1]. Maybe we should introduce a new state 'oldstable' or so?


- Flow


1: https://github.com/gentoo/gentoo/pull/35871


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH] efmtutil-sys: use ebegin/eend and log output

[Florian Schmaus]

I just noticed two things seconds after sending the patch:

Commit message is missing "texlive-common.eclass" prefix.

On 04/04/2024 15.01, Florian Schmaus wrote:

Use ebegin/eend and instead of redirecting the output to /dev/null
capture stdout and stderr under a file under $T.

Signed-off-by: Florian Schmaus 
---
  eclass/texlive-common.eclass | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 66d3999bd103..0cc61f735cb2 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -199,9 +199,11 @@ etexmf-update() {
  efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/bin/fmtutil-sys ]] ; 
then
-   einfo "Rebuilding formats"
-   "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null ||
-   die -n "fmtutil-sys returned non-zero exit status 
${?}"
+   ebegin "Rebuilding TexLive formats"
+   "${EPREFIX}"/usr/bin/fmtutil-sys --all \
+   > "${T}"/fmutil-sys-all.log \
+   &> "${T}"/fmutil-sys-all.err.log

This should be 2> instead of &>

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] efmtutil-sys: use ebegin/eend and log output

[Florian Schmaus]

Use ebegin/eend and instead of redirecting the output to /dev/null
capture stdout and stderr under a file under $T.

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 66d3999bd103..0cc61f735cb2 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -199,9 +199,11 @@ etexmf-update() {
 efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/bin/fmtutil-sys ]] ; 
then
-   einfo "Rebuilding formats"
-   "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null ||
-   die -n "fmtutil-sys returned non-zero exit 
status ${?}"
+   ebegin "Rebuilding TexLive formats"
+   "${EPREFIX}"/usr/bin/fmtutil-sys --all \
+   > "${T}"/fmutil-sys-all.log \
+   &> "${T}"/fmutil-sys-all.err.log
+   eend $? || die -n "fmtutil-sys returned non-zero exit 
status ${?}"
else
ewarn "Cannot run fmtutil-sys for some reason."
ewarn "Your formats might be inconsistent with your 
installed ${PN} version"
-- 
2.43.2

[gentoo-dev] [PATCH 2/2] texlive-module.eclass: add texlive-module_update_tlpdb

[Florian Schmaus]

Update (or create) the tlpdb based on the contents of
/usr/share/tlpkg/tlpobj.

Closes: https://bugs.gentoo.org/928162
Signed-off-by: Florian Schmaus 
---
 eclass/texlive-module.eclass | 57 
 1 file changed, 57 insertions(+)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index d19e02f02647..15346a3535eb 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -420,6 +420,61 @@ texlive-module_src_install() {
texlive-common_handle_config_files
 }
 
+# @FUNCTION: texlive-module_update_tlpdb
+# @DESCRIPTION:
+# Update the TexLive package database at /usr/share/tlpkg/texlive.tlpdb.
+
+texlive-module_update_tlpdb() {
+   [[ ${TL_PV} -lt 2023 ]] && return
+
+   # If we are updating this package, then there is no need to update
+   # the tlpdb in postrm, as it will be again updated in postinst.
+   [[ -n ${REPLACING_VERSIONS} && ${EBUILD_PHASE} == postrm ]] && return
+
+   local tlpkg="${EROOT}"/usr/share/tlpkg
+   local tlpobj="${tlpkg}"/tlpobj
+   local tlpdb="${tlpkg}"/texlive.tlpdb
+
+   ebegin "Regenerating TexLive package database (${tlpdb}, 
${EBUILD_PHASE})"
+
+   local new_tlpdb="${T}"/texlive.tlpdb
+
+   touch "${new_tlpdb}" || die
+
+   find "${tlpobj}" -maxdepth 1 -type f -name "*.tlpobj" -print0 |
+   sort -z |
+   xargs -0 --no-run-if-empty cat >> "${new_tlpdb}"
+   assert "generating tlpdb failed"
+
+   if [[ -f ${tlpdb} ]]; then
+   cmp -s "${new_tlpdb}" "${tlpdb}"
+   local ret=$?
+   case ${ret} in
+   # content equal
+   0)
+   # Nothing to do, return.
+   eend 0
+   return
+   ;;
+   # content differs
+   1)
+   ;;
+   # cmp failed with an error
+   *)
+   eend ${ret} "comparing new and existing tlpdb 
failed (exit status: ${ret})"
+   die
+   ;;
+   esac
+   fi
+
+   mv "${new_tlpdb}" "${tlpdb}"
+   eend $? "moving tlpdb into position failed (exit status: ${?})" || die
+
+   if [[ ! -s ${tlpdb} ]]; then
+   rm "${tlpdb}" || die
+   fi
+}
+
 # @FUNCTION: texlive-module_pkg_postinst
 # @DESCRIPTION:
 # exported function:
@@ -428,6 +483,7 @@ texlive-module_src_install() {
 
 texlive-module_pkg_postinst() {
etexmf-update
+   texlive-module_update_tlpdb
[[ -n ${TL_MODULE_INFORMATION} ]] && elog "${TL_MODULE_INFORMATION}"
 }
 
@@ -439,6 +495,7 @@ texlive-module_pkg_postinst() {
 
 texlive-module_pkg_postrm() {
[[ -z ${REPLACING_VERSIONS} ]] && etexmf-update
+   texlive-module_update_tlpdb
 }
 
 fi
-- 
2.43.2

[gentoo-dev] [PATCH 1/2] texlive-module.eclass: only invoke etexmf-update in postinst if not replacing versions

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-module.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index 9fc4e619ff9b..d19e02f02647 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -438,7 +438,7 @@ texlive-module_pkg_postinst() {
 # installed texmf trees.
 
 texlive-module_pkg_postrm() {
-   etexmf-update
+   [[ -z ${REPLACING_VERSIONS} ]] && etexmf-update
 }
 
 fi
-- 
2.43.2

[gentoo-dev] [PATCH] texlive-common.eclass: etexmf-update to call 'die' for non-"dev-telive"

[Florian Schmaus]

This also makes etexmf-update fail for packages that are outside
dev-texlive/* and don't use the TexLive version scheme like
dev-libs/kpathsea and soon dev-tex/hevea.

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 1e5c8a53d5cc..e8a740df1f27 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -179,7 +179,8 @@ etexmf-update() {
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/sbin/texmf-update ]] ; 
then
"${EPREFIX}"/usr/sbin/texmf-update
local res="${?}"
-   if [[ "${res}" -ne 0 ]] && ver_test -ge 2023; then
+   if [[ "${res}" -ne 0 ]] &&
+  { [[ ${CATEGORY} != dev-texlive ]] || 
ver_test -ge 2023; } then
die -n "texmf-update returned non-zero exit 
status ${res}"
fi
else
-- 
2.43.2

Re: [gentoo-dev] [PATCH 2/3] texlive-common.eclass: check exit status of texmf-update

[Florian Schmaus]

On 29/02/2024 21.40, Ulrich Mueller wrote:

On Thu, 29 Feb 2024, Florian Schmaus wrote:



@@ -178,6 +178,10 @@ etexmf-update() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/sbin/texmf-update ]] ; 
then
"${EPREFIX}"/usr/sbin/texmf-update
+   local res="${?}"
+   if [[ "${?}" -ne 0 ]] && ver_test -ge 2023; then


This condition will always be false.


Is it because assigning 'res' will set '$?'?

- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

[Florian Schmaus]

On 29/02/2024 15.34, Michael Orlitzky wrote:

On Thu, 2024-02-29 at 15:21 +0100, Florian Schmaus wrote:


The eclass only supports EAPIs {7,8,...} so it should suffice to
blacklist EAPI=7.


Fair point, but that would mean to remember to adjust this line once the
eclass gets support for EAPI 9.



It should do the right thing automatically when EAPI=9 is added, no? If
the goal of "-gt 8" is to match EAPI=8 and newer, then rejecting (only)
the one EAPI that's older than 8 should be equivalent without involving
a numerical comparison.


Of course, you are right. Not sure how I could miss that.

I'll go with [[ ${EAPI} != 7 ]] then.

Thanks

- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

[Florian Schmaus]

On 29/02/2024 15.08, Michael Orlitzky wrote:

On Thu, 2024-02-29 at 14:47 +0100, Florian Schmaus wrote:
   
+if [[ -z ${TL_PV} ]] \

+  && [[ ${EAPI} -ge 8 ]] \


I am skeptical of this construct, as in the past we had non-numeric
EAPIs. So I may have to go with EAPI == 8 for now. Input appreciated.




The eclass only supports EAPIs {7,8,...} so it should suffice to
blacklist EAPI=7.


Fair point, but that would mean to remember to adjust this line once the 
eclass gets support for EAPI 9.


It appears that bash does the right thing:

$ if [[ "eapi-future" -gt 8 ]]; then echo "is greater than 8"; else echo 
"is NOT greater than 8"; fi

is NOT greater than 8

even considering

$ if [[ "9-eapi-future" -gt 8 ]]; then echo "is greater than 8"; else 
echo "is NOT greater than 8"; fi

is greater than 8

which would be fine.

Although I prefer the current approach, it is not a hill to die on for me.

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

[Florian Schmaus]

On 29/02/2024 14.38, Florian Schmaus wrote:

Signed-off-by: Florian Schmaus 
---
  eclass/texlive-module.eclass | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index afcd4532975a..d1bf0f86185b 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -85,6 +85,12 @@ HOMEPAGE="https://www.tug.org/texlive/";
  
  IUSE="doc source"
  
+if [[ -z ${TL_PV} ]] \

+  && [[ ${EAPI} -ge 8 ]] \


I am skeptical of this construct, as in the past we had non-numeric 
EAPIs. So I may have to go with EAPI == 8 for now. Input appreciated.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 3/3] texlive-common.eclass: Use nonfatal-respecting die for fmtutil-sys

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index 96e962cb8027..85cdb8ff204e 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -199,7 +199,8 @@ efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/bin/fmtutil-sys ]] ; 
then
einfo "Rebuilding formats"
-   "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null || 
die
+   "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null \
+   || die -n "fmtutil-sys returned non-zero exit 
status ${res}"
else
ewarn "Cannot run fmtutil-sys for some reason."
ewarn "Your formats might be inconsistent with your 
installed ${PN} version"
-- 
2.43.0

[gentoo-dev] [PATCH 2/3] texlive-common.eclass: check exit status of texmf-update

[Florian Schmaus]

The texlive eclasses where traditionally lenient when it comes to the
exit status of texmf-update and fmtutil-sys, as they would return a
non-zero exit status in certain situations, especially when bootstraping
the texlive installation, i.e., when texlive-core is installed.

With the upcoming Texlive 2023 bbump we can make this more strict,
having texlive-core use nonfatal.

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index fab6ff66ecd5..96e962cb8027 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -178,6 +178,10 @@ etexmf-update() {
if has_version 'app-text/texlive-core' ; then
if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/sbin/texmf-update ]] ; 
then
"${EPREFIX}"/usr/sbin/texmf-update
+   local res="${?}"
+   if [[ "${?}" -ne 0 ]] && ver_test -ge 2023; then
+   die -n "texmf-update returned non-zero exit 
status ${res}"
+   fi
else
ewarn "Cannot run texmf-update for some reason."
ewarn "Your texmf tree might be inconsistent with your 
configuration"
-- 
2.43.0

[gentoo-dev] [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/texlive-module.eclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass
index afcd4532975a..d1bf0f86185b 100644
--- a/eclass/texlive-module.eclass
+++ b/eclass/texlive-module.eclass
@@ -85,6 +85,12 @@ HOMEPAGE="https://www.tug.org/texlive/";
 
 IUSE="doc source"
 
+if [[ -z ${TL_PV} ]] \
+  && [[ ${EAPI} -ge 8 ]] \
+  && [[ ${CATEGORY} == dev-texlive ]]; then
+   TL_PV=$(ver_cut 1)
+fi
+
 RDEPEND=">=app-text/texlive-core-${TL_PV:-${PV}}"
 # We do not need anything from SYSROOT:
 #   Everything is built from the texlive install in /
-- 
2.43.0

[gentoo-dev] [PATCH 0/3] *** Three minor changes to texlive-(common|mmodule).elcass ***

[Florian Schmaus]

Following are three minor changes to texlive-(common|module).eclass,
which I expect to be the last changes to the eclasses before start
moving texlive 2023 from ::tex-overlay into ::gentoo (initally
pmasked).

Florian Schmaus (3):
  texlive-module.eclass: implicitly set TL_PV if not explicitly set
  texlive-common.eclass: check exit status of texmf-update
  texlive-common.eclass: Use nonfatal-respecting die for fmtutil-sys

 eclass/texlive-common.eclass | 7 ++-
 eclass/texlive-module.eclass | 6 ++
 2 files changed, 12 insertions(+), 1 deletion(-)

-- 
2.43.0

[gentoo-dev] [PATCH 2/2] texlive-{common,module}.eclass: update for TeX Live 2023

[Florian Schmaus]

Update the texlive eclasses for the upcoming TeX Live 2023 bump. This
includes general cleanup of the eclasses, e.g., reducing the scope of
variables.

Notably changes include that installation of the TeX Live distribution
changes from /usr/share/texmf to /usr/share/texmf-dist, which is the
correct place, according to upstream.

Co-authored-by: Paul Zander 
Signed-off-by: Paul Zander 
Signed-off-by: Florian Schmaus 
---
 eclass/texlive-common.eclass | 113 +--
 eclass/texlive-module.eclass |  77 
 2 files changed, 108 insertions(+), 82 deletions(-)

diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index f43d10926857..5de58300f2f3 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: texlive-common.eclass
@@ -6,7 +6,7 @@
 # t...@gentoo.org
 # @AUTHOR:
 # Original Author: Alexis Ballier 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: Provide various functions used by both texlive-core and texlive 
modules
 # @DESCRIPTION:
 # Purpose: Provide various functions used by both texlive-core and texlive
@@ -15,53 +15,66 @@
 # Note that this eclass *must* not assume the presence of any standard tex too
 
 case ${EAPI} in
-   7) inherit eapi8-dosym ;;
+   7)
+   inherit eapi8-dosym
+   dosym(){ dosym8 "$@"; }
+   ;;
+   8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 if [[ -z ${_TEXLIVE_COMMON_ECLASS} ]]; then
 _TEXLIVE_COMMON_ECLASS=1
 
-TEXMF_PATH=/usr/share/texmf
-TEXMF_DIST_PATH=/usr/share/texmf-dist
-TEXMF_VAR_PATH=/var/lib/texmf
-
 # @FUNCTION: texlive-common_handle_config_files
 # @DESCRIPTION:
 # Has to be called in src_install after having installed the files in ${D}
-# This function will move the relevant files to /etc/texmf and symling them
+# This function will move the relevant files to /etc/texmf and symlink them
 # from their original location. This is to allow easy update of texlive's
-# configuration
-
+# configuration.
+# Called by app-text/texlive-core and texlive-module.eclass.
 texlive-common_handle_config_files() {
+   local texmf_path
+   # Starting with TeX Live 2023, we install in texmf-dist, where a
+   # distribution-provided TeX Live installation is supposed to be,
+   # instead of texmf.
+   if ver_test -ge 2023; then
+   texmf_path=/usr/share/texmf-dist
+   else
+   texmf_path=/usr/share/texmf
+   fi
+
# Handle config files properly
-   [[ -d ${ED}${TEXMF_PATH} ]] || return
-   cd "${ED}${TEXMF_PATH}" || die
+   [[ -d ${ED}${texmf_path} ]] || return
+   cd "${ED}${texmf_path}" || die
 
while read -r f; do
-   if [[ ${f#*config} != ${f} || ${f#doc} != ${f} || ${f#source} 
!= ${f} || ${f#tex} != ${f} ]] ; then
+   if [[ ${f#*config} != "${f}" || ${f#doc} != "${f}" || 
${f#source} != "${f}" || ${f#tex} != "${f}" ]] ; then
continue
fi
-   dodir /etc/texmf/$(dirname ${f}).d
-   einfo "Moving (and symlinking) ${EPREFIX}${TEXMF_PATH}/${f} to 
${EPREFIX}/etc/texmf/$(dirname ${f}).d"
-   mv "${ED}/${TEXMF_PATH}/${f}" "${ED}/etc/texmf/$(dirname 
${f}).d" || die "mv ${f} failed."
-   dosym8 -r /etc/texmf/$(dirname ${f}).d/$(basename ${f}) 
${TEXMF_PATH}/${f}
-   done < <(find  -name '*.cnf' -type f -o -name '*.cfg' -type f | sed -e 
"s:\./::g")
+   local rel_dir
+   rel_dir="$(dirname "${f}")"
+
+   dodir "/etc/texmf/${rel_dir}.d"
+   einfo "Moving (and symlinking) ${EPREFIX}${texmf_path}/${f} to 
${EPREFIX}/etc/texmf/${rel_dir}.d"
+   mv "${ED}/${texmf_path}/${f}" "${ED}/etc/texmf/${rel_dir}.d" || 
die "mv ${f} failed."
+   dosym -r "/etc/texmf/${rel_dir}.d/$(basename "${f}")" 
"${texmf_path}/${f}"
+   done < <(find . -name '*.cnf' -type f -o -name '*.cfg' -type f | sed -e 
"s:\./::g")
 }
 
 # @FUNCTION: texlive-common_is_file_present_in_texmf
 # @DESCRIPTION:
 # Return if a file is present in the texmf tree
 # Call it from the directory containing texmf and texmf-dist
-
+# Called by app-text/texlive-core.
 texlive-common_is_file_present_in_texmf() {
local mark="${T}/${1}.found"
if [[ -d texmf ]]; then
-   find texmf -name ${1} -exec touch ${mark} {} + || die
+   find texmf -name "${1}" -exec touch "

[gentoo-dev] [PATCH 1/2] profiles/thirdpartymirrors: add 'ctan' mirror

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 profiles/thirdpartymirrors | 1 +
 1 file changed, 1 insertion(+)

diff --git a/profiles/thirdpartymirrors b/profiles/thirdpartymirrors
index b890610255f5..1db91760893b 100644
--- a/profiles/thirdpartymirrors
+++ b/profiles/thirdpartymirrors
@@ -1,5 +1,6 @@
 apache https://dlcdn.apache.org/ https://apache.mirror.iphh.net/ 
https://artfiles.org/apache.org/ 
https://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/ 
https://ftp.fau.de/apache/ https://apache.osuosl.org/
 cpan   https://cpan.metacpan.org https://www.cpan.org
+ctan   https://mirrors.ctan.org/ https://ftp.fau.de/ctan/ 
https://mirror.physik.tu-berlin.de/pub/CTAN/ https://ftp.sun.ac.za/ftp/CTAN/ 
https://mirror.math.princeton.edu/pub/CTAN/ 
https://mirrors.sjtug.sjtu.edu.cn/ctan/ https://mirrors.mit.edu/CTAN/ 
https://tug.ctan.org/
 debian https://deb.debian.org/debian/ http://ftp.au.debian.org/debian/ 
http://ftp.at.debian.org/debian/ http://ftp.by.debian.org/debian/ 
http://ftp.be.debian.org/debian/ http://ftp.br.debian.org/debian/ 
http://ftp.bg.debian.org/debian/ http://ftp.ca.debian.org/debian/ 
http://ftp2.cn.debian.org/debian/ http://ftp.cn.debian.org/debian/ 
http://ftp.hr.debian.org/debian/ http://ftp.cz.debian.org/debian/ 
http://ftp.dk.debian.org/debian/ http://ftp.sv.debian.org/debian/ 
http://ftp.ee.debian.org/debian/ http://ftp.fi.debian.org/debian/ 
http://ftp.fr.debian.org/debian/ http://ftp2.de.debian.org/debian/ 
http://ftp.de.debian.org/debian/ http://ftp.gr.debian.org/debian/ 
http://ftp.hu.debian.org/debian/ http://ftp.is.debian.org/debian/ 
http://ftp.ie.debian.org/debian/ http://ftp.it.debian.org/debian/ 
http://ftp.jp.debian.org/debian/ http://ftp.lt.debian.org/debian/ 
http://ftp.mx.debian.org/debian/ http://ftp.md.debian.org/debian/ 
http://ftp.nl.debian.org/debian/ http://ftp.nc.debian.org/debian/ 
http://ftp.nz.debian.org/debian/ http://ftp.no.debian.org/debian/ 
http://ftp.pl.debian.org/debian/ http://ftp.pt.debian.org/debian/ 
http://ftp.ro.debian.org/debian/ http://ftp.ru.debian.org/debian/ 
http://ftp.sg.debian.org/debian/ http://ftp.sk.debian.org/debian/ 
http://ftp.si.debian.org/debian/ http://ftp.es.debian.org/debian/ 
http://ftp.se.debian.org/debian/ http://ftp.ch.debian.org/debian/ 
http://ftp.tw.debian.org/debian/ http://ftp.tr.debian.org/debian/ 
http://ftp.ua.debian.org/debian/ http://ftp.uk.debian.org/debian/ 
http://ftp.us.debian.org/debian/
 gentoo https://distfiles.gentoo.org/distfiles 
https://gentoo.osuosl.org/distfiles 
https://ftp.halifax.rwth-aachen.de/gentoo/distfiles 
https://ftp.fau.de/gentoo/distfiles
 gcchttps://gcc.gnu.org/pub/gcc/ 
http://mirrors.concertpass.com/gcc/ 
https://mirrorservice.org/sites/sourceware.org/pub/gcc/ 
https://ftp.mpi-inf.mpg.de/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/ 
https://bigsearcher.com/mirrors/gcc/
-- 
2.43.0

[gentoo-dev] [PATCH 0/2] texlive eclass updates, in preperation of TeX Live 2023 bump

[Florian Schmaus]

After negril and I worked for the past months on the TeX Live 2023
bump, it is now time to submit the eclass changes to the mailing list
for review.

Note that we tried to keep the changes to the eclasses to a minimum.
There are many more places where the code of the eclasses could be
improved. But bumping TeX Live is already a delicate matter and we do
not want to add more distraction from the actual changes to keep the
changes manageable and reviewable.

Once TeX Live 2023 hits ::gentoo, we will iteratively work on revising
the code of the eclasses.

Florian Schmaus (2):
  profiles/thirdpartymirrors: add 'ctan' mirror
  texlive-{common,module}.eclass: update for TeX Live 2023

 eclass/texlive-common.eclass | 113 +--
 eclass/texlive-module.eclass |  77 
 profiles/thirdpartymirrors   |   1 +
 3 files changed, 109 insertions(+), 82 deletions(-)

-- 
2.43.0

Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Florian Schmaus]

On 10/01/2024 16.10, Ulrich Mueller wrote:

On Wed, 10 Jan 2024, Florian Schmaus wrote:



On 10/01/2024 14.58, Ulrich Mueller wrote:

Looks like readme.gentoo-r1 already gives you control over this:
# If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
# value in your ebuild before this function is called.
# This can be useful when, for example, DOC_CONTENTS is modified, then, you can
# rely on specific REPLACING_VERSIONS handling in your ebuild to print messages
# when people update from versions still providing old message.



It is easy to forget setting FORCE_PRINT_ELOG, just as it is easy to
forget to unset it again.



An automatism is always preferable over a manual solution.


Maybe I want manual control? For example, when I fix a typo in the
README file then I don't want to show it to users again.


An automatism does not exclude an manual override. That can easily be 
added to greadme.eclass.




There seems to be a big win-win if we override the compression
settingin this case.


I tend to disagree. We shouldn't override users' choices unless
absolutely necessary.


Just that there is no misunderstanding: you are aware that it is a file 
of typically just a few lines of text that we are discussing here 
whether or not it should be compressed?


Seems like overshooting the mark to argue with users' choices in this case.

- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Florian Schmaus]

On 10/01/2024 14.58, Ulrich Mueller wrote:

On Wed, 10 Jan 2024, Florian Schmaus wrote:



On 10/01/2024 12.04, Sam James wrote:

1) The name seems odd (why not readme.gentoo-r2)?
2) Why can't the existing eclass be improved?



Both points, the name of the eclass and the question if this should be
added to the existing eclass or as a new eclass, are absolutely *no*
hill I want to die on.



What I *really* care about is having the functionality that there is a
readme eclass that *also* shows the elog message if the README's
content changed (and not just on the first installation of the
package).


Looks like readme.gentoo-r1 already gives you control over this:

# If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
# value in your ebuild before this function is called.
# This can be useful when, for example, DOC_CONTENTS is modified, then, you can
# rely on specific REPLACING_VERSIONS handling in your ebuild to print messages
# when people update from versions still providing old message.


It is easy to forget setting FORCE_PRINT_ELOG, just as it is easy to 
forget to unset it again.


An automatism is always preferable over a manual solution.



4) The compression deal seems not worth bothering with.



Just to clarify: you are agreeing that excluding the readme doc from
being compressed is fine?


Please respect the user's compression settings there. IMHO overriding
them with docompress -x is a big no-no.


Then why does "docompress -x" exist at all?

There seems to be a big win-win if we override the compression settingin 
this case.




It exports phase functions, which readme.gentoo-r1 does not.


Looking at the history, readme.gentoo[-r0] used to export phase
functions:
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/readme.gentoo.eclass?id=1e7b2242de29ec60105df1ef31939aed85a8b0eb#n32
It turned out to be a bad design choice, so -r1 no longer does that.


Interesting find.

It is not obvious to me why the eclass exporting phase function should 
is a bad design choice.


@pacho: could you shed some light into this?



The readme.gentoo-r1 eclass always shoves the full content of the
readme into an environment variable.


Why is this a problem?


Nobody described that as a problem. Not adding stuff into the 
environment is simply nice to have.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Florian Schmaus]

On 10/01/2024 12.04, Sam James wrote:


Florian Schmaus  writes:


I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-specific information about a package to
the user. Especially as it improves the signal-to-noise ratio of
messages arriving to our users.

However, readme.gentoo-r1.eclass will only show this information on
new installs, but not if the information changed. This is a major
drawback. Furthermore, readme.gentoo-r1.eclass does not provide an API
to assemble the information via heredoc.

The following patch includes a new eclass named "greadme", that
addresses those shortcomings of readme.gentoo-r1.eclass and hopefully
can be seen as a general overhaul.


I have a few concerns at the moment, but of varying severity:



1) The name seems odd (why not readme.gentoo-r2)? > 2) Why can't the existing 
eclass be improved?


Both points, the name of the eclass and the question if this should be 
added to the existing eclass or as a new eclass, are absolutely *no* 
hill I want to die on.


What I *really* care about is having the functionality that there is a 
readme eclass that *also* shows the elog message if the README's content 
changed (and not just on the first installation of the package).



> 4) The compression deal seems not worth bothering with.

Just to clarify: you are agreeing that excluding the readme doc from 
being compressed is fine?




3) Is the reason for 2) strong enough to introduce a new eclass?
I don't really want to see a bifurcation in our README eclasses
if we can help it. Porting to something new takes ages and it's
a lot of churn.


I think the arguments for introducing a new eclass are strong enough. I 
will elaborate on this in the appendix of this mail, since I don't think 
its what we should focus on at the moment.


However, right now I want clarify that using "docompress -x" in this 
case is agreeable by everyone.


- Flow


# Appendix: Arguments for introducing a new class

readme.gentoo-r1 can be viewed at

https://github.com/gentoo/gentoo/blob/master/eclass/readme.gentoo-r1.eclass

while the simple and short version (203 lines including comments!) of 
the proposed greadme.eclass can be seen at


https://github.com/Flowdalic/gentoo/blob/greadme.eclass-simple/eclass/greadme.eclass

The proposed API of the greadme eclass is already different from 
readme.gentoo-r1. It exports phase functions, which readme.gentoo-r1 
does not. The readme.gentoo-r1 eclass always shoves the full content of 
the readme into an environment variable. Excluding the readme file from 
compression means we do not have to do that in greadme.


Please feel invited take a look at the code of both eclasses and make 
yourself an opinion if it is sensible to incorporate greadme.eclass into 
the existing eclass.


Then maybe also also look a the API of both eclasses. Switching from 
readme.gentoo-r1 to greadme is simple and straightforward in most cases.


Furthermore, the name readme.gentoo-r1 seems odd, it is one of the few 
eclasses that use a dot as separator (although, I can see why this may 
been done). Looking at eclasses/ it appears that readme-gentoo-r1.eclass 
would be more in-line with the existing eclasses. Or, as a matter of 
opinion, maybe better, because shorter: greadme


Adding a new readme eclass hopefully is not a bifurcation, cause we 
ideally would be able to phase out readme.gentoo-r1.






OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New category: dev-debug

[Florian Schmaus]

On 10/01/2024 12.01, Sam James wrote:


Florian Schmaus  writes:


[[PGP Signed Part:Undecided]]
On 07/01/2024 13.48, Michał Górny wrote:

Hi,
I'd like to propose adding a new dev-debug category.  The
description
could be:
Code debuggers and debugging-related tools.


Seems sensible. I'd probably drop the "Code" from the description,
since packages like d-spy do not primarily debug code.

I assume profilers are explicitly not part of this category?


leio had the same question and we came up with a list of about 5-6
packages at least which would fit in a dev-profile category...


Right and a sensible next step would probably be an extra category for 
those.


The problem is that that the lines between profilers, tracers, and 
performance counter tools sometimes gets blurry. But I think it could be 
fine to shove those all into one category, but maybe dev-perf then 
(e.g., "Tools for performance analysis")?


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New category: dev-debug

[Florian Schmaus]

On 07/01/2024 13.48, Michał Górny wrote:

Hi,

I'd like to propose adding a new dev-debug category.  The description
could be:

   Code debuggers and debugging-related tools.


Seems sensible. I'd probably drop the "Code" from the description, since 
packages like d-spy do not primarily debug code.


I assume profilers are explicitly not part of this category?

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v2 1/3] greadme.eclass: new eclass

[Florian Schmaus]

On 09/01/2024 12.23, David Seifert wrote:

On Tue, 2024-01-09 at 09:39 +0100, Florian Schmaus wrote:

This new eclass is similar to readme.gentoo-r1.eclass. The main
differences are as follows. Firstly, it also displays the doc file
contents if they have changed. Secondly, it provides a convenient API
to
install the doc file via stdin.

Furthermore, this eclass dos not store the doc file's contents in an
environment variable, which helps to keep the environment size of
ebuilds using the eclass small.

Signed-off-by: Florian Schmaus 
---
  eclass/greadme.eclass | 307
++
  1 file changed, 307 insertions(+)
  create mode 100644 eclass/greadme.eclass

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
new file mode 100644
index ..25e0210406c1
--- /dev/null
+++ b/eclass/greadme.eclass
@@ -0,0 +1,307 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 
+# @SUPPORTED_EAPIS: 6 7 8
+# @BLURB: install a doc file, that will be conditionally shown via
elog messages
+# @DESCRIPTION:
+# An eclass for installing a README.gentoo doc file recording tips
+# shown via elog messages.  With this eclass, those elog messages
will only be
+# shown at first package installation or if the contents of the file
have changed.
+# Furthermore, a file for later reviewing will be installed under
+# /usr/share/doc/${PF}
+#
+# This eclass is similar to readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it also displays the doc file
+# contents if they have changed.  Secondly, it provides a convenient
API to
+# install the doc file via stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   …
+#   greadme_stdin <<- EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   …
+#   if use foo; then
+# greadme_stdin --apend <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# You must call greadme_pkg_preinst and greadme_pkg_postinst
explicitly, if
+# you override the default pkg_preinst or respectively pkg_postinst.
+#
+# TODO:
+# - Should this be named README.Distribution instead of
README.Gentoo?
+#   Would that make things easier for Gentoo derivates?
+#   Similary, (g → d)readme, (G → D)README?
+# - Incooperate changes into readme.gentoo-r1.elcass?
+# - Compressing the readme doc file is probably fragile, as it is not
+#   guaranteed that the required binaries for decompression are
installed
+#   in pkg_preinst/pkg_postinst. Note that it is even possible that
two
+#   different compression algorithms are used, in case of binpkgs.
+
+if [[ -z ${_README_GENTOO_ECLASS} ]]; then
+_README_GENTOO_ECLASS=1
+
+case ${EAPI} in
+   6|7|8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ ${_GREADME_COMPRESS} ]]; then
+   inherit unpacker
+fi
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_REL_PATH="usr/share/doc/${PF}/${_GREADME_FILENAME}"
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to
an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append=false
+   while [[ -n ${1} ]] && [[ ${1} =~ --* ]]; do
+   case ${1} in
+   --append)
+   append=true
+   shift
+   ;;
+   esac
+   done
+
+   if $append; then
+   if [[ ! -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README does not exist when trying
to append to it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists while
trying to create it"
+   fi
+
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+greadme_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z "${input_doc_file}" ]]; then
+   die "No file specified"
+   fi
+
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: _greadme_install_doc

Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Florian Schmaus]

On 09/01/2024 11.43, Michał Górny wrote:

On Tue, 2024-01-09 at 11:39 +0100, Florian Schmaus wrote:

Even if we say it is the user's fault, then the problem of handling a
decompressor failure would still exist. The eclass does not gracefully
continue when decompressing the doc file, but instead it runs into a
die(). To address this we would need to make unpacker.eclass and
unpack() aware of nonfatal. The latter would require a PMS change.

Or, I could duplicate unpack logic --- which is probably a lot to
account for the various compression options --- in the eclass. But I
suspect be both do not want that.


Perhaps this is the moment when you realize that there is no guarantee
that unpacker.eclass and/or unpack will support the compression format
set for docompress.  The two were never intended to interact.


Hence I wrote about making then nonfatal aware. Then greadme.eclass 
could try to opportunistically decompress the doc file, and simply 
continue with a sensible behavior it it fails.


A look at the greadme code reveals that it tries to do so already, but 
unfortunately unsuccessfully because nonfatal has no effect on 
unpacker/unpack.


- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Florian Schmaus]

On 09/01/2024 10.59, Michał Górny wrote:

On Tue, 2024-01-09 at 09:30 +0100, Florian Schmaus wrote:

On 06/01/2024 18.21, Michał Górny wrote:

On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote:

I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-specific information about a package to
the user. Especially as it improves the signal-to-noise ratio of
messages arriving to our users.

However, readme.gentoo-r1.eclass will only show this information on
new installs, but not if the information changed. This is a major
drawback. Furthermore, readme.gentoo-r1.eclass does not provide an API
to assemble the information via heredoc.


Are you implying that readme.gentoo-r1 is unfixable and you need to
start over, and have a third generation of eclasses to install a readme
file?


Not at all. See the second item of the TODO list in the eclass' description.

That said, both eclasses are rather small,



Since when, 300 lines to install a README file is "small"?


The eclass becomes very small if you remove the _GREADME_COMPRESS code. 
As I wrote, adding compression support to the eclass makes the code very 
complex.




The main item is doc compression. Right now, greadme.eclass defaults
to add the readme doc to the compression exclusion list via
"docompress -x". A mode where the readme doc is compressed, just as
readme.gentoo-r1.eclass does, can be activated by setting
_GREADME_COMPRESS. However, I believe this mode is fragile as it can
not be guaranteed that a binary for the used compression algorithms is
installed on the host [1].


Dangling reference here.  In any case, documentation compression is
a standard feature of the package manager.  If it doesn't work for
whatever reason, I'd rather see you focus on find a good solution rather
than working it around via abusing `docompress -x`.


The problem is the lack of a guarantee that the utilities required to
decompress the file are available at installation time.


It's user's responsibility to ensure that the tools set in their
make.conf are available.


What if the user obtained a binpkg that was compressed with a different 
algorithm than the one set in their make.conf? Of course, the binhost 
could have set FEATURES=-binpkg-docompress, but what if not?


Even if we say it is the user's fault, then the problem of handling a 
decompressor failure would still exist. The eclass does not gracefully 
continue when decompressing the doc file, but instead it runs into a 
die(). To address this we would need to make unpacker.eclass and 
unpack() aware of nonfatal. The latter would require a PMS change.


Or, I could duplicate unpack logic --- which is probably a lot to 
account for the various compression options --- in the eclass. But I 
suspect be both do not want that.




It gets even worse if you consider binpkgs, as you have surely read the
comment while looking at the code of the greadme.eclass.


See FEATURES=-binpkg-docompress.  That's the correct way to distribute
binary packages.


Is that documented somewhere that this is the right way to distribute 
binary packages?



With the information I have right now, I do not see a better alternative 
than excluding the doc file from compression.


Are you willing a sacrifice a very sensible feature just to be able to 
compress what is usually a file of a few hundred of bytes?




- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH v2 2/3] add UNPACKER_NO_BANNER variable

[Florian Schmaus]

On 09/01/2024 09.39, Florian Schmaus wrote:

Signed-off-by: Florian Schmaus 
---
  eclass/-cover-letter.patch  |  49 
  eclass/0001-greadme.eclass-new-eclass.patch | 305 


Ignore those to patch files. They are accidentally added to the commit.



diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
index 2957ca02d3f4..73b763ca2018 100644
--- a/eclass/unpacker.eclass
+++ b/eclass/unpacker.eclass
@@ -42,6 +42,11 @@ inherit multiprocessing toolchain-funcs
  # `xz`, `plzip`, `pdlzip`, and `lzip`.  Make sure your choice accepts the 
"-dc" options.
  # Note: this is meant for users to set, not ebuilds.
  
+# @ECLASS_VARIABLE: UNPACKER_NO_BANNER

+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set, do not display the unpack banner with information what got unpacked 
where.
+
  # for internal use only (unpack_pdv and unpack_makeself)
  find_unpackable_file() {
local src=$1
@@ -63,6 +68,8 @@ find_unpackable_file() {
  }
  
  unpack_banner() {

+   [[ ${UNPACKER_NO_BANNER} ]] && return
+
echo ">>> Unpacking ${1##*/} to ${PWD}"
  }

Also note that this only prevents the banner emitted by the 
unpacker.eclass. The eclass also invokes unpack() from PMS/portage, 
emitting a banner which can not be disabled via the eclass.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH v2 3/3] greadme.eclass: set UNPACKER_NO_BANNER

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/greadme.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
index 25e0210406c1..ec01d090cc10 100644
--- a/eclass/greadme.eclass
+++ b/eclass/greadme.eclass
@@ -174,7 +174,7 @@ greadme_pkg_preinst() {
if [[ "${image_doc_file_basename}" == "${_GREADME_FILENAME}" 
]]; then
cp "${image_doc_file}" . || die
else
-   nonfatal unpacker "${image_doc_file}"
+   UNPACKER_NO_BANNER=1 nonfatal unpacker 
"${image_doc_file}"
if [[ $? -gt 0 ]]; then
# We failed to unpack the readme doc from the
# image, therefore, we can't show it (unless we
@@ -222,7 +222,7 @@ greadme_pkg_preinst() {
if [[ "${live_doc_file_basename}" == 
"${_GREADME_FILENAME}" ]]; then
cp "${live_doc_file}" .
else
-   nonfatal unpacker "${live_doc_file}"
+   UNPACKER_NO_BANNER=1 nonfatal unpacker 
"${live_doc_file}"
if [[ $? -gt 0 ]]; then
# We failed to unpack the live readme 
doc, fallback
# to show the new readme contents.
-- 
2.41.0

[gentoo-dev] [PATCH v2 2/3] add UNPACKER_NO_BANNER variable

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/-cover-letter.patch  |  49 
 eclass/0001-greadme.eclass-new-eclass.patch | 305 
 eclass/unpacker.eclass  |   7 +
 3 files changed, 361 insertions(+)
 create mode 100644 eclass/-cover-letter.patch
 create mode 100644 eclass/0001-greadme.eclass-new-eclass.patch

diff --git a/eclass/-cover-letter.patch b/eclass/-cover-letter.patch
new file mode 100644
index ..2e162d419a44
--- /dev/null
+++ b/eclass/-cover-letter.patch
@@ -0,0 +1,49 @@
+From edff06160e33b361c9d6a7e273fc7808337c4518 Mon Sep 17 00:00:00 2001
+From: Florian Schmaus 
+Date: Sat, 6 Jan 2024 17:44:44 +0100
+Subject: [PATCH 0/1] [RFC] greadme.eclass
+
+I really like the functionality of readme.gentoo-r1.eclass, as it
+allows to communicate Gentoo-specific information about a package to
+the user. Especially as it improves the signal-to-noise ratio of
+messages arriving to our users.
+
+However, readme.gentoo-r1.eclass will only show this information on
+new installs, but not if the information changed. This is a major
+drawback. Furthermore, readme.gentoo-r1.eclass does not provide an API
+to assemble the information via heredoc.
+
+The following patch includes a new eclass named "greadme", that
+addresses those shortcomings of readme.gentoo-r1.eclass and hopefully
+can be seen as a general overhaul.
+
+This is a first draft of the eclass and therefore I'd like to ask for
+feedback.
+
+The greadme.eclass contains some TODO items at the end of its
+@DESCRIPTION.
+
+The main item is doc compression. Right now, greadme.eclass defaults
+to add the readme doc to the compression exclusion list via
+"docompress -x". A mode where the readme doc is compressed, just as
+readme.gentoo-r1.eclass does, can be activated by setting
+_GREADME_COMPRESS. However, I believe this mode is fragile as it can
+not be guaranteed that a binary for the used compression algorithms is
+installed on the host [1].
+
+I believe it is reasonable to simply install the readme doc
+uncompressed, since they are typically only a few lines long. However,
+if anyone can point out a way to achieve the desired functionality with
+a compressed readme doc, then please let me know.
+
+Thanks for reviewing the eclass.
+
+Florian Schmaus (1):
+  greadme.eclass: new eclass
+
+ eclass/greadme.eclass | 281 ++
+ 1 file changed, 281 insertions(+)
+ create mode 100644 eclass/greadme.eclass
+
+-- 
+2.41.0
diff --git a/eclass/0001-greadme.eclass-new-eclass.patch 
b/eclass/0001-greadme.eclass-new-eclass.patch
new file mode 100644
index ..52f4d9b6ff4d
--- /dev/null
+++ b/eclass/0001-greadme.eclass-new-eclass.patch
@@ -0,0 +1,305 @@
+From edff06160e33b361c9d6a7e273fc7808337c4518 Mon Sep 17 00:00:00 2001
+From: Florian Schmaus 
+Date: Sat, 6 Jan 2024 17:39:45 +0100
+Subject: [PATCH 1/1] greadme.eclass: new eclass
+
+This new eclass is similar to readme.gentoo-r1.eclass. The main
+differences are as follows. Firstly, it also displays the doc file
+contents if they have changed. Secondly, it provides a convenient API to
+install the doc file via stdin.
+
+Signed-off-by: Florian Schmaus 
+---
+ eclass/greadme.eclass | 281 ++
+ 1 file changed, 281 insertions(+)
+ create mode 100644 eclass/greadme.eclass
+
+diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
+new file mode 100644
+index ..ac83c36983ef
+--- /dev/null
 b/eclass/greadme.eclass
+@@ -0,0 +1,281 @@
++# Copyright 1999-2024 Gentoo Authors
++# Distributed under the terms of the GNU General Public License v2
++
++# @ECLASS: greadme.eclass
++# @MAINTAINER:
++# Florian Schmaus 
++# @AUTHOR:
++# Author: Florian Schmaus 
++# @SUPPORTED_EAPIS: 6 7 8
++# @BLURB: install a doc file, that will be conditionally shown via elog 
messages
++# @DESCRIPTION:
++# An eclass for installing a README.gentoo doc file recording tips
++# shown via elog messages.  With this eclass, those elog messages will only be
++# shown at first package installation or if the contents of the file have 
changed.
++# Furthermore, a file for later reviewing will be installed under
++# /usr/share/doc/${PF}
++#
++# This eclass is similar to readme.gentoo-r1.eclass.  The main
++# differences are as follows.  Firstly, it also displays the doc file
++# contents if they have changed.  Secondly, it provides a convenient API to
++# install the doc file via stdin.
++#
++# @CODE
++# inherit greadme
++#
++# src_install() {
++#   …
++#   greadme_stdin <<- EOF
++#   This is the content of the created readme doc file.
++#   EOF
++#   …
++#   if use foo; then
++# greadme_stdin --apend <<-EOF
++# This is conditional readme content, based on USE=foo.
++# EOF
++#   fi
++# }
++# @CODE
++#
++# You must call greadme_pkg_preinst and greadme_pkg_postinst explicitly, if
++# you override the default pkg_preinst or re

[gentoo-dev] [PATCH v2 1/3] greadme.eclass: new eclass

[Florian Schmaus]

This new eclass is similar to readme.gentoo-r1.eclass. The main
differences are as follows. Firstly, it also displays the doc file
contents if they have changed. Secondly, it provides a convenient API to
install the doc file via stdin.

Furthermore, this eclass dos not store the doc file's contents in an
environment variable, which helps to keep the environment size of
ebuilds using the eclass small.

Signed-off-by: Florian Schmaus 
---
 eclass/greadme.eclass | 307 ++
 1 file changed, 307 insertions(+)
 create mode 100644 eclass/greadme.eclass

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
new file mode 100644
index ..25e0210406c1
--- /dev/null
+++ b/eclass/greadme.eclass
@@ -0,0 +1,307 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 
+# @SUPPORTED_EAPIS: 6 7 8
+# @BLURB: install a doc file, that will be conditionally shown via elog 
messages
+# @DESCRIPTION:
+# An eclass for installing a README.gentoo doc file recording tips
+# shown via elog messages.  With this eclass, those elog messages will only be
+# shown at first package installation or if the contents of the file have 
changed.
+# Furthermore, a file for later reviewing will be installed under
+# /usr/share/doc/${PF}
+#
+# This eclass is similar to readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it also displays the doc file
+# contents if they have changed.  Secondly, it provides a convenient API to
+# install the doc file via stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   …
+#   greadme_stdin <<- EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   …
+#   if use foo; then
+# greadme_stdin --apend <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# You must call greadme_pkg_preinst and greadme_pkg_postinst explicitly, if
+# you override the default pkg_preinst or respectively pkg_postinst.
+#
+# TODO:
+# - Should this be named README.Distribution instead of README.Gentoo?
+#   Would that make things easier for Gentoo derivates?
+#   Similary, (g → d)readme, (G → D)README?
+# - Incooperate changes into readme.gentoo-r1.elcass?
+# - Compressing the readme doc file is probably fragile, as it is not
+#   guaranteed that the required binaries for decompression are installed
+#   in pkg_preinst/pkg_postinst. Note that it is even possible that two
+#   different compression algorithms are used, in case of binpkgs.
+
+if [[ -z ${_README_GENTOO_ECLASS} ]]; then
+_README_GENTOO_ECLASS=1
+
+case ${EAPI} in
+   6|7|8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ ${_GREADME_COMPRESS} ]]; then
+   inherit unpacker
+fi
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_REL_PATH="usr/share/doc/${PF}/${_GREADME_FILENAME}"
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append=false
+   while [[ -n ${1} ]] && [[ ${1} =~ --* ]]; do
+   case ${1} in
+   --append)
+   append=true
+   shift
+   ;;
+   esac
+   done
+
+   if $append; then
+   if [[ ! -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README does not exist when trying to append 
to it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists while trying to 
create it"
+   fi
+
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+greadme_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z "${input_doc_file}" ]]; then
+   die "No file specified"
+   fi
+
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: _greadme_install_doc
+# @INTERNAL
+# @DESCRIPTION:
+# Installs the readme file from the temp directory into the image.
+_greadme_in

Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Florian Schmaus]

On 06/01/2024 18.21, Michał Górny wrote:

On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote:

I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-specific information about a package to
the user. Especially as it improves the signal-to-noise ratio of
messages arriving to our users.

However, readme.gentoo-r1.eclass will only show this information on
new installs, but not if the information changed. This is a major
drawback. Furthermore, readme.gentoo-r1.eclass does not provide an API
to assemble the information via heredoc.


Are you implying that readme.gentoo-r1 is unfixable and you need to
start over, and have a third generation of eclasses to install a readme
file?


Not at all. See the second item of the TODO list in the eclass' description.

That said, both eclasses are rather small, and "fixing" readme.gentoo-r1 
would consist of copying most of greadme into readme.gentoo-r1, while 
still having the "legacy" readme.gentoo-r1 functionality in it.


Starting over strikes me as sensible in this case.



The main item is doc compression. Right now, greadme.eclass defaults
to add the readme doc to the compression exclusion list via
"docompress -x". A mode where the readme doc is compressed, just as
readme.gentoo-r1.eclass does, can be activated by setting
_GREADME_COMPRESS. However, I believe this mode is fragile as it can
not be guaranteed that a binary for the used compression algorithms is
installed on the host [1].


Dangling reference here.  In any case, documentation compression is
a standard feature of the package manager.  If it doesn't work for
whatever reason, I'd rather see you focus on find a good solution rather
than working it around via abusing `docompress -x`.  


The problem is the lack of a guarantee that the utilities required to 
decompress the file are available at installation time.


It gets even worse if you consider binpkgs, as you have surely read the 
comment while looking at the code of the greadme.eclass.



> It's basically
> a case of "standard feature X doesn't work for me sometimes, so I now
> randomly disable X via my eclass, and hope nobody notices".

The primary motivation for posting this RFC was to find a solution and 
avoid the "docompress -x" approach. However, I don't think there is one 
that does not require adjusting PMS to provide the guarantee that the 
eclass can decompress the compressed doc file.


Adjusting PMS seems overkill just for avoiding to exclude a single small 
file from compression.


I also tried to make the greadme eclass handle unpacking errors 
gracefully. This turned out to be harder than I hoped because most 
(all?) functions of unpacker.eclass are not nonfatal compatible. The 
same is true for unpack() from PMS, which is used by unpacker.eclass.


I'll send out v2 of greadme.eclass soon.

Looking at the conditional _GREADME_COMPRESS code, you will find that 
adding support for compressing the doc file introduces a lot of 
complexity to the eclass. That would still make me consider it, but I 
can not see any reliable approach to unpacking that does not involve 
adjusting PMS.


Surely you would be able to correct me if I am wrong.



I believe it is reasonable to simply install the readme doc
uncompressed, since they are typically only a few lines long. However,
if anyone can point out a way to achieve the desired functionality with
a compressed readme doc, then please let me know.


The compression mechanism automatically detects when the file is too
small to be worth compressing.  See PORTAGE_DOCOMPRESS_SIZE_LIMIT.


How is this mechanism helpful here?

- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 1/1] greadme.eclass: new eclass

[Florian Schmaus]

This new eclass is similar to readme.gentoo-r1.eclass. The main
differences are as follows. Firstly, it also displays the doc file
contents if they have changed. Secondly, it provides a convenient API to
install the doc file via stdin.

Signed-off-by: Florian Schmaus 
---
 eclass/greadme.eclass | 281 ++
 1 file changed, 281 insertions(+)
 create mode 100644 eclass/greadme.eclass

diff --git a/eclass/greadme.eclass b/eclass/greadme.eclass
new file mode 100644
index ..ac83c36983ef
--- /dev/null
+++ b/eclass/greadme.eclass
@@ -0,0 +1,281 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: greadme.eclass
+# @MAINTAINER:
+# Florian Schmaus 
+# @AUTHOR:
+# Author: Florian Schmaus 
+# @SUPPORTED_EAPIS: 6 7 8
+# @BLURB: install a doc file, that will be conditionally shown via elog 
messages
+# @DESCRIPTION:
+# An eclass for installing a README.gentoo doc file recording tips
+# shown via elog messages.  With this eclass, those elog messages will only be
+# shown at first package installation or if the contents of the file have 
changed.
+# Furthermore, a file for later reviewing will be installed under
+# /usr/share/doc/${PF}
+#
+# This eclass is similar to readme.gentoo-r1.eclass.  The main
+# differences are as follows.  Firstly, it also displays the doc file
+# contents if they have changed.  Secondly, it provides a convenient API to
+# install the doc file via stdin.
+#
+# @CODE
+# inherit greadme
+#
+# src_install() {
+#   …
+#   greadme_stdin <<- EOF
+#   This is the content of the created readme doc file.
+#   EOF
+#   …
+#   if use foo; then
+# greadme_stdin --apend <<-EOF
+# This is conditional readme content, based on USE=foo.
+# EOF
+#   fi
+# }
+# @CODE
+#
+# You must call greadme_pkg_preinst and greadme_pkg_postinst explicitly, if
+# you override the default pkg_preinst or respectively pkg_postinst.
+#
+# TODO:
+# - Should this be named README.Distribution instead of README.Gentoo?
+#   Would that make things easier for Gentoo derivates?
+#   Similary, (g → d)readme, (G → D)README?
+# - Incooperate changes into readme.gentoo-r1.elcass?
+# - Compressing the readme doc file is probably fragile, as it is not
+#   guaranteed that the required binaries for decompression are installed
+#   in pkg_preinst/pkg_postinst. Note that it is even possible that two
+#   different compression algorithms are used, in case of binpkgs.
+
+if [[ -z ${_README_GENTOO_ECLASS} ]]; then
+_README_GENTOO_ECLASS=1
+
+case ${EAPI} in
+   6|7|8) ;;
+   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ ${_GREADME_COMPRESS} ]]; then
+   inherit unpacker
+fi
+
+_GREADME_FILENAME="README.gentoo"
+_GREADME_TMP_FILE="${T}/${_GREADME_FILENAME}"
+_GREADME_REL_PATH="usr/share/doc/${PF}/${_GREADME_FILENAME}"
+
+# @FUNCTION: greadme_stdin
+# @USAGE: [--append]
+# @DESCRIPTION:
+# Create the readme doc via stdin.  You can use --append to append to an
+# existing readme doc.
+greadme_stdin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local append=false
+   while [[ -n ${1} ]] && [[ ${1} =~ --* ]]; do
+   case ${1} in
+   --append)
+   append=true
+   shift
+   ;;
+   esac
+   done
+
+   if $append; then
+   if [[ ! -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README does not exist when trying to append 
to it"
+   fi
+
+   cat >> "${_GREADME_TMP_FILE}" || die
+   else
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists"
+   fi
+
+   cat > "${_GREADME_TMP_FILE}" || die
+   fi
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: greadme_file
+# @USAGE: 
+# @DESCRIPTION:
+# Installs the provided file as readme doc.
+greadme_file() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local input_doc_file="${1}"
+   if [[ -z "${input_doc_file}" ]]; then
+   die "No file specified"
+   fi
+
+   if [[ -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README already exists"
+   fi
+
+   cp "${input_doc_file}" "${_GREADME_TMP_FILE}" || die
+
+   _greadme_install_doc
+}
+
+# @FUNCTION: _greadme_install_doc
+# @INTERNAL
+# @DESCRIPTION:
+# Installs the readme file from the temp directory into the image.
+_greadme_install_doc() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   if [[ ! -f "${_GREADME_TMP_FILE}" ]]; then
+   die "Gentoo README does not exist"
+  

[gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Florian Schmaus]

I really like the functionality of readme.gentoo-r1.eclass, as it
allows to communicate Gentoo-specific information about a package to
the user. Especially as it improves the signal-to-noise ratio of
messages arriving to our users.

However, readme.gentoo-r1.eclass will only show this information on
new installs, but not if the information changed. This is a major
drawback. Furthermore, readme.gentoo-r1.eclass does not provide an API
to assemble the information via heredoc.

The following patch includes a new eclass named "greadme", that
addresses those shortcomings of readme.gentoo-r1.eclass and hopefully
can be seen as a general overhaul.

This is a first draft of the eclass and therefore I'd like to ask for
feedback.

The greadme.eclass contains some TODO items at the end of its
@DESCRIPTION.

The main item is doc compression. Right now, greadme.eclass defaults
to add the readme doc to the compression exclusion list via
"docompress -x". A mode where the readme doc is compressed, just as
readme.gentoo-r1.eclass does, can be activated by setting
_GREADME_COMPRESS. However, I believe this mode is fragile as it can
not be guaranteed that a binary for the used compression algorithms is
installed on the host [1].

I believe it is reasonable to simply install the readme doc
uncompressed, since they are typically only a few lines long. However,
if anyone can point out a way to achieve the desired functionality with
a compressed readme doc, then please let me know.

Thanks for reviewing the eclass.

Florian Schmaus (1):
  greadme.eclass: new eclass

 eclass/greadme.eclass | 281 ++
 1 file changed, 281 insertions(+)
 create mode 100644 eclass/greadme.eclass

-- 
2.41.0

Re: [gentoo-dev] [RFC] global USE=gpg

[Florian Schmaus]

On 30/12/2023 16.54, Andreas K. Huettel wrote:

we have many local gpg useflags which basically just enable gpg.
Should we merge these to one global useflag?

Additionally we have a few gpgme useflags.
See also https://bugs.gentoo.org/679634

What are your ideas?



We have also have a bunch of USE=pgp and USE=openpgp, both of which are
more correct than USE=gpg.


I am always confused when people use "gpg" to talk about OpenPGP.



Yeah, typical case of "formally correct thing being way more difficult to
understand than colloquially practical thing" ...


It is only a matter of time until the more users of gnupg-alternative 
libraries, like sequoia or librnp, appear. USE=gpg is probably already 
sometimes a misnomer, and will definitely be one if we make it a global 
USE flag and there are packages that declare it without pulling in gpg.


- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] webapp.eclass: optimize webapp_serverowned() and inlining webapp_strip_*()

[Florian Schmaus]

Some ebuilds invoke webapp_serverowned with -r, causing the eclass to
iterate over a large set of files. Within the iteration body, the eclass
forks multiple times to invoke the webapp_strip.

This optimizes webapp_serverowned() by replacing the call to the "strip"
functions with an equivalent invocation of find that iterates over all
the files.

Furthermore, all remaining invocations of webapp_strip_*() are inlined.

Closes: https://bugs.gentoo.org/781860
Signed-off-by: Florian Schmaus 
---
 eclass/webapp.eclass | 40 
 1 file changed, 16 insertions(+), 24 deletions(-)

diff --git a/eclass/webapp.eclass b/eclass/webapp.eclass
index 8bd8e2aef03e..5b091c84851f 100644
--- a/eclass/webapp.eclass
+++ b/eclass/webapp.eclass
@@ -96,21 +96,6 @@ webapp_check_installedat() {
${WEBAPP_CONFIG} --show-installed -h localhost -d "${INSTALL_DIR}" 2> 
/dev/null
 }
 
-webapp_strip_appdir() {
-   debug-print-function $FUNCNAME $*
-   echo "${1#${MY_APPDIR}/}"
-}
-
-webapp_strip_d() {
-   debug-print-function $FUNCNAME $*
-   echo "${1#${D}}"
-}
-
-webapp_strip_cwd() {
-   debug-print-function $FUNCNAME $*
-   echo "${1/#.\///}"
-}
-
 webapp_getinstalltype() {
debug-print-function $FUNCNAME $*
 
@@ -195,8 +180,11 @@ webapp_configfile() {
for m in "$@"; do
webapp_checkfileexists "${m}" "${D}"
 
-   local my_file="$(webapp_strip_appdir "${m}")"
-   my_file="$(webapp_strip_cwd "${my_file}")"
+   local my_file
+   # Strip appdir
+   my_file="${m#${MY_APPDIR}/}"
+   # Strip cwd
+   my_file="${my_file/#.\///}"
 
elog "(config) ${my_file}"
echo "${my_file}" >> "${D}/${WA_CONFIGLIST}"
@@ -249,8 +237,11 @@ _webapp_serverowned() {
debug-print-function $FUNCNAME $*
 
webapp_checkfileexists "${1}" "${D}"
-   local my_file="$(webapp_strip_appdir "${1}")"
-   my_file="$(webapp_strip_cwd "${my_file}")"
+   local my_file
+   # Strip appdir
+   my_file="${1#${MY_APPDIR}/}"
+   # Strip cwd
+   my_file="${my_file/#.\///}"
 
echo "${my_file}" >> "${D}/${WA_SOLIST}"
 }
@@ -264,14 +255,15 @@ _webapp_serverowned() {
 webapp_serverowned() {
debug-print-function $FUNCNAME $*
 
-   local a m
+   local m
if [[ "${1}" == "-R" ]]; then
shift
for m in "$@"; do
-   find "${D}${m}" | while read a; do
-   a=$(webapp_strip_d "${a}")
-   _webapp_serverowned "${a}"
-   done
+   pushd "${D}${MY_APPDIR}" > /dev/null || die
+   # Strip appdir
+   m="${m#${MY_APPDIR}/}"
+   find "${m}" >> "${D}/${WA_SOLIST}" || die
+   popd > /dev/null || die
done
else
for m in "$@"; do
-- 
2.41.0

[gentoo-dev] Last rites: acct-{user,group}/{tpm,ultimaker} acct-group/systemd-hostname

[Florian Schmaus]

# Florian Schmaus  (2023-10-14)
# Obsolete acct-* packages that became leaf packages.
# Removal on 2023-11-14.
acct-user/tpm
acct-group/tpm
acct-user/ultimaker
acct-group/ultimaker
acct-group/systemd-hostname

- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 3/3] meson.eclass: use get_makeopts_{jobs,loadavg}

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/meson.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 5aff3eb58930..4757f3fa5eef 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -388,8 +388,8 @@ meson_src_compile() {
 
local mesoncompileargs=(
-C "${BUILD_DIR}"
-   --jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
-   --load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
+   --jobs "$(get_makeopts_jobs 0)"
+   --load-average "$(get_makeopts_loadavg 0)"
)
 
case ${MESON_VERBOSE} in
-- 
2.41.0

[gentoo-dev] [PATCH 2/3] ninja-utils.eclass: use get_makeopts_{jobs,loadavg}

[Florian Schmaus]

Signed-off-by: Florian Schmaus 
---
 eclass/ninja-utils.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
index 5a211e81131d..1af3df9f71e5 100644
--- a/eclass/ninja-utils.eclass
+++ b/eclass/ninja-utils.eclass
@@ -1,3 +1,4 @@
+
 # Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
@@ -72,7 +73,7 @@ esac
 # Get the value of NINJAOPTS, inferring them from MAKEOPTS if unset.
 get_NINJAOPTS() {
if [[ -z ${NINJAOPTS+set} ]]; then
-   NINJAOPTS="-j$(makeopts_jobs "${MAKEOPTS}" 999) 
-l$(makeopts_loadavg "${MAKEOPTS}" 0)"
+   NINJAOPTS="-j$(get_makeopts_jobs 999) -l$(get_makeopts_loadavg 
0)"
fi
echo "${NINJAOPTS}"
 }
-- 
2.41.0

[gentoo-dev] [PATCH 1/3] multiprocessing.eclass: consider (GNU)MAKEFLAGS, add get_makeopts_{jobs,loadavg}

[Florian Schmaus]

Since --load-average may not be found in other Make implementations
besides GNU Make, it is potentially found in GNUMAKEFLAGS and not in
MAKEOPTS.

Signed-off-by: Florian Schmaus 
---
 eclass/multiprocessing.eclass | 40 ---
 eclass/tests/multiprocessing_makeopts_jobs.sh | 24 ++-
 2 files changed, 57 insertions(+), 7 deletions(-)

diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
index e55be636a02c..0768e7cb1e1f 100644
--- a/eclass/multiprocessing.eclass
+++ b/eclass/multiprocessing.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: multiprocessing.eclass
@@ -64,17 +64,36 @@ get_nproc() {
fi
 }
 
+# @FUNCTION: get_all_makeopts
+# @INTERNAL
+# @DESCRIPTION:
+# Returns ${MAKEOPTS} ${GNUMAKEFLAGS} ${MAKEFLAGS}.
+_get_all_makeopts() {
+   echo "${MAKEOPTS} ${GNUMAKEFLAGS} ${MAKEFLAGS}"
+}
+
+# @FUNCTION: get_makeopts_jobs
+# @USAGE: [default-jobs]
+# @DESCRIPTION:
+# Return the number of jobs extracted from the make options (MAKEOPTS,
+# GNUMAKEFLAGS, MAKEFLAGS). If the make options do not specify a number,
+# then either the provided default is returned, or 1.
+get_makeopts_jobs() {
+   local makeopts="$(_get_all_makeopts)"
+   echo $(makeopts_jobs ${makeopts} ${1:-1})
+}
+
 # @FUNCTION: makeopts_jobs
 # @USAGE: [${MAKEOPTS}] [${inf:-$(( $(get_nproc) + 1 ))}]
 # @DESCRIPTION:
-# Searches the arguments (defaults to ${MAKEOPTS}) and extracts the jobs number
+# Searches the arguments (defaults are obtained via get_all_makeopts) and 
extracts the jobs number
 # specified therein.  Useful for running non-make tools in parallel too.
 # i.e. if the user has MAKEOPTS=-j9, this will echo "9" -- we can't return the
 # number as bash normalizes it to [0, 255].  If the flags haven't specified a
 # -j flag, then "1" is shown as that is the default `make` uses.  If the flags
 # specify -j without a number, ${inf} is returned (defaults to nproc).
 makeopts_jobs() {
-   [[ $# -eq 0 ]] && set -- "${MAKEOPTS}"
+   [[ $# -eq 0 ]] && set -- "$(_get_all_makeopts)"
# This assumes the first .* will be more greedy than the second .*
# since POSIX doesn't specify a non-greedy match (i.e. ".*?").
local jobs=$(echo " $* " | sed -r -n \
@@ -83,10 +102,21 @@ makeopts_jobs() {
echo ${jobs:-1}
 }
 
+# @FUNCTION: get_makeopts_loadavg
+# @USAGE: [default-loadavg]
+# @DESCRIPTION:
+# Return the value for the load-average extracted from the make options 
(MAKEOPTS,
+# GNUMAKEFLAGS, MAKEFLAGS).  If the make options do not specify a value, then
+# either the optional provided default is returned, or 999.
+get_makeopts_loadavg() {
+   local makeopts="$(_get_all_makeopts)"
+   echo $(makeopts_loadavg ${makeopts} ${1:-999})
+}
+
 # @FUNCTION: makeopts_loadavg
 # @USAGE: [${MAKEOPTS}] [${inf:-999}]
 # @DESCRIPTION:
-# Searches the arguments (defaults to ${MAKEOPTS}) and extracts the value set
+# Searches the arguments (defaults are obtained via get_all_makeopts()) and 
extracts the value set
 # for load-average. For make and ninja based builds this will mean new jobs are
 # not only limited by the jobs-value, but also by the current load - which 
might
 # get excessive due to I/O and not just due to CPU load.
@@ -95,7 +125,7 @@ makeopts_jobs() {
 # If no limit is specified or --load-average is used without a number, ${inf}
 # (defaults to 999) is returned.
 makeopts_loadavg() {
-   [[ $# -eq 0 ]] && set -- "${MAKEOPTS}"
+   [[ $# -eq 0 ]] && set -- "$(get_all_makeopts)"
# This assumes the first .* will be more greedy than the second .*
# since POSIX doesn't specify a non-greedy match (i.e. ".*?").
local lavg=$(echo " $* " | sed -r -n \
diff --git a/eclass/tests/multiprocessing_makeopts_jobs.sh 
b/eclass/tests/multiprocessing_makeopts_jobs.sh
index 37d5a7257775..56d73ef48b3c 100755
--- a/eclass/tests/multiprocessing_makeopts_jobs.sh
+++ b/eclass/tests/multiprocessing_makeopts_jobs.sh
@@ -1,5 +1,5 @@
 #!/bin/bash
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -9,7 +9,13 @@ inherit multiprocessing
 
 test-makeopts_jobs() {
local exp=$1; shift
-   tbegin "makeopts_jobs($1${2+; inf=${2}}) == ${exp}"
+   local targs
+   if [[ -v 1 ]]; then
+   targs="$1${2+; inf=${2}}"
+   else
+   targs="MAKEOPTS=\"${MAKEOPTS}\" 
GNUMAKEFLAGS=\"${GNUMAKEFLAGS}\" MAKEFLAGS=\"${MAKEFLAGS}\""
+   fi
+   tbegin "makeopts_jobs(${targs}) == ${exp}"
local indirect=$(M

[gentoo-dev] [PATCH 0/3] multiprocessing.eclass: consider (GNU)MAKEFLAGS

[Florian Schmaus]

We'd like portage to provide a sane default with of the "makeopts",
i.e., the maximum number of parallel jobs (--jobs) and the maximum
load average (--load-average) that build systems should try to
establish at once.

However, while --jobs is a pretty standard feature for Make-ish build
systems, --load-average is not. For example, it is not provided by BSD
Make. As such, it was decided that portage should set --load-average
in GNUMAKEFLAGS, instead of MAKEOPTS (see
https://marc.info/?l=gentoo-dev&m=169027605717531&w=2 and
https://github.com/gentoo/portage/pull/1072).

As a result, the multiprocessing.eclass should now also try to extract
the value for --jobs and --load-average not only from MAKEOPTS, but
also from (GNU)MAKEFLAGS.

While we add it, we also overhaul multiprocessing.eclass's API by
providing two new simple methods to extract the values:
get_multiprocessing_jobs() and get_multiprocessing_loadavg().

PR at https://github.com/gentoo/gentoo/pull/32385

Florian Schmaus (3):
  multiprocessing.eclass: consider (GNU)MAKEFLAGS, add
get_makeopts_{jobs,loadavg}
  ninja-utils.eclass: use get_makeopts_{jobs,loadavg}
  meson.eclass: use get_makeopts_{jobs,loadavg}

 eclass/meson.eclass   |  4 +-
 eclass/multiprocessing.eclass | 40 ---
 eclass/ninja-utils.eclass |  3 +-
 eclass/tests/multiprocessing_makeopts_jobs.sh | 24 ++-
 4 files changed, 61 insertions(+), 10 deletions(-)

-- 
2.41.0

[gentoo-dev] [PATCH 1/1] systemd.eclass: add systemd_install_dropin

[Florian Schmaus]

Closes: https://bugs.gentoo.org/876658
Signed-off-by: Florian Schmaus 
---
 eclass/systemd.eclass | 44 ++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index fbed387e0ca0..03d6a82fd310 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -1,4 +1,4 @@
-# Copyright 2011-2022 Gentoo Authors
+# Copyright 2011-2023 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: systemd.eclass
@@ -227,6 +227,48 @@ systemd_install_serviced() {
)
 }
 
+# @FUNCTION: systemd_install_dropin
+# @USAGE: [--user]  
+# @DESCRIPTION:
+# Install  as the dropin file .d/00gentoo.conf,
+# overriding the settings of .
+# Defaults to system unit dropins, unless --user is provided,
+# which causes the dropin to be installed for user units.
+# The required argument  may be '-', in which case the
+# file is read from stdin and  must also be specified.
+# @EXAMPLE:
+# systemd_install_dropin foo.service "${FILESDIR}/foo.service.conf"
+# systemd_install_dropin foo.service - <<-EOF
+#  [Service]
+#  RestartSec=120
+# EOF
+systemd_install_dropin() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local basedir
+   if [[ $# -ge 1 ]] && [[ $1 == "--user" ]]; then
+   basedir=$(_systemd_unprefix systemd_get_userunitdir)
+   shift 1
+   else
+   basedir=$(_systemd_unprefix systemd_get_systemunitdir)
+   fi
+
+   local unit=${1}
+   local src=${2}
+
+   [[ ${unit} ]] || die "No unit specified"
+   [[ ${src} ]] || die "No conf file specified"
+
+   # avoid potentially common mistake
+   [[ ${unit} == *.d ]] && die "Unit ${unit} must not have .d suffix"
+
+   (
+   insopts -m 0644
+   insinto "${basedir}/${unit}".d
+   newins "${src}" 00gentoo.conf
+   )
+}
+
 # @FUNCTION: systemd_enable_service
 # @USAGE:  
 # @DESCRIPTION:
-- 
2.41.0

[gentoo-dev] [PATCH 0/1] systemd.eclass: add systemd_install_dropin

[Florian Schmaus]

PR at https://github.com/gentoo/gentoo/pull/33089

Florian Schmaus (1):
  systemd.eclass: add systemd_install_dropin

 eclass/systemd.eclass | 44 ++-
 1 file changed, 43 insertions(+), 1 deletion(-)

-- 
2.41.0

[gentoo-dev] Re: Standard parsable format for profiles/package.mask file

[Florian Schmaus]

On 21/09/2023 21.40, Arthur Zamarin wrote:

If this is a last-rite message, the last line must list the last-rite
last date (removal date) and the last-rite bug number. You can also list


FWIW, I would assume the last-rite date to be the date where the 
package's last rites where initiated, i.e., where it was p.masked. The 
removal date would be the date on which the packages was cleaned from 
the tree.



other bugs relevant to the last-rite. So I think a format of: "Removal
on ${REMOVAL_DATE}.


I now we, myself included, often wrote "Removal on…", however, I wonder 
if we should reflect reality and write "Removal after…" instead.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

[Florian Schmaus]

On 22/09/2023 08.39, Florian Schmaus wrote:
Some, including me, consider timestamps without timezone specifiers to 
be in local time (either of the consumer or producer of the timestamp). 
Hence, if you really must have UTC here, then at least consider making 
it explicit my requiring the 'Z' timezone specifier.

I forgot the to include the motivation for doing so:

Timestamps with a timezone specifier make it clear to the producer of 
the timestamp that they should produce an offset-ed timestamp and make 
it evident to the consumer of the timestamp which timezone it is in.


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

[Florian Schmaus]

On 21/09/2023 23.48, Sam James wrote:

Ulrich Mueller  writes:

On Thu, 21 Sep 2023, Florian Schmaus wrote:

The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.

 



Can we drop this? Or, at least, relax this.


I think UTC makes a lot of sense in an international context like ours.


It does, but mostly if you also care about the hour and minute of the 
timestamp [1].




It also avoids flapping of the date between entries (i.e. a newer entry
having an older date than the previous one).


This appears to be mainly an esthetic issue (and probably also rarely 
happens).




the same time, I'd like us to standardise on UTC


But why? Which problem does it solve for p.mask entries?



I usually just enter my locale date here and like to avoid having to
think about that UTC is potentially in a different date. I also can
not remember any situation where the date being in UTC matters. Plus,
if you want accurate timestamps, then the git commit/author date is
here for you. :)


Users consume p.mask entries directly rather than via git.


Correct. But how many users reading p.mask entries thought about the 
timezone the date timestamp is in? I'd assume at most only a few, 
because it is not relevant to know if its +00 or +02 or -07.


Some, including me, consider timestamps without timezone specifiers to 
be in local time (either of the consumer or producer of the timestamp). 
Hence, if you really must have UTC here, then at least consider making 
it explicit my requiring the 'Z' timezone specifier (which, if you want 
to be ISO compatible, probably means that the timestamp must include 
HH:MM too).


- Flow


1: That is probably why I don't see a timezone specifier for calendar 
dates in ISO 8601.


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-dev] Re: Standard parsable format for profiles/package.mask file

[Florian Schmaus]

On 21/09/2023 21.40, Arthur Zamarin wrote:

Hi all

I want to suggest a standard format for profiles/package.mask, for
multiple reasons:


Sounds sensible. +1


The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.

 

Can we drop this? Or, at least, relax this.

I usually just enter my locale date here and like to avoid having to 
think about that UTC is potentially in a different date. I also can not 
remember any situation where the date being in UTC matters. Plus, if you 
want accurate timestamps, then the git commit/author date is here for 
you. :)


- Flow


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers

[Florian Schmaus]

On 17/09/2023 14.18, Alexander Neuwirth wrote:
Thanks. Instead of using the lang entry I can imagine these other 
approaches:


2. Adding something specific to GLEP 68, like `type="doi"> https...`. However that seems like a bit too much work for 
adding something that only a small subset of users (science) cares 
about.



  


sounds perfectly fine.

It would require (minor) adjustments to the schema and DTD. And besides 
that, packages that do not have a use for this information do not have 
to pay a cost. Hence, I am not sure why you assume its too much work.



Also integration of parsing with existing tools is an extra 
overhead.


Most XML parsers are non-strict. Which means that they ignore elements 
that they do not know. Therefore, the same argument as above can be 
made: tools that do not need to extract the information, should not 
require any adjustments.


- Flow



OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature