>>> isn't supported per se. But when [the software], or the makefiles, >>> parse the string >>> 3.12-1-amd64 >>> they don't get the expected result. If the uname -r were the string >>> 3.12.9-1 >>> then parsing it would yield the expected result. >>> ---END QUOTE FROM VENDOR--- >>> >>> Is the reported kernel-version string, "3.12-1-amd64", something >>> that I could change by compiling a custom kernel? >> >> Might a shell script that output the expected string work? > > Or link or what ever? I don't understand what the software is doing, > that the output of uname -r doesn't fit to some other string.
I think that the build system is using the uname(1) command, but the compiled software is calling the uname(2) system call. > More information is needed. I have not very much information, but let's assume the worst: The vendor has some compiled code that calls the uname() system call. Is it possible by compiling a custom kernel for me to make what uname() returns be the format that the vendor desires, something like '3.12.9-1', or whatever? > Sure, Debian packages might be named 3.x for kernels 3.x.y, 3.x.z, > 3.x.n. I like this, since I don't need to manually fix my manually > customized grub.cfg, when such a kernel is upgraded and especially those > kernels are updated and older versions automatically will be removed, > while kernels build by myself are never touched. I'm not sure that I understand. The package name is one thing, but isn't what uname returns something else? -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAO_ux8TwPVzU-NmP==wyqe23gia4ukkpujtdgpdprtc1v_...@mail.gmail.com
