[gentoo-dev] Package up for grabs: sys-boot/gnu-efi (nt)
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: tc-env_build: override (E)SYSROOT
On Fri, Apr 19, 2024 at 1:56 PM James Le Cuirot wrote:
>
> On Fri, 2024-04-19 at 12:14 -0400, Mike Gilbert wrote:
> > When using the CBUILD toolchain, it makes no sense to look for headers
> > and libraries in the CHOST-based SYSROOT.
> >
> > Signed-off-by: Mike Gilbert
> > ---
> > eclass/toolchain-funcs.eclass | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> > index cde84e6f34c8..58a718180079 100644
> > --- a/eclass/toolchain-funcs.eclass
> > +++ b/eclass/toolchain-funcs.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 2002-2023 Gentoo Authors
> > +# Copyright 2002-2024 Gentoo Authors
> > # Distributed under the terms of the GNU General Public License v2
> >
> > # @ECLASS: toolchain-funcs.eclass
> > @@ -384,6 +384,12 @@ tc-export_build_env() {
> > # the target build system does not check.
> > tc-env_build() {
> > tc-export_build_env
> > + local -x SYSROOT=
> > + if [[ ${EAPI} == 6 ]]; then
> > + local -x ESYSROOT=${EPREFIX}
> > + else
> > + local -x ESYSROOT=${BROOT}
> > + fi
> > CFLAGS=${BUILD_CFLAGS} \
> > CXXFLAGS=${BUILD_CXXFLAGS} \
> > CPPFLAGS=${BUILD_CPPFLAGS} \
>
> What do you need this for? Just wondering because I wouldn't have thought
> anything you wrap with tc-env_build would care about ESYSROOT.
I ran into this when converting dev-build/ninja to use cmake.eclass.
Basically, I need to invoke ninja to build its own docs. I accomplish
this by building a second "native" (CBUILD) copy of ninja when
cross-compiling.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1122aa04647a60de150811c133490d248de4bc43
cmake.eclass utilizes ESYSROOT when SYSROOT is not empty.
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/cmake.eclass?id=1122aa04647a60de150811c133490d248de4bc43#n503
If I don't set SYSROOT to empty when building the "native" ninja, it
explodes with a segfault when I invoke it in the ebuild.
[gentoo-dev] [PATCH] toolchain-funcs.eclass: tc-env_build: override (E)SYSROOT
When using the CBUILD toolchain, it makes no sense to look for headers
and libraries in the CHOST-based SYSROOT.
Signed-off-by: Mike Gilbert
---
eclass/toolchain-funcs.eclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index cde84e6f34c8..58a718180079 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1,4 +1,4 @@
-# Copyright 2002-2023 Gentoo Authors
+# Copyright 2002-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: toolchain-funcs.eclass
@@ -384,6 +384,12 @@ tc-export_build_env() {
# the target build system does not check.
tc-env_build() {
tc-export_build_env
+ local -x SYSROOT=
+ if [[ ${EAPI} == 6 ]]; then
+ local -x ESYSROOT=${EPREFIX}
+ else
+ local -x ESYSROOT=${BROOT}
+ fi
CFLAGS=${BUILD_CFLAGS} \
CXXFLAGS=${BUILD_CXXFLAGS} \
CPPFLAGS=${BUILD_CPPFLAGS} \
--
2.44.0
[gentoo-dev] [PATCH] meson.eclass: preserve exit status in phase funcs
When the functions are called with nonfatal, we need to ensure 'popd'
does not clobber the exit status of the called command.
Update meson_src_configure as well just for consistency.
Closes: https://bugs.gentoo.org/930119
Signed-off-by: Mike Gilbert
---
eclass/meson.eclass | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 9d7f830e58b0..a22a85887584 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -425,7 +425,10 @@ meson_src_configure() {
export -n {C,CPP,CXX,F,OBJC,OBJCXX,LD}FLAGS
PKG_CONFIG_{LIBDIR,PATH}
echo meson setup "${MESONARGS[@]}" >&2
meson setup "${MESONARGS[@]}"
- ) || die -n
+ )
+ local rv=$?
+ [[ ${rv} -eq 0 ]] || die -n "configure failed"
+ return ${rv}
}
# @FUNCTION: meson_src_compile
@@ -451,9 +454,12 @@ meson_src_compile() {
set -- meson compile "${mesoncompileargs[@]}"
echo "$@" >&2
- "$@" || die -n "compile failed"
+ "$@"
+ local rv=$?
+ [[ ${rv} -eq 0 ]] || die -n "compile failed"
popd > /dev/null || die
+ return ${rv}
}
# @FUNCTION: meson_src_test
@@ -473,9 +479,12 @@ meson_src_test() {
set -- meson test "${mesontestargs[@]}"
echo "$@" >&2
- "$@" || die -n "tests failed"
+ "$@"
+ local rv=$?
+ [[ ${rv} -eq 0 ]] || die -n "tests failed"
popd > /dev/null || die
+ return ${rv}
}
# @FUNCTION: meson_install
@@ -495,9 +504,12 @@ meson_install() {
set -- meson install "${mesoninstallargs[@]}"
echo "$@" >&2
- "$@" || die -n "install failed"
+ "$@"
+ local rv=$?
+ [[ ${rv} -eq 0 ]] || die -n "install failed"
popd > /dev/null || die
+ return ${rv}
}
# @FUNCTION: meson_src_install
--
2.44.0
Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management
On Mon, Apr 8, 2024 at 5:51 AM Jaco Kroon wrote: > > Hi All, > > I was hoping for some advise regarding how I could improve the glusterfs > package for users (and myself). At least those using openrc, but I > suspect similar may be applicable to systemd, but I have no idea how > systemd handles network mounts so perhaps someone could chip in here on > that front too. > > Specifically the mounting of glusterfs file systems currently has a few > problems (glusterd if server=localhost, network, dns(?) and fuse > availability). For now the focus is on the fuse aspect since that's the > biggest annoyance by far. > > Mounting happens via the netmount service. > > In order for glusterfs to mount successfully the fuse module needs to be > available when mount.glusterfs is invoked. This can be achieved in one > of two ways: > > 1. Compile the module statically into the kernel. > 2. Arrange for fuse service to be started prior to netmount (using say > /etc/conf.d/netmount rc_need="fuse") This doesn't sound right. Why does the kernel module need to be loaded explicitly? The kernel should auto-load the module when /dev/fuse is opened for the first time. /dev/fuse should get created via tmpfiles.d via kmod-static-nodes.
Re: [gentoo-dev] [PATCH 2/2] sys-apps/systemd-utils: add workaround for no-multilib
On Tue, Mar 26, 2024 at 12:51 PM Michał Górny wrote: > > On Tue, 2024-03-26 at 11:01 -0400, Mike Gilbert wrote: > > meson.build has some logic to build ia32 EFI binaries on x86_64 if the > > toolchain is compatible. Rather than trying to reproduce this logic in > > the ebuild, just try to build it and ignore any failures. > > > > If meson.build actually defines the targets but we have some other > > compile error, this will move the failure to the install phase instead. > > > > That's not a correct use of nonfatal. It is supposed to be used to > provide customized error handling (e.g. cleanup step before dying), not > a cheap way to ignore errors. I disagree; the error will not go unhandled, it's just being deferred until later.
[gentoo-dev] [PATCH 2/2] sys-apps/systemd-utils: add workaround for no-multilib
meson.build has some logic to build ia32 EFI binaries on x86_64 if the
toolchain is compatible. Rather than trying to reproduce this logic in
the ebuild, just try to build it and ignore any failures.
If meson.build actually defines the targets but we have some other
compile error, this will move the failure to the install phase instead.
Signed-off-by: Mike Gilbert
---
sys-apps/systemd-utils/systemd-utils-255.4.ebuild | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
b/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
index b258f5748243..7f17b37aa3ea 100644
--- a/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
+++ b/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
@@ -253,7 +253,7 @@ multilib_src_configure() {
}
multilib_src_compile() {
- local targets=()
+ local targets=() optional_targets=()
if multilib_is_native_abi; then
if use boot; then
local efi_arch= efi_arch_alt=
@@ -275,7 +275,10 @@ multilib_src_compile() {
src/boot/efi/addon${efi_arch}.efi.stub
)
if [[ -n ${efi_arch_alt} ]]; then
- targets+=(
+ # If we have a multilib toolchain, meson.build
will build the
+ # "alt" arch (ia32). There's no easy way to
detect this, so try
+ # to build it and ignore failure.
+ optional_targets+=(
src/boot/efi/systemd-boot${efi_arch_alt}.efi
src/boot/efi/linux${efi_arch_alt}.efi.stub
src/boot/efi/addon${efi_arch_alt}.efi.stub
@@ -392,9 +395,12 @@ multilib_src_compile() {
)
fi
fi
- if multilib_is_native_abi || use udev; then
+ if [[ ${#targets[@]} -ne 0 ]]; then
meson_src_compile "${targets[@]}"
fi
+ if [[ ${#optional_targets[@]} -ne 0 ]]; then
+ nonfatal meson_src_compile "${optional_targets[@]}"
+ fi
}
multilib_src_test() {
--
2.44.0
[gentoo-dev] [PATCH 1/2] meson.eclass: call die -n in phase helpers
This allows the ebuild author to treat some errors as nonfatal.
Signed-off-by: Mike Gilbert
---
eclass/meson.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 3240fddf7e86..3074fcb09fb0 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -425,7 +425,7 @@ meson_src_configure() {
export -n {C,CPP,CXX,F,OBJC,OBJCXX,LD}FLAGS
PKG_CONFIG_{LIBDIR,PATH}
echo meson setup "${MESONARGS[@]}" >&2
meson setup "${MESONARGS[@]}"
- ) || die
+ ) || die -n
}
# @FUNCTION: meson_src_compile
@@ -450,7 +450,7 @@ meson_src_compile() {
set -- meson compile "${mesoncompileargs[@]}"
echo "$@" >&2
- "$@" || die "compile failed"
+ "$@" || die -n "compile failed"
}
# @FUNCTION: meson_src_test
@@ -469,7 +469,7 @@ meson_src_test() {
set -- meson test "${mesontestargs[@]}"
echo "$@" >&2
- "$@" || die "tests failed"
+ "$@" || die -n "tests failed"
}
# @FUNCTION: meson_install
@@ -488,7 +488,7 @@ meson_install() {
set -- meson install "${mesoninstallargs[@]}"
echo "$@" >&2
- "$@" || die "install failed"
+ "$@" || die -n "install failed"
}
# @FUNCTION: meson_src_install
--
2.44.0
Re: [gentoo-dev] [PATCH v2 4/7] distutils-r1.eclass: Make vars local before calling filter-lto
On Tue, Mar 5, 2024 at 12:16 PM Michał Górny wrote:
>
> Make LTO filtering local to the compilation code. This avoids disabling
> LTO for non-Python parts of an ebuild.
>
> Signed-off-by: Michał Górny
> ---
> eclass/distutils-r1.eclass | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index ee1dcef24ff6..134cb39f276a 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -1828,6 +1828,10 @@ distutils-r1_run_phase() {
> # Rust extensions are incompatible with C/C++ LTO compiler
> # see e.g. https://bugs.gentoo.org/910220
> if has cargo ${INHERITED}; then
> + local x
> + for x in $(all-flag-vars); do
> + local -x "${x}=${!x}"
> + done
> filter-lto
> fi
> fi
I had never thought to loop over all-flag-vars like this. Added to my
mental code repo, thanks!
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: wire up LTO support directly into the meson options
On Tue, Feb 20, 2024 at 1:09 AM Eli Schwartz wrote: > > On 2/20/24 12:58 AM, Mike Gilbert wrote: > > On Mon, Feb 19, 2024 at 11:26 PM Eli Schwartz wrote: > >> > >> meson's builtin LTO support allows meson to introspect whether LTO is > >> enabled and do some fancy things, such as forcing LTO off for a single > >> target that is known to be special(ly bad) and not support LTO. > > > > Please make sure to test this change with a multilib-enabled ebuild > > with multiple ABIs enabled. I suspect the filter-lto call will cause > > differing results for the ABIs after the first. > > > > If that is the case, we may need to declare the relevant FLAGS > > variables with "local -x". > > > >>> Configuring source in > /var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson ... > * abi_x86_32.x86: running multilib-minimal_abi_src_configure > meson setup --libdir lib --localstatedir /var/lib --prefix /usr > --sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path > /usr/share/pkgconfig:/usr/share/pkgconfig --pkg-config-path > /usr/share/pkgconfig:/usr/share/pkgconfig --native-file > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini > -Db_pch=false -Dwerror=false -Db_lto=true -Db_lto_threads=4 > -Dbuildtype=plain -Ddefault_library=shared -Dbin_programs=false > -Dbin_contrib=false -Dbin_tests=false -Dzlib=disabled -Dlzma=disabled > -Dlz4=disabled --native-file > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini.local > /var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson > /var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson-abi_x86_32.x86 > [...] > Native files : > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini > > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini.local > b_lto: true > b_lto_threads: 4 > > > > > * abi_x86_64.amd64: running multilib-minimal_abi_src_configure > meson setup --libdir lib64 --localstatedir /var/lib --prefix /usr > --sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path > /usr/share/pkgconfig --pkg-config-path /usr/share/pkgconfig > --native-file > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini > -Db_pch=false -Dwerror=false -Db_lto=true -Db_lto_threads=4 > -Dbuildtype=plain -Ddefault_library=shared -Dbin_programs=true > -Dbin_contrib=true -Dbin_tests=false -Dzlib=enabled -Dlzma=enabled > -Dlz4=disabled --native-file > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini.local > /var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson > /var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson-abi_x86_64.amd64 > [...] > Native files : > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini > > /var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini.local > b_lto: true > b_lto_threads: 4 I'm afraid I get different results. Build log attached. Happy to help figure this out tomorrow. To test, I applied this patch and ran this: ABI_X86="32 x32 64" CFLAGS="-O2 -pipe -march=amdfam10 -flto=2" ebuild zstd-1.5.5-r1.ebuild clean configure [32m * [39;49;00mPackage:app-arch/zstd-1.5.5-r1:0/1 [32m * [39;49;00mRepository: gentoo [32m * [39;49;00mMaintainer: base-sys...@gentoo.org [32m * [39;49;00mUSE:abi_x86_32 abi_x86_64 abi_x86_x32 amd64 elibc_glibc kernel_linux lzma zlib [32m * [39;49;00mFEATURES: ccache network-sandbox preserve-libs sandbox userpriv usersandbox [32m * [39;49;00mPackage:app-arch/zstd-1.5.5-r1:0/1 [32m * [39;49;00mRepository: gentoo [32m * [39;49;00mMaintainer: base-sys...@gentoo.org [32m * [39;49;00mUSE:abi_x86_32 abi_x86_64 abi_x86_x32 amd64 elibc_glibc kernel_linux lzma zlib [32m * [39;49;00mFEATURES: ccache network-sandbox preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking zstd-1.5.5.tar.gz to /x/portage/app-arch/zstd-1.5.5-r1/work >>> Source unpacked in /x/portage/app-arch/zstd-1.5.5-r1/work >>> Preparing source in /x/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson ... [32m*[0m Applying zstd-1.5.4-no-find-valgrind.patch ... [A[92C [34;01m[ [32;01mok[34;01m ][0m >>> Source prepared. >>> Configuring source in /x/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson ... [32m*[0m abi_x86_32.x86: running multilib-minimal_abi_src_configure meson setup --libdir lib --localstatedir /var/lib --prefix /usr --sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path /us
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: wire up LTO support directly into the meson options
On Mon, Feb 19, 2024 at 11:26 PM Eli Schwartz wrote: > > meson's builtin LTO support allows meson to introspect whether LTO is > enabled and do some fancy things, such as forcing LTO off for a single > target that is known to be special(ly bad) and not support LTO. Please make sure to test this change with a multilib-enabled ebuild with multiple ABIs enabled. I suspect the filter-lto call will cause differing results for the ABIs after the first. If that is the case, we may need to declare the relevant FLAGS variables with "local -x".
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On Fri, Feb 9, 2024 at 12:17 PM Michael Orlitzky wrote: > > On Fri, 2024-02-09 at 11:57 -0500, Mike Gilbert wrote: > > > > Based on this pkgcheck issue, this originates from a decision from by > > Gentoo QA team. > > > > https://github.com/pkgcore/pkgcheck/issues/414#issuecomment-1213057268 > > > > Thanks for the dig. I agree with the reasoning for things like > USE=bash-completion and USE=vim-syntax, where the added complexity of a > flag is not justified to avoid installing small files. In those cases, > the additional files simply don't do anything if you don't (for > example) use vim. > > USE=unicode and USE=ipv6 are different beasts. In many cases they > directly and immediately change the behavior of the package. In most cases I have seen, it makes more sense to toggle the behavior at runtime rather than disabling functionality at build time. Exposing build flags for stuff that can be toggled at runtime is added complexity for little benefit. It sometimes even makes maintaining the ebuild and dependent packages more difficult.
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On Fri, Feb 9, 2024 at 11:07 AM Michael Orlitzky wrote: > > On Fri, 2024-02-09 at 10:54 -0500, Ionen Wolkens wrote: > > > > Is there even any reason to ever disable unicode support? Point is that > > why have USE for it? Or does it introduce additional dependencies? > > Being able to disable things like this is one of the few reasons why > people choose Gentoo. Based on this pkgcheck issue, this originates from a decision from by Gentoo QA team. https://github.com/pkgcore/pkgcheck/issues/414#issuecomment-1213057268
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On Fri, Feb 9, 2024 at 10:23 AM Andrey Grozin wrote: > > Hello *, > > pkgcheck complains about each new version of dev-lisp/sbcl: > > UseFlagWithoutDeps: version 2.4.1: special small-files USE flag without > effect on dependencies: [ unicode ] > > The USE flag "unicode" in the sbcl ebuild has nothing to do with > installing / not installing any files, small or otherwise. It determins > whether the produced lisp will support unicode internally: > > sbcl_feature "$(usep unicode)" ":sb-unicode" > > Usually this is desirable, so, in USE we have +unicode. Is there a way to > silence these warnings? Is there some reason not to enable this unconditionally?
Re: [gentoo-dev] [PATCH] 2024-02-01-grub-upgrades: add news item
On Tue, Feb 6, 2024 at 6:44 AM Christian Bricart wrote: > > Am 28.01.24 um 17:25 schrieb Mike Gilbert: > > […] > > +On upgrades, it is common for users to mismatch the grub-install options > > +they used for the current and previous versions of grub. This will cause > > +a stale core image to exist. For example: > > + > > +/boot/efi/EFI/BOOT/BOOTX64.EFI (grub 2.06 core image) > > +/boot/efi/EFI/gentoo/grubx64.efi (grub 2.12 core image) > > +/boot/grub/x86_64-pc/*.mod (grub 2.12 modules) > > despite x64, the path is always /boot/grub/i386-pc/*.mod for > GRUB_PLATFORMS=pc Fixed. https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=e0e93c981baef4a697dac91e8a9efed0a4a204b5
Re: [gentoo-dev] RFC: Block ebuilds installing tests to ${D} by default
On Thu, Feb 1, 2024 at 4:38 PM Eli Schwartz wrote: > > On 2/1/24 4:03 PM, Michał Górny wrote: > > I suppose you are referring to dev-lang/python here. Unfortunately, > > removing tests from it is a non-trivial problem. As I've mentioned to > > you before, there are packages that actually import modules form the > > test directory. > > > > Remember that Gentoo has a policy of following upstream, and this policy > > is specifically targeted towards developers who expect Gentoo to > > be a good baseline environment for developing packages. By explicitly > > diverging from upstream default install by default, we are effectively > > creating an incompatible Python environment and requiring users to go > > through extra steps to restore upstream compatibility. > > > The "following upstream" argument is extremely weak. > > eschwartz ~/git/cpython $ ./configure --help| grep test > --disable-test-modules don't build nor install test modules > > > Clearly, upstream is giving you loud and clear permission to refrain > from installing this. They even have a split in their Makefile variables: > - LIBSUBDIRS: things that are always installed > - TESTSUBDIRS: test files that you can disable Ah, that's a relatively new configure option added in Python 3.10. It didn't exist back in 2015 when I was looking into this. https://docs.python.org/3/whatsnew/3.10.html#build-changes Thanks for pointing it out.
Re: [gentoo-dev] RFC: Block ebuilds installing tests to ${D} by default
On Thu, Feb 1, 2024 at 3:15 AM Robin H. Johnson wrote:
>
> TL;DR:
> I'd like to propose a change where packages should NOT install their
> tests to ${D} by default. Such an install may optionally enabled with
> USE=test, which should be decoupled from FEATURES=test. Or depending on
> the color of the bikeshed, we add something new like USE=install-tests.
>
> Background:
> Python packages install a number of _test.py files, and related .pyc
> files. The files are generally useful for running tests after the
> package is installed, and may have additional testing dependencies that
> are not installed via RDEPEND.
It sounds like you want to resurrect bug 531648.
https://bugs.gentoo.org/531648
[gentoo-dev] [PATCH] 2024-02-01-grub-upgrades: add news item
Signed-off-by: Mike Gilbert --- .../2024-02-01-grub-upgrades.en.txt | 40 +++ 1 file changed, 40 insertions(+) create mode 100644 2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt diff --git a/2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt b/2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt new file mode 100644 index 000..f7aaa72 --- /dev/null +++ b/2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt @@ -0,0 +1,40 @@ +Title: GRUB upgrades +Author: Mike Gilbert +Posted: 2024-02-01 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-boot/grub + +When booting with GRUB, it is important that the core image and modules +have matching versions. Usually, running grub-install is sufficient to +ensure this. + +On the UEFI platform, grub-install allows the core image to be placed in +two different locations: + +EFI/gentoo/grubx64.efi +This is the location used by grub-install without options. + +EFI/BOOT/BOOTX64.EFI +This is the location used by grub-install --removable. + +On upgrades, it is common for users to mismatch the grub-install options +they used for the current and previous versions of grub. This will cause +a stale core image to exist. For example: + +/boot/efi/EFI/BOOT/BOOTX64.EFI (grub 2.06 core image) +/boot/efi/EFI/gentoo/grubx64.efi (grub 2.12 core image) +/boot/grub/x86_64-pc/*.mod (grub 2.12 modules) + +Booting this system using BOOTX64.EFI image would likely fail due to a +symbol mismatch between the core image and modules. [1] + +Re-runing grub-install both with and without the --removable option +should ensure a working GRUB installation. + +However, this will clobber any BOOTX64.EFI image provded by other +loaders. If dual-booting using another boot loader, users must take care +not to replace BOOTX64.EFI if it is not provided by GRUB. + +References: +[1] https://bugs.gentoo.org/920708 -- 2.43.0
[gentoo-dev] [PATCH] toolchain-funcs.eclass: tc-ld-force-bfd: unset LD before calling tc-getLD
The previous logic would fail with common values of LD set by the user:
LD="ld.lld" -> LD="ld.lld.bfd"
LD="ld.gold" -> LD="ld.gold.bfd"
LD="mold" -> LD="mold.bfd"
It makes more sense to ignore the user's LD setting and use the default
value given by tc-getLD.
If the user doesn't have binutils installed, the "type -P" check will still
fail and LD will be unaltered.
Closes: https://github.com/gentoo/gentoo/pull/33650
Signed-off-by: Mike Gilbert
---
eclass/toolchain-funcs.eclass | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 4559894ca04a..8fef764ad597 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -534,10 +534,9 @@ tc-ld-force-bfd() {
ewarn "Forcing usage of the BFD linker"
# Set up LD to point directly to bfd if it's available.
- local ld=$(tc-getLD "$@")
- # We need to extract the first word in case there are flags appended
- # to its value (like multilib), bug #545218.
- local bfd_ld="${ld%% *}.bfd"
+ # Unset LD first so we get the default value from tc-getLD.
+ local ld=$(unset LD; tc-getLD "$@")
+ local bfd_ld="${ld}.bfd"
local path_ld=$(type -P "${bfd_ld}" 2>/dev/null)
[[ -e ${path_ld} ]] && export LD=${bfd_ld}
--
2.42.0
[gentoo-dev] Re: [gentoo-dev-announce] Up for grabs: packages from sultan's retirement
On Mon, Sep 18, 2023 at 5:49 AM Sam James wrote: > > Packages up for grabs: > acct-group/croc > acct-user/croc > app-misc/liquidctl > dev-libs/hidapi > dev-python/hidapi > net-misc/croc > Also, sultan leaving means we are down to 1 person proxy maintaining www-client/chromium. If you have any interest in helping with this package, please reach out in #gentoo-chromium on Libra.chat.
Re: [gentoo-dev] Re: last rites: sys-fs/eudev
On Thu, Sep 14, 2023 at 10:25 AM Arsen Arsenović wrote: > Madhu writes: > > systemd-udev cannot be built as a static binary again presumably a > > carefully thought out design decision behind its design and > > philosophy. > > Since static linking is seldom a good idea, it is more likely that > simply nobody bothered. I don't recall any udev components in systemd > v249 (which is the version I attempted to rebase eudev on top of) which > can't be static linked. The main issue is symbol conflicts with several major projects. systemd makes careful use of ELF symbol visibility (hidden symbols) to prevent conflicts when libudev or libsystemd are linked with other projects. As I understand it, it is up to the linker to apply any visibility rules. This doesn't work for static libs since the linker isn't actually involved in their creation. A static library is really just an archive with a bunch of unlinked ELF objects. Since the symbol visibility rules are not applied, attempting to link against libudev.a or libsystemd.a leads to symbol conflicts in packages like LVM2 and cryptsetup. There are some Gentoo bug reports about this, but I can't find them immediately. The systemd project (upstream) has chosen not to work around these conflicts by renaming symbols, and instead chooses not to support static linking at all. They see static libs as being defective by design. If the symbol visibility issue could be resolved at the toolchain level, they would probably be more willing to support it.
Re: [gentoo-dev] games-emulation/jgemu keywording request
On Mon, Sep 11, 2023 at 4:11 PM orbea wrote: > > On Mon, 11 Sep 2023 20:38:48 +0100 > Sam James wrote: > > > orbea writes: > > > > > On Mon, 11 Sep 2023 19:18:45 +0100 > > > Sam James wrote: > > > > > >> orbea writes: > > >> > > >> > Hi, > > >> > > > >> > Several months ago I made this issue for keywording the > > >> > games-emulation/jgemu meta package which is a collection of > > >> > minimal emulators for the command-line games-emulation/jgrf > > >> > frontend with a focus on accuracy. > > >> > > > >> > > >> You've not populated the package list and no arches are CC'd, but > > >> we don't keyword things for no reason either on (very) niche > > >> arches. > > >> > > >> Please select a reasonable set of architectures. > > >> > > >> > https://bugs.gentoo.org/891201 > > >> > > >> > > > > > > Apologies, I wasn't aware I needed to do that and in retrospect I > > > should of thought of it. Just to be clear you mean add an issue for > > > each issue and then use them as blockers for the > > > games-emulation/jgemu issue? > > > > No, one bug is okay if you populate the package list field in > > Bugzilla. > > > > Just keep in mind that keywording isn't the same as upstreaam CI > > either and we generally want to only keyword on arches where someone > > is likely to use it. > > > > Apologies, I now understand what you meant... > > The goal is to hopefully entice real world testers on systems that > jgemu may be used. This is not something a CI would be able to > accomplish. This is not an appropriate use of Gentoo arch testing. We keyword things based on user demand, not to satisfy the urges of upstream developers.
Re: [gentoo-dev] Massive Github PR Queue
On Fri, Aug 11, 2023 at 21:18 Michael Orlitzky wrote: > On Fri, 2023-08-11 at 10:35 -0700, orbea wrote: > > > > Perhaps the correct answer would be neither Bugzilla or Github? > > A mailing list (whose archives work :o) with git-send-email threads > would be an improvement over both. > > > I don’t think replacing pull requests with mailing list posts would yield any significant improvement. Personally, I am much less likely to go through the trouble of fetching patches from my email than fetching a branch from GitHub.
[gentoo-dev] Last rites: sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, sys-fs/udev
# Mike Gilbert (2023-07-24) # Migrated to sys-apps/systemd-utils. # Removal on 2023-08-24. sys-apps/systemd-tmpfiles sys-boot/systemd-boot sys-fs/udev
Re: [gentoo-dev] [PATCH v2] meson.eclass: allow disabling verbose compilation
On Thu, Jul 20, 2023 at 11:06 AM Florian Schmaus wrote:
>
> On 20/07/2023 17.00, Matt Turner wrote:
> > On Wed, Jul 19, 2023 at 3:23 AM Florian Schmaus wrote:
> >>
> >> On 18/07/2023 18.44, Matt Turner wrote:
> >>> From: Jonas Rakebrandt
> >>>
> >>> This works similar to cmake.eclass's ${CMAKE_VERBOSE}.
> >>>
> >>> Closes: https://github.com/gentoo/gentoo/pull/28942
> >>> Signed-off-by: Jonas Rakebrandt
> >>> Signed-off-by: Matt Turner
> >>> ---
> >>>eclass/meson.eclass | 15 +--
> >>>1 file changed, 13 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> >>> index 2c274b213191..3b30f66bf30a 100644
> >>> --- a/eclass/meson.eclass
> >>> +++ b/eclass/meson.eclass
> >>> @@ -55,6 +55,12 @@ BDEPEND=">=dev-util/meson-0.62.2
> >>># Build directory, location where all generated files should be placed.
> >>># If this isn't set, it defaults to ${WORKDIR}/${P}-build.
> >>>
> >>> +# @ECLASS_VARIABLE: MESON_VERBOSE
> >>> +# @USER_VARIABLE
> >>> +# @DESCRIPTION:
> >>> +# Set to OFF to disable verbose messages during compilation
> >>> +: "${MESON_VERBOSE:=ON}"
> >>> +
> >>># @ECLASS_VARIABLE: EMESON_BUILDTYPE
> >>># @DESCRIPTION:
> >>># The buildtype value to pass to meson setup.
> >>> @@ -385,10 +391,15 @@ meson_src_compile() {
> >>>-C "${BUILD_DIR}"
> >>>--jobs "$(makeopts_jobs "${MAKEOPTS}" 0)"
> >>>--load-average "$(makeopts_loadavg "${MAKEOPTS}" 0)"
> >>> - --verbose
> >>> - "$@"
> >>>)
> >>>
> >>> + case ${MESON_VERBOSE} in
> >>> + OFF) ;;
> >>> + *) mesoncompileargs+=( --verbose ) ;;
> >>> + esac
> >>
> >> No strong opinion, just to educate myself, but is there an advantage of
> >> using case/easc over if/fi here?
> >>
> >> That is
> >>
> >> if [[ ${MESON_VERBOSE} != off ]]; then
> >> mesoncompileargs+=( --verbose )
> >> fi
> >>
> >> or even the shell-style short idiom using ||.
> >
> > No advantage as far as I'm aware. I was just copying the style used in
> > cmake.eclass.
> >
> > I really wish bash just had boolean types :(
>
> While the bash language has no boolean datatype, you can exploit the
> fact that 'true' and 'false' are usually shell builtins:
>
> : "${MESON_VERBOSE:=true}"
>
> and then later
>
> if $MESON_VERBOSE; then
> mesoncompileargs+=( --verbose )
> fi
I think we generally try to avoid exploiting that behavior in ebuilds.
It's usually much more obvious to check for a non-empty string, or for
a specific value.
Re: [gentoo-dev] [PATCH 1/2] ninja-utils.eclass: Add NINJA_VERBOSE
On Mon, Jul 17, 2023 at 11:21 AM Matt Turner wrote: > > ninja operates in one of three modes: > - verbose (with -v): prints build commands > - quiet (with --quiet): prints nothing > - normal: prints [XX/YY]-style build status updates > > samurai works the same way, except it does not have a quiet mode. > > Thus we can't simply override ninja-utils' hard-coded flag from callers > of eninja. Seems ok to me.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: > > Haven't we been keeping these because we still need to decide on a > > policy about what to do with dead acct-*/* packages? > > Right. https://bugs.gentoo.org/781881 is still open. Flow could ping > the QA team and ask if it should be closed, given the opinion there > seems to be that there's no need to keep them, but I think it's wrong > to do this pre-empting a policy decision, given it essentially forces > the "don't keep them" path. The bug has been open for several months without comment. If a policy were going to materialize, I think it would have happened by now. Forcing the issue by sending this last rites notice seems acceptable to me.
Re: [gentoo-dev] [PATCH 1/1]: profiles/use.desc: add efi global use flag
On Fri, Jul 14, 2023 at 5:07 AM Sam James wrote: > > > Andrew Ammerlaan writes: > > > Hi all, > > > > Currently we have 7 packages defining the efi flag and an additional 2 > > defining the uefi flag. These flags do the same thing, add support for > > (U)EFI booting. I therefore propose we introduce efi as a new global > > flag and later rename the uefi flag to efi in sys-apps/fwupd and > > sys-apps/ipmicfg. > > > > I don't have a strong preference between the efi or uefi flags, but > > since a majority of the packages has chosen efi I suggest we go with > > that. > > Let's do USE=uefi please - UEFI is the modern name for it, and EFI is > legacy. I'd like to avoid another USE=ssl situation (where we're > stuck with it forever given we have no mechanism for USE flag renames, > despite the fact that it's really TLS now). Any thoughts on grub_platforms_efi-32 and grub_platforms_efi-64? If we want to rename USE flags, I would probably take the opportunity to eliminate the GRUB_PLATFORMS USE_EXPAND altogether.
[gentoo-dev] [PATCH] user-info.eclass: egetent: fix lookup by id when ROOT != /
Previous to this change, egetent would match any id that starts with the
id given as input. For example:
egetent group 1
bin::1:root,bin,daemon
wheel::10:root
floppy::11:root
news::13:news
uucp::14:uucp
console::17:
audio::18:
cdrom::19:
users::100:
Adding a colon to the grep expression yeilds the desired result:
egetent group 1
bin::1:root,bin,daemon
Signed-off-by: Mike Gilbert
---
eclass/user-info.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
index b18f280c1022..1cc7b8250309 100644
--- a/eclass/user-info.eclass
+++ b/eclass/user-info.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: user-info.eclass
@@ -64,7 +64,7 @@ egetent() {
getent "${db}" "${key}"
else
if [[ ${key} =~ ^[[:digit:]]+$ ]]; then
- grep -E "^([^:]*:){2}${key}" "${ROOT}/etc/${db}"
+ grep -E "^([^:]*:){2}${key}:"
"${ROOT}/etc/${db}"
else
grep "^${key}:" "${ROOT}/etc/${db}"
fi
--
2.41.0
Re: [gentoo-dev] [PATCH] acct-user.eclass: include exit status in death message
On Sun, Jun 25, 2023 at 2:52 PM Michał Górny wrote:
>
> I think a better approach would be to always include $? in die messages
> in Portage.
It's a nice idea, but will not work in the case where die is not
called immediately after the failing command.
A couple of possible workarounds that could be used to reset $? before
calling die:
1. Exit in a subshell: (exit ${status})
2. Return from a function: set_status() { return $1; }; set_status ${status}
In any case, I would like to apply the acct-user.eclass patch soonish
to help with debugging an error during stage building that releng
reported to me in IRC. We can revisit changing the die function and
possibly revert this patch later.
[gentoo-dev] [PATCH] acct-user.eclass: include exit status in death message
Signed-off-by: Mike Gilbert
---
eclass/acct-group.eclass | 2 +-
eclass/acct-user.eclass | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 8d2d3adb7221..a0ad86066309 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -179,7 +179,7 @@ acct-group_pkg_preinst() {
fi
elog "Adding group ${ACCT_GROUP_NAME}"
- groupadd "${opts[@]}" "${ACCT_GROUP_NAME}" || die
+ groupadd "${opts[@]}" "${ACCT_GROUP_NAME}" || die "groupadd failed with
status $?"
}
fi
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 88d7d354c8e6..b03bf0f1ab28 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -362,7 +362,7 @@ acct-user_pkg_preinst() {
fi
elog "Adding user ${ACCT_USER_NAME}"
- useradd "${opts[@]}" "${ACCT_USER_NAME}" || die
+ useradd "${opts[@]}" "${ACCT_USER_NAME}" || die "useradd failed
with status $?"
_ACCT_USER_ADDED=1
fi
@@ -454,7 +454,7 @@ acct-user_pkg_postinst() {
eerror " usermod ${optsq[@]} ${ACCT_USER_NAME}"
else
eerror "$(<"${T}/usermod-error.log")"
- die "usermod failed"
+ die "usermod failed with status ${status}"
fi
fi
}
@@ -502,7 +502,7 @@ acct-user_pkg_prerm() {
fi
elog "Locking user ${ACCT_USER_NAME}"
- usermod "${opts[@]}" "${ACCT_USER_NAME}" || die
+ usermod "${opts[@]}" "${ACCT_USER_NAME}" || die "usermod failed with
status $?"
}
fi
--
2.41.0
Re: [gentoo-dev] [PATCH] acct-user.eclass: improve error message when usermod fails
On Sun, Jun 25, 2023 at 6:54 AM Florian Schmaus wrote:
> No strong opinion, but it is often a good idea to include the exit
> status. For example:
>
> die "usermod failed (${status})"
That's a really good idea. It could also be applied to the
useradd/groupadd/groupmod commands.
[gentoo-dev] [PATCH] acct-user.eclass: improve error message when usermod fails
usermod refuses to update the home directory for a user with running
processes. Output a more helpful message and avoid calling die for this.
For other usermod failures, output stderr as an eerror message and die.
Example output:
* Failed to update user portage
* This user currently has one or more running processes.
* Please update this user manually with the following command:
* usermod '--comment' 'System user; portage' '--home'
'/var/lib/portage/home' '--shell' '/bin/bash' '--gid' 'portage' '--groups' ''
portage
Bug: https://bugs.gentoo.org/888189
Signed-off-by: Mike Gilbert
---
eclass/acct-user.eclass | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index f8a51ebf9c6b..88d7d354c8e6 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -432,12 +432,30 @@ acct-user_pkg_postinst() {
fi
elog "Updating user ${ACCT_USER_NAME}"
- if ! usermod "${opts[@]}" "${ACCT_USER_NAME}"
2>"${T}/usermod-error.log"; then
- # usermod outputs a warning if unlocking the account would
result in an
- # empty password. Hide stderr in a text file and display it if
usermod
- # fails.
+ # usermod outputs a warning if unlocking the account would result in an
+ # empty password. Hide stderr in a text file and display it if usermod
fails.
+ usermod "${opts[@]}" "${ACCT_USER_NAME}" 2>"${T}/usermod-error.log"
+ local status=$?
+ if [[ ${status} -ne 0 ]]; then
cat "${T}/usermod-error.log" >&2
- die "usermod failed"
+ if [[ ${status} -eq 8 ]]; then
+ # usermod refused to update the home directory
+ # for a uid with active processes.
+ eerror "Failed to update user ${ACCT_USER_NAME}"
+ eerror "This user currently has one or more running
processes."
+ eerror "Please update this user manually with the
following command:"
+
+ # Surround opts with quotes.
+ # With bash-5 (EAPI 8), we can use "${opts[@]@Q}"
instead.
+ local q="'"
+ local optsq=( "${opts[@]/#/$q}" )
+ optsq=( "${optsq[@]/%/$q}" )
+
+ eerror " usermod ${optsq[@]} ${ACCT_USER_NAME}"
+ else
+ eerror "$(<"${T}/usermod-error.log")"
+ die "usermod failed"
+ fi
fi
}
--
2.41.0
Re: [gentoo-dev] Eselect repository feature request
On Wed, Jun 21, 2023 at 12:47 PM TOMAS FABRIZIO ORSI wrote: > I had not considered that possibility either. In that case, could not the > overlay > dependency resolution be handled as a module? > Said module could be a common interface for different package managers. > Then, the execution of said module would be handled on a per package > manager/sync program basis? I'm not quite certain what you mean by "module" here, but that sounds like unnecessary extra abstraction. I think flow's idea to make the sync command configurable somehow would be sufficient, assuming there is demand for it.
Re: [gentoo-dev] Eselect repository feature request
On Wed, Jun 21, 2023 at 12:49 PM Florian Schmaus wrote: > > On 21/06/2023 17.56, Mike Gilbert wrote: > > On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote: > >> > >> On 20.06.23 19:26, Mike Gilbert wrote: > >>> On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote: > >>>> > >>>> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote: > >>>>> Isn't that duplicating the information of metadata/layout.conf's > >>>>> 'master' key-value pair [1]? > >>>>> > >>>>> > >>>>> Yes, I agree that it would be duplicating that information. As a matter > >>>>> of fact, Michał Górny pointed the same thing out. > >>>>> However, Michał also added, quote: "What's really lacking here is > >>>>> support for specifying dependencies via |repositories.xml| > >>>> > >>>> Do we need to duplicate the information in repositories.xml, with all > >>>> the drawbacks of duplication? > >>>> > >>>> Can't eselect repository add the new repository, then read the 'masters' > >>>> value from layout.conf, and add the missing repositories recursively? > >>> > >>> That would be a significant change in behavior for eselect repository. > >> > >> Right, but it seems to be a desirable behaviour. Cases where the user > >> wants to add a repo but not immediately sync it are probably rare. > >> > >> Furthermore, it would avoid duplicating the information, which avoids > >> the typical drawbacks of duplication (e.g., the two sets getting out of > >> sync). > >> > >> I've looked at the eselect-repository code, and it seems not hard to > >> change the behaviour of "eselect repository add" to add and sync a > >> repository and then, recursively, add and sync further required > >> repositories. > >> > >> I may give it a shot, but ideally I'd know if it has a chance to be > >> accepted upstream first. Or maybe there is a good reason why > >> eselect-repository behaves as it currently does that I am missing? > > > > I can't speak for "upstream", but here are my concerns: > > > > 1. As a developer, I might just want to create the repos.conf config > > snippet and sync the repo manually. > > 2. As a user, I might have any arbitrary reason for not wanting to > > sync immediately. > > Would an opt-out switch be enough to alleviate those concerns of you? Yes. > > > 3. eselect-repository does not currently depend on any particular > > package manager. It writes config files intended for Portage, but it > > does not actually invoke any Portage commands. That feels like a > > significant distinction to me. > > 4. If you start invoking Portage commands, you then have to deal with > > the possibility of people using alternate package managers. pkgcore > > can also utilize Portage's repos.conf, and the user might prefer to > > use pmaint instead of emaint or emerge --sync. > > Those two points seem to be based on the same fundamental concern. > > The only portage specific code would be the call to "emaint sync -r > $repo" (remember that "emerge --sync" is just a wrapper for "emaint sync > --auto"). I think it would be easy to add later 1. add support for > different package managers (if the need arises), and 2. make the "sync > command" user configurable. Sure, that seems sensible.
Re: [gentoo-dev] Eselect repository feature request
On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote: > > On 20.06.23 19:26, Mike Gilbert wrote: > > On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote: > >> > >> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote: > >>> Isn't that duplicating the information of metadata/layout.conf's > >>> 'master' key-value pair [1]? > >>> > >>> > >>> Yes, I agree that it would be duplicating that information. As a matter > >>> of fact, Michał Górny pointed the same thing out. > >>> However, Michał also added, quote: "What's really lacking here is > >>> support for specifying dependencies via |repositories.xml| > >> > >> Do we need to duplicate the information in repositories.xml, with all > >> the drawbacks of duplication? > >> > >> Can't eselect repository add the new repository, then read the 'masters' > >> value from layout.conf, and add the missing repositories recursively? > > > > That would be a significant change in behavior for eselect repository. > > Right, but it seems to be a desirable behaviour. Cases where the user > wants to add a repo but not immediately sync it are probably rare. > > Furthermore, it would avoid duplicating the information, which avoids > the typical drawbacks of duplication (e.g., the two sets getting out of > sync). > > I've looked at the eselect-repository code, and it seems not hard to > change the behaviour of "eselect repository add" to add and sync a > repository and then, recursively, add and sync further required > repositories. > > I may give it a shot, but ideally I'd know if it has a chance to be > accepted upstream first. Or maybe there is a good reason why > eselect-repository behaves as it currently does that I am missing? I can't speak for "upstream", but here are my concerns: 1. As a developer, I might just want to create the repos.conf config snippet and sync the repo manually. 2. As a user, I might have any arbitrary reason for not wanting to sync immediately. 3. eselect-repository does not currently depend on any particular package manager. It writes config files intended for Portage, but it does not actually invoke any Portage commands. That feels like a significant distinction to me. 4. If you start invoking Portage commands, you then have to deal with the possibility of people using alternate package managers. pkgcore can also utilize Portage's repos.conf, and the user might prefer to use pmaint instead of emaint or emerge --sync.
Re: [gentoo-dev] Eselect repository feature request
On Wed, Jun 21, 2023 at 10:43 AM TOMAS FABRIZIO ORSI wrote: >> >> Sure, I think it could work. > > Great to hear. > In that case I could try to give it a try and make a pull request to the > emerge --sync with a basic idea. > Any tips? So emerge already emits a warning message when a repo is missing: https://gitweb.gentoo.org/proj/portage.git/tree/lib/portage/repository/config.py?h=portage-3.0.48.1#n1070 That looks something like this: $ sudo emerge --sync Unavailable repository 'foo' referenced by masters entry in '/var/db/repos/gentoo/metadata/layout.conf'
Re: [gentoo-dev] Eselect repository feature request
On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote: > > On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote: > > Isn't that duplicating the information of metadata/layout.conf's > > 'master' key-value pair [1]? > > > > > > Yes, I agree that it would be duplicating that information. As a matter > > of fact, Michał Górny pointed the same thing out. > > However, Michał also added, quote: "What's really lacking here is > > support for specifying dependencies via |repositories.xml| > > Do we need to duplicate the information in repositories.xml, with all > the drawbacks of duplication? > > Can't eselect repository add the new repository, then read the 'masters' > value from layout.conf, and add the missing repositories recursively? That would be a significant change in behavior for eselect repository. Currently, it does not actually sync any repos; it just manages the config in /etc/portage/repos.conf.
[gentoo-dev] Package up for grabs: app-emulation/open-vm-tools
I no longer use VMWare, so I can't really test this package.
Re: [gentoo-dev] [PATCH 1/2 v2] kernel-build.eclass: add IUSE="+strip modules-sign", install generated keys
On Thu, Jun 15, 2023 at 9:06 AM Andrew Ammerlaan
wrote:
> # @FUNCTION: kernel-build_merge_configs
> @@ -270,16 +354,39 @@ kernel-build_merge_configs() {
> local user_configs=( "${BROOT}"/etc/kernel/config.d/*.config )
> shopt -u nullglob
>
> + local merge_configs=( "${@}" )
> +
> + if [[ -n "${ALLOW_MODULES_SIGN}" ]]; then
> + if use modules-sign; then
> + : "${MODULES_SIGN_HASH:=sha512}"
> + cat <<-EOF > "${WORKDIR}/modules-sign.config" || die
> + ## Enable module signing
> + CONFIG_MODULE_SIG=y
> + CONFIG_MODULE_SIG_ALL=y
> + CONFIG_MODULE_SIG_FORCE=y
> + CONFIG_MODULE_SIG_${MODULES_SIGN_HASH^^}=y
I'm not sure if it matters, but menuconfig would also set
CONFIG_MODULE_SIG_HASH. eg.
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
# CONFIG_MODULE_SIG_SHA256 is not set
# CONFIG_MODULE_SIG_SHA384 is not set
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH="sha512"
Re: [gentoo-dev] www-client/chromium needs a new maintainer
On Wed, Jun 7, 2023 at 3:25 PM Jeff Gazso wrote: > > That does sound painful. > > > - Across the 3 channels, you are looking at roughly 12 releases per month. > > That's a lot of churn. > > * Why build unstable stuff, why not build only stable releases and fix the > problems once? That's certainly an option. The downside is stable releases almost always fix security issues, so you are "under the gun" at that point. > * Looking at chromium-browser-official and the GitHub mirror, it's unclear to > me which release is stable. How is that sorted out? Some links for you: https://chromiumdash.appspot.com/releases?platform=Linux https://chromereleases.googleblog.com/ > > - Upstream likes to use modern C++ features, and they write C++ code that > > tends to break or is unsupported on stable releases of GCC and LLVM. > > * How common of a problem is the C++ issue? There are usually some issues with every major Chromium version. > * I don't know C++, is that a major obstacle? Yes; you would at least need to teach yourself enough of the language to attempt to interpret compiler error message. > > - Upstream bundles many libraries. The Gentoo ebuild has some logic to > > unbundle a number of these, but maintaining it is a pain. > > * What tends to go wrong? - Version mismatches: upstream expects a different version of the library than we have stable on Gentoo. - Custom patching: sometimes Chromium forks/patches the bundled library and there is a delay in sending those changes upstream (if it ever happens). - Chromium source files sometimes refer to the bundled header files directly (#include "third_party/mylib/mylib.h") instead of using a generic path like #include . > > - Using the bundled libraries sometimes is problematic, especially on > > non-x86-64 targets which upstream doesn't support well. > > * What tends to break here? For example, take ffmpeg. The bundled library uses a pre-configured copy of ffmpeg, which can break depending on the user's system. At a minimum, we need to reconfigure the bundled ffmpeg to work properly. > * Is the upstream likely to take patches or are we stuck maintaining a patch > set for pretty much all non-x86-64 targets? Upstream supports x86-64 and ARM only. All other targets require distro patching. > * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make > their way upstream? Yes, this is why we have a PPC64 patchset (which we mostly steal from Raptor Computing).
Re: [gentoo-dev] www-client/chromium needs a new maintainer
On Wed, Jun 7, 2023 at 9:09 AM Jeff Gazso wrote: > > I'm in the process of getting Gentoo dev status. I'm willing to consider > maintaining www-client/chromium. I have a high core count rack server that > should be able to handle the build process quite well. Can you give me a list > of common pain points? If that is a long conversation feel free to email me > directly. I'll start by giving a brief overview of the Chromium release process upstream: - 3 release channels: stable, beta, dev/unstable - Major development occurs on the master branch. - Once a month, a new major version is forked from master, and this becomes the "dev channel" release series. - Over the next several weeks in the dev channel the major version is tested and fixed, with releases roughly once per week. - Eventually, the branch is promoted to the "beta channel". - A similar process occurs in the beta channel, with weekly releases until the major version is finally promoted to the "stable channel". - The stable channel sees around 1 to 2 releases per month, usually with security fixes included. Downstream, we have historically tried to keep up with all 3 channels. Keeping the dev channel working is the biggest challenge. The other channels usually just involve build testing and the occasional backport of fixes. Common problems: - Across the 3 channels, you are looking at roughly 12 releases per month. That's a lot of churn. - The dev channel never compiles the first time you try it. There are always problems to fix. - Upstream only really supports using their bundled toolchain (an LLVM git snapshot on Ubuntu). On Gentoo, we try to make it work with the stable release of GCC and LLVM/clang. - Upstream likes to use modern C++ features, and they write C++ code that tends to break or is unsupported on stable releases of GCC and LLVM. - Upstream bundles many libraries. The Gentoo ebuild has some logic to unbundle a number of these, but maintaining it is a pain. - Using the bundled libraries sometimes is problematic, especially on non-x86-64 targets which upstream doesn't support well. - Upstream cross-compiles their ARM binaries, whereas we compile natively on Gentoo. This sometimes causes conflicts. I'm probably missing some things, but I think that should give you some idea of what you're in for. :-)
Re: [gentoo-dev] [PATCH] eapi8-dosym.eclass: Prevent globbing of argument in _dosym8_canonicalize
On Tue, Jun 6, 2023 at 12:11 AM Ulrich Müller wrote: > > Signed-off-by: Ulrich Müller > --- > eclass/eapi8-dosym.eclass | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Looks good to me.
Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config
On Sun, Jun 4, 2023 at 2:03 PM Michael Orlitzky wrote: > > On Sun, 2023-06-04 at 13:31 -0400, Mike Gilbert wrote: > > This allows users to maintain the saved config file in some other > > location. > > > > If so, the symlink should point to a superuser-only location to avoid > creating any new vulnerabilities. We can't fix the general problem, but > we could at least mention in the docs that symlinks will (now) be > followed and that users should be careful if they want to maintain the > files elsewhere. That seems self-evident to me, and I don't think it warrants a callout in the documentation.
[gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config
This allows users to maintain the saved config file in some other
location.
Also drop the recursive (-R) option; this cp command is only executed
when we are restoring a single regular file.
Closes: https://bugs.gentoo.org/907696
Signed-off-by: Mike Gilbert
---
eclass/savedconfig.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index cc5748543078..a778dfba0245 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -124,8 +124,8 @@ restore_config() {
if [[ -f ${found} ]]; then
elog "Building using saved configfile \"${found}\""
- if [ $# -gt 0 ]; then
- cp -pPR "${found}" "$1" || die "Failed to restore
${found} to $1"
+ if [[ $# -gt 0 ]]; then
+ cp -p "${found}" "$1" || die "Failed to restore
${found} to $1"
else
die "need to know the restoration filename"
fi
--
2.40.1
[gentoo-dev] www-client/chromium needs a new maintainer
Hi all, I'm throwing in the towel on www-client/chromium. It just isn't any fun to maintain, and it's making me feel guilty when I don't give it the attention it requires. If anyone is interested in keeping it going, please feel free to reach out and I will do what I can to help with the transition. Full Gentoo developer(s) would be preferred, but I could also facilitate a proxy commit scenario. Also happy to mentor folks who want to make the transition to full developer. I'll stick around in #gentoo-chromium on Libra.chat for the foreseeable future. I'll also keep bumping the chromium-based binary browsers (google-chrome, edge, opera). Thanks.
[gentoo-dev] [PATCH] udev.eclass: add ${EPREFIX} to src_configure example
Signed-off-by: Mike Gilbert
---
eclass/udev.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index ac94f98221aa..7c587dc37f2f 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: udev.eclass
@@ -18,7 +18,7 @@
# DEPEND="${RDEPEND}"
#
# src_configure() {
-# econf --with-rulesdir="$(get_udevdir)"/rules.d
+# econf --with-rulesdir="${EPREFIX}$(get_udevdir)"/rules.d
# }
#
# src_install() {
--
2.40.1
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-portage/layman
On Thu, May 18, 2023 at 7:07 PM Sam James wrote: > > > Alexe Stefan writes: > > > Layman is still a convenient way of managing overlays. It still works > > as intended. > > Is there any way for it to be kept in the repos? > > Is there an issue for you with using eselect-repository, which is > actively maintained and doesn't depend on unmaintained software > (pyGPG and g-sorcery)? Is anyone aware of an alternative for "layman -i repo_name"? I use that on occasion to find overlay maintainers when assigning bug reports.
[gentoo-dev] Last rites: www-client/chromium-bin
# Out of date by several versions. Many unresolved security # vulnerabilities. Lack of manpower/interest in keeping it up to date. # Removal on 2023-06-03. www-client/chromium-bin
[gentoo-dev] Last rites: net-dns/ldns-utils
# Merged into net-libs/ldns. Bug 828109. # Removal on 2023-05-26. net-dns/ldns-utils
Re: [gentoo-dev] [PATCH] unpacker.eclass: Don't assume the default tar is stdin
On Thu, Apr 6, 2023 at 11:37 AM Arsen Arsenović wrote: > > Despite common misconception, the default GNU tar tarfile is not stdin. > On some systems, this can cause tar to fail to extract relevant files. > > See '(tar)file tutorial' for a description of how the default is picked. Looks good to me.
[gentoo-dev] [PATCH] cmake.eclass: handle quoted whitespace in MYCMAKEARGS
This uses eval in a similar way to econf and meson.eclass.
Signed-off-by: Mike Gilbert
---
eclass/cmake.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 2c5620adede5..46659867b1a8 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -595,9 +595,9 @@ cmake_src_configure() {
-DCMAKE_TOOLCHAIN_FILE="${toolchain_file}"
)
- if [[ -n ${MYCMAKEARGS} ]] ; then
- cmakeargs+=( "${MYCMAKEARGS}" )
- fi
+ # Handle quoted whitespace
+ eval "local -a MYCMAKEARGS=( ${MYCMAKEARGS} )"
+ cmakeargs+=( "${MYCMAKEARGS[@]}" )
if [[ -n "${CMAKE_EXTRA_CACHE_FILE}" ]] ; then
cmakeargs+=( -C "${CMAKE_EXTRA_CACHE_FILE}" )
--
2.39.2
[gentoo-dev] Last rites: net-im/teams
# Deprecated upstream. Use the progressive web app instead. # Removal on 2023-03-26. Bug 880425. net-im/teams
Re: [gentoo-dev] [PATCH] user-info.eclass: return immediately if db does not exist
On Sun, Feb 19, 2023 at 5:40 PM Bertrand Jacquin wrote:
>
> Using portage to bootstrap gentoo install can lead to the following
> warning when ROOT is empty:
>
> >> Running pre-merge checks for acct-group/root-0
> grep: /tmp/0xff.z2MjAjJXuo/root/etc/group: No such file or directory
> grep: /tmp/0xff.z2MjAjJXuo/root/etc/group: No such file or directory
>
> This change prevent egetent() from attempting to lookup key if database
> does not exit, removing error from output.
>
> Signed-off-by: Bertrand Jacquin
> ---
> eclass/user-info.eclass | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
> index b18f280c1022..79d33d6881ae 100644
> --- a/eclass/user-info.eclass
> +++ b/eclass/user-info.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2022 Gentoo Authors
> +# Copyright 1999-2023 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: user-info.eclass
> @@ -34,6 +34,9 @@ egetent() {
> *) die "sorry, database '${db}' not yet supported; file a bug" ;;
> esac
>
> + # return immediately if db does not exist
> + [[ ! -e "${EROOT}/etc/${db}" ]] && return 1
> +
> case ${CHOST} in
> *-freebsd*|*-dragonfly*)
> case ${db} in
>
This change makes sense to me.
The "return 1" made me think about the return value a bit more. If we
want to replicate the behavior of getent from glibc, we should return
2 if the user/group does not exist or if the passwd/group files are
missing. I don't think any ebuild/eclass code really cares about the
specific status though, so we can leave that alone for now.
[gentoo-dev] Packages up for grabs: sys-process/daemontools and related tools
These packages were formerly maintained by the base-system project. They have not been updated in a while, and we suspect nobody in the project is actually using them. sys-process/daemontools sys-process/daemontools-encore sys-process/supervise-scripts virtual/daemontools
[gentoo-dev] [PATCH] waf-utils.eclass: enable parallel install
This gives a nice speedup to net-fs/samba, which (re)links several
hundred files in its install phase.
Bug: https://bugs.gentoo.org/715542
Signed-off-by: Mike Gilbert
---
eclass/waf-utils.eclass | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
index 1be02bbea3c..e72676d0656 100644
--- a/eclass/waf-utils.eclass
+++ b/eclass/waf-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: waf-utils.eclass
@@ -138,8 +138,9 @@ waf-utils_src_install() {
export PYTHONHASHSEED=1
- echo "\"${WAF_BINARY}\" --jobs=1 --destdir=\"${D}\" ${*} install"
- "${WAF_BINARY}" --jobs=1 --destdir="${D}" "${@}" install || die "Make
install failed"
+ local jobs="--jobs=$(makeopts_jobs)"
+ echo "\"${WAF_BINARY}\" ${jobs} --destdir=\"${D}\" ${*} install"
+ "${WAF_BINARY}" ${jobs} --destdir="${D}" "${@}" install || die "Make
install failed"
# Manual document installation
einstalldocs
--
2.39.0
[gentoo-dev] Last rites: app-admin/bastille
# Mike Gilbert (2023-01-28) # No upstream releases since 2008. # No Gentoo maintainer since 2009. # Installs files in the wrong places (bug #455542) # and with the wrong mode (bug #892325). # Removal on 2023-02-27. app-admin/bastille
Re: [gentoo-dev] [PATCH 1/1] linux-info.eclass: Add /proc/config.gz as a valid src of CONFIG_* settings
On Sun, Jan 15, 2023 at 12:40 PM Mike Pagano wrote: > > In the event that the linux src tree does not have > a valid .config, check for /proc/config.gz > > Bug: https://bugs.gentoo.org/890720 I think this is the wrong place to "fix" bug 890720. We already have a linux_config_exists function. This change would make that function redundant and removes the ability to check for only a valid .config in the kernel build directory. I think the check_config_extra function should be updated to not call require_configured_kernel.
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Promote tc-env_build to a non-internal function
On Mon, Jan 2, 2023 at 5:34 PM James Le Cuirot wrote: > > It's generally useful and already directly used by three packages. I > need to use it to fix cross-compiling of LLVM. Sounds good to me.
[gentoo-dev] [PATCH] acct-user.eclass: always fix homedir permissions in pkg_preinst
Closes: https://bugs.gentoo.org/886147
Closes: https://github.com/gentoo/gentoo/pull/28744
Signed-off-by: Mike Gilbert
---
eclass/acct-user.eclass | 51 -
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index a37e12121f8..14fda76ced7 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -339,36 +339,35 @@ acct-user_pkg_preinst() {
if egetent passwd "${ACCT_USER_NAME}" >/dev/null; then
elog "User ${ACCT_USER_NAME} already exists"
- return
- fi
-
- local groups=( ${_ACCT_USER_GROUPS} )
- local aux_groups=${groups[*]:1}
- local opts=(
- --system
- --no-create-home
- --no-user-group
- --comment "${_ACCT_USER_COMMENT}"
- --home-dir "${_ACCT_USER_HOME}"
- --shell "${_ACCT_USER_SHELL}"
- --gid "${groups[0]}"
- --groups "${aux_groups// /,}"
- )
+ else
+ local groups=( ${_ACCT_USER_GROUPS} )
+ local aux_groups=${groups[*]:1}
+ local opts=(
+ --system
+ --no-create-home
+ --no-user-group
+ --comment "${_ACCT_USER_COMMENT}"
+ --home-dir "${_ACCT_USER_HOME}"
+ --shell "${_ACCT_USER_SHELL}"
+ --gid "${groups[0]}"
+ --groups "${aux_groups// /,}"
+ )
+
+ if [[ ${_ACCT_USER_ID} -ne -1 ]] &&
+ ! egetent passwd "${_ACCT_USER_ID}" >/dev/null
+ then
+ opts+=( --uid "${_ACCT_USER_ID}" )
+ fi
- if [[ ${_ACCT_USER_ID} -ne -1 ]] &&
- ! egetent passwd "${_ACCT_USER_ID}" >/dev/null
- then
- opts+=( --uid "${_ACCT_USER_ID}" )
- fi
+ if [[ -n ${ROOT} ]]; then
+ opts+=( --prefix "${ROOT}" )
+ fi
- if [[ -n ${ROOT} ]]; then
- opts+=( --prefix "${ROOT}" )
+ elog "Adding user ${ACCT_USER_NAME}"
+ useradd "${opts[@]}" "${ACCT_USER_NAME}" || die
+ _ACCT_USER_ADDED=1
fi
- elog "Adding user ${ACCT_USER_NAME}"
- useradd "${opts[@]}" "${ACCT_USER_NAME}" || die
- _ACCT_USER_ADDED=1
-
if [[ ${_ACCT_USER_HOME} != /dev/null ]]; then
# default ownership to user:group
if [[ -z ${_ACCT_USER_HOME_OWNER} ]]; then
--
2.39.0
Re: [gentoo-dev] [PATCH] unpacker.eclass: support >=app-arch/xz-utils-5.4.0 for lzip decompression
On Wed, Dec 14, 2022 at 6:40 AM Ulrich Mueller wrote: > > > On Wed, 14 Dec 2022, Sam James wrote: > > > *.lz) > > - d="|| ( app-arch/plzip app-arch/pdlzip app-arch/lzip > > )" ;; > > + d=" > > + || ( > > + >=app-arch/xz-utils-5.4.0 > > + app-arch/plzip > > + app-arch/pdlzip > > + app-arch/lzip > > + ) > > + " > > + ;; > > Shouldn't all consumers with a dependency on lzip be revbumped? > Otherwise emerge --depclean (in the default configuration) won't drop > lzip. That seems like an extreme solution to a problem nobody really cares about.
Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
On Wed, Dec 7, 2022 at 4:24 AM James Le Cuirot wrote:
> The new eclasses also skip the operation if you are root. As that bug report
> says, running a prefixed system as root is probably unsupported. I was doing
> this as root into a ROOTed prefix though, which is slightly different. Should
> we also skip the operation if EPREFIX non-empty? I'll think about it.
I would be in favor of skipping adding users/groups if EPREFIX is
non-empty, at least as a temporary solution.
If someone presents a use case where adding users to
${EROOT}/etc/passwd makes sense, we can revisit it then.
Re: [gentoo-dev] [PATCH 3/4] user-info.eclass: Fix for when building in a rooted prefix (EROOT)
On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot wrote:
>
> Users are largely irrelevant for prefix, but we still don't want the
> build to break.
>
> Signed-off-by: James Le Cuirot
> ---
> eclass/user-info.eclass | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
> index 5550e4f08eeb..1339e36634a8 100644
> --- a/eclass/user-info.eclass
> +++ b/eclass/user-info.eclass
> @@ -48,7 +48,7 @@ egetent() {
> fi
>
> # Handle different ROOT
> - [[ -n ${ROOT} ]] && opts+=( -R "${ROOT}" )
> + [[ -n ${ROOT} ]] && opts+=( -R "${EROOT}" )
Another case where the [[ -n ${ROOT} ]] should probably be changed to
[[ -n ${EROOT} ]] if you actually want this to be prefix-aware.
Re: [gentoo-dev] [PATCH 4/4] user.eclass: Fix for when building in a rooted prefix (EROOT)
On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot wrote: > > Users are largely irrelevant for prefix, but we still don't want the > build to break. > > I left the home and shell related bits alone, as it's less clear whether > these should be prefixed or not. Obviously /dev/null should not be. It's > slightly academic anyway, as nothing in the main repo uses this eclass > any more. I just deleted user.eclass, so you can probably drop this patch. :-)
Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot wrote:
>
> Groups are largely irrelevant for prefix, but we still don't want the
> build to break.
>
> Signed-off-by: James Le Cuirot
> ---
> eclass/acct-group.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> index 590a2f20ed8e..ada5fe386693 100644
> --- a/eclass/acct-group.eclass
> +++ b/eclass/acct-group.eclass
> @@ -176,7 +176,7 @@ acct-group_pkg_preinst() {
> fi
>
> if [[ -n ${ROOT} ]]; then
You should probably change this to [[ -n ${EROOT} ]]. Same goes for
acct-user.eclass.
Also see bug 779181; I'm not sure updating ${EROOT}/etc/group and
${EROOT}/etc/passwd makes any sense at all.
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On Sat, Dec 3, 2022 at 2:09 AM Michał Górny wrote: > > Hi, > > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug > states with a simple NEW state. Why? > > 1. Only a handful of developers actually uses these two statuses > in a meaningful way. > > 2. Some users are confused and demotivated by having their bugs stay > UNCONFIRMED for a long time. I think I could be counted among the devs who at least try to use the two statuses. If I stumble upon bugs that I have run into myself, I will flip them from UNCONFIRMED to CONFIRMED. On the opposite end, I occasionally downgrade bugs from CONFIRMED to UNCONFIRMED if they are particularly strange looking and were filed by a script (tinderbox). Anyway, if you decide to make the change, please ensure that it doesn't generate a bunch of pointless bugmail. I have noticed that some devs will replace obsolete values in Product/Component without making any other meaningful changes to the bug. Let's avoid that situation if possible here.
Re: [gentoo-dev] [PATCH] linux-info.eclass: getfilevar: pass 'need-compiler=' to make
On Tue, Nov 29, 2022 at 5:14 PM James Le Cuirot wrote:
>
> On Tue, 2022-11-29 at 13:55 -0500, Mike Gilbert wrote:
> > This avoids some unnecessary Makefile logic and gives a nice speed up.
> >
> > Before the change, linux-info_pkg_setup takes 11 to 15 seconds on my
> > AMD Phenom II. After, it takes 3 to 4 seconds.
> >
> > Signed-off-by: Mike Gilbert
> > ---
> > eclass/linux-info.eclass | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> > index fc125b0d751..3e64cb9457a 100644
> > --- a/eclass/linux-info.eclass
> > +++ b/eclass/linux-info.eclass
> > @@ -238,7 +238,9 @@ getfilevar() {
> > # Pass dot-config=0 to avoid the config check in kernels
> > prior to 5.4.
> > [[ ${EAPI:-0} == [0123] ]] && nonfatal() { "$@"; }
> > echo -e "e:\\n\\t@echo \$(${1})\\ninclude ${basefname}" | \
> > - nonfatal emake -C "${basedname}" --no-print-directory
> > M="${T}" dot-config=0 need-config= ${BUILD_FIXES} -s -f - 2>/dev/null
> > + nonfatal emake -C "${basedname}" --no-print-directory
> > M="${T}" \
> > + dot-config=0 need-config= need-compiler= \
> > + ${BUILD_FIXES} -s -f - 2>/dev/null
> >
> > ARCH=${myARCH}
> > fi
>
> I'm confused. Breaking up the line makes it faster?
The change is stated in the email subject.
[gentoo-dev] [PATCH] linux-info.eclass: getfilevar: pass 'need-compiler=' to make
This avoids some unnecessary Makefile logic and gives a nice speed up.
Before the change, linux-info_pkg_setup takes 11 to 15 seconds on my
AMD Phenom II. After, it takes 3 to 4 seconds.
Signed-off-by: Mike Gilbert
---
eclass/linux-info.eclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index fc125b0d751..3e64cb9457a 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -238,7 +238,9 @@ getfilevar() {
# Pass dot-config=0 to avoid the config check in kernels prior
to 5.4.
[[ ${EAPI:-0} == [0123] ]] && nonfatal() { "$@"; }
echo -e "e:\\n\\t@echo \$(${1})\\ninclude ${basefname}" | \
- nonfatal emake -C "${basedname}" --no-print-directory
M="${T}" dot-config=0 need-config= ${BUILD_FIXES} -s -f - 2>/dev/null
+ nonfatal emake -C "${basedname}" --no-print-directory
M="${T}" \
+ dot-config=0 need-config= need-compiler= \
+ ${BUILD_FIXES} -s -f - 2>/dev/null
ARCH=${myARCH}
fi
--
2.38.1
Re: [gentoo-portage-dev] sys-kernel/vanilla-sources not supported any more?
On Fri, Nov 25, 2022 at 5:50 AM Joakim Tjernlund wrote: > > I have noticed sys-kernel/vanilla-sources lagging behind for a while now and > I wonder if this pkg is obsolete? I think you sent this message to the wrong place. This list is for discussion of Portage development, not packages in the gentoo repository.
Re: [gentoo-portage-dev] Fixing EAPI 8 --enable-static once and for all
On Sat, Nov 19, 2022 at 3:33 AM Ulrich Mueller wrote: > > > On Sat, 19 Nov 2022, David Seifert wrote: > > > With this extensive analysis, I believe this patch to be safe. > > Still looks like an incompatible change, so it will need an EAPI bump. > > EAPI 9 feature bug is here: https://bugs.gentoo.org/815169 I support this patch to fix Portage, regardless of what PMS says. Coding to the spec doesn't make sense if the spec is broken.
[gentoo-dev] [PATCH] 2022-11-19-tmpfiles-clean: new item
Signed-off-by: Mike Gilbert --- .../2022-11-19-tmpfiles-clean.en.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt diff --git a/2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt b/2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt new file mode 100644 index 000..8e17e2a --- /dev/null +++ b/2022-11-19-tmpfiles-clean/2022-11-19-tmpfiles-clean.en.txt @@ -0,0 +1,19 @@ +Title: systemd-tmpfiles --clean enabled by default +Author: Mike Gilbert +Posted: 2022-11-19 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/systemd-utils[tmpfiles] + +Starting with sys-apps/systemd-utils-251.8-r1, a script is installed in +/etc/cron.daily to run "systemd-tmpfiles --clean" once per day. This +will remove stale temp files based on settings specified in tmpfiles.d. + +This change is meant to mimic the behavior of +systemd-tmpfiles-clean.timer from systemd on systems running OpenRC. + +If you wish to opt-out, take any of the following actions: + +1. Comment out the command in /etc/cron.daily/systemd-tmpfiles-clean, or +2. Add /etc/cron.daily/systemd-tmpfiles-clean to INSTALL_MASK, or +3. Disable or remove the cron daemon on your system. -- 2.38.1
Re: [gentoo-dev] Re: Last rites: user.eclass
On Wed, Oct 19, 2022 at 3:08 PM Martin Vaeth wrote: > > Mike Gilbert wrote: > > user.eclass has been deprecated for two years. In the gentoo repo, it > > is currently only used by acct-group.eclass and acct-user.eclass > > It is needed for ebuilds in non-gentoo repositories which cannot > reserve a fixed number for users and groups. Such ebuilds should be converted into acct-user and acct-group packages instead. If you set ACCT_USER_ID=-1 or ACCT_GROUP_ID=-1, they will pick an available UID/GID upon installation.
[gentoo-dev] Last rites: user.eclass
user.eclass has been deprecated for two years. In the gentoo repo, it is currently only used by acct-group.eclass and acct-user.eclass, and a patchset is currently under review remedy that [1]. Planned removal is in 30 days on 2022-11-18. [1] https://github.com/gentoo/gentoo/pull/27825
Re: [gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86
On Tue, Oct 18, 2022 at 12:47 PM Ulrich Mueller wrote: > > > On Tue, 18 Oct 2022, David Seifert wrote: > > > What if I want to build Gentoo on an old AMD Thunderbird which has > > neither SSE1 nor the more important SSE2? > > The -mfpmath=sse option is a no-op if the CPU doesn't support SSE, > i.e. it will use 387 arithmetics nevertheless. I don't really see an "effective" way to deploy this via profiles on x86. We could add it to the default CFLAGS setting in profiles/arch/x86/make.defaults. However, we also default to -march=i686 there, and that doesn't support SSE or SSE2. Also, the entire CFLAGS variable is likely to be overridden by the CFLAGS setting in /etc/make.conf. The CFLAGS_x86 profile variable is only used by the multilib_toolchain_setup function in multilib.eclass. In other words, it only affects ebuilds that utilize the multilib eclasses to build libraries for multiple ABIs. That covers all 32-bit libraries on amd64, but doesn't cover all packages on x86.
Re: [gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86
On Tue, Oct 18, 2022 at 5:56 AM David Seifert wrote: > > On Tue, 2022-10-18 at 10:14 +0200, Ulrich Mueller wrote: > > > > > > > On Tue, 18 Oct 2022, Mike Gilbert wrote: > > > > > Reference: https://gcc.gnu.org/wiki/x87note > > > > Which says: > > > > > ... the amount of worst-case error that could possibly happen using > > > the x87 (with any amount of intermediate rounding) is at worst the > > > same as true 64 or 32 bit arithmetic, and in practice is almost > > > always > > > better. > > > > and: > > > > > Note, however, that this greater repeatability comes at the cost of > > > lost precision (i.e. SSE always gets the same precision because it > > > always takes the equivalent of the x87's worst case: a forced round > > > down at each step). > > > > So, it comes with a price, and I wonder if we shouldn't leave that > > choice to the user, and go with the upstream GCC default? > > > > > -CFLAGS_x86="-m32" > > > +CFLAGS_x86="-m32 -mfpmath=sse" > > -mfpmath=sse is already the default on amd64. I have amended the first paragraph to make this more clear: GCC uses x87 floating point instructions when building 32-bit x86 code by default. When building 64-bit code, SSE2 instructions are used instead.
Re: [gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86
On Tue, Oct 18, 2022 at 9:37 AM David Seifert wrote: > > On Tue, 2022-10-18 at 13:40 +0200, Ulrich Mueller wrote: > > > > > > > On Tue, 18 Oct 2022, David Seifert wrote: > > > > > > > -CFLAGS_x86="-m32" > > > > > +CFLAGS_x86="-m32 -mfpmath=sse" > > > > > -mfpmath=sse is already the default on amd64. > > > > I see. This change makes sense then. > > > > What about profiles/arch/x86 though? IIUC we'll end up with an > > inconsistency between x86 and multilib amd64. > > > > Ulrich > > What if I want to build Gentoo on an old AMD Thunderbird which has > neither SSE1 nor the more important SSE2? Right. On amd64 CPU always supports SSE2, so -mfpmath=sse will always work there. On x86, we need to consider a more diverse set of supported instructions.
[gentoo-dev] [PATCH] profiles/arch/amd64: add "-mfpmath=sse" to CFLAGS_x86
GCC uses x87 floating point instructions when building 32-bit x86 code by default. This is true even for x86-64 multilib. Using the x87 floating point unit can lead to strange behavior when calculating intermediate values for single and double precision floats. It uses 80 bits for all calculations, which is larger than the 32 or 64 bits specified for floats and doubles. Using the SSE2 instructions available on x86-64 for floating point arithmetic leads to more consistent behavior, and is usually faster. Reference: https://gcc.gnu.org/wiki/x87note Signed-off-by: Mike Gilbert --- profiles/arch/amd64/make.defaults | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/profiles/arch/amd64/make.defaults b/profiles/arch/amd64/make.defaults index 0c05dec124e..e7e18ff6a91 100644 --- a/profiles/arch/amd64/make.defaults +++ b/profiles/arch/amd64/make.defaults @@ -1,4 +1,4 @@ -# Copyright 1999-2021 Gentoo Authors +# Copyright 1999-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 ARCH="amd64" @@ -28,7 +28,7 @@ LDFLAGS_amd64="-m elf_x86_64" CHOST_amd64="x86_64-pc-linux-gnu" # 32bit specific settings. -CFLAGS_x86="-m32" +CFLAGS_x86="-m32 -mfpmath=sse" LDFLAGS_x86="-m elf_i386" CHOST_x86="i686-pc-linux-gnu" -- 2.37.3
Re: [gentoo-dev] [PATCH 1/2] profiles/profiles.desc: add systemd/selinux/merged-usr subprofiles
On Wed, Oct 12, 2022 at 10:03 AM Kenton Groombridge wrote: > > Signed-off-by: Kenton Groombridge > --- > profiles/profiles.desc | 3 +++ > 1 file changed, 3 insertions(+) You should reverse the order of these commits: add the profile directories first, and then add them to profiles.desc.
[gentoo-dev] [PATCH] profiles: move merged-usr profiles from dev to stable
Signed-off-by: Mike Gilbert --- profiles/profiles.desc | 50 +- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/profiles/profiles.desc b/profiles/profiles.desc index 5702a9dc7c4..58abd888bbe 100644 --- a/profiles/profiles.desc +++ b/profiles/profiles.desc @@ -30,12 +30,12 @@ amd64 default/linux/amd64/17.1/hardened/selinux stable amd64 default/linux/amd64/17.1/desktop stable amd64 default/linux/amd64/17.1/desktop/gnome stable amd64 default/linux/amd64/17.1/desktop/gnome/systemd stable -amd64 default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr dev +amd64 default/linux/amd64/17.1/desktop/gnome/systemd/merged-usr stable amd64 default/linux/amd64/17.1/desktop/plasma stable amd64 default/linux/amd64/17.1/desktop/plasma/systemd stable -amd64 default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr dev +amd64 default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr stable amd64 default/linux/amd64/17.1/desktop/systemd stable -amd64 default/linux/amd64/17.1/desktop/systemd/merged-usr dev +amd64 default/linux/amd64/17.1/desktop/systemd/merged-usr stable amd64 default/linux/amd64/17.1/developer exp amd64 default/linux/amd64/17.1/no-multilib stable amd64 default/linux/amd64/17.1/no-multilib/hardened stable @@ -44,7 +44,7 @@ amd64 default/linux/amd64/17.1/no-multilib/systemd dev amd64 default/linux/amd64/17.1/no-multilib/systemd/merged-usr dev amd64 default/linux/amd64/17.1/no-multilib/systemd/selinux exp amd64 default/linux/amd64/17.1/systemd stable -amd64 default/linux/amd64/17.1/systemd/merged-usr dev +amd64 default/linux/amd64/17.1/systemd/merged-usr stable amd64 default/linux/amd64/17.1/systemd/selinux exp amd64 default/linux/amd64/17.1/clang exp amd64 default/linux/amd64/17.1/systemd/clang exp @@ -130,15 +130,15 @@ arm64 default/linux/arm64/17.0/hardened/selinux dev arm64 default/linux/arm64/17.0/desktop stable arm64 default/linux/arm64/17.0/desktop/gnome stable arm64 default/linux/arm64/17.0/desktop/gnome/systemd stable -arm64 default/linux/arm64/17.0/desktop/gnome/systemd/merged-usr dev +arm64 default/linux/arm64/17.0/desktop/gnome/systemd/merged-usr stable arm64 default/linux/arm64/17.0/desktop/plasma stable arm64 default/linux/arm64/17.0/desktop/plasma/systemd stable -arm64 default/linux/arm64/17.0/desktop/plasma/systemd/merged-usr dev +arm64 default/linux/arm64/17.0/desktop/plasma/systemd/merged-usr stable arm64 default/linux/arm64/17.0/desktop/systemd stable -arm64 default/linux/arm64/17.0/desktop/systemd/merged-usr dev +arm64 default/linux/arm64/17.0/desktop/systemd/merged-usr stable arm64 default/linux/arm64/17.0/developer exp arm64 default/linux/arm64/17.0/systemd stable -arm64 default/linux/arm64/17.0/systemd/merged-usr dev +arm64 default/linux/arm64/17.0/systemd/merged-usr stable arm64 default/linux/arm64/17.0/systemd/selinux exp @@ -162,7 +162,7 @@ ia64default/linux/ia64/17.0 stable ia64 default/linux/ia64/17.0/desktop stable ia64 default/linux/ia64/17.0/desktop/gnome stable ia64 default/linux/ia64/17.0/desktop/gnome/systemd stable -ia64 default/linux/ia64/17.0/desktop/gnome/systemd/merged-usr dev +ia64 default/linux/ia64/17.0/desktop/gnome/systemd/merged-usr stable ia64 default/linux/ia64/17.0/developer exp ia64 default/linux/ia64/17.0/systemd exp ia64 default/linux/ia64/17.0/systemd/merged-usr exp @@ -216,9 +216,9 @@ ppc default/linux/ppc/17.0
[gentoo-dev] [PATCH] 2022-12-01-systemd-usrmerge: add news item
Signed-off-by: Mike Gilbert --- .../2022-12-01-systemd-usrmerge.en.txt| 35 +++ 1 file changed, 35 insertions(+) create mode 100644 2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt diff --git a/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt b/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt new file mode 100644 index 000..19849bf --- /dev/null +++ b/2022-12-01-systemd-usrmerge/2022-12-01-systemd-usrmerge.en.txt @@ -0,0 +1,35 @@ +Title: /usr merge for systemd users +Author: Mike Gilbert +Posted: 2022-12-01 +Revision: 1 +News-Item-Format 2.0 +Display-If-Installed: sys-apps/systemd + +In the latter half of 2023, systemd will drop support for +split-usr/unmerged-usr systems [1]. All Gentoo systems running systemd +will need to be migrated to merged-usr. + +Migrating to merged-usr will move all data from /bin, /sbin, and /lib +into the /usr/bin and /usr/lib directories. The directories in / are +replaced with symlinks. + +To facilitate this, a new set of sub-profiles has been created, and a +script is availble to perform the actual migration. + +To migrate a system to merged-usr, follow this procedure: + +1. Ensure your system backups are up to date. + +2. Install sys-apps/merge-usr. + +3. Run the merge-usr script. The --dryrun option may be used to + check for error conditions before running the script for real. + +4. Switch to a merged-usr profile. + eg. eselect profile set default/linux/amd64/17.1/systemd/merged-usr + +5. Run emerge with the --newuse or --changed-use option to rebuild + any packages that have a "split-usr" USE flag. + eg. emerge -uDN @world + +[1] https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html -- 2.37.3
Re: [gentoo-dev] RFC: check A's size in go-module.eclass
On Tue, Oct 11, 2022 at 6:06 AM Florian Schmaus wrote: > > > This is a first suggestion in an effort to reach a compromise that > allows EGO_SUM to be un-depracted. > > I have decided to check the size of A, instead of counting the entries > in EGO_SUM, because that seemed more sensible given that as A's size > caused functional issues in the past (bug #719202 [1]). > > 1: https://bugs.gentoo.org/719202 I would suggest we simply add a comment to warn ebuild developers that some unknown large number of modules may cause build failures. If/when the ebuild starts to fail, they will know they went over the limit and will have to start collapsing files into tarballs.
Re: [gentoo-dev] [PATCH] go-module.eclass: ensure that A is less than 112 KiB
On Tue, Oct 11, 2022 at 6:06 AM Florian Schmaus wrote: > > Packages with a large number of EGO_SUM entries, i.e., many thousands, > cause SRC_URI, and in turn A, to become quite large. Prevent issues that > are caused by large environment variables, e.g., execve() errors (see > bug #719203), by ensuring that A stays below a reasonable size. This code will never be reached: if the A environment variable is too large, portage will fail to execute /bin/bash, and the phase function will not be executed. If you want to add an error for this, I think it would require changes to Portage's python code.
[gentoo-dev] [PATCH 2/3] systemd.eclass: add systemd_get_sleepdir
Closes: https://bugs.gentoo.org/873172
Signed-off-by: Mike Gilbert
---
eclass/systemd.eclass | 8
1 file changed, 8 insertions(+)
diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 9e9a9b0cf20..fbed387e0ca 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -132,6 +132,14 @@ systemd_get_systempresetdir() {
_systemd_get_dir systemdsystempresetdir /lib/systemd/system-preset
}
+# @FUNCTION: systemd_get_sleepdir
+# @DESCRIPTION:
+# Output the path for the system sleep directory.
+systemd_get_sleepdir() {
+ debug-print-function ${FUNCNAME} "${@}"
+ _systemd_get_dir systemdsleepdir /lib/systemd/system-sleep
+}
+
# @FUNCTION: systemd_dounit
# @USAGE: ...
# @DESCRIPTION:
--
2.37.3
[gentoo-dev] [PATCH 3/3] eclass/tests: add systemd tests
Signed-off-by: Mike Gilbert
---
eclass/tests/systemd.sh | 50 +
1 file changed, 50 insertions(+)
create mode 100755 eclass/tests/systemd.sh
diff --git a/eclass/tests/systemd.sh b/eclass/tests/systemd.sh
new file mode 100755
index 000..f870df4b7a1
--- /dev/null
+++ b/eclass/tests/systemd.sh
@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+# Copyright 2022 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+source tests-common.sh || exit
+
+inherit systemd
+
+test_system_dir() {
+ local exp1="${EPREFIX}$1"
+ local exp2="${EPREFIX}/usr$1"
+ shift
+ tbegin "$@"
+ local act=$("$@")
+ [[ ${act} == ${exp1} || ${act} == ${exp2} ]]
+ tend $?
+}
+
+test_user_dir() {
+ local exp="${EPREFIX}$1"
+ shift
+ tbegin "$@"
+ local act=$("$@")
+ [[ ${act} == ${exp} ]]
+ tend $?
+}
+
+test_systemd_unprefix() {
+ local exp=$1
+ local EPREFIX=$2
+ shift 2
+ tbegin "EPREFIX=${EPREFIX} _systemd_unprefix $@"
+ [[ "$(_systemd_unprefix "$@")" == "${exp}" ]]
+ tend $?
+}
+
+test_system_dir /lib/systemd/system systemd_get_systemunitdir
+test_system_dir /lib/systemd systemd_get_utildir
+test_system_dir /lib/systemd/system-generators systemd_get_systemgeneratordir
+test_system_dir /lib/systemd/system-preset systemd_get_systempresetdir
+test_system_dir /lib/systemd/system-sleep systemd_get_sleepdir
+
+test_user_dir /usr/lib/systemd/user systemd_get_userunitdir
+
+test_systemd_unprefix /lib/systemd /prefix echo /prefix/lib/systemd
+test_systemd_unprefix /lib/systemd '' echo /lib/systemd
+test_systemd_unprefix /lib/systemd '/*' echo '/*/lib/systemd'
+
+texit
--
2.37.3
[gentoo-dev] [PATCH 1/3] systemd.eclass: rework EPREFIX handling
Instead of adding a private function to get the unprefixed version of
every path, use a new "_systemd_unprefix" helper function.
Signed-off-by: Mike Gilbert
---
eclass/systemd.eclass | 69 ---
1 file changed, 19 insertions(+), 50 deletions(-)
diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 7731bede094..9e9a9b0cf20 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -1,4 +1,4 @@
-# Copyright 2011-2021 Gentoo Authors
+# Copyright 2011-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: systemd.eclass
@@ -53,20 +53,21 @@ _systemd_get_dir() {
if $(tc-getPKG_CONFIG) --exists systemd; then
d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
- d=${d#${EPREFIX}}
else
- d=${fallback}
+ d="${EPREFIX}${fallback}"
fi
echo "${d}"
}
-# @FUNCTION: _systemd_get_systemunitdir
+# @FUNCTION: _systemd_unprefix
+# @USAGE:
# @INTERNAL
# @DESCRIPTION:
-# Get unprefixed unitdir.
-_systemd_get_systemunitdir() {
- _systemd_get_dir systemdsystemunitdir /lib/systemd/system
+# Calls the specified function and removes ${EPREFIX} from the result.
+_systemd_unprefix() {
+ local d=$("${@}")
+ echo "${d#"${EPREFIX}"}"
}
# @FUNCTION: systemd_get_systemunitdir
@@ -77,7 +78,7 @@ _systemd_get_systemunitdir() {
systemd_get_systemunitdir() {
debug-print-function ${FUNCNAME} "${@}"
- echo "${EPREFIX}$(_systemd_get_systemunitdir)"
+ _systemd_get_dir systemdsystemunitdir /lib/systemd/system
}
# @FUNCTION: systemd_get_unitdir
@@ -89,14 +90,6 @@ systemd_get_unitdir() {
systemd_get_systemunitdir
}
-# @FUNCTION: _systemd_get_userunitdir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed userunitdir.
-_systemd_get_userunitdir() {
- _systemd_get_dir systemduserunitdir /usr/lib/systemd/user
-}
-
# @FUNCTION: systemd_get_userunitdir
# @DESCRIPTION:
# Output the path for the systemd user unit directory (not including
@@ -105,15 +98,7 @@ _systemd_get_userunitdir() {
systemd_get_userunitdir() {
debug-print-function ${FUNCNAME} "${@}"
- echo "${EPREFIX}$(_systemd_get_userunitdir)"
-}
-
-# @FUNCTION: _systemd_get_utildir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed utildir.
-_systemd_get_utildir() {
- _systemd_get_dir systemdutildir /lib/systemd
+ _systemd_get_dir systemduserunitdir /usr/lib/systemd/user
}
# @FUNCTION: systemd_get_utildir
@@ -124,15 +109,7 @@ _systemd_get_utildir() {
systemd_get_utildir() {
debug-print-function ${FUNCNAME} "${@}"
- echo "${EPREFIX}$(_systemd_get_utildir)"
-}
-
-# @FUNCTION: _systemd_get_systemgeneratordir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed systemgeneratordir.
-_systemd_get_systemgeneratordir() {
- _systemd_get_dir systemdsystemgeneratordir
/lib/systemd/system-generators
+ _systemd_get_dir systemdutildir /lib/systemd
}
# @FUNCTION: systemd_get_systemgeneratordir
@@ -142,15 +119,7 @@ _systemd_get_systemgeneratordir() {
systemd_get_systemgeneratordir() {
debug-print-function ${FUNCNAME} "${@}"
- echo "${EPREFIX}$(_systemd_get_systemgeneratordir)"
-}
-
-# @FUNCTION: _systemd_get_systempresetdir
-# @INTERNAL
-# @DESCRIPTION:
-# Get unprefixed systempresetdir.
-_systemd_get_systempresetdir() {
- _systemd_get_dir systemdsystempresetdir /lib/systemd/system-preset
+ _systemd_get_dir systemdsystemgeneratordir
/lib/systemd/system-generators
}
# @FUNCTION: systemd_get_systempresetdir
@@ -160,7 +129,7 @@ _systemd_get_systempresetdir() {
systemd_get_systempresetdir() {
debug-print-function ${FUNCNAME} "${@}"
- echo "${EPREFIX}$(_systemd_get_systempresetdir)"
+ _systemd_get_dir systemdsystempresetdir /lib/systemd/system-preset
}
# @FUNCTION: systemd_dounit
@@ -172,7 +141,7 @@ systemd_dounit() {
(
insopts -m 0644
- insinto "$(_systemd_get_systemunitdir)"
+ insinto "$(_systemd_unprefix systemd_get_systemunitdir)"
doins "${@}"
)
}
@@ -186,7 +155,7 @@ systemd_newunit() {
(
insopts -m 0644
- insinto "$(_systemd_get_systemunitdir)"
+ insinto "$(_systemd_unprefix systemd_get_systemunitdir)"
newins "${@}"
)
}
@@ -200,7 +169,7 @@ systemd_douserunit() {
(
insopts -m 0644
- insinto "$(_systemd_get_userunitdir)"
+ insinto "$(_systemd_unprefix systemd_get_userunitdir)"
doins "${@}"
)
}
@@ -215,7 +184,7 @@ systemd_newuseruni
[gentoo-dev] [PATCH 0/3] systemd.eclass improvements
A few improvements to systemd.eclass. Mike Gilbert (3): systemd.eclass: rework EPREFIX handling systemd.eclass: add systemd_get_sleepdir eclass/tests: add systemd tests eclass/systemd.eclass | 77 +++-- eclass/tests/systemd.sh | 50 ++ 2 files changed, 77 insertions(+), 50 deletions(-) create mode 100755 eclass/tests/systemd.sh -- 2.37.3
[gentoo-dev] Last rites: net-misc/netkit-bootpd
# Mike Gilbert (2022-10-05) # Implements the obsolete BOOTP protocol; use DHCP instead. # No activity upstream for over two decades. # Fails to build with -Werror=implicit-function-declaration (#875536). # Removal on 2022-11-04. net-misc/netkit-bootpd
[gentoo-dev] Last rites: app-portage/repoman
# Mike Gilbert (2022-09-12) # repoman is no longer maintained and has been removed from the portage # git repository. Please use dev-util/pkgcheck and dev-util/pkgdev instead. # Removal on 2022-11-11. Bug #835013. app-portage/repoman
[gentoo-dev] [PATCH] Convert 'apparmor' to a global USE flag
Signed-off-by: Mike Gilbert --- app-benchmarks/stress-ng/metadata.xml | 1 - app-containers/containerd/metadata.xml | 1 - app-containers/docker/metadata.xml | 3 --- app-containers/lxc/metadata.xml| 1 - app-containers/lxd/metadata.xml| 3 --- app-containers/podman/metadata.xml | 3 --- app-containers/runc/metadata.xml | 3 --- app-containers/snapd/metadata.xml | 3 --- app-emulation/libvirt/metadata.xml | 1 - media-libs/libextractor/metadata.xml | 1 - profiles/use.desc | 1 + sys-apps/dbus-broker/metadata.xml | 1 - sys-apps/systemd/metadata.xml | 1 - 13 files changed, 1 insertion(+), 22 deletions(-) diff --git a/app-benchmarks/stress-ng/metadata.xml b/app-benchmarks/stress-ng/metadata.xml index 70cc3234093..70bbe8858a5 100644 --- a/app-benchmarks/stress-ng/metadata.xml +++ b/app-benchmarks/stress-ng/metadata.xml @@ -14,7 +14,6 @@ and over 20 virtual memory stress tests. - Add support for AppArmor. https://github.com/ColinIanKing/stress-ng/issues diff --git a/app-containers/containerd/metadata.xml b/app-containers/containerd/metadata.xml index 5641ef37219..5d63e8606e9 100644 --- a/app-containers/containerd/metadata.xml +++ b/app-containers/containerd/metadata.xml @@ -17,7 +17,6 @@ Georgy Yakovlev - Support for AppArmor Support for BTRFS snapshot driver Support for Kubernetes CRI Support for device mapper snapshot driver diff --git a/app-containers/docker/metadata.xml b/app-containers/docker/metadata.xml index bc364de188b..5f163941881 100644 --- a/app-containers/docker/metadata.xml +++ b/app-containers/docker/metadata.xml @@ -21,9 +21,6 @@ Enables dependencies for the "aufs" graph driver, including necessary kernel flags. - - Enable AppArmor support. - Enables dependencies for the "btrfs" graph driver, including necessary kernel flags. diff --git a/app-containers/lxc/metadata.xml b/app-containers/lxc/metadata.xml index 8c08b596f2e..2d20f0346cc 100644 --- a/app-containers/lxc/metadata.xml +++ b/app-containers/lxc/metadata.xml @@ -10,7 +10,6 @@ Gentoo Virtualization Project -Enable AppArmor support Enable io_uring support, and use io_uring instead of epoll Build and install additional command line tools diff --git a/app-containers/lxd/metadata.xml b/app-containers/lxd/metadata.xml index a666d3414c4..dd209643cdb 100644 --- a/app-containers/lxd/metadata.xml +++ b/app-containers/lxd/metadata.xml @@ -9,9 +9,6 @@ virtualizat...@gentoo.org Gentoo Virtualization Project - -Enable AppArmor support - LXD is a modern, secure and powerful system container and virtual machine manager. diff --git a/app-containers/podman/metadata.xml b/app-containers/podman/metadata.xml index 11d7dc7603d..3a429ae4898 100644 --- a/app-containers/podman/metadata.xml +++ b/app-containers/podman/metadata.xml @@ -15,9 +15,6 @@ and volumes. - - Enable AppArmor support. - Enables dependencies for the "btrfs" graph driver, including necessary kernel flags. diff --git a/app-containers/runc/metadata.xml b/app-containers/runc/metadata.xml index d27ad6413b0..76423a90314 100644 --- a/app-containers/runc/metadata.xml +++ b/app-containers/runc/metadata.xml @@ -14,9 +14,6 @@ Georgy Yakovlev - - Enable AppArmor support. - Enable Kernel Memory Accounting. diff --git a/app-containers/snapd/metadata.xml b/app-containers/snapd/metadata.xml index 0109791c93f..730665fd01e 100644 --- a/app-containers/snapd/metadata.xml +++ b/app-containers/snapd/metadata.xml @@ -9,9 +9,6 @@ snapcore/snapd - - Enable AppArmor support. - Automatically disable application confinement if feature detection fails. diff --git a/app-emulation/libvirt/metadata.xml b/app-emulation/libvirt/metadata.xml index aa7a5f87067..9784c19f417 100644 --- a/app-emulation/libvirt/metadata.xml +++ b/app-emulation/libvirt/metadata.xml @@ -52,7 +52,6 @@ Support management of VirtualBox virtualisation (app-emulation/virtualbox) - Enable AppArmor support Enable dtrace support via dev-util/systemtap Allow LXC to use sys-fs/fuse for mountpoints
Re: [gentoo-dev] [PATCH 1/8] dist-kernel-utils.eclass: support EAPI 8
On Thu, Sep 8, 2022 at 1:38 PM Ulrich Mueller wrote:
>
> >>>>> On Thu, 08 Sep 2022, Mike Gilbert wrote:
>
> > @@ -18,7 +18,7 @@ case "${EAPI:-0}" in
> > 0|1|2|3|4|5|6)
> > die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> > ;;
> > - 7)
> > + 7|8)
> > ;;
> > *)
> > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
>
> While at it, maybe convert the conditional to the standard form in all
> these eclasses? Like this:
>
> case ${EAPI} in
> 7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> I'd also drop EAPI 5 where it is applicable.
Done. Check the PR for updates.
[gentoo-dev] [PATCH 8/8] sys-kernel/gentoo-kernel-bin: switch to EAPI 8
Signed-off-by: Mike Gilbert --- sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild | 2 +- sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild | 2 +- sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild | 2 +- sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild index da84e07f808..6fa6637df87 100644 --- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild +++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.10.142.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-install toolchain-funcs diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild index 0787e9b25ee..f81e1d1736a 100644 --- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild +++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.15.67.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-install toolchain-funcs diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild index 0432fc354ea..368d398ae20 100644 --- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild +++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.19.8.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-install toolchain-funcs diff --git a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild index b6c3ce9ca64..f69958baf0a 100644 --- a/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild +++ b/sys-kernel/gentoo-kernel-bin/gentoo-kernel-bin-5.4.212.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-install toolchain-funcs -- 2.37.3
[gentoo-dev] [PATCH 7/8] sys-kernel/gentoo-kernel: switch to EAPI 8
Signed-off-by: Mike Gilbert --- sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild | 2 +- sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild | 2 +- sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild | 2 +- sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild b/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild index 8cc3f580387..4824ab95a1f 100644 --- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild +++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.10.142.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build toolchain-funcs diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild index 64c99e19532..4ea02f952ba 100644 --- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild +++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.67.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build toolchain-funcs diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild b/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild index ca4fd408583..915ecbec450 100644 --- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild +++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build toolchain-funcs diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild b/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild index ffd40f039fd..5fa543cace3 100644 --- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild +++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.4.212.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build -- 2.37.3
[gentoo-dev] [PATCH 6/8] sys-kernel/vanilla-kernel: switch to EAPI 8
Signed-off-by: Mike Gilbert --- sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild | 2 +- sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild | 2 +- sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild | 2 +- sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild b/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild index 718e3ea8262..beb11365e70 100644 --- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild +++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.10.142.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build toolchain-funcs verify-sig diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild b/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild index 13b58c5c983..e9d460c7094 100644 --- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild +++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.15.67.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build toolchain-funcs verify-sig diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild b/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild index 1b962183c7b..410aa49eb43 100644 --- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild +++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.19.8.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build toolchain-funcs verify-sig diff --git a/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild index bffac796479..ae90752d5ab 100644 --- a/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild +++ b/sys-kernel/vanilla-kernel/vanilla-kernel-5.4.212.ebuild @@ -1,7 +1,7 @@ # Copyright 2020-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=7 +EAPI=8 inherit kernel-build verify-sig -- 2.37.3
[gentoo-dev] [PATCH 5/8] kernel-build.eclass: support EAPI 8
Signed-off-by: Mike Gilbert
---
eclass/kernel-build.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 750a8e873d9..43d46f94108 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -6,7 +6,7 @@
# Distribution Kernel Project
# @AUTHOR:
# Michał Górny
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
# @PROVIDES: kernel-install
# @BLURB: Build mechanics for Distribution Kernels
# @DESCRIPTION:
@@ -26,7 +26,7 @@ case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
- 7)
+ 7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
--
2.37.3
[gentoo-dev] [PATCH 4/8] savedconfig.eclass: support EAPI 8
Signed-off-by: Mike Gilbert
---
eclass/savedconfig.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index 20669c08b33..52286caee6c 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: savedconfig.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: common API for saving/restoring complex configuration files
# @DESCRIPTION:
# It is not uncommon to come across a package which has a very fine
@@ -35,7 +35,7 @@ inherit portability
IUSE="savedconfig"
case ${EAPI} in
- [5-7]) ;;
+ 5|6|7|8) ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
--
2.37.3
[gentoo-dev] [PATCH 3/8] portability.eclass: support EAPI 8
Signed-off-by: Mike Gilbert
---
eclass/portability.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/portability.eclass b/eclass/portability.eclass
index 8df8fcebc47..0ef6bd40c21 100644
--- a/eclass/portability.eclass
+++ b/eclass/portability.eclass
@@ -6,11 +6,11 @@
# base-sys...@gentoo.org
# @AUTHOR:
# Diego Pettenò
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: This eclass is created to avoid using non-portable GNUisms inside
ebuilds
case ${EAPI:-0} in
- [567]) ;;
+ 5|6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.37.3
[gentoo-dev] [PATCH 2/8] kernel-install.eclass: support EAPI 8
Signed-off-by: Mike Gilbert
---
eclass/kernel-install.eclass | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
index 8acf1ad1bc0..b7f9abe7bc9 100644
--- a/eclass/kernel-install.eclass
+++ b/eclass/kernel-install.eclass
@@ -6,7 +6,7 @@
# Distribution Kernel Project
# @AUTHOR:
# Michał Górny
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
# @PROVIDES: dist-kernel-utils
# @BLURB: Installation mechanics for Distribution Kernels
# @DESCRIPTION:
@@ -34,7 +34,7 @@ case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
- 7)
+ 7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
@@ -51,14 +51,18 @@ RESTRICT+="
arm? ( test )
"
-# install-DEPEND actually
# note: we need installkernel with initramfs support!
-RDEPEND="
+INSTALL_DEPEND="
|| (
sys-kernel/installkernel-gentoo
sys-kernel/installkernel-systemd-boot
)
initramfs? ( >=sys-kernel/dracut-049-r3 )"
+if [[ ${EAPI} == 7 ]]; then
+ RDEPEND="${INSTALL_DEPEND}"
+else
+ IDEPEND="${INSTALL_DEPEND}"
+fi
# needed by objtool that is installed along with the kernel and used
# to build external modules
# NB: linux-mod.eclass also adds this dep but it's cleaner to have
--
2.37.3
[gentoo-dev] [PATCH 1/8] dist-kernel-utils.eclass: support EAPI 8
Signed-off-by: Mike Gilbert
---
eclass/dist-kernel-utils.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/dist-kernel-utils.eclass b/eclass/dist-kernel-utils.eclass
index d192c31db27..649363ad3e4 100644
--- a/eclass/dist-kernel-utils.eclass
+++ b/eclass/dist-kernel-utils.eclass
@@ -6,7 +6,7 @@
# Distribution Kernel Project
# @AUTHOR:
# Michał Górny
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: Utility functions related to Distribution Kernels
# @DESCRIPTION:
# This eclass provides various utility functions related to Distribution
@@ -18,7 +18,7 @@ case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
- 7)
+ 7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
--
2.37.3
[gentoo-dev] [PATCH 0/8] Migrate dist-kernel packages to EAPI 8
This series adds support for EAPI 8 to relevant eclasses, and updates the latest version in each kernel branch to EAPI 8. The only significant change is in kernel-install.eclass where we populate IDEPEND instead of RDEPEND. PR: https://github.com/gentoo/gentoo/pull/27191 Mike Gilbert (8): dist-kernel-utils.eclass: support EAPI 8 kernel-install.eclass: support EAPI 8 portability.eclass: support EAPI 8 savedconfig.eclass: support EAPI 8 kernel-build.eclass: support EAPI 8 sys-kernel/vanilla-kernel: switch to EAPI 8 sys-kernel/gentoo-kernel: switch to EAPI 8 sys-kernel/gentoo-kernel-bin: switch to EAPI 8 eclass/dist-kernel-utils.eclass | 4 ++-- eclass/kernel-build.eclass | 4 ++-- eclass/kernel-install.eclass | 12 eclass/portability.eclass| 4 ++-- eclass/savedconfig.eclass| 6 +++--- .../gentoo-kernel-bin-5.10.142.ebuild| 2 +- .../gentoo-kernel-bin-5.15.67.ebuild | 2 +- .../gentoo-kernel-bin-5.19.8.ebuild | 2 +- .../gentoo-kernel-bin-5.4.212.ebuild | 2 +- .../gentoo-kernel/gentoo-kernel-5.10.142.ebuild | 2 +- .../gentoo-kernel/gentoo-kernel-5.15.67.ebuild | 2 +- sys-kernel/gentoo-kernel/gentoo-kernel-5.19.8.ebuild | 2 +- .../gentoo-kernel/gentoo-kernel-5.4.212.ebuild | 2 +- .../vanilla-kernel/vanilla-kernel-5.10.142.ebuild| 2 +- .../vanilla-kernel/vanilla-kernel-5.15.67.ebuild | 2 +- .../vanilla-kernel/vanilla-kernel-5.19.8.ebuild | 2 +- .../vanilla-kernel/vanilla-kernel-5.4.212.ebuild | 2 +- 17 files changed, 29 insertions(+), 25 deletions(-) -- 2.37.3
[gentoo-dev] Re: RFC: virtual/dbus
On Wed, Sep 7, 2022 at 11:56 AM Marek Szuba wrote: > > Dear everyone, > > I wonder if we should create a virtual package to allow our users - or > at least those who run systemd anyway - to choose between sys-apps/dbus > and sys-apps/dbus-broken as D-Bus implementation for their systems. The > usual "Gentoo is about choice" thing aside, there is now at least one, > security-related, problem with the former which can be worked around by > switching to the latter: https://github.com/systemd/systemd/issues/22737 > > WDYT? A virtual seems a bit pointless for the following reasons: 1. dbus and dbus-broker can be (and usually are) installed simultaneously. 2. dbus-broker[launcher] utilizes config files installed by dbus, and actually RDEPENDs on sys-apps/dbus for that reason. 3. Many client applications depend on sys-apps/dbus for libdbus. If you can think of some way to encourage users to install/enable dbus-broker, that seems like a good idea to me.
