Re: [Fwd: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version]

2014-02-24 Thread Thomas Vaughan
>> What I'm wondering is whether I can get uname to return the desired >> format by somehow compiling a custom kernel. > > Yes you can, by getting the source code from kernel.org. > If you simply copy the config from the Debians kernel, then IIRC > # make-kpkg --initrd kernel-image kernel-headers >

Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-23 Thread Kushal Kumaran
Thomas Vaughan writes: >>> 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

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-22 Thread Hendrik Boom
On Fri, 21 Feb 2014 22:58:40 -0500, Jerry Stuckle wrote: >> abiname shouldn't change should it? >> >> > I wouldn't think so - but I also don't know. However, if you do change > something basic like the kernel version, what else will it affect? You > might get a kernel which will boot but not

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-22 Thread Sven Joachim
On 2014-02-22 00:20 +0100, Thomas Vaughan wrote: > I have downloaded some proprietary software that I want to install onto a > 64-bit Debian machine. The software is written for 64-bit linux, but the > kernel version reported, for example, by uname (and perhaps by some system > call that the compi

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Jerry Stuckle
On 2/21/2014 10:04 PM, Scott Ferguson wrote: On 22/02/14 13:35, Jerry Stuckle wrote: On 2/21/2014 9:20 PM, Thomas Vaughan wrote: 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 s

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Scott Ferguson
On 22/02/14 13:35, Jerry Stuckle wrote: > On 2/21/2014 9:20 PM, Thomas Vaughan wrote: > 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

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Scott Ferguson
On 22/02/14 13:20, Thomas Vaughan wrote: 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 re

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Jerry Stuckle
On 2/21/2014 9:20 PM, Thomas Vaughan wrote: 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

[Fwd: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version]

2014-02-21 Thread Ralf Mardorf
Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 03:28:15 +0100 Mailer: Evolution 3.10.4 On Fri, 2014-02-21 at 19:20 -0700, Thomas Vaughan wrote: > W

Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Thomas Vaughan
>>> 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--- >>> >>> I

Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Thomas Vaughan
>>> 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

Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Thomas Vaughan
>> 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 rep

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Scott Ferguson
On 22/02/14 11:03, Glenn English wrote: > > On Feb 21, 2014, at 4:20 PM, Thomas Vaughan wrote: > >> 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

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Ralf Mardorf
Forwarded Message From: Ralf Mardorf To: debian-user@lists.debian.org Subject: Re: Third-Party Software Needs Non-Debian Format for Kernel Version Date: Sat, 22 Feb 2014 01:54:59 +0100 Mailer: Evolution 3.10.4 Forwarded Message From: Ralf Mardorf To: debian

Re: Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Glenn English
On Feb 21, 2014, at 4:20 PM, Thomas Vaughan wrote: > 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.

Third-Party Software Needs Non-Debian Format for Kernel Version

2014-02-21 Thread Thomas Vaughan
I have downloaded some proprietary software that I want to install onto a 64-bit Debian machine. The software is written for 64-bit linux, but the kernel version reported, for example, by uname (and perhaps by some system call that the compiled software uses) is not in a format that the software ex