Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
> On Thu, 17 Dec 2020, Mike Gilbert wrote: > Doesn't the same restriction apply to relicensing it? No, because the CC licenses have an explicit provision that allows it when distributing a modified work (which they call an "Adaptation", defined in section 1a). For example, CC-BY-SA-3.0 says in section 4b: You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License. [...] Item (ii) is what gives us the right to distribute under CC-BY-SA-4.0. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On 2020-12-18 01:24, Mike Gilbert wrote: The GLEP already mentions the SKS keyserver pool, and the Gentoo LDAP directory. Are these not also "implementation details"? Hrm, I missed point 7. In this case how about replacing Upload your key to the SKS keyserver rotation before usage! with Upload your key to the keyservers [11] before usage! > > [...] > > References > > [...] > [11] Gentoo Wiki: Upload GLEP 63 based OpenPGP keys to keyservers (https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver) That's all I would do to keep as many details out of the specs. But maybe I am the only one who is so strict about the spec... I am just saying and asking for comments. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 6:58 PM Thomas Deutschmann wrote: > > Hi, > > sorry to be a show stopper here but I have to admit I don't like this > addition. > > If I remember correctly we were talking about this when we actively > worked on this GLEP and decided to not put put anything like that into > GLEP because this is a implementation detail which doesn't belong into > 'specs'. > > We maybe can talk about adding just a reference link to the Wiki guide > but I don't believe we should add this to GLEP. The GLEP already mentions the SKS keyserver pool, and the Gentoo LDAP directory. Are these not also "implementation details"?
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
Hi, sorry to be a show stopper here but I have to admit I don't like this addition. If I remember correctly we were talking about this when we actively worked on this GLEP and decided to not put put anything like that into GLEP because this is a implementation detail which doesn't belong into 'specs'. We maybe can talk about adding just a reference link to the Wiki guide but I don't believe we should add this to GLEP. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 5:03 PM Ulrich Mueller wrote: > > > On Thu, 17 Dec 2020, Mike Gilbert wrote: > > > Should I also drop the explicit copyright notice? > > >> Copyright (c) 2013-2019 by Robin Hugh Johnson, Andreas K. Hüttel, > >> Marissa Fischer, Michał Górny. > > I think that a GLEP shouldn't have such a notice (after all, authors > are listed in the GLEP's header), but you cannot remove it without > permission of all authors. Doesn't the same restriction apply to relicensing it?
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
> On Thu, 17 Dec 2020, Mike Gilbert wrote: > Should I also drop the explicit copyright notice? >> Copyright (c) 2013-2019 by Robin Hugh Johnson, Andreas K. Hüttel, >> Marissa Fischer, Michał Górny. I think that a GLEP shouldn't have such a notice (after all, authors are listed in the GLEP's header), but you cannot remove it without permission of all authors. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: use python eselect module in _meson_env_array
On Thu, 2020-12-17 at 16:50 -0500, Mike Gilbert wrote:
> On Thu, Dec 17, 2020 at 4:44 PM Michał Górny
> wrote:
> >
> > On Thu, 2020-12-17 at 16:30 -0500, Mike Gilbert wrote:
> > > Closes: https://bugs.gentoo.org/759433
> > > Signed-off-by: Mike Gilbert
> > > ---
> > > eclass/meson.eclass | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > > index 21338280df33..6296f1dd26e5 100644
> > > --- a/eclass/meson.eclass
> > > +++ b/eclass/meson.eclass
> > > @@ -126,7 +126,8 @@ EOF
> > > # '--unicode-16=𐐷', '--unicode-32=𐤅']
> > > #
> > > _meson_env_array() {
> > > - python -c "${__MESON_ARRAY_PARSER}" "$@"
> > > + local python="$(eselect python show)"
> > > + ${python} -c "${__MESON_ARRAY_PARSER}" "$@"
> > > }
> > >
> > > # @FUNCTION: _meson_get_machine_info
> >
> > You're missing a BDEPEND on app-eselect/eselect-python.
> >
> > Also, I really don't like these workarounds. It takes a lot of
> > effort
> > to figure out how to break stuff, so people stop doing awful
> > things.
> > It's disrespectful to my time when you invent new hacks. Now I'll
> > have
> > to figure out how to change eselect-python to break it.
>
> Why is this such an awful thing to do?
>
> The code should be able to execute with any version of python
> currently supported by Gentoo.
>
> Please don't assume that I'm trying to avoid a proper solution here.
> Please suggest a better alternative if you have one.
I actually liked installing the script to the system.
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: use python eselect module in _meson_env_array
On Thu, Dec 17, 2020 at 4:44 PM Michał Górny wrote:
>
> On Thu, 2020-12-17 at 16:30 -0500, Mike Gilbert wrote:
> > Closes: https://bugs.gentoo.org/759433
> > Signed-off-by: Mike Gilbert
> > ---
> > eclass/meson.eclass | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index 21338280df33..6296f1dd26e5 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -126,7 +126,8 @@ EOF
> > # '--unicode-16=𐐷', '--unicode-32=𐤅']
> > #
> > _meson_env_array() {
> > - python -c "${__MESON_ARRAY_PARSER}" "$@"
> > + local python="$(eselect python show)"
> > + ${python} -c "${__MESON_ARRAY_PARSER}" "$@"
> > }
> >
> > # @FUNCTION: _meson_get_machine_info
>
> You're missing a BDEPEND on app-eselect/eselect-python.
>
> Also, I really don't like these workarounds. It takes a lot of effort
> to figure out how to break stuff, so people stop doing awful things.
> It's disrespectful to my time when you invent new hacks. Now I'll have
> to figure out how to change eselect-python to break it.
Why is this such an awful thing to do?
The code should be able to execute with any version of python
currently supported by Gentoo.
Please don't assume that I'm trying to avoid a proper solution here.
Please suggest a better alternative if you have one.
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: use python eselect module in _meson_env_array
On Thu, 2020-12-17 at 16:30 -0500, Mike Gilbert wrote:
> Closes: https://bugs.gentoo.org/759433
> Signed-off-by: Mike Gilbert
> ---
> eclass/meson.eclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 21338280df33..6296f1dd26e5 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -126,7 +126,8 @@ EOF
> # '--unicode-16=𐐷', '--unicode-32=𐤅']
> #
> _meson_env_array() {
> - python -c "${__MESON_ARRAY_PARSER}" "$@"
> + local python="$(eselect python show)"
> + ${python} -c "${__MESON_ARRAY_PARSER}" "$@"
> }
>
> # @FUNCTION: _meson_get_machine_info
You're missing a BDEPEND on app-eselect/eselect-python.
Also, I really don't like these workarounds. It takes a lot of effort
to figure out how to break stuff, so people stop doing awful things.
It's disrespectful to my time when you invent new hacks. Now I'll have
to figure out how to change eselect-python to break it.
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 4:31 PM Ulrich Mueller wrote: > > Please also update the license of the GLEP to CC-BY-SA-4.0 [1]. > See for example glep-0001.rst for the new footer. > > [1] > https://www.gentoo.org/glep/glep-0001.html#what-belongs-in-a-successful-glep > (item 8) Should I also drop the explicit copyright notice? > Copyright (c) 2013-2019 by Robin Hugh Johnson, Andreas K. Hüttel, > Marissa Fischer, Michał Górny.
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
Please also update the license of the GLEP to CC-BY-SA-4.0 [1]. See for example glep-0001.rst for the new footer. [1] https://www.gentoo.org/glep/glep-0001.html#what-belongs-in-a-successful-glep (item 8) signature.asc Description: PGP signature
[gentoo-dev] [PATCH 3/3] app-emulation/gallium-nine-standalone: update meson_env_array refereneces
Signed-off-by: Mike Gilbert
---
.../gallium-nine-standalone-0.7.ebuild| 4 ++--
.../gallium-nine-standalone-.ebuild | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild
b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild
index 3e96326a2fc8..1f833e7646b6 100644
--- a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild
+++ b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-0.7.ebuild
@@ -65,8 +65,8 @@ src_prepare() {
sed \
-e "s!@PKG_CONFIG@!$(tc-getPKG_CONFIG)!" \
- -e "s!@CFLAGS@!$(_meson_env_array "${CFLAGS}
'-DG9DLL=${g9dll}'")!" \
- -e "s!@LDFLAGS@!$(_meson_env_array "${LDFLAGS}")!" \
+ -e "s!@CFLAGS@!$(meson_env_array "${CFLAGS}
'-DG9DLL=${g9dll}'")!" \
+ -e "s!@LDFLAGS@!$(meson_env_array "${LDFLAGS}")!" \
-e
"s!@PKG_CONFIG_LIBDIR@!${PKG_CONFIG_LIBDIR:-${ESYSROOT}/usr/$(get_libdir)/pkgconfig}!"
\
${file}.in > ${file} || die
}
diff --git
a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild
b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild
index 3e96326a2fc8..1f833e7646b6 100644
--- a/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild
+++ b/app-emulation/gallium-nine-standalone/gallium-nine-standalone-.ebuild
@@ -65,8 +65,8 @@ src_prepare() {
sed \
-e "s!@PKG_CONFIG@!$(tc-getPKG_CONFIG)!" \
- -e "s!@CFLAGS@!$(_meson_env_array "${CFLAGS}
'-DG9DLL=${g9dll}'")!" \
- -e "s!@LDFLAGS@!$(_meson_env_array "${LDFLAGS}")!" \
+ -e "s!@CFLAGS@!$(meson_env_array "${CFLAGS}
'-DG9DLL=${g9dll}'")!" \
+ -e "s!@LDFLAGS@!$(meson_env_array "${LDFLAGS}")!" \
-e
"s!@PKG_CONFIG_LIBDIR@!${PKG_CONFIG_LIBDIR:-${ESYSROOT}/usr/$(get_libdir)/pkgconfig}!"
\
${file}.in > ${file} || die
}
--
2.30.0.rc0
[gentoo-dev] [PATCH 1/3] meson.eclass: use python eselect module in _meson_env_array
Closes: https://bugs.gentoo.org/759433
Signed-off-by: Mike Gilbert
---
eclass/meson.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 21338280df33..6296f1dd26e5 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -126,7 +126,8 @@ EOF
# '--unicode-16=𐐷', '--unicode-32=𐤅']
#
_meson_env_array() {
- python -c "${__MESON_ARRAY_PARSER}" "$@"
+ local python="$(eselect python show)"
+ ${python} -c "${__MESON_ARRAY_PARSER}" "$@"
}
# @FUNCTION: _meson_get_machine_info
--
2.30.0.rc0
[gentoo-dev] [PATCH 2/3] meson.eclass: make meson_env_array public
Signed-off-by: Mike Gilbert
---
eclass/meson.eclass | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 6296f1dd26e5..7bd4b7ec8395 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -107,8 +107,8 @@ print("[{}]".format(
", ".join([quote(x) for x in shlex.split(" ".join(sys.argv[1:]))])))
EOF
-# @FUNCTION: _meson_env_array
-# @INTERNAL
+# @FUNCTION: meson_env_array
+# @USAGE: ...
# @DESCRIPTION:
# Parses the command line flags and converts them into an array suitable for
# use in a cross file.
@@ -125,7 +125,7 @@ EOF
# '--full-word-backslash=Hello World', '--simple', '--unicode-8=©',
# '--unicode-16=𐐷', '--unicode-32=𐤅']
#
-_meson_env_array() {
+meson_env_array() {
local python="$(eselect python show)"
${python} -c "${__MESON_ARRAY_PARSER}" "$@"
}
@@ -174,29 +174,29 @@ _meson_create_cross_file() {
cat > "${fn}" <<-EOF
[binaries]
- ar = $(_meson_env_array "$(tc-getAR)")
- c = $(_meson_env_array "$(tc-getCC)")
- cpp = $(_meson_env_array "$(tc-getCXX)")
- fortran = $(_meson_env_array "$(tc-getFC)")
+ ar = $(meson_env_array "$(tc-getAR)")
+ c = $(meson_env_array "$(tc-getCC)")
+ cpp = $(meson_env_array "$(tc-getCXX)")
+ fortran = $(meson_env_array "$(tc-getFC)")
llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
- nm = $(_meson_env_array "$(tc-getNM)")
- objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
- objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
+ nm = $(meson_env_array "$(tc-getNM)")
+ objc = $(meson_env_array "$(tc-getPROG OBJC cc)")
+ objcpp = $(meson_env_array "$(tc-getPROG OBJCXX c++)")
pkgconfig = '$(tc-getPKG_CONFIG)'
- strip = $(_meson_env_array "$(tc-getSTRIP)")
- windres = $(_meson_env_array "$(tc-getRC)")
+ strip = $(meson_env_array "$(tc-getSTRIP)")
+ windres = $(meson_env_array "$(tc-getRC)")
[properties]
- c_args = $(_meson_env_array "${CFLAGS} ${CPPFLAGS}")
- c_link_args = $(_meson_env_array "${CFLAGS} ${LDFLAGS}")
- cpp_args = $(_meson_env_array "${CXXFLAGS} ${CPPFLAGS}")
- cpp_link_args = $(_meson_env_array "${CXXFLAGS} ${LDFLAGS}")
- fortran_args = $(_meson_env_array "${FCFLAGS}")
- fortran_link_args = $(_meson_env_array "${FCFLAGS} ${LDFLAGS}")
- objc_args = $(_meson_env_array "${OBJCFLAGS} ${CPPFLAGS}")
- objc_link_args = $(_meson_env_array "${OBJCFLAGS} ${LDFLAGS}")
- objcpp_args = $(_meson_env_array "${OBJCXXFLAGS} ${CPPFLAGS}")
- objcpp_link_args = $(_meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
+ c_args = $(meson_env_array "${CFLAGS} ${CPPFLAGS}")
+ c_link_args = $(meson_env_array "${CFLAGS} ${LDFLAGS}")
+ cpp_args = $(meson_env_array "${CXXFLAGS} ${CPPFLAGS}")
+ cpp_link_args = $(meson_env_array "${CXXFLAGS} ${LDFLAGS}")
+ fortran_args = $(meson_env_array "${FCFLAGS}")
+ fortran_link_args = $(meson_env_array "${FCFLAGS} ${LDFLAGS}")
+ objc_args = $(meson_env_array "${OBJCFLAGS} ${CPPFLAGS}")
+ objc_link_args = $(meson_env_array "${OBJCFLAGS} ${LDFLAGS}")
+ objcpp_args = $(meson_env_array "${OBJCXXFLAGS} ${CPPFLAGS}")
+ objcpp_link_args = $(meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
needs_exe_wrapper = true
sys_root = '${SYSROOT}'
pkg_config_libdir =
'${PKG_CONFIG_LIBDIR:-${EPREFIX}/usr/$(get_libdir)/pkgconfig}'
--
2.30.0.rc0
[gentoo-dev] [PATCH 4/4] python-r1.eclass: Support PYTHON_SINGLE_USEDEP in any-dep API
Signed-off-by: Michał Górny
---
eclass/python-r1.eclass | 40 +---
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index e7a660219c17..5cae020c6d90 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -152,6 +152,28 @@ fi
# python_targets_python2_7(-)?,python_targets_python3_4(-)?
# @CODE
+# @ECLASS-VARIABLE: PYTHON_SINGLE_USEDEP
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# An eclass-generated USE-dependency string for the currently tested
+# implementation. It is set locally for python_check_deps() call.
+#
+# The generated USE-flag list is compatible with packages using
+# python-single-r1 eclass. For python-r1 dependencies,
+# use PYTHON_USEDEP.
+#
+# Example use:
+# @CODE
+# python_check_deps() {
+# has_version "dev-python/bar[${PYTHON_SINGLE_USEDEP}]"
+# }
+# @CODE
+#
+# Example value:
+# @CODE
+# python_single_target_python3_7(-)
+# @CODE
+
# @ECLASS-VARIABLE: PYTHON_REQUIRED_USE
# @OUTPUT_VARIABLE
# @DESCRIPTION:
@@ -507,9 +529,10 @@ python_gen_impl_dep() {
# Generate an any-of dependency that enforces a version match between
# the Python interpreter and Python packages. needs
# to list one or more dependencies with verbatim '${PYTHON_USEDEP}'
-# references (quoted!) that will get expanded inside the function.
-# Optionally, patterns may be specified to restrict the dependency
-# to a subset of Python implementations supported by the ebuild.
+# or '${PYTHON_SINGLE_USEDEP}' references (quoted!) that will get
+# expanded inside the function. Optionally, patterns may be specified
+# to restrict the dependency to a subset of Python implementations
+# supported by the ebuild.
#
# The patterns can be either fnmatch-style patterns (matched via bash
# == operator against PYTHON_COMPAT values) or '-2' / '-3' to indicate
@@ -524,12 +547,12 @@ python_gen_impl_dep() {
# Example use:
# @CODE
# DEPEND="$(python_gen_any_dep '
-# dev-python/foo[${PYTHON_USEDEP}]
+# dev-python/foo[${PYTHON_SINGLE_USEDEP}]
# || ( dev-python/bar[${PYTHON_USEDEP}]
# dev-python/baz[${PYTHON_USEDEP}] )' -2)"
#
# python_check_deps() {
-# has_version "dev-python/foo[${PYTHON_USEDEP}]" \
+# has_version "dev-python/foo[${PYTHON_SINGLE_USEDEP}]" \
# && { has_version "dev-python/bar[${PYTHON_USEDEP}]" \
# || has_version "dev-python/baz[${PYTHON_USEDEP}]"; }
# }
@@ -548,13 +571,13 @@ python_gen_impl_dep() {
# || (
# (
# dev-lang/python:3.7
-#
dev-python/foo[python_targets_python3_7(-),-python_single_target_python3_7(-)]
+# dev-python/foo[python_single_target_python3_7(-)]
# || (
dev-python/bar[python_targets_python3_7(-),-python_single_target_python3_7(-)]
#
dev-python/baz[python_targets_python3_7(-),-python_single_target_python3_7(-)] )
# )
# (
# dev-lang/python:3.8
-#
dev-python/foo[python_targets_python3_8(-),-python_single_target_python3_8(-)]
+# dev-python/foo[python_single_target_python3_8(-)]
# || (
dev-python/bar[python_targets_python3_8(-),-python_single_target_python3_8(-)]
#
dev-python/baz[python_targets_python3_8(-),-python_single_target_python3_8(-)] )
# )
@@ -572,9 +595,11 @@ python_gen_any_dep() {
for i in "${_PYTHON_SUPPORTED_IMPLS[@]}"; do
if _python_impl_matches "${i}" "${@}"; then
local
PYTHON_USEDEP="python_targets_${i}(-),-python_single_target_${i}(-)"
+ local
PYTHON_SINGLE_USEDEP="python_single_target_${i}(-)"
_python_export "${i}" PYTHON_PKG_DEP
local
i_depstr=${depstr//\$\{PYTHON_USEDEP\}/${PYTHON_USEDEP}}
+
i_depstr=${i_depstr//\$\{PYTHON_SINGLE_USEDEP\}/${PYTHON_SINGLE_USEDEP}}
# note: need to strip '=' slot operator for || deps
out="( ${PYTHON_PKG_DEP/:0=/:0} ${i_depstr} ) ${out}"
fi
@@ -780,6 +805,7 @@ python_setup() {
python_is_installed "${impl}" || continue
# then run python_check_deps
local
PYTHON_USEDEP="python_targets_${impl}(-),-python_single_target_${impl}(-)"
+ local
PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
python_check_deps || continue
fi
--
2.29.2
[gentoo-dev] [PATCH 3/4] python-any-r1.eclass: Support PYTHON_SINGLE_USEDEP
Closes: https://bugs.gentoo.org/713894
Signed-off-by: Michał Górny
---
eclass/python-any-r1.eclass | 48 +
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index 9fd7fd6bc27d..5f2dc5b8f384 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -24,9 +24,10 @@
# be called by the eclass with EPYTHON set to each matching Python
# implementation and it is expected to check whether the implementation
# fulfills the package requirements. You can use the locally exported
-# PYTHON_USEDEP to check USE-dependencies of relevant packages. It
-# should return a true value (0) if the Python implementation fulfills
-# the requirements, a false value (non-zero) otherwise.
+# PYTHON_USEDEP or PYTHON_SINGLE_USEDEP to check USE-dependencies
+# of relevant packages. It should return a true value (0) if the Python
+# implementation fulfills the requirements, a false value (non-zero)
+# otherwise.
#
# Please note that python-any-r1 will always inherit python-utils-r1
# as well. Thus, all the functions defined there can be used in the
@@ -131,8 +132,9 @@ EXPORT_FUNCTIONS pkg_setup
# An eclass-generated USE-dependency string for the currently tested
# implementation. It is set locally for python_check_deps() call.
#
-# The generate USE-flag list is compatible with packages using python-r1
-# eclass. It must not be used on packages using other eclasses.
+# The generated USE-flag list is compatible with packages using
+# python-r1 eclass. For python-single-r1 dependencies,
+# use PYTHON_SINGLE_USEDEP.
#
# Example use:
# @CODE
@@ -146,6 +148,28 @@ EXPORT_FUNCTIONS pkg_setup
# python_targets_python3_7(-),-python_single_target_python3_7(-)
# @CODE
+# @ECLASS-VARIABLE: PYTHON_SINGLE_USEDEP
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# An eclass-generated USE-dependency string for the currently tested
+# implementation. It is set locally for python_check_deps() call.
+#
+# The generated USE-flag list is compatible with packages using
+# python-single-r1 eclass. For python-r1 dependencies,
+# use PYTHON_USEDEP.
+#
+# Example use:
+# @CODE
+# python_check_deps() {
+# has_version "dev-python/bar[${PYTHON_SINGLE_USEDEP}]"
+# }
+# @CODE
+#
+# Example value:
+# @CODE
+# python_single_target_python3_7(-)
+# @CODE
+
_python_any_set_globals() {
local usestr deps i PYTHON_PKG_DEP
[[ ${PYTHON_REQ_USE} ]] && usestr="[${PYTHON_REQ_USE}]"
@@ -189,7 +213,8 @@ if [[ ! ${_PYTHON_ANY_R1} ]]; then
# Generate an any-of dependency that enforces a version match between
# the Python interpreter and Python packages. needs
# to list one or more dependencies with verbatim '${PYTHON_USEDEP}'
-# references (quoted!) that will get expanded inside the function.
+# or '${PYTHON_SINGLE_USEDEP}' references (quoted!) that will get
+# expanded inside the function.
#
# This should be used along with an appropriate python_check_deps()
# that checks which of the any-of blocks were matched.
@@ -197,12 +222,12 @@ if [[ ! ${_PYTHON_ANY_R1} ]]; then
# Example use:
# @CODE
# DEPEND="$(python_gen_any_dep '
-# dev-python/foo[${PYTHON_USEDEP}]
+# dev-python/foo[${PYTHON_SINGLE_USEDEP}]
# || ( dev-python/bar[${PYTHON_USEDEP}]
# dev-python/baz[${PYTHON_USEDEP}] )')"
#
# python_check_deps() {
-# has_version "dev-python/foo[${PYTHON_USEDEP}]" \
+# has_version "dev-python/foo[${PYTHON_SINGLE_USEDEP}]" \
# && { has_version "dev-python/bar[${PYTHON_USEDEP}]" \
# || has_version "dev-python/baz[${PYTHON_USEDEP}]"; }
# }
@@ -213,13 +238,13 @@ if [[ ! ${_PYTHON_ANY_R1} ]]; then
# || (
# (
# dev-lang/python:3.7
-#
dev-python/foo[python_targets_python3_7(-),-python_single_target_python3_7(-)]
+# dev-python/foo[python_single_target_python3_7(-)]
# || (
dev-python/bar[python_targets_python3_7(-),-python_single_target_python3_7(-)]
#
dev-python/baz[python_targets_python3_7(-),-python_single_target_python3_7(-)] )
# )
# (
# dev-lang/python:3.8
-#
dev-python/foo[python_targets_python3_8(-),-python_single_target_python3_8(-)]
+# dev-python/foo[python_single_target_python3_8(-)]
# || (
dev-python/bar[python_targets_python3_8(-),-python_single_target_python3_8(-)]
#
dev-python/baz[python_targets_python3_8(-),-python_single_target_python3_8(-)] )
# )
@@ -234,9 +259,11 @@ python_gen_any_dep() {
local i PYTHON_PKG_DEP out=
for i in "${_PYTHON_SUPPORTED_IMPLS[@]}"; do
local
PYTHON_USEDEP="python_targets_${i}(-),-python_single_target_${i}(-)"
+ local PYTHON_SINGLE_USEDEP="python_single_target_${i}(-)"
_python_export "${i}" PYTHON_PKG_DEP
local i_depstr=${depstr//\$\{PYTHON_USEDEP\}/${PYTHON_USEDEP
[gentoo-dev] [PATCH 2/4] python-r1.eclass: Update PYTHON_USEDEP in python_gen_any_dep()
Signed-off-by: Michał Górny
---
eclass/python-r1.eclass | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index 40944684ec8b..e7a660219c17 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -547,16 +547,16 @@ python_gen_impl_dep() {
# @CODE
# || (
# (
-# dev-lang/python:2.7
-#
dev-python/foo[python_targets_python2_7(-)?,python_single_target_python2_7(+)?]
-# || (
dev-python/bar[python_targets_python2_7(-)?,python_single_target_python2_7(+)?]
-#
dev-python/baz[python_targets_python2_7(-)?,python_single_target_python2_7(+)?]
)
+# dev-lang/python:3.7
+#
dev-python/foo[python_targets_python3_7(-),-python_single_target_python3_7(-)]
+# || (
dev-python/bar[python_targets_python3_7(-),-python_single_target_python3_7(-)]
+#
dev-python/baz[python_targets_python3_7(-),-python_single_target_python3_7(-)] )
# )
# (
-# dev-lang/python:3.3
-#
dev-python/foo[python_targets_python3_3(-)?,python_single_target_python3_3(+)?]
-# || (
dev-python/bar[python_targets_python3_3(-)?,python_single_target_python3_3(+)?]
-#
dev-python/baz[python_targets_python3_3(-)?,python_single_target_python3_3(+)?]
)
+# dev-lang/python:3.8
+#
dev-python/foo[python_targets_python3_8(-),-python_single_target_python3_8(-)]
+# || (
dev-python/bar[python_targets_python3_8(-),-python_single_target_python3_8(-)]
+#
dev-python/baz[python_targets_python3_8(-),-python_single_target_python3_8(-)] )
# )
# )
# @CODE
@@ -571,7 +571,7 @@ python_gen_any_dep() {
_python_verify_patterns "${@}"
for i in "${_PYTHON_SUPPORTED_IMPLS[@]}"; do
if _python_impl_matches "${i}" "${@}"; then
- local
PYTHON_USEDEP="python_targets_${i}(-),python_single_target_${i}(+)"
+ local
PYTHON_USEDEP="python_targets_${i}(-),-python_single_target_${i}(-)"
_python_export "${i}" PYTHON_PKG_DEP
local
i_depstr=${depstr//\$\{PYTHON_USEDEP\}/${PYTHON_USEDEP}}
@@ -779,7 +779,7 @@ python_setup() {
# first check if the interpreter is installed
python_is_installed "${impl}" || continue
# then run python_check_deps
- local
PYTHON_USEDEP="python_targets_${impl}(-),python_single_target_${impl}(+)"
+ local
PYTHON_USEDEP="python_targets_${impl}(-),-python_single_target_${impl}(-)"
python_check_deps || continue
fi
--
2.29.2
[gentoo-dev] [PATCH 1/4] python-any-r1.eclass: Update PYTHON_USEDEP to match python-r1
Signed-off-by: Michał Górny
---
eclass/python-any-r1.eclass | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index c634e19813e0..9fd7fd6bc27d 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -131,20 +131,19 @@ EXPORT_FUNCTIONS pkg_setup
# An eclass-generated USE-dependency string for the currently tested
# implementation. It is set locally for python_check_deps() call.
#
-# The generate USE-flag list is compatible with packages using python-r1,
-# python-single-r1 and python-distutils-ng eclasses. It must not be used
-# on packages using python.eclass.
+# The generate USE-flag list is compatible with packages using python-r1
+# eclass. It must not be used on packages using other eclasses.
#
# Example use:
# @CODE
# python_check_deps() {
-# has_version "dev-python/foo[${PYTHON_USEDEP}]"
+# has_version "dev-python/foo[${PYTHON_USEDEP}]"
# }
# @CODE
#
# Example value:
# @CODE
-# python_targets_python2_7(-)?,python_single_target_python2_7(+)?
+# python_targets_python3_7(-),-python_single_target_python3_7(-)
# @CODE
_python_any_set_globals() {
@@ -213,16 +212,16 @@ if [[ ! ${_PYTHON_ANY_R1} ]]; then
# @CODE
# || (
# (
-# dev-lang/python:2.7
-#
dev-python/foo[python_targets_python2_7(-)?,python_single_target_python2_7(+)?]
-# || (
dev-python/bar[python_targets_python2_7(-)?,python_single_target_python2_7(+)?]
-#
dev-python/baz[python_targets_python2_7(-)?,python_single_target_python2_7(+)?]
)
+# dev-lang/python:3.7
+#
dev-python/foo[python_targets_python3_7(-),-python_single_target_python3_7(-)]
+# || (
dev-python/bar[python_targets_python3_7(-),-python_single_target_python3_7(-)]
+#
dev-python/baz[python_targets_python3_7(-),-python_single_target_python3_7(-)] )
# )
# (
-# dev-lang/python:3.3
-#
dev-python/foo[python_targets_python3_3(-)?,python_single_target_python3_3(+)?]
-# || (
dev-python/bar[python_targets_python3_3(-)?,python_single_target_python3_3(+)?]
-#
dev-python/baz[python_targets_python3_3(-)?,python_single_target_python3_3(+)?]
)
+# dev-lang/python:3.8
+#
dev-python/foo[python_targets_python3_8(-),-python_single_target_python3_8(-)]
+# || (
dev-python/bar[python_targets_python3_8(-),-python_single_target_python3_8(-)]
+#
dev-python/baz[python_targets_python3_8(-),-python_single_target_python3_8(-)] )
# )
# )
# @CODE
@@ -234,7 +233,7 @@ python_gen_any_dep() {
local i PYTHON_PKG_DEP out=
for i in "${_PYTHON_SUPPORTED_IMPLS[@]}"; do
- local
PYTHON_USEDEP="python_targets_${i}(-),python_single_target_${i}(+)"
+ local
PYTHON_USEDEP="python_targets_${i}(-),-python_single_target_${i}(-)"
_python_export "${i}" PYTHON_PKG_DEP
local i_depstr=${depstr//\$\{PYTHON_USEDEP\}/${PYTHON_USEDEP}}
@@ -268,7 +267,7 @@ _python_EPYTHON_supported() {
if has "${i}" "${_PYTHON_SUPPORTED_IMPLS[@]}"; then
if python_is_installed "${i}"; then
if declare -f python_check_deps >/dev/null; then
- local
PYTHON_USEDEP="python_targets_${i}(-),python_single_target_${i}(+)"
+ local
PYTHON_USEDEP="python_targets_${i}(-),-python_single_target_${i}(-)"
python_check_deps
return ${?}
fi
--
2.29.2
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Thu, 2020-12-17 at 16:08 -0500, Mike Gilbert wrote: > On Thu, Dec 17, 2020 at 3:50 PM Mike Gilbert > wrote: > > > > On Thu, Dec 17, 2020 at 3:38 PM William Hubbs > > wrote: > > > > > > On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > > > > On Sat, Dec 12, 2020 at 9:09 PM William Hubbs > > > > wrote: > > > > > > > > > > On Sat, Dec 12, 2020 at 04:25:48PM -0500, Mike Gilbert wrote: > > > > > > On Sat, Dec 12, 2020 at 3:48 PM William Hubbs > > > > > > wrote: > > > > > > > If both /usr/bin/python and /usr/bin/python3 are going > > > > > > > away, the best > > > > > > > choice would be to add functionality to python-exec or > > > > > > > eselect python to tell us > > > > > > > the path to the default python interpretor. Once we know > > > > > > > that we call it > > > > > > > directly. > > > > > > > > > > > > I don't think they are "going away". There is a USE flag on > > > > > > dev-lang/python-exec that makes them optional, and I think > > > > > > it will be > > > > > > forcibly enabled for the foreseeable future. > > > > > > > > > > > > > Please do not apply this patch to meson; I think we can > > > > > > > figure something > > > > > > > out that is better. > > > > > > > > > > > > I think installing a small script to help translate > > > > > > arguments from one > > > > > > format to another is a reasonable solution. > > > > > > > > > > I think we should look at the eclass to see if we can > > > > > provide functions > > > > > that can be used by consumers to handle this. > > > > > > > > I don't really understand what you mean by this. I am > > > > converting one > > > > internal bash function into an external script so that its > > > > python > > > > dependencies can be better defined and managed. > > > > > > What I mean is, ebuilds should not be calling _meson_env_array at > > > all > > > since it is defined and documented as an eclass internal > > > function. > > > > > > I would like to know more about what the gallium-nine-standalone > > > ebuild > > > is doing and why it needs to call a meson.eclass internal > > > function. > > > > > > On the other hand, if _meson_env_array is meant to be called by > > > ebuilds, > > > we need to rename it and improve the documentation for it in the > > > eclass. > > > > I do not really care about gallium-nine-standalone and its abuse of > > the private _meson_env_array function. That's an issue that should > > be > > separate from the change I am proposing. I am only touching the > > ebuild > > because my patch removes the _meson_env_array function and I want > > to > > avoid breaking the ebuild. > > > > > > > Also, I don't think your script will run if native-symlinks > > > > > is disabled since in > > > > > that setting /usr/bin/python would not exist. > > > > > > > > python_doscript updates the shebang before installing the > > > > script. > > > > > > Ok, I didn't know python_doscript does this, but couldn't we > > > just > > > change line 129 in the eclass to "python3 -c ..."? > > > > No, that will not help in any way. > > > > > > > I question the value of the native-symlinks use flag on > > > > > python-exec > > > > > unless there is a way to query the path of the default python > > > > > interpretor. > > > > > > > > Regardless, I don't see how that makes my solution a bad thing. > > > > It > > > > ensures that the code will be executed by a > > > > known/support/tested > > > > version of python. > > > > > > > > > > I'm not sure how useful the script is as a command, so I don't > > > think it > > > should be installed that way, but I do want to hear more about > > > this, > > > both from you and chewi. :-) > > > > I don't see any reasonable way to make it work otherwise. If you > > have > > no better suggestion, please refrain from further comments. > > I gave it a little more thought, and I suppose we could use "eselect > python show" to get a valid python interpreter. I'll put together a > patch for that. > Do you want all meson packages to depend on eselect-python? -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Thu, 17 Dec 2020 14:38:43 -0600 William Hubbs wrote: > On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > > I don't really understand what you mean by this. I am converting one > > internal bash function into an external script so that its python > > dependencies can be better defined and managed. > > What I mean is, ebuilds should not be calling _meson_env_array at all > since it is defined and documented as an eclass internal function. > > I would like to know more about what the gallium-nine-standalone ebuild > is doing and why it needs to call a meson.eclass internal function. > > On the other hand, if _meson_env_array is meant to be called by ebuilds, > we need to rename it and improve the documentation for it in the eclass. I knew I spoke to someone about this on IRC and turns out it was you 2 years ago. :P The ebuild needs to render flags as a Meson array and this eclass function is the best way to do it. You did not know why it was private and said to go ahead anyway but file a bug so that this situation could be improved. I admittedly didn't get around to filing a bug but I was totally prepared to deal with the fall out if it broke. Now floppym is improving the situation anyway and fixing the ebuild too. I give my thanks to him. Job done? -- James Le Cuirot (chewi) Gentoo Linux Developer pgpPbvZE71UX_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Thu, Dec 17, 2020 at 3:50 PM Mike Gilbert wrote: > > On Thu, Dec 17, 2020 at 3:38 PM William Hubbs wrote: > > > > On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > > > On Sat, Dec 12, 2020 at 9:09 PM William Hubbs wrote: > > > > > > > > On Sat, Dec 12, 2020 at 04:25:48PM -0500, Mike Gilbert wrote: > > > > > On Sat, Dec 12, 2020 at 3:48 PM William Hubbs > > > > > wrote: > > > > > > If both /usr/bin/python and /usr/bin/python3 are going away, the > > > > > > best > > > > > > choice would be to add functionality to python-exec or eselect > > > > > > python to tell us > > > > > > the path to the default python interpretor. Once we know that we > > > > > > call it > > > > > > directly. > > > > > > > > > > I don't think they are "going away". There is a USE flag on > > > > > dev-lang/python-exec that makes them optional, and I think it will be > > > > > forcibly enabled for the foreseeable future. > > > > > > > > > > > Please do not apply this patch to meson; I think we can figure > > > > > > something > > > > > > out that is better. > > > > > > > > > > I think installing a small script to help translate arguments from one > > > > > format to another is a reasonable solution. > > > > > > > > I think we should look at the eclass to see if we can provide functions > > > > that can be used by consumers to handle this. > > > > > > I don't really understand what you mean by this. I am converting one > > > internal bash function into an external script so that its python > > > dependencies can be better defined and managed. > > > > What I mean is, ebuilds should not be calling _meson_env_array at all > > since it is defined and documented as an eclass internal function. > > > > I would like to know more about what the gallium-nine-standalone ebuild > > is doing and why it needs to call a meson.eclass internal function. > > > > On the other hand, if _meson_env_array is meant to be called by ebuilds, > > we need to rename it and improve the documentation for it in the eclass. > > I do not really care about gallium-nine-standalone and its abuse of > the private _meson_env_array function. That's an issue that should be > separate from the change I am proposing. I am only touching the ebuild > because my patch removes the _meson_env_array function and I want to > avoid breaking the ebuild. > > > > > Also, I don't think your script will run if native-symlinks is disabled > > > > since in > > > > that setting /usr/bin/python would not exist. > > > > > > python_doscript updates the shebang before installing the script. > > > > Ok, I didn't know python_doscript does this, but couldn't we just > > change line 129 in the eclass to "python3 -c ..."? > > No, that will not help in any way. > > > > > I question the value of the native-symlinks use flag on python-exec > > > > unless there is a way to query the path of the default python > > > > interpretor. > > > > > > Regardless, I don't see how that makes my solution a bad thing. It > > > ensures that the code will be executed by a known/support/tested > > > version of python. > > > > > > > I'm not sure how useful the script is as a command, so I don't think it > > should be installed that way, but I do want to hear more about this, > > both from you and chewi. :-) > > I don't see any reasonable way to make it work otherwise. If you have > no better suggestion, please refrain from further comments. I gave it a little more thought, and I suppose we could use "eselect python show" to get a valid python interpreter. I'll put together a patch for that.
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Thu, Dec 17, 2020 at 3:38 PM William Hubbs wrote: > > On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > > On Sat, Dec 12, 2020 at 9:09 PM William Hubbs wrote: > > > > > > On Sat, Dec 12, 2020 at 04:25:48PM -0500, Mike Gilbert wrote: > > > > On Sat, Dec 12, 2020 at 3:48 PM William Hubbs > > > > wrote: > > > > > If both /usr/bin/python and /usr/bin/python3 are going away, the best > > > > > choice would be to add functionality to python-exec or eselect python > > > > > to tell us > > > > > the path to the default python interpretor. Once we know that we call > > > > > it > > > > > directly. > > > > > > > > I don't think they are "going away". There is a USE flag on > > > > dev-lang/python-exec that makes them optional, and I think it will be > > > > forcibly enabled for the foreseeable future. > > > > > > > > > Please do not apply this patch to meson; I think we can figure > > > > > something > > > > > out that is better. > > > > > > > > I think installing a small script to help translate arguments from one > > > > format to another is a reasonable solution. > > > > > > I think we should look at the eclass to see if we can provide functions > > > that can be used by consumers to handle this. > > > > I don't really understand what you mean by this. I am converting one > > internal bash function into an external script so that its python > > dependencies can be better defined and managed. > > What I mean is, ebuilds should not be calling _meson_env_array at all > since it is defined and documented as an eclass internal function. > > I would like to know more about what the gallium-nine-standalone ebuild > is doing and why it needs to call a meson.eclass internal function. > > On the other hand, if _meson_env_array is meant to be called by ebuilds, > we need to rename it and improve the documentation for it in the eclass. I do not really care about gallium-nine-standalone and its abuse of the private _meson_env_array function. That's an issue that should be separate from the change I am proposing. I am only touching the ebuild because my patch removes the _meson_env_array function and I want to avoid breaking the ebuild. > > > Also, I don't think your script will run if native-symlinks is disabled > > > since in > > > that setting /usr/bin/python would not exist. > > > > python_doscript updates the shebang before installing the script. > > Ok, I didn't know python_doscript does this, but couldn't we just > change line 129 in the eclass to "python3 -c ..."? No, that will not help in any way. > > > I question the value of the native-symlinks use flag on python-exec > > > unless there is a way to query the path of the default python > > > interpretor. > > > > Regardless, I don't see how that makes my solution a bad thing. It > > ensures that the code will be executed by a known/support/tested > > version of python. > > > > I'm not sure how useful the script is as a command, so I don't think it > should be installed that way, but I do want to hear more about this, > both from you and chewi. :-) I don't see any reasonable way to make it work otherwise. If you have no better suggestion, please refrain from further comments.
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > On Sat, Dec 12, 2020 at 9:09 PM William Hubbs wrote: > > > > On Sat, Dec 12, 2020 at 04:25:48PM -0500, Mike Gilbert wrote: > > > On Sat, Dec 12, 2020 at 3:48 PM William Hubbs wrote: > > > > If both /usr/bin/python and /usr/bin/python3 are going away, the best > > > > choice would be to add functionality to python-exec or eselect python > > > > to tell us > > > > the path to the default python interpretor. Once we know that we call it > > > > directly. > > > > > > I don't think they are "going away". There is a USE flag on > > > dev-lang/python-exec that makes them optional, and I think it will be > > > forcibly enabled for the foreseeable future. > > > > > > > Please do not apply this patch to meson; I think we can figure something > > > > out that is better. > > > > > > I think installing a small script to help translate arguments from one > > > format to another is a reasonable solution. > > > > I think we should look at the eclass to see if we can provide functions > > that can be used by consumers to handle this. > > I don't really understand what you mean by this. I am converting one > internal bash function into an external script so that its python > dependencies can be better defined and managed. What I mean is, ebuilds should not be calling _meson_env_array at all since it is defined and documented as an eclass internal function. I would like to know more about what the gallium-nine-standalone ebuild is doing and why it needs to call a meson.eclass internal function. On the other hand, if _meson_env_array is meant to be called by ebuilds, we need to rename it and improve the documentation for it in the eclass. > > Also, I don't think your script will run if native-symlinks is disabled > > since in > > that setting /usr/bin/python would not exist. > > python_doscript updates the shebang before installing the script. Ok, I didn't know python_doscript does this, but couldn't we just change line 129 in the eclass to "python3 -c ..."? > > I question the value of the native-symlinks use flag on python-exec > > unless there is a way to query the path of the default python > > interpretor. > > Regardless, I don't see how that makes my solution a bad thing. It > ensures that the code will be executed by a known/support/tested > version of python. > I'm not sure how useful the script is as a command, so I don't think it should be installed that way, but I do want to hear more about this, both from you and chewi. :-) William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, 2020-12-17 at 15:15 -0500, Mike Gilbert wrote: > On Thu, Dec 17, 2020 at 3:03 PM Aaron W. Swenson > wrote: > > > > On Thu, Dec 17, 2020 at 01:12:16PM -0500, Mike Gilbert wrote: > > > Signed-off-by: Mike Gilbert > > > --- > > > > > > v2: Added "This upload is required in addition to uploading the > > > SKS pool." > > > > > > glep-0063.rst | 24 > > > 1 file changed, 20 insertions(+), 4 deletions(-) > > > > > > diff --git a/glep-0063.rst b/glep-0063.rst > > > index 82541bd..ec465db 100644 > > > --- a/glep-0063.rst > > > +++ b/glep-0063.rst > > > @@ -7,10 +7,10 @@ Author: Robin H. Johnson , > > > Michał Górny > > > Type: Standards Track > > > Status: Final > > > -Version: 2.1 > > > +Version: 2.2 > > > Created: 2013-02-18 > > > -Last-Modified: 2019-11-07 > > > -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 > > > +Last-Modified: 2020-12-17 > > > +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, > > > 2020-12-17 > > > Content-Type: text/x-rst > > > --- > > > > > > @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo > > > Linux distribution. > > > Changes > > > === > > > > > > +v2.2 > > > + Added "Gentoo Keyserver" section under "Gentoo Infrastructure" > > > chapter. > > > + > > > v2.1 > > > A requirement for an encryption key has been added, in order to > > > extend > > > the GLEP beyond commit signing and into use of OpenPGP for dev- > > > to-dev > > > @@ -135,8 +138,11 @@ their primary key). > > > > > > 5. Encrypted backup of your secret keys. > > > > > > +Gentoo Infrstructure > > > + > > > + > > > Gentoo LDAP > > > -=== > > > +--- > > > > > > All Gentoo developers must list the complete fingerprint for > > > their primary > > > keys in the "``gpgfingerprint``" LDAP field. It must be exactly > > > 40 hex digits, > > > @@ -147,6 +153,16 @@ of the fingerprint field. In any place that > > > presently displays > > > the "``gpgkey``" field, the last 16 hex digits of the fingerprint > > > should > > > be displayed instead. > > > > > > +Gentoo Keyserver > > > + > > > + > > > +Gentoo infrastructure uses a keyserver that is isolated from the > > > SKS pool. > > > +This keyserver is restricted to accepting uploads from > > > authorized Gentoo hosts. > > > +A script is provided on dev.gentoo.org to allow developers to > > > upload their > > > +keys. This upload is required in addition to uploading to the > > > SKS pool. > > > + > > > +``gpg --export KEYID | ssh dev.gentoo.org > > > /usr/local/bin/openpgp-key-upload`` > > > + > > > Backwards Compatibility > > > === > > > > > > -- > > > 2.30.0.rc0 > > > > > > > > > > Thanks for doing this! You beat me to the punch. I was going to try > > getting to > > it tomorrow. > > > > It may be good to also change step 7 under "Bare minimum > > requirements" to read: > > > > 7. Upload your key to the Gentoo Keyserver before usage! > > > > It'd give skimmers a trigger to look for the Gentoo keyserver info. > > Sure, happy to make that change. > > > We might want to add "Upload to the SKS or some other public PGP > > pool" under > > "Recommendations", but that's probably beyond the scope of the > > document now. > > I think it makes sense to move the SKS instruction to the > recommendations section. > > > Lastly, should we have a link to the step-by-step guide? [1] > > > > [1]: > > https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys > > I'm not sure I like the idea of referring the user to a wiki article > in the GLEP. What do others think of this? > > If others agree, please propose some language/location to insert it, > or send a patch of your own (feel free to use my patch as a starting > point). > I think we should actually have some dedicated info page purely for Infra keyserver. Possibly by replacing the index of https://keys.gentoo.org. Infra will look into it. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 3:03 PM Aaron W. Swenson wrote: > > On Thu, Dec 17, 2020 at 01:12:16PM -0500, Mike Gilbert wrote: > >Signed-off-by: Mike Gilbert > >--- > > > >v2: Added "This upload is required in addition to uploading the SKS pool." > > > > glep-0063.rst | 24 > > 1 file changed, 20 insertions(+), 4 deletions(-) > > > >diff --git a/glep-0063.rst b/glep-0063.rst > >index 82541bd..ec465db 100644 > >--- a/glep-0063.rst > >+++ b/glep-0063.rst > >@@ -7,10 +7,10 @@ Author: Robin H. Johnson , > > Michał Górny > > Type: Standards Track > > Status: Final > >-Version: 2.1 > >+Version: 2.2 > > Created: 2013-02-18 > >-Last-Modified: 2019-11-07 > >-Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 > >+Last-Modified: 2020-12-17 > >+Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17 > > Content-Type: text/x-rst > > --- > > > >@@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux > >distribution. > > Changes > > === > > > >+v2.2 > >+ Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter. > >+ > > v2.1 > > A requirement for an encryption key has been added, in order to extend > > the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev > >@@ -135,8 +138,11 @@ their primary key). > > > > 5. Encrypted backup of your secret keys. > > > >+Gentoo Infrstructure > >+ > >+ > > Gentoo LDAP > >-=== > >+--- > > > > All Gentoo developers must list the complete fingerprint for their primary > > keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex > > digits, > >@@ -147,6 +153,16 @@ of the fingerprint field. In any place that presently > >displays > > the "``gpgkey``" field, the last 16 hex digits of the fingerprint should > > be displayed instead. > > > >+Gentoo Keyserver > >+ > >+ > >+Gentoo infrastructure uses a keyserver that is isolated from the SKS pool. > >+This keyserver is restricted to accepting uploads from authorized Gentoo > >hosts. > >+A script is provided on dev.gentoo.org to allow developers to upload their > >+keys. This upload is required in addition to uploading to the SKS pool. > >+ > >+``gpg --export KEYID | ssh dev.gentoo.org > >/usr/local/bin/openpgp-key-upload`` > >+ > > Backwards Compatibility > > === > > > >-- > >2.30.0.rc0 > > > > > > Thanks for doing this! You beat me to the punch. I was going to try getting to > it tomorrow. > > It may be good to also change step 7 under "Bare minimum requirements" to > read: > > 7. Upload your key to the Gentoo Keyserver before usage! > > It'd give skimmers a trigger to look for the Gentoo keyserver info. Sure, happy to make that change. > We might want to add "Upload to the SKS or some other public PGP pool" under > "Recommendations", but that's probably beyond the scope of the document now. I think it makes sense to move the SKS instruction to the recommendations section. > Lastly, should we have a link to the step-by-step guide? [1] > > [1]: > https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys I'm not sure I like the idea of referring the user to a wiki article in the GLEP. What do others think of this? If others agree, please propose some language/location to insert it, or send a patch of your own (feel free to use my patch as a starting point).
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 01:12:16PM -0500, Mike Gilbert wrote: Signed-off-by: Mike Gilbert --- v2: Added "This upload is required in addition to uploading the SKS pool." glep-0063.rst | 24 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 82541bd..ec465db 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -7,10 +7,10 @@ Author: Robin H. Johnson , Michał Górny Type: Standards Track Status: Final -Version: 2.1 +Version: 2.2 Created: 2013-02-18 -Last-Modified: 2019-11-07 -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 +Last-Modified: 2020-12-17 +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17 Content-Type: text/x-rst --- @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux distribution. Changes === +v2.2 + Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter. + v2.1 A requirement for an encryption key has been added, in order to extend the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev @@ -135,8 +138,11 @@ their primary key). 5. Encrypted backup of your secret keys. +Gentoo Infrstructure + + Gentoo LDAP -=== +--- All Gentoo developers must list the complete fingerprint for their primary keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits, @@ -147,6 +153,16 @@ of the fingerprint field. In any place that presently displays the "``gpgkey``" field, the last 16 hex digits of the fingerprint should be displayed instead. +Gentoo Keyserver + + +Gentoo infrastructure uses a keyserver that is isolated from the SKS pool. +This keyserver is restricted to accepting uploads from authorized Gentoo hosts. +A script is provided on dev.gentoo.org to allow developers to upload their +keys. This upload is required in addition to uploading to the SKS pool. + +``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload`` + Backwards Compatibility === -- 2.30.0.rc0 Thanks for doing this! You beat me to the punch. I was going to try getting to it tomorrow. It may be good to also change step 7 under "Bare minimum requirements" to read: 7. Upload your key to the Gentoo Keyserver before usage! It'd give skimmers a trigger to look for the Gentoo keyserver info. We might want to add "Upload to the SKS or some other public PGP pool" under "Recommendations", but that's probably beyond the scope of the document now. Lastly, should we have a link to the step-by-step guide? [1] [1]: https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 08:27:44PM +0100, Michał Górny wrote: > Thank you for doing this. > > That said, I'm wondering if we should keep SKS pool at all. Did anyone > have any success interacting with it lately? All my attempts of > fetching keys are resulting in server errors. Yes, it worked for me 2 weeks ago when I fetched some keys from a local SKS node to correspond with an upstream developer about a potential security issue recently. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
[gentoo-dev] x11-wm/sawfish needs a maintainer
Package did not have a dedicated maintainer since at least git migration. Bugs are mounting and I will last-rite it mercilessly should it block cleanup of a certain dependency (bug filed). Regards signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 1:44 PM Davide Pesavento wrote: > > On Thu, Dec 17, 2020 at 1:12 PM Mike Gilbert wrote: > > > > Signed-off-by: Mike Gilbert > > --- > > > > v2: Added "This upload is required in addition to uploading the SKS pool." > > > > glep-0063.rst | 24 > > 1 file changed, 20 insertions(+), 4 deletions(-) > > > > diff --git a/glep-0063.rst b/glep-0063.rst > > index 82541bd..ec465db 100644 > > --- a/glep-0063.rst > > +++ b/glep-0063.rst > > @@ -7,10 +7,10 @@ Author: Robin H. Johnson , > > Michał Górny > > Type: Standards Track > > Status: Final > > -Version: 2.1 > > +Version: 2.2 > > Created: 2013-02-18 > > -Last-Modified: 2019-11-07 > > -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 > > +Last-Modified: 2020-12-17 > > +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17 > > Content-Type: text/x-rst > > --- > > > > @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux > > distribution. > > Changes > > === > > > > +v2.2 > > + Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter. > > + > > v2.1 > >A requirement for an encryption key has been added, in order to extend > >the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev > > @@ -135,8 +138,11 @@ their primary key). > > > > 5. Encrypted backup of your secret keys. > > > > +Gentoo Infrstructure > > Typo. Thanks, fixed locally.
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, 2020-12-17 at 13:12 -0500, Mike Gilbert wrote: > Signed-off-by: Mike Gilbert > --- > > v2: Added "This upload is required in addition to uploading the SKS > pool." > > glep-0063.rst | 24 > 1 file changed, 20 insertions(+), 4 deletions(-) > > diff --git a/glep-0063.rst b/glep-0063.rst > index 82541bd..ec465db 100644 > --- a/glep-0063.rst > +++ b/glep-0063.rst > @@ -7,10 +7,10 @@ Author: Robin H. Johnson , > Michał Górny > Type: Standards Track > Status: Final > -Version: 2.1 > +Version: 2.2 > Created: 2013-02-18 > -Last-Modified: 2019-11-07 > -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 > +Last-Modified: 2020-12-17 > +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020- > 12-17 > Content-Type: text/x-rst > --- > > @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo > Linux distribution. > Changes > === > > +v2.2 > + Added "Gentoo Keyserver" section under "Gentoo Infrastructure" > chapter. > + > v2.1 > A requirement for an encryption key has been added, in order to > extend > the GLEP beyond commit signing and into use of OpenPGP for dev-to- > dev > @@ -135,8 +138,11 @@ their primary key). > > 5. Encrypted backup of your secret keys. > > +Gentoo Infrstructure T > + > + > Gentoo LDAP > -=== > +--- > > All Gentoo developers must list the complete fingerprint for their > primary > keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 > hex digits, > @@ -147,6 +153,16 @@ of the fingerprint field. In any place that > presently displays > the "``gpgkey``" field, the last 16 hex digits of the fingerprint > should > be displayed instead. > > +Gentoo Keyserver > + > + > +Gentoo infrastructure uses a keyserver that is isolated from the SKS > pool. > +This keyserver is restricted to accepting uploads from authorized > Gentoo hosts. > +A script is provided on dev.gentoo.org to allow developers to upload > their > +keys. This upload is required in addition to uploading to the SKS > pool. > + > +``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp- > key-upload`` > + > Backwards Compatibility > === Thank you for doing this. That said, I'm wondering if we should keep SKS pool at all. Did anyone have any success interacting with it lately? All my attempts of fetching keys are resulting in server errors. -- Best regards, Michał Górny
Re: [gentoo-dev] GPG key refresh
On Thu, 2020-12-17 at 13:28 -0500, Mike Gilbert wrote: > On Wed, Dec 16, 2020 at 11:48 PM desultory > wrote: > > > > On 12/16/20 03:01, Michał Górny wrote: > > > On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote: > > > > On 2020-12-15 11:16, Michael Orlitzky wrote: > > > > > On 12/15/20 11:11 AM, Thomas Deutschmann wrote: > > > > > > > > > > > > What do you mean exactly? > > > > > > > > > > > > For Gentoo tooling, only Gentoo keyservers are important > > > > > > and > > > > > > Gentoo no longer synchronizes with any other pool. > > > > > > > > > > > "The Gentoo developer tooling explicitly checks the Gentoo > > > > > keyserver > > > > > pool with a much higher frequency" strongly implies that we > > > > > check > > > > > the > > > > > non-Gentoo pools with a non-zero frequency. > > > > > > > > > > > > > > > > > > I'm with Michael on this. I've recently experienced this issue > > > > myself > > > > as the > > > > instruction to upload the key to the Gentoo keyserver is > > > > separate > > > > from the > > > > GLEP63[1] document. It doesn't matter that the step is > > > > documented if > > > > the Holy > > > > Tome GLEP63 doesn't mention it. What hint would I have to look > > > > for a > > > > supplemental document to provide that specific step? > > > > > > > > According to GLEP 63, uploading to the SKS keyserver is a > > > > requirement. > > > > However, it fails to specify which SKS keyserver. In fact, > > > > neither > > > > "SKS" nor > > > > "keyserver" are defined in GLEP63. Ergo, the natural > > > > interpretation > > > > is *anything* > > > > that's called an SKS keyserver will satisfy the requirement. As > > > > long > > > > as the > > > > developer can submit the key, the requirement is met. > > > > > > > > Additionally, the supplemental document[2] doesn't say > > > > developers > > > > must upload > > > > via an internal host, but that devs should upload to both SKS > > > > and the > > > > Gentoo > > > > keyserver. Yes, it says the Gentoo keyserver is currently > > > > restricted > > > > to syncing > > > > with "authorized Gentoo hosts", but that's a nonsense phrase > > > > and > > > > unhelpful. It > > > > assumes I know what the authorized Gentoo hosts are. It doesn't > > > > clearly state > > > > what they are. It kind of hints that it will pull from SKS > > > > eventually, but it > > > > could take a long time. > > > > > > > > I understand we temporarily stopped syncing with the public > > > > keyserver > > > > out of an > > > > overabundance of caution. However, that shouldn't have been > > > > done > > > > without > > > > updating every official Gentoo resource regarding how devs > > > > should > > > > handle their > > > > keys, which as far as I know is only two documents[1,2]. A > > > > whopping 2 > > > > documents. > > > > > > > > This new (I know it's been around for a year but that doesn't > > > > make it > > > > any less > > > > new), stricter requirement, should be **explicitly** stated in > > > > GLEP63, properly > > > > referencing the justification[3], and linking to the infra > > > > supplemental > > > > document. The infra supplemental document needs to then use the > > > > phrase "must" in > > > > place of "should" when informing readers to upload to two > > > > different > > > > locations. > > > > > > ...and what have you done to resolve the problem, except for > > > making > > > oververbose complaints and demands in middle of some random > > > thread? > > > > > Discuss it, which is more than you have done here. There is no need > > to > > berate signal because you feel like making noise. > > > > Formulating and discussing ways to fix problems before actually > > fixing > > them helps to reduce effort wasted on rebuilding old solutions > > which > > have failed for whatever reason. In this case documentation needs > > to be > > updated, discussing the appropriate manner in which to update which > > documentation seems to be more grounds for engagement than > > recrimination. > > > > On the subject of updating the documentation, the proposal seems > > generally sound; do you have any constructive criticism of it? > > > > So I can understand where Michał's reaction comes from. On my first > read through Aaron's message, it seemed like a long email complaining > about things that had been done wrong. Upon re-reading it with a > different mindset, it doesn't seem so bad if you skip over some of > the > text. To me, it sounded like 'I am so important that I can't be bothered to report it properly, so I just write a long complaint right here and expect someone to resolve it'. -- Best regards, Michał Górny
Re: [gentoo-dev] GPG key refresh
On Thu, 2020-12-17 at 13:35 -0500, Mike Gilbert wrote: > On Wed, Dec 16, 2020 at 3:01 AM Michał Górny > wrote: > > > > On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote: > > > On 2020-12-15 11:16, Michael Orlitzky wrote: > > > > On 12/15/20 11:11 AM, Thomas Deutschmann wrote: > > > > > > > > > > What do you mean exactly? > > > > > > > > > > For Gentoo tooling, only Gentoo keyservers are important and > > > > > Gentoo no longer synchronizes with any other pool. > > > > > > > > > "The Gentoo developer tooling explicitly checks the Gentoo > > > > keyserver > > > > pool with a much higher frequency" strongly implies that we > > > > check > > > > the > > > > non-Gentoo pools with a non-zero frequency. > > > > > > > > > > > > > > I'm with Michael on this. I've recently experienced this issue > > > myself > > > as the > > > instruction to upload the key to the Gentoo keyserver is separate > > > from the > > > GLEP63[1] document. It doesn't matter that the step is documented > > > if > > > the Holy > > > Tome GLEP63 doesn't mention it. What hint would I have to look > > > for a > > > supplemental document to provide that specific step? > > > > > > According to GLEP 63, uploading to the SKS keyserver is a > > > requirement. > > > However, it fails to specify which SKS keyserver. In fact, > > > neither > > > "SKS" nor > > > "keyserver" are defined in GLEP63. Ergo, the natural > > > interpretation > > > is *anything* > > > that's called an SKS keyserver will satisfy the requirement. As > > > long > > > as the > > > developer can submit the key, the requirement is met. > > > > > > Additionally, the supplemental document[2] doesn't say developers > > > must upload > > > via an internal host, but that devs should upload to both SKS and > > > the > > > Gentoo > > > keyserver. Yes, it says the Gentoo keyserver is currently > > > restricted > > > to syncing > > > with "authorized Gentoo hosts", but that's a nonsense phrase and > > > unhelpful. It > > > assumes I know what the authorized Gentoo hosts are. It doesn't > > > clearly state > > > what they are. It kind of hints that it will pull from SKS > > > eventually, but it > > > could take a long time. > > > > > > I understand we temporarily stopped syncing with the public > > > keyserver > > > out of an > > > overabundance of caution. However, that shouldn't have been done > > > without > > > updating every official Gentoo resource regarding how devs should > > > handle their > > > keys, which as far as I know is only two documents[1,2]. A > > > whopping 2 > > > documents. > > > > > > This new (I know it's been around for a year but that doesn't > > > make it > > > any less > > > new), stricter requirement, should be **explicitly** stated in > > > GLEP63, properly > > > referencing the justification[3], and linking to the infra > > > supplemental > > > document. The infra supplemental document needs to then use the > > > phrase "must" in > > > place of "should" when informing readers to upload to two > > > different > > > locations. > > > > ...and what have you done to resolve the problem, except for making > > oververbose complaints and demands in middle of some random thread? > > If you think he's being unhelpful, maybe suggest ways of contributing > that would be more helpful. There's no need for this snippy reply. > Are you suggesting that a developer with almost 10 years of experience in Gentoo doesn't know how to file a bug? The likeliness of me reading that particular mail in middle of the thread was really low. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 1:12 PM Mike Gilbert wrote: > > Signed-off-by: Mike Gilbert > --- > > v2: Added "This upload is required in addition to uploading the SKS pool." > > glep-0063.rst | 24 > 1 file changed, 20 insertions(+), 4 deletions(-) > > diff --git a/glep-0063.rst b/glep-0063.rst > index 82541bd..ec465db 100644 > --- a/glep-0063.rst > +++ b/glep-0063.rst > @@ -7,10 +7,10 @@ Author: Robin H. Johnson , > Michał Górny > Type: Standards Track > Status: Final > -Version: 2.1 > +Version: 2.2 > Created: 2013-02-18 > -Last-Modified: 2019-11-07 > -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 > +Last-Modified: 2020-12-17 > +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17 > Content-Type: text/x-rst > --- > > @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux > distribution. > Changes > === > > +v2.2 > + Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter. > + > v2.1 >A requirement for an encryption key has been added, in order to extend >the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev > @@ -135,8 +138,11 @@ their primary key). > > 5. Encrypted backup of your secret keys. > > +Gentoo Infrstructure Typo. > + > + > Gentoo LDAP > -=== > +--- > > All Gentoo developers must list the complete fingerprint for their primary > keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex > digits, > @@ -147,6 +153,16 @@ of the fingerprint field. In any place that presently > displays > the "``gpgkey``" field, the last 16 hex digits of the fingerprint should > be displayed instead. > > +Gentoo Keyserver > + > + > +Gentoo infrastructure uses a keyserver that is isolated from the SKS pool. > +This keyserver is restricted to accepting uploads from authorized Gentoo > hosts. > +A script is provided on dev.gentoo.org to allow developers to upload their > +keys. This upload is required in addition to uploading to the SKS pool. > + > +``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload`` > + > Backwards Compatibility > === > > -- > 2.30.0.rc0 > > The rest LGTM. Thanks, Davide
Re: [gentoo-dev] GPG key refresh
On Wed, Dec 16, 2020 at 3:01 AM Michał Górny wrote: > > On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote: > > On 2020-12-15 11:16, Michael Orlitzky wrote: > > > On 12/15/20 11:11 AM, Thomas Deutschmann wrote: > > > > > > > > What do you mean exactly? > > > > > > > > For Gentoo tooling, only Gentoo keyservers are important and > > > > Gentoo no longer synchronizes with any other pool. > > > > > > > "The Gentoo developer tooling explicitly checks the Gentoo > > > keyserver > > > pool with a much higher frequency" strongly implies that we check > > > the > > > non-Gentoo pools with a non-zero frequency. > > > > > > > > > > I'm with Michael on this. I've recently experienced this issue myself > > as the > > instruction to upload the key to the Gentoo keyserver is separate > > from the > > GLEP63[1] document. It doesn't matter that the step is documented if > > the Holy > > Tome GLEP63 doesn't mention it. What hint would I have to look for a > > supplemental document to provide that specific step? > > > > According to GLEP 63, uploading to the SKS keyserver is a > > requirement. > > However, it fails to specify which SKS keyserver. In fact, neither > > "SKS" nor > > "keyserver" are defined in GLEP63. Ergo, the natural interpretation > > is *anything* > > that's called an SKS keyserver will satisfy the requirement. As long > > as the > > developer can submit the key, the requirement is met. > > > > Additionally, the supplemental document[2] doesn't say developers > > must upload > > via an internal host, but that devs should upload to both SKS and the > > Gentoo > > keyserver. Yes, it says the Gentoo keyserver is currently restricted > > to syncing > > with "authorized Gentoo hosts", but that's a nonsense phrase and > > unhelpful. It > > assumes I know what the authorized Gentoo hosts are. It doesn't > > clearly state > > what they are. It kind of hints that it will pull from SKS > > eventually, but it > > could take a long time. > > > > I understand we temporarily stopped syncing with the public keyserver > > out of an > > overabundance of caution. However, that shouldn't have been done > > without > > updating every official Gentoo resource regarding how devs should > > handle their > > keys, which as far as I know is only two documents[1,2]. A whopping 2 > > documents. > > > > This new (I know it's been around for a year but that doesn't make it > > any less > > new), stricter requirement, should be **explicitly** stated in > > GLEP63, properly > > referencing the justification[3], and linking to the infra > > supplemental > > document. The infra supplemental document needs to then use the > > phrase "must" in > > place of "should" when informing readers to upload to two different > > locations. > > ...and what have you done to resolve the problem, except for making > oververbose complaints and demands in middle of some random thread? If you think he's being unhelpful, maybe suggest ways of contributing that would be more helpful. There's no need for this snippy reply.
Re: [gentoo-dev] GPG key refresh
On Wed, Dec 16, 2020 at 11:48 PM desultory wrote: > > On 12/16/20 03:01, Michał Górny wrote: > > On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote: > >> On 2020-12-15 11:16, Michael Orlitzky wrote: > >>> On 12/15/20 11:11 AM, Thomas Deutschmann wrote: > > What do you mean exactly? > > For Gentoo tooling, only Gentoo keyservers are important and > Gentoo no longer synchronizes with any other pool. > > >>> "The Gentoo developer tooling explicitly checks the Gentoo > >>> keyserver > >>> pool with a much higher frequency" strongly implies that we check > >>> the > >>> non-Gentoo pools with a non-zero frequency. > >>> > >>> > >> > >> I'm with Michael on this. I've recently experienced this issue myself > >> as the > >> instruction to upload the key to the Gentoo keyserver is separate > >> from the > >> GLEP63[1] document. It doesn't matter that the step is documented if > >> the Holy > >> Tome GLEP63 doesn't mention it. What hint would I have to look for a > >> supplemental document to provide that specific step? > >> > >> According to GLEP 63, uploading to the SKS keyserver is a > >> requirement. > >> However, it fails to specify which SKS keyserver. In fact, neither > >> "SKS" nor > >> "keyserver" are defined in GLEP63. Ergo, the natural interpretation > >> is *anything* > >> that's called an SKS keyserver will satisfy the requirement. As long > >> as the > >> developer can submit the key, the requirement is met. > >> > >> Additionally, the supplemental document[2] doesn't say developers > >> must upload > >> via an internal host, but that devs should upload to both SKS and the > >> Gentoo > >> keyserver. Yes, it says the Gentoo keyserver is currently restricted > >> to syncing > >> with "authorized Gentoo hosts", but that's a nonsense phrase and > >> unhelpful. It > >> assumes I know what the authorized Gentoo hosts are. It doesn't > >> clearly state > >> what they are. It kind of hints that it will pull from SKS > >> eventually, but it > >> could take a long time. > >> > >> I understand we temporarily stopped syncing with the public keyserver > >> out of an > >> overabundance of caution. However, that shouldn't have been done > >> without > >> updating every official Gentoo resource regarding how devs should > >> handle their > >> keys, which as far as I know is only two documents[1,2]. A whopping 2 > >> documents. > >> > >> This new (I know it's been around for a year but that doesn't make it > >> any less > >> new), stricter requirement, should be **explicitly** stated in > >> GLEP63, properly > >> referencing the justification[3], and linking to the infra > >> supplemental > >> document. The infra supplemental document needs to then use the > >> phrase "must" in > >> place of "should" when informing readers to upload to two different > >> locations. > > > > ...and what have you done to resolve the problem, except for making > > oververbose complaints and demands in middle of some random thread? > > > Discuss it, which is more than you have done here. There is no need to > berate signal because you feel like making noise. > > Formulating and discussing ways to fix problems before actually fixing > them helps to reduce effort wasted on rebuilding old solutions which > have failed for whatever reason. In this case documentation needs to be > updated, discussing the appropriate manner in which to update which > documentation seems to be more grounds for engagement than recrimination. > > On the subject of updating the documentation, the proposal seems > generally sound; do you have any constructive criticism of it? > So I can understand where Michał's reaction comes from. On my first read through Aaron's message, it seemed like a long email complaining about things that had been done wrong. Upon re-reading it with a different mindset, it doesn't seem so bad if you skip over some of the text. For example, I don't think the paragraph below is necessary, and could evoke a defensive reaction from the recipient. > I understand we temporarily stopped syncing with the public keyserver out of > an > overabundance of caution. However, that shouldn't have been done without > updating every official Gentoo resource regarding how devs should handle their > keys, which as far as I know is only two documents[1,2]. A whopping 2 > documents. I think a shorter email simply requesting that the documentation be updated would have sufficed.
[gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver
Signed-off-by: Mike Gilbert --- v2: Added "This upload is required in addition to uploading the SKS pool." glep-0063.rst | 24 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 82541bd..ec465db 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -7,10 +7,10 @@ Author: Robin H. Johnson , Michał Górny Type: Standards Track Status: Final -Version: 2.1 +Version: 2.2 Created: 2013-02-18 -Last-Modified: 2019-11-07 -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 +Last-Modified: 2020-12-17 +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17 Content-Type: text/x-rst --- @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux distribution. Changes === +v2.2 + Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter. + v2.1 A requirement for an encryption key has been added, in order to extend the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev @@ -135,8 +138,11 @@ their primary key). 5. Encrypted backup of your secret keys. +Gentoo Infrstructure + + Gentoo LDAP -=== +--- All Gentoo developers must list the complete fingerprint for their primary keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits, @@ -147,6 +153,16 @@ of the fingerprint field. In any place that presently displays the "``gpgkey``" field, the last 16 hex digits of the fingerprint should be displayed instead. +Gentoo Keyserver + + +Gentoo infrastructure uses a keyserver that is isolated from the SKS pool. +This keyserver is restricted to accepting uploads from authorized Gentoo hosts. +A script is provided on dev.gentoo.org to allow developers to upload their +keys. This upload is required in addition to uploading to the SKS pool. + +``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload`` + Backwards Compatibility === -- 2.30.0.rc0
Re: [gentoo-dev] [PATCH] glep-0063: Add section about the Gentoo keyserver
On Thu, Dec 17, 2020 at 12:49:09PM -0500, Mike Gilbert wrote: > +Gentoo Keyserver > + > + > +Gentoo infrastructure uses a keyserver that is isolated from the SKS pool. > +This keyserver is restricted to accepting uploads from authorized Gentoo > hosts. > +A script is provided on dev.gentoo.org to allow developers to upload their > +keys. > + > +``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload`` > + Request: Please add the text "This upload is required in addition to uploading the SKS pool", or something to that effect. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
[gentoo-dev] [PATCH] glep-0063: Add section about the Gentoo keyserver
Signed-off-by: Mike Gilbert --- glep-0063.rst | 24 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 82541bd..4191709 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -7,10 +7,10 @@ Author: Robin H. Johnson , Michał Górny Type: Standards Track Status: Final -Version: 2.1 +Version: 2.2 Created: 2013-02-18 -Last-Modified: 2019-11-07 -Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24 +Last-Modified: 2020-12-17 +Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24, 2020-12-17 Content-Type: text/x-rst --- @@ -28,6 +28,9 @@ OpenPGP key management policies for the Gentoo Linux distribution. Changes === +v2.2 + Added "Gentoo Keyserver" section under "Gentoo Infrastructure" chapter. + v2.1 A requirement for an encryption key has been added, in order to extend the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev @@ -135,8 +138,11 @@ their primary key). 5. Encrypted backup of your secret keys. +Gentoo Infrstructure + + Gentoo LDAP -=== +--- All Gentoo developers must list the complete fingerprint for their primary keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits, @@ -147,6 +153,16 @@ of the fingerprint field. In any place that presently displays the "``gpgkey``" field, the last 16 hex digits of the fingerprint should be displayed instead. +Gentoo Keyserver + + +Gentoo infrastructure uses a keyserver that is isolated from the SKS pool. +This keyserver is restricted to accepting uploads from authorized Gentoo hosts. +A script is provided on dev.gentoo.org to allow developers to upload their +keys. + +``gpg --export KEYID | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload`` + Backwards Compatibility === -- 2.29.2
[gentoo-dev] Gentoo kernel hardening
Please consider reviewing and possibly merging this https://github.com/anthraxx/linux-hardened. Also consider reviewing this https://github.com/Whonix/hardened-kernel. Documentation is here https://www.whonix.org/wiki/Hardened-kernel. This is still experimental though. But it could be added in the repos. Thank you. If this is not the appropriate list for this please forward. pEpkey.asc Description: application/pgp-keys
