the alsa-driver-0.9.0_rc1-r4 fails to find the kernel headers. here is a modified version alsa-driver-0.9.0_rc1-r5 which works ok, and is based off of the alsa-driver-0.5.12a ebuild. # Copyright 1999-2001 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License, v2 or later # Author Daniel Robbins <drobbins@gentoo.org> # /space/gentoo/cvsroot/gentoo-x86/media-sound/alsa-driver/alsa-driver-0.9.0_rc$ DESCRIPTION="Advanced Linux Sound Architecture kernel modules" HOMEPAGE="http://www.alsa-project.org/" # By default, drivers for all supported cards will be compiled. # If you want to only compile for specific card(s), set ALSA_CARDS # environment variable accordingly [ x${ALSA_CARDS} = x ] && ALSA_CARDS=all SRC_URI="ftp://ftp.alsa-project.org/pub/driver/${P/_rc/rc}.tar.bz2" S=${WORKDIR}/${P/_rc/rc} #virtual/glibc should depend on specific kernel headers DEPEND="sys-devel/autoconf virtual/glibc" PROVIDE="virtual/alsa" setkv() { KV="" KV=`readlink /usr/src/linux` if [ $? -ne 0 ] ; then echo echo "/usr/src/linux symlink does not exist; cannot continue." echo die else #alsa-driver will compile modules for the kernel pointed to by $ KV=${KV/linux-/} fi } src_unpack() { # Some *broken* Gentoo packages install stuff in /etc/rc.d/init.d # instead of /etc/init.d. However, this causes alsa's installer # to do the same foolish thing. This *hack* inibits the problem. # I filed a bug report about this with the ALSA people: # http://sourceforge.net/tracker/?func=detail&aid=551668&group_id=27464$ unpack ${A} cd ${S} sed -e 's:/etc/rc.d/init.d:/etc/init.d:' < Makefile > Makefile.hacked mv Makefile.hacked Makefile } src_compile() { setkv ./configure \ --host=${CHOST} \ --prefix=/usr \ --with-kernel="${ROOT}usr/src/linux-${KV}" \ --with-isapnp=yes \ --with-sequencer=yes \ --with-oss=yes \ --with-cards=${ALSA_CARDS} \ || die "./configure failed" emake || die "Parallel Make Failed" } src_install () { dodir /usr/include/sound dodir /etc/init.d make DESTDIR=${D} install || die dodoc CARDS-STATUS COPYING FAQ INSTALL README WARNING TODO doc/* insinto /etc/modules.d newins ${FILESDIR}/alsa-modules.conf alsa exeinto /etc/init.d doexe ${FILESDIR}/alsasound } pkg_postinst () { if [ "${ROOT}" = / ] then [ -x /usr/sbin/update-modules ] && /usr/sbin/update-modules fi einfo einfo "You might want to edit file /etc/modules.d/alsa according to you$ einfo "hardware configuration." einfo }
Created attachment 790 [details] updated alsa-driver-0.9.0_rc1-r4 ebuild labels as r5 this is not the offical ebuild, only a submitted bug fix that worked for me. contact drob for an officail release, or check you portage tree
I'll take this one.
Hi, Chris: Is /usr/src/linux a symlink, and, if it is, where is it pointing? I suspect that the bug is in the Portage, and that it has been fixed in the latest versions (see the discrussion for bug 2196 for more details).
i'm currently using portage-1.9.6, and KV is being written as linux- which then causes the alsa-driver since it can't find the linux headers, that is why i added the setkv() from the earlier version of the alsa-driver ebuild it could be that this is a portage issue?
KV should only be set to the numeric part of the kernel version, plus any suffices. E.g. "2.4.17-r3". If you are seeing alsa looking for kernel sources in "linux-", that means that KV is not set to anything at all. All that said, you didn't answer my question: do you have /usr/src/linux symlink and where does it point? I am not going to bring back the function that you suggest, because getting rid of such functions was the whole point of getting Portage to deal with this (see bug 599). My point is: if you have /usr/src/linux and it's a valid symlink, then this becomes a bug with Portage. Thanks
sorry, i forgot to include the /usr/src/linux info. also i wasn't asking you to add the setkv() to the ebuild, now that you have pointed out that this should be set by portage. any ideas why portage 1.9.6 wasn't finding /usr/src/linux on my machine, but the setkv() did work? /usr/src/linux is a symlink ls -l /usr/src/ total 12 lrwxrwxrwx 1 root root 27 Apr 26 17:22 linux -> linux-2.4.17-pre4-openmosix drwxr-xr-x 16 root root 4096 Apr 27 01:59 linux-2.4.17-pre4-openmosix drwxr-xr-x 15 root root 4096 Apr 25 23:39 linux-2.4.19-gentoo drwxr-xr-x 7 root root 4096 Apr 27 08:37 pc
To jnelson: Any clue why portage 1.9.6 doesn't set KV correctly in Chris' case? I'm still using 1.8.19 here. ;^)
-r5 of the alsa-driver ebuild now checks that KV is set, and dies otherwise.
looks like this is a portage issue. i'm seeing the same thing for the nvidia ebuild. bash-2.05a# emerge media-video/nvidia-glx Calculating dependencies ...done! >>> emerge media-video/nvidia-kernel-1.0.2880-r1 to / Matched EXTRAVERSION more than once! >>> md5 ;-) NVIDIA_kernel-1.0-2880.tar.gz Matched EXTRAVERSION more than once! >>> Unpacking source... >>> Unpacking NVIDIA_kernel-1.0-2880.tar.gz >>> Source unpacked. * * Could not determine you kernel version. * Make sure that you have /usr/src/linux symlink. * !!! ERROR: The ebuild did not complete successfully. !!! Function src_compile, Line -30, Exitcode 0 !!! (no error message) !!! emerge aborting on /usr/portage/media-video/nvidia-kernel/nvidia-kernel-1.0.2880-r1.ebuild
changed this to a portage bug
If I may offer the two following items which may help. 1) a KV_extract.py in gentoo-src 2) an updated ebuild.sh to use it. (1) uses python instead of awk (I still love you, awk), but provides better error reporting, including which lines matched more than once, and if no line matched at all. EXTRAVERSION is allowed to be blank, but no others. I tested KV_extract.py with a symlink exactly the same as Chris', and the contents of the Makefile as follows (head -n 5) VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 17 EXTRAVERSION = -pre4-openmosix Chris: What does 'head -n 10 /usr/src/linux/Makefile' print out? Arcady: The following is a patch to ebuild.sh that should help. Note that 0 exit is good, any other is bad (for KV_extract.py). ;-) Index: ebuild.sh =================================================================== RCS file: /home/cvsroot/gentoo-src/portage/bin/ebuild.sh,v retrieving revision 1.38 diff -u -r1.38 ebuild.sh --- ebuild.sh 2002/05/01 19:19:40 1.38 +++ ebuild.sh 2002/05/04 05:32:00 @@ -706,7 +706,7 @@ then KV="" else - KV=`awk -f /usr/lib/portage/bin/KV_extract.awk /usr/src/linux/Makefile` + KV=`python /usr/lib/portage/bin/KV_extract.py /usr/src/linux/Makefile` fi source ${EBUILD}
bash-2.05a# head -n 10 /usr/src/linux/Makefile VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 17 EXTRAVERSION = -pre4-openmosix KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/) KERNELPATH=kernel-$(shell echo $(KERNELRELEASE) | sed -e "s/-//")
Re-assigning this to bug-wranglers, since this bug deals with portage, and not alsa drivers.
Chris emailed me with the output of running the KV_extract.py program, and the problem is in the Makefile for the kernel - EXTRAVERSION is defined twice in the Makefile. Without looking at the entire Makefile, I can't tell if this is an error or just bad planning (both in the Makefile). Chris: Could you paste the results of running KV_extract.py here for the record? Thanks.
There was another data point for this bug in -users. A message posted by James Daniels <gentoo@infosys.ath.cx>, message id <20020505050512.40f0592d.gentoo@infosys.ath.cx> of Sun May 5 08:05:12 2002 -0400. His linux symlink looks like below: bash-2.05a# ls -l /usr/src total 2 lrwxrwxrwx 1 root root 22 05-05 01:28 linux -> linux-2.4.19-gentoo-r1 drwxr-xr-x 16 root root 776 05-05 04:38 linux-2.4.19-gentoo-r1 drwxr-xr-x 7 root root 168 04-16 06:33 redhat I requested that him to provide the top 10 lines of the kernel Makefile and post here.
The problem is that it may not be *in* the top 10 lines of the Makefile, which is the problem that Chris was having. Specifically, all of the variables were set normally, and then near line 57 (I think) EXTRAVERSION got set, again. Chris?
here is my output from KV_extrat.py running portage 1.9.6-r1 bash-2.05a$ python KV_extract.py E:Too many values matched for key EXTRAVERSION! E: Line 4 reads "EXTRAVERSION = -pre4-openmosix" E: Line 59 reads "EXTRAVERSION := $(EXTRAVERSION)-mosix"
bash-2.05a$ qpkg portage sys-apps/portage-1.4-r4 sys-apps/portage-1.9.7 * bash-2.05a$ python KV_extract.py E:Too many values matched for key EXTRAVERSION! E: Line 4 reads "EXTRAVERSION = -pre4-openmosix" E: Line 59 reads "EXTRAVERSION := $(EXTRAVERSION)-mosix"
I believe that, after reviewing the openmosix patches that Gentoo uses, I have discovered the problem. First, the first part of the Makefile is normal. One would end up with a version 2.4.17-pre4-openmosix However, if one were to set the option: Prevent the "-mosix" extension on kernel name CONFIG_MOSIX_EXTMOSIX Say Y if you want the kernel and module directory to have the "-mosix" extension (to distinguish it from coexistant non-MOSIX kernels of the same kernel version number). The version would be 2.4.17-pre4-openmosix-mosix My suggestion is that this is a bug, and my suggestion is to *remove* both the option from linux-openmosix/Documentation/Configure.help and the section in the Makefile, ifdef CONFIG_MOSIX_EXTMOSIX EXTRAVERSION := $(EXTRAVERSION)-mosix endif This will solve the problem. Perhaps a longer-term solution might be useful. Perhaps backing off to the 'symlink' method if the KV_extract.py method doesn't work? One might consider patching the Makefile with a new rule designed to output the $(KERNELRELEASE) variable. My opinion is that the short term is best served with a new kernel release with the changes I describe above.
I'll be attaching (yet another) KV_extract.py This one uses the include/linux/version.h header file, and appears to work very very well. (drobbin's idea!) Since it's in python, it can either be imported or used directly. It returns a tuple, the first item is the version (or None), and the second item is an error string (or None). A successful call would return ("2.4.19-blahblah",None) and an unsuccessful call would return (None, "[errno 2] The foozit is broken: more error here") (just for example ;-) Call it with the *base path* for the kernel, normally just /usr/src/linux
Created attachment 881 [details] KV_extract.py that uses include/linux/version.h
Arcady Genkin - drobbins wanted me to assign this to him w/high severity (Critical), but I don't have the privs. So this note is here to remind all of us.
Assigning to drobbins and raising severity, as per comment #22.
This works just fine for me, now, with portage 1.9.10 Give it a try!
