All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: How to find out why shared sstate is not being used for a recipe
Date: Wed, 4 Jun 2014 08:19:35 +0200	[thread overview]
Message-ID: <538EBA77.8050900@topic.nl> (raw)
In-Reply-To: <1401804615.12440.98.camel@ted>

On 06/03/2014 04:10 PM, Richard Purdie wrote:
> On Tue, 2014-06-03 at 15:54 +0200, Mike Looijmans wrote:
>> On 06/03/2014 10:45 AM, Richard Purdie wrote:
>>> the next steps depend upon how clear the differences are. Basically
>>> there should be some degree of commonality between the two builds and at
>>> some point there will be divergence. We need to pinpoint the point of
>>> divergence. The divergence will be in fpga-image-miami itself or in one
>>> of its dependencies.
>>
>> ALL stamps for ALL tasks for fpga-image-miami are different. There's a few
>> thousand lines in these files, with very few similarities.
>
> Ok, this gives a very strong pointer then, see below.
>
>> I'll just go for the "do_fetch" task then, since that's about the first to
>> execute.
>
> This is a good move.
>
>> So far, on one project (that is, NOT the fpga-image-miami) the SRC_URI is
>> slightly different. The machines are on various sides of a router/firewall, so
>> SRC_URI="git://${MY_SERVER}/blabla" evaluates differently.
>>
>> How can I tell the system that the value of "MY_SERVER" is irrelevant to each
>> and every build step in each and every recipe?
>
> The SRC_URI changing would indeed cause the tasks build separately since
> bitbake thinks they're different things.
>
> You have two ways of addressing this. Firstly, you could setup PREMIRROR
> entries for these git urls which remaps them to the correct thing in
> each case. There would then be one "canonical" url in the recipe and
> you'd not need to change the hash generation.
>
> The other way would be to either exclude the variable from the checksum
> generation or give it a specific value. This would be something like:
>
> do_fetch[vardepsexclude] += "SRC_URI"
>
> you may also have to do this with other tasks that use SRC_URI such as
> do_unpack and do_patch. The other option is:
>
> SRC_URI[vardepvalue] = "git://canonical/url/for/recipe"
>
> which gives it a specific value to use for checksum purposes.

In this case, a very useful syntax. The machines have different MY_SERVER 
values in their local.conf, so I've changed one into:

MY_SERVER = "git://some/local/path"
MY_SERVER[vardepvalue] = "git://common.server/path"

This generates the same SRC_URI signatures for the locations that look 
different but actually refer to the same location.

The PREMIRROR sounds like a generic solution to the underlying problem of 
accessing servers from different locations. I'll keep that in mind for the 
next project.

Next, I'll need to investigate why the fpga-image-miami generates different 
signatures, as both machines fetch it from the same URI.

Mike.


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at MEDTEC Europe 3-5 June, Messe Stuttgart, stand number 5D20
http://medteceurope.com/index.php?page=home-en



  reply	other threads:[~2014-06-04  6:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-27  6:58 How to find out why shared sstate is not being used for a recipe Mike Looijmans
2014-05-28 20:42 ` Khem Raj
2014-05-28 20:46   ` Christopher Larson
2014-05-28 23:12     ` Richard Purdie
2014-06-03  5:25       ` Mike Looijmans
2014-06-03  5:35         ` Mike Looijmans
2014-06-03  8:45           ` Richard Purdie
2014-06-03 13:54             ` Mike Looijmans
2014-06-03 14:10               ` Richard Purdie
2014-06-04  6:19                 ` Mike Looijmans [this message]
2014-06-04 10:44             ` Mike Looijmans
2014-06-03  8:32         ` Martin Jansa
2014-06-03  9:07         ` Richard Purdie
2014-08-18  8:12 ` Mike Looijmans

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=538EBA77.8050900@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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.