mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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®