[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
On Wed, 2022-06-29 at 10:15 +0300, Joonas Niilola wrote: > > dev-libs/apr > dev-libs/apr-util These can be maintained as part of the Apache project. Hans signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 8/7] epatch.eclass: Drop support for EAPIs 0 to 5
Signed-off-by: Ulrich Müller
---
eclass/epatch.eclass | 90 ++--
1 file changed, 4 insertions(+), 86 deletions(-)
diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass
index 6a9c460da0a3..17526653673a 100644
--- a/eclass/epatch.eclass
+++ b/eclass/epatch.eclass
@@ -4,7 +4,7 @@
# @ECLASS: epatch.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
+# @SUPPORTED_EAPIS: 6
# @BLURB: easy patch application functions
# @DEPRECATED: eapply from EAPI 7
# @DESCRIPTION:
@@ -13,11 +13,9 @@
if [[ -z ${_EPATCH_ECLASS} ]]; then
-case ${EAPI:-0} in
- 0|1|2|3|4|5|6)
- ;;
- *)
- die "${ECLASS}: banned in EAPI=${EAPI}; use eapply* instead";;
+case ${EAPI} in
+ 6) ;;
+ *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
esac
inherit estack
@@ -386,85 +384,5 @@ epatch() {
: # everything worked
}
-case ${EAPI:-0} in
-0|1|2|3|4|5)
-
-# @ECLASS_VARIABLE: EPATCH_USER_SOURCE
-# @USER_VARIABLE
-# @DESCRIPTION:
-# Location for user patches, see the epatch_user function.
-# Should be set by the user. Don't set this in ebuilds.
-: ${EPATCH_USER_SOURCE:=${PORTAGE_CONFIGROOT%/}/etc/portage/patches}
-
-# @FUNCTION: epatch_user
-# @USAGE:
-# @DESCRIPTION:
-# Applies user-provided patches to the source tree. The patches are
-# taken from /etc/portage/patches//[:SLOT]/, where the
first
-# of these three directories to exist will be the one to use, ignoring
-# any more general directories which might exist as well. They must end
-# in ".patch" to be applied.
-#
-# User patches are intended for quick testing of patches without ebuild
-# modifications, as well as for permanent customizations a user might
-# desire. Obviously, there can be no official support for arbitrarily
-# patched ebuilds. So whenever a build log in a bug report mentions that
-# user patches were applied, the user should be asked to reproduce the
-# problem without these.
-#
-# Not all ebuilds do call this function, so placing patches in the
-# stated directory might or might not work, depending on the package and
-# the eclasses it inherits and uses. It is safe to call the function
-# repeatedly, so it is always possible to add a call at the ebuild
-# level. The first call is the time when the patches will be
-# applied.
-#
-# Ideally, this function should be called after gentoo-specific patches
-# have been applied, so that their code can be modified as well, but
-# before calls to e.g. eautoreconf, as the user patches might affect
-# autotool input files as well.
-epatch_user() {
- [[ $# -ne 0 ]] && die "epatch_user takes no options"
-
- # Allow multiple calls to this function; ignore all but the first
- local applied="${T}/epatch_user.log"
- [[ -e ${applied} ]] && return 2
-
- # don't clobber any EPATCH vars that the parent might want
- local EPATCH_SOURCE check
- for check in ${CATEGORY}/{${P}-${PR},${P},${PN}}{,:${SLOT%/*}}; do
- EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CTARGET}/${check}
- [[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CHOST}/${check}
- [[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${check}
- if [[ -d ${EPATCH_SOURCE} ]] ; then
- local
old_n_applied_patches=${EPATCH_N_APPLIED_PATCHES:-0}
- EPATCH_SOURCE=${EPATCH_SOURCE} \
- EPATCH_SUFFIX="patch" \
- EPATCH_FORCE="yes" \
- EPATCH_MULTI_MSG="Applying user patches from
${EPATCH_SOURCE} ..." \
- epatch
- echo "${EPATCH_SOURCE}" > "${applied}"
- if [[ ${old_n_applied_patches} -lt
${EPATCH_N_APPLIED_PATCHES} ]]; then
- has epatch_user_death_notice
${EBUILD_DEATH_HOOKS} || \
- EBUILD_DEATH_HOOKS+="
epatch_user_death_notice"
- fi
- return 0
- fi
- done
- echo "none" > "${applied}"
- return 1
-}
-
-# @FUNCTION: epatch_user_death_notice
-# @INTERNAL
-# @DESCRIPTION:
-# Include an explicit notice in the die message itself that user patches were
-# applied to this build.
-epatch_user_death_notice() {
- ewarn "!!! User patches were applied to this build!"
-}
-
-esac
-
_EPATCH_ECLASS=1
fi #_EPATCH_ECLASS
--
2.35.1
[gentoo-dev] [PATCH] ruby-ng.eclass: replace ebegin with einfo in _ruby_invoke_environment
Calling ebegin here makes no sense because it is likely that the called
function will also generate output. This will lead to the "[ ok ]"
potentially appearing many lines later.
It also leads to nested ebegin calls, which make no sense for the same
reason.
Closes: https://bugs.gentoo.org/839585
Closes: https://bugs.gentoo.org/839588
Signed-off-by: Mike Gilbert
---
eclass/ruby-ng.eclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index f0d6c4f6f6c..c43d5b4d982 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -410,9 +410,8 @@ _ruby_invoke_environment() {
pushd "${WORKDIR}" &>/dev/null || die
fi
- ebegin "Running ${_PHASE:-${EBUILD_PHASE}} phase for $environment"
+ einfo "Running ${_PHASE:-${EBUILD_PHASE}} phase for $environment"
"$@"
- eend $?
popd &>/dev/null || die
S=${old_S}
--
2.36.1
[gentoo-dev] [PATCH] optfeature.eclass: remove EAPI 6
Signed-off-by: David Seifert
---
eclass/optfeature.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/optfeature.eclass b/eclass/optfeature.eclass
index acf8584e6db..b44fc1b8525 100644
--- a/eclass/optfeature.eclass
+++ b/eclass/optfeature.eclass
@@ -1,14 +1,14 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: optfeature.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 6 7 8
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: Advertise optional functionality that might be useful to users
case ${EAPI} in
- 6|7|8) ;;
+ 7|8) ;;
*) die "${ECLASS}: EAPI=${EAPI:-0} is not supported" ;;
esac
--
2.35.1
Re: [gentoo-dev] [PATCH 0/7] Drop support for EAPI 5 in eutils and its friends
On Tue, 2022-06-28 at 19:24 +0200, Ulrich Müller wrote: > Obviously, the series can only be merged when the last EAPI 5 ebuild > is gone. Current status is that we're down to 3 packages with EAPI 5 > which are all last-rited. > > Ulrich Müller (7): > eutils.eclass: Drop support for EAPI 5 > eutils.eclass: Remove use_if_iuse > eutils.eclass: Remove emktemp > autotools.eclass: Drop support for EAPI 5 > flag-o-matic.eclass: Drop support for EAPI 5 > multilib.eclass: Drop support for EAPIs 0 and 5 > toolchain-funcs.eclass: Drop support for EAPIs 0 and 5 > > eclass/autotools.eclass | 14 ++-- > eclass/eutils.eclass | 152 +++-- > - > eclass/flag-o-matic.eclass | 17 ++-- > eclass/multilib.eclass | 33 +--- > eclass/toolchain-funcs.eclass | 7 +- > 5 files changed, 33 insertions(+), 190 deletions(-) > The whole series looks good, let's merge it ASAP.
[gentoo-dev] Looking for co-maintainers for number of packages
I've been rather busy lately and can't keep up with all of my packages. There are pending bumps, some bugs, but nothing too crazy or hard. So I'm looking for someone to co-maintain (or even take over if you insist) the following packages: * net-mail/notmuch pseudo-autoconf NIH build system that can be PITA to work with, responsive upstream. High profile package. proxied maintainer in metadata has not been active lately and probably should be dropped. * net-irc/weechat Regular but not very frequent releases, responsive upstream, cmake, pretty sane and very popular. * dev-cpp/abseil-cpp Googleware, it's usually bundled into source, like gnulib, but some projects use system copy. Hardcoded flags, broken abi every other bump, may require slotting in the future, some revdeps rely on older versions. Not hard to maintain, but has more that usual blast radius. * net-libs/grpc * dev-python/grpcio * dev-python/grpcio-tools * dev-python/grpcio-testing grpc stack, googleware again. rather frequent releases, lack of portage-able tests, as tests insist on downloading gtest stack git master in src_test phase. Technically it's already co-maintained, but I't be beneficial if we have more hands and eyes on this one. python project has been helping with python packages, but lack of tests makes the package somewhat risky. bonus points if you can test it with tensorflow. * dev-util/bear Responsive upstream. Tests work but require disabling sandboxing (check ebuild on how to run it). Not too hard, pretty popular. * app-arch/dpkg debian upstream, easy to maintain. just need extra eyeballs. * app-shells/fish Responsive upstream, not very frequent releases, cmake. Requires some attention on non-x86 as arch bugs are rather frequent. But nothing too crazy. * sys-process/glances Responsive upstream, easy package. Just need extra pair of eyes/hands. * dev-util/google-perftools Another google package, very arch-specific, big blast radius if broken. Not hard to maintain, but need to be extra careful with revdeps, requires alt-arch testing. * app-admin/sysstat pretty easy but important package. I will also offer base-system to take it, as it's kinda important one. * app-admin/tmpreaper debian upstream, easy. * x11-misc/xwallpaper sane upstream, easy package. just need extra hands. probably most secure wallpaper setter out there ;-) Thanks, Georgy. PS. Huge bonus if you can test packages not only on x86_64. Ofc I can help with some gotchas in packages and have no plans on abandoning those completely, but realistically I'm not doing enough to keep those properly maintained at the moment.
