Re: [gentoo-dev] [PATCH v2] verify-sig.eclass: avoid calling unpack on sig files
On Tue, May 21, 2024 at 11:38 PM Michał Górny wrote: > > On Tue, 2024-05-21 at 22:05 -0400, Mike Gilbert wrote: > > Signed-off-by: Mike Gilbert > > --- > > eclass/verify-sig.eclass | 10 +++--- > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass > > index b74ed78290aa..4d48c9ed8503 100644 > > --- a/eclass/verify-sig.eclass > > +++ b/eclass/verify-sig.eclass > > @@ -426,10 +426,14 @@ verify-sig_src_unpack() { > > verify-sig_verify_detached \ > > "${DISTDIR}/${f%.*}" "${DISTDIR}/${f}" > > done > > - fi > > > > - # finally, unpack the distfiles > > - default_src_unpack > > + # finally, unpack the distfiles > > + if [[ ${#distfiles[@]} -gt 0 ]]; then > > + unpack "${distfiles[@]}" > > + fi > > + else > > + default_src_unpack > > + fi > > } > > > > fi > > Please make a pull request or send a patch with more context. > As submitted, this patch is completely unreadable. Sure, I updated the commit message per ulm's comments, and opened a PR. https://github.com/gentoo/gentoo/pull/36776
Re: [gentoo-dev] [PATCH v2] verify-sig.eclass: avoid calling unpack on sig files
On Wed, May 22, 2024 at 1:53 AM Ulrich Mueller wrote: > Please provide an explanation what problem this patch fixes. > > Why is calling unpack on sig files bad? It should silently skip files > with unknown extensions. The main reason is that Portage does not *silently* skip unknown extensions in unpack. For example: >>> Unpacking freerdp-2.11.7.tar.gz.asc to >>> /x/portage/net-misc/freerdp-2.11.7/work unpack freerdp-2.11.7.tar.gz.asc: file format not recognized. Ignoring. The other reason would be the small/trivial efficiency gain; there is no point in calling unpack on a file it won't be able to process.
[gentoo-dev] [PATCH v2] verify-sig.eclass: avoid calling unpack on sig files
Signed-off-by: Mike Gilbert --- eclass/verify-sig.eclass | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass index b74ed78290aa..4d48c9ed8503 100644 --- a/eclass/verify-sig.eclass +++ b/eclass/verify-sig.eclass @@ -426,10 +426,14 @@ verify-sig_src_unpack() { verify-sig_verify_detached \ "${DISTDIR}/${f%.*}" "${DISTDIR}/${f}" done - fi - # finally, unpack the distfiles - default_src_unpack + # finally, unpack the distfiles + if [[ ${#distfiles[@]} -gt 0 ]]; then + unpack "${distfiles[@]}" + fi + else + default_src_unpack + fi } fi -- 2.45.1
[gentoo-dev] [PATCH] verify-sig.eclass: avoid calling unpack on sig files
Signed-off-by: Mike Gilbert --- eclass/verify-sig.eclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass index b74ed78290aa..b0f180fdb3ac 100644 --- a/eclass/verify-sig.eclass +++ b/eclass/verify-sig.eclass @@ -429,7 +429,9 @@ verify-sig_src_unpack() { fi # finally, unpack the distfiles - default_src_unpack + if [[ ${#distfiles[@]} -gt 0 ]]; then + unpack "${distfiles[@]}" + fi } fi -- 2.45.1
Re: [gentoo-dev] [PATCH 6/7] linux-info.eclass: respect eselect kernel setting in binpkgs
On Tue, May 14, 2024 at 7:59 AM Andrew Ammerlaan wrote: > Commit f51cd5b64c14ddfb83488a12d538c66a4a309376 resets kernel environment > variables when binpkgs are merged, this makes sense since we care about the > system that the binpkg will be installed on, not the system the binpkg was > built on. This introduced Bug 931213 as a side-effect, which will be fixed > in a separate commit to linux-mod-r1.eclass. In preparation of that, we > document > and rename the LINUX_INFO_BINARY_RESET to SKIP_KERNEL_BINPKG_ENV_RESET. > > However, commit f51cd5b64c14ddfb83488a12d538c66a4a309376 also makes binpkgs > always use the running kernel version. This behaviour is surprising and > confusing. In principle the 'eselect kernel' setting should still be respected > when binpkgs are used. Seems reasonable to me as the author of f51cd5b64c14ddfb83488a12d538c66a4a309376.
[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
Re: [gentoo-dev] [PATCH] linux-mod-r1.eclass: warn if KV does not match virtual/dist-kernel
On 1/30/24 06:07, Andrew Ammerlaan wrote: From 3a3a69379650af341fa318d8f2d1533885b52d0e Mon Sep 17 00:00:00 2001 From: Andrew Ammerlaan Date: Mon, 29 Jan 2024 10:58:11 +0100 Subject: [PATCH] linux-mod-r1.eclass: warn if KV does not match virtual/dist-kernel We have no mechanism to ensure that we build the kernel modules for the same kernel version as the version we will record in the virtual/dist-kernel subslot dependency. This does not fix this problem, but it does add a warning to ensure users are aware that, for example, built binpkgs are going to have wrong dependency metadata. Bug: https://bugs.gentoo.org/923025 Signed-off-by: Andrew Ammerlaan --- eclass/linux-mod-r1.eclass | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/eclass/linux-mod-r1.eclass b/eclass/linux-mod-r1.eclass index 67a4b64eb4815..8d384c2b30c88 100644 --- a/eclass/linux-mod-r1.eclass +++ b/eclass/linux-mod-r1.eclass @@ -1,4 +1,4 @@ -# Copyright 2023 Gentoo Authors +# Copyright 2023-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: linux-mod-r1.eclass @@ -650,6 +650,24 @@ _modules_prepare_kernel() { fi linux-info_pkg_setup + + if use dist-kernel && + ! has_version "~virtual/dist-kernel-${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}" + then + ewarn + ewarn "The kernel modules in ${CATEGORY}/${PN} are being built for" + ewarn "kernel version ${KV_FULL}. But this does not match the" + ewarn "installed version of virtual/dist-kernel." + ewarn + ewarn "If this is not intentional, the problem may be corrected by" + ewarn "using \"eselect kernel\" to set the default kernel version to" + ewarn "the same version as the installed version of virtual/dist-kernel." + ewarn + ewarn "If the distribution kernel is being downgraded, ensure that" + ewarn "virtual/dist-kernel is also downgraded to the same version" + ewarn "before rebuilding external kernel modules." + ewarn + fi } # @FUNCTION: _modules_prepare_sign LGTM -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
[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.
[gentoo-dev] Last rites: app-crypt/tpm-emulator
# Mike Pagano (2023-06-18) # Last upstream activity in 2018, EAPI 7. # See app-crypt/swtpm for an alternative. # Removal on 2023-07-18. Bug #768960, #794547. app-crypt/tpm-emulator
[gentoo-dev] Migration from linux-mod.eclass to linux-mod-r1.eclass
Hello, Thanks to the amazing work by Ionen I'd like to start the process to request all consumers of linux-mod.eclass to start migrating to linux-mod-r1.eclass. Tracker bug is up and I will start to add consumers. If anyone needs a hand with the migration I am happy to help. Details on linux-mod-r1.eclass can be found here[1] and the tracker bug can be found here[2]. [1] https://github.com/gentoo/gentoo/pull/31154/commits/e4b57b51b30fd348da8997aae6e4f651a0a132ce [2] https://bugs.gentoo.org/908692 Mike -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
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] [PATCH 1/1] linux-mod.eclass: Store compression ext in variable
When the kernel configuration contains the setting CONFIG_MODULE_COMPRESS_{GZIP,XZ,STD} we need to store the extension for a subsequent call to modinfo. Bug: https://bugs.gentoo.org/906303 Signed-off-by: Mike Pagano --- eclass/linux-mod.eclass | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass index 0098dbcfc..0fe8d7da4 100644 --- a/eclass/linux-mod.eclass +++ b/eclass/linux-mod.eclass @@ -149,6 +149,12 @@ # @DESCRIPTION: # It's a read-only variable. It contains the extension of the kernel modules. +# @ECLASS_VARIABLE: KV_OBJ_COMPRESS_EXT +# @INTERNAL +# @DESCRIPTION: +# Read-only variable. It contains the compression extension of the kernel +# modules (.xz, .gz, .zst) + case ${EAPI} in 7|8) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; @@ -385,7 +391,7 @@ generate_modulesd() { # OK so now if we have got this far, then we know we want to continue # and generate the modprobe.d file. - module_modinfo="$(modinfo -p ${currm_path}.${KV_OBJ})" + module_modinfo="$(modinfo -p ${currm_path}.${KV_OBJ}${KV_OBJ_COMPRESS_EXT})" module_config="${T}/modulesd-${currm}" ebegin "Preparing file for modprobe.d" @@ -684,6 +690,7 @@ linux-mod_src_install() { if linux_chkconfig_present MODULE_COMPRESS_XZ; then xz -T$(makeopts_jobs) --memlimit-compress=50% -q ${modulename}.${KV_OBJ} || die "Compressing ${modulename}.${KV_OBJ} with xz failed" doins ${modulename}.${KV_OBJ}.xz + KV_OBJ_COMPRESS_EXT=".xz" elif linux_chkconfig_present MODULE_COMPRESS_GZIP; then if type -P pigz &>/dev/null ; then pigz -p$(makeopts_jobs) ${modulename}.${KV_OBJ} || die "Compressing ${modulename}.${KV_OBJ} with pigz failed" @@ -691,9 +698,11 @@ linux-mod_src_install() { gzip ${modulename}.${KV_OBJ} || die "Compressing ${modulename}.${KV_OBJ} with gzip failed" fi doins ${modulename}.${KV_OBJ}.gz + KV_OBJ_COMPRESS_EXT=".gz" elif linux_chkconfig_present MODULE_COMPRESS_ZSTD; then zstd -T$(makeopts_jobs) ${modulename}.${KV_OBJ} || "Compressing ${modulename}.${KV_OBJ} with zstd failed" doins ${modulename}.${KV_OBJ}.zst + KV_OBJ_COMPRESS_EXT=".zst" else doins ${modulename}.${KV_OBJ} fi -- 2.39.3 -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index OpenPGP_0x92A6DBEC81F2B137.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[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
[gentoo-dev] [PATCH 1/1] linux-mod.eclass: Remove EAPI deprecated function call
As warned, remove EAPI deprecated use of econf being called in linux-mod_src_compile Bug: https://bugs.gentoo.org/340597 See: https://marc.info/?l=gentoo-dev=167069431328509 Signed-off-by: Mike Pagano --- eclass/linux-mod.eclass | 4 1 file changed, 4 deletions(-) diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass index 6cf9969b1..482775edc 100644 --- a/eclass/linux-mod.eclass +++ b/eclass/linux-mod.eclass @@ -624,10 +624,6 @@ linux-mod_src_compile() { cd "${srcdir}" || die ln -s "${S}"/Module.symvers Module.symvers # no die for bug #888679 einfo "Preparing ${modulename} module" - if [[ -n ${ECONF_PARAMS} ]]; then - eqawarn "This package relies on the deprecated functionality of econf being called in linux-mod_src_compile (ECONF_PARAMS), which will go away in 30 days (20230107) (https://bugs.gentoo.org/340597)" - econf ${ECONF_PARAMS} - fi # This looks messy, but it is needed to handle multiple variables # being passed in the BUILD_* stuff where the variables also have -- 2.39.1 Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index OpenPGP_0x92A6DBEC81F2B137.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] sys-kernel/linux-headers: Adjust following kernel-2.eclass changes
On 1/24/23 18:37, James Le Cuirot wrote: Signed-off-by: James Le Cuirot --- sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild | 2 +- sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild | 2 +- sys-kernel/linux-headers/linux-headers-5.19.ebuild| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild index 08907ac2fb24..06fcc6978ce1 100644 --- a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild +++ b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild @@ -40,7 +40,7 @@ src_prepare() { } src_test() { - emake headers_check ${xmakeopts} + emake headers_check "${KERNEL_MAKEOPTS[@]}" } src_install() { diff --git a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild index 9d2ebae3daee..dae40c5ab655 100644 --- a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild +++ b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild @@ -43,7 +43,7 @@ src_prepare() { } src_test() { - emake headers_check ${xmakeopts} + emake headers_check "${KERNEL_MAKEOPTS[@]}" } src_install() { diff --git a/sys-kernel/linux-headers/linux-headers-5.19.ebuild b/sys-kernel/linux-headers/linux-headers-5.19.ebuild index 527b4b401d6c..8ae17e59be76 100644 --- a/sys-kernel/linux-headers/linux-headers-5.19.ebuild +++ b/sys-kernel/linux-headers/linux-headers-5.19.ebuild @@ -42,7 +42,7 @@ src_prepare() { } src_test() { - emake headers_check ${xmakeopts} + emake headers_check "${KERNEL_MAKEOPTS[@]}" } src_install() { ACK -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
Re: [gentoo-dev] [PATCH 1/1] linux-info.eclass: Chk for .config/config.gz when CONFIG_* req
On 1/15/23 18:22, Mike Pagano wrote: In the instance where CONFIG_* settings are required and not optional, make sure there is either a .config or a config.gz to check Signed-off-by: Mike Pagano --- eclass/linux-info.eclass | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass index 16ef69ebc..a65d0c441 100644 --- a/eclass/linux-info.eclass +++ b/eclass/linux-info.eclass @@ -805,8 +805,14 @@ check_extra_config() { export LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}" return 0 fi - else - require_configured_kernel + elif ! linux_config_exists; then + qeerror "Could not find a neither a usable .config in the kernel source directory" + qeerror "nor a /proc/config.gz file," + qeerror "Please ensure that ${KERNEL_DIR} points to a configured set of Linux sources." + qeerror "If you are using KBUILD_OUTPUT, please set the environment var so that" + qeerror "it points to the necessary object directory so that it might find .config" + qeerror "or have a properly configured kernel to produce a config.gz file. (CONFIG_IKCONFIG)." + die "Kernel not configured; no .config found in ${KV_OUT_DIR} or /proc/config.gz found" fi ebegin "Checking for suitable kernel configuration options" Committed -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Lead E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
[gentoo-dev] [PATCH 1/1] linux-info.eclass: Chk for .config/config.gz when CONFIG_* req
In the instance where CONFIG_* settings are required and not optional, make sure there is either a .config or a config.gz to check Signed-off-by: Mike Pagano --- eclass/linux-info.eclass | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass index 16ef69ebc..a65d0c441 100644 --- a/eclass/linux-info.eclass +++ b/eclass/linux-info.eclass @@ -805,8 +805,14 @@ check_extra_config() { export LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}" return 0 fi - else - require_configured_kernel + elif ! linux_config_exists; then + qeerror "Could not find a neither a usable .config in the kernel source directory" + qeerror "nor a /proc/config.gz file," + qeerror "Please ensure that ${KERNEL_DIR} points to a configured set of Linux sources." + qeerror "If you are using KBUILD_OUTPUT, please set the environment var so that" + qeerror "it points to the necessary object directory so that it might find .config" + qeerror "or have a properly configured kernel to produce a config.gz file. (CONFIG_IKCONFIG)." + die "Kernel not configured; no .config found in ${KV_OUT_DIR} or /proc/config.gz found" fi ebegin "Checking for suitable kernel configuration options" -- 2.38.2 -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Lead E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
Re: [gentoo-dev] [PATCH 1/1] linux-info.eclass: Add /proc/config.gz as a valid src of CONFIG_* settings
On 1/15/23 15:16, Mike Gilbert wrote: 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. Yeah, I guess that does make sense. The CONFIGs are optional, why look for any config file ? -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
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.
[gentoo-dev] [PATCH 1/1] linux-info.eclass: Add /proc/config.gz as a valid src of CONFIG_* settings
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 Signed-off-by: Mike Pagano --- eclass/linux-info.eclass | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass index 16ef69ebc..daedd758f 100644 --- a/eclass/linux-info.eclass +++ b/eclass/linux-info.eclass @@ -301,10 +301,18 @@ linux_config_qa_check() { # @FUNCTION: linux_config_src_exists # @RETURN: true or false # @DESCRIPTION: -# It returns true if .config exists in a build directory otherwise false +# Returns true if either .config exists in a build directory or +# /proc/config.gz is found, otherwise returns false linux_config_src_exists() { export _LINUX_CONFIG_EXISTS_DONE=1 - use kernel_linux && [[ -n ${KV_OUT_DIR} && -s ${KV_OUT_DIR}/.config ]] + if use kernel_linux; then + if [[ -n ${KV_OUT_DIR} && -s ${KV_OUT_DIR}/.config ]]; then + return 0 + elif linux_config_bin_exists; then + return 0 + fi + fi + return 1 } # @FUNCTION: linux_config_bin_exists -- 2.38.2 -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
Re: [gentoo-dev] [PATCH] linux-mod.eclass: Fix MODULESD_* for hyphenated modules (bug #889752)
On 1/4/23 19:06, Patrick McLean wrote: From: Steven Stallion Use of the MODULESD__{ADDITIONS,ALIASES,EXAMPLES} variables do not currently work with external modules that are hyphenated. The current behavior results in an invalid modprobe.d file containing partially evaluated content. This appears to be due to use of ${currm} rather than ${currm_t} when Referencing variables. This changes the use of ${currm} to ${currm_t} when referencing variables to resolve this issue. Closes: https://bugs.gentoo.org/889752 --- eclass/linux-mod.eclass | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass index d14bbf7d9ea..6cf9969b19a 100644 --- a/eclass/linux-mod.eclass +++ b/eclass/linux-mod.eclass @@ -408,7 +408,7 @@ generate_modulesd() { for((t=0; t<${module_aliases}; t++)) do - echo "alias $(eval echo \${MODULESD_${currm}_ALIASES[$t]})" \ + echo "alias $(eval echo \${MODULESD_${currm_t}_ALIASES[$t]})" \ >> "${module_config}" done echo '' >> "${module_config}" @@ -434,7 +434,7 @@ generate_modulesd() { fi #--- - if [[ $(eval echo \${MODULESD_${currm}_ALIASES[0]}) == guess ]]; then + if [[ $(eval echo \${MODULESD_${currm_t}_ALIASES[0]}) == guess ]]; then # So, let's do some guesswork, eh? if [[ -n ${module_opts} ]]; then echo "# For Example..." >> "${module_config}" @@ -449,7 +449,7 @@ generate_modulesd() { echo "# For Example..." >> "${module_config}" echo "# --" >> "${module_config}" for ((t=0; t<${module_examples}; t++)); do - echo "options $(eval echo \${MODULESD_${currm}_EXAMPLES[$t]})" \ + echo "options $(eval echo \${MODULESD_${currm_t}_EXAMPLES[$t]})" \ >> "${module_config}" done echo '' >> "${module_config}" @@ -458,7 +458,7 @@ generate_modulesd() { #--- if [[ ${module_additions} -gt 0 ]]; then for ((t=0; t<${module_additions}; t++)); do - echo "$(eval echo \${MODULESD_${currm}_ADDITIONS[$t]})" \ + echo "$(eval echo \${MODULESD_${currm_t}_ADDITIONS[$t]})" \ >> "${module_config}" done echo '' >> "${module_config}" Ack -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
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 1/1] kernel-2.eclass: Don't drop CPU OPT patch when CC=clang
Clang is supported by the CPU optimization patch. (USE=experimental) Check for CC=clang and do not drop this patch. Bug: https://bugs.gentoo.org/888727 Signed-off-by: Mike Pagano --- eclass/kernel-2.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass index e13ed1a4f..873d4a204 100644 --- a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@ -1144,7 +1144,7 @@ unipatch() { UNIPATCH_DROP+=" 5011_enable-cpu-optimizations-for-gcc8.patch" UNIPATCH_DROP+=" 5012_enable-cpu-optimizations-for-gcc91.patch" UNIPATCH_DROP+=" 5013_enable-cpu-optimizations-for-gcc10.patch" - if [[ ${GCC_MAJOR_VER} -lt 9 ]]; then + if [[ ${GCC_MAJOR_VER} -lt 9 ]] && ! tc-is-clang; then UNIPATCH_DROP+=" 5010_enable-cpu-optimizations-universal.patch" fi # this legacy section should be targeted for removal -- 2.38.2 -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index OpenPGP_0x92A6DBEC81F2B137.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[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.
[gentoo-dev] [PATCH 1/1] linux-mod.eclass: Remove econf call in compile phase, function
Remove the econf call in linux-mod_src_compile as it is deprecated in later versions of EAPI. There is no current use of this functionality in the official gentoo repo and will close a 12 year old bug. Bug: https://bugs.gentoo.org/340597 Signed-off-by: Mike Pagano --- eclass/linux-mod.eclass | 7 --- 1 file changed, 7 deletions(-) diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass index ff2294f1e..5655ac73a 100644 --- a/eclass/linux-mod.eclass +++ b/eclass/linux-mod.eclass @@ -649,13 +649,6 @@ linux-mod_src_compile() { then cd "${srcdir}" ln -s "${S}"/Module.symvers Module.symvers - einfo "Preparing ${modulename} module" - if [[ -n ${ECONF_PARAMS} ]] - then - eqawarn "This package relies on the deprecated functionality of econf being called in linux-mod_src_compile (ECONF_PARAMS), which will go away in 30 days (20230107) (https://bugs.gentoo.org/340597)" - econf ${ECONF_PARAMS} || \ - die "Unable to run econf ${ECONF_PARAMS}" - fi # This looks messy, but it is needed to handle multiple variables # being passed in the BUILD_* stuff where the variables also have -- 2.37.4 -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index OpenPGP_0x92A6DBEC81F2B137.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
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] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
On 12/3/22 08:59, Florian Schmaus wrote: On 03/12/2022 14.50, Michał Górny wrote: On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote: I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and other (affected) persons, to decide if they need to "chase" the issue's assigned entity. Assume looking at the open bugs list of a developer. If the developer has old bugs in UNCONFIRMED state, you may want to issue a friendly ping. Sure, strictly speaking, this would require all bugs to drop back to UNCONFIMRED when the bug assignee changes. But even without such an implicit mechanism, those two states provide some value. I don't understand how UNCONFIRMED/CONFIRMED makes any difference here. If I file a bug against some package, it is CONFIRMED by default. If an unprivileged user files it, it's UNCONFIRMED. In both cases the assignee didn't do anything. The assignee not doing anything keeps the bug UNCONFIRMED if it is filled by an unprivileged user. That makes the bug distinguishable from a bug that got "verified" by the assignee. Yes, if *you* (as dev) fill a bug, then it is implicitly CONFIRMED (whether or not that is sensible is a different discussion). I do not see how this would invalidate my case, though. - Flow The kernel may be a special case, but personally I use unconfirmed and don't 'confirm' it until it's determined if it's a real kernel bug. Sometimes the kernel is the messenger and not the cause. But this is not a documented process and only exists in my head. Whatever the consensus is I can live with. -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Lead E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
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-dev] Up for grabs: net-print/epson-inkjet-printer-escpr
On 11/21/22 08:12, Andreas Sturmlechner wrote: I no longer have any hardware to test this package thanks to planned obsolescence. No open bugs. Regards I can maintain this one. -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Lead E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
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