Summary: | app-emulation/vendor-reset-0.1.0 - make[1]: *** /.../build: No such file or directory. Stop. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Nick Sarnie <sarnex> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alex, mva, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge-info.txt
app-emulation:vendor-reset-0.1.0:20210327-234243.log emerge-history.txt environment etc.portage.tar.bz2 temp.tar.bz2 vendor-reset-0.1.0.ebuild |
Description
Toralf Förster
2021-03-28 10:16:07 UTC
Created attachment 695298 [details]
emerge-info.txt
Created attachment 695301 [details]
app-emulation:vendor-reset-0.1.0:20210327-234243.log
Created attachment 695304 [details]
emerge-history.txt
Created attachment 695307 [details]
environment
Created attachment 695310 [details]
etc.portage.tar.bz2
Created attachment 695313 [details]
temp.tar.bz2
Toralf, can you please send ls /lib/modules/ The package uses KVER ?= $(shell uname -r) KDIR ?= /lib/modules/$(KVER)/build to get the module directory, but it seems the chroot module directory either doesn't exist or has a different name. Thanks, Sarnex tinderbox@mr-fox ~ $ ls -l run/17.1_desktop_gnome_systemd-20210318-090503/lib/modules/ total 0 drwxr-xr-x 1 root root 496 Mar 27 05:29 5.11.10-gentoo-dist drwxr-xr-x 1 root root 464 Mar 18 09:54 5.11.7-gentoo drwxr-xr-x 1 root root 512 Mar 22 15:38 5.11.7-gentoo-dist drwxr-xr-x 1 root root 524 Mar 25 01:17 5.11.9-gentoo-dist tinderbox@mr-fox ~ $ ls -l run/17.1_desktop_gnome_systemd-20210318-090503/usr/src total 4 lrwxrwxrwx 1 root root 25 Mar 26 21:55 linux -> linux-5.11.10-gentoo-dist drwxr-xr-x 1 root root 508 Mar 26 18:09 linux-5.11.10-gentoo drwxr-xr-x 1 root root 338 Mar 26 21:55 linux-5.11.10-gentoo-dist drwxr-xr-x 1 root root 866 Mar 19 06:24 linux-5.11.7-gentoo drwxr-xr-x 1 root root 338 Mar 20 13:03 linux-5.11.7-gentoo-dist drwxr-xr-x 1 root root 508 Mar 19 06:24 linux-5.11.7-gentoo-r1 drwxr-xr-x 1 root root 508 Mar 22 04:17 linux-5.11.8-gentoo-r1 drwxr-xr-x 1 root root 508 Mar 24 21:23 linux-5.11.9-gentoo drwxr-xr-x 1 root root 338 Mar 25 01:12 linux-5.11.9-gentoo-dist drwxr-xr-x 1 root root 52 Mar 27 18:39 rpm Created attachment 695676 [details]
vendor-reset-0.1.0.ebuild
Thanks for your help. I can't reproduce this so I need help testing a fix.
Can you try the attached ebuild?
If you get an error about ftrace.c:67:18: error: assignment to ‘ftrace_func_t’, just rename the ebuild to vendor-reset-9999.ebuild and use that, it's fixed upstream.
Sarnex
Oh wait, this is an slibtool environment. I bet it’s that. Thanks, I didn't even notice. If that ebuild doesn't fix it, can someone tell me how to reproduce the tinderbox build so I can investigate? Thanks, Sarnex > can someone tell me how to reproduce the tinderbox build so I can investigate? MAKEFLAGS='LIBTOOL=rdlibtool' MAKE='make LIBTOOL=rdlibtool' emerge -av app-emulation/vendor-reset First guess the program has no dependency on the build directory and GNU libtool just happens to work because its slower than mkdir(1), if this is right -j1 should work. SDL2_mixer had a similar issue. https://bugs.gentoo.org/show_bug.cgi?id=777420 On second thought this build doesn't use libtool at all, it has a static makefile. https://github.com/gnif/vendor-reset/blob/v0.1.0/Makefile (In reply to Nick Sarnie from comment #7) > The package uses > KVER ?= $(shell uname -r) By the way, IIRC, such packages should be patched to use KERNEL_DIR, aren't they? Otherwise, they will build modules for only currently running kernel version, and not for "prepared" and selected with eselect. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9e5a76e9db897b85f87d705f30040858ccb66e4 commit e9e5a76e9db897b85f87d705f30040858ccb66e4 Author: Nick Sarnie <sarnex@gentoo.org> AuthorDate: 2022-12-06 01:55:15 +0000 Commit: Nick Sarnie <sarnex@gentoo.org> CommitDate: 2022-12-06 01:58:51 +0000 app-emulation/vendor-reset: Version bump, bugfix Closes: https://bugs.gentoo.org/778890 Signed-off-by: Nick Sarnie <sarnex@gentoo.org> app-emulation/vendor-reset/Manifest | 2 +- .../vendor-reset/files/Respect-eselect-kernel.patch | 13 +++++++++++++ ...0220902.ebuild => vendor-reset-0.1.1_pre20221205.ebuild} | 6 +++++- app-emulation/vendor-reset/vendor-reset-9999.ebuild | 7 ++++++- 4 files changed, 25 insertions(+), 3 deletions(-) (In reply to Vadim A. Misbakh-Soloviov (mva) from comment #14) > (In reply to Nick Sarnie from comment #7) > > The package uses > > KVER ?= $(shell uname -r) > > By the way, IIRC, such packages should be patched to use KERNEL_DIR, aren't > they? > > Otherwise, they will build modules for only currently running kernel > version, and not for "prepared" and selected with eselect. Nice catch, should be fixed now hopefully By the way, I think it can be fixed by setting few variables in ebuild, without patching the package itself. There is an example how one fellow user fixed that issue that way: https://raw.githubusercontent.com/fisher122/fish-overlay/master/app-emulation/vendor-reset/vendor-reset-9999.ebuild Thanks I'll check that |