Vom 15 bis 22.8.2015 fand die diesjährige Debian-Konferenz DebConf in Heidelberg statt. Ich war von Samstag bis Dienstag da und fasse nachfolgend nur die wichtigsten Dinge zusammen – wer mehr wissen möchte, kann mich gerne direkt ansprechen. Ansonsten verweise ich auch gerne auf die Videos.

hLinux

HP hat lange Zeit wie wir alle Debian-Pakete selber gebaut und dafür die Versionsnummern erhöht. Das hat viel Kopfweg erzeugt, weshalb sie das inzwischen aufgegeben haben und direkt die Debian-Pakete verwenden, was dem Konzept “Respekt dem, dem der Respekt gebührt”. HP fährt sehr gut damit, alle ihre Änderungen möglichst direkt an Debian fließen zu lassen.

PS: Falls ihr mal in Heidelberg seit, im Kyffhäuser kann man gut Essen gehen – und nette Leute treffen.

Free Software

Für Debian-Entwickler gibt es nun die Möglichkeit, die rechtlichen Aspekte des Copyleft-Assignment durch Free Software Conservancy vertreten zu lassen. Es geht vor allem um 2 Punkte:

• Copyright Enforcement, wie es Harald Welte mit GPL-Violations gemacht hat.
• Copyright Assignment für Debian, um z.B. auch nach dem Ableben eines Entwicklers noch auf dessen Arbeit zugreifen zu können.

Bits from the DPL

Mit Debian Reproducible Builds gibt es derzeit große Bestrebungen, den Build-Vorgang deterministischer zu gestalten. Ziel ist es, das gebaute Pakete bit-identisch zu früheren Builds sind, um die Sicherheit zu erhöhen.

DDEB verfolgt das Ziel, automatisch für alle kompilierten Pakete zusätzliche Debug-Pakete mit den Debug-Symbolen zu erstellen, um im Falle eines core-Dumps diese sinnvoll auswerten zu können.

PPA wird es auch für Debian geben, allerdings sind diese nur für Entwickler gedacht. Vor einem Upgrade müssen diese unbedingt deaktiviert werden!

LTS-Squeeze

Der LTS-Support für Debian-Squeeze wir vor allem über Freexian abgewickelt und was die finanziellen Aspekte regelt. Firmen zahlen bestimmte Geldbeträge an das Projekt, von dem dann freiwillige Entwickler bezahlt werden, die die Backport machen. Da es zu viel zu tun gibt, sind etliche Pakete ausgeschlossen, darunter insbesondere alle Pakete rund um Virtualisierung! D.h., diese werden nicht aktiv gepflegt, aber wenn doch jemand aktualisierte Pakete haben sollte, können sie natürlich gerne auch bei Debian hochgeladen und der Allgemeinheit zur Verfügung gestellt werden.

LTS-Wheezy

So wie es aussieht, wird es auch für alle zukünftigen Debian-Releases LTS-Support geben (solange sich Leute finden, die die Arbeit tun). Auch hier werden wieder etliche Pakete von Vornherein ausgeschlossen werden.

AppStream

Docker ist derzeit der neue Hype, hat aber einen gravierenden Nachteil: Es virtualisiert mehr oder minder als Container eine komplette Betriebssysteminstanz mit eigenen Bibliotheken, init-System, Diensten, nur eben ohne Kernel. Was leider oft auf der Strecke bleibt ist die Sicherheit, denn die Container sind oft nicht auf Aktualisierung ausgelegt: CoreOS verzichtet bewusst auf jede Paketierung und viele Hersteller bevorzugen statische Bibliotheken, was es unmöglich macht, gepatchte Versionen selber einzuspielen.

Mit AppStream gibt es ein gemeinsames Projekt mehrerer Distributionen, Software allgemein dem Benutzer zugänglicher zu machen. Mit Debian-Limba gibt es zudem die Bestrebung, eine Infrastruktur zu schaffen, um über Container einzelnen Anwendungen neuere Versionen von Bibliotheken und anderen Abhängigkeiten in gewohnter Debian-Qualität zugänglich zu machen.

Linux Kernel

Live-patching-Support in Debian ist derzeit nicht vorgesehen. Wenn sich aber jemand damit beschäftigen möchte, ist die Initiative gerne gesehen.

Der Kernel für Debian-Stretch steht noch nicht fest.

InitRamFS

Die initramfs-tools werden derzeit nur noch von Debian und Ubuntu genutzt. Es ist ein Umstieg auf dracut geplant, für das Tester gesucht werden.

Debian Image Tools

In Debian gibt es unzählige Tools, um Images für VMs zu erstellen. Hier will Riku Voipio nach Möglichkeiten suchen, die Arbeiten besser zu bündeln.

Xen

Xen ist weiterhin ein sehr aktives Projekt und möchte die Schlagzahl der Releases erhöhen. Interessant daran ist, dass insbesondere auch dort die Problematik der Updates der VMs beim Release-Wechsel eine wichtige Rolle spielt. Das XenProject betreibt eine große Farm von verschiedenen Rechnern, auf denen vollautomatische Xen (auf Debian) ausgerollt wird und Tests gefahren werden. Nur wenn es keine Regressionen gibt, wandern Commits vom Entwickler-Branch in den geprüften Branch für das nächste Release. Garniert ist das ganze mit einem automatischen git-bisect, was sich für die Entwicklung als großer Gewinn ergeben hat. (Die Tests umfassen auch automatisierte Live-Migrations-Tests, um gerade die Probleme aufzudecken, die wir mit KVM-Snapshots und neueren Versionen von KVM haben.)

Continuous Delivery

Ein sehr interessanter Vortrag zum Thema Debian-Paketbau:

1. Entwickler checken alle ihre Änderungen über git im Branch master ein.
2. Über Jenkins werden automatische die Pakete gebaut, ein debian/changelog automatisch aus den Commit-Kommentaren generiert, und als PPA zur Verfügung gesellt.
3. Über gerrit erfolgt ein Code-Review, was insbesondere neuen Entwicklern auch Feedback von erfahrenen Entwicklern gibt.
4. Der Release-Manager entscheidet, welche Commits per Cherry-Pick in welchen Releases für Kunden landen.
5. Dazu kommen natürlich noch automatische Tests mit Piuparts, pep8, AutoPkgTest, …, die entsprechend in die Gerrit-Wertung mit eingehen.