From: "Américo Wang" <xiyou.wangcong@gmail.com>
To: trapDoor <trapdoor6@gmail.com>
Cc: "Américo Wang" <xiyou.wangcong@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Pure kernel '2.6.37-rc1-00001-ge99d11d' shown as ~-dirty after compilation
Date: Thu, 4 Nov 2010 17:07:21 +0800 [thread overview]
Message-ID: <20101104090721.GG5210@cr0.nay.redhat.com> (raw)
In-Reply-To: <AANLkTimY+xFht4qLw+gx-axhfmkqBuO+GUtkt1HuCVnM@mail.gmail.com>
On Wed, Nov 03, 2010 at 06:35:46PM +0000, trapDoor wrote:
>Obviously I do that only on freshly cloned git tree or on a kernel
>unpacked from tarball. If I just update my git tree, the firmware
>files will be already in place after previous configuration. And here
>is interesting thing: neither of these commands ..
> make mrproper
> make distclean
>.. will remove the firmware files I had put in place manually. After
>doing 'make mrproper && make distclean' my tree should be clean. But
>those firmwares still remain there (I always check as I need to built
>them in and hence my .config refers to them).
They even don't know your firmwares files exist, how can
you suppose them to remove those files for you?
> And if I run 'make
>oldonfig && make kernelrelease' afterwards, it will come up with a
>'non-dirty' version string. And this seems consistent: 'make mrproper
>&& make distclean' tell me that my tree is clean despite the FW files
>so 'make kernelrelease' gives me a clean version string as well - and
>exactly the same version should be propagated after compilation (in
>vmlinuz, initrd-img, grub entry, etc.). And that how it always worked
>for me before
>
Check the output of 'git status', if it says your tree is clean,
then you should not have '-dirty'.
>It's not that I think that a kernel with (only) firmware file(s) added
>manually should be considered as clean because 'make kernelrelease'
>tells me so - actually I always thought it wasis wrong. I just want to
>have 'make kernelrelease' coming up with the same version name as I'll
>get after compilation.
>
If so, you need to disable CONFIG_LOCALVERSION_AUTO *and*
append "LOCALVERSION=" to your 'make' command.
next prev parent reply other threads:[~2010-11-04 9:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-02 8:26 trapDoor
2010-11-03 16:48 ` Américo Wang
2010-11-03 17:07 ` trapDoor
2010-11-03 18:35 ` trapDoor
2010-11-04 9:07 ` Américo Wang [this message]
2010-11-04 9:00 ` Américo Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101104090721.GG5210@cr0.nay.redhat.com \
--to=xiyou.wangcong@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=trapdoor6@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®