The Makefile for sys-apps/realtime-lsm-0.8.5-r1 incorrectly assumes that it can find the .config file in /usr/src/linux through a hardcoded variable. When emerging it says: > >>> Source unpacked. > * Preparing realtime module > grep: /usr/src/linux/.config: No such file or directory > Failed: Security Capabilities not configured as module > Realtime LSM will not work with /usr/src/linux > Please rerun `make config' on the kernel and try again. > make: *** [config] Error 1 Heree are the offending lines in the Makefile: (from /var/tmp/portage/realtime-lsm-0.8.5-r1/work/realtime-lsm-0.8.5/Makefile, line 8:) > KERNEL_DIR := /usr/src/linux (...later, in line 24:) > @if grep CONFIG_SECURITY_CAPABILITIES=m $(KERNEL_DIR)/.config; This obviously fails if KBUILD_OUTPUT is set, as the .config will not exist in that directory, but in another one. Reproducible: Always Steps to Reproduce: 1. emerge realtime-lsm Actual Results: I got an error about the .config file. Expected Results: Recognised the existence of KBUILD_OUTPUT and used the .config there instead. Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.9-gentoo-r9 i686) ================================================================= System uname: 2.6.9-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 1400MHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 5 2005, 05:45:17)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk/ http://distfiles.gentoo.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/ciaran/portage/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi alsa apm avi berkdb bitmap-fonts cdr crypt cups curl dga divx4linux dvd eds emboss encode esd fam flac foomaticdbfortran gd gdbm gif gmail gnome gphoto2 gpm gstreamer gtk gtk2 imagemagick imlib ipv6 jack java jbig joystick jpeg kde kdeenablefinal ladspa libg++ libwww mad mikmod mmx motif mozsvg mp3 mpeg multitarget mysql ncurses nls nodrm nptl ogg oggvorbis opengl oss pam pdflib perl pic png povray ppds python qt quicktime readline real samba sdl slang sse ssl svga tcpd tiff truetype truetype-fonts type1-fonts v4l vorbis xine xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Created attachment 70774 [details, diff] New patch that removes the check that makes the build not work If this patch is used insead of the kmisc.patch-0.8.2_pre... patch then the config check which is already being done by the ebuild is skipped. With the check skipped, it will merge successfully.
Created attachment 70775 [details] New ebuild to use patch provided in attachment 70774 [details, diff]
Presumably, though, with the check skipped it might be able to be emerged on kernels without the Security Capabilities option compiled as a module? As the warning states, it won't work on such kernels. A better option would seem to be to leave the warning as-is, and dynamically set KERNEL_DIR depending on whether KBUILD_OUTPUT is set or not, I think. I'm not very familiar witht Makefile syntax, however, so I'm not sure how this would be done.
Oh, sorry, I didn't notice that the check was done in the ebuild. My bad; that should be a good solution.
Please, remove jnc from metadata.xml wrt Bug 64582.
Both maintainers listen in metadata.xml retired, whoover picks this up - please remove them.
Created attachment 85646 [details, diff] this patch fixed it for me this patch fixed it for me
There was already a patch given earlier that fixes it. Your patch wouldn't work for anybody that doesn't use KBUILD_OUTPUT.
antarus@kyoto ~/code/pkgcore/bin $ ./pquery --revdep=sys-apps/realtime-lsm antarus@kyoto ~/code/pkgcore/bin $ old
Alec needs to follow his own friggin guidelines; adding maintainer-needed to cc.
Errr why isn't sound@g.o on this bug? Sound is the maintainer as per metadata, and I'll gladly see to take care of this myself if needed.
Is this a bug still at all? I can't see it be a problem now, it doesn't grep over anything directly anymore. Can we just close this?
(In reply to comment #11) > Errr why isn't sound@g.o on this bug? Sound is the maintainer as per metadata, Probably because sound was added 6 months ago while thing bug is over two years old? http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/realtime-lsm/metadata.xml?r1=1.5&r2=1.6 Not to mention that this thing is totally not working - see Bug 154892. Been so for years.
Since opening this bug, I've reinstalled Gentoo and haven't yet needed to reinstall this, but then I haven't tried to use if for heavy music work at all yet. As such, I can't comment on whether it works now or not. I was pretty sure it worked after the patch that Chris gave in comment #1 and comment #2, though, but my memory is a bit fuzzy there, so I could be wrong.
The thing is totally working for me, I got jack working realtime last night by using a (tweaked, I admit, but just to provide a sensible default configuration) realtime-lsm module. I'll see to handle bug #154892, then let's close this bug for now, unless someone has still the problem. Reassigning to sound, no need to treeclean something that works, for now at least.
Works for me at least.
I don't believe the problem identified in this bug has been fixed, though. I don't use KBUILD_OUTPUT in my setup now at the moment, so I can't easily test it, but the changes from Chris' patch haven't been incorporated and the Makefile still refers to KERNEL_DIR so I'm assuming that this still won't work for those using KBUILD_OUTPUT.
