All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Garman <scott.a.garman@intel.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: yocto@yoctoproject.org
Subject: Re: [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image
Date: Wed, 12 Sep 2012 14:59:20 -0700	[thread overview]
Message-ID: <505105B8.4060203@intel.com> (raw)
In-Reply-To: <1732336.2HUq7qo8OI@helios>

On 09/12/2012 01:25 PM, Paul Eggleton wrote:
> On Wednesday 12 September 2012 11:22:07 Scott Garman wrote:
>> On 09/12/2012 08:06 AM, Rudolf Streif wrote:
>>> In Denil modifying kernel parameters and doing
>>>
>>> bitbake linux-yocto -c compile -f
>>> bitbake linux-yocto
>>>
>>> worked perfectly fine. The tasks after compile were rerun and the new
>>> kernel copied to tmp/deploy/images
>>>
>>> In Edison 7.0.1 this does not seem to work anymore. The tasks do not
>>> rerun and the kernel image is not deployed.
>>>
>>> What has changed? Why does it not work anymore?
>>
>> This was a bug that was introduced in 7.0.1. I have included a patch
>> series in my testing branch that is intended to go into the denzil
>> branch soon:
>>
>> d7b818b bitbake: refactor out codeparser cache into a separate class
>> 66123b9 classes/cml1: ensure -c menuconfig forces a rebuild next time
>> 5bd11a9 bitbake: bitbake: ensure -f causes dependent tasks to be re-run
>> 8b8be74 bitbake: implement checksums for local files in SRC_URI
>
> We need to be very careful which patches we backport. In particular that last
> patch 8b8be74 should not be backported - it's new functionality, requires
> support in the metadata to work, and led to several further cleanup patches
> for the metadata to avoid warnings being raised.

I agree with the need to be conservative about backporting new features 
into point-releases. In this case I was given a list from someone of 
which patches were needed to resolve the menuconfig issue, and I didn't 
question it.

I will make a note to try removing 8b8be74 before I submit my final pull 
request to denzil - this almost certainly won't happen this week due to 
conference craziness.

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center


      reply	other threads:[~2012-09-12 21:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12 15:06 [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image Rudolf Streif
2012-09-12 15:08 ` Chris Larson
2012-09-12 15:16   ` Rudolf Streif
2012-09-12 16:01     ` Paul Eggleton
2012-09-12 16:23       ` Rudolf Streif
2012-09-12 17:15         ` Paul Eggleton
2012-09-12 18:22 ` Scott Garman
2012-09-12 20:25   ` Paul Eggleton
2012-09-12 21:59     ` Scott Garman [this message]

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=505105B8.4060203@intel.com \
    --to=scott.a.garman@intel.com \
    --cc=paul.eggleton@linux.intel.com \
    --cc=yocto@yoctoproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.