I spent much of my Debian time in the last few weeks triaging and fixing bugs in initramfs-tools. All of the important bugs should be fixed, except for two where I needed more information from the submitter. Due to the scope of these changes and potential for regressions, I've made a release candidate, version 0.121~rc2, rather than a full release. This is now available in experimental, and I would appreciate real-world testing feedback in the next few weeks. (If you're wondering what happened to rc1, that had 'unstable' as the distribution, which I didn't notice until after pushing the tag.) From the release announcement, the major changes are:

• Split initramfs-tools binary package into core and automation hooks, to allow for coinstallation of the core with other initramfs builders
• Fail at build-time if busybox is wanted but not found
• Rewrite build-time block device sysfs lookup to be generic
• Include modules for all components of a multi-disk device
• Use blkid to resolve LABEL=, UUID=, PARTLABEL= and PARTUUID= block device IDs at boot time, and do this much later
• Change file copying to distinguish executables from other file types and to preserve symlinks
• Run panic scripts just before dropping to a shell

Thanks to Andy Whitcroft, Boris Egorov, Laurent Bigonville, Roger Leigh, Roger Shimizu and Salvatore Bonaccorso for their patches which I applied in this version.

I just released sbuild 0.66.0-1 into unstable. It fixes a whopping 30 bugs! Thus, I'd like to use this platform to:

• kindly ask all sbuild users to report any new bugs introduced with this release
• give a big thank you to everybody who supplied the patches that made fixing this many bugs possible (in alphabetical order): Aurelien Jarno, Christian Kastner, Christoph Egger, Colin Watson, Dima Kogan, Guillem Jover, Luca Falavigna, Maria Valentina Marin Rordrigues, Miguel A. Col n V lez, Paul Tagliamonte

And a super big thank you to Roger Leigh who, despite having resigned from Debian, was always available to give extremely helpful hints, tips, opinion and guidance with respect to sbuild development. Thank you! Here is a list of the major changes since the last release:

• add option --arch-all-only to build arch:all packages
• environment variable SBUILD_CONFIG allows to specify a custom configuration file
• add option --build-path to set a deterministic build path
• fix crossbuild dependency resolution
• add option --extra-repository-key for extra apt keys
• add option --build-dep-resolver=aspcud for aspcud based resolver
• allow complex commands as sbuild hooks
• add now external command %SBUILD_SHELL produces an interactive shell
• add options --build-deps-failed-commands, --build-failed-commands and --anything-failed-commands for more hooks

I thought it would have been smooth, though it wasn t. OpenRC shipped /sbin/rc, which conflicted with the rc shell (an implementation of the AT&T Plan 9 shell), and /sbin/runscript was conflicting with minicom. With the help of upstream authors, /sbin/rc was renamed /sbin/openrc, and /sbin/runscript was renamed /sbin/openrc-run. However, the main goal is reached: after last summer Google Summer of Code project, and a bit of rework for the ruff edges, OpenRC made it to Debian. So, if you wish to try OpenRC, which is a direct replacement for sysv-rc, just add the Debian Experimental repository to your sources.list, and do apt-get install openrc . The only issue will be the first reboot, though that should be fine if one manually shuts down every running daemon, and then type what the postinst suggests as command echoed on the screen. Suggestions on how to improve this is welcome. I warmly also welcome more general feedback. I d like to publicly thank Patrick Lauer, Benda ( ), WIlliam Hubbs, Alexander Vershilov (who are all OpenRC upstreams), Bill Wang who was the GSoC studdent working on OpenRC, Roger Leigh who is the current sysv-init/sysv-rc maintainer, for their help and support when porting OpenRC to Debian. Without them, it wouldn t have been possible.

Most people who follow Debian are probably aware that we're currently in the middle of a major debate over the future of Debian's init system. Over the past month, and particularly over the past week, I undertook an evaluation of two of the options in that debate, using one of my packages as a test bed. I also did a lot of reading, filed a few bugs, and asked a bunch of questions. That's an extension of the questions I've been asking and discussions I've been participating in around init systems for the past year plus. I have been keeping my opinions and writeups confined to the relevant Techncial Committee bug report so that they can be read in context with their rebuttals. There are a lot of thoughtful and well-informed opinions here, of which mine are only one, and several of my conclusions have been inaccurate or at least not complete, so the context is important. You can find the full traffic in the Technical Committee bug. Most of the discussion, in a threaded view, is in the Technical Committee archives for December. However, in one of the messages I sent today, I tried to show my appreciation for the people who have assisted with this evaluation over the past week, month, and years, and I think that section deserves broader distribution outside of the ongoing discussion. It is therefore included below. Throughout this evaluation process, my interactions with upstart and systemd upstream developers and Debian packagers have been uniformly excellent. Bug reports filed against both systemd and upstart have received excellent and timely response, and all involved have been quite willing to explain things I've misunderstood, correct my false starts, and discuss technical and practical aspects of their designs. I was particularly impressed by the clear effort that the systemd and upstart maintainers in Debian have put into fully integrating their init systems in such a way that makes them easy to test and use with existing Debian packages. This includes but is not limited to update-rc.d support, invoke-rc.d support, status synchronization with sysvinit, past Policy discussion, and attention to upgrade paths and init-switching use cases. I also want to particularly thank the OpenRC upstream development team for their involvement in this process and their contributions to the discussion. I personally don't think that package is a good match for Debian's needs on Linux, but that's through no fault of the people involved, and I think they would be an excellent upstream if that package looked like a good fit for the needs of any of Debian's non-Linux ports. I also want to thank Petter Reinholdtsen, Roger Leigh, and everyone else who has worked on the sysvinit package over the years, the insserv conversion to dependency-based boot, and the inclusion of LSB support. If it weren't for their hard work, we would be in a far worse position than we are today. It's often hard to see people discussing the inadequacies of something into which you put years of hard work. I want to call attention to their long-term contributions to the distribution, and to the number of Debian systems that have booted through their efforts over the years.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (195 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dropbox for Debian This is not free software but Dropbox is very popular and they did only provide an Ubuntu package that did not work on Debian. So I created an official package. I have been in touch with Dropbox developers and they have been very helpful. They ll shortly release a signature mechanism (with GPG) so that we can further improve the package by verifying the origin of the downloaded binaries. SAT Britney At the start of the month, I continued my work on the britney reimplementation (the software that creates testing out of unstable) but I quickly stalled it because the release managers asked the feedback of Stefano Zacchiroli and Ralf Treinen (who have extensive knowledge on the topic with their research work on Mancoosi) and I did not want to invest further work in case they would identify a major flow the feedback came only very late this month and while it was somewhat negative, I still think it s worth pursuing the effort for a bit longer. Converted ftplib to multiarch While dpkg still doesn t support multiarch (no news from Guillem and no visible sign of progress ), unstable got all the remaining bits allowing us to convert libraries to multiarch (see the announce). As soon as the required libc6 landed in unstable, I looked into converting the only library package that I maintain. I had no major problem but I still identified 2 issues in Lintian (filed as #630164 and quickly fixed by Niels Thykier). build-arch / build-indep support For the 42th time in the last 10 years, the idea of using build-arch/build-indep targets in the rules file has surfaced again. I had already decided some time ago that I would accept a patch implementing a new field Build-Features to enable dpkg-buildpackage to use those targets and this time Bill Allombert completed such a patch so I merged it. The technical committee also decided that it would take a final decision on this topic (see #629385). Roger Leigh provided useful input by doing an archive-wide rebuild with the various solutions suggested. Given that the majority would like to make the target mandatory at some point in the future, I provided the dpkg patch for my preferred solution. We would use auto-detection as a temporary measure until all packages have been converted to have the targets. The technical committee has not yet taken any decision even though the discussion stalled since the 12th of June. But that s usual with that body. I m sure it will be solved during Debconf. Misc dpkg work

• Modified dpkg-source --after-build to automatically unapply patches if they have been applied by dpkg-source --before-build.
• Lots of small bug fixes (#628726, #629582, #630996, #631435, #631439, #631547, #632168) and that s just to keep with the flow of incoming bug reports!
• Added 2 supplementary Perl modules to the supported API for the benefit of Lintian.
• Spent an evening to track down the possible causes of an long-standing and annoying assertion failure related to triggers.
• Updated my branch with improved triggers directives to take into account the feedback of Guillem, and merged it.
• While doing this I discovered a design flaw with the usage of prerm failed-upgrade and merged a fix.
• Discussed integration of dpkg-buildflags with debhelper in #544844 and decided of further improvements for dpkg-buildflags as a result.

Hamster applet update Hamster-applet is a GNOME application which did not have a 3.0 release, but it had a development release (2.91.x). I checked out whether it was possible to package this version for experimental and have the applet work with the GNOME fallback mode. Apparently not, the code was not yet updated to be compatible with the newer panel. Instead I uploaded the latest stable version (2.32.1) to unstable. It has some nice improvements in the standalone version (and the name of the executable changed). For usage with GNOME 3, I have created a custom shortcut to start it quickly (with gconf-editor set /apps/metacity/global_keybindings/run_command_1 to <Mod4>t and /apps/metacity/keybinding_commands/command_1 to hamster-time-tracker because the GNOME 3 control panel does not seem to work to set custom keybindings currently). Translated my professional website into English While I m grateful for all the people who are supporting my work, I m still far from my goal to have one third of my time funded through donations and sales of products on this blog. So I decided to also bring more visibility to my company and in particular to its Debian-related service offering. It was only available in French up to now so I translated it and expanded it a bit. My support page on this blog now also links to my company s website. If your company needs help to create Debian packages, or needs Debian technical support by email, you just found the right partner. BTW, I have discounted prices for individuals and non-profits who would like to benefit from my help to create Debian packages. The Debian Administrator s Handbook This is the title of the upcoming translation of my book. The project now has a dedicated website: debian-handbook.info. You can subscribe to its RSS feed to keep up with the latest news. The full table of contents is online along with a FAQ. I m actively looking for partners to help me promote the fundraising once it goes live. If you can reach a large set of readers interested by a good Debian book, get in touch with me to join the affiliate program. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

That are only 3 simple words, but their value is hard to underrate. It's very important milestone in my Debian work.

The achievement might not be possible, if there wasn't the help of:
- Vincent Bernat, who thoroughly corrected my first packaging and sponsored my first (and not only) package;
- Dmitry E. Oboukhov, who uploaded many packages for me and also gave some useful advices;
- Roger Leigh, who spent not one day to improve my packaging skills, and also advocated my NM application;
- Enrico Zini, who was my NM Application Manager.
Thank you!

Thanks to people who built my NM procession chain up to creating the account: Bernd Zeimetz (FD), Christoph Berg (DAM), Peter Palfrader (account creation).

I’m extremely happy to let everyone know that I am now a Debian Developer. I’d like to thank my AM - Martin Michlmayr, Drew Parsons for advocating me and sponsoring uploads, and Roger Leigh for also sponsoring uploads. I’d also like to thanks the FD and DAM teams (looks like they have been busy during this last week). The entire process took 13 months to complete, with that time roughly split between waiting for an AM and then covering P&P and T&S. My wait in the FD and DAM queues was quite short. Of course the first thing I did once I found out, like any email freak was to update my .sig file. Thanks once again to all of those people that helped during my time in the NM queue.