TipsAndTricks/CropsCLIContainers
CROPS or How to Run bitbake/devtool/eSDK/Toaster on Your MacWinux Host
Introduction
CROPS provides CLI containers that allow you to run the set of tools listed in the title on Mac OSX, Windows or Linux. The containers themselves are available on Dockerhub at https://hub.docker.com/u/crops/dashboard/
You may wonder why you would use these containers on Linux. The main reason is it gives you a guaranteed clean environment from which to build. Also it means you don't need to install the dependent packages required by the build tools. Measurements show no speed degradation when running in the container. This wiki assumes you have followed the basic documentation on the CROPS github Readme's (like https://github.com/crops/poky-container) and are looking for more tips.
NOTE: ALL the CROPS containers take a --help argument in case you forget the options! For example:
docker run -it --rm crops/poky --help
usage: poky-entry.py [-h] [--workdir WORKDIR] [--id ID]
optional arguments:
-h, --help show this help message and exit
--workdir WORKDIR The active directory once the container is running. In
the abscence of the "id" argument, the uid and gid of the
workdir will also be used for the user in the container.
--id ID uid and gid to use for the user inside the container. It
should be in the form uid:gid
Variations Explained
Poky
The default Poky container is quite generic and will work with most recent releases of YP. Despite the name, it simply contains all the dependent packages required by Poky but not the meta-data. It will work equally well for an OE Core setup. The default container is based on the latest Ubuntu LTS that YP supports. We are in the process of creating ones based on the rest of the standard supported Linux Distro's. For the common usage; however, which Distro is inside is irrelevant since everything is already set up for the user.
eSDK
The eSDK container is also generic in that it takes an extensible sdk install script as an argument so it can be used with a fairly arbitrary ext-sdk. It works equally well with an old fashioned sdk (e.g. one without devtool but with a sysroot and a toolchain).
Toaster
Toaster is more complicated. To facilitate quick startup, the Toaster containers include a database prepopulated from the layer index https://layers.openembedded.org. Because of this, the toaster containers come in a couple of varieties.
- Toaster - https://hub.docker.com/r/crops/toaster/ - This is the last official release YP has available. At the time of writing this T&T, for instance, this is krogoth and will soon be morty.
- Toaster-krogoth - https://hub.docker.com/r/crops/toaster-krogoth - The krogoth release.
- Toaster -morty - https://hub.docker.com/r/crops/toaster-morty/ - The RC release. We created this once the morty branch was named/made.
- Toaster-master - https://hub.docker.com/r/crops/toaster-master/ - This is the ever changing master version. A new image is built for every commit to http://git.yoctoproject.org/cgit/cgit.cgi/poky/ on the master branch. We keep ~ 2 weeks back. A
docker pull toaster-master
will give you the latest commit. If you want a particular commit, look at the tags page: https://hub.docker.com/r/crops/toaster-master/tags/ and you see a number of options.- latest - the last successful (passed the Travis test viewable at https://travis-ci.org/crops/toaster-container )
- latest-<date>-<commitish> - the latest tag points to the last of these. We also keep old ones around for ~ 2 weeks.
- toaster-next-<date>-<commitish> - This is built using the toaster-next branch of poky-contrib http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=toaster-next. This is intended for people actively developing toaster source code itself.
Operating System Oddities
While the purpose of the CROPS cli containers is to insulate the user from the vagaries of the host os, sometimes the oddness creeps in. Instructions and explanations for Mac and Windows can be found here: https://github.com/crops/docker-win-mac-docs/wiki
Issues with File Paths
While the default way to run the containers (using crops/poky as an example but this applies equally well to the others).
docker run --rm -it -v /home/myuser/mystuff:/workdir crops/poky --workdir=/workdir
highlights the fact that the directory path inside the container is independent of the directory path on the host, this can sometimes be confusing. So, it is also quite reasonable to run the container like so:
cd /home/myuser/mystuff docker run --rm -it -v $(pwd):$(pwd) crops/poky --workdir=$(pwd)
This way, inside the container you have the same directory path as you do outside of the container. For things like
devtool modify busybox devtool find-recipe busybox
this can make cutting and pasting easier from the "in container terminal" which lacks an editor into the editor or terminal with an editor on the host system.
Workflow
I tend to run this under tmux. I keep one tmux panel inside the container for commands and another outside the container to do host side editing/git operations.
Git issues
Sometimes i try to do something in the container like git stash save "my stash" and it fails telling me that pokyuser does not have a default git user or email setup. There are 2 ways to work around this.