Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
> On Sat, 14 Dec 2019, Michał Górny wrote: > Actually, I added that because of your comment that people should be > rebasing patches rather than removing context. Isn't rebasing easier than removing context, anyway? I'd trust the maintainer to do the right thing there. The main argument is that the warning is apparently seen by some users, who will then file unwanted bug reports. (Also, as I said before, we don't even have a policy that patches must apply without fuzz.) Ulrich signature.asc Description: PGP signature
[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
[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
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
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, 2019-12-13 at 17:15 -0500, Mike Gilbert wrote: > On Fri, Dec 13, 2019 at 4:42 PM Michał Górny wrote: > > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: > > > On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: > > > > Just like 'many of the proposals lately', developers are going to be > > > > the ones disabling it (because they don't care), and users will be the > > > > ones enabling it (because they do care), just to learn that developers > > > > don't care and go complaining to the mailing lists that users dare > > > > report issues they don't care about. > > > > > > I care if the patch is actually broken, which the warning doesn't > > > really tell me. It's just not a very reliable indicator, and will > > > produce false-positives frequently. > > > > > > > You can also take less context into the patch and use -F0. Then you'll > > have the same effect, no warnings to bother you and no pretending that > > the patch applies when it doesn't. > > That really doesn't help me. My point is that I don't want to touch > the patch unless it is actually necessary to do so. > Then make patches with -U0. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
On Fri, 2019-12-13 at 23:49 +0100, Ulrich Mueller wrote:
> > > > > > On Fri, 13 Dec 2019, Mike Gilbert wrote:
> > > > It also triggers pointless bug reports. Please remove this.
> > >
> > > I don't like that eqawarn either (see above).
> > >
> > > OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES,
> > > so they won't see the warning?
> > Here's a bug report filed by a user, which is what prompted me to
> > reply on this thread in the first place.
> > https://bugs.gentoo.org/702608
>
> Well then, trivial patch included below.
>
>
> From 81000b32d330a1cc41a4541f7e4264918eb7e6c5 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
> Date: Fri, 13 Dec 2019 23:41:23 +0100
> Subject: [PATCH] eapply: Drop QA warning for fuzz factor.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> This didn't add any information beyond what is already present in the
> output of patch. Developers will know how to interpret its output, and
> users won't see the warning anyway with the standard configuration.
>
> Signed-off-by: Ulrich Müller
> ---
> bin/phase-helpers.sh | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
> index b5691bd70..020862ba0 100644
> --- a/bin/phase-helpers.sh
> +++ b/bin/phase-helpers.sh
> @@ -1004,8 +1004,6 @@ if ___eapi_has_eapply; then
> if ${patch_cmd} "${all_opts[@]}" --dry-run -s -F0 \
> < "${f}" &>/dev/null; then
> all_opts+=( -s -F0 )
> - else
> - eqawarn "${f}: patch failed to apply
> without a fuzz factor, please rebase"
> fi
>
> ${patch_cmd} "${all_opts[@]}" < "${f}"
Actually, I added that because of your comment that people should be
rebasing patches rather than removing context.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
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] [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] 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, 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.
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-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Sat, Dec 14, 2019 at 3:41 AM Michał Górny wrote: > > On Fri, 2019-12-13 at 17:15 -0500, Mike Gilbert wrote: > > On Fri, Dec 13, 2019 at 4:42 PM Michał Górny wrote: > > > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: > > > > On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: > > > > > Just like 'many of the proposals lately', developers are going to be > > > > > the ones disabling it (because they don't care), and users will be the > > > > > ones enabling it (because they do care), just to learn that developers > > > > > don't care and go complaining to the mailing lists that users dare > > > > > report issues they don't care about. > > > > > > > > I care if the patch is actually broken, which the warning doesn't > > > > really tell me. It's just not a very reliable indicator, and will > > > > produce false-positives frequently. > > > > > > > > > > You can also take less context into the patch and use -F0. Then you'll > > > have the same effect, no warnings to bother you and no pretending that > > > the patch applies when it doesn't. > > > > That really doesn't help me. My point is that I don't want to touch > > the patch unless it is actually necessary to do so. > > > > Then make patches with -U0. As others have already stated, I might not be the one making the patch in the first place. Your position seems to be that ignoring any amount of context is bad, and I simply don't agree with that. If you can show me that it is causing an epidemic of broken patches to be applied erroneously, you might change my mind. Otherwise, please stop with the non-solutions you keep throwing at me.
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, 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] 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,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/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).
[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
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
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 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
[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-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Sat, Dec 14, 2019 at 8:12 AM Mike Gilbert wrote: > > On Sat, Dec 14, 2019 at 3:41 AM Michał Górny wrote: > > > > On Fri, 2019-12-13 at 17:15 -0500, Mike Gilbert wrote: > > > On Fri, Dec 13, 2019 at 4:42 PM Michał Górny wrote: > > > > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: > > > > > On Fri, Dec 13, 2019 at 3:36 PM Michał Górny > > > > > wrote: > > > > > > Just like 'many of the proposals lately', developers are going to be > > > > > > the ones disabling it (because they don't care), and users will be > > > > > > the > > > > > > ones enabling it (because they do care), just to learn that > > > > > > developers > > > > > > don't care and go complaining to the mailing lists that users dare > > > > > > report issues they don't care about. > > > > > > > > > > I care if the patch is actually broken, which the warning doesn't > > > > > really tell me. It's just not a very reliable indicator, and will > > > > > produce false-positives frequently. > > > > > > > > > > > > > You can also take less context into the patch and use -F0. Then you'll > > > > have the same effect, no warnings to bother you and no pretending that > > > > the patch applies when it doesn't. > > > > > > That really doesn't help me. My point is that I don't want to touch > > > the patch unless it is actually necessary to do so. > > > > > > > Then make patches with -U0. > > As others have already stated, I might not be the one making the patch > in the first place. > > Your position seems to be that ignoring any amount of context is bad, > and I simply don't agree with that. If you can show me that it is > causing an epidemic of broken patches to be applied erroneously, you > might change my mind. Otherwise, please stop with the non-solutions > you keep throwing at me. After giving it some further thought, I suppose I'm overreacting to this a bit. Most patches won't be affected by this anyway.
