Hi! 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. Attending the sprint were: - Marco d'Itri (systemd) - Martin Pitt (systemd) - Michael Biebl (systemd, GNOME) - Michael Stapelberg (systemd) - Andreas Henriksson (GNOME) - Laurent Bigonville (GNOME - Jordi Mallach (GNOME) - Josselin Mouette (GNOME) - Sjoerd Simons (GNOME) - Emilio Pozuelo Monfort (GNOME) For much of the sprint, attendants split into two groups to work separately on systemd and GNOME issues, and joined forces when the topics overlapped. 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 keys. 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