[gentoo-portage-dev] [PATCH] man/portage.5: Add userpatch documentation
Signed-off-by: Nekun
---
// seems like previous message has wrong Message-Id, resending
Starting from EAPI6, this is a built-in Portage functionality, maybe it
was not included in Portage documentation eralier because it was epatch.eclass
functionality which is exclusive for gentoo repo, but according with today's
mandatory "eapply_user" it should be here.
man/portage.5 | 21 +
1 file changed, 21 insertions(+)
diff --git a/man/portage.5 b/man/portage.5
index 247ec5ab0..083abd77e 100644
--- a/man/portage.5
+++ b/man/portage.5
@@ -78,6 +78,9 @@ site-specific overrides of \fB/etc/portage/make.profile/\fR
.BR /etc/portage/sets/
user\-defined package sets
.TP
+.BR /etc/portage/patches/
+user-provided patches to packages
+.TP
.BR /var/db/repos/gentoo/
.nf
sets.conf
@@ -1375,6 +1378,24 @@ Also see \fB/var/lib/portage/world_sets\fR and the
\fBemerge\fR(1)
\fB\-\-list\-sets\fR option.
.RE
.TP
+.BR /etc/portage/patches/
+.RS
+In this directory patches to the package source tree can be created.
+For each package, patches are taken from these subdirectories in the following
order:
+.nr step 1 1
+.IP \n[step]. 3
+/etc/portage/patches/${CATEGORY}/${P}-${PR}[:${SLOT}]
+.IP \n+[step].
+/etc/portage/patches/${CATEGORY}/${P}[:${SLOT}]
+.IP \n+[step].
+/etc/portage/patches/${CATEGORY}/${PN}[:${SLOT}]
+.RE 2
+
+More-specific directories overrides less-specific, i.e. if more than one
directory for the same package coexist, only patches from directory matches the
first matching pattern will be applied. Patches for each package are applied in
the POSIX lexicographic order. Patch file name must end in ".patch" or, for
\fBEAPI\fR >= \fB6\fR, in ".diff".
+
+If package ebuild uses \fBEAPI\fR <= \fB5\fR, it must explicitly invoke
\fBepatch_user\fR or inherit \fBepatch.eclass\fR(5) and rely on default
\fBsrc_prepare\fR for apply patches. Otherwise, patches are silently ignored.
If package ebuild uses \fBEAPI\fR >= \fB6\fR, applying user patches is
mandatory.
+.RE
+.TP
.BR /var/db/repos/gentoo/
.RS
.TP
--
2.26.3
[gentoo-portage-dev] [PATCH] man/portage.5: Add userpatch documentation
Signed-off-by: Nekun
---
Starting from EAPI6, this is a built-in Portage functionality, maybe it
was not included in Portage documentation earlier because it was
epatch.eclass functionality which is exclusive for gentoo repo, but
according with today's mandatory "eapply_user" it should be here.
man/portage.5 | 21 +
1 file changed, 21 insertions(+)
diff --git a/man/portage.5 b/man/portage.5
index 247ec5ab0..083abd77e 100644
--- a/man/portage.5
+++ b/man/portage.5
@@ -78,6 +78,9 @@ site-specific overrides of
\fB/etc/portage/make.profile/\fR
.BR /etc/portage/sets/
user\-defined package sets
.TP
+.BR /etc/portage/patches/
+user-provided patches to packages
+.TP
.BR /var/db/repos/gentoo/
.nf
sets.conf
@@ -1375,6 +1378,24 @@ Also see \fB/var/lib/portage/world_sets\fR and
the \fBemerge\fR(1)
\fB\-\-list\-sets\fR option.
.RE
.TP
+.BR /etc/portage/patches/
+.RS
+In this directory patches to the package source tree can be created.
+For each package, patches are taken from these subdirectories in the
following order:
+.nr step 1 1
+.IP \n[step]. 3
+/etc/portage/patches/${CATEGORY}/${P}-${PR}[:${SLOT}]
+.IP \n+[step].
+/etc/portage/patches/${CATEGORY}/${P}[:${SLOT}]
+.IP \n+[step].
+/etc/portage/patches/${CATEGORY}/${PN}[:${SLOT}]
+.RE 2
+
+More-specific directories overrides less-specific, i.e. if more than
one directory for the same package coexist, only patches from directory
matches the first matching pattern will be applied. Patches for each
package are applied in the POSIX lexicographic order. Patch file name
must end in ".patch" or, for \fBEAPI\fR >= \fB6\fR, in ".diff".
+
+If package ebuild uses \fBEAPI\fR <= \fB5\fR, it must explicitly invoke
\fBepatch_user\fR or inherit \fBepatch.eclass\fR(5) and rely on default
\fBsrc_prepare\fR for apply patches. Otherwise, patches are silently
ignored. If package ebuild uses \fBEAPI\fR >= \fB6\fR, applying user
patches is mandatory.
+.RE
+.TP
.BR /var/db/repos/gentoo/
.RS
.TP
--
2.26.3
Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)
On Fri, Apr 9, 2021 at 5:19 PM Sam James wrote: > > > > > On 10 Apr 2021, at 01:13, Michael Orlitzky wrote: > > > > On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote: > >> > >> > >> Yes, this is the part I find difficult too. The important > >> distinction here was *bootstrapping* (which I missed) > >> but I think at least we should make a list of packages generally considered > >> critical for bootstrap. > >> > > > > What is a bootstrap package? > > > > There is some chicken-and-egg problem to be solved, but I don't think > > that we should be assuming that e.g. GNU grep is always present just > > because, during the base case of some recursive process, POSIX grep > > must be available temporarily. > > > > Anyway, https://bugs.gentoo.org/485356 awaits reopening if you make any > > progress on this. > > > > Oh, I agree completely. CCed myself on the bug and added to the list > to think about/work on. > > I’m pleased a bug existed in the past! I don’t agree with it being closed > though: > documentation issues can exist without a patch existing to fix them yet, > right? I worry a lot about more complex dependencies trees (imagine all of the exciting cycles in the currently excluded @system depgraph.) Remember that while in theory it would be great if portage knew about all of them; computing these nodes and edges isn't free. I question what we are really buying with the extra complexity. -A
Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)
> On 10 Apr 2021, at 01:13, Michael Orlitzky wrote: > > On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote: >> >> >> Yes, this is the part I find difficult too. The important >> distinction here was *bootstrapping* (which I missed) >> but I think at least we should make a list of packages generally considered >> critical for bootstrap. >> > > What is a bootstrap package? > > There is some chicken-and-egg problem to be solved, but I don't think > that we should be assuming that e.g. GNU grep is always present just > because, during the base case of some recursive process, POSIX grep > must be available temporarily. > > Anyway, https://bugs.gentoo.org/485356 awaits reopening if you make any > progress on this. > Oh, I agree completely. CCed myself on the bug and added to the list to think about/work on. I’m pleased a bug existed in the past! I don’t agree with it being closed though: documentation issues can exist without a patch existing to fix them yet, right? signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)
On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote: > > > Yes, this is the part I find difficult too. The important > distinction here was *bootstrapping* (which I missed) > but I think at least we should make a list of packages generally considered > critical for bootstrap. > What is a bootstrap package? There is some chicken-and-egg problem to be solved, but I don't think that we should be assuming that e.g. GNU grep is always present just because, during the base case of some recursive process, POSIX grep must be available temporarily. Anyway, https://bugs.gentoo.org/485356 awaits reopening if you make any progress on this.
Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)
> On 7 Apr 2021, at 12:18, Michael Orlitzky wrote: > > On Tue, 2021-04-06 at 20:32 +0100, Sam James wrote: >> >>> >>> We usually don't add basic tools like grep to dependencies. >> >> Few points: >> >> ... > > 5) There are no clear rules about what @system packages can be left out > of *DEPEND and when, so their presence is wildly inconsistent. Yes, this is the part I find difficult too. The important distinction here was *bootstrapping* (which I missed) but I think at least we should make a list of packages generally considered critical for bootstrap. The Prefix documentation and scripts as well as Catalyst will help here. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)
> On 7 Apr 2021, at 12:06, Ulrich Mueller wrote: > >> On Tue, 06 Apr 2021, Sam James wrote: > >> 1) @system varies between profiles anyway which makes it hard to fully >> rely on; > > That's exactly the reason why you _don't_* add GNU grep as a dependency, > because e.g. on Prefix grep may be provided by another package. > > grep is a POSIX tool and a bootstrap package, so we can be certain that > will be available everywhere. (And the single grep instance in the > eclass doesn't use any GNUisms.) > Yeah, bootstrap package was the key distinction I was missing. >> 2) As a few of us have discussed in #gentoo-portage in the past, >> continuing this trend of not explicitly stating dependencies makes >> parallelism in Portage difficult. You can try this with >> —implicit-system-deps=n, but we really need to be stating what we use >> explicitly. > > This would mean that we'd end up with lots of system dependencies in > every ebuild. The current policy is in place for good reasons. > Yes, although as I’ll say below, I’m not sure it’s as clear as it could be. > You may have a point for adding library dependencies explicitly, but > certainly not for common build tools (aka bootstrap packages). They will > be available from the very beginning of the bootstrap process. Indeed. >> The benefit is enhanced parallelism and the downside is being >> _slightly_ more verbose in some ebuilds; > > s/slightly/much/;s/some/all/ > > We'd end up having a significant subset of profiles/base/packages in > _every_ ebuild. Or even worse, a bunch of any-of-many dependencies or > virtuals, in order to account for different systems. Personally, I > wouldn't be willing to maintain such dependencies for my ebuilds. > I’m not sure this would be a significant subset, but I agree, this approach is really only applicable to non-bootstrap dependencies. What we do need likely need is to document this specific part better. > More importantly, if you want such a policy change, then you should > discuss it first and have it approved. Until then, the current policy > [1] applies. Sure. It should probably be in the QA policy document though, given the devmanual is not always explicitly policy, as we’ve discussed. TL;DR: Agreed, I’ll drop this part from the changes, and we may revisit the issue through e.g. documentation. > >> 3) Implicit dependencies make it hard for us to ever actually swap >> implementations; > >> 4) This helps when creating minimal systems without Portage in it. > > [1] > https://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Fixing user/group creation with different ROOT
Hello everyone,
I've made a PR on github to fix the user/group creation when using a
ROOT different than /.
This is the link of the PR: https://github.com/gentoo/gentoo/pull/19204
Could you please take a moment to take a look at it ?
To test it, you need to create a new minimalist ROOT with:
$ export ROOT=/tmp/test-root
$ export SYSROOT=/tmp/sysroot
$ mkdir -p ${ROOT}/etc/portage
$ cp {,${ROOT}}/etc/portage/make.conf
$ ln -s /var/db/repos/gentoo/profiles/default/linux//
${ROOT}/etc/portage/make.profile
$ emerge baselayout coreutils
Once it is done, you can emerge a new user for this ROOT, with this
patch, the user will be created in ROOT, without the user will be
installed on your system.
Note, this PR work with other arch too.
Thanks for your attention
--
Jérémy
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index ee4358b5c75..efa637a7efa 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -194,8 +194,15 @@ eislocked() {
*)
# NB: 'no password' and 'locked' are indistinguishable
# but we also expire the account which is more clear
- [[ $(getent shadow "$1" | cut -d: -f2) == '!'* ]] &&
- [[ $(getent shadow "$1" | cut -d: -f8) == 1 ]]
+ local shadow
+ if [[ -n "${ROOT}" ]]; then
+ shadow=$(grep "^$1:" "${ROOT}/etc/shadow")
+ else
+ shadow=$(getent shadow "$1")
+ fi
+
+ [[ $( echo ${shadow} | cut -d: -f2) == '!'* ]] &&
+ [[ $(echo ${shadow} | cut -d: -f8) == 1 ]]
;;
esac
}
@@ -222,14 +229,22 @@ elockuser() {
eislocked "$1"
[[ $? -eq 0 ]] && return 0
+ local opts
+ [[ -n ${ROOT} ]] && opts=( --prefix "${ROOT}" )
+
case ${CHOST} in
*-freebsd*|*-dragonfly*)
- pw lock "$1" || die "Locking account $1 failed"
- pw user mod "$1" -e 1 || die "Expiring account $1 failed"
+ pw lock "${opts[@]}" "$1" || die "Locking account $1 failed"
+ pw user mod "${opts[@]}" "$1" -e 1 || die "Expiring account $1 failed"
;;
*-netbsd*)
- usermod -e 1 -C yes "$1" || die "Locking account $1 failed"
+ if [[ -n "${ROOT}" ]]; then
+ ewarn "NetBSD's usermod does not support --prefix option."
+ ewarn "Please use: usermod ${opts[@]} -e 1 -C yes \"$1\" in a chroot"
+ else
+ usermod "${opts[@]}" -e 1 -C yes "$1" || die "Locking account $1 failed"
+ fi
;;
*-openbsd*)
@@ -237,7 +252,7 @@ elockuser() {
;;
*)
- usermod -e 1 -L "$1" || die "Locking account $1 failed"
+ usermod "${opts[@]}" -e 1 -L "$1" || die "Locking account $1 failed"
;;
esac
@@ -265,14 +280,22 @@ eunlockuser() {
eislocked "$1"
[[ $? -eq 1 ]] && return 0
+ local opts
+ [[ -n ${ROOT} ]] && opts=( --prefix "${ROOT}" )
+
case ${CHOST} in
*-freebsd*|*-dragonfly*)
- pw user mod "$1" -e 0 || die "Unexpiring account $1 failed"
- pw unlock "$1" || die "Unlocking account $1 failed"
+ pw user mod "${opts[@]}" "$1" -e 0 || die "Unexpiring account $1 failed"
+ pw unlock "${opts[@]}" "$1" || die "Unlocking account $1 failed"
;;
*-netbsd*)
- usermod -e 0 -C no "$1" || die "Unlocking account $1 failed"
+ if [[ -n "${ROOT}" ]]; then
+ ewarn "NetBSD's usermod does not support --prefix option."
+ ewarn "Please use: \"usermod ${opts[@]} -e 0 -C no $1\" in a chroot"
+ else
+ usermod "${opts[@]}" -e 0 -C no "$1" || die "Unlocking account $1 failed"
+ fi
;;
*-openbsd*)
@@ -281,7 +304,7 @@ eunlockuser() {
*)
# silence warning if account does not have a password
- usermod -e "" -U "$1" 2>/dev/null || die "Unlocking account $1 failed"
+ usermod "${opts[@]}" -e "" -U "$1" 2>/dev/null || die "Unlocking account $1 failed"
;;
esac
@@ -417,7 +440,13 @@ acct-user_pkg_preinst() {
# default ownership to user:group
if [[ -z ${_ACCT_USER_HOME_OWNER} ]]; then
local group_array=( ${_ACCT_USER_GROUPS} )
- _ACCT_USER_HOME_OWNER=${ACCT_USER_NAME}:${group_array[0]}
+ if [[ -n "${ROOT}" ]]; then
+local euid=$(egetent passwd ${ACCT_USER_NAME} | cut -d: -f3)
+local egid=$(egetent passwd ${ACCT_USER_NAME} | cut -d: -f4)
+_ACCT_USER_HOME_OWNER=${euid}:${egid}
+ else
+_ACCT_USER_HOME_OWNER=${ACCT_USER_NAME}:${group_array[0]}
+ fi
fi
# Path might be missing due to INSTALL_MASK, etc.
# https://bugs.gentoo.org/691478
diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
index 15e9238ab44..5e2d3f70490 100644
--- a/eclass/user-info.eclass
+++ b/eclass/user-info.eclass
@@ -6,7 +6,6 @@
# base-sys...@gentoo.org (Linux)
# MichaŠGórny (NetBSD)
# @BLURB: Read-only access to user and group information
-
if [[ -z ${_USER_INFO_ECLASS} ]]; then
_USER_INFO_ECLASS=1
@@ -17,6 +16,7 @@ _USER_INFO_ECLASS=1
# dscl (Mac OS X 10.5), and pw (FreeBSD) used in enewuser()/enewgroup().
#
# Supported databases: group passwd
+# Warning: This function can be used only in pkg_* phases when ROOT is valid.
egetent() {
local db=$1 key=$2
@@ -37,18 +37,31 @@ egetent() {
# lookup by uid/gid
local opts
if [[ ${key} == [[:digit:]]* ]] ; then
- [[ ${db} == "user" ]] && opts="-u" || opts="-g"
+ [[ ${db} ==
Re: [gentoo-dev] vdr-plugin-2.eclass QA fix, please review, bug 778815
> On 9 Apr 2021, at 22:10, Joerg Bornkessel wrote:
>
> https://bugs.gentoo.org/show_bug.cgi?id=778815
>
> pkgcheck, gives an error like this
> VariableScope: vdr-plugin-2: variable 'WORKDIR' used in
> 'vdr-plugin-2_pkg_setup', line 371
>
Hi, thanks for looking into this!
> inserted patch will fix this issues
Could you make the change in a git checkout and then use ‘git format-patch’ and
then
git send-email to send it here?
>
>
> --- vdr-plugin-2.eclass 2020-02-23 17:39:40.0 +0100
> +++ vdr-plugin-2_QA-fixed.eclass2021-04-06 23:27:37.358477036 +0200
> @@ -368,7 +368,7 @@
>VDR_INCLUDE_DIR="/usr/include/vdr"
>DVB_INCLUDE_DIR="/usr/include"
>
> - TMP_LOCALE_DIR="${WORKDIR}/tmp-locale"
> + TMP_LOCALE_DIR="${T}/tmp-locale"
>
>LOCDIR=$(pkg-config --variable=locdir vdr)
>
>
This looks fine as-is, although you may want to take the opportunity
to do some other clean ups, like replacing pkg-config with
$(tc-getPKG_CONFIG) to respect the ${PKG_CONFIG} variable
for e.g. cross-compilation.
We should add pkg-config to BDEPEND in EAPI 7 if it’s needed too.
It looks like there are some missing || dies on e.g. sed and other
external commands too which we could fix.
> i did several tests on my setup, it works like expected.
> please review, thanks...
>
> --
> Joerg Bornkessel
> GnuPG Key: 0x93EB5F4DAA5832A1
> Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1
>
signature.asc
Description: Message signed with OpenPGP
[gentoo-dev] vdr-plugin-2.eclass QA fix, please review, bug 778815
https://bugs.gentoo.org/show_bug.cgi?id=778815
pkgcheck, gives an error like this
VariableScope: vdr-plugin-2: variable 'WORKDIR' used in
'vdr-plugin-2_pkg_setup', line 371
inserted patch will fix this issues
--- vdr-plugin-2.eclass 2020-02-23 17:39:40.0 +0100
+++ vdr-plugin-2_QA-fixed.eclass2021-04-06 23:27:37.358477036 +0200
@@ -368,7 +368,7 @@
VDR_INCLUDE_DIR="/usr/include/vdr"
DVB_INCLUDE_DIR="/usr/include"
- TMP_LOCALE_DIR="${WORKDIR}/tmp-locale"
+ TMP_LOCALE_DIR="${T}/tmp-locale"
LOCDIR=$(pkg-config --variable=locdir vdr)
i did several tests on my setup, it works like expected.
please review, thanks...
--
Joerg Bornkessel
GnuPG Key: 0x93EB5F4DAA5832A1
Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] base.eclass: last-rites
base.eclass: last-rite eclass (mark as @DEAD) Removal on 2021-05-09. Please port to general eclass functions/helpers. See https://bugs.gentoo.org/497022 for information. signature.asc Description: Message signed with OpenPGP
[gentoo-dev] games.eclass: last-rite eclass
games.eclass: mark as @DEAD (last-rite eclass) Removal on 2021-05-09. Please port to general eclass functions/helpers. No specific eclass is needed for general games installation. signature.asc Description: Message signed with OpenPGP
[gentoo-portage-dev] [PATCH] make.conf.5: Sugest PORTAGE_LOG_FILTER_FILE_CMD supervisor for cat fallback (bug 781854)
If PORTAGE_LOG_FILTER_FILE_CMD fails after exec, then output will be lost. Therefore, suggest to use bash as a supervisor, with fallback to cat. Bug: https://bugs.gentoo.org/781854 Signed-off-by: Zac Medico --- man/make.conf.5 | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/man/make.conf.5 b/man/make.conf.5 index 8d551c95e..8a4a2ae30 100644 --- a/man/make.conf.5 +++ b/man/make.conf.5 @@ -1,4 +1,4 @@ -.TH "MAKE.CONF" "5" "Feb 2021" "Portage VERSION" "Portage" +.TH "MAKE.CONF" "5" "Apr 2021" "Portage VERSION" "Portage" .SH "NAME" make.conf \- custom settings for Portage .SH "SYNOPSIS" @@ -998,7 +998,18 @@ will set idle io priority. For more information about ionice, see .B PORTAGE_LOG_FILTER_FILE_CMD This variable specifies a command that filters build log output to a log file. In order to filter ANSI escape codes from build logs, -\fBansifilter\fR(1) is a convenient setting for this variable. +\fBansifilter\fR(1) is a convenient setting for this variable. Generally, +PORTAGE_LOG_FILTER_FILE_CMD should include a supervisor that falls back +to cat if the real filter command fails after exec. For example, a +supervisor is needed for ansifilter, in case it fails after exec due to +a problem resolving libstdc++ during a gcc upgrade. +.br +.I Example: +.nf +# Use bash as a supervisor, for fallback to cat if asifilter fails +# after exec due to a problem resolving libstdc++ during a gcc upgrade. +PORTAGE_LOG_FILTER_FILE_CMD="bash -c \\"ansifilter; exec cat\\"" +.fi .TP .B PORTAGE_LOGDIR This variable defines the directory in which per\-ebuild logs are kept. -- 2.26.2
Re: [gentoo-dev] (resent) [PATCH] eclass: Support dev-util/samurai
Hi,
First things first:
- there should be a detailed commit message explaning what samurai is,
to what degree it is compatible with ninja and what's happening here
- this should be split to one patch per eclass.
On Fri, 2021-04-09 at 18:50 +0200, Lars Wendler wrote:
> From: orbea
>
> Signed-off-by: Lars Wendler
> ---
> eclass/cmake.eclass | 22 --
> eclass/meson.eclass | 4 ++--
> eclass/ninja-utils.eclass | 37 +++--
> 3 files changed, 45 insertions(+), 18 deletions(-)
>
> diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
> index 4bd09459ea6..935ee1d8c81 100644
> --- a/eclass/cmake.eclass
> +++ b/eclass/cmake.eclass
> @@ -52,9 +52,9 @@ _CMAKE_ECLASS=1
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # Specify a makefile generator to be used by cmake.
> -# At this point only "emake" and "ninja" are supported.
> -# The default is set to "ninja".
> -: ${CMAKE_MAKEFILE_GENERATOR:=ninja}
> +# At this point only "emake", "eninja" and "ninja" are supported.
> +# The default is set to "eninja".
> +: ${CMAKE_MAKEFILE_GENERATOR:=eninja}
At this point, this gets really confusing to end users (what is
the difference between 'ninja' and 'eninja')? Also, adding a new value
and changing the default breaks ebuild that run code conditionally
on CMAKE_MAKEFILE_GENERATOR.
>
>
> # @ECLASS-VARIABLE: CMAKE_REMOVE_MODULES_LIST
> # @DESCRIPTION:
> @@ -117,8 +117,8 @@ case ${CMAKE_MAKEFILE_GENERATOR} in
> emake)
> BDEPEND="sys-devel/make"
> ;;
> - ninja)
> - BDEPEND="dev-util/ninja"
> + eninja|ninja)
> + BDEPEND="|| ( dev-util/ninja dev-util/samurai )"
With hardcoded 'ninja' call, I doubt this is going to be true
for 'ninja' choice.
Also, this isn't going to work anyway since you don't check which one
is installed anywhere anyway.
> ;;
> *)
> eerror "Unknown value for \${CMAKE_MAKEFILE_GENERATOR}"
> @@ -335,13 +335,6 @@ cmake_src_prepare() {
> die "FATAL: Unable to find CMakeLists.txt"
> fi
>
>
> - # if ninja is enabled but not installed, the build could fail
> - # this could happen if ninja is manually enabled (eg. make.conf) but
> not installed
> - if [[ ${CMAKE_MAKEFILE_GENERATOR} == ninja ]] && ! has_version -b
> dev-util/ninja; then
> - eerror "CMAKE_MAKEFILE_GENERATOR is set to ninja, but ninja is
> not installed."
> - die "Please install dev-util/ninja or unset
> CMAKE_MAKEFILE_GENERATOR."
> - fi
> -
> local modules_list
> if [[ $(declare -p CMAKE_REMOVE_MODULES_LIST) == "declare -a"* ]]; then
> modules_list=( "${CMAKE_REMOVE_MODULES_LIST[@]}" )
> @@ -534,7 +527,7 @@ cmake_src_configure() {
>
>
> local generator_name
> case ${CMAKE_MAKEFILE_GENERATOR} in
> - ninja) generator_name="Ninja" ;;
> + eninja|ninja) generator_name="Ninja" ;;
> emake) generator_name="Unix Makefiles" ;;
> esac
>
>
> @@ -592,8 +585,9 @@ cmake_build() {
> *) emake VERBOSE=1 "$@" ;;
> esac
> ;;
> - ninja)
> + eninja|ninja)
> [[ -e build.ninja ]] || die "build.ninja not found.
> Error during configure stage."
> + CMAKE_MAKEFILE_GENERATOR=eninja
> eninja "$@"
> ;;
> esac
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index d0ce5adb355..ea02402aa83 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 2017-2020 Gentoo Authors
> +# Copyright 2017-2021 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
>
> # @ECLASS: meson.eclass
> @@ -55,7 +55,7 @@ if [[ -z ${_MESON_ECLASS} ]]; then
> _MESON_ECLASS=1
>
>
> MESON_DEPEND=">=dev-util/meson-0.54.0
> - >=dev-util/ninja-1.8.2
> + || ( >=dev-util/ninja-1.8.2 dev-util/samurai )
> dev-util/meson-format-array
> "
Same as for cmake.
>
>
> diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
> index ca8d67191dc..5008564dabf 100644
> --- a/eclass/ninja-utils.eclass
> +++ b/eclass/ninja-utils.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2018 Gentoo Foundation
> +# Copyright 1999-2021 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
>
> # @ECLASS: ninja-utils.eclass
> @@ -27,6 +27,15 @@ case ${EAPI:-0} in
> *) die "EAPI=${EAPI} is not yet supported" ;;
> esac
>
>
> +# @ECLASS-VARIABLE: NINJA
> +# @PRE_INHERIT
> +# @DEFAULT_UNSET
'Default unset' conflicts with the default set below.
> +# @DESCRIPTION:
> +# Specify a compatible ninja implementation to be used by eninja.
> +# At this point only "ninja" and "samu" are supported.
> +# The default is set to "ninja".
> +: ${NINJA:=ninja}
> +
> # @ECLASS-VARIABLE:
[gentoo-dev] (resent) [PATCH] eclass: Support dev-util/samurai
From: orbea
Signed-off-by: Lars Wendler
---
eclass/cmake.eclass | 22 --
eclass/meson.eclass | 4 ++--
eclass/ninja-utils.eclass | 37 +++--
3 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea6..935ee1d8c81 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -52,9 +52,9 @@ _CMAKE_ECLASS=1
# @DEFAULT_UNSET
# @DESCRIPTION:
# Specify a makefile generator to be used by cmake.
-# At this point only "emake" and "ninja" are supported.
-# The default is set to "ninja".
-: ${CMAKE_MAKEFILE_GENERATOR:=ninja}
+# At this point only "emake", "eninja" and "ninja" are supported.
+# The default is set to "eninja".
+: ${CMAKE_MAKEFILE_GENERATOR:=eninja}
# @ECLASS-VARIABLE: CMAKE_REMOVE_MODULES_LIST
# @DESCRIPTION:
@@ -117,8 +117,8 @@ case ${CMAKE_MAKEFILE_GENERATOR} in
emake)
BDEPEND="sys-devel/make"
;;
- ninja)
- BDEPEND="dev-util/ninja"
+ eninja|ninja)
+ BDEPEND="|| ( dev-util/ninja dev-util/samurai )"
;;
*)
eerror "Unknown value for \${CMAKE_MAKEFILE_GENERATOR}"
@@ -335,13 +335,6 @@ cmake_src_prepare() {
die "FATAL: Unable to find CMakeLists.txt"
fi
- # if ninja is enabled but not installed, the build could fail
- # this could happen if ninja is manually enabled (eg. make.conf) but
not installed
- if [[ ${CMAKE_MAKEFILE_GENERATOR} == ninja ]] && ! has_version -b
dev-util/ninja; then
- eerror "CMAKE_MAKEFILE_GENERATOR is set to ninja, but ninja is
not installed."
- die "Please install dev-util/ninja or unset
CMAKE_MAKEFILE_GENERATOR."
- fi
-
local modules_list
if [[ $(declare -p CMAKE_REMOVE_MODULES_LIST) == "declare -a"* ]]; then
modules_list=( "${CMAKE_REMOVE_MODULES_LIST[@]}" )
@@ -534,7 +527,7 @@ cmake_src_configure() {
local generator_name
case ${CMAKE_MAKEFILE_GENERATOR} in
- ninja) generator_name="Ninja" ;;
+ eninja|ninja) generator_name="Ninja" ;;
emake) generator_name="Unix Makefiles" ;;
esac
@@ -592,8 +585,9 @@ cmake_build() {
*) emake VERBOSE=1 "$@" ;;
esac
;;
- ninja)
+ eninja|ninja)
[[ -e build.ninja ]] || die "build.ninja not found.
Error during configure stage."
+ CMAKE_MAKEFILE_GENERATOR=eninja
eninja "$@"
;;
esac
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index d0ce5adb355..ea02402aa83 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -1,4 +1,4 @@
-# Copyright 2017-2020 Gentoo Authors
+# Copyright 2017-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: meson.eclass
@@ -55,7 +55,7 @@ if [[ -z ${_MESON_ECLASS} ]]; then
_MESON_ECLASS=1
MESON_DEPEND=">=dev-util/meson-0.54.0
- >=dev-util/ninja-1.8.2
+ || ( >=dev-util/ninja-1.8.2 dev-util/samurai )
dev-util/meson-format-array
"
diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
index ca8d67191dc..5008564dabf 100644
--- a/eclass/ninja-utils.eclass
+++ b/eclass/ninja-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: ninja-utils.eclass
@@ -27,6 +27,15 @@ case ${EAPI:-0} in
*) die "EAPI=${EAPI} is not yet supported" ;;
esac
+# @ECLASS-VARIABLE: NINJA
+# @PRE_INHERIT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specify a compatible ninja implementation to be used by eninja.
+# At this point only "ninja" and "samu" are supported.
+# The default is set to "ninja".
+: ${NINJA:=ninja}
+
# @ECLASS-VARIABLE: NINJAOPTS
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -36,6 +45,30 @@ esac
inherit multiprocessing
+_ninja_to_use() {
+ case "${NINJA}" in
+ ninja)
+ local ninja=dev-util/${NINJA}
+ ;;
+ samu)
+ local ninja=dev-util/samurai
+ ;;
+ *)
+ eerror "Unknown value for \${NINJA}"
+ die "Value ${NINJA} is not supported"
+ ;;
+ esac
+
+ # if ninja or samurai are enabled but not installed, the build could
fail
+ # this could happen if they are manually enabled (eg. make.conf) but
not installed
+ if ! has_version -b ${ninja}; then
+ eerror "Value ${NINJA} for \${NINJA} is not installed"
+ die "Please install ${ninja}"
+ fi
+
+ echo ${NINJA}
+}
+
# @FUNCTION: eninja
# @USAGE: [...]
# @DESCRIPTION:
@@ -49,7 +82,7 @@
[gentoo-dev] [PATCH] eclass: Support dev-util/samurai
From: orbea
Signed-off-by: Lars Wendler
---
eclass/cmake.eclass | 10 +-
eclass/meson.eclass | 4 ++--
eclass/ninja-utils.eclass | 35 +--
3 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea6..c0c22394a31 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -118,7 +118,7 @@ case ${CMAKE_MAKEFILE_GENERATOR} in
BDEPEND="sys-devel/make"
;;
ninja)
- BDEPEND="dev-util/ninja"
+ BDEPEND="|| ( dev-util/ninja dev-util/samurai )"
;;
*)
eerror "Unknown value for \${CMAKE_MAKEFILE_GENERATOR}"
@@ -337,9 +337,9 @@ cmake_src_prepare() {
# if ninja is enabled but not installed, the build could fail
# this could happen if ninja is manually enabled (eg. make.conf) but
not installed
- if [[ ${CMAKE_MAKEFILE_GENERATOR} == ninja ]] && ! has_version -b
dev-util/ninja; then
- eerror "CMAKE_MAKEFILE_GENERATOR is set to ninja, but ninja is
not installed."
- die "Please install dev-util/ninja or unset
CMAKE_MAKEFILE_GENERATOR."
+ if [[ ${CMAKE_MAKEFILE_GENERATOR} == ninja ]] && ! has_version -b
dev-util/ninja && ! has_version -b dev-util/samurai; then
+ eerror "CMAKE_MAKEFILE_GENERATOR is set to ninja, but neither
ninja or samurai are installed."
+ die "Please install dev-util/ninja, dev-util/samurai or unset
CMAKE_MAKEFILE_GENERATOR."
fi
local modules_list
@@ -653,7 +653,7 @@ cmake_src_install() {
_cmake_check_build_dir
pushd "${BUILD_DIR}" > /dev/null || die
- DESTDIR="${D}" ${CMAKE_MAKEFILE_GENERATOR} install "$@" ||
+ DESTDIR="${D}" eninja install "$@" ||
die "died running ${CMAKE_MAKEFILE_GENERATOR} install"
popd > /dev/null || die
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index d0ce5adb355..ea02402aa83 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -1,4 +1,4 @@
-# Copyright 2017-2020 Gentoo Authors
+# Copyright 2017-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: meson.eclass
@@ -55,7 +55,7 @@ if [[ -z ${_MESON_ECLASS} ]]; then
_MESON_ECLASS=1
MESON_DEPEND=">=dev-util/meson-0.54.0
- >=dev-util/ninja-1.8.2
+ || ( >=dev-util/ninja-1.8.2 dev-util/samurai )
dev-util/meson-format-array
"
diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
index ca8d67191dc..3b23d4c002a 100644
--- a/eclass/ninja-utils.eclass
+++ b/eclass/ninja-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: ninja-utils.eclass
@@ -27,6 +27,15 @@ case ${EAPI:-0} in
*) die "EAPI=${EAPI} is not yet supported" ;;
esac
+# @ECLASS-VARIABLE: NINJA
+# @PRE_INHERIT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specify a compatible ninja implementation to be used by eninja.
+# At this point only "ninja" and "samu" are supported.
+# The default is set to "ninja".
+: ${NINJA:=ninja}
+
# @ECLASS-VARIABLE: NINJAOPTS
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -36,6 +45,28 @@ esac
inherit multiprocessing
+_ninja_to_use() {
+ case "${NINJA}" in
+ ninja)
+ local ninja=dev-util/${NINJA}
+ ;;
+ samu)
+ local ninja=dev-util/samurai
+ ;;
+ *)
+ eerror "Unknown value for \${NINJA}"
+ die "Value ${NINJA} is not supported"
+ ;;
+ esac
+
+ if ! has_version -b $ninja; then
+ eerror "Value ${NINJA} for \${NINJA} is not installed"
+ die "Please install $ninja"
+ fi
+
+ echo ${NINJA}
+}
+
# @FUNCTION: eninja
# @USAGE: [...]
# @DESCRIPTION:
@@ -49,7 +80,7 @@ eninja() {
if [[ -z ${NINJAOPTS+set} ]]; then
NINJAOPTS="-j$(makeopts_jobs) -l$(makeopts_loadavg
"${MAKEOPTS}" 0)"
fi
- set -- ninja -v ${NINJAOPTS} "$@"
+ set -- "$(_ninja_to_use)" -v ${NINJAOPTS} "$@"
echo "$@" >&2
"$@" || die "${nonfatal_args[@]}" "${*} failed"
}
--
2.31.1
Re: [gentoo-dev] Last-rites: app-admin/lastpass-cli
> > I actually use lastpass-cli, because my company use LastPass. Is there an > > alternative, or can we keep this somehow? > > > > Unfortunately we cannot keep it unless the upstream shows a sign of life. You > can still use the web interface etc. of LastPass. There is also a community > fork of lastpass-cli[0], which I would be opposed to maintaining because it’s > not sanctioned by LogMeIn. > > Given the fact that upstream is practically dead now, you can just not delete > the package. Most likely it’ll eventually break if one of its dependencies’ > ABI changes, which would require a rebuild. If you really want to keep the > package, you can save it in a local overlay and use it for as long as it > lasts. Just remember that if LogMeIn decides to change the web API at some > point, lastpass-cli is effectively a program with undefined behavior. Sigh. I guess it'll have to be that way :-) I'll follow the community fork and put it in my own overlay. Thanks, -- Thomas
