BBB angstrom-v2013.06 build error with libjpeg-turbo: LIC_FILES_CHKSUM (trunk/trunk?)

I’m trying to build a custom image for the BBB with built in WiFi support for the Edimax EW-7811Un (RTL8192cu). I’m building on a new (clean) Ubuntu 13.04 image. I followed the instructions on the angstrom page:

sudo apt-get install gettext chrpath subversion gawk texinfo g++ git diffstat
git clone git://
git checkout angstrom-v2013.06-yocto1.4
MACHINE=beaglebone ./ config beaglebone
MACHINE=beaglebone ./ update


At this point, I created my own config file in ./sources/meta-ti/recipes-misc/images/ – basically, I copied the cloud9-image and removed cloud9, nodejs and the samples and added wireless-tools, linux-firmware-rtl8192cu and wpa-supplicant.

MACHINE=beaglebone ./ bitbake bbbwifi-image

Seems ok so far … after a while it fails with this error:

ERROR: Function failed: libjpeg-turbo: LIC_FILES_CHKSUM points to an invalid file: /home/winston/Work/bbb/setup-scripts/build/tmp-angstrom_v2013_06-eglibc/work/cortexa8hf-vfp-neon-angstrom-linux-gnueabi/libjpeg-turbo/8d+1.2.1-r2/trunk/cdjpeg.h
ERROR: Logfile of failure stored in: /home/winston/Work/bbb/setup-scripts/build/tmp-angstrom_v2013_06-eglibc/work/cortexa8hf-vfp-neon-angstrom-linux-gnueabi/libjpeg-turbo/8d+1.2.1-r2/temp/log.do_configure.13606
Log data follows:

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: SITE files [‘endian-little’, ‘bit-32’, ‘arm-common’, ‘common-linux’, ‘common-glibc’, ‘arm-linux’, ‘arm-linux-gnueabi’, ‘common’]
DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing shell function do_configure
NOTE: nothing to configure
DEBUG: Shell function do_configure finished
DEBUG: Executing python function do_qa_configure
NOTE: Checking autotools environment for common misconfiguration
DEBUG: Python function do_qa_configure finished
ERROR: Function failed: libjpeg-turbo: LIC_FILES_CHKSUM points to an invalid file: /home/winston/Work/bbb/setup-scripts/build/tmp-angstrom_v2013_06-eglibc/work/cortexa8hf-vfp-neon-angstrom-linux-gnueabi/libjpeg-turbo/8d+1.2.1-r2/trunk/cdjpeg.h
ERROR: Task 2024 (/home/winston/Work/bbb/setup-scripts/sources/meta-openembedded/meta-oe/recipes-core/jpeg/, do_configure) failed with exit code ‘1’


So I took a look in ./build/tmp-angstrom_v2013_06-eglibc/work/cortexa8hf-vfp-neon-angstrom-linux-gnueabi/libjpeg-turbo/8d+1.2.1-r2/trunk and I didn’t find what I expected:

winston@ubuntu-raring:~/Work/bbb/setup-scripts/build/tmp-angstrom_v2013_06-eglibc/work/cortexa8hf-vfp-neon-angstrom-linux-gnueabi/libjpeg-turbo/8d+1.2.1-r2/trunk$ ls
branches tags trunk


Another ‘trunk’ directory which contains the sources for libjpeg-turbo. So somehow I’ve ended up with a ‘trunk/trunk’ when I should have ‘trunk’ (or perhaps script is wrong, but trunk/trunk seems more wrong!).

Any thoughts?




I do not see problem with trunk in trunk.

In my case bitbake fetcher for a given SRC_URI is not downloading files and license paths are incorrect as well.
When replacing appropriate lines in;


I have not had any download problems, I seem to have a different SRC_URI than you. I didn’t apply your proposed fix because it would only fix the LIC_FILES_CHKSUM issue, it still wouldn’t be able to find it to compile it. However, instead I made the following single line change:

S = "${WORKDIR}/trunk"


S = "${WORKDIR}/trunk/trunk"

The libjpeg-turbo then proceeded to build and I did see the do_package_write_ipk step for libjpeg-turbo. Overall, the build has continued well past that now, but I’m still only about 50% complete on the tasks so fingers crossed! But I believe this fixes the libjpeg-turbo issue.

Hope this helps someone.


I have changed SRC_URI by myself.

Usually when there is a problem with the download it is only warning because fetcher IS STILL ABLE to find that package on mirrored sites defined somewhere in bitbake scripts.
For me it wasn’t and that was bad and reason for change.
I am not sure if the structure of the source code for a given library on mirrored sites is always the same and that may be the reason for problem in this case.