ZenLinux Blog

In early November I’ll be in Barcelona for the European Embedded Linux Conference. Once again, I’ll also be involved with running another Yocto Project Developer Day on Nov. 8, the day after ELC-E officially ends.

The intro level hands-on lab class I’ll be teaching has been reworked considerably based on feedback I received from the first event we did in February, to allow for more independent learning/exercises. And as before, we’ll have some hands-on labs for experienced Yocto Project developers as well in addition to a panel discussion.

I’m really excited to help people get started using our build system, and to meet our OpenEmbedded contributors from across the pond. Don’t be a stranger!

After teaching a very successful Yocto Project hands-on lab at the Intel Developer Forum last September, I learned that there was a lot of demand for training resources along these lines. Rather than having me fly out to various Intel sites to teach these courses, I decided it would be better to develop some hands-on labs in video format, so we’d have some “scalable” training materials to meet the demand.

The first screencast video was publicly released last week at the Embedded Linux Conference in Redwood City, CA. It’s a half-hour long and combines some introductory theory with hands-on exercises you can follow along with.

Getting Started with the Yocto Project – New Developer Screencast Tutorial from Yocto Project on Vimeo.

Note: You’ll probably want to view the video in full-screen mode when viewing the more detailed slides and during the live demos. You can also directly download the video in Windows Media format (300 MB) or Ogg Theora format (500 MB).

Topics covered include:

• An overview of the Poky build system
• How the Poky sources are organized (types of metadata and where to find them)
• How to build your first Linux image and run it under emulation
• An introduction to recipes and an explanation of the most common types of metadata, using actual recipe examples
• An introduction to layers
• Where to obtain Yocto BSPs from
• How simple it is to download and enable a Yocto BSP
• Where to find further project resources (documentation, mailing lists, git repository, bugzilla)

By the end of this screencast, a new user will understand fundamental concepts about the build system, and be able to start their exploration of the Yocto Project with a solid foundation of knowledge.

Quite honestly, creating this screencast was pretty agonizing, as the video editing tools Linux offers are either horribly complicated or extremely unstable. Perhaps at some point I’ll write up everything I learned about screencasting and give a talk for PLUG. 🙂

This won’t be the last screencast, but I can’t promise a timetable for the next one just yet.

I’ll be in Redwood City, CA next week for the Linux Foundation’s Embedded Linux Conference. Additionally, I’ll be helping to run the Yocto Developer Day on Tuesday, Feb. 14th.

We’ve got a full day of presentations and hands-on labs geared toward embedded Linux development with Yocto, both for new users as well as more experienced folks. I’ll be teaching the intro hands-on lab with Jessica Zhang, as well as presenting Techniques for Troubleshooting Common Build Errors in the intermedite developer track.

Most of all, I’m really looking forward to meeting members of the OpenEmbedded and Yocto community in person. So please say hello if you’ll be at either of these events!

The following originally appeared on the Yocto Project’s blog:

The Yocto Project’s developers have been working hard to improve the usability of our software, especially its “out of the box” user experience. One area that has admittedly been a thorn in our side is when users need to access the internet via a network proxy server*. I thought I’d take a few moments to explain the situation, why we don’t have a “silver bullet” solution yet, and how to work around it.

If your personal or corporate network doesn’t require you to use a network proxy to access the Internet, consider yourself lucky. Proxies complicate network communications, requiring special protocols (such as SOCKS) to pass your development computer’s packets out to the Internet and back. And while the “do one thing and do it well” design philosophy of Linux/Unix programs has allowed these utilities to weather the test of time extremely well, there is no universally adopted method of modifying the networking behavior of these programs when it comes to using proxies. Here are but a few methods Linux programs can be made to use a proxy server:

• Some utilities check for a special environment variable (HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, etc)
• Many desktop applications (e.g, GNOME apps) look for a proxy settings key in their global desktop registry
• Others (like Subversion, or Mozilla Firefox) have their own config files or internal configuration dialogs where you have to specify proxy settings
• Finally, some programs don’t contain any code for working with network proxies at all! In this case, you can sometimes get away with running the program under a separate, wrapper program which intercepts its network communications and automatically routes them through your proxy (tsocks is one of these wrapper programs)

I’m reminded of the saying: “Standards are like toothbrushes – everyone has one, but no one wants to use anyone else’s.” Truth be told, there is really no single solution to the proxy problem.

Another issue that poses problems for Yocto Project developers is that many of the proxy configurations for various tools (such as Subversion) are stored in the user’s own home directory. And modifying configuration files in your home directory is not something that will endear us to many users.

So what do you need to do to work with the Yocto Project behind a network proxy? Rather than filling this blog post with configuration tips, I’ll refer you to our wiki page, Working Behind a Network Proxy, where we make every effort to keep up to date with configuration tweaks needed for network proxy users.

If anyone can devise a way of reliably automating this process into a support script we could ship with the Yocto Project, we would be very open to including it. Just keep in mind that the script’s actions cannot clobber other config customizations a user may have, and would need to be fully reversible, to work for users who need to move in and out of proxied network environments.

* Note: a network proxy is different from a “firewall” – Yocto builds should work fine when run from behind a typical firewall router. Sometimes the terms “proxy” and “firewall” are used interchangeably, but they are quite different concepts.

I was recently asked to give a short presentation to the Yocto Project team about how to upstream patches most effectively. I thought I’d share it:

I don’t think there’s anything too revealatory here, but it might serve as a good reminder of some best practices for collaborating with open source communities. One thing I will say is that I have been impressed with Intel’s commitment to getting our work integrated upstream when possible. My management really cares about this, not simply because it makes our work easier in the long-run, but because it’s part of being a good open source citizen. And as an additional bonus it keeps us on Greg Kroah-Hartman’s good side. 🙂

chroots provide an extremely useful way of running multiple Linux distros on a single computer without having to run them within a full virtual machine environment. Why would this be an advantage? Well, in my case, I’m performing builds of hundreds of packages for the Yocto Project, and I want to maximize performance by avoiding having to go through a virtualization layer to access my hard disks.

My goal was to create a minimal environment which closely matched what we’re running on some of our autobuilders, which happens to be openSUSE 11.2. It’s easy to set up Debian-based distributions within a chroot by using the debootstrap command, but openSUSE doesn’t have anything analagous to this AFAIK.

It turns out it’s pretty simple to use zypper, openSUSE’s command-line package management utility, to bootstrap an installation into an arbitrary sysroot that you can then use to pull in additional packages over the network. The only caveat is you have to create your initial chroot on an existing openSUSE machine where you have root privileges. Here’s how.

The first thing you’ll need to do is set up the most basic openSUSE package repository config within your sysroot. To create this in the /data/opensuse-11.2 directory, you’d do the following:

mkdir /data/opensuse-11.2
zypper --root /data/opensuse-11.2/ ar http://ftp.osuosl.org/pub/opensuse/distribution/11.2/repo/oss/ repo-oss

Next, you’ll need a /dev/zero device file within your sysroot, since some packages have post-install scripts which make use of it. You can create it manually, but I prefer to simply copy it from /dev:

sudo mkdir /data/opensuse-11.2/dev
sudo cp -a /dev/zero /data/opensuse-11.2/dev/

Presumably you’ll want to move this chroot onto another computer as soon as possible, so here I only install a few needed packages to get started (rpm, zypper, wget, and vim). An editor can be handy in case you need to edit a configuration file (in my case, to configure system-wide proxy settings in /etc/sysconfig/proxy):

sudo zypper --root /data/opensuse-11.2/ install rpm zypper wget vim

At this point you can now tar up the chroot and copy it over to your destination machine of choice. Keep in mind you’ll still need root privileges to tar it up properly:

cd /data
sudo tar cvjf opensuse-11.2.tar.bz2 opensuse-11.2

I use schroot to manage my chroots and highly recommend this little-known utility. It allows you to work within a chroot’ed environment but still have access to your home directory (or any other directory, if you configure it as a bind mount).

After having moved my chroot to its final destination, I added additional zypper repositories and followed the Yocto Project Quick Start Guide to install required build dependencies.

zypper ar http://download.opensuse.org/update/11.2 repo-update
zypper ar http://download.opensuse.org/repositories/security/openSUSE_11.2/ security
zypper ar http://download.opensuse.org/repositories/openSUSE:/Tools:/1.7/openSUSE_11.2/ tools
zypper refresh
zypper install python m4 make ...

From that point on, I could fire up a schroot session anytime I needed to perform builds within a minimal openSUSE 11.2 envrionment with no need to deal with virtualization environments or reboot into another OS.