On Thursday 13 May 2010 21:02:50 Markus Schuster wrote: > I've tested your version from git and it looks very promising - I've just > found one little bug: You use `uname -r` to determine what compatibility > patches to apply. The problem is: When using module-assistant, you can > specify another kernel to build for. In my case, my buildserver runs a > 2.6.29 kernel, but I want to compile for lennys 2.6.26 kernel, so I run > # m-a --kernel-dir=/usr/src/linux-headers-2.6.26-2-amd64/ --kvers- > list=2.6.26-2-amd64 build iscsitarget > But now only the patches up to 2.6.29 are applied and the build fails. > But it's easy to fix, please have a look at my patch below:
Damn!! I had ended up spending a lot of time in the night thinking why this error was triggered during iscsitarget package build time. dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -le: unexpected operator [: 1: -lt: unexpected operator dh_testdir dh_testroot rm -f build-arch-stamp build-indep-stamp #CONFIGURE-STAMP# /usr/bin/make -C usr clean So it happens because the same rules file is share by both. And during iscsitarget package build time, KVERS is not available. Sigh!! Sometimes you just got to go sleep when something does not work. :-) I have pushed the change and will prepare an upload soon. Thanks for your effort. Regards, Ritesh -- Ritesh Raj Sarraf | http://people.debian.org/~rrs "Necessity is the mother of invention."
signature.asc
Description: This is a digitally signed message part.