The Ubuntu Developer Summit was held in Copenhagen last week, to discuss plans for the next six-month cycle of Ubuntu. This
was the most productive UDS that I've been to — maybe it was the shorter four-day schedule, or the overlap with Linaro Connect, but it sure felt like a whirlwind of activity.
I thought I'd share some details about some of the sessions that cover areas I'm working
on at the moment. In no particular order:
This plan is a part of a mutli-cycle effort to improve cross-compilation
support in Ubuntu. Progress is generally going well — the consensus from the
session was that the components are fairly close to complete, but we still
need some work to pull those parts together into something usable.
So, this cycle we'll be working on getting that done. While we have a few
bugfixes and infrastructure updates to do, one significant part of this cycle’s
work will be to document the “best-practices” for cross builds in Ubuntu, on
wiki.ubuntu.com. This process will be
heavily based on existing pages on the Linaro wiki. Because most of the
support for cross-building is already done, the actual process for
cross-building should be fairly straightforward, but needs to be
I'll post an update when we have a working draft on the Ubuntu wiki,
stay tuned for details.
Rapid archive bringup for new hardware
I'd really like for there to be a way to get an Ubuntu archive built
“from scratch”, to enable custom toolchain/libc/other system components
to be built and tested. This is typically useful when bringing up new hardware,
or testing rebuilds with new compiler settings. Because we may be dealing
with new hardware, doing this bootstrap through cross-compilation is
something we'd like too.
Eventually, it would be great to have something as straightforward as the
OpenEmbedded or OpenWRT build process to construct a repository with a core set
of Ubuntu packages (say, minbase), for previously-unsupported hardware.
The archive bootstrap process isn't done often, and can require a large
amount of manual intervention. At present, there's only a couple of
folks who know how to get it working. The plan here is to document the
bootstrap process in this cycle, so that others can replicate the process,
and possibly improve the bits that are a little too janky for general
ARM64 / ARMv8 / aarch64 support
This session is an update for progress on the support for ARMv8 processors
in Ubuntu. While no general-purpose hardware exists at the moment, we want
to have all the pieces ready for when we start seeing initial
implementations. Because we don't have hardware yet, this work has to be
done in a cross-build environment; another reason to keep on with the
So far, toolchain progress is going well, with initial cross toolchains
Although kernel support isn’t urgent at the moment, we’ll be building an
initial kernel-headers package for aarch64. There's also a plan to get a page
listing the aarch64-cross build status of core packages, so we'll know what
is blocked for 64-bit ARM enablement.
We’ve also got a bunch of workitems for volunteers to fix cross-build issues
as they arise. If you're interested, add a workitem in the blueprint, and keep an eye on it for updates.
Secure boot support in Ubuntu
This session covered progress of secure boot support as at the 12.10
Quantal Quetzal release,
items that are planned for 13.04, and backports for 12.04.2.
As for 12.10, we’ve got the significant components of secure boot
support into the release — the signed boot chain. The one part that hasn't
hit 12.10 yet is the certificate management & update infrastructure, but that
is planned to reach 12.10 by way of a not-too-distant-future update.
The foundations team also mentioned that they were starting the 12.04.2
backport right after UDS, which will bring secure boot support to our
current “Long Term Support” (LTS) release. Since the LTS release is often
preferred Ubuntu preinstall situations, this may be used as a base for
hardware enablement on secure boot machines. Combined with the certificate
management tools (described at sbkeysync & maintaining uefi key databases), and the requirement for
“custom mode” in general-purpose hardware, this will allow for user-defined
trust configuration in an LTS release.
As for 13.04, we're planning to update the shim package to a more recent
version, which will have Matthew Garrett's work on the Machine Owner Key
plan from SuSE.
We're also planning to figure out support for signed kernel modules, for
users who wish to verify all kernel-level code. Of course, this will mean
some changes to things like DKMS, which run custom module builds outside
of the normal Ubuntu packages.
Netboot with secure boot is still in progress, and will require some
fixes to GRUB2.
And finally, the
sbsigntools codebase could do with some
new testcases, particularly for the PE/COFF parsing code. If you're interested
in contributing, please contact me at firstname.lastname@example.org.