Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
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
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
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
# 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
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
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
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
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
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
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
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
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
# 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
# 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)
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
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
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
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
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
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
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?
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
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)
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
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
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
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
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
# 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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
# 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
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
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
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
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
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
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
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
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
# 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
# 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
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
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
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
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
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
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
Bug: https://bugs.gentoo.org/695698
[gentoo-dev] [PATCH 1/3] cargo.eclass: do not use virtual/cargo anymore
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
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
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
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
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
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
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
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
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
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
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()
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
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
-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
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
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
