Re: Concerning make-kpkg --append-to-version
Adam Hardy wrote:
> 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: 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?
Add a period to the beginning of your --append_to_version="" i.e.
I've get some ugly kernel names when I forget the period