Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
On 12/14/19 11:53 PM, Ralph Seichter wrote: Of the three packages you mentioned, milter-regex (not regex-milter) is the only one with a name that actually contains "milter". OpenDMARC should never have user a user named milter in the first place, and in the future it should use "opendmarc". Besides, since nobody has claimed group/user "milter" before me, I think this falls under first come, first serve. I agree that milter-regex has the strongest claim to the username. All I'm saying is that until opendmarc updates to GLEP81, changes its username, and all of its old versions have been purged from the tree... (a) we still have a dumb security vulnerability, in that these daemons can modify each others' files; and (b) you have to be careful not to do anything in acct-user/milter that could break someone's opendmarc setup, because now reinstalling acct-user/milter will reset all of the settings for its user (see the mythtv thread from today about this).
Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
* Michael Orlitzky: > I guess we could keep "milter" for only regex-milter, but that has the > disadvantage that it messes with the opendmarc package in the meantime. Of the three packages you mentioned, milter-regex (not regex-milter) is the only one with a name that actually contains "milter". OpenDMARC should never have user a user named milter in the first place, and in the future it should use "opendmarc". Besides, since nobody has claimed group/user "milter" before me, I think this falls under first come, first serve. -Ralph
Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
On 12/13/19 4:17 PM, Ralph Seichter wrote: The mail-filter/milter-regex ebuild already uses user/group 'milter', and for the currently open bump to version 2.7 I'd like to claim GID/UID 438. I recently cited the "milter" user on this list as a bad example from the user.eclass days... it was used by at least three unrelated packages: milter-regex, opendmarc, and opendkim. I fixed opendkim, of course, but it looks like opendmarc still uses "milter" as its user, too. Now would be a good time to switch them to unique accounts, since neither package should be able to access the other's files. The obvious choice for opendmarc is "opendmarc", and that's even what upstream defaults to -- we sed it to "milter" in Gentoo. I guess we could keep "milter" for only regex-milter, but that has the disadvantage that it messes with the opendmarc package in the meantime. Upstream uses "_milter-regex", and according to the PMS that's... actually... a legal package name? How do people feel about that? It's insane, for sure; but I'm too tired to tell if it's good insane or bad insane.
Re: [gentoo-dev] RFC: acct-user/... modifies existing user sometimes
On 2019-12-14 21:47, The Bit Pit wrote: > acct-user/mythtv modifies the existing user if that user is not logged > in. Mythtv has been around for years and users have created specialized > configurations for the mythtv user. They do not like changes to the > mythtv user when upgrading. Could you please be a little bit more precise what's changing? acct-* shouldn't mess with already *existing* users. So upgrade experience shouldn't be affected... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds
On 14/12/19 12:03, Kent Fredric wrote: > On Sat, 14 Dec 2019 08:16:03 +0100 > Ulrich Mueller wrote: > >> These prevent NOCOLOR in make.conf or emerge --color=n from working >> correctly, and I guess they are also problematic from an accessibility >> point of view. >> >> Are there any objections against removing these sequences from strings? >> AFAICS, they are used by less than ten packages, and one eclass. > Maybe we can have some future EAPI feature, or special eclass, that > allows people to add escape codes while also respecting the > configuration. > > Sort of like what git has in its formatting codes, where they're turned > off when colours are turned off. > > hl 1 "${@}" # because 'hl' inherently behaves like echo when not captures > einfo "Fetching $(hl "${r}" ) ..." > > Or something along those lines? > > I'd wager that a large body of things "not using it" is not because > it wouldn't be useful, but due to people knowing this problem exists? > > -- Further Bikeshed -- > > Maybe it could even be thematic? > >"Fetching $(hl url https://path.to/whatever )" > > Nah. > > But < hl > as a general concept works. > Something that could be included in gentoo-functions script(s)? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: acct-user/... modifies existing user sometimes
On Sat, 2019-12-14 at 14:47 -0600, The Bit Pit wrote: > acct-user/mythtv modifies the existing user if that user is not logged > in. Mythtv has been around for years and users have created specialized > configurations for the mythtv user. They do not like changes to the > mythtv user when upgrading. > > A couple of solutions: > > 1) > the ebuild does not depend on acct-user/mythtv when the user already > exists. This prevents both the changing and deletion of the existing user. > > What is the gentoo way to discover a preexisting user? Repoman does not > like anything I tried using egetent passwd mythtv > > 2) Add something to the acct-user/mythtv to (conditionally) prevent any > change if there is a preexisting user on the system. The acct-user > unmerge would also check that the user was not modified since it was > created by acct-user. This seems like a lot of work. > Users are supposed to create a local acct-user/mythtv override if they want to use a custom setup. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: acct-user/... modifies existing user sometimes
acct-user/mythtv modifies the existing user if that user is not logged in. Mythtv has been around for years and users have created specialized configurations for the mythtv user. They do not like changes to the mythtv user when upgrading. A couple of solutions: 1) the ebuild does not depend on acct-user/mythtv when the user already exists. This prevents both the changing and deletion of the existing user. What is the gentoo way to discover a preexisting user? Repoman does not like anything I tried using egetent passwd mythtv 2) Add something to the acct-user/mythtv to (conditionally) prevent any change if there is a preexisting user on the system. The acct-user unmerge would also check that the user was not modified since it was created by acct-user. This seems like a lot of work.
Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds
On Sat, Dec 14, 2019 at 10:31:06AM +0100, Toralf Förster wrote: > On 12/14/19 8:16 AM, Ulrich Mueller wrote: > > These prevent NOCOLOR in make.conf or emerge --color=n from working > > correctly, and I guess they are also problematic from an accessibility > > point of view. > +1 > > > Good idea Ulrich ! > The SGR control sequences are annoying in script based grepping of issues of > log streams. I agree more with this concern than an accessibility. Along the same lines, this is a concern when redirecting emerge output to a file then loading that file into an editor to do searches. William signature.asc Description: Digital signature
[gentoo-dev] [PATCH] elisp-common.eclass: Drop support for EAPIs 0 to 3.
This goes along with a small code simplification, since doins will die by itself in EAPI 4 or later. Signed-off-by: Ulrich Müller --- eclass/elisp-common.eclass | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass index 05b03f493957..ea172fe5a870 100644 --- a/eclass/elisp-common.eclass +++ b/eclass/elisp-common.eclass @@ -1,4 +1,4 @@ -# Copyright 1999-2015 Gentoo Foundation +# Copyright 1999-2019 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: elisp-common.eclass @@ -10,6 +10,7 @@ # Mamoru Komachi # Christian Faulhammer # Ulrich Müller +# @SUPPORTED_EAPIS: 4 5 6 7 # @BLURB: Emacs-related installation utilities # @DESCRIPTION: # @@ -156,6 +157,11 @@ # environment, so it is no problem when you unset USE=emacs between # merge and unmerge of a package. +case ${EAPI:-0} in + 4|5|6|7) ;; + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; +esac + # @ECLASS-VARIABLE: SITELISP # @DESCRIPTION: # Directory where packages install Emacs Lisp files. @@ -298,12 +304,11 @@ elisp-make-autoload-file() { elisp-install() { local subdir="$1" shift - ebegin "Installing Elisp files for GNU Emacs support" + einfo "Installing Elisp files for GNU Emacs support" ( # subshell to avoid pollution of calling environment insinto "${SITELISP}/${subdir}" doins "$@" ) - eend $? "elisp-install: doins failed" || die } # @FUNCTION: elisp-site-file-install @@ -316,14 +321,14 @@ elisp-install() { # respectively. elisp-site-file-install() { - local sf="${1##*/}" my_pn="${2:-${PN}}" ret + local sf="${1##*/}" my_pn="${2:-${PN}}" local header=";;; ${PN} site-lisp configuration" [[ ${sf} == [0-9][0-9]*-gentoo*.el ]] \ || ewarn "elisp-site-file-install: bad name of site-init file" [[ ${sf%-gentoo*.el} != "${sf}" ]] && sf="${sf%-gentoo*.el}-gentoo.el" + einfo "Installing site-init file ${sf} for GNU Emacs" sf="${T}/${sf}" - ebegin "Installing site initialisation file for GNU Emacs" [[ $1 = "${sf}" ]] || cp "$1" "${sf}" sed -i -e "1{:x;/^\$/{n;bx;};/^;.*${PN}/I!s:^:${header}\n\n:;1s:^:\n:;}" \ -e "s:@SITELISP@:${EPREFIX}${SITELISP}/${my_pn}:g" \ @@ -332,9 +337,7 @@ elisp-site-file-install() { insinto "${SITELISP}/site-gentoo.d" doins "${sf}" ) - ret=$? rm -f "${sf}" - eend ${ret} "elisp-site-file-install: doins failed" || die } # @FUNCTION: elisp-site-regen -- 2.24.1 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/3] python-any-r1.eclass: Constrain to EAPI >= 5
> On Sat, 14 Dec 2019, David Seifert wrote: > Also, it makes egencache failures in overlays more descriptive, and > hence I'd keep it for the time being. WFM signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/3] python-any-r1.eclass: Constrain to EAPI >= 5
On Sat, 2019-12-14 at 12:29 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 14 Dec 2019, David Seifert wrote: > > case "${EAPI:-0}" in > > - 0|1|2|3|4|5|6|7) > > + [01234]) > > + die "Unsupported EAPI=${EAPI:-0} (too old) for > > ${ECLASS}" > > + ;; > > + [567]) > > ;; > > *) > > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" > > I know that this exists in other eclasses as well, but do we really > need > that distinction in the error message for "too old" and "unknown" > EAPIs? > It should be pretty clear which case applies there, especially since > the > message is addressed at developers, not users. > > Ulrich Also, it makes egencache failures in overlays more descriptive, and hence I'd keep it for the time being.
Re: [gentoo-dev] [PATCH 1/3] python-any-r1.eclass: Constrain to EAPI >= 5
On Sat, 2019-12-14 at 12:29 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 14 Dec 2019, David Seifert wrote: > > case "${EAPI:-0}" in > > - 0|1|2|3|4|5|6|7) > > + [01234]) > > + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" > > + ;; > > + [567]) > > ;; > > *) > > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" > > I know that this exists in other eclasses as well, but do we really need > that distinction in the error message for "too old" and "unknown" EAPIs? > It should be pretty clear which case applies there, especially since the > message is addressed at developers, not users. > Maybe not strictly necessary right now but it gives a clear distinction whether the eclass hasn't been ported *yet* vs *won't* be ported at all. This helps avoid people trying to add new EAPIs to eclasses that are being deprecated. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] git-r3.eclass: Remove SGR control sequences from messages.
On Sat, 2019-12-14 at 12:29 +0100, Ulrich Müller wrote: > These prevent NOCOLOR in make.conf or emerge --color=n from working > correctly, and may also be problematic for accessibility. > > Signed-off-by: Ulrich Müller > --- > eclass/git-r3.eclass | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass > index e0d2bbb5edc0..144236c6ac38 100644 > --- a/eclass/git-r3.eclass > +++ b/eclass/git-r3.eclass > @@ -227,19 +227,19 @@ _git-r3_env_setup() { > ;; > single) > if [[ ${EGIT_CLONE_TYPE} == shallow ]]; then > - einfo "git-r3: ebuild needs to be cloned in > '\e[1msingle\e[22m' mode, adjusting" > + einfo "git-r3: ebuild needs to be cloned in > 'single' mode, adjusting" > EGIT_CLONE_TYPE=single > fi > ;; > single+tags) > if [[ ${EGIT_CLONE_TYPE} == shallow || > ${EGIT_CLONE_TYPE} == single ]]; then > - einfo "git-r3: ebuild needs to be cloned in > '\e[1msingle+tags\e[22m' mode, adjusting" > + einfo "git-r3: ebuild needs to be cloned in > 'single+tags' mode, adjusting" > EGIT_CLONE_TYPE=single+tags > fi > ;; > mirror) > if [[ ${EGIT_CLONE_TYPE} != mirror ]]; then > - einfo "git-r3: ebuild needs to be cloned in > '\e[1mmirror\e[22m' mode, adjusting" > + einfo "git-r3: ebuild needs to be cloned in > 'mirror' mode, adjusting" > EGIT_CLONE_TYPE=mirror > fi > ;; > @@ -439,7 +439,7 @@ _git-r3_set_submodules() { > done > > if [[ ! ${res} ]]; then > - einfo "Skipping submodule \e[1m${subname}\e[22m" > + einfo "Skipping submodule ${subname}" > continue > fi > fi > @@ -658,7 +658,7 @@ git-r3_fetch() { > fi > for r in "${repos[@]}"; do > if [[ ! ${EVCS_OFFLINE} ]]; then > - einfo "Fetching \e[1m${r}\e[22m ..." > + einfo "Fetching ${r} ..." > > local fetch_command=( git fetch "${r}" ) > local clone_type=${EGIT_CLONE_TYPE} > @@ -892,7 +892,7 @@ git-r3_checkout() { > local -x GIT_DIR > _git-r3_set_gitdir "${repos[0]}" > > - einfo "Checking out \e[1m${repos[0]}\e[22m to \e[1m${out_dir}\e[22m ..." > + einfo "Checking out ${repos[0]} to ${out_dir} ..." > > if ! git cat-file -e refs/git-r3/"${local_id}"/__main__; then > die "Logic error: no local clone of ${repos[0]}. git-r3_fetch > not used?" > @@ -1042,7 +1042,7 @@ git-r3_peek_remote_ref() { > > local r success > for r in "${repos[@]}"; do > - einfo "Peeking \e[1m${remote_ref}\e[22m on \e[1m${r}\e[22m ..." > >&2 > + einfo "Peeking ${remote_ref} on ${r} ..." >&2 > > local lookup_ref > if [[ ${remote_ref} == refs/* || ${remote_ref} == HEAD ]] > @@ -1098,9 +1098,9 @@ git-r3_pkg_needrebuild() { > [[ ${new_commit_id} && ${EGIT_VERSION} ]] || die "Lookup failed" > > if [[ ${EGIT_VERSION} != ${new_commit_id} ]]; then > - einfo "Update from \e[1m${EGIT_VERSION}\e[22m to > \e[1m${new_commit_id}\e[22m" > + einfo "Update from ${EGIT_VERSION} to ${new_commit_id}" > else > - einfo "Local and remote at \e[1m${EGIT_VERSION}\e[22m" > + einfo "Local and remote at ${EGIT_VERSION}" > fi > > [[ ${EGIT_VERSION} != ${new_commit_id} ]] Sure. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds
On Sat, 14 Dec 2019 08:16:03 +0100 Ulrich Mueller wrote: > These prevent NOCOLOR in make.conf or emerge --color=n from working > correctly, and I guess they are also problematic from an accessibility > point of view. > > Are there any objections against removing these sequences from strings? > AFAICS, they are used by less than ten packages, and one eclass. Maybe we can have some future EAPI feature, or special eclass, that allows people to add escape codes while also respecting the configuration. Sort of like what git has in its formatting codes, where they're turned off when colours are turned off. hl 1 "${@}" # because 'hl' inherently behaves like echo when not captures einfo "Fetching $(hl "${r}" ) ..." Or something along those lines? I'd wager that a large body of things "not using it" is not because it wouldn't be useful, but due to people knowing this problem exists? -- Further Bikeshed -- Maybe it could even be thematic? "Fetching $(hl url https://path.to/whatever )" Nah. But < hl > as a general concept works. pgpVJJDyXL5IW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] python-any-r1.eclass: Constrain to EAPI >= 5
On Sat, 2019-12-14 at 12:29 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 14 Dec 2019, David Seifert wrote: > > case "${EAPI:-0}" in > > - 0|1|2|3|4|5|6|7) > > + [01234]) > > + die "Unsupported EAPI=${EAPI:-0} (too old) for > > ${ECLASS}" > > + ;; > > + [567]) > > ;; > > *) > > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" > > I know that this exists in other eclasses as well, but do we really > need > that distinction in the error message for "too old" and "unknown" > EAPIs? > It should be pretty clear which case applies there, especially since > the > message is addressed at developers, not users. > > Ulrich This was just copypasta from the other python-r1.eclass. I personally don't care either way, it should IMO just be consistent across the tree.
[gentoo-dev] [PATCH] git-r3.eclass: Remove SGR control sequences from messages.
These prevent NOCOLOR in make.conf or emerge --color=n from working correctly, and may also be problematic for accessibility. Signed-off-by: Ulrich Müller --- eclass/git-r3.eclass | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass index e0d2bbb5edc0..144236c6ac38 100644 --- a/eclass/git-r3.eclass +++ b/eclass/git-r3.eclass @@ -227,19 +227,19 @@ _git-r3_env_setup() { ;; single) if [[ ${EGIT_CLONE_TYPE} == shallow ]]; then - einfo "git-r3: ebuild needs to be cloned in '\e[1msingle\e[22m' mode, adjusting" + einfo "git-r3: ebuild needs to be cloned in 'single' mode, adjusting" EGIT_CLONE_TYPE=single fi ;; single+tags) if [[ ${EGIT_CLONE_TYPE} == shallow || ${EGIT_CLONE_TYPE} == single ]]; then - einfo "git-r3: ebuild needs to be cloned in '\e[1msingle+tags\e[22m' mode, adjusting" + einfo "git-r3: ebuild needs to be cloned in 'single+tags' mode, adjusting" EGIT_CLONE_TYPE=single+tags fi ;; mirror) if [[ ${EGIT_CLONE_TYPE} != mirror ]]; then - einfo "git-r3: ebuild needs to be cloned in '\e[1mmirror\e[22m' mode, adjusting" + einfo "git-r3: ebuild needs to be cloned in 'mirror' mode, adjusting" EGIT_CLONE_TYPE=mirror fi ;; @@ -439,7 +439,7 @@ _git-r3_set_submodules() { done if [[ ! ${res} ]]; then - einfo "Skipping submodule \e[1m${subname}\e[22m" + einfo "Skipping submodule ${subname}" continue fi fi @@ -658,7 +658,7 @@ git-r3_fetch() { fi for r in "${repos[@]}"; do if [[ ! ${EVCS_OFFLINE} ]]; then - einfo "Fetching \e[1m${r}\e[22m ..." + einfo "Fetching ${r} ..." local fetch_command=( git fetch "${r}" ) local clone_type=${EGIT_CLONE_TYPE} @@ -892,7 +892,7 @@ git-r3_checkout() { local -x GIT_DIR _git-r3_set_gitdir "${repos[0]}" - einfo "Checking out \e[1m${repos[0]}\e[22m to \e[1m${out_dir}\e[22m ..." + einfo "Checking out ${repos[0]} to ${out_dir} ..." if ! git cat-file -e refs/git-r3/"${local_id}"/__main__; then die "Logic error: no local clone of ${repos[0]}. git-r3_fetch not used?" @@ -1042,7 +1042,7 @@ git-r3_peek_remote_ref() { local r success for r in "${repos[@]}"; do - einfo "Peeking \e[1m${remote_ref}\e[22m on \e[1m${r}\e[22m ..." >&2 + einfo "Peeking ${remote_ref} on ${r} ..." >&2 local lookup_ref if [[ ${remote_ref} == refs/* || ${remote_ref} == HEAD ]] @@ -1098,9 +1098,9 @@ git-r3_pkg_needrebuild() { [[ ${new_commit_id} && ${EGIT_VERSION} ]] || die "Lookup failed" if [[ ${EGIT_VERSION} != ${new_commit_id} ]]; then - einfo "Update from \e[1m${EGIT_VERSION}\e[22m to \e[1m${new_commit_id}\e[22m" + einfo "Update from ${EGIT_VERSION} to ${new_commit_id}" else - einfo "Local and remote at \e[1m${EGIT_VERSION}\e[22m" + einfo "Local and remote at ${EGIT_VERSION}" fi [[ ${EGIT_VERSION} != ${new_commit_id} ]] -- 2.24.1 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/3] python-any-r1.eclass: Constrain to EAPI >= 5
> On Sat, 14 Dec 2019, David Seifert wrote: > case "${EAPI:-0}" in > - 0|1|2|3|4|5|6|7) > + [01234]) > + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" > + ;; > + [567]) > ;; > *) > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" I know that this exists in other eclasses as well, but do we really need that distinction in the error message for "too old" and "unknown" EAPIs? It should be pretty clear which case applies there, especially since the message is addressed at developers, not users. Ulrich signature.asc Description: PGP signature
[gentoo-dev] [PATCH 3/3] python-utils-r1.eclass: Remove Python 3.5
* Python 3.5 will go EOL on 2020-09-13 and in order to reduce testing and maintenance burden, we want to keep the number of active Py3 impls below four. https://devguide.python.org/#status-of-python-branches Signed-off-by: David Seifert --- eclass/python-utils-r1.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass index 779e228e4dc..aae091fade7 100644 --- a/eclass/python-utils-r1.eclass +++ b/eclass/python-utils-r1.eclass @@ -47,7 +47,7 @@ _PYTHON_ALL_IMPLS=( jython2_7 pypy pypy3 python2_7 - python3_5 python3_6 python3_7 python3_8 + python3_6 python3_7 python3_8 ) readonly _PYTHON_ALL_IMPLS @@ -83,10 +83,10 @@ _python_impl_supported() { # keep in sync with _PYTHON_ALL_IMPLS! # (not using that list because inline patterns shall be faster) case "${impl}" in - python2_7|python3_[5678]|jython2_7|pypy|pypy3) + python2_7|python3_[678]|jython2_7|pypy|pypy3) return 0 ;; - pypy1_[89]|pypy2_0|python2_[56]|python3_[1234]) + pypy1_[89]|pypy2_0|python2_[56]|python3_[12345]) return 1 ;; *) -- 2.24.1
[gentoo-dev] [PATCH 2/3] python-utils-r1.eclass: Constrain to EAPI >= 5
Signed-off-by: David Seifert --- eclass/python-utils-r1.eclass | 32 +--- 1 file changed, 9 insertions(+), 23 deletions(-) diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass index 3eadc50f93e..779e228e4dc 100644 --- a/eclass/python-utils-r1.eclass +++ b/eclass/python-utils-r1.eclass @@ -7,7 +7,7 @@ # @AUTHOR: # Author: Michał Górny # Based on work of: Krzysztof Pawlik -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 # @BLURB: Utility functions for packages with Python parts. # @DESCRIPTION: # A utility eclass providing functions to query Python implementations, @@ -20,7 +20,10 @@ # https://wiki.gentoo.org/wiki/Project:Python/python-utils-r1 case "${EAPI:-0}" in - 0|1|2|3|4|5|6|7) + [01234]) + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" + ;; + [567]) ;; *) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" @@ -33,7 +36,7 @@ fi if [[ ! ${_PYTHON_UTILS_R1} ]]; then -[[ ${EAPI:-0} == [012345] ]] && inherit eutils multilib +[[ ${EAPI} == 5 ]] && inherit eutils multilib inherit toolchain-funcs # @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS @@ -80,17 +83,12 @@ _python_impl_supported() { # keep in sync with _PYTHON_ALL_IMPLS! # (not using that list because inline patterns shall be faster) case "${impl}" in - python2_7|python3_[5678]|jython2_7) + python2_7|python3_[5678]|jython2_7|pypy|pypy3) return 0 ;; pypy1_[89]|pypy2_0|python2_[56]|python3_[1234]) return 1 ;; - pypy|pypy3) - if [[ ${EAPI:-0} == [01234] ]]; then - die "PyPy is supported in EAPI 5 and newer only." - fi - ;; *) [[ ${PYTHON_COMPAT_NO_STRICT} ]] && return 1 die "Invalid implementation in PYTHON_COMPAT: ${impl}" @@ -776,9 +774,6 @@ python_newexe() { [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is null).' [[ ${#} -eq 2 ]] || die "Usage: ${FUNCNAME} " - if [[ ${EAPI:-0} == [0123] ]]; then - die "python_do* and python_new* helpers are banned in EAPIs older than 4." - fi local wrapd=${python_scriptroot:-/usr/bin} @@ -906,9 +901,6 @@ python_domodule() { debug-print-function ${FUNCNAME} "${@}" [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is null).' - if [[ ${EAPI:-0} == [0123] ]]; then - die "python_do* and python_new* helpers are banned in EAPIs older than 4." - fi local d if [[ ${python_moduleroot} == /* ]]; then @@ -948,9 +940,6 @@ python_doheader() { debug-print-function ${FUNCNAME} "${@}" [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is null).' - if [[ ${EAPI:-0} == [0123] ]]; then - die "python_do* and python_new* helpers are banned in EAPIs older than 4." - fi local d PYTHON_INCLUDEDIR=${PYTHON_INCLUDEDIR} [[ ${PYTHON_INCLUDEDIR} ]] || python_export PYTHON_INCLUDEDIR @@ -1093,10 +1082,7 @@ python_is_installed() { [[ ${impl} ]] || die "${FUNCNAME}: no impl nor EPYTHON" local hasv_args=() - case ${EAPI:-0} in - 0|1|2|3|4) - local -x ROOT=/ - ;; + case ${EAPI} in 5|6) hasv_args+=( --host-root ) ;; @@ -1265,7 +1251,7 @@ python_fix_shebang() { if [[ ! ${any_fixed} ]]; then local cmd=eerror - [[ ${EAPI:-0} == [012345] ]] && cmd=eqawarn + [[ ${EAPI} == 5 ]] && cmd=eqawarn "${cmd}" "QA warning: ${FUNCNAME}, ${path#${D%/}} did not match any fixable files." if [[ ${any_correct} ]]; then -- 2.24.1
[gentoo-dev] [PATCH 1/3] python-any-r1.eclass: Constrain to EAPI >= 5
Signed-off-by: David Seifert --- eclass/python-any-r1.eclass | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass index 3863ef6fa84..869ece64c65 100644 --- a/eclass/python-any-r1.eclass +++ b/eclass/python-any-r1.eclass @@ -7,7 +7,7 @@ # @AUTHOR: # Author: Michał Górny # Based on work of: Krzysztof Pawlik -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7 +# @SUPPORTED_EAPIS: 5 6 7 # @BLURB: An eclass for packages having build-time dependency on Python. # @DESCRIPTION: # A minimal eclass for packages which need any Python interpreter @@ -37,7 +37,10 @@ # https://wiki.gentoo.org/wiki/Project:Python/python-any-r1 case "${EAPI:-0}" in - 0|1|2|3|4|5|6|7) + [01234]) + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" + ;; + [567]) ;; *) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" -- 2.24.1
Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds
On 12/14/19 8:16 AM, Ulrich Mueller wrote: > These prevent NOCOLOR in make.conf or emerge --color=n from working > correctly, and I guess they are also problematic from an accessibility > point of view. +1 Good idea Ulrich ! The SGR control sequences are annoying in script based grepping of issues of log streams. -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: dev-libs/botan
Due to the proxied maintainer resigning, the following package is now up for grabs: dev-libs/botan It needs a version bump. It has no other bugs reported. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part