[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Concerning make-kpkg --append-to-version



David A. Cobb on 09/09/05 02:41, wrote:
I have been trying various configurations building LINUX-SOURCE-2.6.12 using make-kpkg.
To minimize avoidable errors, I run the whole make from a bash script.

If I use --append-to-version "x6+p0c40" for example, the first build is fine. However, the appended codes get written into '.config' If I then re-run the script (having corrected something), the make-kpkg apparently concatenates the value in '.config' with my value and gives me a horror "2.6.12x6+p0c40x6+p0c40" -- which is in any case too long for LILO to accomodate (it is also incorrect). If, on the other hand, I manually enter my code in '.config' and do NOT use the --append-to-version option, make-kpkg goes through the make process but then declares:

usr/bin/make -f /usr/share/kernel-package/rules real_stamp_image
make[1]: Entering directory `/usr/src/linux-source-2.6.12_2.6.12-6'
The UTS Release version in include/linux/version.h 2.6.12x6+p0c40 does not match current version 2.6.12, reconfiguring.

It apparently proceeds to REMOVE the appended "brand" from the version code. At least it isn't in the .deb file name any more.

Do I have to forcably get rid of the header line in '.config' where the LocalVersion appears? I am already removing 'include/linux/version.h' (and debian/official) before building. Are there other places where I need to remove remnants of the code?

No you shouldn't have to do any editing of .config by hand and I've never seen the behaviour you describe so I'd say you must be doing something wrong.

I don't remove version.h or any other code during the process. Perhaps that is what's causing the problem. What documentation are you using which recommends that approach?



Adam


--


There are places I'll remember, all my life, though some have changed, like Debian Linux 2.6.12.3



Reply to: