The Hob project represents a GUI alternative to the BitBake build system. Its purpose is to execute the most common tasks in an easier and faster manner, but it does not make command-line interactions go away. This is because most parts of recipes and configurations still need to be done manually. In the previous chapter, the BitBake Commander extension was introduced as an alternative solution for the editing of recipes, but in this project, it has its limitations.
Hob's primary purpose is to allow interaction with the build system made easier for users. Of course, there are users who do not prefer the graphical user interface alternatives to command-line options, and I kind of agree with them, but this is another discussion altogether. Hob can be an option for them also; it is an alternative not only for people who prefer having an interface in front of them, but also for those who are attached to their command-line interaction.
In this chapter, I will show you how to use the Hob project to build a Linux operating system image. To demonstrate this, I will use the Atmel SAMA5D3 Xplained machine, which is what I also used for other demonstrations in previous chapters.
To retrieve the graphical interface, the user needs perform the given steps required for the BitBake command-line interaction. Firstly, it needs to create a build directory and from this build directory, the user needs to start the Hob graphical interface, using the Hob commands, given as follows:
The next step is to establish the layers that are required for your build. You can do this by selecting them in the Layers window. The first thing to do for the meta-atmel layer is to add it to the build. Although you may start work in an already existing build directory, Hob will not be able to retrieve the existing configurations and will create a new one over the bblayers.conf and local.conf configuration files. It will mark the added lines using the next #added by hob message.
After the corresponding meta-atmel layer is added to the build directory, all the supported machines are available in the Select a machine drop-down, including those that are added by the meta-atmel layer. From the available options, the sama5d3-xplained machine needs to be selected:
When the Atmel sama5d3-xplained machine is selected, an error, shown in the following screenshot, appears:
Since all the available configuration files and recipes are parsed, the parsing process takes a while, and after this, you will see an error, as shown in the following screenshot:
After another quick inspection, you will see the following code:
The only explanation is the fact the meta-atmel layer does not update its recipes but appends them. This can be overcome in two ways. The simplest one would be to update the recipe the .bbappend file and make sure that the new available recipe is transformed into a patch for the upstream community. A patch with the required changes inside the meta-atmel layer will be explained to you shortly, but first, I will present the available options and the necessary changes that are needed to resolve the problems existing in the build process.
After this problem is fixed, new options will be available to the user, as depicted in the following screenshot:
Now, the user has the chance to select the image that needs to be built, as well as the extra configurations that need to be added. These configurations include:
Some of these are depicted in the following screenshot:
I've chosen to change the distribution type from poky-tiny to poky, and the resulting root filesystem output format is visible in the following screenshot:
With the tweaks made, the recipes are reparsed, and when this process is finished, the resulting image can be selected so that the build process can start. The image that is selected for this demonstration is the atmel-xplained-demo-image image, which corresponds to the recipes with the same name. This information is also displayed in the following screenshot:
The build process is started by clicking on the Build image button. A while after the build starts, an error will show up, which tells us that the meta-atmel BSP layer requires more of the dependencies that need to be defined by us:
This information is gathered from the iperf recipe, which is not available in the included layers; it is available inside the meta-openembedded/meta-oe layer. After a more detailed search and update process, there have been a few revelations. There are more layer dependencies than required for the meta-atmel BSP layer, which are given as follows:
- Replace
packagegroup-core-basicwithpackagegroup-core-full-cmdlinebecause the latest Poky has updated thepackagegroupnames. - Delete
python-setuptoolsbecause it is not available in themeta-openembedded/meta-oelayer anymore, as well as in the newmeta-openembedded/meta-pythonlayer, which is the new placeholder for all Python-related recipes. Thepython-setuptoolstool was removed because it had the ability to download, build, install, upgrade, and uninstall extra Python packages, and is not a mandatory requirement for Yocto. This is its general purpose. - The preceding change regarding the update to
qt4-embedded-4.8.6forqt4-embedded-4.8.5, as shown earlier, presented errors.
All the changes made to the meta-atmel layer are available in following patch:
This patch has been given in the chapter as an example for Git interaction and is a necessity when creating a patch that needs to be upstream to the community. At the time of writing this chapter, this patch had not yet been released to the upstream community, so this could be a gift for anyone interested in adding a contribution to the meta-atmel community in particular and the Yocto community in general.
Toaster represents an alternative to Hob, which at a given point in time, will replace it completely. It is also a web-based interface for the BitBake command line. This tool is much more effective than Hob; it is not only able to do the most common tasks in a similar manner as Hob, but it also incorporates a build analysis component that collects data regarding the build process and the resultant outcome. These results are presented in a very easy-to-grasp manner, offering the chance to search, browse, and query the information.
From the collected information, we can mention the following:
- Structure of the image directory
- The available build configurations
- The outcome of a build along with the errors and registered warnings
- The packages present in an image recipe
- Recipes and packages that are built
- Tasks that are executed
- Performance data regarding executed tasks, such as CPU usage, time, and disk I/O usage
- Dependency and reverse dependencies for recipes
There are also some drawbacks to the Hob solution. Toaster does not yet offer the ability to configure and launch a build. However, there are initiatives taken to include these functionalities that Hob has inside Toaster, which will be implemented in the near future.
- Interactive mode: This is the mode available and released with the Yocto Project 1.6 release version. It is based on a
toasteruibuild recording component and atoasterguibuild inspection and statistics user interface. - Managed mode: In addition to the Yocto Project 1.6 release version, this is the mode that handles build configurations, scheduling, and executions that are triggered from the web interface.
- Remote managed mode: This is a hosted Toaster mode and is defined for production because it offers support for multiple users and customized installations.
- Local managed mode or _local_ is: This is the mode available after a Poky checkout and permits running builds using the local machine code and build directory. It is the also used by anyone who interacts with a Toaster project for the first time.
- For the interactive mode, building with tools, such as AutoBuilder, BuildBot, or Jenkins, a set up separated from the hardware on which the Yocto Project builds are running will be required. Behind a normal instance of Toaster, there are three things that happen:
- A BitBake server is started
- A Toaster UI is started and connected to the BitBake server as well as to an SQL database
- A web server is started for the purpose of reading information related to a database and displaying it on the web interface
To set up an SQL server on a Ubuntu machine, a package needs to be installed, using the following command:
With the set up done, the database synchronization can begin in the following way:
After this is done, the normal build process can be started and builds can begin while the build is running inside the web interface logs and data is available to be examined. One quick mention, though: do not forget to kill the BitBake server after you have finished working inside the build directory using the bitbake –m command.
Run a build in the console, and it will be automatically updated in the web interface, as shown in the following screenshot:
After the build is finished, the web interface will be updated accordingly. I closed the header image and information to make sure that only the builds are visible in the web page.
For the failing build, a detailed fail report is available, as displayed in the following screenshot:
The build that finished successfully offers access to a lot of information. The following screenshot shows interesting features that a build should have. It shows, for the kernel build, all the BitBake variables used, their values, their location, and a short description. This information is very useful for all developers, not only because it offers all of this at a single location, but also because it offers a search option that reduces the search time spent looking for a troublesome variable to a minimum:
To stop Toaster, the source toaster stop command can be used after the execution activities are finished.
bitbake-cookerdaemon.log: This log file is necessary for the BitBake server.toastermain.pid: This is the file that containspidof the web server.toasterui.pid: It contains the DSI data bridge,pidtoaster.sqlite: This is the database filetoaster_web.log: This is the web server log filetoaster_ui.log: This is the log file used for components of the user interface
Autobuilder is the project responsible for QA, and a testing build is available inside the Yocto Project. It is based on the BuildBot project. Although this topic isn't dealt with in this book, for those of you interested in the BuildBot project, you can find more information about it in the following information box.
Note
The starting page of Buildbot can be accssed at http://trac.buildbot.net/. You can find a guide on quick starting BuildBot at http://docs.buildbot.net/0.8.5/tutorial/tour.html, and its concepts can be found at http://docs.buildbot.net/latest/manual/concepts.html.
We are now going to address a software area that is very poorly treated by developers in general. Here, I am referring to the testing and quality assurance of a development process. This is, in fact, an area that requires more attention from us, including me as well. The Yocto Project through the AutoBuilder initiative tries to bring more attention to this area. Also, in the past few years, there has been a shift toward QA and Continuous Integration (CI) of available open source projects, and this can primarily be seen in the Linux Foundation umbrella projects.
- Publishing the testing and QA plans using Bugzilla test cases and plans (https://bugzilla.yoctoproject.org).
- Demonstrating these plans and making them accessible for everyone to see. Of course, for this, you will need a corresponding account.
- Developing tools, tests, and QA procedures for everyone to use.
Having the preceding activities as a foundation, they offer access to a public AutoBuilder that shows the current status of the Poky master branch. Nightly builds and test sets are executed for all the supported targets and architectures and are all available for everyone at http://autobuilder.yoctoproject.org/.
To interact with the AutoBuilder Project, the setup is defined in the README-QUICKSTART file as a four-step procedure:
At this point, the AutoBuilder should be running. If it is started inside a web interface, the result should look similar to the following screenshot:
As it can be visible from the header of the web page, there are multiple options available not only for the executed builds, but also for a different view and perspective of them. Here is one of the visualization perspectives:
