Summary: | sys-process/atop-2.9.0-r1 fails after kernel upgrade | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick Soveiko <gentoo-bugzilla> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | benoit.dufour, gentoo-bugzilla |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
/var/tmp/portage/sys-process/atop-2.9.0-r1/temp/build.log
Logs for trying to build atop modules with mismatching uname -r and eselect kernel show |
Description
Nick Soveiko
2023-12-10 19:35:28 UTC
Created attachment 878650 [details]
/var/tmp/portage/sys-process/atop-2.9.0-r1/temp/build.log
$ emerge -pqv '=sys-process/atop-2.9.0-r1::gentoo' [ebuild R ] sys-process/atop-2.9.0-r1 USE="modules modules-sign strip -dist-kernel" $ emerge --info '=sys-process/atop-2.9.0-r1::gentoo' Portage 3.0.56 (python 3.11.6-final-0, default/linux/amd64/17.1/no-multilib, gcc-13, glibc-2.37-r7, 6.1.57-gentoo-ns x86_64) ================================================================= System Settings ================================================================= [skipped, as above] ================================================================= Package Settings ================================================================= sys-process/atop-2.9.0-r1::gentoo was built with the following: USE="modules modules-sign strip -dist-kernel" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks downgrade-backup ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict suidctl unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" It also happens on sys-process/atop-2.10.0-r1. This is probably caused because both ebuilds use a patch that uses `uname -r` (the current kernel) in make install instead of getting the kernel version from for e.g. `eselect kernel show`. See the line 23 of this file: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-process/atop/files/atop-2.9.0-netatop-makefile.patch I'll also add my own logs. Note that I use the xanmod-rt-kernel, which is based on the dist-kernel, but that this also happens if the current running kernel is gentoo-dist. tux ~ # uname -r 6.6.41-rt37-xanmod1-dist Created attachment 899841 [details]
Logs for trying to build atop modules with mismatching uname -r and eselect kernel show
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8c8087a90e1123ea8a7e62a10d2be5df9167b1 commit df8c8087a90e1123ea8a7e62a10d2be5df9167b1 Author: Paul Zander <negril.nx+gentoo@gmail.com> AuthorDate: 2024-08-11 20:51:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-08-11 20:56:01 +0000 sys-process/atop: patch out uname usage Bonus: dies when it finds uname in netatop source Closes: https://bugs.gentoo.org/919693 Signed-off-by: Paul Zander <negril.nx+gentoo@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> sys-process/atop/atop-2.10.0-r1.ebuild | 8 ++++++++ sys-process/atop/atop-2.9.0-r1.ebuild | 8 ++++++++ 2 files changed, 16 insertions(+) (In reply to benoit.dufour from comment #4) > It also happens on sys-process/atop-2.10.0-r1. > This is probably caused because both ebuilds use a patch that uses `uname > -r` (the current kernel) in make install instead of getting the kernel > version from for e.g. `eselect kernel show`. > See the line 23 of this file: > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-process/atop/files/atop-2. > 9.0-netatop-makefile.patch > > I'll also add my own logs. > Note that I use the xanmod-rt-kernel, which is based on the dist-kernel, but > that this also happens if the current running kernel is gentoo-dist. > tux ~ # > uname -r > 6.6.41-rt37-xanmod1-dist Note that this analysis was bogus. The patch was not adding uname (it's in a context line) but also the ebuild wasn't using the install target for this reason. I noticed too late. I had already sent the message with the little ping on IRC. So I thought you would notice without I ping you another time. Anyway, thanks you a lot, like that I won't have to triple reboot anymore after a kernel upgrade. |