[gentoo-dev] [PATCH v2 4/4] sys-kernel/vanilla-kernel-bin: Migrate to kernel-install.eclass

2020-01-04 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 sys-kernel/vanilla-kernel-bin/Manifest|  2 +
 .../vanilla-kernel-bin-5.4.7-r1.ebuild| 52 +++
 2 files changed, 54 insertions(+)
 create mode 100644 
sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild

diff --git a/sys-kernel/vanilla-kernel-bin/Manifest 
b/sys-kernel/vanilla-kernel-bin/Manifest
index ec54297a6eee..6d408165e261 100644
--- a/sys-kernel/vanilla-kernel-bin/Manifest
+++ b/sys-kernel/vanilla-kernel-bin/Manifest
@@ -2,3 +2,5 @@ DIST tinycorelinux-10.1-amd64.qcow2 16842752 BLAKE2B 
e013e76503c335739a9623c0901
 DIST tinycorelinux-10.1-x86.qcow2 14876672 BLAKE2B 
3c760eb7438b13261e52ecfaa33a53649ced95f1ab40aae52134b8cdc31a16d7aa0d6a6dd716e268ed148e9d77a10b7c700b141b61d70c82d271ffe88e8e2a3c
 SHA512 
9964538dc42f232a11949f74b61d46422ea5da3bdc253a217119bd0b8a750c40fd2da0b07157067be9ac0226472614f210a1248114df0d331df390979867a895
 DIST vanilla-kernel-5.4.7-1.amd64.xpak 67980060 BLAKE2B 
6bff3c16edc33dc65eedc55290d83cd26bf23bcf70addff39f43ba0d2fe9a678bc8bd2ba259802c95032132dce14e6866f15c30d66c4be23d82b88fa7e33d2f1
 SHA512 
edad0f70a46d2398702beeed442a84818d9d34cbd057372ad1175e7c2d944d59f6c5dbe2731658ed4c74eb66ffc3dd542b2589b1e776095c457b6347872d3dc4
 DIST vanilla-kernel-5.4.7-1.x86.xpak 59512079 BLAKE2B 
be8b611d164cb0e17fc9232eebdd642ea3e7926acf0c8628dde6bfe4de9d5600fca8f33aeba039bffce574926d7f1dff5bfa9910ed42553fa168e6104207fa13
 SHA512 
9d2a59824f7ce0cd01ea5aced3a95c4e2ac44ca4ad82cf5997987f9b0df730650cb8c8c5a83476084e427af345ad4d5515eb996dd2db5d5c7fa21c0eb1d8871e
+DIST vanilla-kernel-5.4.7-r1-1.amd64.xpak 67962241 BLAKE2B 
4ed062c5fc7b2fc1c711a2deb642cfc14bb5dfe87df04bd4b512ab5aac3b9b1c3c1cfcae1cf36feeac27aa99b5ca1c89c51ce4ac79f8925ef8f7b4d68d0c629b
 SHA512 
322eced9f6e3a8d671598baeb406761c52de7bd82d6844fefd748e2a72d94e5cee77298d0381dd8a9ababafd5cb6b6b24c809b959b2c40c6eb64c7b9ee74941a
+DIST vanilla-kernel-5.4.7-r1-1.x86.xpak 59493734 BLAKE2B 
1788b96ea680bd53186a1982498d1ede762a0e9b60f995bc5ee8d8f116435765b5a6264badb714e99ac7201161762cca34418d57c8755e8ec36154869f954594
 SHA512 
0f09758840d88c170fd387165476ae293f5a7701d0ec0cd508d920196a580bc263b9cb3a93ab2afacf97761f6161c5e4bbc86cdc0a4f4e0c9ea0724e435866c9
diff --git a/sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild 
b/sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild
new file mode 100644
index ..39dfe68a2ff9
--- /dev/null
+++ b/sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild
@@ -0,0 +1,52 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit kernel-install
+
+MY_P=${PF/-bin/}-1
+DESCRIPTION="Pre-built vanilla Linux kernel"
+HOMEPAGE="https://www.kernel.org/;
+SRC_URI="
+   amd64? (
+   
https://dev.gentoo.org/~mgorny/binpkg/amd64/kernel/sys-kernel/vanilla-kernel/${MY_P}.xpak
+   -> ${MY_P}.amd64.xpak
+   )
+   x86? (
+   
https://dev.gentoo.org/~mgorny/binpkg/x86/kernel/sys-kernel/vanilla-kernel/${MY_P}.xpak
+   -> ${MY_P}.x86.xpak
+   )"
+S=${WORKDIR}
+
+LICENSE="GPL-2"
+KEYWORDS="~amd64 ~x86"
+
+RDEPEND="
+   !sys-kernel/vanilla-kernel:${SLOT}"
+
+QA_PREBUILT='*'
+
+pkg_pretend() {
+   mount-boot_pkg_pretend
+
+   ewarn "This is an experimental package.  The built kernel and/or 
initramfs"
+   ewarn "may not work at all or fail with your bootloader configuration.  
Please"
+   ewarn "make sure to keep a backup kernel available before testing it."
+}
+
+src_unpack() {
+   ebegin "Unpacking ${MY_P}.${ARCH}.xpak"
+   tar -x < <(xz -c -d --single-stream "${DISTDIR}/${MY_P}.${ARCH}.xpak")
+   eend ${?} || die "Unpacking ${MY_P} failed"
+}
+
+src_test() {
+   kernel-install_test "${PV}" \
+   
"${WORKDIR}/usr/src/linux-${PV}/$(kernel-install_get_image_path)" \
+   "lib/modules/${PV}"
+}
+
+src_install() {
+   mv * "${ED}" || die
+}
-- 
2.24.1




[gentoo-dev] [PATCH v2 2/4] kernel-build.eclass: Build logic for dist-kernels

2020-01-04 Thread Michał Górny
Introduce a new eclass that contains common logic for building
distribution kernels from source.

Signed-off-by: Michał Górny 
---
 eclass/kernel-build.eclass | 175 +
 1 file changed, 175 insertions(+)
 create mode 100644 eclass/kernel-build.eclass

Changed in v2: improved cross support, thanks to floppym

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
new file mode 100644
index ..028f0da8148e
--- /dev/null
+++ b/eclass/kernel-build.eclass
@@ -0,0 +1,175 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: kernel-build.eclass
+# @MAINTAINER:
+# Distribution Kernel Project 
+# @AUTHOR:
+# Michał Górny 
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Build mechanics for Distribution Kernels
+# @DESCRIPTION:
+# This eclass provides the logic to build a Distribution Kernel from
+# source and install it.  Post-install and test logic is inherited
+# from kernel-install.eclass.
+#
+# The ebuild must take care of unpacking the kernel sources, copying
+# an appropriate .config into them (e.g. in src_prepare()) and setting
+# correct S.  The eclass takes care of respecting savedconfig, building
+# the kernel and installing it along with its modules and subset
+# of sources needed to build external modules.
+
+if [[ ! ${_KERNEL_BUILD_ECLASS} ]]; then
+
+case "${EAPI:-0}" in
+   0|1|2|3|4|5|6)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   7)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+inherit savedconfig toolchain-funcs kernel-install
+
+BDEPEND="
+   sys-devel/bc
+   virtual/libelf"
+
+# @FUNCTION: kernel-build_src_configure
+# @DESCRIPTION:
+# Prepare the toolchain for building the kernel, get the default .config
+# or restore savedconfig, and get build tree configured for modprep.
+kernel-build_src_configure() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   # force ld.bfd if we can find it easily
+   local LD="$(tc-getLD)"
+   if type -P "${LD}.bfd" &>/dev/null; then
+   LD+=.bfd
+   fi
+
+   tc-export_build_env
+   MAKEARGS=(
+   V=1
+
+   HOSTCC="$(tc-getBUILD_CC)"
+   HOSTCXX="$(tc-getBUILD_CXX)"
+   HOSTCFLAGS="${BUILD_CFLAGS}"
+   HOSTLDFLAGS="${BUILD_LDFLAGS}"
+
+   CROSS_COMPILE=${CHOST}-
+   AS="$(tc-getAS)"
+   CC="$(tc-getCC)"
+   LD="${LD}"
+   AR="$(tc-getAR)"
+   NM="$(tc-getNM)"
+   STRIP=":"
+   OBJCOPY="$(tc-getOBJCOPY)"
+   OBJDUMP="$(tc-getOBJDUMP)"
+
+   # we need to pass it to override colliding Gentoo envvar
+   ARCH=$(tc-arch-kernel)
+   )
+
+   [[ -f .config ]] || die "Ebuild error: please copy default config into 
.config"
+   restore_config .config
+
+   mkdir -p "${WORKDIR}"/modprep || die
+   mv .config "${WORKDIR}"/modprep/ || die
+   emake O="${WORKDIR}"/modprep "${MAKEARGS[@]}" olddefconfig
+   emake O="${WORKDIR}"/modprep "${MAKEARGS[@]}" modules_prepare
+   cp -pR "${WORKDIR}"/modprep "${WORKDIR}"/build || die
+}
+
+# @FUNCTION: kernel-build_src_compile
+# @DESCRIPTION:
+# Compile the kernel sources.
+kernel-build_src_compile() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   emake O="${WORKDIR}"/build "${MAKEARGS[@]}" all
+}
+
+# @FUNCTION: kernel-build_src_test
+# @DESCRIPTION:
+# Test the built kernel via qemu.  This just wraps the logic
+# from kernel-install.eclass with the correct paths.
+kernel-build_src_test() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   emake O="${WORKDIR}"/build "${MAKEARGS[@]}" \
+   INSTALL_MOD_PATH="${T}" modules_install
+
+   kernel-install_test "${PV}" \
+   "${WORKDIR}/build/$(kernel-install_get_image_path)" \
+   "${T}/lib/modules/${PV}"
+}
+
+# @FUNCTION: kernel-build_src_install
+# @DESCRIPTION:
+# Install the built kernel along with subset of sources
+# into /usr/src/linux-${PV}.  Install the modules.  Save the config.
+kernel-build_src_install() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   # do not use 'make install' as it behaves differently based
+   # on what kind of installkernel is installed
+   emake O="${WORKDIR}"/build "${MAKEARGS[@]}" \
+   INSTALL_MOD_PATH="${ED}" modules_install
+
+   # note: we're using mv rather than doins to save space and time
+   # install main and arch-specific headers first, and scripts
+   local kern_arch=$(tc-arch-kernel)
+   dodir "/usr/src/linux-${PV}/arch/${kern_arch}"
+   mv include scripts "${ED}/usr/src/linux-${PV}/" || die
+   mv "arch/${kern_arch}/include" \
+   "${ED}/usr/src/linux-${PV}/arch/${kern_arch}/" || die
+
+   # remove 

[gentoo-dev] [PATCH v2 3/4] sys-kernel/vanilla-kernel: Migrate to kernel-build.eclass

2020-01-04 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 .../vanilla-kernel-5.4.7-r1.ebuild| 66 +++
 1 file changed, 66 insertions(+)
 create mode 100644 sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild

diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild 
b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild
new file mode 100644
index ..980ee832584f
--- /dev/null
+++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild
@@ -0,0 +1,66 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit kernel-build
+
+MY_P=linux-${PV}
+AMD64_CONFIG_VER=5.4.7.arch1-1
+AMD64_CONFIG_HASH=ff79453bc0451a9083bdaa02c3901372d61a9982
+I686_CONFIG_VER=5.4.3-arch1
+I686_CONFIG_HASH=076a52d43a08c4b3a3eacd1f2f9a855fb3b62f42
+
+DESCRIPTION="Linux kernel built from vanilla upstream sources"
+HOMEPAGE="https://www.kernel.org/;
+SRC_URI+=" https://cdn.kernel.org/pub/linux/kernel/v5.x/${MY_P}.tar.xz
+   amd64? (
+   
https://git.archlinux.org/svntogit/packages.git/plain/trunk/config?h=packages/linux=${AMD64_CONFIG_HASH}
+   -> linux-${AMD64_CONFIG_VER}.amd64.config
+   )
+   x86? (
+   
https://git.archlinux32.org/packages/plain/core/linux/config.i686?id=${I686_CONFIG_HASH}
+   -> linux-${I686_CONFIG_VER}.i686.config
+   )"
+S=${WORKDIR}/${MY_P}
+
+LICENSE="GPL-2"
+KEYWORDS="~amd64 ~x86"
+
+RDEPEND="
+   !sys-kernel/vanilla-kernel-bin:${SLOT}"
+
+pkg_pretend() {
+   mount-boot_pkg_pretend
+
+   ewarn "This is an experimental package.  The built kernel and/or 
initramfs"
+   ewarn "may not work at all or fail with your bootloader configuration.  
Please"
+   ewarn "make sure to keep a backup kernel available before testing it."
+}
+
+src_prepare() {
+   default
+
+   # prepare the default config
+   case ${ARCH} in
+   amd64)
+   cp "${DISTDIR}"/linux-${AMD64_CONFIG_VER}.amd64.config 
.config || die
+   ;;
+   x86)
+   cp "${DISTDIR}"/linux-${I686_CONFIG_VER}.i686.config 
.config || die
+   ;;
+   *)
+   die "Unsupported arch ${ARCH}"
+   ;;
+   esac
+
+   # while Arch config is cool, we don't want gcc plugins as they
+   # break distcc
+   sed -i -e '/GCC_PLUGIN/d' .config || die
+   # module compression prevents us from stripping them post-inst
+   sed -i -e '/MODULE_COMPRESS/d' .config || die
+   # shove our theft under the carpet!
+   sed -i -e '/HOSTNAME/s:archlinux:gentoo:' .config || die
+   # hey, we do support x32
+   sed -i -e '/CONFIG_X86_X32/s:.*:CONFIG_X86_X32=y:' .config || die
+}
-- 
2.24.1




[gentoo-dev] [PATCH v2 1/4] kernel-install.eclass: Install logic for dist-kernels

2020-01-04 Thread Michał Górny
Introduce a new eclass that contains common logic needed to test
and install distribution kernels.  This is the eclass common both
to kernels built from source and installed from binary packages.

Signed-off-by: Michał Górny 
---
 eclass/kernel-install.eclass | 309 +++
 1 file changed, 309 insertions(+)
 create mode 100644 eclass/kernel-install.eclass

diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
new file mode 100644
index ..f64e01976a7b
--- /dev/null
+++ b/eclass/kernel-install.eclass
@@ -0,0 +1,309 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: kernel-install.eclass
+# @MAINTAINER:
+# Distribution Kernel Project 
+# @AUTHOR:
+# Michał Górny 
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Installation mechanics for Distribution Kernels
+# @DESCRIPTION:
+# This eclass provides the logic needed to test and install different
+# kinds of Distribution Kernel packages, including both kernels built
+# from source and distributed as binaries.  The eclass relies on the
+# ebuild installing a subset of built kernel tree into
+# /usr/src/linux-${PV} containing the kernel image in its standard
+# location and System.map.
+#
+# The eclass exports src_test, pkg_postinst and pkg_postrm.
+# Additionally, the inherited mount-boot eclass exports pkg_pretend.
+# It also stubs out pkg_preinst and pkg_prerm defined by mount-boot.
+
+if [[ ! ${_KERNEL_INSTALL_ECLASS} ]]; then
+
+case "${EAPI:-0}" in
+   0|1|2|3|4|5|6)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   7)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+inherit mount-boot
+
+TCL_VER=10.1
+SRC_URI+="
+   test? (
+   amd64? (
+   
https://dev.gentoo.org/~mgorny/dist/tinycorelinux-${TCL_VER}-amd64.qcow2
+   )
+   x86? (
+   
https://dev.gentoo.org/~mgorny/dist/tinycorelinux-${TCL_VER}-x86.qcow2
+   )
+   )"
+
+SLOT="${PV}"
+IUSE="+initramfs test"
+RESTRICT+=" !test? ( test ) test? ( userpriv )"
+
+# install-DEPEND actually
+# note: we need installkernel with initramfs support!
+RDEPEND="
+   || (
+   sys-kernel/installkernel-gentoo
+   sys-kernel/installkernel-systemd-boot
+   )
+   initramfs? ( >=sys-kernel/dracut-049-r3 )"
+BDEPEND="
+   test? (
+   dev-tcltk/expect
+   sys-kernel/dracut
+   amd64? ( app-emulation/qemu[qemu_softmmu_targets_x86_64] )
+   x86? ( app-emulation/qemu[qemu_softmmu_targets_i386] )
+   )"
+
+# @FUNCTION: kernel-install_build_initramfs
+# @USAGE:  
+# @DESCRIPTION:
+# Build an initramfs for the kernel.   specifies the absolute
+# path where initramfs will be created, while  specifies
+# the kernel version, used to find modules.
+kernel-install_build_initramfs() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   [[ ${#} -eq 2 ]] || die "${FUNCNAME}: invalid arguments"
+   local output=${1}
+   local version=${2}
+
+   ebegin "Building initramfs via dracut"
+   dracut --force "${output}" "${version}"
+   eend ${?} || die "Building initramfs failed"
+}
+
+# @FUNCTION: kernel-install_get_image_path
+# @DESCRIPTION:
+# Get relative kernel image path specific to the current ${ARCH}.
+kernel-install_get_image_path() {
+   case ${ARCH} in
+   amd64|x86)
+   echo arch/x86/boot/bzImage
+   ;;
+   *)
+   die "${FUNCNAME}: unsupported ARCH=${ARCH}"
+   ;;
+   esac
+}
+
+# @FUNCTION: kernel-install_install_kernel
+# @USAGE:   
+# @DESCRIPTION:
+# Install kernel using installkernel tool.   specifies
+# the kernel version,  full path to the image, 
+# full path to System.map.
+kernel-install_install_kernel() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   [[ ${#} -eq 3 ]] || die "${FUNCNAME}: invalid arguments"
+   local version=${1}
+   local image=${2}
+   local map=${3}
+
+   ebegin "Installing the kernel via installkernel"
+   # note: .config is taken relatively to System.map;
+   # initrd relatively to bzImage
+   installkernel "${version}" "${image}" "${map}"
+   eend ${?} || die "Installing the kernel failed"
+}
+
+# @FUNCTION: kernel-install_update_symlink
+# @USAGE:  
+# @DESCRIPTION:
+# Update the kernel source symlink at  (full path) with a link
+# to - if it's either missing or pointing out to
+# an older version of this package.
+kernel-install_update_symlink() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   [[ ${#} -eq 2 ]] || die "${FUNCNAME}: invalid arguments"
+   local target=${1}
+   local version=${2}
+
+   if [[ ! -e ${target} ]]; then
+   ebegin "Creating 

Re: [gentoo-dev] [PATCH 2/4] kernel-build.eclass: Build logic for dist-kernels

2020-01-04 Thread Michał Górny
On Sat, 2020-01-04 at 18:41 -0500, Mike Gilbert wrote:
> On Sat, Jan 4, 2020 at 4:24 PM Michał Górny  wrote:
> > +# @FUNCTION: kernel-build_src_configure
> > +# @DESCRIPTION:
> > +# Prepare the toolchain for building the kernel, get the default .config
> > +# or restore savedconfig, and get build tree configured for modprep.
> > +kernel-build_src_configure() {
> > +   debug-print-function ${FUNCNAME} "${@}"
> > +
> > +   # force ld.bfd if we can find it easily
> > +   local LD="$(tc-getLD)"
> > +   if type -P "${LD}.bfd" &>/dev/null; then
> > +   LD+=.bfd
> > +   fi
> > +
> > +   MAKEARGS=(
> > +   V=1
> > +
> > +   HOSTCC="$(tc-getCC)"
> > +   HOSTCXX="$(tc-getCXX)"
> > +   HOSTCFLAGS="${CFLAGS}"
> > +   HOSTLDFLAGS="${LDFLAGS}"
> 
> I think the HOST variables should reference the CBUILD toolchain. Example 
> below.
> 
> # Sets BUILD_CFLAGS and BUILD_LDFLAGS if not set in make.conf.
> tc-export_build_env
> 
> HOSTCC="$(tc-getBUILD_CC)"
> HOSTCXX="$(tc-getBUILD_CXX)"
> HOSTCFLAGS="${BUILD_CFLAGS}"
> HOSTLDFLAGS="${BUILD_LDFLAGS}"
> 

Yeah, I was supposed to fix this and I've forgotten.  Thanks for doing
the work for me ;-).

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

2020-01-04 Thread Jason A. Donenfeld
On Sat, Jan 4, 2020 at 9:33 PM Aaron Bauman  wrote:
>
> On Sat, Jan 04, 2020 at 09:11:01PM -0500, Jason A. Donenfeld wrote:
> > Hi,
> >
> > I'd appreciate some code review of this before I commit.
> >
> > Thanks,
> > Jason
> >
>
> Silence is consent.

Maybe. But there's quite a bit of this that I look at and think,
"that's not necessary, let me just trim this all down to something
much smaller..." And then I start to wonder whether the original
authors have already been through several bug-fixing cycles when they
added all that. So I'd like to avoid repeating that exercise if
possible.



Re: [gentoo-dev] Re: [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

2020-01-04 Thread Aaron Bauman
On Sat, Jan 04, 2020 at 09:11:01PM -0500, Jason A. Donenfeld wrote:
> Hi,
> 
> I'd appreciate some code review of this before I commit.
> 
> Thanks,
> Jason
> 

Silence is consent. I also don't know the original authors are even Gentoo devs
anymore...

-- 
Cheers,
Aaron


signature.asc
Description: PGP 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




[gentoo-dev] Re: [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

2020-01-04 Thread Jason A. Donenfeld
Hi,

I'd appreciate some code review of this before I commit.

Thanks,
Jason



Re: [gentoo-dev] [PATCH 2/4] kernel-build.eclass: Build logic for dist-kernels

2020-01-04 Thread Mike Gilbert
On Sat, Jan 4, 2020 at 4:24 PM Michał Górny  wrote:
> +# @FUNCTION: kernel-build_src_configure
> +# @DESCRIPTION:
> +# Prepare the toolchain for building the kernel, get the default .config
> +# or restore savedconfig, and get build tree configured for modprep.
> +kernel-build_src_configure() {
> +   debug-print-function ${FUNCNAME} "${@}"
> +
> +   # force ld.bfd if we can find it easily
> +   local LD="$(tc-getLD)"
> +   if type -P "${LD}.bfd" &>/dev/null; then
> +   LD+=.bfd
> +   fi
> +
> +   MAKEARGS=(
> +   V=1
> +
> +   HOSTCC="$(tc-getCC)"
> +   HOSTCXX="$(tc-getCXX)"
> +   HOSTCFLAGS="${CFLAGS}"
> +   HOSTLDFLAGS="${LDFLAGS}"

I think the HOST variables should reference the CBUILD toolchain. Example below.

# Sets BUILD_CFLAGS and BUILD_LDFLAGS if not set in make.conf.
tc-export_build_env

HOSTCC="$(tc-getBUILD_CC)"
HOSTCXX="$(tc-getBUILD_CXX)"
HOSTCFLAGS="${BUILD_CFLAGS}"
HOSTLDFLAGS="${BUILD_LDFLAGS}"



[gentoo-dev] Last rites: media-plugins/vdr-* mass masking

2020-01-04 Thread Joerg Bornkessel
Before looking at the complete list, some words from me:
All packages have been carefully selected and checked.
Many packages have been abandoned by upstream and only live on user
provided patches.
I also looked at the Debian and Archlinux colleagues,
what they did in their repos.
The bug https://bugs.gentoo.org/703944 was previously in the
vdr-portal.de put up for discussion.
It is not my intention to make users unhappy using certain packages. If
user patches are submitted later, it is possible to keep the packages in
the tree.
The list is not written in stone ...

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# The Maintainer give up this projecet and
# it is dead on upstream since ~2008
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 703900
media-plugins/vdr-fepg

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# This plugin is dead on upstream
# No HOMEPAGE and upstream SRC_URI
# You could use as replacement for this plugin
# media-plugins/vdr-devstatus
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 703962
media-plugins/vdr-recstatus

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# This plugin is dead on upstream
# request about the project status to upstream was
# not answered
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 703966
media-plugins/vdr-zaphistory

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# This plugin is for an a very old version of
# media-video/vdr
# dead on upstream
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 703970
media-plugins/vdr-wapd

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# No Homepage and upstream SRC_URI
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 703972
media-plugins/vdr-nordlichtsepg

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# This plugin is for an a very old version of
# media-video/vdr
# No upstream available
# No Homepage and SRC_URI
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 703974
media-plugins/vdr-pilotskin


# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# several open bugs on upstream, the oldest is from
# ~2010, the latest is from ~2016
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 703990
media-plugins/vdr-sudoku


# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# there are several open bugs up from ~2010 on
# upstream
# request about the project status to upstream was
# not answered
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 704000
media-plugins/vdr-pvrinput

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# this plugin is from ~2008 and depends on a very
# old version of vdr
# As there is no upstream email, it is not possible to
# request for fixing this issues
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 704006
media-plugins/vdr-lcr


# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# This plugin needs a KDE kicker applet
# We do not have this applet in the tree anymore
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 704008
media-plugins/vdr-kvdrmon

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# Requested to upstream, pstream answered to this:
# “vdr-infosatepg was useful many years ago.
# today it delivers only additional EPG
# for "Eurosport" channel.”
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 704010
media-plugins/vdr-infosatepg

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# This plugin is from ~2004
# An Upstream url and src_uri is not available
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 704014
media-plugins/vdr-extb


# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# this plugin is from ~2005 and depends
# on a very old version of vdr
# No upstream is available
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 704016
media-plugins/vdr-decruft

# Joerg Bornkessel  (2020-01-04)
# plugin is broken by update to
# media-video/vdr-2.4.x
# The last commit on upstream is from ~2012
# request about the project status to upstream was
# not answered
# https://projects.vdr-developer.org/issues/2597
# No packages have a reverse RDEPEND on it
# removal from tree ~4 Feb 2020
# wrt bug 704018

[gentoo-dev] [PATCH 4/4] sys-kernel/vanilla-kernel-bin: Migrate to kernel-install.eclass

2020-01-04 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 sys-kernel/vanilla-kernel-bin/Manifest|  2 +
 .../vanilla-kernel-bin-5.4.7-r1.ebuild| 52 +++
 2 files changed, 54 insertions(+)
 create mode 100644 
sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild

diff --git a/sys-kernel/vanilla-kernel-bin/Manifest 
b/sys-kernel/vanilla-kernel-bin/Manifest
index ec54297a6eee..6d408165e261 100644
--- a/sys-kernel/vanilla-kernel-bin/Manifest
+++ b/sys-kernel/vanilla-kernel-bin/Manifest
@@ -2,3 +2,5 @@ DIST tinycorelinux-10.1-amd64.qcow2 16842752 BLAKE2B 
e013e76503c335739a9623c0901
 DIST tinycorelinux-10.1-x86.qcow2 14876672 BLAKE2B 
3c760eb7438b13261e52ecfaa33a53649ced95f1ab40aae52134b8cdc31a16d7aa0d6a6dd716e268ed148e9d77a10b7c700b141b61d70c82d271ffe88e8e2a3c
 SHA512 
9964538dc42f232a11949f74b61d46422ea5da3bdc253a217119bd0b8a750c40fd2da0b07157067be9ac0226472614f210a1248114df0d331df390979867a895
 DIST vanilla-kernel-5.4.7-1.amd64.xpak 67980060 BLAKE2B 
6bff3c16edc33dc65eedc55290d83cd26bf23bcf70addff39f43ba0d2fe9a678bc8bd2ba259802c95032132dce14e6866f15c30d66c4be23d82b88fa7e33d2f1
 SHA512 
edad0f70a46d2398702beeed442a84818d9d34cbd057372ad1175e7c2d944d59f6c5dbe2731658ed4c74eb66ffc3dd542b2589b1e776095c457b6347872d3dc4
 DIST vanilla-kernel-5.4.7-1.x86.xpak 59512079 BLAKE2B 
be8b611d164cb0e17fc9232eebdd642ea3e7926acf0c8628dde6bfe4de9d5600fca8f33aeba039bffce574926d7f1dff5bfa9910ed42553fa168e6104207fa13
 SHA512 
9d2a59824f7ce0cd01ea5aced3a95c4e2ac44ca4ad82cf5997987f9b0df730650cb8c8c5a83476084e427af345ad4d5515eb996dd2db5d5c7fa21c0eb1d8871e
+DIST vanilla-kernel-5.4.7-r1-1.amd64.xpak 67962241 BLAKE2B 
4ed062c5fc7b2fc1c711a2deb642cfc14bb5dfe87df04bd4b512ab5aac3b9b1c3c1cfcae1cf36feeac27aa99b5ca1c89c51ce4ac79f8925ef8f7b4d68d0c629b
 SHA512 
322eced9f6e3a8d671598baeb406761c52de7bd82d6844fefd748e2a72d94e5cee77298d0381dd8a9ababafd5cb6b6b24c809b959b2c40c6eb64c7b9ee74941a
+DIST vanilla-kernel-5.4.7-r1-1.x86.xpak 59493734 BLAKE2B 
1788b96ea680bd53186a1982498d1ede762a0e9b60f995bc5ee8d8f116435765b5a6264badb714e99ac7201161762cca34418d57c8755e8ec36154869f954594
 SHA512 
0f09758840d88c170fd387165476ae293f5a7701d0ec0cd508d920196a580bc263b9cb3a93ab2afacf97761f6161c5e4bbc86cdc0a4f4e0c9ea0724e435866c9
diff --git a/sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild 
b/sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild
new file mode 100644
index ..39dfe68a2ff9
--- /dev/null
+++ b/sys-kernel/vanilla-kernel-bin/vanilla-kernel-bin-5.4.7-r1.ebuild
@@ -0,0 +1,52 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit kernel-install
+
+MY_P=${PF/-bin/}-1
+DESCRIPTION="Pre-built vanilla Linux kernel"
+HOMEPAGE="https://www.kernel.org/;
+SRC_URI="
+   amd64? (
+   
https://dev.gentoo.org/~mgorny/binpkg/amd64/kernel/sys-kernel/vanilla-kernel/${MY_P}.xpak
+   -> ${MY_P}.amd64.xpak
+   )
+   x86? (
+   
https://dev.gentoo.org/~mgorny/binpkg/x86/kernel/sys-kernel/vanilla-kernel/${MY_P}.xpak
+   -> ${MY_P}.x86.xpak
+   )"
+S=${WORKDIR}
+
+LICENSE="GPL-2"
+KEYWORDS="~amd64 ~x86"
+
+RDEPEND="
+   !sys-kernel/vanilla-kernel:${SLOT}"
+
+QA_PREBUILT='*'
+
+pkg_pretend() {
+   mount-boot_pkg_pretend
+
+   ewarn "This is an experimental package.  The built kernel and/or 
initramfs"
+   ewarn "may not work at all or fail with your bootloader configuration.  
Please"
+   ewarn "make sure to keep a backup kernel available before testing it."
+}
+
+src_unpack() {
+   ebegin "Unpacking ${MY_P}.${ARCH}.xpak"
+   tar -x < <(xz -c -d --single-stream "${DISTDIR}/${MY_P}.${ARCH}.xpak")
+   eend ${?} || die "Unpacking ${MY_P} failed"
+}
+
+src_test() {
+   kernel-install_test "${PV}" \
+   
"${WORKDIR}/usr/src/linux-${PV}/$(kernel-install_get_image_path)" \
+   "lib/modules/${PV}"
+}
+
+src_install() {
+   mv * "${ED}" || die
+}
-- 
2.24.1




[gentoo-dev] [PATCH 3/4] sys-kernel/vanilla-kernel: Migrate to kernel-build.eclass

2020-01-04 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 .../vanilla-kernel-5.4.7-r1.ebuild| 66 +++
 1 file changed, 66 insertions(+)
 create mode 100644 sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild

diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild 
b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild
new file mode 100644
index ..980ee832584f
--- /dev/null
+++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.7-r1.ebuild
@@ -0,0 +1,66 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit kernel-build
+
+MY_P=linux-${PV}
+AMD64_CONFIG_VER=5.4.7.arch1-1
+AMD64_CONFIG_HASH=ff79453bc0451a9083bdaa02c3901372d61a9982
+I686_CONFIG_VER=5.4.3-arch1
+I686_CONFIG_HASH=076a52d43a08c4b3a3eacd1f2f9a855fb3b62f42
+
+DESCRIPTION="Linux kernel built from vanilla upstream sources"
+HOMEPAGE="https://www.kernel.org/;
+SRC_URI+=" https://cdn.kernel.org/pub/linux/kernel/v5.x/${MY_P}.tar.xz
+   amd64? (
+   
https://git.archlinux.org/svntogit/packages.git/plain/trunk/config?h=packages/linux=${AMD64_CONFIG_HASH}
+   -> linux-${AMD64_CONFIG_VER}.amd64.config
+   )
+   x86? (
+   
https://git.archlinux32.org/packages/plain/core/linux/config.i686?id=${I686_CONFIG_HASH}
+   -> linux-${I686_CONFIG_VER}.i686.config
+   )"
+S=${WORKDIR}/${MY_P}
+
+LICENSE="GPL-2"
+KEYWORDS="~amd64 ~x86"
+
+RDEPEND="
+   !sys-kernel/vanilla-kernel-bin:${SLOT}"
+
+pkg_pretend() {
+   mount-boot_pkg_pretend
+
+   ewarn "This is an experimental package.  The built kernel and/or 
initramfs"
+   ewarn "may not work at all or fail with your bootloader configuration.  
Please"
+   ewarn "make sure to keep a backup kernel available before testing it."
+}
+
+src_prepare() {
+   default
+
+   # prepare the default config
+   case ${ARCH} in
+   amd64)
+   cp "${DISTDIR}"/linux-${AMD64_CONFIG_VER}.amd64.config 
.config || die
+   ;;
+   x86)
+   cp "${DISTDIR}"/linux-${I686_CONFIG_VER}.i686.config 
.config || die
+   ;;
+   *)
+   die "Unsupported arch ${ARCH}"
+   ;;
+   esac
+
+   # while Arch config is cool, we don't want gcc plugins as they
+   # break distcc
+   sed -i -e '/GCC_PLUGIN/d' .config || die
+   # module compression prevents us from stripping them post-inst
+   sed -i -e '/MODULE_COMPRESS/d' .config || die
+   # shove our theft under the carpet!
+   sed -i -e '/HOSTNAME/s:archlinux:gentoo:' .config || die
+   # hey, we do support x32
+   sed -i -e '/CONFIG_X86_X32/s:.*:CONFIG_X86_X32=y:' .config || die
+}
-- 
2.24.1




[gentoo-dev] [PATCH 2/4] kernel-build.eclass: Build logic for dist-kernels

2020-01-04 Thread Michał Górny
Introduce a new eclass that contains common logic for building
distribution kernels from source.

Signed-off-by: Michał Górny 
---
 eclass/kernel-build.eclass | 173 +
 1 file changed, 173 insertions(+)
 create mode 100644 eclass/kernel-build.eclass

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
new file mode 100644
index ..b5e520b3bed2
--- /dev/null
+++ b/eclass/kernel-build.eclass
@@ -0,0 +1,173 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: kernel-build.eclass
+# @MAINTAINER:
+# Distribution Kernel Project 
+# @AUTHOR:
+# Michał Górny 
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Build mechanics for Distribution Kernels
+# @DESCRIPTION:
+# This eclass provides the logic to build a Distribution Kernel from
+# source and install it.  Post-install and test logic is inherited
+# from kernel-install.eclass.
+#
+# The ebuild must take care of unpacking the kernel sources, copying
+# an appropriate .config into them (e.g. in src_prepare()) and setting
+# correct S.  The eclass takes care of respecting savedconfig, building
+# the kernel and installing it along with its modules and subset
+# of sources needed to build external modules.
+
+if [[ ! ${_KERNEL_BUILD_ECLASS} ]]; then
+
+case "${EAPI:-0}" in
+   0|1|2|3|4|5|6)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   7)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+inherit savedconfig toolchain-funcs kernel-install
+
+BDEPEND="
+   sys-devel/bc
+   virtual/libelf"
+
+# @FUNCTION: kernel-build_src_configure
+# @DESCRIPTION:
+# Prepare the toolchain for building the kernel, get the default .config
+# or restore savedconfig, and get build tree configured for modprep.
+kernel-build_src_configure() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   # force ld.bfd if we can find it easily
+   local LD="$(tc-getLD)"
+   if type -P "${LD}.bfd" &>/dev/null; then
+   LD+=.bfd
+   fi
+
+   MAKEARGS=(
+   V=1
+
+   HOSTCC="$(tc-getCC)"
+   HOSTCXX="$(tc-getCXX)"
+   HOSTCFLAGS="${CFLAGS}"
+   HOSTLDFLAGS="${LDFLAGS}"
+
+   AS="$(tc-getAS)"
+   CC="$(tc-getCC)"
+   LD="${LD}"
+   AR="$(tc-getAR)"
+   NM="$(tc-getNM)"
+   STRIP=":"
+   OBJCOPY="$(tc-getOBJCOPY)"
+   OBJDUMP="$(tc-getOBJDUMP)"
+
+   # we need to pass it to override colliding Gentoo envvar
+   ARCH=$(tc-arch-kernel)
+   )
+
+   [[ -f .config ]] || die "Ebuild error: please copy default config into 
.config"
+   restore_config .config
+
+   mkdir -p "${WORKDIR}"/modprep || die
+   mv .config "${WORKDIR}"/modprep/ || die
+   emake O="${WORKDIR}"/modprep "${MAKEARGS[@]}" olddefconfig
+   emake O="${WORKDIR}"/modprep "${MAKEARGS[@]}" modules_prepare
+   cp -pR "${WORKDIR}"/modprep "${WORKDIR}"/build || die
+}
+
+# @FUNCTION: kernel-build_src_compile
+# @DESCRIPTION:
+# Compile the kernel sources.
+kernel-build_src_compile() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   emake O="${WORKDIR}"/build "${MAKEARGS[@]}" all
+}
+
+# @FUNCTION: kernel-build_src_test
+# @DESCRIPTION:
+# Test the built kernel via qemu.  This just wraps the logic
+# from kernel-install.eclass with the correct paths.
+kernel-build_src_test() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   emake O="${WORKDIR}"/build "${MAKEARGS[@]}" \
+   INSTALL_MOD_PATH="${T}" modules_install
+
+   kernel-install_test "${PV}" \
+   "${WORKDIR}/build/$(kernel-install_get_image_path)" \
+   "${T}/lib/modules/${PV}"
+}
+
+# @FUNCTION: kernel-build_src_install
+# @DESCRIPTION:
+# Install the built kernel along with subset of sources
+# into /usr/src/linux-${PV}.  Install the modules.  Save the config.
+kernel-build_src_install() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   # do not use 'make install' as it behaves differently based
+   # on what kind of installkernel is installed
+   emake O="${WORKDIR}"/build "${MAKEARGS[@]}" \
+   INSTALL_MOD_PATH="${ED}" modules_install
+
+   # note: we're using mv rather than doins to save space and time
+   # install main and arch-specific headers first, and scripts
+   local kern_arch=$(tc-arch-kernel)
+   dodir "/usr/src/linux-${PV}/arch/${kern_arch}"
+   mv include scripts "${ED}/usr/src/linux-${PV}/" || die
+   mv "arch/${kern_arch}/include" \
+   "${ED}/usr/src/linux-${PV}/arch/${kern_arch}/" || die
+
+   # remove everything but Makefile* and Kconfig*
+   find -type f '!' '(' -name 'Makefile*' -o -name 'Kconfig*' ')' \
+   -delete || die
+   

[gentoo-dev] [PATCH 1/4] kernel-install.eclass: Install logic for dist-kernels

2020-01-04 Thread Michał Górny
Introduce a new eclass that contains common logic needed to test
and install distribution kernels.  This is the eclass common both
to kernels built from source and installed from binary packages.

Signed-off-by: Michał Górny 
---
 eclass/kernel-install.eclass | 309 +++
 1 file changed, 309 insertions(+)
 create mode 100644 eclass/kernel-install.eclass

diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
new file mode 100644
index ..f64e01976a7b
--- /dev/null
+++ b/eclass/kernel-install.eclass
@@ -0,0 +1,309 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: kernel-install.eclass
+# @MAINTAINER:
+# Distribution Kernel Project 
+# @AUTHOR:
+# Michał Górny 
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Installation mechanics for Distribution Kernels
+# @DESCRIPTION:
+# This eclass provides the logic needed to test and install different
+# kinds of Distribution Kernel packages, including both kernels built
+# from source and distributed as binaries.  The eclass relies on the
+# ebuild installing a subset of built kernel tree into
+# /usr/src/linux-${PV} containing the kernel image in its standard
+# location and System.map.
+#
+# The eclass exports src_test, pkg_postinst and pkg_postrm.
+# Additionally, the inherited mount-boot eclass exports pkg_pretend.
+# It also stubs out pkg_preinst and pkg_prerm defined by mount-boot.
+
+if [[ ! ${_KERNEL_INSTALL_ECLASS} ]]; then
+
+case "${EAPI:-0}" in
+   0|1|2|3|4|5|6)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   7)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+inherit mount-boot
+
+TCL_VER=10.1
+SRC_URI+="
+   test? (
+   amd64? (
+   
https://dev.gentoo.org/~mgorny/dist/tinycorelinux-${TCL_VER}-amd64.qcow2
+   )
+   x86? (
+   
https://dev.gentoo.org/~mgorny/dist/tinycorelinux-${TCL_VER}-x86.qcow2
+   )
+   )"
+
+SLOT="${PV}"
+IUSE="+initramfs test"
+RESTRICT+=" !test? ( test ) test? ( userpriv )"
+
+# install-DEPEND actually
+# note: we need installkernel with initramfs support!
+RDEPEND="
+   || (
+   sys-kernel/installkernel-gentoo
+   sys-kernel/installkernel-systemd-boot
+   )
+   initramfs? ( >=sys-kernel/dracut-049-r3 )"
+BDEPEND="
+   test? (
+   dev-tcltk/expect
+   sys-kernel/dracut
+   amd64? ( app-emulation/qemu[qemu_softmmu_targets_x86_64] )
+   x86? ( app-emulation/qemu[qemu_softmmu_targets_i386] )
+   )"
+
+# @FUNCTION: kernel-install_build_initramfs
+# @USAGE:  
+# @DESCRIPTION:
+# Build an initramfs for the kernel.   specifies the absolute
+# path where initramfs will be created, while  specifies
+# the kernel version, used to find modules.
+kernel-install_build_initramfs() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   [[ ${#} -eq 2 ]] || die "${FUNCNAME}: invalid arguments"
+   local output=${1}
+   local version=${2}
+
+   ebegin "Building initramfs via dracut"
+   dracut --force "${output}" "${version}"
+   eend ${?} || die "Building initramfs failed"
+}
+
+# @FUNCTION: kernel-install_get_image_path
+# @DESCRIPTION:
+# Get relative kernel image path specific to the current ${ARCH}.
+kernel-install_get_image_path() {
+   case ${ARCH} in
+   amd64|x86)
+   echo arch/x86/boot/bzImage
+   ;;
+   *)
+   die "${FUNCNAME}: unsupported ARCH=${ARCH}"
+   ;;
+   esac
+}
+
+# @FUNCTION: kernel-install_install_kernel
+# @USAGE:   
+# @DESCRIPTION:
+# Install kernel using installkernel tool.   specifies
+# the kernel version,  full path to the image, 
+# full path to System.map.
+kernel-install_install_kernel() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   [[ ${#} -eq 3 ]] || die "${FUNCNAME}: invalid arguments"
+   local version=${1}
+   local image=${2}
+   local map=${3}
+
+   ebegin "Installing the kernel via installkernel"
+   # note: .config is taken relatively to System.map;
+   # initrd relatively to bzImage
+   installkernel "${version}" "${image}" "${map}"
+   eend ${?} || die "Installing the kernel failed"
+}
+
+# @FUNCTION: kernel-install_update_symlink
+# @USAGE:  
+# @DESCRIPTION:
+# Update the kernel source symlink at  (full path) with a link
+# to - if it's either missing or pointing out to
+# an older version of this package.
+kernel-install_update_symlink() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   [[ ${#} -eq 2 ]] || die "${FUNCNAME}: invalid arguments"
+   local target=${1}
+   local version=${2}
+
+   if [[ ! -e ${target} ]]; then
+   ebegin "Creating 

Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Sat, Jan 4, 2020 at 3:13 PM Christopher Head  wrote:
>
>
> Of course this would be a bad argument if V-S were lagging behind upstream 
> significantly, and it’s a much better argument for packages that come with 
> expectations of security team support than those that don’t, but it is 
> something to consider.
>

This was my main concern when it was mentioned that it wasn't
security-supported.

If it is always up-to-date that definitely helps mitigate things.
Though, there should definitely be some kind of warning on the package
that it isn't security supported.  Even if it is up to date it won't
get GLSAs and GLSA-checker won't work.  Though, that really only makes
a difference insofar as the GLSAs are also timely.

In any case, if the just-announced distribution kernel project takes
off and remains active I could easily see that becoming the most
commonly used kernel option.  I'm not knocking minimal kernels but I
suspect a LOT of users are going to be well-served by a modular kernel
that just works 99% of the time.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Christopher Head
On January 4, 2020 4:54:07 AM PST, Rich Freeman  wrote:
>
>Uh, all it does is install kernel sources.  They're useless unless you
>build a kernel using them.
>
>Apparently git and tar are too complicated for Gentoo users, but
>managing symlinks, using make, managing a bootloader, dealing with the
>kernel's configuration system, and so on are just fine?

I use gentoo-sources myself, but still, I would like to propose one reason for 
keeping vanilla-sources. For me, git/tar are not too complicated, but having 
V-S in the Gentoo tree would provide another benefit: reducing the number of 
things I have to check every weekly update cycle. Every piece of software I get 
from a source other than the Gentoo tree is another website I have to visit 
every update day to check whether there’s a newer version available. So from 
that perspective, the advantage of having packages in tree that just install 
some files is that emerge tells me when a new version is available, rather than 
me having to go every week to upstream’s website and check manually (or sign up 
for countless announcement mailing lists).

Of course this would be a bad argument if V-S were lagging behind upstream 
significantly, and it’s a much better argument for packages that come with 
expectations of security team support than those that don’t, but it is 
something to consider.

-- 
Christopher Head

signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rolf Eike Beer
Am Samstag, 4. Januar 2020, 19:41:05 CET schrieb 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.

Bad idea. If you wonder why: eshowkw dev-lang/rust.

Eike

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: net-misc/chrome-remote-desktop

2020-01-04 Thread Mike Gilbert
# Mike Gilbert  (2020-01-04)
# Un-fetchable distfile, bug 704782.
# No maintainer.
# Removal in 30 days.
net-misc/chrome-remote-desktop



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Michał Górny
On Sat, 2020-01-04 at 12:41 -0600, William Hubbs wrote:
> 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.
> 

You could also force people to install systemd.  That would be more
merciful.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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 Michał Górny
On Sat, 2020-01-04 at 08:38 +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?

Yes, we should.  This really sounds like some horror where developers
are hacking things around in sources instead of communicating with
people maintaining the component where a proper fix belongs.

> 
> As far as I understand this from the thread by now, these are set by
> default by Gentoo Sources. So we shouldn't really expect much breakage
> if we set them via sysctl.
> 
> 

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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


[gentoo-dev] Historical devmanual sources?

2020-01-04 Thread Ulrich Mueller
Currently the devmanual git repository contains the history (converted
from subversion) back to 2006-02-20, but apart from two snapshots in
July and August 2005, we don't have anything from before. The wayback
machine has only an incomplete archive of the generated html [1].

Can anybody help? Any information about an early source code repository
or even snapshots of the sources would be welcome. Note that the sources
at the time would still be in reStructuredText (*.rst).

Ulrich

[1] 
https://web.archive.org/web/20050507124548/http://www.firedrop.org.uk/devmanual/


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Thomas Deutschmann
On 2020-01-04 12:01, Rich Freeman wrote:
> Packages without security support should be masked.  Really I don't
> see the point of even having this in the repo.

THIS! +infinite

And arches without security support in general can't have stable keywords.

But this is a dream. :-/


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Thomas Deutschmann
On 2020-01-04 14:08, Roy Bamford wrote:
> emerge -1 vanilla-sources
> eselect kernel ...
> genkernel all
> ...

Please tell user to do

genkernel --kernel-config=/proc/config.gz all

by default which will give them a better experience because new kernel
will be build based on kernel configuration from current running kernel.
Without providing a kernel config, user will probably fall back to
generic configuration which isn't intended for daily usage.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2020-01-04 Thread Rolf Eike Beer
Am Samstag, 4. Januar 2020, 12:25:07 CET schrieb Michael 'veremitz' Everitt:
> On 04/01/20 11:09, Rolf Eike Beer wrote:
> > Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer:
> >> Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman:
> >>> On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer  
wrote:
>  Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
> > hppa is making us keep old kernels around [1].  Should the kernel team
> > be
> > doing more to get your attention then CC'ing hppa on all of the kernel
> > STABLEREQ bugs [2]?
>  
>  I only run vanilla-sources since there are still lot of cache
>  corruption
>  problems in hppa kernels, or whatever makes them flaky.
>  
>  Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019
>  parisc64
>  PA8800 (Mako) 9000/785/C8000 GNU/Linux
>  Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc
>  PA8600
>  (PCX-W+) 9000/785/C3600 GNU/Linux
>  
>  So _I_ personally would say just drop old kernels, but that is in no
>  way
>  authorative.
> >>> 
> >>> Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel
> >>> sources of each stable and LTS version.
> >> 
> >> If it's just that I could test them, but this still be no LTS version
> >> that I would look at.
> > 
> > So, do you want me to stable a random gentoo-sources (usually the most
> > recent one) every few weeks when I just happen to upgrade my machine?

> I don't think that works very well with kernel/security-team stabilisation
> policies, sadly.
> 
> Is there any possibility you would be able to do a stabilisation run, and
> do a reboot cycle on one LTS branch (of choice, eg. most recent) and then
> revert to your preferred kernel afterwards?

This is annoying, because it usually collides with the nightly runs in some 
way. Doing the build on the C3600 took ~1d last time, the C8000 is faster, but 
I still have to time this right.

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Roy Bamford
On 2020.01.04 12:54, Rich Freeman wrote:
> On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford 
> wrote:

[snip]
> 
> Apparently git and tar are too complicated for Gentoo users, but
> managing symlinks, using make, managing a bootloader, dealing with the
> kernel's configuration system, and so on are just fine?

emerge -1 vanilla-sources
eselect kernel ...
genkernel all
...

Yep, lots of users have trouble managing their boot loader. They come to
the forums and IRC every day not running the kernel they think they are.
That's not related to any particular kernel sources though.

[snip]

> 
> On a further aside, I just noticed how up-to-date gentoo-sources are.
> Kudos to whoever is doing that these days - for a while it was tending
> to slip a bit but it seems like we're basically current.

+1

> 
> -- 
> Rich
> 
> 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpOaAY6RX0hb.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford  wrote:
>
> On 2020.01.04 11:01, Rich Freeman wrote:
> >
> > Is there some reason that we should keep vanilla sources despite not
> > getting security handling?
> >
>
> Gentoo had this discussion before. The outcome was that
> vanilla-sources is just as Linus intended.
> If Gentoo did anything to it, it wouldn't be vanilla any longer.

Obviously.  I wasn't suggesting that we keep vanilla sources but not
make them vanilla.  That doesn't mean that they couldn't be
security-supported, or that we have to have them in the repo.

> Yes, it should be kept. We should not force users to learn
> git or tar.

Uh, all it does is install kernel sources.  They're useless unless you
build a kernel using them.

Apparently git and tar are too complicated for Gentoo users, but
managing symlinks, using make, managing a bootloader, dealing with the
kernel's configuration system, and so on are just fine?

I completely get the point of the distribution kernel project that was
just announced, as I already said.

> I agree git or a tarball of vanilla-sources is faster and more
> efficient but that's not a reason to drop it.
> By the same argument we could drop linux-firmware too.
> There are probably other packages that only install whatever
> they fetch. Could they be dropped?

So, a few issues with that argument:

1.  Those other packages are security supported.
2.  Those other packages are largely functional once installed, and to
the degree that they require configuration that is generally one-time
and after updates they remain functional.

All that said, it seems like vanilla-sources is pretty up-to-date, so
I'm not sure what we mean by it not being security supported.  I just
took that as a given.  Does that mean that we're not releasing patches
before upstream?  If so, that seems like a pretty minor issue since
upstream generally does security bumps pretty quickly.  4.4.208 isn't
in our repo but was released today - I'm not sure how quickly these
get bumped.  If our repo could be days behind that is definitely
another reason not to host this stuff, as users should be directed
upstream if our packages aren't security supported.

On a further aside, I just noticed how up-to-date gentoo-sources are.
Kudos to whoever is doing that these days - for a while it was tending
to slip a bit but it seems like we're basically current.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Roy Bamford
On 2020.01.04 11:01, Rich Freeman wrote:
>
> Is there some reason that we should keep vanilla sources despite not
> getting security handling?
> 
> -- 
> Rich
> 

Rich,

Gentoo had this discussion before. The outcome was that 
vanilla-sources is just as Linus intended.
If Gentoo did anything to it, it wouldn't be vanilla any longer.

Yes, it should be kept. We should not force users to learn
git or tar.

I agree git or a tarball of vanilla-sources is faster and more
efficient but that's not a reason to drop it.
By the same argument we could drop linux-firmware too.
There are probably other packages that only install whatever
they fetch. Could they be dropped?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpNeBPcQXuuf.pgp
Description: PGP signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2020-01-04 Thread Michael 'veremitz' Everitt
On 04/01/20 11:09, Rolf Eike Beer wrote:
> Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer:
>> Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman:
>>> On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer  wrote:
 Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
> hppa is making us keep old kernels around [1].  Should the kernel team
> be
> doing more to get your attention then CC'ing hppa on all of the kernel
> STABLEREQ bugs [2]?
 I only run vanilla-sources since there are still lot of cache
 corruption
 problems in hppa kernels, or whatever makes them flaky.

 Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64
 PA8800 (Mako) 9000/785/C8000 GNU/Linux
 Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600
 (PCX-W+) 9000/785/C3600 GNU/Linux

 So _I_ personally would say just drop old kernels, but that is in no
 way
 authorative.
>>> Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel
>>> sources of each stable and LTS version.
>> If it's just that I could test them, but this still be no LTS version that I
>> would look at.
> So, do you want me to stable a random gentoo-sources (usually the most recent 
> one) every few weeks when I just happen to upgrade my machine?
>
> Eike
I don't think that works very well with kernel/security-team stabilisation
policies, sadly.

Is there any possibility you would be able to do a stabilisation run, and
do a reboot cycle on one LTS branch (of choice, eg. most recent) and then
revert to your preferred kernel afterwards?

I appreciate this is a rather onerous process on older hardware, but just
trying to think of some form of semi-compromise that prevents potential
de-keywording, without also suggesting that something that genuinely has
issues is either (1) working or (2) supported, if so.

I believe Whissi is leading kernel stabilisation requests, on behalf of
security- and kernel- teams, so maybe a chat with him may be fruitful.
Cheers,
veremitz/Michael.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2020-01-04 Thread Rolf Eike Beer
Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer:
> Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman:
> > On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer  wrote:
> > >Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
> > >> hppa is making us keep old kernels around [1].  Should the kernel team
> > >> be
> > >> doing more to get your attention then CC'ing hppa on all of the kernel
> > >> STABLEREQ bugs [2]?
> > >
> > >I only run vanilla-sources since there are still lot of cache
> > >corruption
> > >problems in hppa kernels, or whatever makes them flaky.
> > >
> > >Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64
> > >PA8800 (Mako) 9000/785/C8000 GNU/Linux
> > >Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600
> > >(PCX-W+) 9000/785/C3600 GNU/Linux
> > >
> > >So _I_ personally would say just drop old kernels, but that is in no
> > >way
> > >authorative.
> > 
> > Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel
> > sources of each stable and LTS version.
> 
> If it's just that I could test them, but this still be no LTS version that I
> would look at.

So, do you want me to stable a random gentoo-sources (usually the most recent 
one) every few weeks when I just happen to upgrade my machine?

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Fri, Jan 3, 2020 at 11:28 AM Aaron Bauman  wrote:
> On January 3, 2020 9:55:31 AM EST, 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.
> >
> >Every option sucks. I was only trying to point out that vanilla-sources
> >gets no security support -- security@ has stated this, but it's on a
> >private bug, so I won't quote it -- and the risk is more than academic.
>
> This should be known. Security does not support vanilla-sources. This is one 
> reason vanilla-sources are not stabilized.
>

Packages without security support should be masked.  Really I don't
see the point of even having this in the repo.

I run vanilla sources personally but I just get them from upstream.
Makes way more sense than worrying about whether the version in the
repo is up to date for the longterm kernel I'm following.  People
running vanilla sources are probably using out-of-tree modules (like
me) and as such are going to have particular requirements around how
they're updated.  So, Gentoo is adding fairly little value.

All they do is download sources anyway, which is trivially done from
git more efficiently (or tarballs that are probably easy to obtain
just as efficiently).  I can see more of the point in the new
distribution kernel project which will be turnkey.  I can see some of
the value in gentoo-sources (particularly as the upstream for the
distribution kernels) especially if they're tied to Gentoo-specific
bugs.  For more general bugs that apply to all distros I really don't
see the point in trying to compete with the upstream stable branches
(if they're taking forever to merge a patch, chances are there is a
reason for it, and I'm skeptical that Gentoo users are special in some
way).

Is there some reason that we should keep vanilla sources despite not
getting security handling?

-- 
Rich



[gentoo-dev] Package up for grabs: net-misc/mosh

2020-01-04 Thread Patrice Clement
The following package is now up for grabs:

net-misc/mosh

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature