Re: [gentoo-dev] [PATCH 1/4] profiles/use.desc: create USE=strip global USE flag
On Fri, May 26, 2023 at 06:06:46AM +0100, Sam James wrote: > > Ionen Wolkens writes: > > > Primarily intended for use by linux-mod-r1.eclass, which needs > > a global IUSE to control stripping of kernel modules *before* > > signatures and compression (alternative would be to simply never > > strip, but that seem sub-optimal). > > > > Originally meant to be USE=modules-strip or similar, but this can > > have a more general use case when portage does not know how to > > strip special files properly while the ebuild does. > > > > Notable is mingw ebuilds (wine-*, dxvk, vkd3d-proton, mingw64-*). > > If portage uses x86_64-pc-linux-strip on, e.g. mingw64-toolchain's > > runtime libraries, then at least the 32bit toolchain ends up broken > > and cannot compile anything anymore. But then dostrip -x results in > > unstripped files while we can use x86_64-w64-mingw32-strip in the > > ebuild potentially saving 60MB+. Currently this is done through > > USE=debug, but does not feel fully fitting given this isn't about > > adding debugging paths (or even symbols, or anything) and is merely > > "do not strip". > > > > No USE in ::gentoo currently contain the word "strip" and defining > > it should not conflict. > > This sounds fine (and a good idea), but we may want some indication > in the USE flag description (eh), a QA policy to indicate > it's only for special situations, or some note in the devmanual. > > Can see people getting this wrong and trying to use it in ebuilds > which would work otherwise. But maybe the "special" in the USE > description is enough? This is what I had in mind when I used that word. Didn't want the description to sound like it's aimed at developers more than users, but still have something that prevents matching common strip usage. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/4] profiles/use.desc: create USE=strip global USE flag
Ionen Wolkens writes: > Primarily intended for use by linux-mod-r1.eclass, which needs > a global IUSE to control stripping of kernel modules *before* > signatures and compression (alternative would be to simply never > strip, but that seem sub-optimal). > > Originally meant to be USE=modules-strip or similar, but this can > have a more general use case when portage does not know how to > strip special files properly while the ebuild does. > > Notable is mingw ebuilds (wine-*, dxvk, vkd3d-proton, mingw64-*). > If portage uses x86_64-pc-linux-strip on, e.g. mingw64-toolchain's > runtime libraries, then at least the 32bit toolchain ends up broken > and cannot compile anything anymore. But then dostrip -x results in > unstripped files while we can use x86_64-w64-mingw32-strip in the > ebuild potentially saving 60MB+. Currently this is done through > USE=debug, but does not feel fully fitting given this isn't about > adding debugging paths (or even symbols, or anything) and is merely > "do not strip". > > No USE in ::gentoo currently contain the word "strip" and defining > it should not conflict. This sounds fine (and a good idea), but we may want some indication in the USE flag description (eh), a QA policy to indicate it's only for special situations, or some note in the devmanual. Can see people getting this wrong and trying to use it in ebuilds which would work otherwise. But maybe the "special" in the USE description is enough? signature.asc Description: PGP signature
[gentoo-dev] [PATCH 4/4] app-admin/ryzen_smu: migrate to linux-mod-r1
Randomly migrating myself as a very simple migration example (don't
actually use this, no hardware). Notably makes the CC_IS_CLANG checks
from the old ebuild unnecessary.
Signed-off-by: Ionen Wolkens
---
.../ryzen_smu-0.1.2_p20211205-r1.ebuild | 28 +++
1 file changed, 28 insertions(+)
create mode 100644 app-admin/ryzen_smu/ryzen_smu-0.1.2_p20211205-r1.ebuild
diff --git a/app-admin/ryzen_smu/ryzen_smu-0.1.2_p20211205-r1.ebuild
b/app-admin/ryzen_smu/ryzen_smu-0.1.2_p20211205-r1.ebuild
new file mode 100644
index ..f1b8625e5b94
--- /dev/null
+++ b/app-admin/ryzen_smu/ryzen_smu-0.1.2_p20211205-r1.ebuild
@@ -0,0 +1,28 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit linux-mod-r1
+
+DESCRIPTION="Kernel driver for AMD Ryzen's System Management Unit"
+HOMEPAGE="https://github.com/leogx9r/ryzen_smu;
+SRC_URI="https://dev.gentoo.org/~slashbeast/distfiles/${PN}/${P}.tar.xz;
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+
+src_compile() {
+ local modlist=( ryzen_smu )
+ local modargs=( KERNEL_BUILD="${KV_OUT_DIR}" )
+
+ linux-mod-r1_src_compile
+}
+
+src_install() {
+ linux-mod-r1_src_install
+
+ insinto /usr/lib/modules-load.d
+ doins "${FILESDIR}"/ryzen_smu.conf
+}
--
2.40.1
[gentoo-dev] [PATCH 3/4] linux-mod-r1.eclass: new eclass, rewrite of linux-mod.eclass
Here's a rough overview of -r0 -> -r1 differences with occasional
rationale behind them if felt relevant (for migrating, refer to
the eclassdocs instead as this does not really document usage
changes):
Features that did not exist in previous eclass (not exhaustive):
* automatic modules signing support, been often requested and
users would instead use messy bashrc hacks to accomplish this
(enabled with USE=modules-sign)
* modules (manual) stripping support to allow stripping *before*
signing and compression
(can be disabled with USE=-strip)
* can auto-select toolchain to match kernel, e.g. if built with
clang-15 then it won't use gcc nor clang-16 if possible
(will warn if the matching compiler went missing)
* helper functions to profit from the above 3 even if not using
linux-mod-r1_src_compile+install (e.g. for zfs-kmod)
* generic supported kernel version checks (min/max) which comes with
an encouragement to use LTS kernels for out-of-tree modules
(but max is not enforced, just makes a strong suggestion)
* linux-mod-r1_src_install now does einstalldocs
* can guess some common build targets rather than just 'module',
largely removing the need for BUILD_TARGETS
* user-oriented MODULES_EXTRA_EMAKE among other few variables
* various additional sanity checks hopefully making issues
clearer for users and ebuilds a bit harder to write wrong
"Features" that existed but were not kept (not exhaustive):
* support for =4.14.x
* allowing doing all in global scope using variables ran through `eval`
(this often led to all sort of variable misuse in global scope)
* MODULESD_* support, originally meant to keep but it is used by only
5 packages and holds very little meaning that I can see even in these
(when needed, packages should write their own .conf)
* moduledb, was being updated for nothing in postinst/postrm
despite the tool that can use this (sys-kernel/module-rebuild)
being gone from the tree since Feb 2014
* convert_to_m(), only 1 in-tree ebuild uses this right now (svgalib)
* various other functions with no consumers were dropped, some
were likely meant to be @INTERNAL, get-KERNEL_CC was never used
either and now there's ${KERNEL_CC}
* running 'clean' by default, this sometime led to race conditions by
attempting to clean and build at same time in e.g. nvidia-drivers
(if an ebuild truly need this, it can be specified manually)
* BUILD_FIXES support, this is set by linux-info.eclass but has no
real relevance that I can see (ebuilds have sometime wrongly used it)
* undocumented feature CONFIG_CHECK="@CONFIG:modname" (or so?) meant
for automagic based on kernel config is no longer supported, this
also removes the also undocumented MODULE_IGNORE used by it (found
0 ebuilds using these in the tree, can be done manually if needed)
* converting CONFIG_CHECK to non-fatal for running again on binary
merge when (while *possible*) it's rather unlikely would build
modules for a different kernel than the one that will be used
* having preinst and postrm exports, removed
-> originally wanted to remove pkg_setup too but it complicated
things with linux-info's own pkg_setup and made the eclass
feel less convenient and error-prone with environment handling
Dependency changes:
* virtual/libelf DEPEND removed, building objtool (which uses this) is
not handled by the eclass and does not seem auto-built by make if
missing, as such the dependency is not used *here* but rather by
dist-kernels and source packages which both already request it.
* sys-apps/kmod[tools] BDEPEND+IDEPEND added, and removed from DEPEND
(linux-mod-r0 uses it similarly but lacks the eapi7+8 adjustment)
* modules-sign? ( dev-libs/openssl virtual/pkgconfig ) BDEPEND for
building sign-file, unlike objtool it may need rebuilds for openssl
and is handled here
* dependencies are no longer guarded by "kernel_linux? ( )", it only
served to silence pkgcheck and then give build failures (linux-only
ebuilds should be masked on non-Linux profiles or, if mixed, use a
masked MODULES_OPTIONAL_IUSE which *can* be kernel_linux).
Tentative changes:
* drop KERNEL_ABI support, (nowadays) kernel seems to append its own
-m32/-m64 and should be no need for multilib.eclass complications
(tested to work *at least* with x32[userland]+64bit[kernel])
* ^ but add hppa2.0->64 kgcc64 switching like kernel-build.eclass
* drop addpredict wrt bug #653286, assuming no longer relevant given
unable to reproduce even with kernel-4.14.315+split-debug+some misc
modules, perhaps would with spl but that (removed) ebuild is too
broken to try
Misc changes:
* misc -> extra default install dir, to match the kernel's defaults
(this is also where zfs-kmod already installs due to that default)
Three bugs were addressed, but not closing given -r0 remains affected:
* bug #447352: modules signing is supported
* bug #759238: arguably not an issue anymore in -r0 either due to
CHECKCONFIG_DONOTHING=1 (bug #862315) now
[gentoo-dev] [PATCH 2/4] profiles/use.desc: create USE=modules-sign global USE flag
Similarly to gyakovlev's proposition for signing back in 2018 (with a module-sign IUSE), linux-mod-r1.eclass will make use of this to enable/disable signing and it would be inconvenient if consumers had to define it. An alternative could be to automagic enable when the kernel has "sign by default" a bit like compression is handled -- albeit this can sometime need more configuration and may be unexpected (i.e. permissions for keys, if keys were moved to a different locations, passphrases, and dist-kernels unsurprisingly don't install the private key and would result in failure out-of-the-box). Having a USE also makes it more obvious that support exists, and attempting to enable will give bit of explanations if anything is amiss. Name-wise, debated between this and 'sign-modules' but fwiw former sorts better with the already existing 'modules'. Signed-off-by: Ionen Wolkens --- profiles/use.desc | 1 + 1 file changed, 1 insertion(+) diff --git a/profiles/use.desc b/profiles/use.desc index aa5d16dd652e..bd8cb7031ab8 100644 --- a/profiles/use.desc +++ b/profiles/use.desc @@ -192,6 +192,7 @@ mms - Support for Microsoft Media Server (MMS) streams mng - Add support for libmng (MNG images) modplug - Add libmodplug support for playing SoundTracker-style music files modules - Build the kernel modules +modules-sign - Cryptographically sign installed kernel modules (requires CONFIG_MODULE_SIG=y in the kernel) mono - Build Mono bindings to support dotnet type stuff motif - Add support for the Motif toolkit mp3 - Add support for reading mp3 files -- 2.40.1
[gentoo-dev] [PATCH 1/4] profiles/use.desc: create USE=strip global USE flag
Primarily intended for use by linux-mod-r1.eclass, which needs a global IUSE to control stripping of kernel modules *before* signatures and compression (alternative would be to simply never strip, but that seem sub-optimal). Originally meant to be USE=modules-strip or similar, but this can have a more general use case when portage does not know how to strip special files properly while the ebuild does. Notable is mingw ebuilds (wine-*, dxvk, vkd3d-proton, mingw64-*). If portage uses x86_64-pc-linux-strip on, e.g. mingw64-toolchain's runtime libraries, then at least the 32bit toolchain ends up broken and cannot compile anything anymore. But then dostrip -x results in unstripped files while we can use x86_64-w64-mingw32-strip in the ebuild potentially saving 60MB+. Currently this is done through USE=debug, but does not feel fully fitting given this isn't about adding debugging paths (or even symbols, or anything) and is merely "do not strip". No USE in ::gentoo currently contain the word "strip" and defining it should not conflict. Signed-off-by: Ionen Wolkens --- profiles/use.desc | 1 + 1 file changed, 1 insertion(+) diff --git a/profiles/use.desc b/profiles/use.desc index 47438c839071..aa5d16dd652e 100644 --- a/profiles/use.desc +++ b/profiles/use.desc @@ -301,6 +301,7 @@ ssl - Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer startup-notification - Enable application startup event feedback mechanism static - !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically static-libs - Build static versions of dynamic libraries as well +strip - Allow symbol stripping to be performed by the ebuild for special files subversion - Enable subversion (version control system) support suid - Enable setuid root program(s) svg - Add support for SVG (Scalable Vector Graphics) -- 2.40.1
[gentoo-dev] [PATCH 0/4] linux-mod-r1.eclass: new eclass, rewrite of -r0
Posting here for early general feedback / review, see also the PR[1]. Please try to migrate some ebuilds using it, small issues / nitpicks can be resolved anytime but usage changes could be messy after merge. Refer to eclass docs for usage and migration instructions. Commit message for linux-mod-r1 gives an overview of feature differences with -r0. Including a simple migrated ebuild (ryzen_smu) to show what it looks like. PR[1] has additional ones, currently: nvidia-drivers, virtualbox-modules, xpadneo, and zfs-kmod. [1] https://github.com/gentoo/gentoo/pull/31154 Ionen Wolkens (4): profiles/use.desc: create USE=strip global USE flag profiles/use.desc: create USE=modules-sign global USE flag linux-mod-r1.eclass: new eclass, rewrite of linux-mod.eclass app-admin/ryzen_smu: migrate to linux-mod-r1 .../ryzen_smu-0.1.2_p20211205-r1.ebuild | 28 + eclass/linux-mod-r1.eclass| 1199 + profiles/use.desc |2 + 3 files changed, 1229 insertions(+) create mode 100644 app-admin/ryzen_smu/ryzen_smu-0.1.2_p20211205-r1.ebuild create mode 100644 eclass/linux-mod-r1.eclass -- 2.40.1
[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
