On 06/09/2011 01:04 AM, Richard Purdie wrote:
> On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
>> On 06/02/2011 09:35 AM, Richard Purdie wrote:
>>> On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
Even if we're using the sstate
cache from /foo/oecore/tmp over in /bar/oecore/tmp (a
On 06/09/2011 01:08 AM, Richard Purdie wrote:
> On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
>> On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
>>> On 06/02/2011 09:35 AM, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
> Even if we're using the ss
Richard Purdie wrote:
> On Thu, 2011-06-09 at 21:51 +0800, Cui, Dexuan wrote:
>> Richard Purdie wrote:
>>> On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
I suspect you've asking for some partial sstate cache to be shared
between two builds?
Put simpler, you probably
On Thu, 2011-06-09 at 21:51 +0800, Cui, Dexuan wrote:
> Richard Purdie wrote:
> > On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
> >> I suspect you've asking for some partial sstate cache to be shared
> >> between two builds?
> >>
> >> Put simpler, you probably want:
> >>
> >> in tmp0
Richard Purdie wrote:
> On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
>> On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
>>> On 06/02/2011 09:35 AM, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
> Even if we're using the sstate
> cache from /f
On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
> On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
> > On 06/02/2011 09:35 AM, Richard Purdie wrote:
> > > On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
> > >> Even if we're using the sstate
> > >> cache from /foo/oecore/tmp over in
On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
> On 06/02/2011 09:35 AM, Richard Purdie wrote:
> > On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
> >> Even if we're using the sstate
> >> cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
> >> is rm -rf'd) ? Since we'
On 06/02/2011 09:35 AM, Richard Purdie wrote:
> On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
>> On 06/02/2011 07:37 AM, Phil Blundell wrote:
>>> On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote:
But help2man is just the easy/common case. Heck, it _may_ blow up even
with the host h
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
> On 06/02/2011 07:37 AM, Phil Blundell wrote:
> > On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote:
> >> But help2man is just the easy/common case. Heck, it _may_ blow up even
> >> with the host help2man instead of help2man-native, if a recipe u
On 06/02/2011 07:37 AM, Phil Blundell wrote:
> On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote:
>> But help2man is just the easy/common case. Heck, it _may_ blow up even
>> with the host help2man instead of help2man-native, if a recipe uses
>> system-wide help2man and perlnative.bbclass. The ro
On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote:
> But help2man is just the easy/common case. Heck, it _may_ blow up even
> with the host help2man instead of help2man-native, if a recipe uses
> system-wide help2man and perlnative.bbclass. The root problem (again,
> from memory) is that since we
On 06/02/2011 07:06 AM, Richard Purdie wrote:
> On Wed, 2011-06-01 at 13:59 -0700, Tom Rini wrote:
>> On 06/01/2011 01:45 PM, Phil Blundell wrote:
>>> On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote:
What falls down in this case is that once
perl-native is built (and in our PATH), if i
On Wed, 2011-06-01 at 13:59 -0700, Tom Rini wrote:
> On 06/01/2011 01:45 PM, Phil Blundell wrote:
> > On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote:
> >> What falls down in this case is that once
> >> perl-native is built (and in our PATH), if it's a different version than
> >> system-wide per
Tom Rini wrote:
> On 06/01/2011 01:05 PM, Phil Blundell wrote:
>> On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote:
>>> Maybe race isn't quite the right word. But recipe A depends on
>>> lib$something-perl-native, and brings in perl-native. It also
>>> checks
>>> for perl in its auto-foo and fi
On 06/01/2011 01:45 PM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote:
>> What falls down in this case is that once
>> perl-native is built (and in our PATH), if it's a different version than
>> system-wide perl, stuff starts failing on version mis-match.
>
> I think th
On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote:
> What falls down in this case is that once
> perl-native is built (and in our PATH), if it's a different version than
> system-wide perl, stuff starts failing on version mis-match.
I think that's the bit that I'm not properly understanding. Whi
On 06/01/2011 01:05 PM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote:
>> Maybe race isn't quite the right word. But recipe A depends on
>> lib$something-perl-native, and brings in perl-native. It also checks
>> for perl in its auto-foo and finds our perl. It now also
On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote:
> Maybe race isn't quite the right word. But recipe A depends on
> lib$something-perl-native, and brings in perl-native. It also checks
> for perl in its auto-foo and finds our perl. It now also uses our perl
> when it wants a host perl and all
On 06/01/2011 10:56 AM, Richard Purdie wrote:
> On Wed, 2011-06-01 at 10:17 -0700, Tom Rini wrote:
>> On 06/01/2011 06:18 AM, Dexuan Cui wrote:
>>> Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and
>>> perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in
>>> t
On Wed, 2011-06-01 at 10:17 -0700, Tom Rini wrote:
> On 06/01/2011 06:18 AM, Dexuan Cui wrote:
> > Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and
> > perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in
> > the PATH when bitbake is running.
> > This can cau
On 06/01/2011 06:18 AM, Dexuan Cui wrote:
> Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and
> perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in
> the PATH when bitbake is running.
> This can cause some race conditions: many places detecting perl from PATH
Hi Dexuan,
On Wed, 2011-06-01 at 21:18 +0800, Dexuan Cui wrote:
> Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and
> perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in
> the PATH when bitbake is running.
> This can cause some race conditions: many places d
Currently both perl-native (a.k.a. ${STAGING_BINDIR_NATIVE}/perl )and
perl-native-runtime(a.k.a. the system perl, or /usr/bin/perl) appear in
the PATH when bitbake is running.
This can cause some race conditions: many places detecting perl from PATH
can't make sure which path will be used as this d
23 matches
Mail list logo
