Hi,
I tried to do a create a DSP decoding capable image in narcissus but it failed:
ti-codec-engine-examples - package does not exist
ti-dmai-apps - unsatisfied dependency: ti-codecs-omap3530-server
ti-dmai-tests - unsatisfied dependency: ti-codecs-omap3530-server
It seems all codec packages have been removed from the beagle feed. So
to avoid further spamming of the mailing list and irc channel, I ask,
are these removed on purpose?
Regards,
Gyorgy
Hi,
Could somebody give me an estimate of what's needed for a build
of beagleboard-demo-image from the org.openembedded.dev git branch?
I've just run out of space on a 40GB VirtualBox drive image which I've
extended twice by 10GB each time (which is a real pain with VirtualBox
for some reason - doesn't seem to be any easy way other than copying)
I'm a little space constrained on the physical drive so knowing whether
50GB or 60GB is going to suffice would help me a lot.
Thanks!
Alex
i just finished building that image from the latest git pull on the
dev branch, and here's my disk usage under my self-contained oe/
directory:
$ du -s *
24267608 angstrom-dev
12 build
4222844 downloads
683768 openembedded
4 source-me.txt
$
unsurprisingly, the vast majority of space is eaten up by the output
(angstrom-dev) directory, and a bit more by the downloads directory.
this is on a ubuntu pre-maverick gateway laptop with 4G of RAM.
rday
Put this token in local.conf
INHERIT += “rm_work”
it will solve your disk problems 
2010/9/3 Robert P. J. Day <rpjday@crashcourse.ca>
Put this token in local.conf
INHERIT += "rm_work"
it will solve your disk problems
Fantastic. Thanks Maxim / Rday 
Hi Maxim,
Oddly enough, I find I already have this in my ~/OE/build/conf/local.conf,
and yet when I du I see that around 14GB of space is all going in
~/OE/tmp-xyz/work/armv7a-angstrom-linux-gnueabi.
V. strange
Alex,
“rm_work” works only if you build OE from scratch. If you have a ton of compiled sources this option can do nothing to them. If you insert “rm_work” in a middle of the building process then all remaining sources will be cleaned during the procedure.
Max
2010/9/3 Alex J Lennon <ajlennon@dynamicdevices.co.uk>
Hi Max,
>"rm_work" works only if you build OE from scratch. If you have a ton of compiled sources this option can do nothing to them. If you insert "rm_work" in a middle of the building process then all remaining sources will be cleaned during the procedure.
Thanks for coming back to me. I'm pretty certain I pulled this OE tree out of GIT dev onto a clean disk,
and I haven't added rm_work to the local.conf so it should have been there since the start of the build.
I'm out at meetings today so I'll clean down tmp_xx, build from scratch, and see what happens.
Cheers,
Alex
Alex,
"rm_work" works only if you build OE from scratch. If you have a ton of compiled sources this option can do nothing to them. If you insert "rm_work" in a middle of the building process then all remaining sources will be cleaned during the procedure.
That's not quite true. If you add rm_work, it will run rm_work_all recursively on all the dependencies of the target you bitbaked. So it you do 'bitbake console-image' it will remove all work dirs from the stuff in that image.
regards,
Koen
Hi,
That's not quite true. If you add rm_work, it will run rm_work_all recursively on all the dependencies of the target you bitbaked. So it you do 'bitbake console-image' it will remove all work dirs from the stuff in that image.
I'm not sure where I'm going wrong but the local.conf looks right. I deleted the temp dir and started a bitbake of beagleboard-demo-image.
Coming back to it tonight the f/s is at 100% and those work directories are not being cleared out.
All I can imagine is my .conf is in the wrong place, but it looks right...
Alex/