[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the systemd + GNOME sprint


Below is a report from the recently held systemd + GNOME sprint in
Antwerp. Enjoy!

Ten Debian developers gathered in Antwerp (Belgium) last weekend to
discuss and work on a variety of topics concerning systemd and GNOME
integration in Debian.  During the two days, lots of work was done and
most of our agenda items were resolved or discussed.

For much of the sprint, attendants split into two groups to work
separately on systemd and GNOME issues, and joined forces when the topics

Marco and Martin worked on cleaning up Debian's udev. Until recently, it
had its own set of rules for device permissions, drivers, and persistent
names, but they did not keep up with upstream and thus had a few
deficiencies. We went through all of them and are now left with only 13
rule lines which aren't covered by upstream rules already and are not
obsolete, and some of them can even go upstream. This leads to a few bug
fixes, support for hwdb, faster boot (due to switching modprobe calls to
the kmod builtin), and easier package maintenance. We also imported a few
rule bug fixes from Ubuntu.

We discussed how to improve the current gitpkg branch for systemd; it
does not offer a view of separated changes against upstream split by
concept, only an individual by-commit list. It is also rather hard to
understand for most Debian developers and does not follow the usual 3.0
(quilt) packaging that is the common case these days. We changed to
git-buildpackage with proper broken-out debian/patches/ managed by
gbp-pq, converted the repository, and documented the workflow [GBP]. The
repository now also has an Ubuntu branch with the Ubuntu delta, so that
Ubuntu's systemd now has an official git repository as well. The delta
against Debian was massively shrunk (by 80% or more) by Debian now using
the upstream udev rules, dropping the obsolete systemd-services split,
using the Debian approach for starting logind under upstart/sysvinit, and
merging the applicable Ubuntu changes to Debian. With all that we are now
in a much better position for shared maintenance, bug fixing, and making
it easier for contributors to help.

[GBP] http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/README.source;hb=HEAD

A patch was merged and tested to parse the insserv configuration files
and amend LSB/SysV based units with the dependency information derived
from those facilities. This greatly improves integration with our
currently used LSB/SysV init scripts and the facility names defined by
LSB and Debian.

Additionally, we went through the bug tracker and closed old/obsolete
bugs, worked on resolving some still relevant bugs and sent out a few
patches for adding native systemd service units to popular packages
(unattended-upgrades, hdparm, apache2).

Michael B. also updated systemd to 208 in experimental. This was a good
test of how practical gbp-pq's rebasing works, and we were quite pleased
with the result. This release also includes a major rework of the cgroup
handling that was done upstream as part of  version 205. As a result
logind no longer creates cgroup hierarchies on its own and the standalone
logind is no longer functional without support from systemd (or an
equivalent cgroup manager). We discussed how such functionality could be
provided by systemd-shim via cgmanager. While the Debian systemd team
itself will not work on providing that kind of functionality in
systemd-shim/cgmanager we invite everyone interested in keeping a
standalone logind working (under sysvinit or upstart) to get in touch
with the systemd team.

The GNOME and systemd teams jointly discussed how to configure and start
display managers. This is not an easy task in a world where we have the
combinatorial explosion of several display managers (gdm, kdm, lightdm,
xdm, etc.) times several init systems times multiple ways  of
enabling/disabling/chaging them (debconf, systemctl, update-rc.d,
/etc/X11/default-display-manager). We believe we have a working solution
now, fixed gdm, fixed lightdm upstream and in Ubuntu, and sent a patch to
lightdm in Debian.

The entire core GNOME packaging team was able to attend the sprint, so
they were able to tackle a lot of topics that have been on the pipeline
for years.

Early on Saturday, and with the much appreciated help from release team
member Niels Thykier, the planned Evolution Data Server, libgdata and
GNOME Online Accounts transitions were combined into one and initiated in
unstable. That meant doing a dozen or so source uploads and getting quite
a few more binnmus scheduled, and dealing with some last minute problems
like libgmp10 not having proper shlib versioning, or evolution-mapi
needing to adapt  to 0day OpenChange API changes in unstable. This
transition is going very well, and if no last-minute RC bugs arise,
should be ready to migrate soon.

In parallel, the Glade transition was started as well, and both Glade and
the scheduled nmus have been churning along since, with no unexpected
problems for the transition to finalise.

While that was being sorted out, other team members were busy at updating
most packages to their 3.12.1 release and uploading to unstable every bit
that wasn't blocked by pending transitions. The net result is that our
GNOME 3.12 status chart [312STATUS] is looking greener than ever.

[312STATUS] http://www.0d.be/debian/debian-gnome-3.12-status.html

The GNOME team also used the opportunity to discuss implementation
details for our switch from Subversion to Git for our packaging work.
Having the systemd people a few meters away was great to discuss the
advantages and disadvantages of the various workflow models, and we ended
up settling on using a git-buildpackage workflow, while allowing optional
usage of gbp-pq or pure quilt patch management. Sjoerd has been testing
git conversions for months and is near having a set of scripts that
cleanup our jumpy history well enough for us, and we should be nearing
the day when we make SVN read-only and officially do the switch.

On Sunday, we discussed the feasibility of shipping GNOME 3.14 with
jessie. The GNOME 3.13 roadmap [313ROADMAP] shows it's a bit of an uphill
battle, with final 3.14 tarballs released on September 22, and Debian
jessie freezing on November. However, it was discussed that a possible
plan would be to track and upload GNOME 3.14 beta releases to
experimental, and try to start transitions as soon as they are safe (with
beta2 or release candidate). In our favour, there is no Evolution Data
Server release planned for 3.14 [EVO312], which makes the transition
overhead quite smaller. The GNOME team would arrange another face to face
meeting very early in September to try to speed up all the process, if
the release team agrees this can be done.

[313ROADMAP] https://wiki.gnome.org/ThreePointThirteen

[EVO312] https://wiki.gnome.org/Apps/Evolution/ReleaseHOWTO#Release_Schedule

Besides this, quite a few more topics were discussed, like trying to make
our experimental packages always installable, or to maintain a
semi-official repository that makes it easier to install our latest
packaging work. On the flip side, backporting new GNOME releases to
Debian stable was rejected due to complexity involved in updating
GTK+3.0, which unfortunately sometimes affects some non-GNOME rdepends.

Wayland support for jessie was briefly discussed, and we agreed to
provide a Wayland GDM session as a technology preview, as all the bits
and pieces will be ready in that timeframe.

We finally discussed how to tackle Bluez5. Bluez 4 is the current release
available in Debian, which is dead upstream and deprecated since late
2012.  GNOME 3.12 only supports Bluez 5, while the rest of Bluez users in
Debian (including KDE, Xfce and other environments) haven't been ported
yet to Bluez 5. Both releases are not parallel installable, so we
concluded that a potential solution could be to upload Bluez 5 as
“bluez5”, and let it conflict with ”bluez” [BLUEZ5BTS]. Desktops would
then recommend their supported release instead of depending on it, which
would allow for parallel installation of different desktop environments,
while respecting the bluez conflict. With that in place, it'd be a lot
easier to migrate Bluez 4 users to Bluez 5 in a case by case basis. The
GNOME team is ready to provide directions or assistance to the Debian
bluez maintainer in order to achieve this transition.

[BLUEZ5BTS] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746078

The attendees used this great opportunity to keysign our new, stronger
GnuPG keys in order to help the effort to abandon our older and weaker

We'd like to thank our sponsors, most notably INUITS, which provided the
venue for us, and Debian and its donors for covering the travel expenses
for 5 of the attendees. A few of the attendees were kindly sponsored by
their employers.

[HAPPYHACKERS] http://malsain.org/~joss/hackfest.jpg

Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

Attachment: signature.asc
Description: Digital signature

Reply to: