The OpenEmbedded project has started to maintain a stable branch, next to its development branch, on March 28th 2007. Besides "org.openembedded.dev" there now is the "org.openembedded.stable" branch.

The plumbing work on the development branch (long-term improvements such as packaged staging, creating stand-alone SDK toolchains and a new package manager) colides with the goal of offering a stable base for OpenEmbedded-derived distributions. Some projects, most notably the Angstrom distribution, already maintained a stable branch for this reason.

The effort of maintaining a stable branch is now centralized back into the OpenEmbedded project. The main goal of the stable branch is to provide a branch that progresses in time with a minimum of disruptive changes, especially to the framework, which include classes, configuration namespace, package management, and tooling such as the bitbake tool. Changes to the stable branch are selected and reviewed according to an agreed upon policy before being committed to the stable branch. This will require extra effort from the OpenEmbedded developer community.

The stable branch is not intended to keep up with the pace of development on the development branch. Planned is to create new stable branches every year; the next stable branch is scheduled to branch of the development tree during 2008.12. Old stable branches will go in unmaintained mode 3 months after a new stable branch is created; the current stable will retire 2009.2.

OpenEmbedded projects and distributions now have the choice of at least a .dev and .stable branch and the OpenEmbedded developers can keep on plumbing.

mailinglist | ViewMTN

The friendly folks at OpenMoko, Inc. just told us that they have hired a developer that will work full-time on the OpenEmbedded distribution. They aim for a 50/50 split in dealing with OpenMoko-specific issues and distribution independent issues.

Although this split is tentative and may switch on-demand (when OpenMoko has more work to do), we think it's a great thing for us. We are not allowed to disclose the name of the developer yet -- please wait for an official OpenMoko announcement.

Holger Freyther has finally found some time to finish a BitBake class, which is called insane.bbclass. This class is inspired by some early bugs in OpenEmbedded (e.g. the unzip package), and other bug reports and issues we have found during development. E.g. when creating the dedicated debug packages. Some packages are inspired by portage QA script. The goal of this BitBake class, similiar to the fail-fast patchset (remember CROSS COMPILE Badness?), is to increase quality and to find issues at compile time before someone is shipping the first package with easy and obvious issues. The insane.bbclass executes a set of unsound and incomplete tests on the packages, the content and the staging area to identify troublesome issues and will report them. These tests include at the moment:

• A test to find config.log files in the current $WORKDIR to search for the "CROSS COMPILE Badness" string. Finding this string indicates some troubles with the configure script which are in conflict with the OpenEmbedded goals in creating a deterministic system. E.g. gnome- vfs, mp3blaster and mpd are known to fail this test. For convenience these scripts add /usr/include to the CPPFLAGS to find headers. For OpenEmbedded there is no excuse to search in these directories. To solve such issues it might be as easy as specifying additional parameters in EXTRA_OECONF or just fixing the configure script.
• RPATH inside shipped binaries. RPATH to world writable directories could expose security issues and for an OE based distribution there is probably no excuse in having rpath set. Note that -rpath-link is considered okay and probably should be used.
• permissions: Well we do not check permissions of directories, setuid'ed binaries and other files. E.g. we do not want world writable executable which might get the setuid bit set. Once such an issue is detected you can fix these by either adjusing the custom do_install task, or the package itself
• .so symlinks in non -dev packages These symlinks indicate -dev packages and should be shipped in those packages. Normally you will adjust the FILES_* section to fix this issue
• non debug (-dbg) package RDEPENDS on -dbg package Well a non debug package depends on libraries from a -dbg package. This can only be a packagign bug. This can be either a bug in the package itself, or the package you RDEPEND on.
• .la files All libtool file should under no circumstances point to the $WORKDIR. This is a bug that should be fixed! And there is a lot to be fixed. This can be either hacked with sed or some proper solution I don't know. For packaged and -native staged files installed should be set to yes (installed=yes). E.g. installed=no is the wrong answer and shows an error. So make sure that installed=yes is found For -native staged files there should be no trace to /usr/include For packaged files the libdir should be /usr/lib Sadly there a lot of -native packages that need fixing, more than one of us can handle alone.
• .pc files Similiar to libtool files, no direct reference to directories should be included. A bad example is croco from GNOME, and a patch for it is included in OpenEmbedded.
• checking Architecture and ABI of binary files. If alpha is the PACKAGE_ARCH we will make sure alpha binaries are inside this package. If this is not the case check the compile log and see which compiler was used and fix the buildsystem.

The Angstrom Distribution is an early adaptor of this BitBake class and we might find issues and hopefully you will be able to spare a patch and improve the quality. It has never been so easy.

The OpenEmbedded Tinderbox is getting better and better with the huge effort Holger is putting into it, and after some css hacking by Koen it's looking like the main OE website.
You can view the tinderbox by clicking on the link in the menu on the left. Please help us with our QA by adding your thoughts to the QA page.

As seen on slashdot.org:

NewsForge is reporting on a recent discovery by Warren Woodford about how the GPL could affect derivative Linux distributions. This could make life difficult for those small distros that are being maintained by one or two people in their spare time due to the high amount of work it creates. From the article:

    "Woodford does supply the source code for MEPIS' reconfigured kernel in a Debian source-package. His mistake seems to have been the assumption that, so long as the source code was available somewhere, he did not have to provide it himself if he hadn't modified it. While he has not contacted any other distributions, he suspects that he is far from the only one to make this assumption. 'We, like 10,000 other people, probably, believed we were covered by the safe harbor of having an upstream distribution available online,' Woodford says. 'I think, of the 500 distributions tracked by DistroWatch, probably 450 of them are in trouble right now per this position.'"

This means that people that distribute GPL'ed binaries built with OE need to provide sources themselves, vigorous handwaving and pointing to http://www.oesources.org/source/current/ won't do.

But how do you distribute sources in an automatic way using OpenEmbedded? The solution is easy - a few lines added into conf/local.conf will solve it:

SRC_DIST_LOCAL = "copy"

INHERIT += "src_distribute_local"

Now each recipe which has a LICENSE that mandates source availability like the GPL will be copied into SRC_DISTRIBUTEDIR dir (by default it is tmp/deploy/sources/) after building.
The list of licenses is configurable via conf/licenses.conf - The OpenEmbedded metadata already contains that file with some popular licenses added.

About one month ago one OpenZaurus user contacted Marcin 'hrw' Juszkiewicz and Michael ‘mickeyl’ Lauer with info that he want to donate two Zaurus machines to project - SL-6000L (tosa) and SL-5600 (poodle). After some discussion both machines was sent to Marcin - he will keep tosa for some time to resolve some of bugs, poodle will go to Mickeyl. Both machines are added into OpenEmbedded project devices.

Plan is to flash both machines to OpenZaurus 3.5.4 + upgrades and do work to get their bugs fixed and improve their support in OE.

Überhacker Holger 'Zecke' Freyther commited a patch that allows testing for bogus local includes (i.e. /usr/include) that contaminate builds and is the reason for unnoticed bugs and noticed ones like missing references etc.

This patch is now active in the .dev branch. You might see it working when you encounter the following message:

| CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/libxml2

In that case, please tell us the package and help us to fix its build system. Thanks.

If you are desperate to use .dev but don't have the time to fix the build system, you may remove 'fail-fast' from the list of OVERRIDES in conf/bitbake.conf.

Michael Lauer (mickeyl) May, 20th, 2006.

A new edition of the OOO Newsletter is available, covering the latest news in the BitBake, OpenEmbedded, OE-based distributions, Opie, GPE, and Ångström projects.

Michael Lauer (mickeyl) May, 8th, 2006.