Page History

As with any complex system, the real answer is it depends, but of course that is not very helpful. The simplest method for adding a single package to your build is to add a line like this to add 

the below line to conf/local.conf:

• IMAGE_INSTALL_append = " package"

Use your own package name in place of package. Note the leading space before the package name. If you want to add multiple packages, you can use multiple lines like the above, or list all packages on a single line with:

• IMAGE_INSTALL_append = " package1 package2 package3"

Although If we you add in local.conf , that is not permanent change. For permanent addition of that package in final rootfs, you need to be added in image recipe or any package group which is included in the image recipe.

Prebuilds are handled internally by Yocto by using sstate-cache. If a prebuilt from a known good build is available, the build can point to that folder via the conf file inside the ./build<buildtype>/conf/ folder so that the prebuilts are picked up from the location

bitbake has division of work into individual tasks for a component. Secondly, the recipes are wired to notice changes in upstream repository as well when you do repo sync. You can use below command to see what all individual tasks are available.

bitbake -c listtasks <component>

It will show an output like

do_build                       Default task for a recipe - depends on all other normal tasks required to 'build' a recipe

do_bundle_initramfs            Combines an initial ramdisk image and kernel together to form a single image

do_checkuri                    Validates the SRC_URI value

do_checkuriall                 Validates the SRC_URI value for all recipes required to build a target

do_clean                       Removes all output files for a target

do_cleanall                    Removes all output files, shared state cache, and downloaded source files for a target

do_cleansstate                 Removes all output files and shared state cache for a target

do_compile                     Compiles the source in the compilation directory

You can rerun any of the above tasks

bitbake -C compile rdkbrowser

would force recompile of servicemanager, if you wish to perform all the build steps for a component you can do that too by

bitbake -c cleansstate rdkbrowser; bitbake rdkbrowser

Similarly, in general we you can have:

bitbake <target> -c<task_to_be_executed>

This will ensure do_<task_to_be_executed>() will be called.

task_to_be_executed can be can  fetch, unpack, configure, compile, install, package etc

If we were to draw parallels

--rebuild = bitbake -c cleansstate <component> ; bitbake <component>

--build-only = bitbake <component>

--skip-package is delegated to shared state mechanism to figure out at present.

Unless you do 'repo sync' sources should will not be updated

'repo sync' can cover only components with external src support, it means that in cases when SRCREV is set to AUTOREV and component doesn't support external src, then bitbake will try to update sources from a remote repository during build time.

There is no documentation for AUTOREV, but it's doing only one function - check remote repository for any new sources updates.

You can prevent this behaviour by changing BB_SRCREV_POLICY variable in you local <sandbox>/conf/local.conf

• You can find log files for each task in the recipe's temp directory. Log files are named log.taskname-Eg:compile logs are present in the file log.do_compile. Bitbake maintains logs separately for each of the tasks that run while building the component. These tasks are typically the fetch task, the compile task, install task and so on.
• Eg: For a RPI device, typically logs are present under the build-raspberrypi-rdk-hybrid//tmp/work/<*-rdk-linux> and under the component directory. Other devices would have logs present under similar folders. On my systemFor instance, logs are present under build-raspberrypi-rdk-hybrid/tmp/work/<*-rdk-linux>/rdkbrowser/1.99+gitAUTOINC+8c3f17fdc6_fa6c8b4334_dc33f7d6bc_4bc1f2f4c9-r0/temp

* satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-...:

*             net-snmp *

* opkg_install_cmd: Cannot install package packagegroup-....

Such errors mean this The above error indicates that :

You asked for adding net-snmp ( the package ) not ( the recipe ) now net-snmp ( the recipe ) may generate a number of ( packages ) so you should add the packages ( runtime items) to the package groups and not the recipes ( build time items). Usually yocto/OE does generate a output package with same name as input recipe so for net-snmp.bb there will be a net-snmp ipk but thats just a common case not a hard and fast rule.

Now in this particular case when a package has nothing to emit into the ${PN} package the package is left empty and hence not emitted. If you want to emit the package regardless you have to add

ALLOW_EMPTY_<package> = "1" in the recipe,but this is less of a usecase to demand empty packages. If you expressed the packagegroup RDEPENDS correctly you would not need it.

• Sometimes when you have a working branch which is not checked out or has uncommitted changes then repo will fail when you try to sync to the latest code base.
• The

  Sample failure logs

  might look something like below.

  :

error: generic/devicesettings/generic/: contains uncommitted changes

error: generic/rdkbrowser/: branch master is published (but not merged) and is now 11 commits behind

error: meta-rdk-oem-X/: contains uncommitted changes

• To resolve this you need to checkout the branch and rebase it to the master using below commands.

git rebase —abort

git rebase rdkgerrit/master ( or rdkgerrit/stable2)

• During the process git might throw conflict errors if it cannot merge files automatically. Then you need to merge manually using Vim or any other text editors. But it can be simple if you know exactly what changes needs to be saved / removed.
• For example you can use below command to keep your changes

git checkout --ours FILE

• If you want to run on multiple files then use below command.

grep -lr ‘<<<<<<<<’.  |  xargs git checkout --ours

• Similarly,  you can use below commands if you want to keep other changes.

git checkout --yours FILE

grep -lr ‘<<<<<<<<’.  |  xargs git checkout –theirs

Common build failures are reported in Yocto builds. Some build failures are hard to analyze with logs, unless we get access to the failure workspace. In most cases they are hard to reproduce on local workspace. We go through multiple iteration of builds, lock down the node and then debug. To debug these failures use Packages file found under tmp/deploy/ipk directory on you local workspace .

This should be because of arch architecture bit mismatch . To overcome this should either choose the right target platform or put the executable file as a tar file in bb file.

Issue:

The issue is observed during setup and machine selection stage, setup-environment script will through throw unexpected error about non-existing layer paths.

Example console log:

gpsahu01@dvm-wcdcc-tata-001:~/cmf/emulator-2.1-20160919$ source meta-cmf/setup-environment

1) meta-raspberrypi/conf/machine/raspberrypi0.conf             7) meta-rdk-bsp-emulator/conf/machine/qemux86hyb.conf

2) meta-raspberrypi/conf/machine/raspberrypi2.conf             8) meta-rdk-bsp-emulator/conf/machine/qemux86mc.conf

[…]

Please enter your choice of machine [1..11]: 7

### Shell environment set up for builds. ###

Writing auto.conf ...

Writing versions.txt ...

-bash: cd: ../meta-browser//: No such file or directory

fatal: Not a git repository (or any parent up to mount point /mnt)

Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

-bash: ../patches/rdk-oe/meta-linaro//*.patch: No such file or directory

-bash: cd: ../meta-openembedded//: No such file or directory

fatal: Not a git repository (or any parent up to mount point /mnt)

Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Possible solution:

If the host PC has set colored terminal output for commands then it may cause unexpected errors being shown during execution of meta-cmf/setup-environment script. To fix the problem we can run following command:

gpsahu01@dvm-wcdcc-tata-001:~/cmf/emulator-2.1-20160919$ alias ls='ls --color=no'

Looks like memory issue hence changing Ubuntu to 64 bit version should resolve the issue. The below are the Ubuntu configurations,

• Ubuntu 16.04 - 64 bit
• 6GB RAM

16GB Swap

To include a specific feature that is not available in base build, enable the feature specific DISTRO flag in platform specific config file. For example to include USPA feature in Rpi build,

Add the DISTRO specific flag in Rpi platform specific conf file

In File meta-cmf-raspberrypi/conf/distro/include/rdk-rpi.inc

Add DISTRO_FEATURES_append = " usppa" (to include the feature if not there)

DISTRO_FEATURES_remove = " usppa" (to remove the feature)

Make sure the recipe is part of the package build

In File meta-rdk/recipes-core/packagegroups/packagegroup-rdk-ccsp-broadband.bb

must be included as a DISTRO protected feature

RDEPENDS_packagegroup-rdk-ccsp-broadband += " \ ${@bb.utils.contains('DISTRO_FEATURES', 'usppa', "usp-pa", "", d)}"

Please refer Compile-time Build Variants Flags

Sample Error Example Console Log :

repo: warning: Python 2 is no longer supported; Please upgrade to Python 3.6+.
Downloading Repo source from https://gerrit.googlesource.com/git-repo
remote: Finding sources: 100% (32/32)
remote: Total 32 (delta 14), reused 32 (delta 14)
Unpacking objects: 100% (32/32), done.
File "/mnt/home /cmf/.repo/repo/main.py", line 79
file=sys.stderr)
^
SyntaxError: invalid syntax

If you're using an older system without Python 3.6+, try downloading an older version of the Repo Launcher that still supports Python 2.7.

Possible Solution :

# create a bin directory

mkdir ~/bin

export PATH=~/bin:$PATH

curl https://storage.googleapis.com/git-repo-downloads/repo-1 > ~/bin/repo

chmod a+x ~/bin/repo