Hallo, * Andreas Beckmann [Thu, Aug 18 2016, 02:21:38AM]: > On 2016-08-17 00:07, Eduard Bloch wrote: > >> module-assistant build --text-mode --force --kvers-list 4.7.0-rc7-amd64 > >> nvidia-kernel > > > > a) minor detail, the readme does not mention --force, although it should > > not be required. > > It's just helpful to rebuild again and again looking for your problem... > > > c) I tried a similar command with 4.6.0-1-amd64 (Sid kernel) and it did NOT > > work. Now > > I just had a good burger for dinner and it DID work. > But it still didn't tell me the command you used. > > Nevertheless, I managed to come up with a command that reproduces your > failure: > > m-a build -t -O -k /usr/src/linux-headers-4.6.0-1-amd64 -f nvidia
Nice, I can test it now. And also add -d (my old "debug" mode). And I see something suspicious in the diff: ++ return 0 -+ build build KVERS=4.6.0-1-amd64 KSRC=/usr/src/linux-headers-4.6.0-1-amd64 KDREV=4.6.4-1 kdist_image ++ build build KVERS=4.6.0-1-amd64 KSRC=/lib/modules/4.6.0-1-amd64/build KDREV=4.6.4-1 kdist_image This is the call from m-a passed to you and it is OK. This points to the same directory. dh_testroot -/usr/bin/make clean SYSSRC="/usr/src/linux-headers-4.6.0-1-amd64" +/usr/bin/make clean KERNEL_UNAME="4.6.0-1-amd64" And this is what YOUR build system made out from it. The kernel version AND directory were passed previously to your build script, why is this information lost in the call? > On 2016-08-16 20:02, Eduard Bloch wrote: > > I have no idea how you manage to build the current modules even for Sid. > > We use -l, not -k. Shouldn't make a difference. (I should know it, I wrote m-a, originally it was even made for nvidia compiling as first use case, and it's just a tool investigating environment and preparing information). > And let the buildsystem figure out the details from /lib/modules > > I don't think there is an easy way to make the -k option work for the > split Debian header packages (e.g. -common and -amd64) with the nvidia What is the problem with splitted headers? They are interconnected with symlinks, there should not be any difference. > kernel module (and their conftest.sh script). But it seems to work for > the locally built kernel (no split headers) I have residing in my module > testbuild chroot. What about regular users, they are supposed to use chroots for everything too? > PS: Setting only SYSSRC was an error which made us maintain our own > conftest.h for about 10 years since the upstream conftest.sh didn't work > with the split Debian header packages. Because we never told it about > SYSOUT as well. Those are internal details I have no real insight in. I see symptoms and report them, just that. Regards, Eduard.
