[gentoo-dev] [PATCH] eclass/lua-utils.eclass: remove EPREFIX from exported module paths

2021-01-11 Thread William Hubbs
Bug: https://bugs.gentoo.org/762769
Signed-off-by: William Hubbs 
---
 eclass/lua-utils.eclass | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 100be14cb08..9fe4d22e93f 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -212,8 +212,9 @@ _lua_get_library_file() {
die "Invalid implementation: ${impl}"
;;
esac
-   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
 
+   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
+   
debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
echo "${libdir}/${libname}"
 }
@@ -274,6 +275,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_CMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_CMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
${LUA_CMOD_DIR}"
@@ -282,6 +284,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable includedir 
${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_INCLUDE_DIR=${val}
debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
${LUA_INCLUDE_DIR}"
@@ -298,6 +301,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_LMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_LMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
${LUA_LMOD_DIR}"
@@ -364,11 +368,14 @@ lua_get_CFLAGS() {
 # @USAGE: []
 # @DESCRIPTION:
 # Obtain and print the name of the directory into which compiled Lua
-# modules are installed, for the given implementation. If no implementation
+# modules are installed for the given implementation. If no implementation
 # is provided, ${ELUA} will be used.
 #
-# Please note that this function requires Lua and pkg-config installed,
-# and therefore proper build-time dependencies need be added to the ebuild.
+# Please note that this function requires Lua and pkg-config to be installed,
+# and therefore proper build-time dependencies need to be added to the ebuild.
+#
+# For prefix installations, this function does not include the offset in
+# the path.
 lua_get_cmod_dir() {
debug-print-function ${FUNCNAME} "${@}"
 
@@ -385,6 +392,9 @@ lua_get_cmod_dir() {
 #
 # Please note that this function requires Lua and pkg-config installed,
 # and therefore proper build-time dependencies need be added to the ebuild.
+#
+# For prefix installations, this function does not include the offset in
+# the path.
 lua_get_include_dir() {
debug-print-function ${FUNCNAME} "${@}"
 
@@ -412,11 +422,14 @@ lua_get_LIBS() {
 # @USAGE: []
 # @DESCRIPTION:
 # Obtain and print the name of the directory into which native-Lua
-# modules are installed, for the given implementation. If no implementation
+# modules are installed for the given implementation. If no implementation
 # is provided, ${ELUA} will be used.
 #
 # Please note that this function requires Lua and pkg-config installed,
 # and therefore proper build-time dependencies need be added to the ebuild.
+#
+# For prefix installations, this function does not include the offset in
+# the path.
 lua_get_lmod_dir() {
debug-print-function ${FUNCNAME} "${@}"
 
-- 
2.26.2




Re: [gentoo-dev] [PATCH] eclass/lua.eclass: remove EPREFIX from exported paths

2021-01-07 Thread William Hubbs
I'll fix the subject before I commit.

William

On Thu, Jan 07, 2021 at 05:13:09PM -0600, William Hubbs wrote:
> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs 
> ---
>  eclass/lua-utils.eclass | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..1e552da0848 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,10 @@ _lua_get_library_file() {
>   die "Invalid implementation: ${impl}"
>   ;;
>   esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>  
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> + libdir="${libdir#${ESYSROOT#${SYSROOT}}}"
> + 
>   debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
>   echo "${libdir}/${libname}"
>  }
> @@ -274,6 +276,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_CMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
> ${LUA_CMOD_DIR}"
> @@ -282,6 +285,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable includedir 
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_INCLUDE_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +302,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_LMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
> ${LUA_LMOD_DIR}"
> -- 
> 2.26.2
> 
> 


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] eclass/lua.eclass: remove EPREFIX from exported paths

2021-01-07 Thread William Hubbs
Bug: https://bugs.gentoo.org/762769
Signed-off-by: William Hubbs 
---
 eclass/lua-utils.eclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 100be14cb08..1e552da0848 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -212,8 +212,10 @@ _lua_get_library_file() {
die "Invalid implementation: ${impl}"
;;
esac
-   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
 
+   libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
+   libdir="${libdir#${ESYSROOT#${SYSROOT}}}"
+   
debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
echo "${libdir}/${libname}"
 }
@@ -274,6 +276,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_CMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_CMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
${LUA_CMOD_DIR}"
@@ -282,6 +285,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable includedir 
${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_INCLUDE_DIR=${val}
debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
${LUA_INCLUDE_DIR}"
@@ -298,6 +302,7 @@ _lua_export() {
local val
 
val=$($(tc-getPKG_CONFIG) --variable 
INSTALL_LMOD ${impl}) || die
+   val="${val#${ESYSROOT#${SYSROOT}}}"
 
export LUA_LMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
${LUA_LMOD_DIR}"
-- 
2.26.2




Re: [gentoo-dev] [PATCH 1/3] meson.eclass: use python eselect module in _meson_env_array

2020-12-20 Thread William Hubbs
On Thu, Dec 17, 2020 at 10:58:23PM +0100, Michał Górny wrote:
> 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.

If we are going to install it to the system, that should not be done by
dev-util/meson; it is a gentoo-specific script, so we should probably
create a separate package for it. Also, it is debatable whether that
script should be installed in a directory that is on the path.

I have major concerns about the native-symlinks use flag for python-exec.
It looks like turning this flag off would result in /usr/bin/python not being
installed which will cause massive breakage. This is similar to removing
/bin/sh., so I am strongly against the idea of this use flag unless
upstream python is recommending it. If they are not installing
/usr/bin/python in their native builds any longer, I'll be quiet.
Otherwise, imo this is a really bad idea for a use flag.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-17 Thread William Hubbs
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 1/3] dev-util/meson: install meson-array script

2020-12-12 Thread William Hubbs
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.

Also, I don't think your script will run if native-symlinks is disabled since in
that setting /usr/bin/python would not exist.

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.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 3/3] app-emulation/gallium-nine-standalone: use meson-array

2020-12-12 Thread William Hubbs
On Fri, Dec 11, 2020 at 06:17:44PM -0500, Mike Gilbert wrote:
> Bug: https://bugs.gentoo.org/759433
> 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..9e075e1f5edb 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-array "${CFLAGS} 
> '-DG9DLL=${g9dll}'")!" \
> + -e "s!@LDFLAGS@!$(meson-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..9e075e1f5edb 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-array "${CFLAGS} 
> '-DG9DLL=${g9dll}'")!" \
> + -e "s!@LDFLAGS@!$(meson-array "${LDFLAGS}")!" \
>   -e 
> "s!@PKG_CONFIG_LIBDIR@!${PKG_CONFIG_LIBDIR:-${ESYSROOT}/usr/$(get_libdir)/pkgconfig}!"
>  \
>   ${file}.in > ${file} || die
>   }
> -- 
> 2.29.2

# @FUNCTION: _meson_env_array
# @INTERNAL
# @DESCRIPTION:
# Parses the command line flags and converts them into an array suitable for
# use in a cross file.

The _meson_env_array function is not part of the API for the meson
eclass.

Can you tell me more about gallium-nine-standalone and what it needs
from the meson eclass? We can probably provide functions that return the
info it needs.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-12 Thread William Hubbs
On Fri, Dec 11, 2020 at 06:17:42PM -0500, Mike Gilbert wrote:
> Bug: https://bugs.gentoo.org/759433
> Signed-off-by: Mike Gilbert 
> ---
>  dev-util/meson/files/meson-array   | 18 ++
>  ...on-0.55.3.ebuild => meson-0.55.3-r1.ebuild} |  5 +
>  dev-util/meson/meson-.ebuild   |  5 +
>  3 files changed, 28 insertions(+)
>  create mode 100644 dev-util/meson/files/meson-array
>  rename dev-util/meson/{meson-0.55.3.ebuild => meson-0.55.3-r1.ebuild} (96%)
> 
> diff --git a/dev-util/meson/files/meson-array 
> b/dev-util/meson/files/meson-array
> new file mode 100644
> index ..0f4e8c7c6389
> --- /dev/null
> +++ b/dev-util/meson/files/meson-array
> @@ -0,0 +1,18 @@
> +#!/usr/bin/env python
> +
> +import itertools
> +import shlex
> +import sys
> +
> +def quote(s):
> +return "'" + s.replace("\\", "").replace("'", "\\'") + "'"
> +
> +def main():
> +args = sys.argv[1:]
> +args = (shlex.split(x) for x in args)
> +args = itertools.chain.from_iterable(args)
> +args = (quote(x) for x in args)
> +print("[" + ", ".join(args) + "]")
> +
> +if __name__ == "__main__":
> +main()
> diff --git a/dev-util/meson/meson-0.55.3.ebuild 
> b/dev-util/meson/meson-0.55.3-r1.ebuild
> similarity index 96%
> rename from dev-util/meson/meson-0.55.3.ebuild
> rename to dev-util/meson/meson-0.55.3-r1.ebuild
> index ddf27ccdc725..4708a46b324f 100644
> --- a/dev-util/meson/meson-0.55.3.ebuild
> +++ b/dev-util/meson/meson-0.55.3-r1.ebuild
> @@ -82,6 +82,11 @@ python_test() {
>   ) || die "Testing failed with ${EPYTHON}"
>  }
>  
> +python_install() {
> + distutils-r1_python_install
> + python_doscript "${FILESDIR}/meson-array"
> +}
> +
>  python_install_all() {
>   distutils-r1_python_install_all
>  
> diff --git a/dev-util/meson/meson-.ebuild 
> b/dev-util/meson/meson-.ebuild
> index 38ccf9179e21..1cdd142a3f79 100644
> --- a/dev-util/meson/meson-.ebuild
> +++ b/dev-util/meson/meson-.ebuild
> @@ -82,6 +82,11 @@ python_test() {
>   ) || die "Testing failed with ${EPYTHON}"
>  }
>  
> +python_install() {
> + distutils-r1_python_install
> + python_doscript "${FILESDIR}/meson-array"
> +}
> +
>  python_install_all() {
>   distutils-r1_python_install_all
>  
> -- 
> 2.29.2

I am fully aware I don't have full context for this, so fill me in if I
am missing something.

Reading this patch series and the bug linked in this message, it looks
like we are trying to make meson.eclass work if /usr/bin/python is missing.

My question is why? as far as I know /usr/bin/python is standard
like /bin/sh; when a version of python is installed this link is
always available.

If /usr/bin/python is going away, it is going to break not only this but
every python script that has "#!/usr/bin/python" or
"#!/usr/bin/env python" as a shebang line.

If /usr/bin/python is going away, what about /usr/bin/python3? If that
isn't going away, the easier thing to do is to tweak the eclass to call
it instead.

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.

Please do not apply this patch to meson; I think we can figure something
out that is better.

Also, see my comments on the third patch in the series for more context.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-29 Thread William Hubbs
On Thu, Nov 26, 2020 at 07:55:33AM +0100, Piotr Karbowski wrote:
> Hi,
> 
> On 25/11/2020 22.57, Georgy Yakovlev wrote:
> > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus,
> > and is just a drop-in replacement, the only step needed is to emerge the
> > package.
> > it's a simple single binary + manpage, binary links to libacl and couple 
> > other
> > system libs.
> 
> Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been
> using it since end of October.
> 
> Two things that are different in terms of interface to opentmpfiles is
> that systemd-tmpfiles does not have --dry-run runtime option, and it
> will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of
> /run, but that's just an warning.

Also, have we tested this on musl systems?

My plan is to take the tmpfiles code from systemd, like eudev and elogin
have done, and rewrite it to not use the systemd libraries so it will be
more portable.

Once this happens, I'll probably switch the provider back to
opentmpfiles.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-07 Thread William Hubbs
On Tue, Nov 03, 2020 at 10:32:11PM +0100, Michał Górny wrote:
> net-libs/nodejs

I'll take this one for now.

William


signature.asc
Description: PGP signature


[gentoo-dev] sys-cluster/kubernetes last rites

2020-10-25 Thread William Hubbs
# Wiliam Hubbs  (2020-10-26)
# Combining kubernetes into one package breaks upgrades, so it is split
# into separate packages. You need to upgrade and install the following
# packages based on the needs of your cluster:
#
# sys-cluster/kubeadm, sys-cluster/kube-apiserver
# sys-cluster/kube-controller-manager, sys-cluster/kubectl
# sys-cluster/kubelet, sys-cluster/kube-proxy
# sys-cluster/kube-scheduler
#
# This package is being removed in 30 days. bug #741572
sys-cluster/kubernetes

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 1/6] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-06 Thread William Hubbs
Hey all,

I'm just picking an eclass to respond to because I see this pretty
often, so I'm definitely not picking on mgorny with this question.

On Tue, Oct 06, 2020 at 02:10:45PM +0200, Michał Górny wrote:

*snip*

> +case "${EAPI:-0}" in
> + 0|1|2|3|4|5|6)
> + die "Unsupported EAPI=${EAPI} (obsolete) for ${ECLASS}"
> + ;;
> + 7)
> + ;;
> + *)
> + die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> + ;;
> +esac

Does it really matter that an EAPI is unsupported because it is obsolete
vs unknown? Can we simplify this case statement to the following or
something similar for all of our eclasses?

case "${EAPI:-0}" in
7)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac

William



signature.asc
Description: PGP signature


[gentoo-dev] newsitem: k8s split packages round 3

2020-10-05 Thread William Hubbs
[Note: After chatting on irc, I haven't come up with anything that makes
sense for a kubernetes meta package, but I am open to meta packages if others
think they might be useful, so let's discuss that idea in a separate
thread. The text of the newsitem is below.]

Title: kubernetes Split Packages Returning
Author: William Hubbs 
Posted: 2020-10-06
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-cluster/kubernetes

In order to fix the ability to upgrade kubernetes components separately,
the kubernetes split packages are returning [1].

Starting with kubernetes 1.17.12, 1.18.9 and 1.19.2, you will need to
install the following packages in the appropriate configuration for
your cluster.

sys-cluster/kubeadm
sys-cluster/kube-apiserver
sys-cluster/kube-controller-manager
sys-cluster/kubectl
sys-cluster/kubelet
sys-cluster/kube-proxy
sys-cluster/kube-scheduler

Once the split packages are stabilized, sys-cluster/kubernetes will be
masked and removed.

[1] https://bugs.gentoo.org/741572


signature.asc
Description: PGP signature


Re: [gentoo-dev] newsitem: k8s split packages returning round 2

2020-10-04 Thread William Hubbs
On Sun, Oct 04, 2020 at 10:23:10PM +0200, Michał Górny wrote:
> On Sun, 2020-10-04 at 14:48 -0500, William Hubbs wrote:
> > Title: K8s Split Packages Returning
> 
> I think you should really use the full name here, especially that it is
> also the package name.

This is fixed.

> 
> > Author: William Hubbs 
> > Posted: 2020-10-06
> > Revision: 1
> > News-Item-Format: 2.0
> > Display-If-Installed: sys-cluster/kubernetes
> > 
> > Due to bug #741572,, the k8s split packages are returning to fix issues
> > with upgrading clusters [1].
> 
> It would be nice to include a short explanation what these issues are.
>  Expecting all affected users to open Bugzilla just to see whether
> the bug in question is relevant causes them unnecessary work.

The short version is it is not possible to upgrade a cluster if you have
everything in one package.

> > Starting with k8s 1.17.12, 1.18.9 and 1.19.2, you will need to install
> > the following packages in the appropriate configuration for your
> > cluster.
> > 
> > sys-cluster/kubeadm
> > sys-cluster/kube-apiserver
> > sys-cluster/kube-controller-manager
> > sys-cluster/kubectl
> > sys-cluster/kubelet
> > sys-cluster/kube-proxy
> > sys-cluster/kube-scheduler
> > 
> > Once the split packages are stabilized, sys-cluster/kubernetes will be
> > masked and removed.
> 
> Why not make it a metapackage, and maybe have USE flags to assist common
> configurations?
 
I've thought about that, and I'm not opposed to  meta packages. I'm just
not sure yet which pieces are required where. I know you don't need all
of the pieces to run a cluster. I'm just not sure which pieces are
required on which nodes.

I don't think it would be one kubernetes meta package, but several
depending on the type of node you are setting up.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] newsitem: k8s split packages returning round 2

2020-10-04 Thread William Hubbs
On Sun, Oct 04, 2020 at 02:48:35PM -0500, William Hubbs wrote:
> Due to bug #741572,, the k8s split packages are returning to fix issues

The typo on this line is fixed.

William


signature.asc
Description: PGP signature


[gentoo-dev] newsitem: k8s split packages returning round 2

2020-10-04 Thread William Hubbs
Title: K8s Split Packages Returning
Author: William Hubbs 
Posted: 2020-10-06
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-cluster/kubernetes

Due to bug #741572,, the k8s split packages are returning to fix issues
with upgrading clusters [1].

Starting with k8s 1.17.12, 1.18.9 and 1.19.2, you will need to install
the following packages in the appropriate configuration for your
cluster.

sys-cluster/kubeadm
sys-cluster/kube-apiserver
sys-cluster/kube-controller-manager
sys-cluster/kubectl
sys-cluster/kubelet
sys-cluster/kube-proxy
sys-cluster/kube-scheduler

Once the split packages are stabilized, sys-cluster/kubernetes will be
masked and removed.

[1] https://bugs.gentoo.org/741572


signature.asc
Description: PGP signature


Re: [gentoo-dev] newsitem: k8s split packages returning

2020-10-04 Thread William Hubbs
On Sun, Oct 04, 2020 at 09:19:27AM +0300, Joonas Niilola wrote:
> Could you please plaintext the news item in your mail so it'd be easier 
> to quote?
 
 I'm curious why it is hard for you to quote from an attachment? I see
 later in the thread that ulm has no problem doing so. No big deal, I'm
 just wondering.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] newsitem: k8s split packages returning

2020-10-04 Thread William Hubbs
On Sun, Oct 04, 2020 at 08:52:13AM +0200, Toralf Förster wrote:
> On 10/4/20 12:11 AM, William Hubbs wrote:
> 
> And either the enw Thunderbirds GPG sucks or your key does not match the 
> sender name :-(

It shows up as a good signature here when I get the email back on the
list, so I'm not sure what's up.

William



signature.asc
Description: PGP signature


[gentoo-dev] newsitem: k8s split packages returning

2020-10-03 Thread William Hubbs
Title: K8s Split Packages Returning
Author: William Hubbs 
Posted: 2020-10-06
Revision: 1
News-Item-Format: 2.0
display-if-installed: sys-cluster/kubernetes

It was called to my attention in bug #741572 that having k8s in a single
package can block upgrades. Because of this, I need to bring back the
split packages [1].

Starting with k8s 1.17.12, 1.18.9 and 1.19.2, you will need to install
the following packages in the appropriate configuration for your
cluster.

sys-cluster/kubeadm
sys-cluster/kube-apiserver
sys-cluster/kube-controller-manager
sys-cluster/kubectl
sys-cluster/kubelet
sys-cluster/kube-proxy
sys-cluster/kube-scheduler

Once the split packages are stabilized, sys-cluster/kubernetes will be
masked and removed.

[1] https://bugs.gentoo.org/741572


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: kubernetes packaging

2020-09-15 Thread William Hubbs
On Mon, Sep 14, 2020 at 12:30:48PM +0200, Marc Schiffbauer wrote:
> * William Hubbs schrieb am 14.09.20 um 00:39 Uhr:
> > All,
> > 
> > I would like to get some thoughts on kubernetes packaging.
> > 
> > When I started maintaining it in Gentoo, it was packaged as 7 ebuilds
> > (one per executable), and only one of them was marked stable.
> > 
> > Since we normally do not split up monorepos into separate packages, I
> > started moving everything over to one kubernetes ebuild.
> > Now a bug has
> > been opened which has a good case for kubeadm being a package on its
> > own, so I have done that [1].
> > 
> > I need to know the best way to proceed, so I'll throw out a couple
> > of questions:
> > 
> > 1) should I bring back the split packages and lastrites
> > sys-cluster/kubernetes?
> > 
> > 2) should I just bring back other split packages that need to be split
> > as I find them?
> > 
> > What do folks think would be the best way for us to package Kubernetes?
> 
> 
> Interesting.
> 
> So it seems like at least kubeadm and kube-apiserver need to be in 
> seperate packages.
> 
> I am not a kubernetes guy, but would SLOTting be an option? Like 
> postgresql for example where you need both versions, old a new to do 
> database migration.

I'm not really interested in slotting; that becomes complicated really
quickly -- renaming all of the binaries to version-specific names
writing an eselect module, etc.

> If this is not an option I would say this is a case for split package 
> and perhaps a meta-package bringing all of them together.

Thinking about it more, the split packages are going to be the best
setup. However, a meta package would only be valuable if all parts of
kubernetes are needed on the same machine, and that isn't the case most
of the time from what I've been told.

If folks think that single case justifies one, let me know.
My thought is that the meta package, if I create one, should only have a
two level version number and use * dependencies to match all package
versions in that range.

What do others think? is it worth a meta package for the case of having
all kubernetes binaries on one machine? If so, what do you think about
my suggestion of the minor versions for the meta package?

William



signature.asc
Description: PGP signature


[gentoo-dev] rfc: kubernetes packaging

2020-09-13 Thread William Hubbs
All,

I would like to get some thoughts on kubernetes packaging.

When I started maintaining it in Gentoo, it was packaged as 7 ebuilds
(one per executable), and only one of them was marked stable.

Since we normally do not split up monorepos into separate packages, I
started moving everything over to one kubernetes ebuild.
Now a bug has
been opened which has a good case for kubeadm being a package on its
own, so I have done that [1].

I need to know the best way to proceed, so I'll throw out a couple
of questions:

1) should I bring back the split packages and lastrites
sys-cluster/kubernetes?

2) should I just bring back other split packages that need to be split
as I find them?

What do folks think would be the best way for us to package Kubernetes?

Thanks,

William

[1] https://bugs.gentoo.org/741572



signature.asc
Description: PGP signature


[gentoo-dev] slotted lua

2020-09-09 Thread William Hubbs
All,

I'm trying again because I didn't see my last msg come back.

Someone mentioned issues with slotted lua on a thread earlier but didn't
give any details.

What are the issues that you have found? are there open bugs for them?
I would like to take a look.

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] Re: [PATCH] meson.eclass: fix machine files

2020-08-30 Thread William Hubbs
On Sun, Aug 30, 2020 at 05:36:32PM -0400, Mike Gilbert wrote:
> On Sun, Aug 30, 2020 at 4:06 PM William Hubbs  wrote:
> >
> > Several options we were setting in the [properties] section of the
> > machine files have been moved to the [built-in options] section.
> 
> What version of meson introduced "built-in options"? I imagine we will
> need to keep the properties around until a new enough version of meson
> is stable.

It looks like we'll need to wait for 0.56.x to be released before we can
do this.

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] meson.eclass: fix machine files

2020-08-30 Thread William Hubbs
Several options we were setting in the [properties] section of the
machine files have been moved to the [built-in options] section.

Closes: https://bugs.gentoo.org/738710
Signed-off-by: William Hubbs 
---
 eclass/meson.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 21338280df3..a02e94c7a01 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -185,7 +185,7 @@ _meson_create_cross_file() {
strip = $(_meson_env_array "$(tc-getSTRIP)")
windres = $(_meson_env_array "$(tc-getRC)")
 
-   [properties]
+   [built-in options]
c_args = $(_meson_env_array "${CFLAGS} ${CPPFLAGS}")
c_link_args = $(_meson_env_array "${CFLAGS} ${LDFLAGS}")
cpp_args = $(_meson_env_array "${CXXFLAGS} ${CPPFLAGS}")
@@ -236,7 +236,7 @@ _meson_create_native_file() {
strip = $(_meson_env_array "$(tc-getBUILD_STRIP)")
windres = $(_meson_env_array "$(tc-getBUILD_PROG RC windres)")
 
-   [properties]
+   [built-in options]
c_args = $(_meson_env_array "${BUILD_CFLAGS} ${BUILD_CPPFLAGS}")
c_link_args = $(_meson_env_array "${BUILD_CFLAGS} ${BUILD_LDFLAGS}")
cpp_args = $(_meson_env_array "${BUILD_CXXFLAGS} ${BUILD_CPPFLAGS}")
-- 
2.26.2




Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread William Hubbs
On Mon, Aug 10, 2020 at 05:47:52PM +0200, Alexis Ballier wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sat, 8 Aug 2020 13:51:41 -0500
> William Hubbs  wrote:
> 
> > All,
> > 
> > I would like to propose that we switch the default udev provider on
> > new systems from eudev to udev.
> > 
> > This is not a lastrites, and it will not affect current systems since
> > they have to migrate manually. Also, this change can be overridden at
> > the profile level if some profile needs eudev (the last time I
> > checked, this applies to non-glibc configurations).
> > 
> > What do people think?
> 
> No opinion on which to choose, I use the default one at the time I do
> an install and have been happy with both.
> 
> My main concern is that since the change won't be "live" until a
> switched virtual reaches stable, eudev will still be much better tested
> in our environment at this point, and people might uncover corner cases
> when it's too late. Maybe a compromise could be to provide and
> primarily advertise udev stages before making the switch ?

Creating udev stages would require a separate profile which would be
removed once we did the default switch, so I'm not sure if we want to go
that route. Does anyone remember if we did this for the original eudev
switch? If we did, I am open to doing it again, but I honestly don't recall.

All of the providers are stable currently, so my thought is a tracker +
newsitem with a delay before switching the default. I'm thinking about a
30 day test window where we ask people to migrate their systems and
if they find issues open bugs that block the tracker.

Thoughts?

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread William Hubbs
On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> On 8/8/2020 14:51, William Hubbs wrote:
> > All,
> > 
> > I would like to propose that we switch the default udev provider on new
> > systems from eudev to udev.
> > 
> > This is not a lastrites, and it will not affect current systems since
> > they have to migrate manually. Also, this change can be overridden at
> > the profile level if some profile needs eudev (the last time I checked,
> > this applies to non-glibc configurations).
> > 
> > What do people think?
> > 
> > Thanks,
> > 
> > William
> 
> Is eudev broken in some way?  If so, has a bug been filed?  If not, why not?
> 
> If eudev is not broken, then why your proposed fix?

bitrot and bus factor.

> It works fine for new installs, having just done one myself.  Seems like we
> aught to keep it that way.  I count six open bugs against eudev right now,
> and none of them look to be critical, so I vote "no" on your proposal unless
> there is some verifiable reason why eudev is no longer suitable to be the
> default udev provider.

The thing is, udev was never unsuitable. AS I said the original change
was not because of the lack of suitability, but because of fear of what
the udev devs might do. That fear never came true.

Not that it matters much, but I'll go there since you did, I count 26
open issues against eudev and some of them have been open since 2012.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread William Hubbs
On Mon, Aug 10, 2020 at 08:49:20AM -0400, Rich Freeman wrote:
> On Mon, Aug 10, 2020 at 8:16 AM Thomas Deutschmann  wrote:
> >
> > On 2020-08-10 14:07, Michał Górny wrote:
> > > ...or a revert of a change made for change's sake.
> >
> > That's a bold statement for an unambiguous 7-0 decision as seen in
> > https://bugs.gentoo.org/575718.
> 
> As one who voted yes, my rationale is already in the bug comments, and
> I voted yes because it seemed to be the preference of most non-systemd
> users on the mailing list.  I can't say whether this is still the case
> but I'm guessing it is.  I don't think it is really a well-founded
> preference but I don't really see a point in fighting it when people
> can use whichever they prefer.
 
My rationale for voting yes was based on the idea that it would
be easy to switch back, and even if we did, it would be easy for
someone to switch to eudev if they want it.

> If the eudev bus factor drops from 1 to 0 and people get tired of
> dealing with it, I suspect switching back will become more popular.
> If that never happens that is fine too.  If people have unusual
> configs not addressed by eudev, or just plain old good taste,  they
> can always use udev or systemd.
> 
> If eudev were causing serious problems or holding back other projects
> for some reason I'd feel differently.  Otherwise I tend to agree with
> the sense that if you're going to make a change there should be a
> reason.  The reason for the previous change was that a strong majority
> had a strong preference.  Based on the tone of discussion I'm not sure
> that has changed - there isn't as much vehemence in the discussion,
> but I suspect that is mostly because most don't think this is likely
> to happen so they don't bother to reply.
 
 There's another interpretation. Most users or developers don't care.

No one has offered to switch from eudev to udev and look at
regressions. People are asking me to show what features exist in udev
that aren't in eudev. I stuck with udev. I don't use eudev so I don't
know.

As I have said earlier on the thread, we should look at udev and seee if
it breaks things in relation to eudev. That would take some folks
migrating their systems and reporting issues.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-09 Thread William Hubbs
On Sun, Aug 09, 2020 at 01:22:44PM -0500, William Hubbs wrote:
> On Sun, Aug 09, 2020 at 06:40:07PM +0200, Thomas Deutschmann wrote:
> > On 2020-08-08 20:51, William Hubbs wrote:
> > > What do people think?
> > 
> > Like others already asked: What's the reason for this?
>  
>  Like others have said on the thread, the reason for the switch away
>  from udev in the past was mostly fear driven instead of fact driven. As
>  already said, if the udev developers were going to make udev unusable
>  without systemd they would have by now.
> 
> > What do you expect from this change?

> > Is there a problem when new Gentoo installations will use EUDEV by
> > default? Or is there a benefit if new installations would use sys-fs/udev?

Here is something else to consider.

Blueness and any of the other eudev maintainers are doing good work
for alternative c library support such as musl. In fact, the musl
profiles hard mask sys-fs/udev, so they are covered no matter what
happens as a result of this thread.

Eudev is supposed to be udev without systemd along with alternative c
library support, but it appears to be behind what eudev offers.

The following commit appears to be the last time eudev synced with udev:

https://github.com/gentoo/eudev/commit/2ab887ec67afd15eb9b0849467f1f9c036a2b6c8

There are roughly 100 commits in the udev master branch since the date of this
sync:

https://github.com/systemd/systemd/commits/master/src/udev

There are several new commits in libudev and udev rules since then as
well:

https://github.com/systemd/systemd/commits/master/src/libudev
https://github.com/systemd/systemd/commits/master/rules.d

I would like to publically thank Leio for providing me with the
information above.

I asked the council for guidance and was told that they don't need to be
involved, so I guess the best thing to do now is call for testers.

It would be helpful if people migrate their systems manually from eudev to udev
and report issues.

I'm not a valid test case because I have always run udev.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-09 Thread William Hubbs
On Sun, Aug 09, 2020 at 06:40:07PM +0200, Thomas Deutschmann wrote:
> On 2020-08-08 20:51, William Hubbs wrote:
> > What do people think?
> 
> Like others already asked: What's the reason for this?
 
 Like others have said on the thread, the reason for the switch away
 from udev in the past was mostly fear driven instead of fact driven. As
 already said, if the udev developers were going to make udev unusable
 without systemd they would have by now.

> What do you expect from this change?
 
 I expect Gentoo to use, by default, what most of the Linux community
 uses for device management.

> Is there a problem when new Gentoo installations will use EUDEV by
> default? Or is there a benefit if new installations would use sys-fs/udev?

Please look back at the history of why we switched away from udev. It
was not technical. Udev did not cause any wide scale distro breakages.
It was because some folks were very loud about a possible systemd
consppiracy around making udev not work without systemd.

Years later, this has not happened, so to be honest, I think it is time
to admit that we , as a council and distro, over reacted and undo that
over reaction.

Notice again that I'm not saying we need to lastrites eudev. There are
cases that have developed for it (mainly non-glibc systems), but I am
saying I see no justification at this point for it being the default
distro wide.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
Hi Rich,

On Sat, Aug 08, 2020 at 06:22:17PM -0400, Rich Freeman wrote:
> On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford  wrote:
> >
> > With the declared aim from upstream of making udev inseparable from
> > systemd, its not something to be done lightly.
> > That's the entire reason that eudev was necessary.
> >
> > I would want some convincing that it was not another step on the road
> > to Gentoo being assimilated by systemd.
> 
> So, I really could care less what the default is since it won't impact
> any of my Gentoo hosts either way, but this seems like a silly reason
> to base the decision on.  IMO it was paranoid years ago when people
> first brought it up.  Now it is even moreso considering that years
> have elapsed without any grand systemd conspiracy being revealed.  If
> their goal was to make it impossible to use udev on its own just to
> mess with the 0.01% of Linux users who don't use systemd but do use
> (e)udev, I'd think they'd have gotten around to it by now, or at least
> they would still be talking about it.
 
 I couldn't agree with you more on this point. I think if they were
 going to make udev impossible to use without systemd they would have
 gotten around to that by now. And, yes, the fear of this was the
 primary reason for the switch when the council voted to change it.

> William - can you actually elaborate on WHY you want to change things?
>  Is there some problem with eudev?  Is it actively maintained and
> generally tracking upstream udev commits (minus whatever they
> intentionally don't want to accept)?
 
 It is maintained primarily by one person the last time I checked, and I
 don't really know what he has included or not included from udev. What
 I can say is that the last release of eudev hit the tree a year ago,
 and I'm not sure about feature parity with udev.

> I'd be curious as to a list of the practical differences between the
> two at this point.  For the longest time the only ones I was aware of
> were the de-bundled build system, and the change in the default
> persistent ethernet device name rule which was made in udev but not
> made (by default) in eudev.  Perhaps at this point there are other
> differences.

The only other one I know of is if you aren't using glibc udev will not
compile, but I'm not even sure that is an issue still.

The way I see it, we switched away from udev because of a fear that
never materialized, and I'm not convinced that we have enough time to
keep it in feature parity with udev which it needs to be to be the
default provider.

I am going to echo again. I am not talking about removing eudev from the
tree, so you would be able to use it if you want. I'm just suggesting
that we should start new systems out with udev.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
On Sat, Aug 08, 2020 at 11:38:36PM +0200, Jaco Kroon wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> On 2020/08/08 22:57, William Hubbs wrote:
> > On Sat, Aug 08, 2020 at 09:17:20PM +0100, Roy Bamford wrote:
> >> On 2020.08.08 19:51, William Hubbs wrote:
> >>> All,
> >>>
> >>> I would like to propose that we switch the default udev provider on
> >>> new
> >>> systems from eudev to udev.
> >>>
> >>> This is not a lastrites, and it will not affect current systems since
> >>> they have to migrate manually. Also, this change can be overridden at
> >>> the profile level if some profile needs eudev (the last time I
> >>> checked,
> >>> this applies to non-glibc configurations).
> >>>
> >>> What do people think?
> >>>
> >>> Thanks,
> >>>
> >>> William
> >>>
> >>>
> >>
> >> William,
> >>
> >> With the declared aim from upstream of making udev inseparable from
> >> systemd, its not something to be done lightly.
> >> That's the entire reason that eudev was necessary.
> >  
> > Eudev never became necessary unless you are using a non-glibc system,
> > and as I said, this can be handled in the profiles.
> > Udev  runs completely fine without systemd, so I fail to see how eudev
> > is necessary for most of Gentoo.
> 
> It actually works is enough reason for me.  Was forced to migrate a
> bunch of systems not six months back from systemd-udev to eudev because
> systemd-udev is absolutely terrible w.r.t. race conditions resulting in
> lockups that kept forcing us into manual intervention situations. 
> Mostly on systems with LVM.
 
I don't exactly know what your situation is, but as I said, this
proposal wouldn't affect your systems. I'm not talking about lastrites
for eudev, just making it the default for new installs.

> I'm completely against the proposal.
> 
> >> I would want some convincing that it was not another step on the road
> >> to Gentoo being assimilated by systemd.
> >>
> >> We had this discussion several years ago when the default became
> >> eudev. What's changed?
> >
> > If systemd folks do make udev inseparable from systemd, then we would
> > need eudev to be the default, but as I see it right now, there is not
> > a case for it being the default.
> 
> Other than that it works and the systemd version does not.  Might be
> configuration dependent, but I don't expect a default udev
> configuration/system side to not cause LVM breakages when running
> commands as simple as "lvs".  eudev in coparison just works.
 
 I don't know what is going on with your systems, but I suspect possible
 configuration dependence.

When are the breakages happening-- just at random or during bootup?

William

> >
> > Another thing to consider is bus factor (eudev is maintained by one
> > person primarily, so I have doubts about its viability as the default.
> 
> Yes, this is a problem.
> 
> Kind Regards,
> Jaco
> 
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8vG1AACgkQCC3Esa/3
> 7p7Yvgf6Apoi1oCUKSyLEvH8fAEgbMIODULJAZx5+/C1dbROdjkWEzTTp3pNjWiQ
> u8S2qz3xmh9QmKBwTAxB38U/gqXVRpF+xYfSF7K/CDUVcfAg5ViTL3W7YeJMPFNa
> Jk8BgrarAc1Ln8OXCJ37Gf0eeuyBTsQQQ5qqubzNjdLBhrZegWY57gElrItE0Ywb
> IjVBUO4QX3PSoOpZ5UlIo8Ioh+8ANXc/ADg7wASVQkd3dciyewZasZho/q6cNn6W
> c44aMNFRTeiUfcK4+bpGMslq70y7D7JITkjkP+9e68e8wkh93L8fVs4BszBYEtUY
> G6IXc4QtJ5Jf3bQRbyCnGcFYXrSLgg==
> =rF5/
> -END PGP SIGNATURE-
> 
> 


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
On Sat, Aug 08, 2020 at 09:17:20PM +0100, Roy Bamford wrote:
> On 2020.08.08 19:51, William Hubbs wrote:
> > All,
> > 
> > I would like to propose that we switch the default udev provider on
> > new
> > systems from eudev to udev.
> > 
> > This is not a lastrites, and it will not affect current systems since
> > they have to migrate manually. Also, this change can be overridden at
> > the profile level if some profile needs eudev (the last time I
> > checked,
> > this applies to non-glibc configurations).
> > 
> > What do people think?
> > 
> > Thanks,
> > 
> > William
> > 
> > 
> 
> William,
> 
> With the declared aim from upstream of making udev inseparable from 
> systemd, its not something to be done lightly.
> That's the entire reason that eudev was necessary.
 
Eudev never became necessary unless you are using a non-glibc system,
and as I said, this can be handled in the profiles.
Udev  runs completely fine without systemd, so I fail to see how eudev
is necessary for most of Gentoo.

> I would want some convincing that it was not another step on the road
> to Gentoo being assimilated by systemd.
> 
> We had this discussion several years ago when the default became 
> eudev. What's changed?

If systemd folks do make udev inseparable from systemd, then we would
need eudev to be the default, but as I see it right now, there is not
a case for it being the default.

Another thing to consider is bus factor (eudev is maintained by one
person primarily, so I have doubts about its viability as the default.

William



signature.asc
Description: PGP signature


[gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
All,

I would like to propose that we switch the default udev provider on new
systems from eudev to udev.

This is not a lastrites, and it will not affect current systems since
they have to migrate manually. Also, this change can be overridden at
the profile level if some profile needs eudev (the last time I checked,
this applies to non-glibc configurations).

What do people think?

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] last rites: kubernetes split packages

2020-07-13 Thread William Hubbs
# William Hubbs  (2020-07-14)
# The kubernetes split packages are old versions with known security
# issues.
#
#If you haven't already, please upgrade and migrate to sys-cluster/kubernetes:
#
# 
https://www.gentoo.org/support/news-items/2020-04-03-kubernetes-moving-to-single-package.html
#
# Removal in 60 days. Bug #731804
sys-cluster/kubeadm
sys-cluster/kube-apiserver
sys-cluster/kube-controller-manager
sys-cluster/kubectl
sys-cluster/kubelet
sys-cluster/kube-proxy
sys-cluster/kube-scheduler

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs (aerc, vagrant, rust utils and others)

2020-07-11 Thread William Hubbs
On Fri, Jul 10, 2020 at 11:04:20PM -0700, Georgy Yakovlev wrote:
> Hello People,
> 
> The following packages are up for grabs:
> 
> mail-client/aerc | go package, great upstream

I'm interested in this one, so I'll add myself.

William



signature.asc
Description: PGP signature


[gentoo-dev] rfc: script to migrate to usr merged layout

2020-07-03 Thread William Hubbs
Hey all,

I am hearing that there is interest from users in the usr merge layout
(turning off the split-usr use flag) on their systems.

You can't really do this on a live system without migrating your system
to the new layout. I wrote a script a while back that attempts this, but I
haven't packaged it yet because I'm not sure how safe it is.

I will attach the script here before I package it.

Any comments or suggestions for this would be very helpful.

Thanks,

William

#!/bin/bb

is_internal()
{
[ -z "$1" ] && return 1
case $(command -v $1) in
*/*) rc=1 ;;
*) rc=0 ;;
esac
return $rc
}

run_command()
{
local dry_run
[ $DRYRUN -eq 1 ] && dry_run=echo
$dry_run "$@"
}

DRYRUN=1
HELP=0
while [ $# -gt 0 ]; do
case $1 in
-d|--dryrun|--dry-run) DRYRUN=1 ;;
-h|--help) HELP=1 ;;
esac
shift
done

if [ $HELP -eq 1 ]; then
echo "$(basename $0) -h \| --help - displays this message"
echo "$(basename $0) --dryrun \| --dry-run  - show what would be done"
exit 0
fi

for cmd in cp ln; do
if ! is_internal $cmd; then
echo "Please rebuild busybox and include the $cmd command"
exit 1
fi
done

if [ -L /bin -a -L /sbin ]; then
echo "It appears that the /usr merge has already been done on this 
system."
exit 0
fi

# copy binaries
for dir in /bin /sbin /usr/sbin; do
run_command cp -a $dir/* /usr/bin
done

# copy libraries
for dir in /lib*; do
[ -L $dir ] && continue
run_command cp -a $dir/* /usr$dir
done

# Create the /usr merge compatibility symlinks
for dir in /bin /sbin; do
run_command rm -rf $dir
run_command ln -s usr/bin $dir
done
run_command rm -rf /usr/sbin
run_command ln -s bin /usr/sbin
for dir in /lib*; do
run_command rm -rf $dir
run_command ln -s usr$dir $dir
done


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

2020-06-27 Thread William Hubbs
On Sun, Jun 21, 2020 at 10:02:25PM +0200, Andreas Sturmlechner wrote:
> On Sunday, 21 June 2020 21:27:02 CEST Joonas Niilola wrote:
> > What's the current trend of attaching news items? It
> > makes hard to point out enhancements.
> 
> Indeed, I didn't even look at the previous mail that was sent like that.

I realize I'm late to this and maybe this is being discussed in another
thread (I'm catching up), but attaching newsitems is the standard way of
getting them reviewed; this is not anything new.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-06-12 Thread William Hubbs
All,

this patch is being committed today.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: adding GOPATH to ENV_UNSET in base profile

2020-06-06 Thread William Hubbs
On Mon, Jun 01, 2020 at 04:31:16PM +0200, Rafael Goncalves Martins wrote:
> On Sun, May 31, 2020 at 9:06 PM William Hubbs  wrote:
> 
> > All,
> >
> > The GOPATH variable has similar issues to GOBIN [1], so I would like to
> > add it along side GOBIN to ENV_UNSET in the base profile.
> >
> > The message link below is only there for reference, but I see ebuilds
> > unsetting GOPATH in the tree and this would take care of it across all
> > of the tree.
> >
> > Thoughts?
> >
> >
> We need this. Anyone developing go software with GOPATH explicitly set will
> hit issues like this when installing a package using go-module.eclass, at
> least:
> 
> verifying github.com/mitchellh/go-homedir@v1.1.0: open
> /home/rafael/dev/git/go/pkg/mod/cache/download/
> github.com/mitchellh/go-homedir/@v/v1.1.0.ziphash: permission denied

This is done.

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] rfc: adding GOPATH to ENV_UNSET in base profile

2020-05-31 Thread William Hubbs
All,

The GOPATH variable has similar issues to GOBIN [1], so I would like to
add it along side GOBIN to ENV_UNSET in the base profile.

The message link below is only there for reference, but I see ebuilds
unsetting GOPATH in the tree and this would take care of it across all
of the tree.

Thoughts?

Thanks,

William

[1] 
https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0


signature.asc
Description: PGP signature


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-31 Thread William Hubbs
On Fri, May 29, 2020 at 04:34:24PM -0700, Alec Warner wrote:
> Another major issue is operating the software. I haven't found anyone to
> *run* gitlab; I'm not eager to do it. Today Gentoo is mostly distributed,
> bugs are in bugzilla, wiki is on mediawiki, code is on gitolite with N
> mirrors, email and lists are separate, etc. In a world where bugs, wiki,
> code, ci, containers, PRs, are all on gitlab and it breaks and we can't fix
> it; it will be bad news for all of those things. If the bugzilla machine
> breaks we lose bugzilla; if gitlab breaks we lose the ability to edit the
> wiki, file bugs, commit, run CI, etc.

Ping me sometime this week if I don't catch up with you first. I have
some experience running gitlab, so I could help run it.

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: checking properties in ebuilds and eclasses

2020-05-18 Thread William Hubbs
On Mon, May 18, 2020 at 09:42:46PM +0200, Michał Górny wrote:
> Why would an ebuild have to check whether the ebuild is live?  Isn't it
> supposed to know that by definition?
 
 See below where I talk about the ebuild version.

> > The up side of this would be that we aren't reserving a specific version
> > number for live ebuilds.
> 
> We aren't.

In practice we basically do. If an ebuild has version number , that
version is considered a live ebuild.
 
 I suppose this brings up the question of one ebuild serving as release
 and live ebuilds.

I've written a number of ebuilds like this because it seems easier to
keep things in sync if you do this. I'm guessing others have done the
same also.

If I remember correctly you are not comfortable with ebuilds like this and I'm
not quite sure why.

> > The down side that is being pointed out to me right now is that
> > we would need a function like in_iuse, but called in_properties, to
> > check the properties. We would need something like this because
> > properties supports use conditionals, e.g.
> > PROPERTIES="foo? ( bar )"
> 
> No, that's not why we needed in_iuse.  We need IUSE because IUSE is
> stacked and there's no guarantee that its value will be correct (or even
> present) at an arbitrary time during ebuild execution.
> 
> in_iuse does not handle USE conditionals because obviously there are
> none in IUSE.
> 
> PROPERTIES isn't stacked at the moment but there is a proposition to
> make it stacked in EAPI 8 for better consistency.  Right now it is easy
> to wrongly assume it is stacked and accidentally override it.

Is RESTRICT part of that proposal? It would be nice to have it
stacked as well.

Thanks,

William

> 
> -- 
> Best regards,
> Michał Górny
> 




signature.asc
Description: PGP signature


[gentoo-dev] rfc: checking properties in ebuilds and eclasses

2020-05-18 Thread William Hubbs
All,

I would like to start a discussion on checking the PROPERTIES value in
ebuilds. Specifically this could be used to check for live ebuilds
instead of assuming that the version number of an ebuild indicates
whether the ebuild is live.

The up side of this would be that we aren't reserving a specific version
number for live ebuilds.

The down side that is being pointed out to me right now is that
we would need a function like in_iuse, but called in_properties, to
check the properties. We would need something like this because
properties supports use conditionals, e.g.
PROPERTIES="foo? ( bar )"

I suppose another downside (and I do this, so I would have to adapt) is
that you couldn't really use one ebuild for a release and a live ebuild
at the same time any longer.A

Does anyone else have any thoughts about this?

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] rfc: $PROPERTIES, $FEATURES and pms

2020-05-17 Thread William Hubbs
All,

I have been acting as a backup maintainer for dev-vcs/cli. A pull
request was opened today that changes the way we detect whether the
ebuild is live from looking for "live" in $PROPERTIES to the version
number [1].

A different dev referred me to PMS which indicates that ebuilds should
not rely on $PROPERTIES for anything [2].

I see quite a few ebuilds in the tree checking $FEATURES however, which
imo is even less reliable since $FEATURES is not specified anywhere in pms
and the $FEATURES variable is portage-specific.

I guess I'm looking for consistency. If we are going to allow
$FEATURES to be checked, should we allow $PROPERTIES to be checked? Or,
should we ban checking both of them?

IMO if we allow $FEATURES to be checked, we really should reword PMS to
not say anything about $PROPERTIES other than to define the tokens it
can contain.

Thoughts?

William

[1] https://github.com/gentoo/gentoo/pull/15851
[2] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-670007.3.5


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-12 Thread William Hubbs
On Tue, May 12, 2020 at 11:41:45AM +0100, Samuel Bernardo wrote:
> Hi William,
> 
> How about overlays using the eclass, will this changes only apply to EAPI 8?
 
 Hi Samuel,

 this change will apply to all users of the eclass.

 Overlays are not considered blockers for in-tree eclass work.

Also, keepin mind that there was a qa warning in place for this issue
for 3 months, so overlay owners should have been able to see that and
migrate their ebuilds to EGO_SUM.

 That being said, if any overlay owner would like my assistance with
 migrating their ebuilds, I have no problem with showing them how.

 Thanks,

 William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-12 Thread William Hubbs
On Mon, May 11, 2020 at 10:47:23PM -0700, Matt Turner wrote:
> On Mon, May 11, 2020 at 4:00 PM William Hubbs  wrote:
> >
> > On Tue, May 12, 2020 at 01:45:45AM +0300, Andreas K. Hüttel wrote:
> > > > This patch makes migrating mandatory by forcing ebuilds to die if they
> > > > have EGO_VENDOR set and are using go-module.eclass.
> > >
> > > You can't commit this as long as there is a single such ebuild in the 
> > > tree.
> >
> > Sure, and I'm working on migrating them.
> 
> I think all the replies to this thread could have been avoided by just
> saying that in your initial email. :)

I didn't have a problem with what dilfridge said or even with the list
of points floppym came up with. My issue was more with the tone of
floppym's reply, and that has been resolved. :-)

William



signature.asc
Description: PGP signature


[gentoo-dev] last rites: dev-go/go-protobuf

2020-05-11 Thread William Hubbs
# William Hubbs  (2020-05-11)
# No reverse dependencies, upstream has superseeded this with the
# ggoogle.golang.org/protobuf module.
# Removal in 30 days. Bug #722542.
dev-go/go-protobuf

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-11 Thread William Hubbs
On Tue, May 12, 2020 at 01:45:45AM +0300, Andreas K. Hüttel wrote:
> > This patch makes migrating mandatory by forcing ebuilds to die if they
> > have EGO_VENDOR set and are using go-module.eclass.
> 
> You can't commit this as long as there is a single such ebuild in the tree. 

Sure, and I'm working on migrating them.

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-11 Thread William Hubbs
On Mon, May 11, 2020 at 09:51:45AM -0400, Mike Gilbert wrote:
> On Sun, May 10, 2020 at 5:16 PM William Hubbs  wrote:
> >
> > All,
> >
> > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from
> > go-module.eclass.
> >
> > This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> > warning advising people to migrate their ebuilds to EGO_SUM.
> >
> > This patch makes migrating mandatory by forcing ebuilds to die if they
> > have EGO_VENDOR set and are using go-module.eclass.
> >
> > Thoughts?
> 
> It seems like you're being very lazy about this. At a minimum, you
> should do the following:
 
I will respond to your points below, but first, I take offense to your
accusation of me being lazy especially since it seems pretty obvious you
didn't attempt to research my work before you said it.

> 1. Search for affected packages.

Done.

> 2. Contact the maintainers, possibly via bug reports.

Already done. If you look at the packages I have been doing this conversion for
so far, you would see that most of them are maintained by myself, zac or
not maintained at all.

> 3. Give them a some time to convert their packages.

No one has had issues with me doing the work myself, so that is what has
been happening. Also, keep in mind that there was a public announcement
made on this list about migrating go packages to the go-module eclass,
and no one spoke out then against it.

> 4. Mask any packages that do not get updated.

There's only one I have masked so far and that was per the maintainer. I
did post the lastrites but it looks like I need to forward it to -dev or
re-post it, I will take a look again after I respond to this message.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-11 Thread William Hubbs
On Mon, May 11, 2020 at 06:13:19PM +0200, David Seifert wrote:
> On Mon, 2020-05-11 at 09:51 -0400, Mike Gilbert wrote:
> > On Sun, May 10, 2020 at 5:16 PM William Hubbs 
> > wrote:
> > > All,
> > > 
> > > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR
> > > support from
> > > go-module.eclass.
> > > 
> > > This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> > > warning advising people to migrate their ebuilds to EGO_SUM.
> > > 
> > > This patch makes migrating mandatory by forcing ebuilds to die if
> > > they
> > > have EGO_VENDOR set and are using go-module.eclass.
> > > 
> > > Thoughts?
> > 
> > It seems like you're being very lazy about this. At a minimum, you
> > should do the following:
> > 
> > 1. Search for affected packages.
> > 2. Contact the maintainers, possibly via bug reports.
> > 3. Give them a some time to convert their packages.
> > 4. Mask any packages that do not get updated.
> > 
> 
> Wow, and python changing one line in its implementation details is
> breaking the world, whereas there's still a ton of users of EGO_VENDOR
> in the tree?

I'm looking at a specific combination at this point. The ebuilds I'm
looking at inherit go-module *and* use EGO_VENDOR. Most of these have
already been fixed because I have permission from the maintainers to
work on them or I am the maintainer.

The hard part is going to be the work of migrating ebuilds that inherit
golang-* and use EGO_VENDOR over to go-module. That will take work with
upstreams in some cases to make it happen.

William



signature.asc
Description: PGP signature


[gentoo-dev] [PATCH 1/1] eclass/go-module.eclass: remove EGO_VENDOR support

2020-05-10 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 81 +++--
 1 file changed, 6 insertions(+), 75 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 17d37494f15..7b66c3e2b1e 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -120,29 +120,6 @@ EXPORT_FUNCTIONS src_unpack pkg_postinst
 # This decision  does NOT weaken Go module security, as Go will verify the
 # go.sum copy of the Hash1 values during building of the package.
 
-# @ECLASS-VARIABLE: EGO_VENDOR
-# @DESCRIPTION:
-# This variable is deprecated and should no longer be used. Please
-# convert your ebuilds to use EGO_SUM.
-
-# @FUNCTION: go-module_vendor_uris
-# @DESCRIPTION:
-# This function is deprecated.
-go-module_vendor_uris() {
-   local hash import line repo x
-   for line in "${EGO_VENDOR[@]}"; do
-   read -r import hash repo x <<< "${line}"
-   if [[ -n ${x} ]]; then
-   eerror "Trailing information in EGO_VENDOR in 
${P}.ebuild"
-   eerror "${line}"
-   eerror "Trailing information is: \"${x}\""
-   die "Invalid EGO_VENDOR format"
-   fi
-   : "${repo:=${import}}"
-   echo "https://${repo}/archive/${hash}.tar.gz -> 
${repo//\//-}-${hash}.tar.gz"
-   done
-}
-
 # @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
 # @DESCRIPTION:
 # Golang module proxy service to fetch module files from. Note that the module
@@ -261,17 +238,16 @@ go-module_set_globals() {
 
 # @FUNCTION: go-module_src_unpack
 # @DESCRIPTION:
-# - If EGO_VENDOR is set, use the deprecated function to unpack the base
-#   tarballs and the tarballs indicated in EGO_VENDOR to the correct
-#   locations.
-# - Otherwise, if EGO_SUM is set, unpack the base tarball(s) and set up the
+# If EGO_SUM is set, unpack the base tarball(s) and set up the
 #   local go proxy.
+# - Otherwise, if EGO_VENDOR is set, bail out.
 # - Otherwise do a normal unpack.
 go-module_src_unpack() {
-   if [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
-   _go-module_src_unpack_vendor
-   elif [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
+   if [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
_go-module_src_unpack_gosum
+   elif [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
+   eerror "${EBUILD} is using EGO_VENDOR which is no longer 
supported"
+   die "Please update this ebuild"
else
default
fi
@@ -350,51 +326,6 @@ _go-module_gosum_synthesize_files() {
fi
 }
 
-# @FUNCTION: _go-module_src_unpack_vendor
-# @DESCRIPTION:
-# Extract all archives in ${a} which are not nentioned in ${EGO_VENDOR}
-# to their usual locations then extract all archives mentioned in
-# ${EGO_VENDOR} to ${S}/vendor.
-_go-module_src_unpack_vendor() {
-   # shellcheck disable=SC2120
-   debug-print-function "${FUNCNAME}" "$@"
-   local f hash import line repo tarball vendor_tarballs x
-   vendor_tarballs=()
-   for line in "${EGO_VENDOR[@]}"; do
-   read -r import hash repo x <<< "${line}"
-   if [[ -n ${x} ]]; then
-   eerror "Trailing information in EGO_VENDOR in 
${P}.ebuild"
-   eerror "${line}"
-   die "Invalid EGO_VENDOR format"
-   fi
-   : "${repo:=${import}}"
-   vendor_tarballs+=("${repo//\//-}-${hash}.tar.gz")
-   done
-   for f in ${A}; do
-   [[ -n ${vendor_tarballs[*]} ]] && has "${f}" 
"${vendor_tarballs[@]}" &&
-   continue
-   unpack "${f}"
-   done
-
-   [[ -z ${vendor_tarballs[*]} ]] && return
-   for line in "${EGO_VENDOR[@]}"; do
-   read -r import hash repo _ <<< "${line}"
-   : "${repo:=${import}}"
-   tarball=${repo//\//-}-${hash}.tar.gz
-   ebegin "Vendoring ${import} ${tarball}"
-   rm -fr "${S}/vendor/${import}" || die
-   mkdir -p "${S}/vendor/${import}" || die
-   tar -C "${S}/vendor/${import}" -x --strip-components 1 \
-   -f "${DISTDIR}/${tarball}" || die
-   eend
-   done
-   # replace GOFLAGS if EGO_VENDOR is being used
-   [[ ${#EGO_VENDOR[@]} -gt 0 ]] &&
-   GOFLAGS="-v -x -mod=vendor"
-   eqawarn "${P}.ebuild: EGO_VENDOR will be removed in the future."
-   eqawarn "Please request that the author migrate to EGO_SUM."
-}
-
 # @FUNCTION: _go-module_src_unpack_verify_gosum
 # @DESCRIPTION:
 # Validate the Go modules declared by EGO_SUM are sufficient to cover building
-- 
2.26.2




[gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-10 Thread William Hubbs
All,

now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from
go-module.eclass.

This was kept when the EGO_SUM support was added on 4 Mar, with a qa
warning advising people to migrate their ebuilds to EGO_SUM.

This patch makes migrating mandatory by forcing ebuilds to die if they
have EGO_VENDOR set and are using go-module.eclass.

Thoughts?

William Hubbs (1):
  eclass/go-module.eclass: remove EGO_VENDOR support

 eclass/go-module.eclass | 81 +++--
 1 file changed, 6 insertions(+), 75 deletions(-)

-- 
2.26.2




[gentoo-dev] rfc: "emerge --sync" vs "emaint sync"

2020-05-06 Thread William Hubbs
All,

I know that most of our documentation tells people to use "emerge --sync";
however, today I heard about "emaint sync" for the first time.  ;-)

Which one should we use? Will there be a phase-out for "emerge --sync" or
"emaint sync"? Are the plans to keep both available?

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-21 Thread William Hubbs
On Tue, Apr 21, 2020 at 07:50:13AM +0200, Michał Górny wrote:
> On Mon, 2020-04-20 at 16:04 -0500, William Hubbs wrote:
> > Your proposal seems to completely go against how the go ecosystem operates,
> > but if you can come up with a proof-of-concept for how it would work
> > without forcing a lot of busy work on us that would never get accepted
> > upstream, I'll take a look.
> > 
> 
> Define 'busy work'.
 
 Busy work, to me at least, is work that generates a large amount of
overhead compared to the gain it offers the distro and will never be
accepted by upstream.

> Is doing things right 'busy work' vs taking shortcuts?

This depends on what you think "doing things right" or "taking
shortcuts" mean. For example, I have had discussions with maintainers who
are fine with writing patches to fix issues without reporting the issues
upstream. Personally, I disagree with this approach.

> Is it 'busy
> work' that I'm putting a lot of effort into fixing Python packages? 
> Should I just last rite them all and tell people to use virtualenv?
 
This gets into the other issue being discussed on the thread, but I have
heard people say that yes you should. All we really need in portage is
the base python tools -- the language, maybe pip and maybe setuptools
and portage itself, then everything else should be installed via pip.

> Is testing packages 'busy work'?  I suppose it's all easier when you
> just silently include 240 dependencies without testing a single one of
> them and call it a day.  Sure, you run some tests on the final package. 
> Leaves 240 untested, some of them likely failing tests and requiring
> 'busy work' to fix them.
 
In general I would say no, but I have run into tests that do not tollerate
portage's sandbox, tests that take hours or days to run, or tests that
require root privs. We don't force those kinds of tests to be run in src_test.

> Is security support 'busy work'?  I suppose it's all easier when you
> ignore them problem and let security team deal with it (except they
> won't).  Sure, you can assume that when vulnerability is discovered, all
> upstreams will eventually learn of it, update their bundled dependencies
> and *maybe* inform people that their code might have been indirectly
> vulnerable (but would they do the 'busy work' of discovering whether it
> affected them or not?).
 
In my experience, the security team doesn't write patches to fix
vulnerabilities, so what they do wouldn't be any different in this case.

> I realize Go is not isolated here.  It's just brought as one major
> example.  Rust is no better.  All these shiny 'write and forget'
> languages share the same problem.  Pay for some work hours, get
> a working product, deploy it and forget unless customers want more
> features.
> 
> Today these languages are still young and the problems can be considered
> largely theoretical.  But some day -- well, unless all the cool kids
> manage to move on to next shiny new language before then -- this will be
> a major catastrophe.

We can talk about theoretical issues in languages all day, but if we are
going to do that we also have to talk about how terrible and permissive
c is. You can google things like "security in c" and you will find that
since it allows you to do exactly what you want, it is a major
catastrophe in terms of security, but we accept new applications in c
without any questions.

Also, what about the nightmare that is php?

In short, I don't see any reason to bikeshed about theoretical issues in
languages.

The way I see Go and Rust specifically is, more and more things are
being written in these languages, and if we don't accept them, we will
become irrelivent fast.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread William Hubbs
On Mon, Apr 20, 2020 at 03:23:15PM -0400, Michael Orlitzky wrote:
> > Are you volunteering to do the work to package go packages? The people 
> > doing the work generally get to decide how that work gets done, and which 
> > approach they would like to take. The upstream situation makes it very 
> > labour-intensive to do the work in a the way you are proposing (many 
> > packages would end up with hundreds to thousands of packages in the tree). 
> > Separating everything out in to separate packages will just increase the 
> > maintenance load exponentially, with no gains as go upstreams version lock 
> > all their dependencies.
> > 
> 
> I'm volunteering to work on one or two small Go packages. Can I convert
> the eclass to use dynamic linking? Can I start replacing your packages
> with my own if I need them as dependencies? I suspect not, and that's
> one of many reasons why "having things in ::gentoo does not affect
> anyone who does not use them" is bullshit.

As one of the maintainers of the go-module eclass, I'm all ears, but
keep a couple of things in mind.

First, I have yet to see an upstream go-based build system that uses
dynamic linking for go libraries. No one does it. they all statically
link everything. This alone probably means you'll have to patch every
upstream build system you find.

Another issue is the sheer number of dependencies that a single go
package would pull into the tree. 
For example, dev-vcs/cli-0.6.3, which looks  like a small enough
package, has 65 dependencies. sys-apps/kubernetes-1.18.2, a bigger package for
sure, has 246. So, the worst case you are looking at here is over 300
dependencies, and this is just for two packages. The only way this
number would come down is if these packages happened to share exact
dependencies since you can't really unlock the versions.

and, yes, gccgo is out there, but no one writes for it. I have yet
to see an upstream that supports using it. So, if you go that route,
you are looking at patching build systems.

Your proposal seems to completely go against how the go ecosystem operates,
but if you can come up with a proof-of-concept for how it would work
without forcing a lot of busy work on us that would never get accepted
upstream, I'll take a look.

William




[gentoo-dev] newsitem: k8s moving to a single package

2020-03-31 Thread William Hubbs
Title: K8s Moving to a Single Package
Author: William Hubbs 
Posted: 2020-04-03
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-cluster/kubeadm
Display-If-Installed: sys-cluster/kube-apiserver
Display-If-Installed: sys-cluster/kube-controller-manager
Display-If-Installed: sys-cluster/kubectl
Display-If-Installed: sys-cluster/kubelet
Display-If-Installed: sys-cluster/kube-proxy
Display-If-Installed: sys-cluster/kube-scheduler

Formerly, we packaged kubernetes as seven separate packages:

sys-cluster/kubeadm, sys-cluster/kube-apiserver,
sys-cluster/kube-controller-manager, sys-cluster/kubectl,
sys-cluster/kubelet, sys-cluster/kube-proxy and
sys-cluster/kube-scheduler.

Starting with kubernetes 1.18.0, 1.17.5 and 1.16.9, these will be merged
into one package, sys-cluster/kubernetes. The components of this package
which are build and installed will be selectable by use flags.

If you are using 1.16.x or 1.17.x and would like to migrate to the
single package without upgrading, I have also made 1.16.8 and 1.17.4
available in this new package.

Currently, everything is built and installed by default; however, I am
open to changing this if there is a better way to configure the default
build.


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-27 Thread William Hubbs
On Fri, Mar 27, 2020 at 06:54:25AM +0100, Michał Górny wrote:
> On Thu, 2020-03-26 at 22:12 +0100, Ulrich Mueller wrote:
> > > > > > > On Thu, 26 Mar 2020, William Hubbs wrote:
> > >  If there's a way inside an eclass to check that the ebuild inheriting
> > > it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
> > > and this variable is set.
> > 
> > Oh please, not this again. An ebuild or eclass is supposed to work the
> > same everywhere, independent of the repo it is located in.
> > 
> > Why don't you simply copy the eclass to your overlay and do the changes
> > there?
> > 
> 
> They did, and then they complained that every few months they have to
> update it.  See the big slander mail from William.

Michal,

I already responded here on the list and apologized for the way I
presented the original issues.

So, I would appreciate it if you drop the slander accusation.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread William Hubbs
On Thu, Mar 26, 2020 at 08:37:17PM +0100, David Seifert wrote:

*snip*

> How do you prevent some extra clever Gentoo developer from doing the following
> in ::gentoo
> 
>   dev-python/foo/foo-1.ebuild:
> 
>   # don't have the time to port this right now, patches welcome
>   PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 )
>   PYTHON_COMPAT=( python3_4 )
>   inherit distutils-r1
 
 If there's a way inside an eclass to check that the ebuild inheriting
it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
and this variable is set.

> Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break 
> metadata
> invariance, causing tons of cache mis-hits. How do you prevent that?
> 
> In addition, this will very quickly cause whatever overlay this is being used 
> in
> to become invalid. Imagine I have dev-python/foo::gentoo that supports python
> 3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a
> hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove
> python 3.4 from ::gentoo in python-utils-r1, and one week later we remove
> python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev-
> python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an
> invalid depgraph. How do you wish to resolve this?

These are both overlay maintenance questions that wouldn't affect
::gentoo, but the answer to the first one is we regenerate the metadata
very often so it wouldn't be an issue, and the second one is  resolved
by grabbing packages and putting them in another overlay until we don't
need them.

> I feel like keeping up with ::gentoo is ultimately the better strategy than
> trying to add backdoors to eclasses because some overlays are somewhat behind.
 
I agree with you. However, sometimes in the real world it doesn't work
that way, or it can take longer to move than Gentoo.

If we can do something minimal to allow downstream overlays to do what
they need to do to catch up, I think we should, especially if someone
from downstream is offering to do the work.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread William Hubbs
On Thu, Mar 26, 2020 at 03:37:48PM -0400, Mike Gilbert wrote:
> On Thu, Mar 26, 2020 at 3:13 PM William Hubbs  wrote:
> >
> > This variable is meant to be set in downstream overlays when they need 
> > python
> > implementations other than the ones we support in the tree.
> > It should be a space-separated list of extra implementations.
> 
> This new variable should be documented in the eclass, along with a
> note that its use is unsupported for general use.
>
> Do you intend this variable to be set in profiles or make.conf? In
> either case, I don't think you can use bash arrays. Also, you're
> mixing scalar and array variable syntax in your patch.

Sure, I can do that. I'll fix up the syntax and add the documentation.

Thanks,

William



signature.asc
Description: Digital signature


[gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread William Hubbs
This variable is meant to be set in downstream overlays when they need python
implementations other than the ones we support in the tree.
It should be a space-separated list of extra implementations.

Signed-off-by: William Hubbs 
---
 eclass/python-utils-r1.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..4370c7a825f 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -43,6 +43,8 @@ _PYTHON_ALL_IMPLS=(
python2_7
python3_6 python3_7 python3_8
 )
+[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&
+   _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
 readonly _PYTHON_ALL_IMPLS
 
 # @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-- 
2.24.1




[gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread William Hubbs
There are situations in which downstream overlays need to have versions
of python which Gentoo no longer supports in the tree.

Currently, the only way to do this is for the overlay author to fork
python-utils-r1.eclass. This is highly undesirable since it creates a
very significant maintenance burden for the overlay author.

There are a couple of things we can do upstream to make this easier, and
I think we should do one of them.

The simplest way would be to apply the following patch.
In this situation, all the overlay author
would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.

The other option would be to move _PYTHON_ALL_IMPLS and  the
implementation of _python_impl_supported to a separate eclass, e.g.
python-impls-r1.eclass. This eclass could be forked freely downstream
without worrying about the other python eclasses.
I will volunteer to do the legwork for this option if we do not like the
first one.

I would advocate the first option however since no one has to fork
anything.

Thoughts?

William

William Hubbs (1):
  python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

 eclass/python-utils-r1.eclass | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.24.1




Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-26 Thread William Hubbs
On Wed, Mar 25, 2020 at 10:29:23AM +0100, Michał Górny wrote:
> William,
> 
> So many things are wrong with this e-mail, I'm not even sure where to
> start.  In my opinion, this mail shouldn't have ever happened.  While
> I believe you had a good intent, this does not justify sending such
> mails without verifying your claims first.

I apologize for being vague in my initial email about what
my claims were. It would have been better to link the changes up front
instead of later in the thread and give more information about what was
broken, and I will do this next time around.

Also, I do agree that cc'ing QA and the council was overkill for an
rfc message.

I hope we can move on from this thread. Let me know what you think.

From my pov, the incident that prompted this highlights some concerns about
our eclass patch handling process, so expect a separate thread from me
soon about this process.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread William Hubbs
On Mon, Mar 23, 2020 at 08:19:20PM +0100, Michał Górny wrote:
> On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> > Hey all,
> > 
> > it has been brought to my attention that there have been several
> > backward-incompatible changes made to the python eclasses lately.
> 
> Does 'several' in this case mean more than one?  Please correct me if
> I'm mistaken but the only change I can think of were the changes
> in python-single-r1.
> 
> > It is true that everything in ::gentoo has been fixed along with the
> > changes to the eclasses; however, when a change like this goes into a
> > widely used eclass it breaks overlays with little to no notice;
> > especially since we do not require developers to be subscribed to this
> > mailing list.
> > 
> > I do agree that overlay authors are on their own to fix things, but we need 
> > to
> > find a way to notify them when a breaking change is going into a widely
> > used eclass and give them time to adjust their ebuilds.
> > 
> > If the old way of doing things cannot be supported
> > along side the new way the correct path forward is a new version of the
> > eclass then a lastrites on the old version. That would give overlay
> > authors time to switch to the new eclass.
> > 
> > If the old and new way can be supported in the same code base, a
> > reasonable way forward is to  allow both ways to exist while ::gentoo is
> > migrated to the new code path then do the equivalent of a lastrites for
> > the old code path so overlay authors can adjust their ebuilds.
> > 
> 
> The lesson was learned.  If a similar change would be necessary
> in the future, I will bump the eclass instead.  I don't understand why
> you bring that today.

The change that blew us up today was

https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258

and this is the reason I brought it to the ml.

The previous change that blew us up was

https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread William Hubbs
On Mon, Mar 23, 2020 at 02:14:06PM -0500, William Hubbs wrote:
> On Mon, Mar 23, 2020 at 08:03:47PM +0100, David Seifert wrote:
> > On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote:
> > > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote:
> > > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> > > > > Hey all,
> > > > > 
> > > > > it has been brought to my attention that there have been several
> > > > > backward-incompatible changes made to the python eclasses lately.
> > > > > 
> > > > > It is true that everything in ::gentoo has been fixed along with the
> > > > > changes to the eclasses; however, when a change like this goes into a
> > > > > widely used eclass it breaks overlays with little to no notice;
> > > > > especially since we do not require developers to be subscribed to this
> > > > > mailing list.
> > > > > 
> > > > > I do agree that overlay authors are on their own to fix things, but we
> > > > > need to
> > > > > find a way to notify them when a breaking change is going into a 
> > > > > widely
> > > > > used eclass and give them time to adjust their ebuilds.
> > > > > 
> > > > > If the old way of doing things cannot be supported
> > > > > along side the new way the correct path forward is a new version of 
> > > > > the
> > > > > eclass then a lastrites on the old version. That would give overlay
> > > > > authors time to switch to the new eclass.
> > > > > 
> > > > > If the old and new way can be supported in the same code base, a
> > > > > reasonable way forward is to  allow both ways to exist while ::gentoo 
> > > > > is
> > > > > migrated to the new code path then do the equivalent of a lastrites 
> > > > > for
> > > > > the old code path so overlay authors can adjust their ebuilds.
> > > > > 
> > > > > Thoughts?
> > > > > 
> > > > > William
> > > > > 
> > > > 
> > > > All of this was announced with a 3 month timeout, using the right 
> > > > channels.
> > > > Have
> > > > you checked all python-related eclasses changes submitted to the ML? In 
> > > > this
> > > > case, eqawarn would not have been possible, because the change involved
> > > > dereferencing a variable.
> > > 
> > > This is the change that broke us today.
> > > 
> > > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
> > > 
> > > Where is the three month timeout for it?
> > > 
> > > Thanks,
> > > 
> > > William
> > > 
> > 
> > Oh I thought you meant the python-single-r1 change from a month ago.
> 
> The other one that is being pointed out to me is this one:
> 
> https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871
> 
> Is that the python-single-r1 change you were talking about?
> 
> If it is, what do we consider the appropriate channels for api change
> announcements to be?

Sorry about sending too quickly on this message.

We have mostly fixed this one by now.

Thanks,

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread William Hubbs
On Mon, Mar 23, 2020 at 08:03:47PM +0100, David Seifert wrote:
> On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote:
> > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote:
> > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> > > > Hey all,
> > > > 
> > > > it has been brought to my attention that there have been several
> > > > backward-incompatible changes made to the python eclasses lately.
> > > > 
> > > > It is true that everything in ::gentoo has been fixed along with the
> > > > changes to the eclasses; however, when a change like this goes into a
> > > > widely used eclass it breaks overlays with little to no notice;
> > > > especially since we do not require developers to be subscribed to this
> > > > mailing list.
> > > > 
> > > > I do agree that overlay authors are on their own to fix things, but we
> > > > need to
> > > > find a way to notify them when a breaking change is going into a widely
> > > > used eclass and give them time to adjust their ebuilds.
> > > > 
> > > > If the old way of doing things cannot be supported
> > > > along side the new way the correct path forward is a new version of the
> > > > eclass then a lastrites on the old version. That would give overlay
> > > > authors time to switch to the new eclass.
> > > > 
> > > > If the old and new way can be supported in the same code base, a
> > > > reasonable way forward is to  allow both ways to exist while ::gentoo is
> > > > migrated to the new code path then do the equivalent of a lastrites for
> > > > the old code path so overlay authors can adjust their ebuilds.
> > > > 
> > > > Thoughts?
> > > > 
> > > > William
> > > > 
> > > 
> > > All of this was announced with a 3 month timeout, using the right 
> > > channels.
> > > Have
> > > you checked all python-related eclasses changes submitted to the ML? In 
> > > this
> > > case, eqawarn would not have been possible, because the change involved
> > > dereferencing a variable.
> > 
> > This is the change that broke us today.
> > 
> > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
> > 
> > Where is the three month timeout for it?
> > 
> > Thanks,
> > 
> > William
> > 
> 
> Oh I thought you meant the python-single-r1 change from a month ago.

The other one that is being pointed out to me is this one:

https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871

Is that the python-single-r1 change you were talking about?

If it is, what do we consider the appropriate channels for api change
announcements to be?

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread William Hubbs
On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote:
> On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> > Hey all,
> > 
> > it has been brought to my attention that there have been several
> > backward-incompatible changes made to the python eclasses lately.
> > 
> > It is true that everything in ::gentoo has been fixed along with the
> > changes to the eclasses; however, when a change like this goes into a
> > widely used eclass it breaks overlays with little to no notice;
> > especially since we do not require developers to be subscribed to this
> > mailing list.
> > 
> > I do agree that overlay authors are on their own to fix things, but we need 
> > to
> > find a way to notify them when a breaking change is going into a widely
> > used eclass and give them time to adjust their ebuilds.
> > 
> > If the old way of doing things cannot be supported
> > along side the new way the correct path forward is a new version of the
> > eclass then a lastrites on the old version. That would give overlay
> > authors time to switch to the new eclass.
> > 
> > If the old and new way can be supported in the same code base, a
> > reasonable way forward is to  allow both ways to exist while ::gentoo is
> > migrated to the new code path then do the equivalent of a lastrites for
> > the old code path so overlay authors can adjust their ebuilds.
> > 
> > Thoughts?
> > 
> > William
> > 
> 
> All of this was announced with a 3 month timeout, using the right channels. 
> Have
> you checked all python-related eclasses changes submitted to the ML? In this
> case, eqawarn would not have been possible, because the change involved
> dereferencing a variable.

This is the change that broke us today.

https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258

Where is the three month timeout for it?

Thanks,

William



signature.asc
Description: Digital signature


[gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread William Hubbs
Hey all,

it has been brought to my attention that there have been several
backward-incompatible changes made to the python eclasses lately.

It is true that everything in ::gentoo has been fixed along with the
changes to the eclasses; however, when a change like this goes into a
widely used eclass it breaks overlays with little to no notice;
especially since we do not require developers to be subscribed to this
mailing list.

I do agree that overlay authors are on their own to fix things, but we need to
find a way to notify them when a breaking change is going into a widely
used eclass and give them time to adjust their ebuilds.

If the old way of doing things cannot be supported
along side the new way the correct path forward is a new version of the
eclass then a lastrites on the old version. That would give overlay
authors time to switch to the new eclass.

If the old and new way can be supported in the same code base, a
reasonable way forward is to  allow both ways to exist while ::gentoo is
migrated to the new code path then do the equivalent of a lastrites for
the old code path so overlay authors can adjust their ebuilds.

Thoughts?

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-21 Thread William Hubbs
On Sat, Mar 21, 2020 at 11:22:40AM -0700, Alec Warner wrote:
> On Sat, Mar 21, 2020 at 1:03 AM Alexander Tsoy  wrote:
> 
> > В Сб, 21/03/2020 в 00:53 -0700, Matt Turner пишет:
> > > On Fri, Mar 20, 2020 at 9:55 PM Kent Fredric 
> > > wrote:
> > > > If X is "noarch" and its dependency Y is "amd64", then a user on
> > > > "sparc"
> > > > will be able to install "X", but not its dependency "Y".
> > >
> > > Thank you. This is a good explanation of the problem.
> > >
> > > How do other distributions handle this? Arch, Fedora, and Debian have
> > > "noarch" packages. Surely they've found a reasonable way to make this
> > > work.
> >
> > Binary distros usually have separate repositories for each
> > architecture.
> >
> 
> Pretty much this. There is not 1 repository, there are N. This means that
> if leaf package A "noarch" depends on package B (only stable on x86) then
> in the x86 tree, A and B will be available. In the sparc tree, B is not
> available and so A is uninstallable and also not available.
> 
> We had discussed doing this in the past but in practice we use a bunch of
> files to compute these boundaries on the fly and this is not particularly
> cheap in the current implementation.

This part of the thread has been the best explanation I've seen for why
this couldn't work for us, so I'm cool with this.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread William Hubbs
On Wed, Mar 18, 2020 at 07:12:08PM +0100, Michał Górny wrote:
> On Wed, 2020-03-18 at 12:47 -0500, William Hubbs wrote:
> > On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > > > this came up again on the recent thread about dropping non x86/amd64
> > > > support for python packages, and I want to bring it up again on its own
> > > > thread.
> > > > 
> > > > How often do architecture specific bugs really exist in languages like
> > > > perl, python etc? From what I've seen they are pretty rare. Not to 
> > > > mention,
> > > > if we found one somewhere, we could adjust keywords as necessary.
> > > > 
> > > > Also, if someone did inadvertently keyword a package with noarch that 
> > > > didn't
> > > > work everywhere, it would be a matter of adjusting the keywords for that
> > > > package.
> > > > 
> > > > So, my question is, why can't we add a noarch/~noarch keyword and see
> > > > how things go? If it gets abused we can always nuke it later.
> > > > 
> > > 
> > > 1. How is this going to work when noarch package depends on non-nonarch
> > > package?  I mean, will all the package managers actually work?  Have you
> > > did some minimal testing before bringing this up?
> >  
> > Can you have multiple ACCEPT_KEYWORDS values in make.conf or
> > make.defaults like this?
> > 
> >  ACCEPT_KEYWORDS="amd64 noarch"
> > 
> > If so, things should just work.
> > 
> > Currently I don't know of any arch/package combos to test this with.
> 
> I'm talking about repoman/pkgcheck.

See my response to chewi about this part. I have no idea how
much work would be involved in making this work.

> 
> > > 2. Who will be responsible for handling noarch stablereqs?  Will there
> > > be a noarch arch team?
> > 
> > The maintainer would be able to add the "~noarch" keyword. I'm not sure
> > there needs to be a noarch arch team. We could just say that all arch
> > team members can stabilize these or maybe the maintainers can afterh the
> > timeout.
> > 
> 
> Would you CC all arch teams on the bug then?
> 
> We have ALLARCHES already, and to my experience most arch teams fail to
> handle that.

There would be no need to cc all arches on the bug, just make noarch@g.o
an alias that emails to all arch teams.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread William Hubbs
On Wed, Mar 18, 2020 at 05:52:25PM +, James Le Cuirot wrote:
> On Wed, 18 Mar 2020 12:47:53 -0500
> William Hubbs  wrote:
> 
> > On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:  
> > > > this came up again on the recent thread about dropping non x86/amd64
> > > > support for python packages, and I want to bring it up again on its own
> > > > thread.
> > > > 
> > > > How often do architecture specific bugs really exist in languages like
> > > > perl, python etc? From what I've seen they are pretty rare. Not to 
> > > > mention,
> > > > if we found one somewhere, we could adjust keywords as necessary.
> > > > 
> > > > Also, if someone did inadvertently keyword a package with noarch that 
> > > > didn't
> > > > work everywhere, it would be a matter of adjusting the keywords for that
> > > > package.
> > > > 
> > > > So, my question is, why can't we add a noarch/~noarch keyword and see
> > > > how things go? If it gets abused we can always nuke it later.
> > > >   
> > > 
> > > 1. How is this going to work when noarch package depends on non-nonarch
> > > package?  I mean, will all the package managers actually work?  Have you
> > > did some minimal testing before bringing this up?  
> >  
> > Can you have multiple ACCEPT_KEYWORDS values in make.conf or
> > make.defaults like this?
> > 
> >  ACCEPT_KEYWORDS="amd64 noarch"
> > 
> > If so, things should just work.
> 
> Not quite. Tools like repoman will need to be updated to understand
> that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> only KEYWORDS="noarch". I do think the idea has merit though.

Ok, that's reasonable and generates more questions.

How much work would it be to update the tools to take that into account?

In the meantime, is it worth adding the noarch keyword but not dropping
other keywords until the tools are fixed?

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread William Hubbs
On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:
> > this came up again on the recent thread about dropping non x86/amd64
> > support for python packages, and I want to bring it up again on its own
> > thread.
> > 
> > How often do architecture specific bugs really exist in languages like
> > perl, python etc? From what I've seen they are pretty rare. Not to mention,
> > if we found one somewhere, we could adjust keywords as necessary.
> > 
> > Also, if someone did inadvertently keyword a package with noarch that didn't
> > work everywhere, it would be a matter of adjusting the keywords for that
> > package.
> > 
> > So, my question is, why can't we add a noarch/~noarch keyword and see
> > how things go? If it gets abused we can always nuke it later.
> > 
> 
> 1. How is this going to work when noarch package depends on non-nonarch
> package?  I mean, will all the package managers actually work?  Have you
> did some minimal testing before bringing this up?
 
Can you have multiple ACCEPT_KEYWORDS values in make.conf or
make.defaults like this?

 ACCEPT_KEYWORDS="amd64 noarch"

If so, things should just work.

Currently I don't know of any arch/package combos to test this with.

> 2. Who will be responsible for handling noarch stablereqs?  Will there
> be a noarch arch team?

The maintainer would be able to add the "~noarch" keyword. I'm not sure
there needs to be a noarch arch team. We could just say that all arch
team members can stabilize these or maybe the maintainers can afterh the
timeout.

William

> -- 
> Best regards,
> Michał Górny
> 




signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread William Hubbs
On Wed, Mar 18, 2020 at 05:11:17PM +0100, Rolf Eike Beer wrote:
> Am 2020-03-18 15:54, schrieb William Hubbs:
> > All,
> > 
> > this came up again on the recent thread about dropping non x86/amd64
> > support for python packages, and I want to bring it up again on its own
> > thread.
> > 
> > How often do architecture specific bugs really exist in languages like
> > perl, python etc? From what I've seen they are pretty rare. Not to 
> > mention,
> > if we found one somewhere, we could adjust keywords as necessary.
> 
> I'm not judging this proposal, just a data point: packages that e.g. 
> read from /proc, especially /proc/cpuinfo, get easily blow up on 
> architecture changes. See https://bugs.gentoo.org/663424 for an example.
 
 Sure, but if you run into something like that you just don't use the
 noarch keyword for those packages.

 Thanks,

 William


signature.asc
Description: Digital signature


[gentoo-dev] rfc: noarch keyword

2020-03-18 Thread William Hubbs
All,

this came up again on the recent thread about dropping non x86/amd64
support for python packages, and I want to bring it up again on its own
thread.

How often do architecture specific bugs really exist in languages like
perl, python etc? From what I've seen they are pretty rare. Not to mention,
if we found one somewhere, we could adjust keywords as necessary.

Also, if someone did inadvertently keyword a package with noarch that didn't
work everywhere, it would be a matter of adjusting the keywords for that
package.

So, my question is, why can't we add a noarch/~noarch keyword and see
how things go? If it gets abused we can always nuke it later.

Thanks,

William



signature.asc
Description: Digital signature


[gentoo-dev] rfc: reply-to munging

2020-03-13 Thread William Hubbs
On Thu, Mar 12, 2020 at 09:09:39PM +0100, Andreas K. Huettel wrote:
> Am Donnerstag, 12. März 2020, 20:23:56 CET schrieb Michał Górny:
> > I suppose that a part of the problem is the default Reply-To in these
> > mails.
 
Yes, I agree that this is a problem.

> Which was deliberately added...

Why was this added? I have asked before and never gotten an answer.

Thanks,

William


signature.asc
Description: Digital signature


[gentoo-dev] cleaning up go packages

2020-03-05 Thread William Hubbs
All,

within the next few days I will start migrating go packages in the tree
that inherit the go-module eclass and use EGO_VENDOR to Euse EGO_SUM.

Once I do that, I will go through packages that inherit golang-* and see
if they can be migrated to inherit go-module instead.

If someone doesn't want me to touch their ebuilds, please speak up.

Thanks,

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 0/2] fix support for go modules

2020-03-04 Thread William Hubbs
On Wed, Feb 26, 2020 at 09:24:35AM -0600, William Hubbs wrote:
> *** BLURB HERE ***
> This is another round of support for go modules.
> The first patch adds goproxy to the gentoo mirror system so that
> ebuilds can be written with "mirror://goproxy/foo/bar" in SRC_URI. This
> is used by the go-module.eclass changes in the second patch.
> 
> The second patch adds EGO_SUM as a variable to the go-module.eclass.
> This also allows us to create a local goproxy for the modules we
> download.

This is in the tree with some documentation updates.

Now we need to start migrating go-module ebuilds from EGO_VENDOR to
EGO_SUM.

If no one objects I'll work on this over the next few days along with
anyone else who happens to see the ebuilds.

Let me know if there are any questions.

Thanks,

William



signature.asc
Description: Digital signature


[gentoo-dev] [PATCH 1/2] profiles/thirdpartymirrors: add goproxy mirror

2020-02-26 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 profiles/thirdpartymirrors | 1 +
 1 file changed, 1 insertion(+)

diff --git a/profiles/thirdpartymirrors b/profiles/thirdpartymirrors
index ad4c4b97214..d60f166e07c 100644
--- a/profiles/thirdpartymirrors
+++ b/profiles/thirdpartymirrors
@@ -25,3 +25,4 @@ sourceforge   https://download.sourceforge.net
 sourceforge.jp http://iij.dl.sourceforge.jp https://osdn.dl.sourceforge.jp 
https://jaist.dl.sourceforge.jp
 ubuntu http://mirror.internode.on.net/pub/ubuntu/ubuntu/ 
https://mirror.tcc.wa.edu.au/ubuntu/ http://ubuntu.uni-klu.ac.at/ubuntu/ 
http://mirror.dhakacom.com/ubuntu-archive/ http://ubuntu.c3sl.ufpr.br/ubuntu/ 
http://ubuntu.uni-sofia.bg/ubuntu/ http://hr.archive.ubuntu.com/ubuntu/ 
http://cz.archive.ubuntu.com/ubuntu/ https://mirror.dkm.cz/ubuntu 
http://ftp.cvut.cz/ubuntu/ http://ftp.stw-bonn.de/ubuntu/ 
https://ftp-stud.hs-esslingen.de/ubuntu/ https://mirror.netcologne.de/ubuntu/ 
https://mirror.unej.ac.id/ubuntu/ http://kr.archive.ubuntu.com/ubuntu/ 
https://mirror.nforce.com/pub/linux/ubuntu/ 
http://mirror.amsiohosting.net/archive.ubuntu.com/ 
http://nl3.archive.ubuntu.com/ubuntu/ https://mirror.timeweb.ru/ubuntu/ 
http://ubuntu.mirror.su.se/ubuntu/ https://ftp.yzu.edu.tw/ubuntu/ 
https://mirror.aptus.co.tz/pub/ubuntuarchive/ 
https://ubuntu.volia.net/ubuntu-archive/ 
https://mirror.sax.uk.as61049.net/ubuntu/ https://mirror.pnl.gov/ubuntu/ 
http://mirror.cc.columbia.edu/pub/linux/ubuntu/archive/ 
https://mirrors.namecheap.com/ubuntu/
 vdr-developerorg http://projects.vdr-developer.org/attachments/download
+goproxyhttps://proxy.golang.org/ https://goproxy.io/ 
https://gocenter.io/
-- 
2.24.1




[gentoo-dev] [PATCH 2/2] go-module.eclass: add support for EGO_SUM

2020-02-26 Thread William Hubbs
The EGO_SUM variable replaces EGO_VENDOR for go modules.

Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 362 +++-
 1 file changed, 322 insertions(+), 40 deletions(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 80ff2902b3a..68b95bbc510 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -4,28 +4,29 @@
 # @ECLASS: go-module.eclass
 # @MAINTAINER:
 # William Hubbs 
+# @AUTHOR:
+# William Hubbs 
+# Robin H. Johnson 
 # @SUPPORTED_EAPIS: 7
 # @BLURB: basic eclass for building software written as go modules
 # @DESCRIPTION:
-# This eclass provides basic settings and functions
-# needed by all software written in the go programming language that uses
-# go modules.
-#
-# You will know the software you are packaging uses modules because
-# it will have files named go.sum and go.mod in its top-level source
-# directory. If it does not have these files, use the golang-* eclasses.
+# This eclass provides basic settings and functions needed by all software
+# written in the go programming language that uses modules.
 #
-# If it has these files and a directory named vendor in its top-level
-# source directory, you only need to inherit the eclass since upstream
-# is vendoring the dependencies.
+# If the software you are packaging  has a file named go.mod in its top
+# level directory, it uses modules and  your ebuild should inherit this
+# eclass. If it does not, your ebuild should use the golang-* eclasses.
 #
-# If it does not have a vendor directory, you should use the EGO_VENDOR
-# variable and the go-module_vendor_uris function as shown in the
-# example below to handle dependencies.
+# If, besides go.mod, your software has a directory named vendor in its
+# top level directory, the only thing you need to do is inherit the
+# eclass. If there is no vendor directory, you need to also populate
+# EGO_SUM and call go-module_set_globals as discussed below.
 #
 # Since Go programs are statically linked, it is important that your ebuild's
 # LICENSE= setting includes the licenses of all statically linked
 # dependencies. So please make sure it is accurate.
+# You can use a utility like dev-util/golicense (network connectivity is
+# required) to extract this information from the compiled binary.
 #
 # @EXAMPLE:
 #
@@ -33,19 +34,21 @@
 #
 # inherit go-module
 #
-# EGO_VENDOR=(
-#  "github.com/xenolf/lego 6cac0ea7d8b28c889f709ec7fa92e92b82f490dd"
-# "golang.org/x/crypto 453249f01cfeb54c3d549ddb75ff152ca243f9d8 
github.com/golang/crypto"
+# EGO_SUM=(
+#   "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod 
h1:q/89r3U2H7sSsE2t6Kca0lfwTK8JdoNGS/yzM/4iH5I="
+#   "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59 
h1:WWB576BN5zNSZc/M9d/10pqEx5VHNhaQ/yOVAkmj5Yo="
 # )
 #
+# go-module_set_globals
+#
 # SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> 
${P}.tar.gz
-# $(go-module_vendor_uris)"
+# ${EGO_SUM_SRC_URI}"
 #
 # @CODE
 
 case ${EAPI:-0} in
7) ;;
-   *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
+   *) die "${ECLASS} EAPI ${EAPI} is not supported."
 esac
 
 if [[ -z ${_GO_MODULE} ]]; then
@@ -64,10 +67,12 @@ export GO111MODULE=on
 export GOCACHE="${T}/go-build"
 
 # The following go flags should be used for all builds.
-# -mod=vendor stopps downloading of dependencies from the internet.
 # -v prints the names of packages as they are compiled
 # -x prints commands as they are executed
-export GOFLAGS="-mod=vendor -v -x"
+# -mod=readonly do not update go.mod/go.sum but fail if updates are needed
+# -mod=vendor use the vendor directory instead of downloading dependencies
+export GOFLAGS="-v -x -mod=readonly"
+[[ ${#EGO_VENDOR[@]} -gt 0 ]] && GOFLAGS+=" -mod=vendor"
 
 # Do not complain about CFLAGS etc since go projects do not use them.
 QA_FLAGS_IGNORED='.*'
@@ -77,28 +82,36 @@ RESTRICT="strip"
 
 EXPORT_FUNCTIONS src_unpack pkg_postinst
 
+# @ECLASS-VARIABLE: EGO_SUM
+# @DESCRIPTION:
+# This is an array based on the go.sum content from inside the target package.
+# Each array entry must be quoted and contain a single line from go.sum.
+#
+# The format of go.sum is described upstream here:
+# https://tip.golang.org/cmd/go/#hdr-Module_authentication_using_go_sum
+#
+# h1: is the Hash1 structure used by upstream Go
+# Note that Hash1 is MORE stable than Gentoo distfile hashing, and upstream
+# warns that it's conceptually possible for the Hash1 value to remain stable
+# while the upstream zipfiles change. E.g. it does NOT capture mtime changes in
+# files within a zipfile.
+
 # @ECLASS-VARIABLE: EGO_VENDOR
 # @DESCRIPTION:
-# This variable contains a list of vendored packages.
-# The items of this array are strings that contain the
-# import path and the git commit hash for a vendored package.
-

[gentoo-dev] [PATCH 0/2] fix support for go modules

2020-02-26 Thread William Hubbs
*** BLURB HERE ***
This is another round of support for go modules.
The first patch adds goproxy to the gentoo mirror system so that
ebuilds can be written with "mirror://goproxy/foo/bar" in SRC_URI. This
is used by the go-module.eclass changes in the second patch.

The second patch adds EGO_SUM as a variable to the go-module.eclass.
This also allows us to create a local goproxy for the modules we
download.

William Hubbs (2):
  profiles/thirdpartymirrors: add goproxy mirror
  go-module.eclass: add support for EGO_SUM

 eclass/go-module.eclass| 362 +
 profiles/thirdpartymirrors |   1 +
 2 files changed, 323 insertions(+), 40 deletions(-)

-- 
2.24.1




Re: [gentoo-dev] [PATCH v2 1/4] eclass/go-module: add support for building based on go.sum

2020-02-22 Thread William Hubbs
I did find a way to apply your patch to the eclass today, so I'm working
with it locally now.

I would find it much more difficult to add license info to EGO_SUM than
to add it to LICENSE= directly. The lines in EGO_SUM are already pretty
long and adding info to them manually is more tedious than adding it to
LICENSE=.

Also, I do not see an advantage to adding license info
to EGO_SUM over adding it to LICENSE=. Either way yoou have to use
golicense or something similar to extract the info from the binary and manually
add it to the ebuild.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread William Hubbs
On Wed, Feb 19, 2020 at 12:02:51PM -0800, Patrick McLean wrote:
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed:  
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
> 
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t
> 
> If your system is booted with openrc, use this command  (as root) 
> to restart sshd:
> /etc/init.d/sshd restart

A better choice would be:

rc-service sshd --nodeps restart

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH v2 1/4] eclass/go-module: add support for building based on go.sum

2020-02-19 Thread William Hubbs
On Wed, Feb 19, 2020 at 09:20:13AM -0600, William Hubbs wrote:
> On Wed, Feb 19, 2020 at 07:36:27AM +, Robin H. Johnson wrote:
> > On Tue, Feb 18, 2020 at 11:46:45PM -0600, William Hubbs wrote:
> > > > -# If it does not have a vendor directory, you should use the EGO_VENDOR
> > > > +# Alternatively, older versions of this eclass used the EGO_VENDOR
> > > >  # variable and the go-module_vendor_uris function as shown in the
> > > >  # example below to handle dependencies.
> > > I think we can remove the example with EGO_VENDOR and
> > > go-module_vendor_uris; we really don't want people to continue following
> > > that example.
> > I tried to handle more cases here, but now I'm wondering if it would be
> > cleaner just to put all of new way into a distinct eclass, and sunset
> > the old eclass entirely. I found unforeseen interactions, see below.
> > 
> > > > +# S="${WORKDIR}/${MY_P}"
> > > The default setting of S should be fine for most ebuilds, so I don't
> > > think we need this in the example.
> > I'd copied it, but yes in this case.
> > 
> > > 
> > > > +# go-module_set_globals
> > > > +#
> > > > +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> 
> > > > ${P}.tar.gz
> > > > +# ${EGO_SUM_SRC_URI}"
> > > > +#
> > > > +# LICENSE="some-license ${EGO_SUM_LICENSES}"
> > > > +#
> > > > +# src_unpack() {
> > > > +#  unpack ${P}.tar.gz
> > > > +#  go-module_src_unpack
> > > > +# }
> > >  I don't think I would put an src_unpack() in the example.
> > This is one of the unforeseen interactions.
> > The go.sum unpack only applies special handling to distfiles that it
> > knows about. It does NOT process any other distfiles at all.
> > 
> > EAPI8 or future Portage improvements might have annotations to disable
> > any automatic unpacking for specific distfiles, which would resolve this
> > issue.
> > 
> > Hence, you need to explicitly unpack any distfiles that are NOT part of
> > the go.sum dependencies. There are some ebuilds that do unpack & rename
> > in src_unpack already, so they need extra care as well.
> > 
> > The EGO_VENDOR src_unpack unpacked EVERYTHING, so it didn't have this
> > issue.

It used filtering to decide what to unpack where, so I think we can use
the same idea.  Look at this patch to what is in the tree currently.

Look at this patch. Part of it is just comments, but I think this could
work if module_files is populated correctly.

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 80ff2902b3a..3e0091a0d25 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -113,7 +113,8 @@ go-module_vendor_uris() {
 # ${EGO_VENDOR} to ${S}/vendor.
 go-module_src_unpack() {
debug-print-function ${FUNCNAME} "$@"
-   local f hash import line repo tarball vendor_tarballs x
+   local f hash import line repo tarball module_files vendor_tarballs x
+   module_files=()
vendor_tarballs=()
for line in "${EGO_VENDOR[@]}"; do
read -r import hash repo x <<< "${line}"
@@ -125,9 +126,15 @@ go-module_src_unpack() {
: "${repo:=${import}}"
vendor_tarballs+=("${repo//\//-}-${hash}.tar.gz")
done
+   # populate module_files with the files we do not want to unpack
+   # based on EGO_SUM
+
+   # unpack the appropriate files from $A
for f in $A; do
[[ -n ${vendor_tarballs[*]} ]] && has "$f" 
"${vendor_tarballs[@]}" &&
continue
+   [[ -n ${module_files[*]} ]] && has "$f" "${module_files[@]}" &&
+   continue
unpack "$f"
done
 


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH v2 1/4] eclass/go-module: add support for building based on go.sum

2020-02-19 Thread William Hubbs
On Wed, Feb 19, 2020 at 07:36:27AM +, Robin H. Johnson wrote:
> On Tue, Feb 18, 2020 at 11:46:45PM -0600, William Hubbs wrote:
> > > -# If it does not have a vendor directory, you should use the EGO_VENDOR
> > > +# Alternatively, older versions of this eclass used the EGO_VENDOR
> > >  # variable and the go-module_vendor_uris function as shown in the
> > >  # example below to handle dependencies.
> > I think we can remove the example with EGO_VENDOR and
> > go-module_vendor_uris; we really don't want people to continue following
> > that example.
> I tried to handle more cases here, but now I'm wondering if it would be
> cleaner just to put all of new way into a distinct eclass, and sunset
> the old eclass entirely. I found unforeseen interactions, see below.
> 
> > > +# S="${WORKDIR}/${MY_P}"
> > The default setting of S should be fine for most ebuilds, so I don't
> > think we need this in the example.
> I'd copied it, but yes in this case.
> 
> > 
> > > +# go-module_set_globals
> > > +#
> > > +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> 
> > > ${P}.tar.gz
> > > +#   ${EGO_SUM_SRC_URI}"
> > > +#
> > > +# LICENSE="some-license ${EGO_SUM_LICENSES}"
> > > +#
> > > +# src_unpack() {
> > > +#unpack ${P}.tar.gz
> > > +#go-module_src_unpack
> > > +# }
> >  I don't think I would put an src_unpack() in the example.
> This is one of the unforeseen interactions.
> The go.sum unpack only applies special handling to distfiles that it
> knows about. It does NOT process any other distfiles at all.
> 
> EAPI8 or future Portage improvements might have annotations to disable
> any automatic unpacking for specific distfiles, which would resolve this
> issue.
> 
> Hence, you need to explicitly unpack any distfiles that are NOT part of
> the go.sum dependencies. There are some ebuilds that do unpack & rename
> in src_unpack already, so they need extra care as well.
> 
> The EGO_VENDOR src_unpack unpacked EVERYTHING, so it didn't have this
> issue.

I will look at that in a bit and comment on it.

> 
> > 
> > > +# The extra metadata keys accepted at this time are:
> > > +# - license: for dependencies built into the final runtime, the value 
> > > field is
> > > +#   a comma seperated list of Gentoo licenses to apply to the LICENSE 
> > > variable, 
> > > +#
> > There are two lines for each module in go.sum, the one with /go.mod as a
> > suffix to the version and the one without. We do not need both right?
> This is not entirely correct, and it's the warnings from golang upstream
> about some hidden complexity in the /go.mod that lead me to list both of
> them.
> 
> If we intend to verify the h1: in future, then we need to list all
> /go.mod entries explicitly, so have somewhere to put the h1: hash.
> If you're verifying the h1: hash, you must verify it on the
> {version}.mod ALWAYS, and if the {version}.zip is present, then also on
> that file (otherwise it could sneak in some evil metadata via the
> {version}.mod).
> 
> If we omit h1: entirely, then we can get away with listing ONE line in
> EGO_SUM for each dependency.
> - If it contains /go.mod, it will fetch ONLY the {version}.mod file.
> - If it does not contain /go.mod, it will fetch the {version}.mod file
>   AND the {version}.zip file
 
If Go itself does that verification during the build, do we need to do
it also?

> > > +# @EXAMPLE:
> > > +# # github.com/BurntSushi/toml is a build-time only dep
> > > +# # github.com/aybabtme/rgbterm is a runtime dep, annotated with licenses
> > 
> > I'm not sure we can distinguish between buildtime only and runtime deps.
> The 'golicense' tool will take a Golang binary and print out all of the
> Golang modules that got linked into it. I consider those to be the
> runtime deps in this case.
> 
> > > +# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
> ...
> > > +# This variable should NOT be present in user-level configuration e.g.
> > > +# /etc/portage/make.conf, as it will violate metadata immutability!
> > > +: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
> > 
> > If this isn't supposed to be in user-level configuration, where should
> > it be set?
> Maybe I'll just prefix it with 'readonly' and force the value for now.
> 
> > >  # @FUNCTION: go-module_src_unpack
> > >  # @DESCRIPTION:
> > > +# Extract & configure Go modules for consumpations.
> > > +# - Modules listed in EGO_SUM are configured

Re: [gentoo-dev] [PATCH v2 4/4] dev-vcs/cli: new package

2020-02-18 Thread William Hubbs
On Mon, Feb 17, 2020 at 01:22:32AM -0800, Robin H. Johnson wrote:
> Package-Manager: Portage-2.3.84, Repoman-2.3.18
> Signed-off-by: Robin H. Johnson 
> ---
>  dev-vcs/cli/Manifest | 137 +++
>  dev-vcs/cli/cli-0.5.5.ebuild | 177 +++
>  dev-vcs/cli/metadata.xml |  11 +++
>  3 files changed, 325 insertions(+)
>  create mode 100644 dev-vcs/cli/Manifest
>  create mode 100644 dev-vcs/cli/cli-0.5.5.ebuild
>  create mode 100644 dev-vcs/cli/metadata.xml

*snip manifest*

> diff --git dev-vcs/cli/cli-0.5.5.ebuild dev-vcs/cli/cli-0.5.5.ebuild
> new file mode 100644
> index ..3892d656a46e
> --- /dev/null
> +++ dev-vcs/cli/cli-0.5.5.ebuild
> @@ -0,0 +1,177 @@
> +# Copyright 1999-2020 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +inherit bash-completion-r1 go-module
> +
> +EGO_SUM=(
> + "github.com/akavel/rsrc v0.8.0/go.mod 
> h1:uLoCtb9J+EyAqh+26kdrTgmzRBFPGOolLWKpdxkKq+c="
> + "github.com/AlecAivazis/survey/v2 v2.0.4/go.mod 
> h1:WYBhg6f0y/fNYUuesWQc0PKbJcEliGcYHB9sNT3Bg74="
> + "github.com/AlecAivazis/survey/v2 v2.0.4 
> h1:qzXnJSzXEvmUllWqMBWpZndvT2YfoAUzAMvZUax3L2M= license:MIT"
> + "github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38/go.mod 
> h1:r7bzyVFMNntcxPZXK3/+KdruV1H5KSlyVY0gc+NgInI="
> + "github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 
> h1:smF2tmSOzy2Mm+0dGI2AIUHY+w0BUc+4tn40djz7+6U="
> + "github.com/alecthomas/chroma v0.6.8/go.mod 
> h1:o9ohftueRi7H5be3+Q2cQCNa/YnLBFUNx40ZJfGVFKA="
> + "github.com/alecthomas/chroma v0.6.8 
> h1:TW4JJaIdbAbMyUtGEd6BukFlOKYvVQz3vVhLBEUNwMU= license:MIT"
> + "github.com/alecthomas/colour v0.0.0-20160524082231-60882d9e2721/go.mod 
> h1:QO9JBoKquHd+jz9nshCh40fOfO+JzsoXy8qTHF68zU0="
> + "github.com/alecthomas/colour v0.0.0-20160524082231-60882d9e2721 
> h1:JHZL0hZKJ1VENNfmXvHbgYlbUOvpzYzvy2aZU5gXVeo="
> + "github.com/alecthomas/kong-hcl 
> v0.1.8-0.20190615233001-b21fea9723c8/go.mod 
> h1:MRgZdU3vrFd05IQ89AxUZ0aYdF39BYoNFa324SodPCA="
> + "github.com/alecthomas/kong 
> v0.1.17-0.20190424132513-439c674f7ae0/go.mod 
> h1:+inYUSluD+p4L8KdviBSgzcqEjUQOfC5fQDRFuc36lI="
> + "github.com/alecthomas/kong v0.2.1-0.20190708041108-0548c6b1afae/go.mod 
> h1:+inYUSluD+p4L8KdviBSgzcqEjUQOfC5fQDRFuc36lI="
> + "github.com/alecthomas/repr v0.0.0-20180818092828-117648cd9897/go.mod 
> h1:xTS7Pm1pD1mvyM075QCDSRqH6qRLXylzS24ZTpRiSzQ="
> + "github.com/alecthomas/repr v0.0.0-20180818092828-117648cd9897 
> h1:p9Sln00KOTlrYkxI1zYWl1QLnEqAqEARBEYa8FQnQcY="
> + "github.com/armon/consul-api v0.0.0-20180202201655-eb2c6b5be1b6/go.mod 
> h1:grANhF5doyWs3UAsr3K4I6qtAmlQcZDesFNEHPZAzj8="
> + "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod 
> h1:q/89r3U2H7sSsE2t6Kca0lfwTK8JdoNGS/yzM/4iH5I= license:BSD-2,MIT"
> + "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59 
> h1:WWB576BN5zNSZc/M9d/10pqEx5VHNhaQ/yOVAkmj5Yo="
> + "github.com/BurntSushi/toml v0.3.1/go.mod 
> h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU="
> + "github.com/BurntSushi/toml v0.3.1 
> h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ="
> + "github.com/coreos/etcd v3.3.10+incompatible/go.mod 
> h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE="
> + "github.com/coreos/go-etcd v2.0.0+incompatible/go.mod 
> h1:Jez6KQU2B/sWsbdaef3ED8NzMklzPG4d5KIOhIy30Tk="
> + "github.com/coreos/go-semver v0.2.0/go.mod 
> h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk="
> + "github.com/cpuguy83/go-md2man v1.0.10/go.mod 
> h1:SmD6nW6nTyfqj6ABTjUi3V3JVMnlJmwcJI5acqYI6dE="
> + "github.com/cpuguy83/go-md2man v1.0.10 
> h1:BSKMNlYxDvnunlTymqtgONjNnaRV1sTpcovwwjF22jk="
> + "github.com/daaku/go.zipexe v1.0.0/go.mod 
> h1:z8IiR6TsVLEYKwXAoE/I+8ys/sDkgTzSL0CLnGVd57E="
> + "github.com/danwakefield/fnmatch 
> v0.0.0-20160403171240-cbb64ac3d964/go.mod 
> h1:Xd9hchkHSWYkEqJwUGisez3G1QY8Ryz0sdWrLPMGjLk="
> + "github.com/danwakefield/fnmatch v0.0.0-20160403171240-cbb64ac3d964 
> h1:y5HC9v93H5EPKqaS1UYVg1uYah5Xf51mBfIoWehClUQ= license:BSD-2"
> + "github.com/davecgh/go-spew v1.1.0/go.mod 
> h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38="
> + "github.com/davecgh/go-spew v1.1.1/go.mod 
> h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38="
> + "github.com/davecgh/go-spew v1.1.1 
> h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c="
> + "github.com/dlclark/regexp2 v1.1.6/go.mod 
> h1:2pZnwuY/m+8K6iRw6wQdMtk+rH5tNGR1i55kozfMjCc="
> + "github.com/dlclark/regexp2 v1.1.6 
> h1:CqB4MjHw0MFCDj+PHHjiESmHX+N7t0tJzKvC6M97BRg= license:MIT"
> + "github.com/fsnotify/fsnotify v1.4.7/go.mod 
> h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo="
> + "github.com/GeertJohan/go.incremental v1.0.0/go.mod 
> h1:6fAjUhbVuX1KcMD3c8TEgVUqmo4seqhv0i0kdATSkM0="
> + "github.com/GeertJohan/go.rice v1.0.0/go.mod 
> h1:eH6gbSOAUv07dQuZVnBmoDP8mgsM1rtixis4Tib9if0="
> + 

Re: [gentoo-dev] [PATCH v2 3/4] app-admin/kube-bench: convert to go-module go.sum

2020-02-18 Thread William Hubbs
On Mon, Feb 17, 2020 at 01:22:31AM -0800, Robin H. Johnson wrote:
> Signed-off-by: Robin H. Johnson 
> ---
>  app-admin/kube-bench/Manifest | 351 
>  .../kube-bench/kube-bench-0.2.3-r1.ebuild | 394 ++
>  2 files changed, 745 insertions(+)
>  create mode 100644 app-admin/kube-bench/kube-bench-0.2.3-r1.ebuild
> 

*snip manifest*

> diff --git app-admin/kube-bench/kube-bench-0.2.3-r1.ebuild 
> app-admin/kube-bench/kube-bench-0.2.3-r1.ebuild
> new file mode 100644
> index ..fcab0aed86e9
> --- /dev/null
> +++ app-admin/kube-bench/kube-bench-0.2.3-r1.ebuild
> @@ -0,0 +1,394 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +EGO_PN=github.com/aquasecurity/kube-bench

You shouldn't need EGO_PN

> +DESCRIPTION="Kubernetes Bench for Security runs the CIS Kubernetes Benchmark"
> +HOMEPAGE="https://github.com/aquasecurity/kube-bench;
> +
> +EGO_SUM=(
> + "cloud.google.com/go v0.26.0/go.mod 
> h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw="
> + "cloud.google.com/go v0.34.0/go.mod 
> h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw="
> + "cloud.google.com/go v0.37.4 
> h1:glPeL3BQJsbF6aIIYfZizMwc5LTYz250bDMjttbBGAU="
> + "cloud.google.com/go v0.37.4/go.mod 
> h1:NHPJ89PdicEuT9hdPXMROBD91xc5uRDxsMtSB16k7hw="
> + "github.com/BurntSushi/toml v0.3.1 
> h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ="
> + "github.com/BurntSushi/toml v0.3.1/go.mod 
> h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU="
> + "github.com/NYTimes/gziphandler 
> v0.0.0-20170623195520-56545f4a5d46/go.mod 
> h1:3wb06e3pkSAbeQ52E9H9iFoQsEEwGN64994WTCIhntQ="
> + "github.com/OneOfOne/xxhash v1.2.2/go.mod 
> h1:HSdplMjZKSmBqAxg5vPj2TmRDmfkzw+cTzAElWljhcU="
> + "github.com/PuerkitoBio/purell v1.0.0/go.mod 
> h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0="
> + "github.com/PuerkitoBio/purell v1.1.1 
> h1:WEQqlqaGbrPkxLJWfBwQmfEAE1Z7ONdDLqrN38tNFfI="
> + "github.com/PuerkitoBio/purell v1.1.1/go.mod 
> h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0="
> + "github.com/PuerkitoBio/urlesc 
> v0.0.0-20160726150825-5bd2802263f2/go.mod 
> h1:uGdkoq3SwY9Y+13GIhn11/XLaGBb4BfwItxLd5jeuXE="
> + "github.com/PuerkitoBio/urlesc v0.0.0-20170810143723-de5bf2ad4578 
> h1:d+Bc7a5rLufV/sSk/8dngufqelfh6jnri85riMAaF/M="
> + "github.com/PuerkitoBio/urlesc 
> v0.0.0-20170810143723-de5bf2ad4578/go.mod 
> h1:uGdkoq3SwY9Y+13GIhn11/XLaGBb4BfwItxLd5jeuXE="
> + "github.com/Shopify/sarama v1.19.0/go.mod 
> h1:FVkBWblsNy7DGZRfXLU0O9RCGt5g3g3yEuWXgklEdEo="
> + "github.com/Shopify/toxiproxy v2.1.4+incompatible/go.mod 
> h1:OXgGpZ6Cli1/URJOF1DMxUHB2q5Ap20/P/eIdh4G0pI="
> + "github.com/alecthomas/template 
> v0.0.0-20160405071501-a0175ee3bccc/go.mod 
> h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc="
> + "github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod 
> h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0="
> + "github.com/apache/thrift v0.12.0/go.mod 
> h1:cp2SuWMxlEZw2r+iP2GNCdIi4C1qmUzdZFSVb+bacwQ="
> + "github.com/armon/consul-api v0.0.0-20180202201655-eb2c6b5be1b6/go.mod 
> h1:grANhF5doyWs3UAsr3K4I6qtAmlQcZDesFNEHPZAzj8="
> + "github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973/go.mod 
> h1:Dwedo/Wpr24TaqPxmxbtue+5NUziq4I4S80YR8gNf3Q="
> + "github.com/beorn7/perks v1.0.0/go.mod 
> h1:KWe93zE9D1o94FZ5RNwFwVgaQK1VOXiVxmqh+CedLV8="
> + "github.com/cespare/xxhash v1.1.0/go.mod 
> h1:XrSqR1VqqWfGrhpAt58auRo0WTKS1nRRg3ghfAqPWnc="
> + "github.com/client9/misspell v0.3.4/go.mod 
> h1:qj6jICC3Q7zFZvVWo7KLAzC3yx5G7kyvSDkc90ppPyw="
> + "github.com/coreos/bbolt v1.3.2/go.mod 
> h1:iRUV2dpdMOn7Bo10OQBFzIJO9kkE559Wcmn+qkEiiKk="
> + "github.com/coreos/etcd v3.3.10+incompatible/go.mod 
> h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE="
> + "github.com/coreos/go-semver v0.2.0/go.mod 
> h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk="
> + "github.com/coreos/go-systemd v0.0.0-20190321100706-95778dfbb74e/go.mod 
> h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4="
> + "github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f/go.mod 
> h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA="
> + "github.com/davecgh/go-spew v0.0.0-20151105211317-5215b55f46b2/go.mod 
> h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38="
> + "github.com/davecgh/go-spew v1.1.0/go.mod 
> h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38="
> + "github.com/davecgh/go-spew v1.1.1 
> h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c="
> + "github.com/davecgh/go-spew v1.1.1/go.mod 
> h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38="
> + "github.com/denisenkom/go-mssqldb v0.0.0-20190515213511-eb9f6a1743f3 
> h1:tkum0XDgfR0jcVVXuTsYv/erY2NnEDqwRojbxR1rBYA="
> + "github.com/denisenkom/go-mssqldb 
> v0.0.0-20190515213511-eb9f6a1743f3/go.mod 
> h1:zAg7JM8CkOJ43xKXIj7eRO9kmWm/TW578qo+oDO6tuM="
> + "github.com/dgrijalva/jwt-go v3.2.0+incompatible/go.mod 
> 

Re: [gentoo-dev] [PATCH v2 2/4] dev-go/go-tour: convert to go-module go.sum

2020-02-18 Thread William Hubbs
This ebuild isn't fully convirted, so it probably isn't the best
example.

My comments are just a couple of aspects of it.


On Mon, Feb 17, 2020 at 01:22:30AM -0800, Robin H. Johnson wrote:
> Signed-off-by: Robin H. Johnson 
> ---
>  dev-go/go-tour/Manifest  |  7 ++
>  dev-go/go-tour/go-tour-0_p20190829-r2.ebuild | 68 
>  2 files changed, 75 insertions(+)
>  create mode 100644 dev-go/go-tour/go-tour-0_p20190829-r2.ebuild
> 
> diff --git dev-go/go-tour/Manifest dev-go/go-tour/Manifest
> index 4790cfab02c5..89515578048c 100644
> --- dev-go/go-tour/Manifest
> +++ dev-go/go-tour/Manifest
> @@ -1,3 +1,10 @@
>  DIST github.com-golang-net-3b0461eec859c4b73bb64fdc8285971fd33e3938.tar.gz 
> 1099680 BLAKE2B 
> 989a8d6c9166696bef1aff398acc8cd1e41e1240c5c113be030c80355cdf96eaa6d5f231c99f2c44d8eacf199579804c59fc45f999862bc4bf057b694841c8dc
>  SHA512 
> 5e42e26ac17f52d6408b63eebd740bedc5a78b8023b675688d7b39b20afa53b34ffde764b693828143483c8f5450180f6a00e9eb28b8f3f6e14303cc4cd7c62b
>  DIST github.com-golang-tools-7b79afddac434519a8ca775cc575fddb0d162aab.tar.gz 
> 2682003 BLAKE2B 
> 60d9981b9fcc47077bc0dc1179e518ba2f2373595d5798eb6aa37a832ce72f475b0808b2030919f141cd978533792294fdd8528e1d52b4eeec6e9f1a3b6e772d
>  SHA512 
> 5b7af03d138567edaa70e1b3555b8a9c4822f33c3fb14e8ec435499d21f46d61f44b62fddcec3ecc6f75d4e9a6dfb6b2a7526ddf8785d933941d64e646dc1b9b
>  DIST go-tour-0_p20190829.tar.gz 321179 BLAKE2B 
> 56fad2c3608aec9653e31a59e8696aa445375de88f17e72a95620b4b375c88b8e45838360c09a1c53184e5a20c1a5ca044f6ad055de3736e675d3faf3fd52a91
>  SHA512 
> 2701234788810a8fdb932faae666ec89796664e078b3170344b8c219a2247a510df66bff825bdc458ba062bd4b3f5dccd07dbf88a092053b1ea791c2f50248f4
> +DIST golang.org%2Fx%2Fcrypto%2F@v%2Fv0.0.0-20190308221718-c2843e01d9a2.mod 
> 88 BLAKE2B 
> aec7d0eea1278eb3d1568d5bfb4041267501ad14457ebfcbdbc5fe21473170b8616ca4028f52af2edbfd85922cbe04540b4b0df7f69f63197698143cc5557a7a
>  SHA512 
> 2df49895053b36fed7ea905aa73f86568fbafd79ff0a7976679d8c77cf15025129435d9dbfd89367b611b1aadbea4f4bd1835eb4efa9ea702466e443638d379e
> +DIST golang.org%2Fx%2Fnet%2F@v%2Fv0.0.0-20190311183353-d8887717615a.mod 119 
> BLAKE2B 
> e042b2716739483252c3340451b2c3c7b421fdf8d6b3e0333e979802fca66159596982ea63a24b6a64457b2757a0ad24cbb9ea032bab4c5377edf84a3ea18b97
>  SHA512 
> 26b6c92eecd2208967336d4d23f8a71f77f9a73643ad1e5cd84dee36b2f626fffc806e4dd33acc284831a0961e2b363d898a747903235945fbfb665c5b4d5ef2
> +DIST golang.org%2Fx%2Fnet%2F@v%2Fv0.0.0-20190311183353-d8887717615a.zip 
> 1273340 BLAKE2B 
> 7d42472afb905448b6ae6f66258dc805fa7c4b9c8dffb230ad6458b250fe5d564a3f6e2bf97b241ac9293c9f5885f28cc996ab7953a0ba9e97b8731911b982d5
>  SHA512 
> 57852d3cd066a9eb279f909b464824041e138db1eb98c66ffbbc81259cb3f94da8ecd4d2b961646fbbe0c05156785ab2f44408b19d9f467001627d7b12fed4af
> +DIST golang.org%2Fx%2Fsys%2F@v%2Fv0.0.0-20190215142949-d0b11bdaac8a.mod 24 
> BLAKE2B 
> 64a70c4594f5d3c37d962c1ed07630fba8abeaf534242f8f1509af271684499252af9a2320d5bac8e44064dba344b807535e4e9dd085fc0fb47bd9304120601a
>  SHA512 
> ffe50fccf7f1d200f2ebc805b190e3f10c5a3184458a38f4590e520d7ce115e1520fbabe56651bbdc2e08da4a8db5ac86d0e88728efde3ab26c64ab4e0cd604c
> +DIST golang.org%2Fx%2Ftext%2F@v%2Fv0.3.0.mod 25 BLAKE2B 
> 31009af0fdcd0f8730c9985287e6e364ec4e5183e57e92560dbc80a2010eced51b8a90f01a82b49384268c8a0adbf69d179c205d3f68e0eb459169d2ea9528f0
>  SHA512 
> ca081ef7cccd7bbedc6843fbe0c452352661a07e1298cd02ff338ed79d807c6401d613a3cf20011189d2f98a794ffa410547b3e352eb58a6f0a84822285d391d
> +DIST golang.org%2Fx%2Ftools%2F@v%2Fv0.0.0-20190312164927-7b79afddac43.mod 87 
> BLAKE2B 
> 32cb406deea05323b1121386bf61f344f8eda0b5370e95bb73828ce0bea50bee375ae3e9b076b9d683a4d89561709c5e97e45e6b08344fbdf6b03b3ce4398dcd
>  SHA512 
> 18ae9b2f54109b4ec5cdea433ee0e3b7006e4d5ea57022d6e8151d4d364735a6b55cf7b5eb2f43b602ec786b2b6819ad78dfc33151ee1a63a0b1199f54ce34a1
> +DIST golang.org%2Fx%2Ftools%2F@v%2Fv0.0.0-20190312164927-7b79afddac43.zip 
> 3200356 BLAKE2B 
> 8ebbd9b772d54bfa39de2319a583c5d80cf6580456a4da5043a5b9a49450c3dcc5eba68ac7726dd7771c0855032294b2ee6a9df738780e87c312935fbc94e5a8
>  SHA512 
> 5e56ee0659802472d5187c0fe65c6e2b93478cf968b95c2c79db3d458844c38b18a597ad032cfe3a712a5516215d6010f1efcf36db2aa2bb2d29bf337819969d
> diff --git dev-go/go-tour/go-tour-0_p20190829-r2.ebuild 
> dev-go/go-tour/go-tour-0_p20190829-r2.ebuild
> new file mode 100644
> index ..256553da8002
> --- /dev/null
> +++ dev-go/go-tour/go-tour-0_p20190829-r2.ebuild
> @@ -0,0 +1,68 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +MY_PN=tour
> +EGO_PN="golang.org/x/${MY_PN}"
 +
 You shouldn't need EGO_PN or MY_PN any longer.

> +EGO_SUM=(
> + # Minimal covering set
> + "golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod"
> + "golang.org/x/net v0.0.0-20190311183353-d8887717615a license:BSD"
> + "golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod"
> + 

Re: [gentoo-dev] [PATCH v2 1/4] eclass/go-module: add support for building based on go.sum

2020-02-18 Thread William Hubbs
On Mon, Feb 17, 2020 at 01:22:29AM -0800, Robin H. Johnson wrote:
> EGO_SUM mode now supplements the existing EGO_VENDOR mode.
> 
> EGO_SUM should be populated by the maintainer, directly from the go.sum
> file of the root package. See eclass and conversion examples for further
> details: dev-go/go-tour, app-admin/kube-bench, dev-vcs/cli
> 
> The go-module_set_globals function performs validation of
> inputs and dies on fatal errors.
> 
> Signed-off-by: Robin H. Johnson 
> ---
>  eclass/go-module.eclass| 419 +++--
>  profiles/thirdpartymirrors |   1 +
>  2 files changed, 397 insertions(+), 23 deletions(-)
> 
> diff --git eclass/go-module.eclass eclass/go-module.eclass
> index 80ff2902b3ad..50aff92735af 100644
> --- eclass/go-module.eclass
> +++ eclass/go-module.eclass
> @@ -4,22 +4,45 @@
>  # @ECLASS: go-module.eclass
>  # @MAINTAINER:
>  # William Hubbs 
> +# @AUTHOR:
> +# William Hubbs 
> +# Robin H. Johnson 
>  # @SUPPORTED_EAPIS: 7
>  # @BLURB: basic eclass for building software written as go modules
>  # @DESCRIPTION:
> -# This eclass provides basic settings and functions
> -# needed by all software written in the go programming language that uses
> -# go modules.
> +# This eclass provides basic settings and functions needed by all software
> +# written in the go programming language that uses go modules.
> +#
> +# You might know the software you are packaging uses modules because
> +# it has files named go.sum and go.mod in its top-level source directory.
> +# If it does not have these files, try use the golang-* eclasses FIRST!
> +# There ARE legacy Golang packages that use external modules with none of
> +# go.mod, go.sum, vendor/ that can use this eclass regardless.
> +#
> +# Guidelines for usage:
> +# "vendor/":
> +# - pre-vendored package. Do NOT set EGO_SUM or EGO_VENDOR.
>  #
> -# You will know the software you are packaging uses modules because
> -# it will have files named go.sum and go.mod in its top-level source
> -# directory. If it does not have these files, use the golang-* eclasses.
> +# "go.mod" && "go.sum":
> +# - Populate EGO_SUM with entries from go.sum
> +# - Append license:${GENTOO_LICENSE} to any modules needed at runtime.
> +#   dev-go/golicense can tell you which modules in a Golang binary are used 
> at
> +#   runtime (requires network connectivity).
>  #
> -# If it has these files and a directory named vendor in its top-level
> -# source directory, you only need to inherit the eclass since upstream
> -# is vendoring the dependencies.
> +# None of the above:
> +# - Did you try golang-* eclasses first? Upstream has undeclared dependencies
> +#   (perhaps really old source). You can use either EGO_SUM or EGO_VENDOR.
> +
> +#
> +# If it has these files AND a directory named "vendor" in its top-level 
> source
> +# directory, you only need to inherit the eclass since upstream has already
> +# vendored the dependencies.
> +
> +# If it does not have a vendor directory, you should use the EGO_SUM
> +# variable and the go-module_gosum_uris function as shown in the
> +# example below to handle dependencies.
>  #
> -# If it does not have a vendor directory, you should use the EGO_VENDOR
> +# Alternatively, older versions of this eclass used the EGO_VENDOR
>  # variable and the go-module_vendor_uris function as shown in the
>  # example below to handle dependencies.

I think we can remove the example with EGO_VENDOR and
go-module_vendor_uris; we really don't want people to continue following
that example.

> @@ -28,6 +51,28 @@
>  # dependencies. So please make sure it is accurate.
>  #
>  # @EXAMPLE:
> +# @CODE
> +#
> +# inherit go-module
> +#
> +# EGO_SUM=(
> +#   "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod 
> h1:q/89r3U2H7sSsE2t6Kca0lfwTK8JdoNGS/yzM/4iH5I= license:BSD-2,MIT"
> +#   "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59 
> h1:WWB576BN5zNSZc/M9d/10pqEx5VHNhaQ/yOVAkmj5Yo="
> +# )
> +# S="${WORKDIR}/${MY_P}"

The default setting of S should be fine for most ebuilds, so I don't
think we need this in the example.

> +# go-module_set_globals
> +#
> +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> 
> ${P}.tar.gz
> +#   ${EGO_SUM_SRC_URI}"
> +#
> +# LICENSE="some-license ${EGO_SUM_LICENSES}"
> +#
> +# src_unpack() {
> +#unpack ${P}.tar.gz
> +#go-module_src_unpack
> +# }
 +#
 I don't think I would put an src_unpack() in the example.

> +# @CODE
>  #
>  # @CODE
>  #
> @@ -35,7 +80,7 @@
>  #
>  # EGO_VENDOR=(
>  #&qu

Re: [gentoo-dev] [Policy change] Package masking of live ebuilds

2020-02-18 Thread William Hubbs
On Tue, Feb 18, 2020 at 08:52:59PM +0100, Ulrich Mueller wrote:
> The devmanual says about live ebuilds:
> 
> | CVS ebuilds must be either with empty KEYWORDS or package.masked
> | (but not both). Empty KEYWORDS are strongly preferred. This applies
> | to "live" ebuilds (-) and to ebuilds that extract a static
> | revision but still use CVS for fetching.
> 
> As of today, I count 2123 live ebuilds in the Gentoo repository with
> empty KEYWORDS and 1 (one) ebuild with non-empty KEYWORDS but
> package.masked.
> 
> So, can we finally make empty KEYWORDS mandatory and drop the part
> about package.masking?

I'm all for this; live ebuilds should have empty keywords and not be in
package.mask.

On a side note, the subject of this thread is somewhat confusing because
it implies that you want to do the opposite. ;-)

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-12 Thread William Hubbs
On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote:
> On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote:
> > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
> > > Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
> > > Manifest?!
> > 
> > Pardon mine but do 'we' really need to read your useless comments
> > everywhere, all the time and just get irritated for no benefit to
> > Gentoo?
> 
> Perhaps I'm the one being ignorant here, but why are we lambasting someone 
> for 
> seeking clarification about an unusual inclusion on a review thread?

I wasn't going to say anything, but I can't let this go by without
commenting.

Sam is correct. Maybe the tone is a bit off, (and that is debatable),
but this definitely can be seen as a legit question, regardless of other things
Michael has posted.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 1/3] eclass/go-module: add support for building based on go.sum

2020-02-09 Thread William Hubbs
On Sun, Feb 09, 2020 at 11:35:25PM +, Robin H. Johnson wrote:
> On Sun, Feb 09, 2020 at 04:11:28PM -0600, William Hubbs wrote:
> > On Sun, Feb 09, 2020 at 12:31:19PM -0800, Robin H. Johnson wrote:
> > > +# "go.mod" only:
> > > +# - Populate EGO_VENDOR
> > go.mod without go.sum can mean that there are no external dependencies, so 
> > there
> > shouldn't be a reason to populate EGO_VENDOR in this case.
> ...
> > The way I see this going is to transition to EGO_SUM and
> > drop EGO_VENDOR. unless I'm missing something.
> I know another corner case for legacy stuff, but let's drop entirely and
> encourage migration to EGO_SUM.

I'm curious, what is the corner case I'm missing?

Thanks,

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 1/3] eclass/go-module: add support for building based on go.sum

2020-02-09 Thread William Hubbs
On Sun, Feb 09, 2020 at 12:31:19PM -0800, Robin H. Johnson wrote:
> EGO_SUM mode now supplements the existing EGO_VENDOR mode.
> 
> EGO_SUM should be populated by the maintainer, directly from the go.sum
> file of the root package. See eclass and conversion example
> (dev-go/go-tour & app-admin/kube-bench) for further details.
> 
> The go-module_set_globals function performs validation of
> inputs and does die on fatal errors.
> 
> Signed-off-by: Robin H. Johnson 
> ---
>  eclass/go-module.eclass| 328 +++--
>  profiles/thirdpartymirrors |   1 +
>  2 files changed, 311 insertions(+), 18 deletions(-)
> 
> diff --git eclass/go-module.eclass eclass/go-module.eclass
> index d5de5f60ccdf..b8a635d52de7 100644
> --- eclass/go-module.eclass
> +++ eclass/go-module.eclass
> @@ -4,22 +4,46 @@
>  # @ECLASS: go-module.eclass
>  # @MAINTAINER:
>  # William Hubbs 
> +# @AUTHOR:
> +# William Hubbs 
> +# Robin H. Johnson 
>  # @SUPPORTED_EAPIS: 7
>  # @BLURB: basic eclass for building software written as go modules
>  # @DESCRIPTION:
> -# This eclass provides basic settings and functions
> -# needed by all software written in the go programming language that uses
> -# go modules.
> +# This eclass provides basic settings and functions needed by all software
> +# written in the go programming language that uses go modules.
> +#
> +# You might know the software you are packaging uses modules because
> +# it has files named go.sum and go.mod in its top-level source directory.
> +# If it does not have these files, try use the golang-* eclasses FIRST!
> +# There ARE legacy Golang packages that use external modules with none of
> +# go.mod, go.sum, vendor/ that can use this eclass regardless.
> +#
> +# Guidelines for usage:
> +# "go.mod" && "go.sum" && "vendor/":
> +# - pre-vendored package. Do NOT set EGO_SUM or EGO_VENDOR.
> +#
> +# "go.mod" && "go.sum":
> +# - Populate EGO_SUM with entries from go.sum
> +# - Do NOT include any lines that contain /go.mod
> +#
> +# "go.mod" only:
> +# - Populate EGO_VENDOR

go.mod without go.sum can mean that there are no external dependencies, so there
shouldn't be a reason to populate EGO_VENDOR in this case.

Here is a valid go.mod:

--- cut here ---
module github.com/williamh/get-ego-vendor

go 1.12
--- cut here ---

If go.mod has require lines in it and go.sum doesn't exist, this is
an issue to address upstream.

The way I see this going is to transition to EGO_SUM and
drop EGO_VENDOR. unless I'm missing something.


Thanks,

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] moving uid-gid.txt to metadata

2020-01-20 Thread William Hubbs
On Mon, Jan 20, 2020 at 12:56:48PM -0500, Michael Orlitzky wrote:
> On 1/20/20 11:57 AM, William Hubbs wrote:
> > 
> > Imo a better fit is the metadata directory in the ebuild repository.
> > That way you can add users/groups along with the acct-* packages that
> > install them.
> What benefit is there to syncing that file to everyone's machines?

I don't see this as a concern because the size of the file is
negligible compared to the tree.

William



signature.asc
Description: Digital signature


[gentoo-dev] moving uid-gid.txt to metadata

2020-01-20 Thread William Hubbs
All,

as I recall I was one of the folks who suggested that uid-gid.txt should
go in the api repository, but after thinking about it more and seeing it
in practice, I see the error of my ways on this. ;-)

Imo a better fit is the metadata directory in the ebuild repository.
That way you can add users/groups along with the acct-* packages that
install them.

Thoughts?

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread William Hubbs
On Sun, Jan 19, 2020 at 12:31:52PM +0100, Michał Górny wrote:
> Hello,
> 
> In the light of the recent misunderstandings, I have started working
> on an official Policy Guide [1].  The Guide is meant to provide
> a focused list of officially approved QA policies, along with their
> rationale and any other useful information.
> 
> This should supplement devmanual [2] with clear information on what is
> enforceable policy, and what is merely a suggestion (or possibly
> outdated information, which is a common problem for devmanual).
> 
> The current document contents were approved by the QA project.  However,
> it is by no means complete.  Further existing policies (as well as new
> policies) will be documented there as they are approved by QA team.

Why are we creating another guide instead of just consolidating
everything in the devmanual?

My understanding of things has been that the devmanual is the location
of official qa policies, but now we have devmanual, this new guide and

https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies


> 
> The sources are stored in proj/policy-guide.git [3].  If you wish to
> submit your own changes, you can either use the 'Policy Guide' bugzilla
> component [4] and/or GitHub mirror [5].

I also agree with ulm et al wrt any official discussion wrt changes
needing to happen on bugzilla.

Thanks,

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] Package up for grabs: sys-cluster/kubectl

2020-01-15 Thread William Hubbs
On Wed, Jan 15, 2020 at 10:41:30AM +0100, Michał Górny wrote:
> Due to the maintainer retiring, the following package is orphaned now:
> 
>   sys-cluster/kubectl

I'll grab this since I'm maintaining the rest of kubernetes.

William

> 
> FWICS it has a single bug filed and needs a minor version bump.
> 
> -- 
> Best regards,
> Michał Górny
> 




signature.asc
Description: Digital signature


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread William Hubbs
On Mon, Jan 13, 2020 at 12:17:36AM +0100, David Seifert wrote:
> On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote:
> > On 1/12/2020 17:46, David Seifert wrote:
> > > On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote:
> > > > On 1/12/2020 17:32, Andreas Sturmlechner wrote:
> > > > > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote:
> > > > > > It might be worthwhile to treat the removal of Python-2.7
> > > > > > from
> > > > > > the tree in
> > > > > > the same manner as an EAPI deprecation and removal, given how
> > > > > > ingrained it
> > > > > > is due to its longevity.  That will minimize the whiplash-
> > > > > > effect
> > > > > > of emerge
> > > > > > complaining about slot conflicts and dependency
> > > > > > conflicts.  Like
> > > > > > I just ran
> > > > > > into w/ setuptools-45.0.0.0's release.
> > > > > 
> > > > > So, no packaging of >=setuptools-45.0.0 until the end of 2020?
> > > > > Do
> > > > > you want to 
> > > > > freeze all python libs that upstreams are dropping py27 support
> > > > > from?
> > > > > 
> > > > 
> > > > Not saying not to package it.  Right now, the issue seems to be
> > > > it
> > > > causes
> > > > dependency conflicts in emerge's depgraph parsing when
> > > > PYTHON_TARGETS
> > > > includes python2_7 support.  Remove that and stick with python3_*
> > > > only, then
> > > > other packages that need python2_7 will whine.
> > > > 
> > > > Did setuptools-45.0.0 remove all python2 support?  I looked at
> > > > the
> > > > commit
> > > > log, and it's only the title that any meaningful hint that it may
> > > > have,
> > > > "dev-python/setuptools: Bump to 45.0.0 (py3 only)".  If it did,
> > > > then
> > > > that
> > > > change is the right change, but anyone with a userland that has a
> > > > mix
> > > > of
> > > > python2 and python3 is going to have difficulty getting that
> > > > update
> > > > to merge
> > > > in, so I really can't go higher than setuptools-44.0.0 for the
> > > > time
> > > > being.
> > > > 
> > > 
> > > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0
> > 
> > At least you didn't squirrel that behind a lmgtfy link 
> > 
> > In any event, it's clear the tree does not seem set up real well to
> > handle
> > the random removal or deprecation of python2 support.  And
> > considering
> > python2.7 isn't dead //yet//, I have to question the wisdom of
> > removing
> > packages that still support 2.7, and also wonder if there's a way to
> > be more
> > graceful in handling updates to packages whose upstream decides to
> > remove
> > python2 support.
> > 
> > Or we can just continue down the current Mad Max methodology and
> > leave it to
> > every developer for themselves.
> > 
> 
> Or - you know - you could help? Talk is cheap, gracefully removing py2
> from the tree is the hard part. A quick grep tells me we have 4388
> ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun
> devising a plan (and then doing the actual work). Pro-tip: "Don't
> remove py2" is not an actual plan when many important core dependencies
> have started removing py2 already.

Joshua and all, I am not on the python team either, but I want to drop
this link here for reference in case you haven't seen it.

https://python3statement.org

tl;dr: python 2.7 was actually deprecated in 2015 with support extended
to 2020-01-01 so folks would have time to transition off of it. All of
the upstreams on that list will be dropping support for python 2.7 this
year if they haven't already done so.

Given that, I think it is going to be extremely difficult to keep py 2.7
in the main tree.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH] go-module.eclass: set a reasonable default for the go build cache

2020-01-06 Thread William Hubbs
On Sat, Jan 04, 2020 at 08:13:36PM -0600, William Hubbs wrote:
> Signed-off-by: William Hubbs 
> ---
>  eclass/go-module.eclass | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> index 9c11959fdf8..89b32ed1201 100644
> --- a/eclass/go-module.eclass
> +++ b/eclass/go-module.eclass
> @@ -59,6 +59,10 @@ BDEPEND=">=dev-lang/go-1.12"
>  # this will become the default in the future.
>  export GO111MODULE=on
>  
> +# Set the default for the go build cache
> +# See "go help environment" for information on this setting
> +export GOCACHE="${T}/go-build"
> +
>  # The following go flags should be used for all builds.
>  # -mod=vendor stopps downloading of dependencies from the internet.
>  # -v prints the names of packages as they are compiled
> -- 
> 2.24.1

This is committed.

Thanks,

William



signature.asc
Description: Digital signature


[gentoo-dev] [PATCH] go-module.eclass: set a reasonable default for the go build cache

2020-01-04 Thread William Hubbs
Signed-off-by: William Hubbs 
---
 eclass/go-module.eclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 9c11959fdf8..89b32ed1201 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -59,6 +59,10 @@ BDEPEND=">=dev-lang/go-1.12"
 # this will become the default in the future.
 export GO111MODULE=on
 
+# Set the default for the go build cache
+# See "go help environment" for information on this setting
+export GOCACHE="${T}/go-build"
+
 # The following go flags should be used for all builds.
 # -mod=vendor stopps downloading of dependencies from the internet.
 # -v prints the names of packages as they are compiled
-- 
2.24.1




Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread William Hubbs
On Fri, Jan 03, 2020 at 09:55:31AM -0500, Michael Orlitzky wrote:
> On 1/3/20 9:52 AM, Michael Orlitzky wrote:
> > 
> > But here we are. Do we make OpenRC Linux-only and steal the fix from
> > systemd? Or pretend to support other operating systems, but leave them
> > insecure?
> > 
> 
> Or the gripping hand: rewrite opentmpfiles in C, so that it's only as
> insecure as checkpath.

There is a pr open for opentmpfiles for this, and we are also discussing
writing it in rust.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread William Hubbs
On Sat, Jan 04, 2020 at 08:38:59AM +0100, Hanno Böck wrote:
> On Fri, 3 Jan 2020 15:48:54 +0100
> Toralf Förster  wrote:
> 
> > #   Restrict potential illegal access via links
> > # 
> > fs.protected_hardlinks = 1
> > fs.protected_symlinks = 1 
> 
> Given the issues with openrc:
> Wouldn't it be a good idea to add these by default to Gentoo's
> sysctl.conf in baselayout?

If we want to do this, it is easy for me to do it in baselayout.

Thanks,

William



signature.asc
Description: Digital signature


  1   2   3   4   5   6   7   8   9   10   >