Actually, I did need the BBMASK so the problem was real. But I didn't need
to include the openembedded-core/meta layer.
Thanks so much for your help. Now to go on to find the next set of
problems...
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
_
> From: Burton, Ross
>
> Ah ha!
>
> poky contains a copy of oe-core, so you don't need both, for a given
> version the meta/ directories will be identical (poky is the union of
> oe-core, bitbake, and meta-yocto).
>
> I'd forgotten that meta-oe used to have guile in. Presumably the
> problem her
Hi Paul,
On 21 March 2013 06:48, Paul D. DeRocco wrote:
> In the metadata trees, meta-openembedded/meta-oe has recipes called
> "guile_1.8.7.bb" and "guile-native_1.8.7.bb". poky-danny-8.0/meta and
> openembedded-core/meta both have recipes called "guile_2.0.6.bb". The latter
> has some extra jun
Still no joy. Nuked tmp/, re-checkedout the current danny branch head on
both meta-openembedded and openembedded-core, and got the same error. Here
are some things I notice about what's in my directory trees:
My build tree shows both guile-1.8.7 and guile-2.0.6 in downloads. It shows
stuff related
On Wednesday, 20 March 2013 at 20:45, Paul D. DeRocco wrote:
> Okay, here goes...
>
> I'll let you know how it comes out, some time tomorrow. I'm compiling it on
> my lowly D2700. ;-)
Oh my!
If you wiped tmp/ but left sstate/, it shouldn't take that long.
Ross
_
> From: Ross Burton
>
> Right. Probably easiest to blow away your tmp/ as it will
> have bits of master in, and downgrading isn't supported.
> > By the way, since you're from Intel, why the hell are they
Okay, here goes...
I'll let you know how it comes out, some time tomorrow. I'm compiling
On Wednesday, 20 March 2013 at 20:35, Paul D. DeRocco wrote:
> They're both current within the last few weeks. However, a bit of history:
> My goal was to add Samba, which is contained in the meta-oe layer of
> meta-openembedded, which also required adding the meta layer of
> openembedded-core. But
> From: Ross Burton
>
> Oky. So what version of oe-core or poky are you using
> that is providing the guile-native? Having autogen-native r3
> implies some revision of master post-danny, as danny (1.3)
> only has autogen-native r2. Either way, both Danny and master
> have guile-native 2.
On Wednesday, 20 March 2013 at 20:06, Paul D. DeRocco wrote:
> > From: Burton, Ross
> >
> > Okay, try doing "bitbake -c devshell autogen-native", and then running
> > "pkg-config --cflags --libs guile-2.0". That should produce errors,
> > which may be more useful. Debugging over email is quite dif
> From: Burton, Ross
>
> Okay, try doing "bitbake -c devshell autogen-native", and then running
> "pkg-config --cflags --libs guile-2.0". That should produce errors,
> which may be more useful. Debugging over email is quite difficult. :(
It complains that guile-2.0 is not found in the pkg-confi
On 20 March 2013 19:43, Paul D. DeRocco wrote:
> That "worked", in the sense of claiming to have executed the do_build task,
> but it happened so fast that I think all it did was run a null make. When I
> then did a bitbake of the entire image, I got the same error I got before,
> about not being
> From: Burton, Ross
>
> Yep, so it should, I was wrong. Try bitbake -f guile-native. The
> dependencies say that you should have guile-native already, so I don't
> know why it would be failing.
That "worked", in the sense of claiming to have executed the do_build task,
but it happened so fast
On 20 March 2013 18:11, Paul D. DeRocco wrote:
>> From: Burton, Ross
>>
>> autogen-native depends on guile-native so that should have worked -
>> try doing "bitbake -ccleansstate guile-native ; bitbake guile-native"
>> to force that to be rebuilt.
>
> It complains that guile-native doesn't have a
> From: Burton, Ross
>
> autogen-native depends on guile-native so that should have worked -
> try doing "bitbake -ccleansstate guile-native ; bitbake guile-native"
> to force that to be rebuilt.
It complains that guile-native doesn't have a task called do_cleanstate.
--
Ciao, Pa
On 13 March 2013 06:53, Paul D. DeRocco wrote:
> One thing that I notice is that in my build/tmp/work/i686-linux, I have two
> directories, autogen-native-5.12-r2 and autogen-native-5.12-r3. The first is
> from my successful out-of-the-box build of a week ago; the second is from my
> current faile
"Paul D. DeRocco" writes:
>> From: Burton, Ross
>>
>> On 12 March 2013 18:20, Paul D. DeRocco
>> wrote:
>> > It says "attempted 145 tasks of which 145 didn't need to be
>> > rerun". So it thinks it's already there.
>>
>> Indeed. Something is breaking - you'll have to mail the whole
>> conf
Hi Paul,
On 12 March 2013 18:20, Paul D. DeRocco wrote:
> It says "attempted 145 tasks of which 145 didn't need to be rerun". So it
> thinks it's already there.
Indeed. Something is breaking - you'll have to mail the whole
configure log from autogen to attempt to debug this.
> Or is it now co
> From: Burton, Ross
>
> autogen-native should be building guile-native, you won't need the
> host guile. Can you confirm that by running "bitbake guile-native"?
It says "attempted 145 tasks of which 145 didn't need to be rerun". So it
thinks it's already there.
Or is it now confused by the fac
On 12 March 2013 02:28, Paul D. DeRocco wrote:
> I'm bitbaking a console image for an Atom, which worked when I did a plain
> vanilla version. Now I've added the OpenEmbedded layer containing Samba, and
> it's failing on one thing. The error message points me to a 5000-line log
> file called
> bui
I'm bitbaking a console image for an Atom, which worked when I did a plain
vanilla version. Now I've added the OpenEmbedded layer containing Samba, and
it's failing on one thing. The error message points me to a 5000-line log
file called
build/tmp/work/i686-linux/autogen-native-5.12-r3/temp/log.do_
20 matches
Mail list logo
