Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust

2022-01-17 Thread Georgy Yakovlev
On Mon, 2022-01-17 at 21:58 -0500, Ionen Wolkens wrote:
> On Mon, Jan 17, 2022 at 03:24:23PM -0800, Georgy Yakovlev wrote:
> > Hi,
> > 
> > I've been approached multiple times with that request, and a lot of
> > time I see new users completely destroyed by rust build time and
> > disk
> > space requirements.
> 
> fwiw it may be a bit mitigated by the new desktop stages that come
> with
> rust, or at least it won't be the first thing they see when they try
> to build their brand new desktop install until a rust update.
> 
> It's nice if users can get a basic desktop before worrying about how
> to
> handle rust. Not that desktop stages are heavily visible/known so new
> users may not always pick them.
indeed it helps, but it takes time for users to discover/consider this.
it mostly hits very new users or users of containers/vms, who don't
have enough disk space or ram.
> 
> > 
> > WDYT about switching order of rusts in a virtual?
> > 
> > RDEPEND="|| (
> >     ~dev-lang/rust-${PV}
> >     ~dev-lang/rust-bin-${PV}
> > )"
> > 
> > 
> > becomes
> > 
> > RDEPEND="|| (
> >     ~dev-lang/rust-bin-${PV}
> > ~dev-lang/rust-${PV}
> > )"
> > 
> > 
> > Existing installs should be unaffected ofc.
> > But portage may prefer to depclean rust and not rust-bin if both
> > are
> > present.
> 
> Haven't tested how it reacts, but wouldn't that be an issue with
> system-bootstrap in situations where it pulls rust-bin to build
> itself?
it can build itself with non-bin too. as long as it's same or ver-
minus-1 and is installed, if not installed it will pull rust-bin of
matching version.
also system-bootstrap is stable-masked (for various reasons), so I'm
not too worried about it. ~kw users know their way around.

> 
> > Users who wish to use source version at all times can just add it
> > to
> > world file.
> > 
> > I see both positives and negatives of doing that, but would like to
> > reach out to community first.
> 
> Unsure what I like best, I generally agree should default to sources
> but I do see new users complaining about building rust every few
> days.
> Not that the step of telling them that rust-bin exists is that bad
> (part of the issue is that they don't know it's an option).
> 

If I had clear answer myself I would not be asking opinions here =)
just trying to understand if I'm missing something or my view is too
different.
developer and user opinions all are helpful to build picture.
I receive at least weekly complaint about how resource-intensive rust
build is, that counts too.

for now on stable systems, if user types, let's say,
 $ emerge ripgrep

with USE=-system-bootsrap (the default):
portage will pull virtual/rust, which will pull dev-lang/rust, which
will bootstrap itself by downloading proper rust-bin tarball, but not
as a package, just as a tarball behind the scenes.

with USE=system-bootstrap:
portage will pull virtual/rust, which will pull dev-lang/rust-bin, and
build dev-lang/rust, to build ripgrep.

USE=system-llvm (also stable-masked) complicates picture even more.

We've had openjdk-bin and icedtea-bin as default provider for as long
as I can remember, before I started to maintain it. works fine.

PS:
and just to be clear - I'm not pushing for it, just asking for input.



[gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust

2022-01-17 Thread Georgy Yakovlev
Hi,

I've been approached multiple times with that request, and a lot of
time I see new users completely destroyed by rust build time and disk
space requirements.

WDYT about switching order of rusts in a virtual?

RDEPEND="|| (
~dev-lang/rust-${PV}
~dev-lang/rust-bin-${PV}
)"


becomes

RDEPEND="|| (
~dev-lang/rust-bin-${PV}
~dev-lang/rust-${PV}
)"


Existing installs should be unaffected ofc.
But portage may prefer to depclean rust and not rust-bin if both are
present.
Users who wish to use source version at all times can just add it to
world file.

I see both positives and negatives of doing that, but would like to
reach out to community first.

Thanks!

--
Georgy



Re: [gentoo-dev] Package up for grabs: app-shells/kshdb

2022-01-16 Thread Georgy Yakovlev
On Sun, 2022-01-16 at 12:42 -0500, Mike Gilbert wrote:
> I no longer wish to maintain this. Please take it if you are
> interested.
> 
adopted.



[gentoo-dev] Last rites: ~sys-fs/zfs{,-kmod}-0.8.6

2022-01-15 Thread Georgy Yakovlev
# Georgy Yakovlev  (2022-01-15)
# Last branch update happened ~ 12 month ago.
# Maximum kernel supported is 5.9, which we no longer package.
# So 5.10 LTS users can't use it. only 4.x LTS and 5.4 LTS.
# ebuild is effectively unmaintained/untested, so is upstream branch.
# Removal date: sometime around June 2022
# Bug: https://bugs.gentoo.org/830020
~sys-fs/zfs-0.8.6
~sys-fs/zfs-kmod-0.8.6


Feel free to reach out if you think this should not happen or be
delayed.

2.0.x is stable for quite some time.
2.1.x is going stable today too, and it's the upstream LTS branch.



Re: [gentoo-dev] [PATCH] profiles/targets/desktop: disable USE=xvid by default

2022-01-14 Thread Georgy Yakovlev
On Wed, 2022-01-12 at 20:25 -0500, Matt Turner wrote:
> On Tue, Jan 11, 2022 at 9:45 PM Georgy Yakovlev
>  wrote:
> > 
> > it's an ancient codec that is barely used nowadays
> > so let's disable it by default.
> > Users are free to re-enable if required.
> > 
> > Bug: https://bugs.gentoo.org/831044
> 
> Heh, looks like you want to leave it disabled by default because it
> fails to compile on arm? :)
> 
> I don't have a preference. I would note that a few packages depend on
> it being enabled in ffmpeg:
> 
> media-gfx/blender
> media-libs/libopenshot
> media-plugins/mythplugins
Thanks for actually checking it =)

I'm not on a crusade to disable it, just thought it's a sensible thing
to do in 2022.

I've opened a bug and asked maintainers for those packages to double-
check if possible.

My initial investigation (very brief) showed that it might be a catch-
all dep or simply a historical dep that never got re-verified.

https://bugs.gentoo.org/831211



[gentoo-dev] [PATCH] profiles/targets/desktop: disable USE=xvid by default

2022-01-11 Thread Georgy Yakovlev
it's an ancient codec that is barely used nowadays
so let's disable it by default.
Users are free to re-enable if required.

Bug: https://bugs.gentoo.org/831044
Signed-off-by: Georgy Yakovlev 
---
 profiles/targets/desktop/make.defaults | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/profiles/targets/desktop/make.defaults 
b/profiles/targets/desktop/make.defaults
index d7eab4cd0587..34470e021ca0 100644
--- a/profiles/targets/desktop/make.defaults
+++ b/profiles/targets/desktop/make.defaults
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd 
dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms libnotify 
mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl spell 
startup-notification svg tiff truetype vorbis udev udisks unicode upower usb 
wxwidgets X xcb x264 xml xv xvid"
+USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd 
dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms libnotify 
mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl spell 
startup-notification svg tiff truetype vorbis udev udisks unicode upower usb 
wxwidgets X xcb x264 xml xv"
-- 
2.34.1




Re: [gentoo-dev] [PATCH] kernel-2.eclass: fix minor OBOBJCOPY -> OBJCOPY typo

2022-01-06 Thread Georgy Yakovlev
merged with minor edit ( NM dupe removed in parent commit )
thanks!

On Wed, 2022-01-05 at 17:59 +0200, Adrian Ratiu wrote:
> Fixes:55f5c68c01e791c7339144aadc1f20802791551e
> Suggested-by: Manoj Gupta 
> Signed-off-by: Adrian Ratiu 
> ---
>  eclass/kernel-2.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 865c43d3153..d1784717e41 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
> elif type -p ${CHOST}-ar >/dev/null; then
> xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> fi
> -   xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-
> getCC) LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) NM=$(tc-getNM)
> OBOBJCOPY=$(tc-getOBJCOPY) READELF=$(tc-getREADELF) STRIP=$(tc-
> getSTRIP)"
> +   xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-
> getCC) LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) NM=$(tc-getNM)
> OBJCOPY=$(tc-getOBJCOPY) READELF=$(tc-getREADELF) STRIP=$(tc-
> getSTRIP)"
> export xmakeopts
>  }
>  




[gentoo-dev] [PATCH 2/2] EXAMPLE, NOMERGE sys-kernel/gentoo-kernel: use ppc_pagesize expand

2022-01-04 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 .../gentoo-kernel/gentoo-kernel-5.15.11.ebuild | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild 
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
index e4ac32a7019..05ae8331c84 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
@@ -1,123 +1,135 @@
-# Copyright 2020-2021 Gentoo Authors
+# Copyright 2020-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
 
 inherit kernel-build toolchain-funcs
 
 MY_P=linux-${PV%.*}
 GENPATCHES_P=genpatches-${PV%.*}-$(( ${PV##*.} + 2 ))
 CONFIG_VER=5.15.10
 CONFIG_HASH=4882b85cc85fb2b7df396c4d671cc6432596eca0
 GENTOO_CONFIG_VER=5.15.5
 
 DESCRIPTION="Linux kernel built with Gentoo patches"
 HOMEPAGE="https://www.kernel.org/;
 SRC_URI+=" https://cdn.kernel.org/pub/linux/kernel/v$(ver_cut 
1).x/${MY_P}.tar.xz

https://dev.gentoo.org/~mpagano/dist/genpatches/${GENPATCHES_P}.base.tar.xz

https://dev.gentoo.org/~mpagano/dist/genpatches/${GENPATCHES_P}.extras.tar.xz

https://github.com/mgorny/gentoo-kernel-config/archive/v${GENTOO_CONFIG_VER}.tar.gz
-> gentoo-kernel-config-${GENTOO_CONFIG_VER}.tar.gz
amd64? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-x86_64-fedora.config
-> kernel-x86_64-fedora.config.${CONFIG_VER}
)
arm64? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-aarch64-fedora.config
-> kernel-aarch64-fedora.config.${CONFIG_VER}
)
ppc64? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-ppc64le-fedora.config
-> kernel-ppc64le-fedora.config.${CONFIG_VER}
)
x86? (

https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-i686-fedora.config
-> kernel-i686-fedora.config.${CONFIG_VER}
)"
 S=${WORKDIR}/${MY_P}
 
 LICENSE="GPL-2"
 KEYWORDS="amd64 ~arm arm64 ~ppc ppc64 ~x86"
-IUSE="debug hardened"
-REQUIRED_USE="arm? ( savedconfig )"
+IUSE="debug hardened ppc_pagesize_4K +ppc_pagesize_64K"
+REQUIRED_USE="
+   arm? ( savedconfig )
+   ppc64? ( ^^ ( ppc_pagesize_4K ppc_pagesize_64K ) )
+"
 
 RDEPEND="
!sys-kernel/gentoo-kernel-bin:${SLOT}"
 BDEPEND="
debug? ( dev-util/pahole )"
 PDEPEND="
>=virtual/dist-kernel-${PV}"
 
 QA_FLAGS_IGNORED="
usr/src/linux-.*/scripts/gcc-plugins/.*.so
usr/src/linux-.*/vmlinux
usr/src/linux-.*/arch/powerpc/kernel/vdso.*/vdso.*.so.dbg
 "
 
 src_prepare() {
local PATCHES=(
# meh, genpatches have no directory
"${WORKDIR}"/*.patch
)
default
 
local biendian=false
 
# prepare the default config
case ${ARCH} in
amd64)
cp 
"${DISTDIR}/kernel-x86_64-fedora.config.${CONFIG_VER}" .config || die
;;
arm)
return
;;
arm64)
cp 
"${DISTDIR}/kernel-aarch64-fedora.config.${CONFIG_VER}" .config || die
biendian=true
;;
ppc)
# assume powermac/powerbook defconfig
# we still package.use.force savedconfig
cp 
"${WORKDIR}/${MY_P}/arch/powerpc/configs/pmac32_defconfig" .config || die
;;
ppc64)
cp 
"${DISTDIR}/kernel-ppc64le-fedora.config.${CONFIG_VER}" .config || die
biendian=true
;;
x86)
cp "${DISTDIR}/kernel-i686-fedora.config.${CONFIG_VER}" 
.config || die
;;
*)
die "Unsupported arch ${ARCH}"
;;
esac
 
local myversion="-gentoo-dist"
use hardened && myversion+="-hardened"
echo "CONFIG_LOCALVERSION=\"${myversion}\"" > "${T}"/version.config || 
die
local 
dist_conf_path="${WORKDIR}/gentoo-kernel-config-${GENTOO_CONFIG_VER}"
 
local merge_configs=(
"${T}"/version.config
"${dist_conf_path}"/base.config
)
use debug || merge_configs+=(
"${dist_conf_path}"/no-debug.config
)

[gentoo-dev] [PATCH 1/2] profiles: add PPC_PAGESIZE use expand

2022-01-04 Thread Georgy Yakovlev
Hardware can use either size, it's a built time option.
64K is standard and is what we use by default and 99% of distros use.
4K is more compatible with desktop applications and GPU drivers,
which often assume 4K page size.

Problem from switching page sizes on reboot:
btrfs and swaps break, other filesystems like ext4 may become
unmountable, sepending on direction of switch 4K <-> 64K.

Our installcd provides both kernel options, so users can choose which
one to boot.

Planned consumers of this flag:
sys-kernel/gentoo-kernel
sys-kernel/gentoo-kernel-bin ( in the future )
sys-kernel/vanilla-kernel
dev-util/google-perftools

any other application that has a build time switch to optimize for or
set page size.
Also can be used by applications that are known to be broken with
specific page size.
Mesa and amdgpu drivers used to have some problems in the past, but it
was fixed, however broken apps still exist.

Signed-off-by: Georgy Yakovlev 
---
 profiles/arch/powerpc/ppc64/make.defaults | 6 +-
 profiles/base/make.defaults   | 4 ++--
 profiles/desc/ppc_pagesize.desc   | 5 +
 profiles/embedded/make.defaults   | 4 ++--
 4 files changed, 14 insertions(+), 5 deletions(-)
 create mode 100644 profiles/desc/ppc_pagesize.desc

diff --git a/profiles/arch/powerpc/ppc64/make.defaults 
b/profiles/arch/powerpc/ppc64/make.defaults
index ff2526a2530..6555ec277b7 100644
--- a/profiles/arch/powerpc/ppc64/make.defaults
+++ b/profiles/arch/powerpc/ppc64/make.defaults
@@ -1,41 +1,45 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # All extra USE/etc should be specified in sub-profiles.
 # DO NOT POLLUTE USE ON THIS PROFILE.
 
+# Georgy Yakovlev  (2022-01-04)
+# Unhide PPC specific USE_EXPANDs.
+USE_EXPAND_HIDDEN="-PPC_PAGESIZE"
+
 ARCH="ppc64"
 ACCEPT_KEYWORDS="${ARCH}"
 
 CHOST="powerpc64-unknown-linux-gnu"
 CFLAGS="-O2 -pipe"
 CXXFLAGS="${CFLAGS}"
 FFLAGS="${CFLAGS}"
 FCFLAGS="${CFLAGS}"
 
 USE="ibm"
 
 MULTILIB_ABIS="ppc64"
 DEFAULT_ABI="ppc64"
 KERNEL_ABI="ppc64"
 PROFILE_ARCH="ppc64"
 ABI="ppc64"
 
 #CFLAGS_ppc64="-m64"
 LDFLAGS_ppc64="-m elf64ppc"
 CHOST_ppc64="powerpc64-unknown-linux-gnu"
 
 CFLAGS_ppc="-m32"
 LDFLAGS_ppc="-m elf32ppc"
 CHOST_ppc="powerpc-unknown-linux-gnu"
 
 # Michał Górny  (2014-06-27)
 # Make the ABI flag implicit for compatibility with native ebuilds.
 IUSE_IMPLICIT="abi_ppc_64"
 
 # Donnie Berkholz  (2006-08-18)
 # Defaults for video drivers
 VIDEO_CARDS="fbdev mga nv r128 radeon"
 
 # Enable abi_ppc_64 for packages that don't have it forced.
 ABI_PPC="64"
diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index 547c7b31e83..0056543be29 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -1,179 +1,179 @@
 # Copyright 1999-2022 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 #
 # System-wide defaults for the Portage system
 # See portage(5) manpage
 
 # Profile IUSE injection (applies only to ebuilds which use EAPI 5 or later)
 IUSE_IMPLICIT="prefix prefix-guest prefix-stack"
 USE_EXPAND_IMPLICIT="ELIBC KERNEL USERLAND"
 USE_EXPAND_VALUES_ELIBC="AIX bionic Cygwin Darwin DragonFly glibc HPUX Interix 
mingw musl NetBSD OpenBSD SunOS Winnt"
 USE_EXPAND_VALUES_KERNEL="AIX Darwin FreeBSD freemint HPUX linux NetBSD 
OpenBSD SunOS Winnt"
 USE_EXPAND_VALUES_USERLAND="BSD GNU"
 
 # Env vars to expand into USE vars.  Modifying this requires prior
 # discussion on gentoo-dev@lists.gentoo.org.
-USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS 
APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS 
CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC FFTOOLS GPSD_PROTOCOLS 
GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS 
LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP 
NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION 
OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS 
PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS 
ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS 
VOICEMAIL_STORAGE XTABLES_ADDONS"
+USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS 
APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS 
CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC FFTOOLS GPSD_PROTOCOLS 
GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS 
LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP 
NGINX_MODULES_MAIL

[gentoo-dev] [PATCH] toolchain.eclass: fix crossdev powerpc-*-musl builds

2021-12-26 Thread Georgy Yakovlev
otherwise initial build may fail with:
 unknown long double size, cannot define BFP_FMT

Signed-off-by: Georgy Yakovlev 
---
 eclass/toolchain.eclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index fd03ba176276..1102c4fc5d56 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1099,6 +1099,11 @@ toolchain_src_configure() {
# Set up defaults based on current CFLAGS
is-flagq -mfloat-gprs=double && confgcc+=( --enable-e500-double 
)
[[ ${CTARGET//_/-} == *-e500v2-* ]] && confgcc+=( 
--enable-e500-double )
+   if [[ ${CTARGET} == powerpc-*-musl ]]; then
+   # fix: unknown long double size, cannot define BFP_FMT
+   confgcc+=( --disable-decimal-float )
+   export gcc_cv_target_ldbl128=no
+   fi
;;
ppc64)
# On ppc64 big endian target gcc assumes elfv1 by default,
-- 
2.34.1




[gentoo-dev] [PATCH] profiles/base/make.defaults: treat dtbs like modules

2021-12-26 Thread Georgy Yakovlev
when dist-kernel gets uninstalled, /lib/modules/
is left behind on purpose. However, on some systems kernels also install
device-tree files to /boot/dtbs/

leaving /lib/modules, but removing device-tree file may leave system
unbootable, so let's treat dtbs directory similar to modules.

Signed-off-by: Georgy Yakovlev 
---
 profiles/base/make.defaults | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index f25074f9d81a..be5651f0ac43 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -134,11 +134,11 @@ PYTHON_SINGLE_TARGET="python3_9"
 
 # Michał Górny  (2013-08-10)
 # Moved from portage's make.globals.
-# 1) do not uninstall kernel modules and therefore allow replacing them,
+# 1) do not uninstall kernel modules/dtbs and therefore allow replacing them,
 # 2,3) removed wrt bug #663170,
 # 4) protect /var/{run,lock} symlinks for bug 519620
-COLLISION_IGNORE="/lib/modules/*"
-UNINSTALL_IGNORE="/lib/modules/* /var/run /var/lock"
+COLLISION_IGNORE="/boot/dtbs/* /lib/modules/*"
+UNINSTALL_IGNORE="/boot/dtbs/* /lib/modules/* /var/run /var/lock"
 
 # Andreas K. Hüttel  (2013-08-23)
 # Make emerge messages default to English as per Council decision
-- 
2.34.1




[gentoo-dev] Re: [PATCH] app-containers: new category

2021-12-18 Thread Georgy Yakovlev
On 01.12.2021 04:46, Georgy Yakovlev wrote:
> Discussed in 
> https://archives.gentoo.org/gentoo-dev/message/67ecdd21af5eaddffd87e6707d54de61
> Signed-off-by: Georgy Yakovlev 
> ---
>  app-containers/metadata.xml | 7 +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 app-containers/metadata.xml
> 
> diff --git a/app-containers/metadata.xml b/app-containers/metadata.xml
> new file mode 100644
> index ..c1a2b4e9a74a
> --- /dev/null
> +++ b/app-containers/metadata.xml
> @@ -0,0 +1,7 @@
> +
> +https://www.gentoo.org/dtd/metadata.dtd;>
> +
> + 
> + The app-containers category contains container related software.
> + 
> +
> -- 
> 2.34.1
> 

-- 
Best regards,
Georgy

modified variant of this merged,
also moved:

containerd
docker-proxy



[gentoo-dev] Last rites: app-shells/ksh-2020.0.0

2021-12-14 Thread Georgy Yakovlev
# Georgy Yakovlev  (2021-12-14)
# AT decided to roll back community changes in March 2020
# for version 2020.x.x
# This version is no longer maintained.
# New version is maintained at https://github.com/ksh93/ksh
# and is available as app-shells/ksh-1.0.0_beta1 at time of writing.
~app-shells/ksh-2020.0.0

-- 
Best regards,
Georgy



[gentoo-dev] [PATCH] app-containers: new category

2021-12-01 Thread Georgy Yakovlev
Discussed in 
https://archives.gentoo.org/gentoo-dev/message/67ecdd21af5eaddffd87e6707d54de61
Signed-off-by: Georgy Yakovlev 
---
 app-containers/metadata.xml | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 app-containers/metadata.xml

diff --git a/app-containers/metadata.xml b/app-containers/metadata.xml
new file mode 100644
index ..c1a2b4e9a74a
--- /dev/null
+++ b/app-containers/metadata.xml
@@ -0,0 +1,7 @@
+
+https://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   The app-containers category contains container related software.
+   
+
-- 
2.34.1




Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-25 Thread Georgy Yakovlev
On 25.11.2021 04:21, Thomas Deutschmann wrote:
> Bug: https://bugs.gentoo.org/825234
> Signed-off-by: Thomas Deutschmann 
> ---
>  ...adb-database-restore-maybe-required.en.txt | 46 +++
>  1 file changed, 46 insertions(+)
>  create mode 100644 
> 2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
> 
> diff --git 
> a/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
>  
> b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
> new file mode 100644
> index 000..c4a698e
> --- /dev/null
> +++ 
> b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
> @@ -0,0 +1,46 @@
> +Title: Full MariaDB database restore maybe required
> +Author: Thomas Deutschmann 
> +Posted: 2021-11-23
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Installed: dev-db/mariadb
> +Display-If-Installed: sys-cluster/galera
> +
> +On 2021-11-21, a member of the QA project accidentially de-keyworded
Agreed with others in the thread, this is not professional.

> +MariaDB 10.6 to address a file collision, users, who also had latest
> +dev-db/mariadb-connector-c installed, experienced (NOTE: The default
> +MySQL connector in Gentoo Linux is provided by
> +dev-db/mysql-connector-c) [Link 1].
This ^ is a very confusing sentence and is way too long. Needs shortening and
re-wording, too much commas.

> +
> +However, downgrades are not supported in MySQL/MariaDB [Link 2].
> +
> +In case you already fully upgraded to MariaDB 10.6 (which includes
> +executing mysql_upgrade command) and forcefully downgraded your
> +MariaDB instance afterwards during the time window when keywords were
> +removed, you maybe experiencing different problems:
> +
> +At best, your forcefully downgraded MariaDB instance prevented startup
> +so all you have to do is upgrade to MariaDB 10.6 again to resume
> +services.
> +
> +In case previous MariaDB version was able to start, you are encouraged
> +to do a full backup as soon as possible using mysqldump command and
> +manually restore each database ("logical downgrade") to prevent any
> +data corruption.
> +
> +Depending on used feature set and from which version you upgraded,
> +it is maybe required to do a full restore from a previous backup before
> +MariaDB 10.6 upgrade to restore services and prevent any data loss or
> +future runtime errors.
> +
> +In case you are using MariaDB in a cluster and/or Galera setup you
> +probably have to rebuild the entire cluster in case the upgrade to
> +MariaDB 10.6 was already replicated (using pt-table-checksum from
> +dev-db/percona-toolkit can help you to validate your cluster).
> +
> +Keep in mind that due to the forced downgraded, point-in-time recovery
> +may not be available to the extent that you are used to.
> +
> +Link 1: https://bugs.gentoo.org/825234#c8
> +
> +Link 2: 
> https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/
> -- 
> 2.34.0
> 
> 

-- 
Best regards,
Georgy



Re: [gentoo-dev] [RFC] Un-slotting LLVM

2021-11-08 Thread Georgy Yakovlev
On 08.11.2021 12:18, Michał Górny wrote:
> Hi,
> 
> A few years back I've slotted LLVM and Clang to make the life with
> revdeps easier.  Long story short, every major LLVM release (which
> happens twice a year) breaks API and it takes some time for revdeps to
> adjust.  Slotting made it possible to install multiple versions
> simultaneously, and therefore let "faster" packages use newer LLVM
> without being blocked by "slower" packages on the user's system.
> 
> Unfortunately, this ended up pretty bothersome to maintain.  Besides
> making ebuilds quite complex (and prone to mistakes), I'm hearing more
> and more reports of programs being broken through getting multiple LLVM
> versions in the link chain.
> 
> This is not something that can be easily solved.  In other words, it's
> a mess and I don't think we're really getting anywhere.  For this
> reason, I'm considering dropping slotting and going back to permitting
> only a single version of LLVM and Clang being installed.
> 
> This would have two major implications:
> 
> 1. If you installed any package that requires older LLVM, it'd block all
> other packages from updating.  If you hit two packages that do not have
> a common supported LLVM version, you won't be able to install them
> at all.
> 
> On the plus side, this will motivate developers to actually start fixing
> these packages rather than letting them rot until I start removing old
> LLVM versions.
> 
> 2. We will no longer support having multiple clang versions installed. 
> While it was convenient for testing stuff, it's not really a killer
> feature though.
> 
> The only real alternative I see is actively limiting supported LLVM
> versions in packages to ensure that all libraries in the depgraph end up
> using the same LLVM version.  However, I don't think it's really worth
> the effort.
> 
> I don't have a ready unslotting plan yet.
> 
> WDYT?
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

This can block rust and consumers quite badly.
Currently in rust source ebuild we lock llvm version for system llvm to
exact one bundled by upstream, for example

1.55 - llvm12 (with/without system-llvm set)
1.56 - llvm13 (with/without system-llvm set)

that's effective with both system-llvm set or unset, and for rust-bin.
in theory I can unlock rust version and provide compatibility with
multiple, but we run into next problem:

rust-1.56 can come with llvm12 and llvm13, but only llvm13 if -system-llvm
rust-bin only can use llvm13 (internal one, pre-compiled by upstream)

this will break firefox and spidermonkey and thunderbird on some
systems.
mozilla products need to be compiled and linked with the same llvm
version in all components. 

compiling/linking firefox with llvm13/clang13, but rust-1.55 will
not be possible, because of mis-matched llvm versions. or it may work
but break at runtime.

and if we have multiple llvm possible in firefox it will not be able to
enforce dependency chain via portage.

well, we could introduce llvm-ver useflags for rust, and clang, so
firefox can require rust[llvm13(-)] clang[llvm13(-)] with a lot of
required-use boilerplate, but that's _very_ ugly.

-- 
Best regards,
Georgy



[gentoo-dev] RFC: new category for container related packages, instead of app-emulation

2021-08-05 Thread Georgy Yakovlev
Hi,

We've been collecting more and more container related packages in
 app-emulation/*

What do you think about finally moving those packages to separate category?

probably app-containers/

Here's the tentative list, most tools have description attached for easier
review, 36 candidates so far, there may be more around, I only looked at
app-emulation.

app-emulation/buildah - A tool that facilitates building OCI images
app-emulation/cadvisor - container analyzer
app-emulation/conmon - An OCI container runtime monitor
app-emulation/containerd - A daemon to control runC
app-emulation/containers-storage - containers/storage library
app-emulation/cri-o - OCI-based implementation of Kubernetes CRI 
app-emulation/cri-tools - CLI and validation tools for CRI
app-emulation/crun - OCI Container Runtime fully written in C
app-emulation/distrobuilder - System container image builder for LXC and LXD
app-emulation/docker - Main offender
app-emulation/docker-bench-security - Test for best docker practices
app-emulation/docker-cli - Main offender cli
app-emulation/docker-compose - Multi-container orchestration for Docker
app-emulation/docker-credential-helpers -
app-emulation/docker-gc - Docker garbage collection of containers and images
app-emulation/docker-proxy - Docker container networking
app-emulation/docker-registry -
app-emulation/docker-swarm -
app-emulation/flannel - An etcd backed network fabric for containers
app-emulation/go-secbench - run and evaluate the docker security benchmark
app-emulation/img - Standalone Dockerfile and OCI container image builder
app-emulation/k3d - creates k3s clusters in docker
app-emulation/kompose - Tool to move from docker-compose to Kubernetes
app-emulation/lxc - A userspace interface for the Linux kernel containment
app-emulation/lxc-templates -
app-emulation/lxd - Fast, dense and secure container management
app-emulation/nerdctl - Docker-compatible CLI for containerd
app-emulation/podman - Main offender killer
app-emulation/reg - Docker registry v2 command line client
app-emulation/runc - another docker thing
app-emulation/s6-overlay - an s6-based init system for containers
app-emulation/sen - Terminal User Interface for docker engine
app-emulation/skopeo - Utility for operations on container images/repositories
app-emulation/slirp4netns - User-mode networking for unpriv network namespaces
app-emulation/snapd - Service and tools for management of snap packages
app-emulation/umoci - Manipulation tool for OCI images

Those 4 are technically emulation related, so I'm not sure about category:
app-emulation/docker-machine
app-emulation/docker-machine-kvm
app-emulation/hyperd
app-emulation/runv


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


Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

2021-08-02 Thread Georgy Yakovlev
On Monday, August 2, 2021 1:30:07 AM PDT Michał Górny wrote:
> On Mon, 2021-08-02 at 01:28 -0700, Georgy Yakovlev wrote:
> > it can actually check if ebuild calls tmpfiles_process, not only
> > inherit.
> > something like:
> > 
> > local pkg_postinst_body="$(declare -fp pkg_postinst)"
> > if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
> > eqawarn "QA Notice: package is installing tmpfiles without
> > calling
> > eqawarn "tmpfiles_process in pkg_postinst phase"
> > fi
> >
> > ofc accounting for edge cases floppym mentioned.
> 
> This is going to cause false positives if tmpfiles_process is called via
> another function.

ineed, but seems there are no such cases yet.
simple test (via ripgrep): prints all files calling tmpfiles_process at any 
point, and checks if any files from the list do not have a string ^pkg_postinst
it  may not catch all ofc, because it does not check where call happens or if 
it's actually defined, but I think it's good enough.

rg tmpfiles_process --files-with-matches | xargs rg ^pkg_postinst --files-
without-match

1 result, eclass/tmpfiles.eclass, which is fine.

I think adding body checker outweighs possible edge case yet to happen.
ebuilds not calling it already happened, we fixed some.
for example, logrotate was broken out of the box on systemd.

-- 
Best regards,
Georgy






Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

2021-08-02 Thread Georgy Yakovlev
On Saturday, July 31, 2021 4:56:34 PM PDT Sam James wrote:
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;
> 
> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
> 
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).
> 
> Signed-off-by: Sam James 
> ---
>  metadata/install-qa-check.d/60tmpfiles-paths | 37 
>  1 file changed, 37 insertions(+)
>  create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths
> 
> diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
> b/metadata/install-qa-check.d/60tmpfiles-paths new file mode 100644
> index 0..2c56c031bd1e3
> --- /dev/null
> +++ b/metadata/install-qa-check.d/60tmpfiles-paths
> @@ -0,0 +1,37 @@
> +# Copyright 2021 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# QA check: ensure that packages installing tmpfiles configuration inherit
> the eclass +# Maintainer: Sam James 
> +
> +# Implements two checks:
> +# 1) Installation to /etc/tmpfiles.d (which is a deprecated location);
> +# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting
> the eclass +#(needed for tmpfiles_process in pkg_postinst)
> +tmpfiles_check() {
> + # Check 1
> + # Scan image for files in /etc/tmpfiles.d which is a deprecated 
location
> + if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then
> + eqawarn "QA Notice: files installed to the deprecated /etc/
tmpfiles.d
> location" +   eqawarn "tmpfiles configuration files must be 
installed to
> /usr/lib/tmpfiles.d!" +   fi
> +
> + # Check 2
> + # We're now going to check for whether we install files to
> /usr/lib/tmpfiles.d without + # inheriting the eclass (weak catch for
> ebuilds not calling tmpfiles_process in pkg_postinst) +
> + # No need to carry on if we're inheriting the eclass
> + if has tmpfiles ${INHERITED} ; then
> + return

it can actually check if ebuild calls tmpfiles_process, not only inherit.
something like:

local pkg_postinst_body="$(declare -fp pkg_postinst)"
if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
eqawarn "QA Notice: package is installing tmpfiles without calling
eqawarn "tmpfiles_process in pkg_postinst phase"
fi

ofc accounting for edge cases floppym mentioned.

> + fi
> +
> + if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
> + eqawarn "QA Notice: package is installing tmpfiles without 
inheriting
> tmpfiles.eclass!" +   eqawarn "Packages must inherit tmpfiles.eclass 
then
> call tmpfiles_process in pkg_postinst." + fi
> +}
> +
> +tmpfiles_check
> +: # guarantee successful exit
> +
> +# vim:ft=sh


-- 
Best regards,
Georgy


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


Re: [gentoo-dev] [PATCH v2 5/5] check-reqs.eclass: Repl. I_KNOW_WHAT_I_AM_DOING w/ CHECKREQS_DONOTHING

2021-07-24 Thread Georgy Yakovlev
On 23.07.2021 08:58, Andreas Sturmlechner wrote:
> Signed-off-by: Andreas Sturmlechner 
> ---
>  eclass/check-reqs.eclass | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
> index 39e4bad1363..836dd0d4a1f 100644
> --- a/eclass/check-reqs.eclass
> +++ b/eclass/check-reqs.eclass
> @@ -68,6 +68,13 @@ _CHECK_REQS_ECLASS=1
>  # @DESCRIPTION:
>  # How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
>  
> +# @ECLASS-VARIABLE: CHECKREQS_DONOTHING
> +# @USER_VARIABLE
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Do not error out in _check-reqs_output if requirements are not met.
> +# This is a user flag and should under _no circumstances_ be set in the 
> ebuild.
...snip...

note that developer profiles set I_KNOW_WHAT_I_AM_DOING="yes" by default

in profiles/targets/developer/make.defaults

I don't know if anyone seriously using this profile though.

-- 
Best regards,
Georgy



[gentoo-dev] [PATCH] 2021-07-17-new-ppc64-profiles: add new item

2021-07-17 Thread Georgy Yakovlev
a lot of text taken from 17.1 profile news item:
2019-06-05-amd64-17-1-profiles-are-now-stable.en.txt

Bug: https://bugs.gentoo.org/640184
Bug: https://bugs.gentoo.org/715680
---
 .../2021-07-17-new-ppc64-profiles.en.txt  | 78 +++
 1 file changed, 78 insertions(+)
 create mode 100644 
2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt

diff --git a/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt 
b/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt
new file mode 100644
index 000..6344963
--- /dev/null
+++ b/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt
@@ -0,0 +1,78 @@
+Title: new ppc64 profiles
+Author: Georgy Yakovlev 
+Posted: 2021-07-17
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland
+Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop
+Display-If-Profile: 
default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome
+Display-If-Profile: 
default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome/systemd
+Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/developer
+
+A new set of ppc64 profiles has been added to the Gentoo
+repository in Jan 2020.  These profiles switch to a more standard
+'no SYMLINK_LIB' multilib layout, and require explicit migration as
+described below.  They are considered stable at the moment, and we would
+like to request all users to upgrade their systems.  The old profiles
+will be deprecated in the near future.
+
+In the new profiles, the lib->lib64 compatibility symlink is removed.
+64-bit libraries need to be installed directly to lib64.  /lib
+and /usr/lib become real directories, that are used for cross-arch
+and native non-library packages (gcc, clang).
+
+The migration is performed using app-portage/unsymlink-lib tool.
+The following steps can be used to upgrade your system:
+
+1. Sync and upgrade your system to the newest package versions
+   to reduce the risk of issues.
+
+2. Install the tool:
+
+ # emerge -1v app-portage/unsymlink-lib
+
+3. Run 'unsymlink-lib --analyze' and check the output for obvious
+   mistakes.  If you need to perform any changes to the system, remember
+   to run 'unsymlink-lib --analyze' again afterwards.
+
+[past this point do not call emerge or modify /usr manually]
+
+4. This is a very good time to make a backup.
+
+5. Run 'unsymlink-lib --migrate'.  You can add '--pretend' first to see
+   what is going to happen.
+
+6. Reboot your system.  Check if important programs work.
+   In particular, verify that e.g. 'emerge --info' works (but do not
+   install anything).  If you hit any serious problems, you can use
+   'unsymlink-lib --rollback' to revert the changes and return to
+   step 4.
+
+7. Run 'unsymlink-lib --finish'.  You can add '--pretend' first to see
+   what is going to happen but note that you're going to see a very long
+   list of files to remove.
+
+8. Switch the profile, e.g.:
+
+ # eselect profile set default/linux/ppc64/17.0
+
+[at this point you can start using emerge again]
+
+9. Rebuild the toolchain:
+
+  # emerge -1v sys-devel/gcc:10
+  [ repeat for other slots you will be using ]
+  # emerge -1v sys-devel/binutils
+  # emerge -1v sys-libs/glibc
+
+For known issues, please see bugs #506276 [2] and #640184[3] .
+If you have any problems with the new profiles or the migration procedure,
+please report a bug and make it block the tracker.
+
+For more information on the layout, please see the wiki article
+on AMD64 multilib layouts [4], it applies to PPC64 as well.
+
+[1] https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html
+[2] https://bugs.gentoo.org/506276
+[3] https://bugs.gentoo.org/640184
+[4] https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
-- 
2.32.0




[gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

2021-07-09 Thread Georgy Yakovlev
This reverts commit a93dbc1701de3b983c6f791391f7967d4b919b4a.
and addresses some feedback items
---
 .../2021-07-09-systemd-tmpfiles.en.txt| 66 +++
 1 file changed, 66 insertions(+)
 create mode 100644 
2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt

diff --git a/2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt 
b/2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt
new file mode 100644
index 000..e902a3b
--- /dev/null
+++ b/2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt
@@ -0,0 +1,66 @@
+Title: opentmpfiles deprecation
+Author: Georgy Yakovlev 
+Author: Sam James 
+Posted: 2021-07-09
+Revision: 2
+News-Item-Format: 2.0
+Display-If-Installed: sys-apps/opentmpfiles
+Display-If-Installed: sys-apps/systemd-tmpfiles
+
+A tmpfiles [0] implementation provides a generic mechanism to define
+the creation of regular files, directories, pipes, and device nodes,
+adjustments to their access mode, ownership, attributes, quota
+assignments, and contents, and finally their time-based removal.
+It is commonly used for volatile and temporary files and directories
+such as those located under /run/, /tmp/, /var/tmp/, the API file
+systems such as /sys/ or /proc/, as well as some other directories
+below /var/. [1]
+
+On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a
+root privilege escalation vulnerability (CVE-2017-18925 [2],
+bug #751415 [3], issue 4 [4] upstream).
+
+The use of opentmpfiles is discouraged by its maintainer due to the
+unpatched vulnerability and other long-standing bugs [5].
+
+Users will start seeing their package manager trying to replace
+sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is
+another provider of virtual/tmpfiles.
+
+Despite the name, 'systemd-tmpfiles' does not depend on systemd, does
+not use dbus, and is just a drop-in replacement for opentmpfiles. It is
+a small binary built from systemd source code, but works separately,
+similarly to eudev or elogind. It is known to work on both glibc and
+musl systems.
+
+Note that systemd-tmpfiles is specifically for non-systemd systems. It
+is intended to be used on an OpenRC system.
+
+If you wish to selectively test systemd-tmpfiles, follow those steps:
+
+ 1. # emerge --oneshot sys-apps/systemd-tmpfiles
+ 2. # reboot
+ 3. # rm /etc/runlevels/boot/opentmpfiles-setup
+ 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev
+
+No other steps required.
+
+If, after reviewing the linked bug reference for opentmpfiles, you feel
+your system is not vulnerable/applicable to the attack described, you
+can unmask [6] opentmpfiles at your own risk:
+
+ 1. In /etc/portage/package.unmask, add a line:
+ sys-apps/opentmpfiles
+ 2. # emerge --oneshot sys-apps/opentmpfiles
+
+Note that opentmpfiles is likely to be removed from gentoo repository
+in the future.
+
+[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
+[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
+[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925
+[3] https://bugs.gentoo.org/751415
+[4] https://github.com/OpenRC/opentmpfiles/issues/4
+[5] 
https://archives.gentoo.org/gentoo-dev/message/bce91b9d37db0b1e0980eb923a8607c9
+[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package
+
-- 
2.32.0




[gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: restore news item

2021-07-09 Thread Georgy Yakovlev
This reverts commit a93dbc1701de3b983c6f791391f7967d4b919b4a.
and addresses some feedback items
---
 .../2021-07-07-systemd-tmpfiles.en.txt| 66 +++
 1 file changed, 66 insertions(+)
 create mode 100644 
2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt

diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt 
b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
new file mode 100644
index 000..7167985
--- /dev/null
+++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
@@ -0,0 +1,66 @@
+Title: opentmpfiles deprecation
+Author: Georgy Yakovlev 
+Author: Sam James 
+Posted: 2021-07-09
+Revision: 2
+News-Item-Format: 2.0
+Display-If-Installed: sys-apps/opentmpfiles
+Display-If-Installed: sys-apps/systemd-tmpfiles
+
+A tmpfiles [0] implementation provides a generic mechanism to define
+the creation of regular files, directories, pipes, and device nodes,
+adjustments to their access mode, ownership, attributes, quota
+assignments, and contents, and finally their time-based removal.
+It is commonly used for volatile and temporary files and directories
+such as those located under /run/, /tmp/, /var/tmp/, the API file
+systems such as /sys/ or /proc/, as well as some other directories
+below /var/. [1]
+
+On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a
+root privilege escalation vulnerability (CVE-2017-18925 [2],
+bug #751415 [3], issue 4 [4] upstream).
+
+The use of opentmpfiles is discouraged by its maintainer due to the
+unpatched vulnerability and other long-standing bugs [5].
+
+Users will start seeing their package manager trying to replace
+sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is
+another provider of virtual/tmpfiles.
+
+Despite the name, 'systemd-tmpfiles' does not depend on systemd, does
+not use dbus, and is just a drop-in replacement for opentmpfiles. It is
+a small binary built from systemd source code, but works separately,
+similarly to eudev or elogind. It is known to work on both glibc and
+musl systems.
+
+Note that systemd-tmpfiles is specifically for non-systemd systems. It
+is intended to be used on an OpenRC system.
+
+If you wish to selectively test systemd-tmpfiles, follow those steps:
+
+ 1. # emerge --oneshot sys-apps/systemd-tmpfiles
+ 2. # reboot
+ 3. # rm /etc/runlevels/boot/opentmpfiles-setup
+ 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev
+
+No other steps required.
+
+If, after reviewing the linked bug reference for opentmpfiles, you feel
+your system is not vulnerable/applicable to the attack described, you
+can unmask [6] opentmpfiles at your own risk:
+
+ 1. In /etc/portage/package.unmask, add a line:
+ -sys-apps/opentmpfiles-
+ 2. # emerge --oneshot sys-apps/opentmpfiles
+
+Note that opentmpfiles is likely to be removed from gentoo repository
+in the future.
+
+[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
+[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
+[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925
+[3] https://bugs.gentoo.org/751415
+[4] https://github.com/OpenRC/opentmpfiles/issues/4
+[5] 
https://archives.gentoo.org/gentoo-dev/message/bce91b9d37db0b1e0980eb923a8607c9
+[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package
+
-- 
2.32.0




Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-09 Thread Georgy Yakovlev
On 09.07.2021 13:57, Ulrich Mueller wrote:
> >>>>> On Fri, 09 Jul 2021, Georgy Yakovlev wrote:
> 
> > Already pushed as is.
> 
> So as far as I can see, you've posted it for review at 02:38:05 today,
> and pushed it at 08:25:55?
> 
> That is less than the 72 hours mandated by GLEP 42, so definitely
> not OK. That pr@ wasn't CCed isn't helpful either.
> 
> Ulrich

Sorry about not CC-ing and making title longer than 50.

But sure, let's revert and wait 3 days, instead of sending an explanation
to users who may need it now.
Let's wait till more topics on forums created, and let our IRC support
guys do more work explaining it to people.

Makes sense.

-- 
Best regards,
Georgy


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-09 Thread Georgy Yakovlev
On 09.07.2021 08:50, Tomas Mozes wrote:
> On Fri, Jul 9, 2021 at 4:38 AM Georgy Yakovlev  wrote:
> 
> > Signed-off-by: Sam James 
> > Signed-off-by: Georgy Yakovlev 
> > ---
> >  .../2021-07-07-systemd-tmpfiles.en.txt| 48 +++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644
> > 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> >
> > diff --git
> > a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> > b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> > new file mode 100644
> > index 000..0960663
> > --- /dev/null
> > +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
...snip
> > +
> > + 1. # emerge --oneshot sys-apps/systemd-tmpfiles
> > + 2. # reboot
> > +
> > +No other steps required.
> > +
...snip
> Plus maybe removing these dead symlinks:
> /etc/runlevels/boot/opentmpfiles-setup
> /etc/runlevels/sysinit/opentmpfiles-dev

added, thanks.

-- 
Best regards,
Georgy


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-09 Thread Georgy Yakovlev
On 09.07.2021 09:11, Michał Górny wrote:
> On Thu, 2021-07-08 at 21:43 -0700, Georgy Yakovlev wrote:
> > Signed-off-by: Sam James 
> > Signed-off-by: Georgy Yakovlev 
> > ---
> >  .../2021-07-07-systemd-tmpfiles.en.txt| 64 +++
> >  1 file changed, 64 insertions(+)
> >  create mode 100644 
> > 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> > 
> > diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt 
> > b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
> > new file mode 100644
> > index 000..e946c89
> > --- /dev/null
> > +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
... snip
> > +Note that systemd-tmpfiles is specifically for non-systemd systems. It
> > +is intended to be used on an OpenRC system.
> 
> Maybe it'd be worth adding a sentence that systemd itself provides
> the utility on systemd systems.
Already pushed as is. It should not be shown to systemd users anyway, so
no big losss.
> -- 
> Best regards,
> Michał Górny
> 
> 

-- 
Best regards,
Georgy


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-08 Thread Georgy Yakovlev
Signed-off-by: Sam James 
Signed-off-by: Georgy Yakovlev 
---
 .../2021-07-07-systemd-tmpfiles.en.txt| 64 +++
 1 file changed, 64 insertions(+)
 create mode 100644 
2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt

diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt 
b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
new file mode 100644
index 000..e946c89
--- /dev/null
+++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
@@ -0,0 +1,64 @@
+Title: systemd-tmpfiles replaces opentmpfiles due to security issues
+Author: Georgy Yakovlev 
+Author: Sam James 
+Posted: 2021-07-07
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: sys-apps/opentmpfiles
+Display-If-Installed: sys-apps/systemd-tmpfiles
+
+A tmpfiles [0] implementation provides a generic mechanism to define
+the creation of regular files, directories, pipes, and device nodes,
+adjustments to their access mode, ownership, attributes, quota
+assignments, and contents, and finally their time-based removal.
+It is commonly used for volatile and temporary files and directories
+such as those located under /run/, /tmp/, /var/tmp/, the API file
+systems such as /sys/ or /proc/, as well as some other directories
+below /var/. [1]
+
+On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a
+root privilege escalation vulnerability (CVE-2017-18925 [2],
+bug #751415 [3], issue 4 [4] upstream).
+
+The use of opentmpfiles is discouraged by its maintainer due to the
+unpatched vulnerability and other long-standing bugs [5].
+
+Users will start seeing their package manager trying to replace
+sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is
+another provider of virtual/tmpfiles.
+
+Despite the name, 'systemd-tmpfiles' does not depend on systemd, does
+not use dbus, and is just a drop-in replacement for opentmpfiles. It is
+a small binary built from systemd source code, but works separately,
+similarly to eudev or elogind. It is known to work on both glibc and
+musl systems.
+
+Note that systemd-tmpfiles is specifically for non-systemd systems. It
+is intended to be used on an OpenRC system.
+
+If you wish to selectively test systemd-tmpfiles, follow those steps:
+
+ 1. # emerge --oneshot sys-apps/systemd-tmpfiles
+ 2. # reboot
+
+No other steps required.
+
+If, after reviewing the linked bug reference for opentmpfiles, you feel
+your system is not vulnerable/applicable to the attack described, you
+can unmask [6] opentmpfiles at your own risk:
+
+ 1. In /etc/portage/package.unmask, add a line:
+ -sys-apps/opentmpfiles-
+ 2. # emerge --oneshot sys-apps/opentmpfiles
+
+Note that opentmpfiles is likely to be removed from gentoo repository
+in the future.
+
+[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
+[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
+[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925
+[3] https://bugs.gentoo.org/751415
+[4] https://github.com/OpenRC/opentmpfiles/issues/4
+[5] https://bugs.gentoo.org/741216
+[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package
+
-- 
2.32.0




[gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item

2021-07-08 Thread Georgy Yakovlev
Signed-off-by: Sam James 
Signed-off-by: Georgy Yakovlev 
---
 .../2021-07-07-systemd-tmpfiles.en.txt| 48 +++
 1 file changed, 48 insertions(+)
 create mode 100644 
2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt

diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt 
b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
new file mode 100644
index 000..0960663
--- /dev/null
+++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt
@@ -0,0 +1,48 @@
+Title: systemd-tmpfiles replaces opentmpfiles due to security issues
+Author: Georgy Yakovlev 
+Author: Sam James 
+Posted: 2021-07-07
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: virtual/tmpfiles
+
+On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a
+root privilege escalation vulnerability (CVE-2017-18925 [0],
+bug #751415 [1], issue 4 [2] upstream).
+
+The use of opentmpfiles is discouraged by its maintainer due to the
+unpatched vulnerability and other long-standing bugs [3].
+
+Users will start seeing their package manager trying to replace
+sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is
+another provider of virtual/tmpfiles.
+
+Despite the name, 'systemd-tmpfiles' does not depend on systemd, does
+not use dbus, and is just a drop-in replacement for opentmpfiles. It is
+a small binary built from systemd source code, but works separately,
+similarly to eudev or elogind. It is known to work on both glibc and
+musl systems.
+
+Note that systemd-tmpfiles is specifically for non-systemd systems. It
+is intended to be used on an OpenRC system.
+
+If you wish to selectively test systemd-tmpfiles, follow those steps:
+
+ 1. # emerge --oneshot sys-apps/systemd-tmpfiles
+ 2. # reboot
+
+No other steps required.
+
+If, after reviewing the linked bug reference for opentmpfiles, you feel
+your system is not vulnerable/applicable to the attack described, you
+can unmask[4] opentmpfiles at your own risk:
+
+1. In /etc/portage/package.unmask, add:
+-sys-apps/opentmpfiles
+2. # emerge --oneshot sys-apps/opentmpfiles
+
+[0] https://nvd.nist.gov/vuln/detail/CVE-2017-18925
+[1] https://bugs.gentoo.org/751415
+[2] https://github.com/OpenRC/opentmpfiles/issues/4
+[3] https://bugs.gentoo.org/741216
+[4] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package
-- 
2.32.0




[gentoo-dev] [PATCH 2/2] cargo.eclass: make CRATES an eclass variable

2021-07-01 Thread Georgy Yakovlev
it's needed to be present in all ebuilds for
crate auditing tools to work properly.

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 17 +
 1 file changed, 17 insertions(+)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 9923b1c9deb2..50237d302ce6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,409 +1,426 @@
 # Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: cargo.eclass
 # @MAINTAINER:
 # r...@gentoo.org
 # @AUTHOR:
 # Doug Goldstein 
 # Georgy Yakovlev 
 # @SUPPORTED_EAPIS: 7 8
 # @BLURB: common functions and variables for cargo builds
 
 if [[ -z ${_CARGO_ECLASS} ]]; then
 _CARGO_ECLASS=1
 
 # check and document RUST_DEPEND and options we need below in case conditions.
 # https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md
 RUST_DEPEND="virtual/rust"
 
 case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
7)
# 1.37 added 'cargo vendor' subcommand and net.offline config 
knob
RUST_DEPEND=">=virtual/rust-1.37.0"
;;
 
8)
# 1.39 added --workspace
# 1.46 added --target dir
# 1.48 added term.progress config option
# 1.51 added split-debuginfo profile option
# 1.52 may need setting RUSTC_BOOTSTRAP envvar for some crates
# 1.53 added cargo update --offline, can be used to update 
vulnerable crates from pre-fetched registry without editing toml
RUST_DEPEND=">=virtual/rust-1.53"
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
 esac
 
 inherit multiprocessing toolchain-funcs
 
 if [[ ! ${CARGO_OPTIONAL} ]]; then
BDEPEND="${RUST_DEPEND}"
EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install 
src_test
 fi
 
 IUSE="${IUSE} debug"
 
 ECARGO_HOME="${WORKDIR}/cargo_home"
 ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 
+# @ECLASS-VARIABLE: CRATES
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# bash string containing all crates package wants to download
+# used by cargo_crate_uris()
+# Example:
+# @CODE
+# CRATES="
+# metal-1.2.3
+# bar-4.5.6
+# iron_oxide-0.0.1
+# "
+# inherit cargo
+# ...
+# SRC_URI="$(cargo_crate_uris ${CRATES})"
+# @CODE
+
 # @ECLASS-VARIABLE: CARGO_OPTIONAL
 # @DEFAULT_UNSET
 # @PRE_INHERIT
 # @DESCRIPTION:
 # If set to a non-null value, before inherit cargo part of the ebuild will
 # be considered optional. No dependencies will be added and no phase
 # functions will be exported.
 #
 # If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
 # for your package and call at least cargo_gen_config manually before using
 # other src_ functions of this eclass.
 # note that cargo_gen_config is automatically called by cargo_src_unpack.
 
 # @ECLASS_VARIABLE: myfeatures
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Optional cargo features defined as bash array.
 # Should be defined before calling cargo_src_configure().
 #
 # Example package that has x11 and wayland as features, and disables default.
 # @CODE
 # src_configure() {
 #  local myfeatures=(
 #  $(usex X x11 '')
 #  $(usev wayland)
 #  )
 #  cargo_src_configure --no-default-features
 # }
 # @CODE
 
 # @ECLASS-VARIABLE: ECARGO_REGISTRY_DIR
 # @USER_VARIABLE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Storage directory for cargo registry.
 # Used by cargo_live_src_unpack to cache downloads.
 # This is intended to be set by users.
 # Ebuilds must not set it.
 #
 # Defaults to "${DISTDIR}/cargo-registry" it not set.
 
 # @ECLASS-VARIABLE: ECARGO_OFFLINE
 # @USER_VARIABLE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # If non-empty, this variable prevents online operations in
 # cargo_live_src_unpack.
 # Inherits value of EVCS_OFFLINE if not set explicitly.
 
 # @ECLASS-VARIABLE: EVCS_UMASK
 # @USER_VARIABLE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Set this variable to a custom umask. This is intended to be set by
 # users. By setting this to something like 002, it can make life easier
 # for people who use cargo in a home directory, but are in the portage
 # group, and then switch over to building with FEATURES=userpriv.
 # Or vice-versa.
 
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
 cargo_crate_uris() {
local -r regex='^([a-zA-Z0-9_\-]+)-([0-9]+\.[0-9]+\.[0-9]+.*)$'
local crate
for crate in "$@"; do
local name version url
[[ $crate =~ $regex ]] || die "Could not parse name and version 
from crate: $crate"
name="${BASH_REMATCH[1]}"
version

[gentoo-dev] [PATCH 1/2] cargo.eclass: support EAPI=8, misc changes

2021-07-01 Thread Georgy Yakovlev
remove cargo-snapshot* unpacker, it was needed
for separate dev-util/cargo we used to have.

Bug: https://bugs.gentoo.org/715890
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 15b9d455bdef..9923b1c9deb2 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,396 +1,409 @@
 # Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: cargo.eclass
 # @MAINTAINER:
 # r...@gentoo.org
 # @AUTHOR:
 # Doug Goldstein 
 # Georgy Yakovlev 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: common functions and variables for cargo builds
 
 if [[ -z ${_CARGO_ECLASS} ]]; then
 _CARGO_ECLASS=1
 
-# we need this for 'cargo vendor' subcommand and net.offline config knob
-RUST_DEPEND=">=virtual/rust-1.37.0"
+# check and document RUST_DEPEND and options we need below in case conditions.
+# https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md
+RUST_DEPEND="virtual/rust"
 
 case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
7)
+   # 1.37 added 'cargo vendor' subcommand and net.offline config 
knob
+   RUST_DEPEND=">=virtual/rust-1.37.0"
+   ;;
+
+   8)
+   # 1.39 added --workspace
+   # 1.46 added --target dir
+   # 1.48 added term.progress config option
+   # 1.51 added split-debuginfo profile option
+   # 1.52 may need setting RUSTC_BOOTSTRAP envvar for some crates
+   # 1.53 added cargo update --offline, can be used to update 
vulnerable crates from pre-fetched registry without editing toml
+   RUST_DEPEND=">=virtual/rust-1.53"
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
 esac
 
 inherit multiprocessing toolchain-funcs
 
 if [[ ! ${CARGO_OPTIONAL} ]]; then
BDEPEND="${RUST_DEPEND}"
EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install 
src_test
 fi
 
 IUSE="${IUSE} debug"
 
 ECARGO_HOME="${WORKDIR}/cargo_home"
 ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 
 # @ECLASS-VARIABLE: CARGO_OPTIONAL
 # @DEFAULT_UNSET
 # @PRE_INHERIT
 # @DESCRIPTION:
 # If set to a non-null value, before inherit cargo part of the ebuild will
 # be considered optional. No dependencies will be added and no phase
 # functions will be exported.
 #
 # If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
 # for your package and call at least cargo_gen_config manually before using
 # other src_ functions of this eclass.
 # note that cargo_gen_config is automatically called by cargo_src_unpack.
 
 # @ECLASS_VARIABLE: myfeatures
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Optional cargo features defined as bash array.
 # Should be defined before calling cargo_src_configure().
 #
 # Example package that has x11 and wayland as features, and disables default.
 # @CODE
 # src_configure() {
 #  local myfeatures=(
 #  $(usex X x11 '')
 #  $(usev wayland)
 #  )
 #  cargo_src_configure --no-default-features
 # }
 # @CODE
 
 # @ECLASS-VARIABLE: ECARGO_REGISTRY_DIR
 # @USER_VARIABLE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Storage directory for cargo registry.
 # Used by cargo_live_src_unpack to cache downloads.
 # This is intended to be set by users.
 # Ebuilds must not set it.
 #
 # Defaults to "${DISTDIR}/cargo-registry" it not set.
 
 # @ECLASS-VARIABLE: ECARGO_OFFLINE
 # @USER_VARIABLE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # If non-empty, this variable prevents online operations in
 # cargo_live_src_unpack.
 # Inherits value of EVCS_OFFLINE if not set explicitly.
 
 # @ECLASS-VARIABLE: EVCS_UMASK
 # @USER_VARIABLE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Set this variable to a custom umask. This is intended to be set by
 # users. By setting this to something like 002, it can make life easier
 # for people who use cargo in a home directory, but are in the portage
 # group, and then switch over to building with FEATURES=userpriv.
 # Or vice-versa.
 
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
 cargo_crate_uris() {
local -r regex='^([a-zA-Z0-9_\-]+)-([0-9]+\.[0-9]+\.[0-9]+.*)$'
local crate
for crate in "$@"; do
local name version url
[[ $crate =~ $regex ]] || die "Could not parse name and version 
from crate: $crate"
name="${BASH_REMATCH[1]}"
version="${BASH_REMATCH[2]}"

url="https://crates.io/api/v1/crates/${name}/${vers

[gentoo-dev] [PATCH] metadata/install-qa-check.d: add virtual/libcrypt dep check

2021-06-26 Thread Georgy Yakovlev
Bug: https://bugs.gentoo.org/699422
Signed-off-by: Georgy Yakovlev 
---
 metadata/install-qa-check.d/60libcrypt-deps | 38 +
 1 file changed, 38 insertions(+)
 create mode 100644 metadata/install-qa-check.d/60libcrypt-deps

diff --git a/metadata/install-qa-check.d/60libcrypt-deps 
b/metadata/install-qa-check.d/60libcrypt-deps
new file mode 100644
index ..fd915fb852d7
--- /dev/null
+++ b/metadata/install-qa-check.d/60libcrypt-deps
@@ -0,0 +1,38 @@
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that package specifies a dependency on virtual/libcrypt
+# Author: Georgy Yakovlev 
+# Maintainer Sam James 
+
+libcrypt_check() {
+   if ! type -P scanelf >/dev/null || has binchecks ${PORTAGE_RESTRICT}; 
then
+   return
+   fi  
+
+   # nothing to do here
+   if grep -q virtual/libcrypt <<<${RDEPEND}; then
+   return
+   fi
+
+   local libcrypt_consumers
+   # grep outputs newline separated list of files, so it's ok to skip 
specifying delimiter
+   IFS= mapfile libcrypt_consumers < <(find "${ED}" -type f -executable \
+   -print0 | xargs -0 scanelf -qyRF '%F %n' | grep 'libcrypt.so' 
2>/dev/null )
+   
+   if [[ -n ${libcrypt_consumers[@]} ]]; then
+   eqawarn "Binary files linked to libcrypt.so found"
+   eqawarn "But dependency on virtual/libcrypt is not declared"
+   eqawarn
+   eqatag -v virtual-libcrypt.missing "${libcrypt_consumers[@]%% 
*}"
+   eqawarn
+   eqawarn "Please add virtual/libcrypt dependency"
+   eqawarn "Gentoo Bug: https://bugs.gentoo.org/699422;
+   fi
+   
+}
+
+libcrypt_check
+: # guarantee successful exit
+
+# vim:ft=sh
-- 
2.32.0




[gentoo-dev] [PATCH] metadata/install-qa-check.d: add virtual/libcrypt dep check

2021-06-24 Thread Georgy Yakovlev
Bug: https://bugs.gentoo.org/699422
Signed-off-by: Georgy Yakovlev 
---
 metadata/install-qa-check.d/60libcrypt-deps | 38 +
 1 file changed, 38 insertions(+)
 create mode 100644 metadata/install-qa-check.d/60libcrypt-deps

diff --git a/metadata/install-qa-check.d/60libcrypt-deps 
b/metadata/install-qa-check.d/60libcrypt-deps
new file mode 100644
index ..bc7b8d3dced2
--- /dev/null
+++ b/metadata/install-qa-check.d/60libcrypt-deps
@@ -0,0 +1,38 @@
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that package specifies a dependency on virtual/libcrypt
+# Author: Georgy Yakovlev 
+# Maintainer Sam James 
+
+libcrypt_check() {
+   if ! type -P scanelf >/dev/null || has binchecks ${PORTAGE_RESTRICT}; 
then
+   return
+   fi  
+
+   # nothing to do here
+   if grep -q virtual/libcrypt <<<${RDEPEND}; then
+   return
+   fi
+
+   local libcrypt_consumers
+   # grep outputs newline separated list of files, so it's ok to skip 
specifying delimiter
+   IFS= mapfile libcrypt_consumers < <(find "${ED}" -type f -executable \
+   -print0 | xargs -0 scanelf -qyRF '%F %n' {} + | grep 
'libcrypt.so' 2>/dev/null )
+   
+   if [[ -n ${libcrypt_consumers[@]} ]]; then
+   eqawarn "Binary files linked to libcrypt.so found"
+   eqawarn "But dependency on virtual/libcrypt is not declared"
+   eqawarn
+   eqatag -v virtual-libcrypt.missing "${libcrypt_consumers[@]%% 
*}"
+   eqawarn
+   eqawarn "Please add virtual/libcrypt dependency"
+   eqawarn "Gentoo Bug: https://bugs.gentoo.org/699422;
+   fi
+   
+}
+
+libcrypt_check
+: # guarantee successful exit
+
+# vim:ft=sh
-- 
2.32.0




[gentoo-dev] Last-rites: sys-apps/timer_entropyd

2021-05-15 Thread Georgy Yakovlev
# Georgy Yakovlev  (2011-05-15)
# Dead upstream, homepage missing, EAPI=5, no systemd units.
# https://bugs.gentoo.org/790413 , #434900, #552760
# Use any of or combination of the following instead:
# sys-apps/rng-tools
# sys-apps/haveged
# app-crypt/jitterentropy-rngd
sys-apps/timer_entropyd

-- 
Best regards,
Georgy


signature.asc
Description: PGP signature


Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

2021-04-25 Thread Georgy Yakovlev
On 22.04.2021 10:22, Miroslav Šulc wrote:
> Dne 22. 04. 21 v 8:37 Kaibo Ma napsal(a):
> > Is there a tracking issue for Java 11 on Bugzilla?
> > 
> > Kaibo Ma
> 
> this is it: https://bugs.gentoo.org/697014

created an alias for it, also can be found as

https://bugs.gentoo.org/show_bug.cgi?id=jdk11

and simply searching for jdk11 in the search field
> 
> fordfrog
> 
> 
> 

-- 
Best regards,
Georgy


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH 2/2] profiles/info_pkgs: print rust{,-bin} versions

2021-04-03 Thread Georgy Yakovlev
Bug: https://bugs.gentoo.org/756340
Signed-off-by: Georgy Yakovlev 
---
 profiles/info_pkgs | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/profiles/info_pkgs b/profiles/info_pkgs
index 9c12cc958ac7..650516bcf853 100644
--- a/profiles/info_pkgs
+++ b/profiles/info_pkgs
@@ -17,6 +17,8 @@ sys-devel/libtool
 sys-devel/make
 dev-lang/python
 dev-lang/perl
+dev-lang/rust
+dev-lang/rust-bin
 sys-apps/sandbox
 dev-util/ccache
 sys-devel/gcc
-- 
2.31.1




[gentoo-dev] [PATCH 1/2] profiles/info_vars: print RUSTFLAGS as well

2021-04-03 Thread Georgy Yakovlev
Bug:  https://bugs.gentoo.org/756340
Signed-off-by: Georgy Yakovlev 
---
 profiles/info_vars | 1 +
 1 file changed, 1 insertion(+)

diff --git a/profiles/info_vars b/profiles/info_vars
index b578103d116a..051948c1e8ef 100644
--- a/profiles/info_vars
+++ b/profiles/info_vars
@@ -34,6 +34,7 @@ PORTAGE_CONFIGROOT
 PORTAGE_TMPDIR
 PORTDIR
 PORTDIR_OVERLAY
+RUSTFLAGS
 SYNC
 USE
 PORTAGE_RSYNC_OPTS
-- 
2.31.1




Re: [gentoo-dev] Packages up for grabs: telegram-desktop & deps

2021-03-26 Thread Georgy Yakovlev
On 28.02.2021 12:21, Georgy Yakovlev wrote:
> The following packages are for grabs:
> 
> net-im/telegram-desktop
> media-libs/libtgvoip ( no other revdeps )
> media-libs/tg_owt ( no other revdeps )
> dev-cpp/range-v3 ( has another revdep, not only tg )
> 
> Many bugs open and many issues.
> 
> Before you try to take it over, here's some info for future maintainers:
> 0. you better speak Russian to be able to reach devs =) optional, but VERY 
> beneficial. I can connect you to developer group.
> 
> 1. expect to deal with a lot of bundling, no releases, submodules and all 
> related packaging issues with this approach.
> 
> 2. expect pretty aggressive userbase, very direct, even brutally so.
> 
> 3. expect dependency fights between wayland-only crowd and x11-only crowd.
> 
> 4. same as above but for pulse vs alsa.
> 
> 5. same as above but openssl vs libressl (this one should be easier nowadays 
> as support is going away)
> 
> 6. project is split into 4 repos basically, 1 for app, 1 for webrtc, 1 for 
> cmake files, 1 for audio lib. there are no releases for any except tdesktop 
> itself.
> 
> 7. expect to read a lot of cmake cross-referenced across all those 4 repos.
> 
> 8. expect to be able to patch cmake a lot. for example one can't toggle off 
> automagic deps.
> 
> 9. expect to collaborate with other disto developers, who also work on 
> mentioned tasks. rpmfusion and freebsd guys are very helpful and solve same 
> problems as we do.
> 
> 
> If you are still reading - reach out, I'll help to get started.
> I don't have time to maintain it anymore, so it either should be removed or 
> go into caring hands, as it needs A LOT OF CARE.
> 
> https://bugs.gentoo.org/buglist.cgi?quicksearch=telegram-desktop
> -- 
> Best regards,
> Georgy

Since this message made it to some news websites, I'd like to send a
follow-up with a positive resolution.

tdesktop have finally found a caring person and is now proxy-maintained.
we've got an update that fixes quite a lot of issues, including audio
call crashes under some conditions and work on unbundling critical libraries is 
in progress.
it will remain in the tree, I'm proxying and still testing it on
non-amd64 arches (forcing SSE2 is not nice).

stabilization of new versions will happen sooner than later.

Have a nice day ;-)

-- 
Best regards,
Georgy


signature.asc
Description: PGP signature


[gentoo-dev] Packages up for grabs: telegram-desktop & deps

2021-02-28 Thread Georgy Yakovlev
The following packages are for grabs:

net-im/telegram-desktop
media-libs/libtgvoip ( no other revdeps )
media-libs/tg_owt ( no other revdeps )
dev-cpp/range-v3 ( has another revdep, not only tg )

Many bugs open and many issues.

Before you try to take it over, here's some info for future maintainers:
0. you better speak Russian to be able to reach devs =) optional, but VERY 
beneficial. I can connect you to developer group.

1. expect to deal with a lot of bundling, no releases, submodules and all 
related packaging issues with this approach.

2. expect pretty aggressive userbase, very direct, even brutally so.

3. expect dependency fights between wayland-only crowd and x11-only crowd.

4. same as above but for pulse vs alsa.

5. same as above but openssl vs libressl (this one should be easier nowadays as 
support is going away)

6. project is split into 4 repos basically, 1 for app, 1 for webrtc, 1 for 
cmake files, 1 for audio lib. there are no releases for any except tdesktop 
itself.

7. expect to read a lot of cmake cross-referenced across all those 4 repos.

8. expect to be able to patch cmake a lot. for example one can't toggle off 
automagic deps.

9. expect to collaborate with other disto developers, who also work on 
mentioned tasks. rpmfusion and freebsd guys are very helpful and solve same 
problems as we do.


If you are still reading - reach out, I'll help to get started.
I don't have time to maintain it anymore, so it either should be removed or go 
into caring hands, as it needs A LOT OF CARE.

https://bugs.gentoo.org/buglist.cgi?quicksearch=telegram-desktop
-- 
Best regards,
Georgy


signature.asc
Description: PGP signature


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

2020-11-28 Thread Georgy Yakovlev
On 25.11.2020 13:57, Georgy Yakovlev wrote:
> Hi,
> 
> In case you don't know, opentmpfiles has an open CVE
> CVE-2017-18925: root privilege escalation by symlink attack
> https://github.com/OpenRC/opentmpfiles/issues/4
> It has been an issue for quite a while, reported 3 years ago,
> and not much changed since.
> Also it lacks any sort of testing, and master branch is in a non-working
> state at time of writing, latest version is masked.[0]
> 
> Due to nature of opentmpfiles (it's a POSIX sh script),
> it may be impossible to fix symlink handling and TOCTOU races.
> As a consequence I'll be switching default tmpfiles
> provider to sys-apps/systemd-tmpfiles by the end of the week by updating
> virtual/tmpfiles ebuild.
> 
> pros of systemd-tmpfiles:
> 0) Secure.
> 1) Reference implementation.
> 2) Supports all features, because ^.
> 3) Has working tests.
> 4) Has millions of users as part of systemd.
> 5) upstream supports standalone usecase/build our ebuild uses. [1][2]
> 6) drop-in replacement, just emerge and forget.
> 
> 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.
> 
> existing installations will not be affected, but openrc users are welcome to
> opt-in by running 'emerge --oneshot systemd-tmpfiles'
> 
> [0] https://bugs.gentoo.org/751739
> [1] https://github.com/systemd/systemd/pull/16061
> [2] 
> https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4

This is done in
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab23417927d8454c8bb1c0ae52a5cac79d140b94


signature.asc
Description: PGP signature


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

2020-11-25 Thread Georgy Yakovlev
Hi,

In case you don't know, opentmpfiles has an open CVE
CVE-2017-18925: root privilege escalation by symlink attack
https://github.com/OpenRC/opentmpfiles/issues/4
It has been an issue for quite a while, reported 3 years ago,
and not much changed since.
Also it lacks any sort of testing, and master branch is in a non-working
state at time of writing, latest version is masked.[0]

Due to nature of opentmpfiles (it's a POSIX sh script),
it may be impossible to fix symlink handling and TOCTOU races.
As a consequence I'll be switching default tmpfiles
provider to sys-apps/systemd-tmpfiles by the end of the week by updating
virtual/tmpfiles ebuild.

pros of systemd-tmpfiles:
0) Secure.
1) Reference implementation.
2) Supports all features, because ^.
3) Has working tests.
4) Has millions of users as part of systemd.
5) upstream supports standalone usecase/build our ebuild uses. [1][2]
6) drop-in replacement, just emerge and forget.

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.

existing installations will not be affected, but openrc users are welcome to
opt-in by running 'emerge --oneshot systemd-tmpfiles'

[0] https://bugs.gentoo.org/751739
[1] https://github.com/systemd/systemd/pull/16061
[2] 
https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4


signature.asc
Description: PGP signature


Re: [gentoo-dev] Pushing to distfiles?

2020-11-11 Thread Georgy Yakovlev
On 11.11.2020 19:23, Joshua Kinard wrote:
> Forgive me for being a dunce, but what is the current procedure to push
> files to distfiles for distribution to the mirrors?  The devmanual is blank
> on this topic, and GLEP75 just talks about the motivations behind the change
> away from the flat directory format.  I am not easily finding anything that
> details how to get new distfiles onto the mirrors.
Hi,

Just put to devspace.
for example I keep distfiles in ~/public_html/distfiles

This is preferred of having file on mirrors only.
And it will be automatically mirrored from devspace, so no extra steps
required.
> 
> Thanks,
> 
> -- 
> Joshua Kinard
> Gentoo/MIPS
> ku...@gentoo.org
> rsa6144/5C63F4E3F5C6C943 2015-04-27
> 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
> 
> "The past tempts us, the present confuses us, the future frightens us.  And
> our lives slip away, moment by moment, lost in that vast, terrible 
> in-between."
> 
> --Emperor Turhan, Centauri Republic
> 


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] eclass/cargo.eclass: add CARGO_OPTIONAL condition

2020-11-10 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index e6fec844d274..03dfbfebd1d7 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -15,20 +15,40 @@ _CARGO_ECLASS=1
 # we need this for 'cargo vendor' subcommand and net.offline config knob
 RUST_DEPEND=">=virtual/rust-1.37.0"
 
-case ${EAPI} in
-   7) BDEPEND="${RUST_DEPEND}";;
-   *) die "EAPI=${EAPI:-0} is not supported" ;;
+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 multiprocessing toolchain-funcs
 
-EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
+if [[ ! ${CARGO_OPTIONAL} ]]; then
+   BDEPEND="${RUST_DEPEND}"
+   EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install 
src_test
+fi
 
 IUSE="${IUSE} debug"
 
 ECARGO_HOME="${WORKDIR}/cargo_home"
 ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 
+# @ECLASS-VARIABLE: CARGO_OPTIONAL
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# If set to a non-null value, before inherit cargo part of the ebuild will
+# be considered optional. No dependencies will be added and no phase
+# functions will be exported.
+#
+# If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
+# for your package and call at least cargo_gen_config manually before using
+# other src_ functions of this eclass.
+
 # @VARIABLE: myfeatures
 # @DEFAULT_UNSET
 # @DESCRIPTION:
-- 
2.29.2




[gentoo-dev] RFC: introduce RUST_TARGETS use-expand (take2)

2020-10-10 Thread Georgy Yakovlev

Hi,

sending again, accidentally sent from personal email first time and it's 
stuck somewhere.


I would like to introduce new USE_EXPAND in profiles for rusts
3 consumers in the tree:
dev-lang/rust
dev-lang/rust-bin
sys-devel/rust-std
and maybe virtual, but not sure yet, may be required for firefox.

The idea:
Rust supports building as many targets as one wants, as long as C 
toolchan can do it and matching llvm target is enabled on rust or llvm.


There are some special rust targets that require same host toolchain but 
are treated like separate targets in rust.

For example x86_64-unknown-linux-gnu target is primary on amd64,
but on multilib profiles we can easily enable i686-unknown-linux-gnu 
target and it will just work (that's how multilib in rust works now)


Another example is arm:

armv7-unknown-linux-gnueabihf is primary toolchain.
but rust supports additional target thumbv7neon-unknown-linux-gnueabihf,
which requires exactly same host toolchain, but is capable of emitting 
thumb-neon binaries. This is required by firefox if --enable-neon is 
passed in firefox build.


Another example: ppc64

We can easily build both ppc64 and ppc64le targets in a single bootstrap 
with host toolchain, and rust will support emitting code for both endians.


Another example: musl

On musl we need 1 extra target with gentoo vendor field.
So installing both
  x86_64-unknown-linux-musl
  x86_64-gentoo-linux-musl
will be very easy, as both targets use same C toolchain, but slightly 
different settings.


And last, but not the least, it allows cross support if matching 
toolchain is installed (tested with crossdev)

A user can unmask the following targets on amd64
  rust_targets_thumbv7neon-unknown-linux-gnueabihf
  rust_targets_armv7-unknown-linux-gnueabihf

And as long as they have /usr/armv7a-unknown-linux-gnueabihf toolchain 
available at build time, and llvm_targets_ARM enabled, rust will 
bootstrap itself in a way that it will be able to emit code for any of 3 
targets enable. This is optional opt-in functionality.


And just to clarify, native host toolchain is not going to be a 
use-expand, at least that's how I imagine it now.
Native target matching CHOST is always build without any flags, and is 
the default target for rust.

But I may re-evaluate it and introduce requirements like

 abi_x86_64?? ( rust_targets_x86_64-unknown-linux-gnu )
 abi_x86_32? ( rust_targets_i686-unknown-linux-gnu )

for multilib profiles.

and something like this for non-multilib arches.

 ppc64? ( ||
rust_targets_powerpc64le-unknown-linux-gnu
rust_targets_powerpc64-unknown-linux-gnu
)

for example, similar to as llvm does with LLVM_TARGETS.
Of course default targets will be use-forced via profiles.
But if possible I'd avoid it.


Proof of concept exists (without using expand flags for now) in both 
rust and rust-bin ebuilds. Multilib is implemented that way and has been 
working great for more than a year, also experimental cross support in 
rust implemented that way, and users are already able to define as many 
targets as they want, but it feels hacky and I would like to move 
forward to targets approach and make it trackable via flags, and not 
magic variables nobody knows about.



Initial rollout will require a bit of arch profile masking (like llvm 
does it) and maybe new eclass to reduce boilerplate code in ebuilds, but 
nothing to complex.


WDYT?

tracking bug https://bugs.gentoo.org/747760

cross bugs:
https://bugs.gentoo.org/679878
https://bugs.gentoo.org/680652
https://bugs.gentoo.org/689336

Regards, Georgy.



[gentoo-dev] Re: RFC: introduce RUST_TARGETS use-expand

2020-10-10 Thread Georgy Yakovlev

On 10/10/20 7:17 PM, Georgy Yakovlev wrote:

Hi,
Sorry, thunderbird used personal mailfrom for some reason. Probably an 
issue after update.


OpenPGP_0xA5EDB076475B46A6.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 2/2] eclass/cargo.eclass: require cargo_gen_config in cargo_src* functions

2020-09-27 Thread Georgy Yakovlev
cargo_gen_config sets required config values and env vars, which
cargo_src_{compile,test,install} rely on.

it should be called as last step of src_unpack normally, so check it did.
Crate sources may have been vendored or cargo is wrapped by other build
system and pre-fetched, so cargo_*unpack may be not used.

In that case we can't guarantee our config will work, so src_ functions
should not be used.

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index dde601ec4e3c..3e0bb443 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -267,6 +267,7 @@ cargo_gen_config() {
_EOF_
 
export CARGO_HOME="${ECARGO_HOME}"
+   _CARGO_GEN_CONFIG_HAS_RUN=1
 }
 
 # @FUNCTION: cargo_src_configure
@@ -323,6 +324,9 @@ cargo_src_configure() {
 cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
+   [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+   die "FATAL: please call cargo_gen_config before using 
${FUNCNAME}"
+
tc-export AR CC CXX
 
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
@@ -340,6 +344,9 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
+   [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+   die "FATAL: please call cargo_gen_config before using 
${FUNCNAME}"
+
set -- cargo install $(has --path ${@} || echo --path ./) \
--root "${ED}/usr" \
$(usex debug --debug "") \
@@ -359,6 +366,9 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
+   [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+   die "FATAL: please call cargo_gen_config before using 
${FUNCNAME}"  
+
set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo test failed"
-- 
2.28.0




[gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: support cached downloads for live ebuilds

2020-09-27 Thread Georgy Yakovlev
Also honor ECARGO_OFFLINE/EVCS_OFFLINE
Good portion of the code/logic inspired by git-r3.eclass.

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 115 +---
 1 file changed, 108 insertions(+), 7 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 6d341601a112..dde601ec4e3c 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -46,6 +46,35 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 # }
 # @CODE
 
+# @ECLASS-VARIABLE: ECARGO_REGISTRY_DIR
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Storage directory for cargo registry.
+# Used by cargo_live_src_unpack to cache downloads.
+# This is intended to be set by users.
+# Ebuilds must not set it.
+#
+# Defaults to '${DISTDIR}/ecargo-registry' it not set.
+
+# @ECLASS-VARIABLE: ECARGO_OFFLINE
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, this variable prevents online operations in
+# cargo_live_src_unpack.
+# Inherits value of EVCS_OFFLINE if not set explicitly.
+
+# @ECLASS-VARIABLE: EVCS_UMASK
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Set this variable to a custom umask. This is intended to be set by
+# users. By setting this to something like 002, it can make life easier
+# for people who use cargo in a home directory, but are in the portage
+# group, and then switch over to building with FEATURES=userpriv.
+# Or vice-versa.
+
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -122,13 +151,84 @@ cargo_live_src_unpack() {
[[ "${EBUILD_PHASE}" == unpack ]] || die "${FUNCNAME} only allowed in 
src_unpack"
 
mkdir -p "${S}" || die
+   mkdir -p "${ECARGO_VENDOR}" || die
+   mkdir -p "${ECARGO_HOME}" || die
+
+   local distdir=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}
+   : ${ECARGO_REGISTRY_DIR:=${distdir}/ecargo-registry}
+
+   local offline="${ECARGO_OFFLINE:-${EVCS_OFFLINE}}"
+
+   if [[ ! -d ${ECARGO_REGISTRY_DIR} && ! ${offline} ]]; then
+   (
+   addwrite "${ECARGO_REGISTRY_DIR}"
+   mkdir -p "${ECARGO_REGISTRY_DIR}"
+   ) || die "Unable to create ${ECARGO_REGISTRY_DIR}"
+   fi
+
+   if [[ ${offline} ]]; then
+   local subdir
+   for subdir in cache index src; do
+   if [[ ! -d ${ECARGO_REGISTRY_DIR}/registry/${subdir} 
]]; then
+   eerror "Networking activity has been disabled 
via ECARGO_OFFLINE or EVCS_OFFLINE"
+   eerror "However, no valid cargo registry 
available at ${ECARGO_REGISTRY_DIR}"
+   die "Unable to proceed with 
ECARGO_OFFLINE/EVCS_OFFLINE."
+   fi
+   done
+   fi
+
+   if [[ ${EVCS_UMASK} ]]; then
+   local saved_umask=$(umask)
+   umask "${EVCS_UMASK}" || die "Bad options to umask: 
${EVCS_UMASK}"
+   fi
 
pushd "${S}" > /dev/null || die
-   # need to specify CARGO_HOME before cargo_gen_config fired
-   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
-   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+
+   # Respect user settings befire cargo_gen_config is called.
+   if [[ ! ${CARGO_TERM_COLOR} ]]; then
+   [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && export 
CARGO_TERM_COLOR=never
+   local unset_color=true
+   fi
+   if [[ ! ${CARGO_TERM_VERBOSE} ]]; then
+   export CARGO_TERM_VERBOSE=true
+   local unset_verbose=true
+   fi
+
+   # Let cargo fetch to system-wide location.
+   # It will keep directory organized by itself.
+   addwrite "${ECARGO_REGISTRY_DIR}"
+   export CARGO_HOME="${ECARGO_REGISTRY_DIR}"
+
+   # Absence of quotes around offline arg is intentional, as cargo bails 
out if it encounters ''
+   einfo "cargo fetch ${offline:+--offline}"
+   cargo fetch ${offline:+--offline} || die #nowarn
+
+   # Let cargo copy all required crates to "${WORKDIR}" for offline use in 
later phases.
+   einfo "cargo vendor ${offline:+--offline} ${ECARGO_VENDOR}"
+   cargo vendor ${offline:+--offline} "${ECARGO_VENDOR}" || die #nowarn
+
+   # Users may have git checkouts made by cargo.
+   # While cargo vendors the sources, it still needs git checkout to be 
present.
+   # Copying full dir is an overkill, so just symlink it.
+   if [[ -d ${ECARGO_REGISTRY_DIR}/git ]]; then
+   ln -sv "${ECARGO_REGISTRY_DIR}/git" "${ECARGO_HOME}/git" || die
+   fi
+
popd 

Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps

2020-09-19 Thread Georgy Yakovlev
took a while, removed.

I was able to save jabref-bin, works fine with openjdk:8
geogebra now availabie as geogebra-bin and works with openjdk8 and 11.
sleuthkit was spared.

rest is gone, but if someone wants to restore - patches welcome.


On 4/18/20 9:10 PM, Georgy Yakovlev wrote:
> # Georgy Yakovlev  (2020-04-18)
> # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
> # requires agreement to restrictive license
> # Revdeps that still depend on oracle variants require javafx
> # Please use icedtea or openjdk instead.
> # Removal in 30 days.
> # https://bugs.gentoo.org/681828
> dev-java/oracle-jdk-bin
> dev-java/oracle-jre-bin
> app-forensics/sleuthkit
> app-text/jabref-bin
> dev-java/netbeans-platform
> dev-java/netbeans-harness
> games-util/pogo-manager-bin
> net-p2p/bisq
> sci-mathematics/geogebra
> 
> 
> 
> Oracle java has been maintainer-needed since august 2019,
> no one stepped up.
> Removal in 30 days.
> 
> If someone wants to save the javafx revdeps, best way will be
> packaging zulufx community [1], I can provide some guidance
> on packaging it, should not be too hard.
> 




[gentoo-dev] Last rites: dev-python/ansimarkup

2020-09-02 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-09-02)


# Masked for removal. No revdeps.


dev-python/ansimarkup



[gentoo-dev] Re: [PATCH] profiles/base/make.defaults: ENV_UNSET CARGO_HOME

2020-08-30 Thread Georgy Yakovlev
On 8/28/20 2:09 PM, Georgy Yakovlev wrote:
> CARGO_HOME may leak into ebuild environment and lead to
> write attempts to directory specified.
> This is explicitly taken care of in cargo.eclass, but
> ebuilds that don't use the eclass can still be affected.
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  profiles/base/make.defaults | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
> index 1ac69f51ec9..9f570d905c8 100644
> --- a/profiles/base/make.defaults
> +++ b/profiles/base/make.defaults
> @@ -40,7 +40,7 @@ CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf"
>  # GOBIN needs to be cleaned as random values in GOBIN can affect the
>  # building of some packages:
>  # 
> https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0
> -ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
> XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
> PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH"
> +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
> XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
> PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH CARGO_HOME"
>  
>  # Variables that are set exclusively by the profile
>  # and not by user configuration files.
> 

Pushed.



[gentoo-dev] [PATCH] profiles/base/make.defaults: ENV_UNSET CARGO_HOME

2020-08-28 Thread Georgy Yakovlev
CARGO_HOME may leak into ebuild environment and lead to
write attempts to directory specified.
This is explicitly taken care of in cargo.eclass, but
ebuilds that don't use the eclass can still be affected.

Signed-off-by: Georgy Yakovlev 
---
 profiles/base/make.defaults | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index 1ac69f51ec9..9f570d905c8 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -40,7 +40,7 @@ CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf"
 # GOBIN needs to be cleaned as random values in GOBIN can affect the
 # building of some packages:
 # 
https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0
-ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH"
+ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH CARGO_HOME"
 
 # Variables that are set exclusively by the profile
 # and not by user configuration files.
-- 
2.28.0




Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Georgy Yakovlev
On 8/5/20 5:02 AM, Thomas Deutschmann wrote:
> Hi,
> 
> please review the news item below:
> 

Not all arches support --reuse-cmdline btw.
It may be only x86 which supports it.

This looks like a candidate wiki page or a word of warning in a
handbook, not a news item.



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

2020-07-11 Thread Georgy Yakovlev
Hello People,

The following packages are up for grabs:

# untested with plundervolt mitigations, please test.
sys-power/intel-undervolt | need intel CPU machine to maintain

# rust stuff
app-misc/skim | needs bump, cleanup and new stable
app-shells/mcfly | needs minor bump
app-text/fblog | needs major bump
sys-apps/bat | great upstream, very friendly
sys-apps/exa | may be abandoned, check upstream


# vagrant bundle. take all 3 together.
app-emulation/vagrant | low prio bug [1]
dev-ruby/hashicorp-checkpoint | tests fail bug [2]
dev-ruby/vagrant_cloud

# random stuff
app-shells/loksh | release syned with openbsd releases
mail-client/aerc | go package, great upstream

-
Regards, Georgy.

[1] https://bugs.gentoo.org/589114
[2] https://bugs.gentoo.org/723820



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] eclass/cargo.eclass: add cargo_src_configure (revised)

2020-06-12 Thread Georgy Yakovlev
simple src_configure implementation inspired by cmake.eclass

Closes: https://bugs.gentoo.org/721936

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 77 -
 1 file changed, 70 insertions(+), 7 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ccbf87aa9a6..77c8e90755b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -22,7 +22,7 @@ esac
 
 inherit multiprocessing toolchain-funcs
 
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
 
 IUSE="${IUSE} debug"
 
@@ -34,6 +34,29 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 # Allows overriding the default cwd to run cargo install from
 : ${CARGO_INSTALL_PATH:=.}
 
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before 
calling
+# src_configure.
+# If this array is not empty, --no-default-features is passed to cargo.
+# To enable default crate features in that case you can add 'default' to the 
array.
+# Extra positional arguments supplied to this function
+# will be passed to cargo in all phases.
+# Make sure all cargo subcommands support flags passed here.
+#
+# Example for package that has x11 and wayland as features, and enables 
default set.
+# @CODE
+# src_configure() {
+#  local myfeatures=(
+#  default
+#  $(usex X x11 '')
+#  $(usev wayland)
+#  )
+#  cargo_src_configure
+# }
+# @CODE
+
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -112,6 +135,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
 
pushd "${S}" > /dev/null || die
+   # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -151,6 +175,47 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color = 
'never'" >> "${ECARGO_HOME}/config"
+
+   export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features and arguments.
+# Example for package that explicitly builds only 'foo' binary and
+# enables single feature 'barfeature', disabling default feature set.
+# will pass '--no-default-features --features barfeature --bin foo'
+# in src_{compile,test,install}
+# @CODE
+# src_configure() {
+#  local myfeatures=(
+#  barfeature
+#  )
+#  cargo_src_configure --bin foo
+# }
+# @CODE
+
+cargo_src_configure() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+   local myfeaturestype=$(declare -p myfeatures 2>&-)
+   if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+   die "myfeatures must be declared as array"
+   fi
+
+   # transform array from simple feature list
+   # to multiple cargo args:
+   # --features feature1 --features feature2 ...
+   # this format is chosen because 2 other methods of
+   # listing features (space OR comma separated) require
+   # more fiddling with strings we'd like to avoid here.
+   myfeatures=( ${myfeatures[@]/#/--features } )
+
+   # prepend --no-default features if myfeatures array is not empty, 
append extra args
+   readonly ECARGO_ARGS=( ${myfeatures:+--no-default-features 
${myfeatures[@]}} ${@} )
+
+   [[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
 }
 
 # @FUNCTION: cargo_src_compile
@@ -159,11 +224,9 @@ cargo_gen_config() {
 cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
 
-   cargo build $(usex debug "" --release) "$@" \
+   cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo build failed"
 }
 
@@ -173,8 +236,8 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install --path ${CARGO_INSTALL_PATH} \
-   --root="${ED}/usr" $(usex debug --debug "") "$@" \
+   cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+   $(usex debug --debug "") ${ECARGO_ARGS[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -188,7 +251,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test $(usex debug "" --release) "$@" \
+   cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo test failed"
 }
 
-- 
2.27.0




Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 11:59 AM, Luca Barbato wrote:
> On 12/06/2020 18:24, Georgy Yakovlev wrote:
>> On 6/12/20 4:16 AM, Luca Barbato wrote:
>>> On 12/06/2020 11:04, Georgy Yakovlev wrote:
>>>> +# cargo_src_configure --no-default-features
>>>
>>> Shall we default in not-defaulting so we can spare some boilerplate?
>> I don't think so. Let me explain.
>>
>> First of all, this will force to explicitly micro-manage all the
>> features for all the packages in the tree.
>>
> 
> The idea is:
> - if myfeatures is empty, do not pass --no-default-features.
> - if myfeatures has content, automatically pass --no-default-features.
> 
I realized that was the intention after sending the email.
That makes more sense, I'll scout toml files a bit and probably will
implement it.
I certainly remember scenarios where turning off default features is
highly undesirable, but toggling extras makes sense.
> --no-default-features --features default seems working as intended btw.
> 

in that case
local myfeatures=(
default
$(usex flagX featureX '')
)
-> --no-default-features --features default --features featureX

looks quite good actually. just need to make sure we pass
--no-default-features first in order in that scenario.
> lu




[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support

2020-06-12 Thread Georgy Yakovlev
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  eclass/cargo.eclass | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
>  RUST_DEPEND=">=virtual/rust-1.37.0"
>  
>  case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
>   7) BDEPEND="${RUST_DEPEND}";;
>   *) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
> 
merged c30b9bed5d16025c59b878e9dff69b90af41bf4d



Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 6:03 AM, Kent Fredric wrote:

I've replied privately by mistake, replying to the list again.
> On Fri, 12 Jun 2020 02:04:51 -0700
> Georgy Yakovlev  wrote:
> 
>> +#   cargo_src_configure --no-default-features
> 
> Looking at the source, I don't see how this is passed from this command to 
> anything.
yeah I caught it later, will just pass it as

readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )

> 
>> +# transform array from simple feature list
>> +# to multiple cargo args:
>> +# --features feature1 --features feature2 ...
>> +readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
> 
> Is this really necessary?
> 
>> cargo --features "feature1 feature2"
> 
> is perfectly legal.
> 
cargo is very picky about how multiple features are quoted in your example.
like REALLY picky, and it breaks depending on how array is passed.
I had that initially but found that just not worth it because it may break.
multiple toggles is perfectly legal way to pass features as well and is
more robust in this situation IMO.





Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 4:16 AM, Luca Barbato wrote:
> On 12/06/2020 11:04, Georgy Yakovlev wrote:
>> +# cargo_src_configure --no-default-features
> 
> Shall we default in not-defaulting so we can spare some boilerplate?
I don't think so. Let me explain.

First of all, this will force to explicitly micro-manage all the
features for all the packages in the tree.

Like 90% of crates I've seen ship working choice and there's no benefit
of micro-management, and no benefit of enabling non-default features at
all. Not all features need to be exposed as use-flags, and this was
quite consistent situation so far.

I know it may sound a bit strange but automagic in this case works with
no downsides, unlike other languages/frameworks/build-systems.

Also it will break all the tree packages which do not manage features
directly if merged as is.

Not sure if --features=default  will activate default set and how it
will react to being passed along.

--no-default-features --features default
IDK, looks kinda unnatural.

I have a feeling that we'll get more boilerplate if we pass
--no-default-features than if we don't.

We can re-evaluate as time goes by, but for now I see no major benefit
and only downsides.
> 
> lu
> 




[gentoo-dev] Re: [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> simple src_configure implementation inspired by cmake.eclass
> 
> Closes: https://bugs.gentoo.org/721936
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  eclass/cargo.eclass | 51 ++---
>  1 file changed, 44 insertions(+), 7 deletions(-)
> 
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..b084e082730 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -23,7 +23,7 @@ esac
>  
>  inherit multiprocessing toolchain-funcs
>  
> -EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
> +EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
>  
>  IUSE="${IUSE} debug"
>  
> @@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
>  # Allows overriding the default cwd to run cargo install from
>  : ${CARGO_INSTALL_PATH:=.}
>  
> +# @VARIABLE: myfeatures
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Optional cargo features defined as bash array. Should be defined before 
> calling
> +# src_configure.
> +# Example for package that has x11 and wayland as features.
> +# Also disables default features, as optional parameter is passed.
> +# @CODE
> +# src_configure() {
> +#local myfeatures=(
> +#$(usex X x11 '')
> +#$(usev wayland)
> +#)
> +#
> +#cargo_src_configure --no-default-features
> +# }
> +# @CODE
> +
>  # @FUNCTION: cargo_crate_uris
>  # @DESCRIPTION:
>  # Generates the URIs to put in SRC_URI to help fetch dependencies.
> @@ -113,6 +131,7 @@ cargo_live_src_unpack() {
>   mkdir -p "${S}" || die
>  
>   pushd "${S}" > /dev/null || die
> + # need to specify CARGO_HOME before cargo_gen_config fired
>   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
>   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
>   popd > /dev/null || die
> @@ -152,6 +171,26 @@ cargo_gen_config() {
>   EOF
>   # honor NOCOLOR setting
>   [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color = 
> 'never'" >> "${ECARGO_HOME}/config"
> +
> + export CARGO_HOME="${ECARGO_HOME}"
> +}
> +
> +# @FUNCTION: cargo_src_configure
> +# @DESCRIPTION:
> +# Configure cargo package features
> +cargo_src_configure() {
> + debug-print-function ${FUNCNAME} "$@"
> +
> + [[ -z ${myfeatures} ]] && declare -a myfeatures=()
> + local myfeaturestype=$(declare -p myfeatures 2>&-)
> + if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
> + die "myfeatures must be declared as array"
> + fi
> +
> + # transform array from simple feature list
> + # to multiple cargo args:
> + # --features feature1 --features feature2 ...
> + readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
missed ${@}, fixed locally, this should be,
readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )
>  }
>  
>  # @FUNCTION: cargo_src_compile
> @@ -160,11 +199,9 @@ cargo_gen_config() {
>  cargo_src_compile() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - export CARGO_HOME="${ECARGO_HOME}"
> -
>   tc-export AR CC
>  
> - cargo build $(usex debug "" --release) "$@" \
> + cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
>   || die "cargo build failed"
>  }
>  
> @@ -174,8 +211,8 @@ cargo_src_compile() {
>  cargo_src_install() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - cargo install --path ${CARGO_INSTALL_PATH} \
> - --root="${ED}/usr" $(usex debug --debug "") "$@" \
> + cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
> + $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
>   || die "cargo install failed"
>   rm -f "${ED}/usr/.crates.toml"
>   rm -f "${ED}/usr/.crates2.json"
> @@ -189,7 +226,7 @@ cargo_src_install() {
>  cargo_src_test() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - cargo test $(usex debug "" --release) "$@" \
> + cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
>   || die "cargo test failed"
>  }
>  
> 




[gentoo-dev] Re: [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> Signed-off-by: Georgy Yakovlev 
> ---
>  x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild 
> b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> index ac4d768d09b..2efc1a6dd0a 100644
> --- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
> +++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> @@ -328,19 +328,20 @@ src_unpack() {
>  }
>  
>  src_configure() {
> - myfeatures=(
> + local myfeatures=(
>   $(usex X x11 '')
>   $(usev wayland)
>   )
> + cargo_src_configure
>  }
>  
>  src_compile() {
>   cd alacritty || die
> - cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"} 
> --no-default-features
> + cargo_src_compile --no-default-features
>  }
^ --no-default-features should be passed to configure, missed it before
push, fixed locally.
>  
>  src_install() {
> - CARGO_INSTALL_PATH="alacritty" cargo_src_install 
> ${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
> + CARGO_INSTALL_PATH="alacritty" cargo_src_install
>  
>   newman extra/alacritty.man alacritty.1
>  
> @@ -368,5 +369,5 @@ src_install() {
>  
>  src_test() {
>   cd alacritty || die
> - cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"} 
> --no-default-features
> + cargo_src_test
>  }
> 




[gentoo-dev] PATCH: cargo.eclass src_configure function

2020-06-12 Thread Georgy Yakovlev


Add simple src_configure implementation, based on cmake.eclass. 
2nd patch is an example of migrated ebuild.




[gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
simple src_configure implementation inspired by cmake.eclass

Closes: https://bugs.gentoo.org/721936

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 51 ++---
 1 file changed, 44 insertions(+), 7 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..b084e082730 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -23,7 +23,7 @@ esac
 
 inherit multiprocessing toolchain-funcs
 
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
 
 IUSE="${IUSE} debug"
 
@@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 # Allows overriding the default cwd to run cargo install from
 : ${CARGO_INSTALL_PATH:=.}
 
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before 
calling
+# src_configure.
+# Example for package that has x11 and wayland as features.
+# Also disables default features, as optional parameter is passed.
+# @CODE
+# src_configure() {
+#  local myfeatures=(
+#  $(usex X x11 '')
+#  $(usev wayland)
+#  )
+#
+#  cargo_src_configure --no-default-features
+# }
+# @CODE
+
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -113,6 +131,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
 
pushd "${S}" > /dev/null || die
+   # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -152,6 +171,26 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color = 
'never'" >> "${ECARGO_HOME}/config"
+
+   export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features
+cargo_src_configure() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+   local myfeaturestype=$(declare -p myfeatures 2>&-)
+   if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+   die "myfeatures must be declared as array"
+   fi
+
+   # transform array from simple feature list
+   # to multiple cargo args:
+   # --features feature1 --features feature2 ...
+   readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
 }
 
 # @FUNCTION: cargo_src_compile
@@ -160,11 +199,9 @@ cargo_gen_config() {
 cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
 
-   cargo build $(usex debug "" --release) "$@" \
+   cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo build failed"
 }
 
@@ -174,8 +211,8 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install --path ${CARGO_INSTALL_PATH} \
-   --root="${ED}/usr" $(usex debug --debug "") "$@" \
+   cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+   $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -189,7 +226,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test $(usex debug "" --release) "$@" \
+   cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo test failed"
 }
 
-- 
2.27.0




[gentoo-dev] [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild 
b/x11-terms/alacritty/alacritty-0.4.3.ebuild
index ac4d768d09b..2efc1a6dd0a 100644
--- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
+++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
@@ -328,19 +328,20 @@ src_unpack() {
 }
 
 src_configure() {
-   myfeatures=(
+   local myfeatures=(
$(usex X x11 '')
$(usev wayland)
)
+   cargo_src_configure
 }
 
 src_compile() {
cd alacritty || die
-   cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"} 
--no-default-features
+   cargo_src_compile --no-default-features
 }
 
 src_install() {
-   CARGO_INSTALL_PATH="alacritty" cargo_src_install 
${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
+   CARGO_INSTALL_PATH="alacritty" cargo_src_install
 
newman extra/alacritty.man alacritty.1
 
@@ -368,5 +369,5 @@ src_install() {
 
 src_test() {
cd alacritty || die
-   cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"} 
--no-default-features
+   cargo_src_test
 }
-- 
2.27.0




[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support

2020-06-11 Thread Georgy Yakovlev
This will also allow me to start adding cross support to cargo.eclass
with new cross-friendly variables.


experimental cross support landed in rust-1.44.0 today [1]

[1] https://bugs.gentoo.org/679878
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  eclass/cargo.eclass | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
>  RUST_DEPEND=">=virtual/rust-1.37.0"
>  
>  case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
>   7) BDEPEND="${RUST_DEPEND}";;
>   *) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
> 




[gentoo-dev] [PATCH] eclass/cargo.eclass: drop EAPI=6 support

2020-06-11 Thread Georgy Yakovlev
no consumers left in the tree

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..ccbf87aa9a6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -16,7 +16,6 @@ _CARGO_ECLASS=1
 RUST_DEPEND=">=virtual/rust-1.37.0"
 
 case ${EAPI} in
-   6) DEPEND="${RUST_DEPEND}";;
7) BDEPEND="${RUST_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
-- 
2.27.0




Re: [gentoo-dev] cmake-utils.eclass: DEPRECATED notice

2020-06-08 Thread Georgy Yakovlev
opened a PR to add it to repoman:

https://github.com/gentoo/portage/pull/554

On 6/8/20 2:09 AM, Sergei Trofimovich wrote:
> On Mon, 08 Jun 2020 10:13:24 +0200
> Andreas Sturmlechner  wrote:
> 
>> This eclass no longer receives any changes.
>> Everyone must port to cmake.eclass.
> 
> We have quite a few ebuilds that still use it:
> $ git grep -E 'inherit.*cmake-utils' | wc -l
> 1338
> 
> I don't see any warnings reported by repoman to suggest users
> to migrate away. Should we have one?
> 




Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps

2020-04-19 Thread Georgy Yakovlev
On Sun, 19 Apr 2020 11:30:25 +0200
"Haelwenn (lanodan) Monnier"  wrote:

> [2020-04-18 21:10:45-0700] Georgy Yakovlev:
> > # Georgy Yakovlev  (2020-04-18)
> > # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
> > # requires agreement to restrictive license
> > # Revdeps that still depend on oracle variants require javafx
> > # Please use icedtea or openjdk instead.
> > # Removal in 30 days.
> > # https://bugs.gentoo.org/681828
> > dev-java/oracle-jdk-bin
> > dev-java/oracle-jre-bin
> > app-forensics/sleuthkit
> > app-text/jabref-bin
> > dev-java/netbeans-platform
> > dev-java/netbeans-harness
> > games-util/pogo-manager-bin
> > net-p2p/bisq
> > sci-mathematics/geogebra
> 
> The mask on app-forensics/sleuthkit seems to be faulty/overkill: 
> optionally depends on java, only uses oracle-jdk on 4.7.0.
> 
Thanks! my grep misfired.
I removed it from package.mask, and masked java useflag for 4.7.0 instead.


-- 
Georgy Yakovlev 


pgpAH_4mWfNs3.pgp
Description: PGP signature


[gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps

2020-04-18 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-04-18)
# Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
# requires agreement to restrictive license
# Revdeps that still depend on oracle variants require javafx
# Please use icedtea or openjdk instead.
# Removal in 30 days.
# https://bugs.gentoo.org/681828
dev-java/oracle-jdk-bin
dev-java/oracle-jre-bin
app-forensics/sleuthkit
app-text/jabref-bin
dev-java/netbeans-platform
dev-java/netbeans-harness
games-util/pogo-manager-bin
net-p2p/bisq
sci-mathematics/geogebra



Oracle java has been maintainer-needed since august 2019,
no one stepped up.
Removal in 30 days.

If someone wants to save the javafx revdeps, best way will be
packaging zulufx community [1], I can provide some guidance
on packaging it, should not be too hard.

-- 
Georgy Yakovlev 

[1] 
https://www.azul.com/downloads/zulu-community/?version=java-8-lts=linux=jdk-fx


pgpQeTto78oDk.pgp
Description: PGP signature


[gentoo-dev] package up for grabs: net-news/newsboat

2020-04-05 Thread Georgy Yakovlev
No longer use it.
Needs a minor bump, upstream changed doc dependency to asciidoctor.
Uses custom build system and rust,
may be tricky to maintain, but I can help.

Couple of open bugs: arm keywording and musl related build falure.

net-news/newsboat


-- 
Georgy Yakovlev 


pgpTpfceqLlmO.pgp
Description: PGP signature


[gentoo-dev] Re: [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item

2020-04-04 Thread Georgy Yakovlev
Clarification: this is just news item for review.

Profiles need to be marked stable, before posting news item,
but I see no reason not to.
Old profiles will be deprecated and removed on June 1st 2020.

Tracking bug: https://bugs.gentoo.org/715680

On Sat,  4 Apr 2020 19:37:32 -0700
Georgy Yakovlev  wrote:

> Signed-off-by: Georgy Yakovlev 
> ---
>  .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++
>  1 file changed, 25 insertions(+)
>  create mode 100644 
> 2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
> 
> diff --git 
> a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt 
> b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
> new file mode 100644
> index 000..c496154
> --- /dev/null
> +++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
> @@ -0,0 +1,25 @@
> +Title: new ppc64le (little-endian) profiles
> +Author: Georgy Yakovlev 
> +Posted: 2020-04-04
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Profile: 
> default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
> +Display-If-Profile: 
> default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
> +
> +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository.
> +New profiles are compatible with existing ppc64 little-endian profiles,
> +and no additional action required after switching the profile.
> +
> +Please migrate away from the old profiles:
> +
> +* Old profiles:
> +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
> +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
> +
> +* Replaced by:
> +default/linux/ppc64le/17.0 
> +default/linux/ppc64le/17.0/systemd
> +
> +Desktop profiles are now also available.
> +
> +Refer to `eselect profile list` output.
> -- 
> 2.26.0
> 


-- 
Georgy Yakovlev 


pgp4vCSLEyCeW.pgp
Description: PGP signature


[gentoo-dev] [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item

2020-04-04 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++
 1 file changed, 25 insertions(+)
 create mode 100644 
2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt

diff --git 
a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt 
b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
new file mode 100644
index 000..c496154
--- /dev/null
+++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
@@ -0,0 +1,25 @@
+Title: new ppc64le (little-endian) profiles
+Author: Georgy Yakovlev 
+Posted: 2020-04-04
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Profile: 
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
+Display-If-Profile: 
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
+
+A new set of 17.0 ppc64le profiles has been added to the Gentoo repository.
+New profiles are compatible with existing ppc64 little-endian profiles,
+and no additional action required after switching the profile.
+
+Please migrate away from the old profiles:
+
+* Old profiles:
+default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
+default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
+
+* Replaced by:
+default/linux/ppc64le/17.0 
+default/linux/ppc64le/17.0/systemd
+
+Desktop profiles are now also available.
+
+Refer to `eselect profile list` output.
-- 
2.26.0




Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-23 Thread Georgy Yakovlev
On Mon, 23 Mar 2020 21:09:15 +0200
Jaco Kroon  wrote:

> Hi Michał,
> 
> On 2020/03/23 18:25, Michał Górny wrote:
> 
> > On Mon, 2020-03-23 at 10:21 +0200, Jaco Kroon wrote:
> >> Hi,
> >>
> >> https://bugs.gentoo.org/713668 relates.
> >>
> >>  * Searching for /usr/include/execinfo.h ...
> >> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
> >>
> >> As I see I can either add an explicit depend on glibc which I'd prefer
> >> not to.  Or someone from the musl team could possibly assist on how to
> >> get the backtrace() set of calls on musl please?
> >>
> > As someone not on musl team, I think libunwind provides
> > an implementation of backtrace().
> >
> Thanks.  That indeed looks interesting.
> 
> Let's say I do go that route rather than simply no-opping it, would I
> add a BDEPEND + RDEPEND of the form:
> 
> || ( sys-libs/glibc sys-libs/libunwind )
> 
> To the ebuild?
> 
> The code (./configure and actual "C" I'll manage).
> 
> Kind Regards,
> Jaco
> 
> 

if libunwind can be used, you should use this dep

elibc_musl? ( sys-libs/libunwind:= )

but idk if it's usable as is on musl.
best way to check is to get musl stage3 tarball and test it.
alpine does have a musl patch, but it seems they just patch it out completely.
https://git.alpinelinux.org/aports/tree/main/dahdi-tools/fix-musl.patch



-- 
Georgy Yakovlev 


pgpb0FaDXw7ig.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] metadata/policy.conf: Introduce QA check configuration

2020-02-26 Thread Georgy Yakovlev
On Wed, 26 Feb 2020 11:23:49 +0100
Michał Górny  wrote:

> Introduce a new configuration file for assigning QA check significance
> levels to PG policies.  Long-term goal is that this will permit
> unified configuration of various QA tools, including pkgcheck, repoman
> and install-qa-check.d.
> 
> Signed-off-by: Michał Górny 
> ---
>  metadata/policy.conf | 61 
>  1 file changed, 61 insertions(+)
>  create mode 100644 metadata/policy.conf
> 
> diff --git a/metadata/policy.conf b/metadata/policy.conf
> new file mode 100644
> index ..824598063cc1
> --- /dev/null
> +++ b/metadata/policy.conf
> @@ -0,0 +1,61 @@
> +# Copyright 2020 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# The policy section assigns significance levels to various policies.
> +# Keys are identifiers from the Policy Guide, values are either
> +# 'notice', 'warninging' or 'error'.
extra ing here
> +#
> +# The rule of thumb is that 'error' indicates a serious problem that
> +# may cause serious problem to the end users and therefore should block
> +# committing / deployment.  'Warning' should be fixed by developer
capital W probably should be w
> +# but does not need to immediately prevent committing.
> +#
> +# https://projects.gentoo.org/qa/policy-guide/std-policy-index.html
> +

Looks really interesting.
Will overlays be able to define their own policy ?
Maybe rename file to metadata/qa-policy.conf ? just policy.conf is ambiguous.

-- 
Georgy Yakovlev 



Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check

2020-02-13 Thread Georgy Yakovlev
On Thu, 13 Feb 2020 08:11:09 -0800
Christopher Head  wrote:

> On Wed, 12 Feb 2020 23:39:11 -0800
> Georgy Yakovlev  wrote:
> 
> > +   eqawarn "For more details, please see the
> > freedesktop Upstrem Metadate guidelines"  
> 
> Couple of typos here: s/Upstrem/Upstream/, s/Metadate/Metadata/.

Thanks!
Fixed and pushed now.

Tracker bug is https://bugs.gentoo.org/709450


pgpaI8vnwCbLs.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check

2020-02-12 Thread Georgy Yakovlev
this will warn if package installs xml files to /usr/share/appdata
this location is deprecated, files should be installed to
/usr/share/metainfo

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html

Signed-off-by: Georgy Yakovlev 
---
 metadata/install-qa-check.d/60appdata-path | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 metadata/install-qa-check.d/60appdata-path

diff --git a/metadata/install-qa-check.d/60appdata-path 
b/metadata/install-qa-check.d/60appdata-path
new file mode 100644
index 000..c4878949b0e
--- /dev/null
+++ b/metadata/install-qa-check.d/60appdata-path
@@ -0,0 +1,33 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that metadata files are installed in /usr/share/metainfo
+# Maintainer: Georgy Yakovlev 
+
+appdata_path_check() {
+   [[ -d ${ED%/}/usr/share/appdata ]] || return
+
+   local found=() f
+   while read -d '' -r f; do
+   found+=( "${f%/*}" )
+   done < <(find "${ED%/}/usr/share/appdata" -name '*.xml' -print0 || die)
+
+   if [[ ${found[@]} ]]; then
+   eqawarn
+   eqawarn "This package seems to install metainfo files into the 
following"
+   eqawarn "location(s):"
+   eqawarn
+   eqatag -v appdata.invalid-path "${found[@]#${D%/}}"
+   eqawarn
+   eqawarn "This location is deprecated, it should not be used 
anymore by new software"
+   eqawarn "Appdata/Metainfo files should be installed into 
/usr/share/metainfo directory"
+   eqawarn "For more details, please see the freedesktop Upstrem 
Metadate guidelines"
+   eqawarn 
"https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html;
+   eqawarn
+   fi
+}
+
+appdata_path_check
+: # guarantee successful exit
+
+# vim:ft=sh
-- 
2.25.0




Re: [gentoo-dev] Last rites: virtual/cargo

2020-01-27 Thread Georgy Yakovlev
On Mon, 27 Jan 2020 10:48:51 +0100
David Seifert  wrote:

> On Sun, 2020-01-26 at 21:53 -0500, Michael Orlitzky wrote:
> > On 1/26/20 9:46 PM, Georgy Yakovlev wrote:
> > > # update your rust packages running emerge with the
> > > # --changed-deps option if you have problems
> > 
> > If this advice helps, you have violated the PMS.
> > 
> 
> Agreed, if possible revbump any critical ebuilds, so we can avoid the
> virtual/pam disaster this time round.
> 
> 

All critical explicit consumers switched a while ago (mozilla & co).

Consumers via eclass switched about 1 month ago.

I considered revbumps, there were 44 ebuilds and 23 unique
packages,about half of that with stable keywords.
not that much, it's not pam after all. I did bump some meanwhile.
There will be no disaster.


pgpoJ8exDAmlk.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: virtual/cargo

2020-01-26 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-01-26)
# Not needed anymore, feel free to remove from your system
# emerge -C virtual/cargo
# update your rust packages running emerge with the
# --changed-deps option if you have problems
# https://bugs.gentoo.org/695698
virtual/cargo


pgpq8isLKhJsg.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: www-plugins/passff

2020-01-26 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-01-26)
# Starting with Firefox 74 Mozilla removes xpi sideloading support
# install from addons.mozilla.org
# passff-host remains in the tree
www-plugins/passff


pgpMRWkCmo2fK.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-06 Thread Georgy Yakovlev
On Friday, December 6, 2019 3:44:38 PM PST Sergei Trofimovich wrote:
> On Fri,  6 Dec 2019 12:09:31 -0800
> 
> Georgy Yakovlev  wrote:
> > Default output just prints crate name.
> > With -vv we can see all cargo options and rustc args.
> > 
> > Signed-off-by: Georgy Yakovlev 
> > ---
> 
> Looks good!
> 
> I had to do an equivalent locally at least a few times.
Pushed!
> 
> While at it I also suggest adding equivalent of
> econf's/emake's ${EXTRA_ECONF} and ${EXTRA_EMAKE}
> to allow users to inject arbitrary stuff. For example
> to sneak in '-Z' options globally.
> 
> Say, ${CARGO_BUILD_EXTRA},  ${CARGO_INSTALL_EXTRA},
> ${CARGO_TEST_EXTRA}.
> 

Yeah, it's on my to-do list for this eclass.
1 question tho, should it come after "$@" or before? Do you use it?
I know cargo can be picky about order and some ebuilds rely on passing params 
in phase funcs.




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


[gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-06 Thread Georgy Yakovlev
Default output just prints crate name.
With -vv we can see all cargo options and rustc args.

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 5b6d1f050f1..13dd5c355fb 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -146,7 +146,7 @@ cargo_src_compile() {
 
export CARGO_HOME="${ECARGO_HOME}"
 
-   cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo build -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo build failed"
 }
 
@@ -156,7 +156,7 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug 
--debug "") "$@" \
+   cargo install -vv -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug 
--debug "") "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
 
@@ -169,7 +169,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo test -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo test failed"
 }
 
-- 
2.23.0




Re: [gentoo-dev] Last rites: app-misc/rq, net-news/newsboat

2019-12-02 Thread Georgy Yakovlev
On Monday, December 2, 2019 11:53:58 AM PST Zoltan Puskas wrote:
> On Mon, Dec 02, 2019 at 11:10:52AM -0800, Georgy Yakovlev wrote:
... 
> 
> Let me know if you need some help maintaining newsboat, I'm willing to proxy
> maintain it, with you being the primary owner of the ebuild.
> 
Feel free to submit a PR on github next time there's a version bump, with a 
version bump and metadata.xml update, I appreciate the help.

> > also I use rq from time to time, I'll see if I can take it over and remove
> > mask if I decide to take it.
> 
> Zoltan








Re: [gentoo-dev] Last rites: app-misc/rq, net-news/newsboat

2019-12-02 Thread Georgy Yakovlev
On Sunday, December 1, 2019 1:27:34 PM PST Michał Górny wrote:
> # Michał Górny  (2019-12-01)
> # Unmaintained Rust packages with incorrect license information.
> # Removal in 30 days.  Bug #694414.
> app-misc/rq
> net-news/newsboat

I recently took over newsboat, just did not have enough time to push updated 
ebuild, will commit and unmask later today.

also I use rq from time to time, I'll see if I can take it over and remove 
mask if I decide to take it.

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


Re: [gentoo-dev] packages up for grabs

2019-11-18 Thread Georgy Yakovlev
On 11/18/19 4:47 PM, Tim Harder wrote:

Taken:
app-arch/pigz
net-news/newsboat
app-misc/binwalk
net-misc/proxychains
dev-vcs/tig (with chutzpah)

I already maintain this:
sys-apps/ripgrep
net-irc/weechat
app-misc/skim



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 3/3] cargo.eclass: use verbose cargo invocation

2019-10-25 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index dc031623067..940096ea230 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -115,8 +115,8 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
 
pushd "${S}" > /dev/null || die
-   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
-   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+   CARGO_HOME="${ECARGO_HOME}" cargo -vv fetch || die
+   CARGO_HOME="${ECARGO_HOME}" cargo -vv vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
 
cargo_gen_config
@@ -146,7 +146,7 @@ cargo_src_compile() {
 
export CARGO_HOME="${ECARGO_HOME}"
 
-   cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo -vv build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo build failed"
 }
 
@@ -156,7 +156,7 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug 
--debug "") "$@" \
+   cargo -vv install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug 
--debug "") "$@" \
|| die "cargo install failed"
rm -f "${D}/usr/.crates.toml"
 
@@ -169,7 +169,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo -vv test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo test failed"
 }
 
-- 
2.23.0




[gentoo-dev] RFC: cargo.eclass changes and virtual/cargo retirement

2019-10-25 Thread Georgy Yakovlev
Bug: https://bugs.gentoo.org/695698




[gentoo-dev] [PATCH 1/3] cargo.eclass: do not use virtual/cargo anymore

2019-10-25 Thread Georgy Yakovlev
Bug: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 44d11cdb838..dc031623067 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -14,14 +14,14 @@ _CARGO_ECLASS=1
 
 if [[ ${PV} == ** ]]; then
# we need at least this for cargo vendor subommand
-   CARGO_DEPEND=">=virtual/cargo-1.37.0"
+   RUST_DEPEND=">=virtual/rust-1.37.0"
 else
-   CARGO_DEPEND="virtual/cargo"
+   RUST_DEPEND="virtual/rust"
 fi
 
 case ${EAPI} in
-   6) DEPEND="${CARGO_DEPEND}";;
-   7) BDEPEND="${CARGO_DEPEND}";;
+   6) DEPEND="${RUST_DEPEND}";;
+   7) BDEPEND="${RUST_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-- 
2.23.0




[gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

2019-10-25 Thread Georgy Yakovlev
not used anymore

Closes: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev 
---
 virtual/cargo/cargo-1.34.2.ebuild | 17 -
 virtual/cargo/cargo-1.35.0.ebuild | 17 -
 virtual/cargo/cargo-1.36.0.ebuild | 17 -
 virtual/cargo/cargo-1.37.0.ebuild | 17 -
 virtual/cargo/cargo-1.38.0.ebuild | 17 -
 virtual/cargo/metadata.xml|  8 
 6 files changed, 93 deletions(-)
 delete mode 100644 virtual/cargo/cargo-1.34.2.ebuild
 delete mode 100644 virtual/cargo/cargo-1.35.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.36.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.37.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.38.0.ebuild
 delete mode 100644 virtual/cargo/metadata.xml

diff --git a/virtual/cargo/cargo-1.34.2.ebuild 
b/virtual/cargo/cargo-1.34.2.ebuild
deleted file mode 100644
index 032ae4f274f..000
--- a/virtual/cargo/cargo-1.34.2.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="amd64 ~arm64 ~ppc64 x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.35.0.ebuild 
b/virtual/cargo/cargo-1.35.0.ebuild
deleted file mode 100644
index 2c015c4a0d9..000
--- a/virtual/cargo/cargo-1.35.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.36.0.ebuild 
b/virtual/cargo/cargo-1.36.0.ebuild
deleted file mode 100644
index 5e737019292..000
--- a/virtual/cargo/cargo-1.36.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 ~arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.37.0.ebuild 
b/virtual/cargo/cargo-1.37.0.ebuild
deleted file mode 100644
index 631c2ccb793..000
--- a/virtual/cargo/cargo-1.37.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="amd64 arm64 ppc64 x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.38.0.ebuild 
b/virtual/cargo/cargo-1.38.0.ebuild
deleted file mode 100644
index 5e737019292..000
--- a/virtual/cargo/cargo-1.38.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 ~arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/metadata.xml b/virtual/cargo/metadata.xml
deleted file mode 100644
index 85cf4eb9205..000
--- a/virtual/cargo/metadata.xml
+++ /dev/null
@@ -1,8 +0,0 @@
-
-http://www.gentoo.org/dtd/metadata.dtd;>
-
-  
-r...@gentoo.org
-Rust Project
-  
-
-- 
2.23.0




[gentoo-dev] [PATCH] 2019-09-11-cpu_flags_ppc-introduction: new item

2019-09-11 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 ...19-09-11-cpu_flags_ppc-introduction.en.txt | 38 +++
 1 file changed, 38 insertions(+)
 create mode 100644 
2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt

diff --git 
a/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt
 
b/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt
new file mode 100644
index 000..a4a4ee5
--- /dev/null
+++ 
b/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt
@@ -0,0 +1,38 @@
+Title: new CPU_FLAGS_PPC USE_EXPAND
+Author: Georgy Yakovlev 
+Posted: 2019-09-11
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Keyword: ~ppc
+Display-If-Keyword: ~ppc64
+Display-If-Keyword: ppc
+Display-If-Keyword: ppc64
+
+
+A new set of CPU_FLAGS_PPC USE_EXPAND flags has been added.
+The flags are:
+
+  altivec - Use the AltiVec/VMX instruction set
+  vsx - Use the Vector Scalar Extension instruction set
+  vsx3 - Use the Vector Scalar Extension v.3 instruction set
+
+Note that CPU_FLAGS_PPC variable is used on ppc and ppc64 architectures.
+
+In order to transition to new set of flags, if the following flag was
+was present:
+ 
+  USE="altivec"
+
+This flag needs to be set as:
+
+  CPU_FLAGS_PPC="altivec"
+
+It's advised to keep 'altivec' USE flag enabled to ensure safe
+migration and compatibility with external repositories.
+'vsx' and 'vsx3' are new flags and no migration necessary.
+
+To help users enable the correct USE_EXPAND flags PPC support has been
+added to app-portage/cpuid2cpuflags package:
+
+  # emerge -1v >=app-portage/cpuid2cpuflags-7
+  $ cpuid2cpuflags
-- 
2.23.0




Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags

2019-09-11 Thread Georgy Yakovlev
On 9/10/19 12:44 PM, Michał Górny wrote:
> Hi, everyone.
> 
> I've recently (finally!) started adding tests to cpuid2cpuflags.  Tests
> are based on mocked syscalls that return arch-specific data read from
> text files.  So far I've got x86 and ppc covered, and now I'd like to
> add tests for various arm hardware.  Since ARM covers a pretty broad
> range of hardware, I'd use as much data as possible, especially from
> different ARM generations.
> 
> If you have an ARM board and would like to help, please:
> 
> wget https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2
> tar -xf cpuid2cpuflags-7-dev.tar.bz2
> cd cpuid2cpuflags-7-dev
> ./configure
> make hwcap-dump
> ./hwcap-dump
> 
> and send me the output along with 'uname -m'.  TIA!
> 


couple of boards here


== rockpro64
Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53)

$ uname -m
aarch64

$ ./hwcap-dump
hwcap:08ff
hwcap2:

./cpuid2cpuflags
CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 aes sha1 sha2
crc32 v4 v5 v6 v7 v8 thumb2


cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4


diff -U0 <(./cpuid2cpuflags | tr ' ' '\n' | sed 1d |sort) <(grep -m1
Features /proc/cpuinfo | tr ' ' '\n' | sed 1d | grep '.' |sort)
--- /dev/fd/63  2019-09-11 09:57:36.360796732 -0700
+++ /dev/fd/62  2019-09-11 09:57:36.364130054 -0700
@@ -1,0 +2,2 @@
+asimd
+cpuid
@@ -3,2 +5,3 @@
-edsp
-neon
+evtstrm
+fp
+pmull
@@ -7,11 +9,0 @@
-thumb
-thumb2
-v4
-v5
-v6
-v7
-v8
-vfp
-vfp-d32
-vfpv3
-vfpv4





== Odroid N2
Amlogic S922X (4x Cortex-A73 @ 1.8GHz, 2x Cortex-A53 @ 1.9GHz)

$ uname -m
aarch64

$ ./hwcap-dump
hwcap:00ff
hwcap2:

CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 aes sha1 sha2
crc32 v4 v5 v6 v7 v8 thumb2

cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

CPU info: 290a41200e01313254524d50
Serial  : .
Hardware: Hardkernel ODROID-N2
Revision: 0400


diff -U0 <(./cpuid2cpuflags | tr ' ' '\n' | sed 1d |sort) <(grep -m1
Features /proc/cpuinfo | tr ' ' '\n' | sed 1d | grep '.' |sort)
--- /dev/fd/63  2019-09-11 09:59:59.616633443 -0700
+++ /dev/fd/62  2019-09-11 09:59:59.616633443 -0700
@@ -1,0 +2 @@
+asimd
@@ -3,2 +4,3 @@
-edsp
-neon
+evtstrm
+fp
+pmull
@@ -7,11 +8,0 @@
-thumb
-thumb2
-v4
-v5
-v6
-v7
-v8
-vfp
-vfp-d32
-vfpv3
-vfpv4




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: go 1.13 and go modules

2019-09-09 Thread Georgy Yakovlev
On Monday, September 9, 2019 2:46:16 PM PDT William Hubbs wrote:
> On Tue, Sep 10, 2019 at 08:35:17AM +1200, Kent Fredric wrote:
> > On Mon, 9 Sep 2019 12:34:18 -0500
> > 
> > William Hubbs  wrote:
> > > There is another option I want to try which is adding "go mod vendor" to
> > > src_unpack for go packages.
> > 
> > Is it infeasible to write a tool that you execute as a maintainer, that
> > simulates what "go mod vendor" would do, but instead emits a list of
> > entries for SRC_URI, and then have an eclass or something construct the
> > vendor dir from those?
> > 
> > That's what is available for rust stuff.
> 
> I'm not sure how feasible something like that is.
> 
> $ go list -m all
> 
> will list the dependencies of a module, but that doesn't look like it
> can be translated into src_uri format.
> 
> You would basically have to parse go.mod exactly the way upstream does
> it and come up with a way to download the correct versions of the
> source.
> 
> William

check mail-client/aerc ebuild.
I use "go list -m all" and manually format EGO_VENDOR string which will be 
translated into SRC_URI by eclass.
tool is certainly possible and should be quite easy to implement.
some manual editing will still be needed if dealing with forked packages/
repos, but looks pretty straightforward.
This is very similar approach to cargo ebuilds and it supports offline 
installs, PM checksumming and does not require packaging every single go 
dependency as a package.



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


Re: [gentoo-dev] [PATCH] tmpfiles.eclass: fix @USAGE to not include function name

2019-09-06 Thread Georgy Yakovlev
On Friday, September 6, 2019 11:52:53 AM PDT Michael Everitt wrote:
> On 06/09/19 18:27, Ben Kohler wrote:
> 
> This series seems super counter-intuitive to me .. surely all usage
> examples (in Linux/etc in general) utilise the command itself to provide
> context of how to invoke the function/etc ?? or am I [once again] mistaken?
> 
> Perhaps the series should be to *add* the function across the tree, rather
> than remove it?

Command itself is already added by magic awk, Ben just removing duplicates.

for example, desktop eclass man page right now

make_desktop_entry make_desktop_entry(, [name], [icon], [type]...

after the change

make_desktop_entry (, [name], [icon], [type], [fields])



check app-doc/eclass-manpages awk magic file how the pages are generated.

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


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
On 8/30/19 11:29 PM, Michał Górny wrote:
> On Sat, 2019-08-31 at 00:19 -0700, Georgy Yakovlev wrote:
>> On 8/30/19 11:11 PM, Michał Górny wrote:
>>> On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:
>> 
>>>> +altivec - Use the AltiVec instruction set
>>>> +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
>>>> +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and 
>>>> later)
>>>
>>> Do all those flags have real use cases in ::gentoo?  I'd really prefer
>>> not having more 'unused flag' warnings ;-).
>>>
>>
>> yeah, I have mentioned possible users above and there are plenty I
>> haven't identified yet. patches to ebuilds will follow, I promise =)
>>
>> for example x264 if built with proper flags gives a noticeable boost,
>> (at least 2x at encoding), totally worth it.
>>
>> ppc will not have a lot of flags like on arm or x86, maybe a couple
>> more, but that's it for now.
>>
> 
> Just to be clear: we're not talking about -m compiler flags, are we? 
> 'cause those should be handled via CFLAGS.
> 

of course not just compiler flags, that's clear.

for example libpng has --enable-powerpc-vsx ./configure flag, and build
system will do it's black magic with intrinsics if it's passed.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
On 8/30/19 11:11 PM, Michał Górny wrote:
> On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:

>> +altivec - Use the AltiVec instruction set
>> +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
>> +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and 
>> later)
> 
> Do all those flags have real use cases in ::gentoo?  I'd really prefer
> not having more 'unused flag' warnings ;-).
> 

yeah, I have mentioned possible users above and there are plenty I
haven't identified yet. patches to ebuilds will follow, I promise =)

for example x264 if built with proper flags gives a noticeable boost,
(at least 2x at encoding), totally worth it.

ppc will not have a lot of flags like on arm or x86, maybe a couple
more, but that's it for now.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] PATCH: add CPU_FLAGS_PPC USE_EXPAND

2019-08-31 Thread Georgy Yakovlev
Possible users from the tree: 
  altivec useflag consumers (many)
  media libraries (x264, x265, libpng and others.)

also firefox-70[1] will have auto-detection of features but we may want to
prevent automagic optimizations.


cpuid2cpuflags support[2] is ready and and will be merged soon,
so users will have a gentoo-way of setting those flags.


And this patch in github PR[3] format for easy viewing

[1] https://hg.mozilla.org/mozilla-central/rev/252643ff91c5
[2] https://github.com/mgorny/cpuid2cpuflags/pull/13
[3] https://github.com/gentoo/gentoo/pull/12829





[gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 profiles/desc/cpu_flags_ppc.desc | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 profiles/desc/cpu_flags_ppc.desc

diff --git a/profiles/desc/cpu_flags_ppc.desc b/profiles/desc/cpu_flags_ppc.desc
new file mode 100644
index 000..abd2434c4f5
--- /dev/null
+++ b/profiles/desc/cpu_flags_ppc.desc
@@ -0,0 +1,6 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+altivec - Use the AltiVec instruction set
+vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
+vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and later)
-- 
2.23.0




[gentoo-dev] [PATCH 2/2] profiles: Add CPU_FLAGS_PPC to USE_EXPAND

2019-08-31 Thread Georgy Yakovlev
hide everywhere, and unhide in top level powerpc profile

Signed-off-by: Georgy Yakovlev 
---
 profiles/arch/powerpc/make.defaults | 9 +
 profiles/base/make.defaults | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 profiles/arch/powerpc/make.defaults

diff --git a/profiles/arch/powerpc/make.defaults 
b/profiles/arch/powerpc/make.defaults
new file mode 100644
index 000..8613dd7619e
--- /dev/null
+++ b/profiles/arch/powerpc/make.defaults
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# All extra USE/etc should be specified in sub-profiles.
+# DO NOT POLLUTE USE ON THIS PROFILE.
+
+# Georgy Yakovlev 

[gentoo-dev] [PATCH] cargo.eclass: add cargo_live_src_unpack()

2019-08-28 Thread Georgy Yakovlev
This function will allow using 'cargo fetch' during src_fetch
Since only new cargo supports that, all live packages will
have to depend on >=rust-1.37.0

This enables us to ship live rust packages,
cargo fetch will download all crates and vendor them for offline
phases.

here's an example of src_unpack()

src_unpack() {
if [[ "${PV}" == ** ]]; then
git-r3_src_unpack
cargo_live_src_unpack
else
cargo_src_unpack
fi
}

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index b16e0e9d633..44d11cdb838 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -12,7 +12,12 @@
 if [[ -z ${_CARGO_ECLASS} ]]; then
 _CARGO_ECLASS=1
 
-CARGO_DEPEND="virtual/cargo"
+if [[ ${PV} == ** ]]; then
+   # we need at least this for cargo vendor subommand
+   CARGO_DEPEND=">=virtual/cargo-1.37.0"
+else
+   CARGO_DEPEND="virtual/cargo"
+fi
 
 case ${EAPI} in
6) DEPEND="${CARGO_DEPEND}";;
@@ -97,6 +102,26 @@ cargo_src_unpack() {
cargo_gen_config
 }
 
+# @FUNCTION: cargo_live_src_unpack
+# @DESCRIPTION:
+# Runs 'cargo fetch' and vendors downloaded crates for offline use, used in 
live ebuilds
+
+cargo_live_src_unpack() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   [[ "${PV}" == ** ]] || die "${FUNCNAME} only allowed in live/ 
ebuilds"
+   [[ "${EBUILD_PHASE}" == unpack ]] || die "${FUNCNAME} only allowed in 
src_unpack"
+
+   mkdir -p "${S}" || die
+
+   pushd "${S}" > /dev/null || die
+   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
+   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+   popd > /dev/null || die
+
+   cargo_gen_config
+}
+
 # @FUNCTION: cargo_gen_config
 # @DESCRIPTION:
 # Generate the $CARGO_HOME/config necessary to use our local registry
-- 
2.23.0




[gentoo-dev] Packages up for grabs: dev-java/oracle-jdk-bin, dev-java/oracle-jre-bin

2019-08-18 Thread Georgy Yakovlev
All future versions masked, unmaintained, multiple security bugs, the
most important bug is a possible serious license violation[1] that puts
users into legal trouble.

nobody in java team maintains it, so if you want to keep it - please
take care of it.

Current tarballs no longer accessible, downloading new ones requires
oracle account and agreement to new license, which is in effect since
April 2019
New license seems to be ok for home or development use, but IANAL.



general discussion bug still open:
https://bugs.gentoo.org/681828


PS. Personally I'd drop it, but it was discussed before[2] and some
people expressed strong opinion of keeping it outside of java team.

[1]https://bugs.gentoo.org/692420
[2]https://archives.gentoo.org/gentoo-dev/message/ed6b0e3c3ac174aba972d2a436ab252f



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: sys-kernel/bliss-initramfs

2019-08-17 Thread Georgy Yakovlev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

# Georgy Yakovlev  (2019-08-17)
# Unmaintained both upstream and in gentoo, author retired
# Removal in 30 days
sys-kernel/bliss-initramfs


@fearedbliss retired a while ago.
upstream page[1] litreally says:
"This project is no longer in development. Please fork. Thank you."

[1] https://github.com/fearedbliss/bliss-initramfs
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3NQc5d2Nq7vhc9JNonLI8BUSnVIFAl1YqmMACgkQonLI8BUS
nVLA0RAAwYSUQAJ+H6ITlUSEJjatpjPfiAZg+zq1q9E24Lt4pwNGTGFlfzyYnUjg
oSkUxjXbi8jsrIvc0FDdQy+HcGP7HyVA24iSeQ5D3aJahpDNmrxGQI7098lLmhWv
xXGVyEbJWz2T00/l2pLZnJgpXKpxgtMUeKLxR+hSOc1Iq5O7W1o1KKM2LP9VeHdH
oSMyCt5BNOaz3eMwdEDdMMGTE6ucz5nrl5OUvI83fNpuVAokgLytX4wEGN/a4Fb6
gFjoafljFJPDt5+6HN0XcwcnEq8IBkAHupS/9cp/oan+2U77Vf346ysoqghYuMhr
3TSlVooktfmEMeq/462q4W0TI6lQFzTppqWQMFNPA190LmkbW/TJ5rG8PjO9uraY
lAkWyU201LqXO+jBe+eHPZ0iRr1Y9vRuQRLGQEmJleM2/OnO9zyB/7TaKXtxzhsc
acrn12kNMl/bz88WEaAei42Isie0ScWMNSpmgr+IrAhZU8urZXKwSPv+ov0wTBr7
i+bIVuRgEWYwdXYZQ7awBRhWfh+oel8/7o4/kmPFXkVlT2GtPOAq1KQHQzGKT/4e
2l6zbxmP79RsGNVqfaZr/EDqWR/2F+PqvpxRn1j91oS1X29aBM2swIM+WeULr/ZU
8DK1r+F59pE/JSJ8bDXQKHnkw/NYih7IaS7bBdxxOGiSqr7j2jw=
=gPMW
-END PGP SIGNATURE-



Re: [gentoo-dev] mark ppc64le profiles stable

2019-08-15 Thread Georgy Yakovlev
On Thursday, August 15, 2019 1:32:28 AM PDT Georgy Yakovlev wrote:
> Let's mark ppc64le profiles stable.
> It passes CI https://github.com/gentoo/gentoo/pull/12711
> 
> Regards, Georgy.

pushed.

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


[gentoo-dev] [PATCH 3/3] profiles/profiles.desc: mark ppc64le profiles stable

2019-08-15 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 profiles/profiles.desc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index afafbf39dea..d9384010e59 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -159,8 +159,8 @@ ppc64   
default/linux/powerpc/ppc64/17.0/64bit-userland/desktop
 ppc64   default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome  
 stable
 ppc64   
default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome/systemd   stable
 ppc64   default/linux/powerpc/ppc64/17.0/64bit-userland/developer  
 stable
-ppc64  default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian   
exp
-ppc64  
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd   exp
+ppc64  default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian   
stable
+ppc64  
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd   stable
 
 # RISC-V Profiles
 # @MAINTAINER: ri...@gentoo.org
-- 
2.22.1




  1   2   >