manpages now specify
their language in the HTML tag so that search engines can offer users the
most appropriate version of the manpage.

I contributed mandocd(8) to the mandoc project, which debiman
now uses for significantly faster manpage conversion (useful for disaster
recovery/development). An entire run previously took 2 hours on my workstation.
With this change, it takes merely 22 minutes. The effects are even more
pronounced on manziarly, the VM behind manpages.debian.org.

Thanks to Peter Palfrader (weasel) from the Debian System Administrators (DSA)
team, manpages.debian.org is now serving its manpages (and most of its
redirects) from Debian s static mirroring infrastructure. That way, planned
maintenance won t result in service downtime. I contributed README.static-mirroring.txt,
which describes the infrastructure in more detail.

The list above is not complete, but rather a selection of things I found worth
pointing out to the larger public.
There are still a few things I plan to work on soon, so stay tuned :).

5 September 2016

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me.
This months is rather light since I was away in vacation for two weeks.
Kali related work
The new pkg-security team is working full steam and I reviewed/sponsored many packages during the month: polenum, accheck, braa, t50, ncrack, websploit.
I filed bug #834515 against sbuild since sbuild-createchroot was no longer usable for kali-rolling due to the embedded dash. That misfeature has been reverted and implemented through an explicit option.
I brought the attention of ftpmasters on #832163 since we had unexpected packages in the standard section (they have been discovered in the Kali live ISO while we did not want them).
I uploaded two fontconfig NMU to finally push to Debian a somewhat cleaner fix for the problem of various captions being displayed as squares after a font upgrade (see #828037 and #835142).
I tested (twice) a live-build patch from Adrian Gibanel Lopez implementing EFI boot with grub and merged it into the official git repository (see #731709).
I filed bug #835983 on python-pypdf2 since it has an invalid dependency forbidding co-installation with python-pypdf.
I orphaned splint since its maintainer was missing in action (MIA) and immediately made a QA upload to fix the RC bug which kicked it out of testing (this package is a build dependency of a Kali package).
django-jsonfield
I wrote a patch to make python-django-jsonfield compatible with Django 1.10 (#828668) and I committed that patch in the upstream repository.
Distro Tracker
I made some changes to make the codebase compatible with Django 1.10 (and added Django 1.10 to the tox test matrix). I added a Debian Maintainer Dashboard link next to people s name on request of Lucas Nussbaum (#830548).
I made a preliminary review of Paul Wise s patch to add multiarch hints (#833623) and improved the handling of the mailbot when it gets MIME Headers referencing an unknown charset (like cp-850 , Python only knows of cp850 )
I also helped Peter Palfrader to enabled a .onion address for tracker.debian.org, see onion.debian.org for the full list of services available over Tor.
Misc stuff
I updated my letsencrypt.sh salt formula to work with the latest version of letsencrypt.sh (0.2.0)
I merged updated translations for the Debian Administrator s Handbook from weblate.org and uploaded a new version to Debian.
Thanks
See you next month for a new summary of my activities.

Test infrastructure
For testing the impact of allowing variations of the buildpath (which up until
now we required to be identical for reproducible rebuilds), Reiner Herrmann
contribed a patch which enabled build path variations on testing/i386. This is
possible now since dpkg 1.18.10 enables the --fixdebugpath build flag feature
by default, which should result in reproducible builds (for C code) even with
varying paths. So far we haven't had many results due to disturbances in our
build network in the last days, but it seems this would mean roughly between
5-15% additional unreproducible packages - compared to what we see now. We'll
keep you updated on the numbers (and problems with compilers and common
frameworks) as we find them.
lynxis continued work to test LEDE
and OpenWrt on two different
hosts, to include date variation in the tests.
Mattia and Holger worked on the (mass) deployment scripts, so that the - for space
reasons - only jenkins.debian.net GIT
clone resides in ~jenkins-adm/ and not anymore in Holger's homedir, so
that soon Mattia (and possibly others!) will be able to fully maintain this setup,
while Holger is doing siesta.
Miscellaneous
Chris, dkg, h01ger and Ximin attended a Core Infrastricture
Initiative summit meeting in New York
City, to discuss and promote this Reproducible Builds project. The CII was set
up in the wake of the Heartbleed SSL vulnerability to support software projects
that are critical to the functioning of the internet.
This week's edition was written by Ximin Luo and Holger Levsen and reviewed by a bunch of
Reproducible Builds folks on IRC.

29 July 2016

Abstract
I just set up a lot of Onion Services for many of
Debian's static websites.
You can find the entire list of services on onion.debian.org.
More might come in the future.
Read more about this on either Bits or on the Tor Blog.
-- Peter Palfrader

14 January 2016

During his DebConf15 keynote, Jacob Appelbaum
observed
that those listening on the Internet lines would have good reason to
believe a computer have a given security hole if it download a
security fix from a Debian mirror. This is a good reason to always
use encrypted connections to the Debian mirror, to make sure those
listening do not know which IP address to attack. In August, Richard
Hartmann observed that encryption was not enough, when it was possible
to interfere download size to security patches or the fact that
download took place shortly after a security fix was released, and
proposed
to always use Tor to download packages from the Debian mirror. He
was not the first to propose this, as the
apt-transport-tor
package by Tim Retout already existed to make it easy to convince apt
to use Tor, but I was not
aware of that package when I read the blog post from Richard.
Richard discussed the idea with Peter Palfrader, one of the Debian
sysadmins, and he set up a Tor hidden service on one of the central
Debian mirrors using the address vwakviie2ienjx6t.onion, thus making
it possible to download packages directly between two tor nodes,
making sure the network traffic always were encrypted.
Here is a short recipe for enabling this on your machine, by
installing apt-transport-tor and replacing http and https
urls with tor+http and tor+https, and using the hidden service instead
of the official Debian mirror site. I recommend installing
etckeeper before you start to have a history of the changes
done in /etc/.

If you have more sources listed in /etc/apt/sources.list.d/, run
the sed commands for these too. The sed command is assuming your are
using the ftp.debian.org Debian mirror. Adjust the command (or just
edit the file manually) to match your mirror.
This work in Debian Jessie and later. Note that tools like
apt-file only recently started using the apt transport
system, and do not work with these tor+http URLs. For
apt-file you need the version currently in experimental,
which need a recent apt version currently only in unstable. So if you
need a working apt-file, this is not for you.
Another advantage from this change is that your machine will start
using Tor regularly and at fairly random intervals (every time you
update the package lists or upgrade or install a new package), thus
masking other Tor traffic done from the same machine. Using Tor will
become normal for the machine in question.
On Freedombox, APT
is set up by default to use apt-transport-tor when Tor is
enabled. It would be great if it was the default on any Debian
system.

9 November 2015

Announced 7 November 2015 on the debian-devel-announce mailing list.
The Debian Project now has an XMPP service available to all Debian Developers. Your Debian.org email identity can be used as your XMPP address.
The SIP service has also been upgraded and now supports presence. SIP and XMPP presence, rosters and messaging are not currently integrated.
The Lumicall app has been improved to enable rapid setup for Debian.org SIP users.
This announcement concludes the maintenance window on the RTC services. All services are now running on jessie (using packages from jessie-backports).
XMPP and SIP enable a whole new world of real-time multimedia communications possibilities: video/webcam, VoIP, chat messaging, desktop sharing and distributed, federated communication are the most common use cases.
Details about how to get started and get support are explained in the User Guide in the Debian wiki. As it is a wiki, you are completely welcome to help it evolve.
Several of the people involved in the RTC team were also at the Cambridge mini-DebConf (7-8 November).
The password for all these real time communication services can be set via the LDAP control panel. Please note that this password needs to be different to any of your other existing debian.org passwords. Please use a strong password and please keep it secure.
Some of the infrastructure, like the TURN server, is shared by clients of both SIP and XMPP. Please configure your XMPP and SIP clients to use the TURN server for audio or video streaming to work most reliably through NAT.
A key feature of both our XMPP and SIP services is that they support federated inter-connectivity with other domains. Please try it. The FedRTC service for Fedora developers is one example of another SIP service that supports federation. For details of how it works and how we establish trust between domains, please see the RTC Quick Start Guide. Please reach out to other communities you are involved with and help them consider enabling SIP and XMPP federation of their own communities/domains: as Metcalfe's law suggests, each extra person or community who embraces open standards like SIP and XMPP has far more than just an incremental impact on the value of these standards and makes them more pervasive.
If you are keen to support and collaborate on the wider use of Free RTC technology, please consider joining the Free RTC mailing list sponsored by FSF Europe. There will also be a dedicated debian-rtc list for discussion of these technologies within Debian and derivatives.
This service has been made possible by the efforts of the DSA team in the original SIP+WebRTC project and the more recent jessie upgrades and XMPP project. Real-time communications systems have specific expectations for network latency, connectivity, authentication schemes and various other things. Therefore, it is a great endorsement of the caliber of the team and the quality of the systems they have in place that they have been able to host this largely within their existing framework for Debian services. Feedback from the DSA team has also been helpful in improving the upstream software and packaging to make them convenient for system administrators everywhere.
Special thanks to Peter Palfrader and Luca Filipozzi from the DSA team, Matthew Wild from the Prosody XMPP server project, Scott Godin from the reSIProcate project, Juliana Louback for her contributions to JSCommunicator during GSoC 2014, Iain Learmonth for helping get the RTC team up and running, Enrico Tassi, Sergei Golovan and Victor Seva for the Prosody and prosody-modules packaging and also the Debian backports team, especially Alexander Wirt, helping us ensure that rapidly evolving packages like those used in RTC are available on a stable Debian system.

10 September 2014

When we setup Freexian s offer to bring together funding from multiple companies in order to sponsor the work of multiple developers on Debian LTS, one of the rules that I imposed is that all paid contributors must provide a public monthly report of their paid work.
While the LTS project officially started in June, the first month where contributors were actually paid has been July. Freexian sponsored Thorsten Alteholz and Holger Levsen for 10.5 hours each in July and for 16.5 hours each in August. Here are their reports:

It s worth noting that Freexian sponsored Holger s work to fix the security tracker to support squeeze-lts. It s my belief that using the money of our sponsors to make it easier for everybody to contribute to Debian LTS is money well spent.
As evidenced by the progress bar on Freexian s offer page, we have not yet reached our minimal goal of funding the equivalent of a half-time position. And it shows in the results, the dla-needed.txt still shows around 30 open issues. This is slightly better than the state two months ago but we can improve a lot on the average time to push out a security update
To have an idea of the relative importance of the contributions of the paid developers, I counted the number of uploads made by Thorsten and Holger since July: of 40 updates, they took care of 19 of them, so about the half.
I also looked at the other contributors: Rapha l Geissert stands out with 9 updates (I believe that he is contracted by lectricit de France for doing this) and most of the other contributors look like regular Debian maintainers taking care of their own packages (Paul Gevers with cacti, Christoph Berg with postgresql, Peter Palfrader with tor, Didier Raboud with cups, Kurt Roeckx with openssl, Balint Reczey with wireshark) except Matt Palmer and Luciano Bello who (likely) are benevolent members of the LTS team.
There are multiple things to learn here:

Paid contributors already handle almost 70% of the updates. Counting only on volunteers would not have worked.

Quite a few companies that promised help (and got mentioned in the press release) have not delivered the promised help yet (neither through Freexian nor directly).

Last but not least, this project wouldn t exist without the support of multiple companies and organizations. Many thanks to them:

1 September 2014

= Driving your firefox like vim
Recently a friend of mine pointed out
pentadactyl to me. It's a firefox add-on
to drive your browser in a vim-like style. I had tried vimperator in
the past and didn't like it very much back then, but a lot has improved
since then.
Obviously there's a learning curve involved, like in many great tools,
but I think for me it was worth it. I have it now enabled in all my
firefoxes/iceweasels.
Aloha,

= Fun and Profit with lirc
== Getting the basics
A couple weeks ago I got myself a small USB Infrared Transceiver from the
people at iguanaworks.
It comes in different models and I got the dual socket one that allows me
to hook up external IR emitters. The goal was to remote control my stereo from
my desktop machine, so using wired IR blasters gives me the flexibility I need
with the wiring.
They provide Debian packages built for some version of Ubunutu from their
website. I wanted to build them from source, so apt-get source from
their repository it is. The build process of the package
is pretty broken -- it assumes there already is an iguanair user for instance.
If somebody could package this up properly for Debian that'd be real nice. And who
knows, maybe upstream would appreciate that as well. At first glance the software
looks free enough.
Once iguanair has been built and installed, lirc needs a recompile
-- it will pick up the iguanair library automatically.
Their Getting Started docs
are actually pretty good.
== Learning the IR codes
Anyway, once the software was set up, I needed the IR-codes to send to my Denon.
There are a couple of databases for varios remote controls and receivers on the
internet, but I didn't find a single entry for my old Denon AVR-1600RD.
Fortunately lirc alls you to learn codes off a remote control you already have,
and since the iguana device also comes with a receiver, I could use irrecord
to get the needed magic bytes for commands like power on/off, mute, volume up/down.
This actually worked quite well, the only problem was realizing that the IR blasters
are really picky about being properly aligned and close to the receiver (my Denon).
Once I got that right, all the recorded codes worked.
lircd.conf for Denon AVR-1600RD
== Putting it all together
I can now use this to mute my stereo using
irsend send_once denon KEY_MUTE for instance.
What I also wanted to get out of this was that the stereo should
be shut off automatically when my machine goes to sleep, or
when I haven't used it in a while.
Since my Denon only has a power toggle command and does not appear to have a
discrete power-off command -- at least I don't know it -- I needed something
on my system to keep state, and it means I no longer should use my real remote
control or else things will get out of sync.
I have written a small wrapper script that does this for me -- stereo.
It's in /usr/local/bin .
=== Initialisation
On boot, the script creates its state file when called with the init
command. There is a small init script that takes
care of this, as well as turning off the stereo when the machine reboots
or powers off.
=== Power off on suspend
In addition to powering off the stereo when the machine goes down,
I also want it to do that when it goes to sleep. Enter /etc/pm/sleep.d/20 stereo .
=== Power off on idle
Furthermore, I run the script out of cron every 5 minutes - to see if anything
is using the alsa device. If there isn't for half an hour the stereo gets
turned off. Crontab entry:
*/5 * * * * /usr/local/bin/stereo off-if-idle
=== Manually controlling it
And last not least I have integrated it into my xbindkeys config.
I am abusing a couple special keys that I never ever use. Here's the snippet
from my ~/.xbindkeysrc :
"stereo mute"
XF86HomePage
"stereo vol-"
XF86Search
"stereo vol+"
XF86Mail
"stereo toggle"
c:193
"stereo touch"
c:192
Cheers,

11 January 2014

Abstract
I recently moved our primary nameserver from orff.debian.org, which is
an aging blade in Greece, to a VM on one of our ganeti clusters. In the
process, I rediscovered a lot about our DNS infrastructure. In this post,
I will describe the many sources of information and how they all come
together.

Introduction
The Domain Name System is the hierarchical database and query
protocol that is in use on the Internet today to map hostnames to IP
addresses, to map the reverse thereof, to lookup relevant servers for
certain services such as mail, and a gazillion other things. Management
and authority in the DNS is split into different zones, subtrees of the
global tree of domain names.
Debian currently has a bit over a score of zones. The two most
prominents clearly are debian.org and
debian.net. The rest is made up of debian
domains in various other top level domains and reverse zones, which
are utilized in IP address to hostname mappings.

Types and sources of information
The data we put into DNS comes from a wide range of different systems:

Classical zonefiles maintained in git. This represents
the core of our domain data. It maps services like
blends.debian.org to static.debian.org or
specifies the servers responsible for accepting mail to
@debian.org addresses. It also is where all the
ftp.CC.debian.org entries are kept and maintained together with the
mirror team.

Information about debian.org hosts, such as master, is maintained
in Debian's userdir LDAP, queryable using
LDAP1.

This includes first and foremost the host's IP addresses (v4 and v6).

Additionally, we store the server responsible for receiving a host's
mail in LDAP (mXRecord LDAP attribute, DNS MX record type).

LDAP also has some specs on computers, which we put into each host's
HINFO record, mainly because we can and we are old-school.

Last but not least, LDAP also has each host's public ssh key, which we
extract into SSHFP records for DNS.

LDAP also has per-user information. Users of debian infrastructure
can attach limited DNS elements as dnsZoneEntry attributes to their
user2.

The auto-dns system (more on that below).

Our puppet also is a source of DNS information. Currently it
generates only the TLSA records that enable clients to
securely authenticate certificates used for mail and HTTPS, similar
to how SSHFP works for authenticating ssh host keys.

Debian's auto-dns and geo setup
We try to provide the best service we can. As such, our goal is that,
for instance, user access to www or bugs should always
work. These services are, thus, provided by more than one machine on
the Internet.
However, HTTP did not specify a requirement for clients to re-try a
different server if one of those in a set is unavailable. This means
for us that when a host goes down, it needs to be removed from the
corresponding DNS entry.
Ideally, the world wouldn't have to wait for one of us to notice and
react before they can have their service in a working manner.
Our solution for this is our auto-dns setup. We maintain a
list of hosts that are providing a service. We monitor them
closely. Whenever a server goes away or comes back we
automatically rebuild the zone that contains the element.
This setup also lets us reboot servers cleanly since one of the
things we monitor is "is there a shutdown running", we can, simply by
issuing a shutdown -r 30 kernel-update, de-rotate the machine in
question from DNS. Once the host is back it'll automatically get
re-added to the round-robin zone entry.
The auto-dns system produces two kinds of output:

In service-mode it generates a file with just the address records
for a specific service. This snippet is then included in its zone
using a standard bind $INCLUDE directive. Services that work like
this include bugs and static (service definition for
static).

In zone-mode, auto-dns produces zonefiles. For each service it
produces a set of zonefiles, one for each out of a set of different
geographic regions. These individual zonefiles are then transferred
using rsync to our GEO-IP enabled nameservers. This
enables us to give users a list of security mirrors closer to them
and thus hopefully faster for them.

Tying it all together
Figure 1: The Debian DNS Rube Goldberg Machine.
Once all the individual pieces of source information have been
collected, the dns-update and write_zonefile scripts from our
dns-helpers repository take over the job of building complete
zonefiles and a bind configuration snippet. Bind then loads the zones
and notifies its secondaries.
For geozones, the zonefiles are already produced by auto-dns'
build-zones and those are pulled from the geo nameservers via rsync
over ssh, after an ssh trigger.

and also DNSSEC
All of our zones are signed using DNSSEC. We have a script in
dns-helpers that produces, for all zones, a set of rolling signing
keys. For the normal zones, bind 9.9 takes care of signing them
in-process before serving the zones to its secondaries. For our
geo-zones we sign them in the classical dnssec-signzone way before
shipping them.
The secure delegation status (DS set in parent matches DNSKEY in child)
is monitored by a set of nagios tests, from both [dsa-nagios] and
dns-helpers. Of these, manage-dnssec-keys has a dual job: not
only will it warn us if an expiring key is still in the DSset, it can
also prevent it from getting expired by issuing timly updates of the
keys metadata.

1 January 2014

We are in the process of deploying
DNSSEC,
the DNS Security Extensions, on the Debian zones. This means properly
configured resolvers will be able to verify the authenticity of information
they receive from the domain name system.
The plan is to introduce DNSSEC in several steps so that we can react
to issues that arise without breaking everything at once.
We will start with serving signed debian.net and
debian.com zones. Assuming nobody complains loudly enough
the various reverse zones and finally the debian.org zone will
follow. Once all our zones are signed we will publish our trust anchors
in ISC's DLV Registry, again in
stages.
The various child zones that are handled differently from our normal
DNS infrastructure
(mirror.debian.net,
alioth,
bugs,
ftp,
packages,
security,
volatile,
www)
will follow at a later date.
We are using bind 9.6 for NSEC3 support and
ourfork
of RIPE's
DNSSEC Key Management Tools
for managing our keys because we believe that it integrates nicely
with our
existing DNS helper scripts,
at least until something better becomes available.
We will use NSEC3RSASHA1 with key sizes of 1536 bits for the KSK and
1152 bits for the ZSK. Signature validity period will most likely be
four weeks, with a one week signature publication period
(cf. RFC4641: DNSSEC Operational
Practices).
Zone keys rollovers will happen regularly and will not be announced in
any specific way. Key signing key rollovers will probably be announced
on the
debian-infrastructure-announce
list until such time that our zones are reachable from a
signed root. KSK rollovers for our own
child zones (www.d.o et al.), once signed, will not be announced because
we can just put proper
DS records
in the respective parent zone.
Until we announce the first set of trust anchors on the mailinglist the
keysets present in DNS should be considered experimental. They can
be changed at any time, without observing standard rollover practices.
Please direct questions or comments to either the debian-admin or, if
you want a more public forum, the debian-project list at
lists.debian.org.
See also:

16 March 2013

I've just pushed out the release files for Obnam version
1.4, my backup application, and Larch,
my B-tree library, which Obnam uses.
They are available via my home page (http://liw.fi/). Since Debian is
frozen, I am not uploading packages to Debian, but .deb files are
available from my personal apt repository
for intrepid explorers. (I will be uploading to Debian again after the
freeze. I am afraid I'm too lazy to upload to experimental, or do
backports. Help is welcome!)
From the Obnam NEWS file:

The ls command now takes filenames as (optional) arguments, instead
of a list of generations. Based on patch by Damien Courouss .

Even more detailed progress reporting during a backup.

Add --fsck-skip-generations option to tell fsck to not check any
generation metadata.

The default log level is now INFO, instead of DEBUG. This is to be
considered a quantum leap in the continuing rise of the maturity level
of the software. (Actually, the change is there just to save some
disk space and I/O for people who don't want to be involved in Obnam
development and don't want to have massive log files.)

The default sizes for the lru-size and upload-queue-size settings
have been reduced, to reduce the memory impact of Obnam.

obnam restore now reports transfer statistics at the end, similarly
to what obnam backup does. Suggested by "S. B.".

Bug fixes:

If listing extended attributes for a filesystem that does not support
them, Obnam no longer crashes, just silently does not backup extended
attributes. Which aren't there anyway.

A bug in handling stat lookup errors was fixed. Reported by
Peter Palfrader. Symptom: AttributeError: 'exceptions.OSError'
object has no attribute 'st_ino' in an error message or log file.

A bug in a restore crashing when failing to set extended attributes
on the restored file was fixed. Reported by "S. B.".

Made it clearer what is happening when unlocking the repository due to
errors, and fixed it so that a failure to unlock is also an error.
Reported by andrewsh.

The dependency on Larch is now for 1.20121216 or newer, since that is
needed for fsck to work.

The manual page did not document the client name arguments to the
add-key and remove-key subcommands. Reported by Lars Kruse.

Restoring symlinks as root would fail. Reported and fixed by
David Fries.

Only set ssh user/port if explicitily requested, otherwise let ssh
select them. Reported by Michael Goetze, fixed by David Fries.

Fix problem with old version of paramiko and chdir. Fixed by Nick Altmann.

20 February 2013

A few years ago I was doing research comparing how large software distributions handled shared object libraries, and studied Debian, FreeBSD, and Ubuntu. Extracting data about Debian packages was easy thanks to Peter Palfrader s snapshot.debian.org service, which provides a machine-usable interface to Debian s package history. FreeBSD s data is equally accessible, albeit in a less pleasant format: their ports tree was stored in CVS until July 2012. One could easily rsync a copy of the ports tree s CVS repository to a local machine to analyze the data. This left you with a local tree full of ,v files, each corresponding to the history of a given file with at that location. I needed to extract all kinds of data from a tree full of these files, such as what revisions contained lines matching a regex, when these revisions were checked in, any tags associated with it, etc. To make things easier, it also helped to know the line numbers of the matching lines. Hence the birth of rcsgrep.
rcsgrep is a Python script that makes use of Paul McGuire s fabulous pyparsing library. It allows you to search a RCS file (the ,v file format used by RCS and CVS to store revision history) using a Python regex, and the output format is customizable to allow printing only certain kinds of information, such as the revision number, the line number, the matching line, the line s author, the date it appeared, any tags associated with the line, and (useful when running over a large number of files) the file name. To make machine parsing (using AWK of course) easier, you can also specify the column separator.
For example, I entered the lines The quick brown , fox jumped over , the lazy dog. Woof! into the file abc, checking in the changes after each line. The invocation ./rcsgrep -s ' ' -f rlLda '.*' abc,v, with spaces for column separation, and format options r is for revision, l for line number, L for line contents, d for date, and a for author, outputs:

I m particularly proud about my grep() function in rcsfile.py, which goes through each revision, tracking additions and deletions, but only keeping the lines matching the regex in memory. In any case, rcsgrep is licensed under the ISC license and can be found on github.
Addendum: I learned after the fact that O Reilly s UNIX Power Tools offers something similar by the same name, except that it is runs several processes, such as co, grep and sed, as opposed to a single Python script.

29 November 2012

Driving your firefox like vim
Recently a friend of mine pointed out
pentadactyl to me. It's a firefox add-on
to drive your browser in a vim-like style. I had tried vimperator in
the past and didn't like it very much back then, but a lot has improved
since then.
Obviously there's a learning curve involved, like in many great tools,
but I think for me it was worth it. I have it now enabled in all my
firefoxes/iceweasels.
Aloha,

23 June 2012

Participation and Results
From June 15-17th we held a Debian BugSquashingParty in Salzburg, hosted and sponsored by
conova communications GmbH. It was a fun and busy weekend,
with 15-17 people from 5 countries being around, mainly working on RC bugs in Testing/Unstable.
Gerfried Fuchs (rhonda) also worked on triaging the impact of RC bugs on the version in Squeeze,
while Peter Palfrader (weasel) took care of Tor related things and Debian sysadmin work,
including starting on the new bugs and udd hosts. Phillip Hug (hug) worked on the debian.ch infrastructure.
Together with Miroslav Such from Red Hat Bernd Zeimetz (bzed) worked on the packaging of the necessary
libraries and daemons to add (basic) Spacewalk client support to Debian. As soon as the packages passed
NEW and #677871 was applied (thanks to the APT guys for working on that
already), managing Debian clients with Spacewalk should work out of the box.
Of course we also had a little keysigning party

Statistics

about 68 bugs in unstable/testing were triaged/patched/fixed or at least pinged

54 bugs were tagged to show if they affect Squeeze, several other bugs were pinged to retrieve necessary
information or to trigger an update in the next stable pointrelease.

Accomodation
Thanks to Debian funds we were able to provide accomodation for four participants in the JUFA youth hostel in Salzburg.
We had paid in advance for eight, but changing to rooms with a higher category for only 4 people would have been equally or more expensive.

Press/Media coverage
Additionally to being mentioned in the calendars on ProLinux and similar pages, we had some press coverage by the local newspaper and online magazines:

Fun facts
We consumed 2kg of Leberkas, a big plate of "Buchteln mit Vanillesosse", about 16000cm^2 of Pizza, about 80 litres of coke, juice, beer and wine and I guess we drank at least the same amount of water. We had coffee made of 1.5kg coffee beans and managed to empty the (formerly well filled) icemaker in the fridge.
Also we had successful training sessions of a standard Debconf game (rules won't be explained here obviously). Maybe we even successfully spread the game to the employees of a commercial linux distribution

30 April 2012

I've just released version 0.27 of Obnam,
my backup application. The relevant part of NEWS:

The repository format has again changed in an incompatible manner,
so you will need to re-backup everything again. Alternatively, you can
try the new convert5to6 subcommand. See the manual page for details.
Make sure you have a copy of the repository before converting, the
code is new and may be buggy.

New option --small-files-in-btree enables Obnam to store the contents
of small files in the per-client B-tree. This is not the default, at
least yet, since it's impact on real life performance is unknown, but
it should make things go a bit faster for high latency repository
connections.

Some SFTP related speed optimizations.

Data filtering is now strictly stable and priority-ordered, ensuring that
compression always happens before encryption etc.

Repository metadata is never filtered, so that we can be sure that
in future if when we add backwards-compatibility we can detect the format
without worrying about any other filtering which might occur.

Forcing of locks is now unconditional and across the entire repository.

Uses the larch 0.30 read-only mode to fix a bug where opening a B-tree
rolls back changes someone else is making, even if we only use the tree
to read stuff from.

"obnam backup" will now exit with a non-zero exit code if there were
any errors during a backup, and the problematic files were skipped.
Thanks, Peter Palfrader, for reporting the bug.

19 February 2012

Log files are now created with permissions that allow only the owner
to read or write them. This fixes a privacy leak.

The nagios-last-backup-age subcommand is useful for setting up Nagios
(or similar systems) to check that backups get run properly. Thanks to
Peter Palfrader for the patch.

Some clarification on how the forget policy works, prompted by questions
from Peter Palfrader.

New settings ssh-known-hosts (for choosing which file to check for
known host keys), strict-ssh-host-keys (for disallowing unknown host
keys), and ssh-key (for choosing which key file to use for SSH
connections) allow better and safer use of ssh.

Checkpoints will now happen even in the middle of files (but between
chunks).

23 January 2012

The script isn't fully automated yet, I'm running it manually and watching for errors, but I do now have a simple script (~100 lines of perl) which runs edos-debcheck against each of the supported Emdebian architectures for unstable-grip and picks out those packages which are missing from the subset of packages which Emdebian monitors for Grip.

I was hoping to make these scripts into a normal Debian package but there are some limitations in that the scripts need to assume various pieces of Debian infrastructure. e.g. I started off using rsync to pull in the Packages files (along with Release and Sources) because apt has annoying behaviours with multiple architectures. (Emdebian Grip processes 7 architectures simultaneously on blavet.debian.org). Peter Palfrader kindly arranged for a local mirror to be available and now the entire Packages processing can be done using symlinks. Much, much better.

Once again, I am indebted to the EDOS team (please, please keep working on edos-debcheck - it hasn't had uploads recently) because I tried to get this working with germinate but failed. (Colin - I'll be looking to borrow some of your time to work out what was going wrong.)

The dependency resolution script now means that I can meet release team requirements that when foo is updated in sid to depend on libbar2 but Emdebian Grip only has libbar1, the scripts will automatically pick up libbar2 and add it to Emdebian Grip. The current sid version gets pulled in and (the theory goes) will migrate into testing-grip as an almost automatically valid candidate. Processing of the dependency can happen within hours of the updated version of foo arriving in Emdebian Grip but as long as it happens within a few days I think everyone will be fine with it.

I've got a sync script too which can periodically run across the entire suite and check for packages which have slipped the net. I'll have to see how often that needs to run but once a week doesn't sound too painful.

Processing for Emdebian Grip is very fast. Most of the time is taken uploading:

(It was a lot longer, comparatively, when I was having to rsync and then dget instead of just read from the local filesystem.)

I've also been working on an init script which will gradually work through the subset of packages by order of Priority - approximately what a new architecture (like armhf) would do. Note that Emdebian Grip supports armhf already. The only slight concern is whether the init script needs to be throttled back to not flood the queues with hundreds of uploads an hour (which it could end up doing, at least for the first 24 hours).

18 August 2011

You might not know who Peter is because he s not very visible on Debian mailing lists. He s very active however and in particular on IRC. He was an admin of the OFTC IRC network at the time Debian switched from Freenode to OFTC. Nowadays he s a member of the Debian System Administration team who runs all the debian.org servers.
If you went to a Debconf you probably met him since he s always looking for new signatures of his GPG key. He owns the best connected key in the PGP web of trust. He also wrote caff a popular GPG key signing tool.
Raphael: Who are you?
Peter: I m Peter Palfrader, also known as weasel. I m in my early 30s, born
and raised in Innsbruck, Austria and am now living and working in
Salzburg, Austria. In my copious free time, other than help running
Debian s servers I also help maintaining the Tor project s infrastructure.
Away from the computer I enjoy reading fiction (mostly English language
Science Fiction and Fantasy), playing board games and going to the movies.
Weather permitting, I also occasionally do some cycling.
Raphael: How did you start contributing to Debian?
Peter: I installed my first Debian the week slink came out. That was Debian
2.1 for the youngsters, in early 1999. The one thing I immediately
liked about slink was that Debian s pppd supported RAS
authentication which my university s dial-up system required. No way
I d go back to SuSE 5.3 when I had working Internet with my Debian box.
During that year I started getting involved in the German language
Debian channel on IRCnet which got me in contact with some DDs.
Christian Kurz (<shorty>) was working on Debian QA at the time
and he asked my help in writing a couple of scripts. Some of that
work, debcheck, still produces parts of the qa.d.o website, tho the relevance of
that nowadays is probably negligible.
While trying to learn more Perl earlier, I had written a program to
produce syntax highlighted HTML for code snippets in various languages.
I didn t really know what I was doing but it kinda worked, and probably
still does since I still get mail from users every now and then.
I figured that it would be really nice if people could just get my
software together with Debian. According to code2html s
Debian changelog the initial release of the package was done on a
weekday at 2:30 in the morning early in 2000, and if my memory serves me
correctly, shorty uploaded it shortly afterwards.
I started packaging a couple of other piece of software and in the same
year I sent my mail to the debian account managers to register my intent
to become a DD. No new developers where being accepted at that time
since the DAMs wanted to overhaul the entire process so I wasn t
surprised to not get any immediate reply. Of course what the silence
also meant was that the mail had been lost, but I only learned of that
later when I took all my courage to ask DAM about the status of
application a couple months later. Once that was sorted out I was
assigned an AM, did the usual dance, and got my account late in November
2000.
Raphael: Four years ago, the Debian System Administration team was a real bottleneck
for the project and personal conflicts made it almost impossible to
find solutions. You were eager to help and at some point you got
dropped as a new member in that team. Can you share your story and how
you managed the transition in the difficult climate at that time?
Peter: Ah, that was quite the surprise for an awful lot of people, me included.
Branden Robinson, who was our DPL for the 2005-2006 term, tried to get
some new blood added to DSA who were at the time quite divided. He
briefly talked to me on IRC some time in summer 2005, telling me I had
come recommended for a role on the sysadmin team . In the course of
these 15 minutes he outlined some of the issues he thought a new member
of DSA would face and asked me if I thought I could help. My reply was
cautiously positive, saying that I didn t want to step on anybody s toes
but maybe I could be of some assistance.
And that was the first and last of it, until some fine November day two
years later I got an email from Phil Hands saying I ve just added
you to the adm group, and added you to the debian-admin@d.o
alias. and welcome on board . *blink* What!?
My teammates at the time were James Troup (elmo), Phil Hands (fil),
Martin Joey Schulze and Ryan Murray (neuro).
The old team, while apparently not on good terms with one another, was
however still around to do heavy lifting when required. I still remember
when on my first or second day on the team two disks failed in the raid5
of ftp-master.debian.org aka ries. Neuro did the reinstall once new
disks had arrived at Brown University. I m sure I d have been way out
of my league had this job fallen to me.
Fortunately my teammates were all willing and able to help me find
whatever pieces of information existed that might help me learn how
debian.org does its stuff. Unfortunately a lot of it only existed in
various heads, or when lucky, in one of the huge mbox archives of the
debian-admin alias or list. Anyway, soon I was able to get my hands
dirty with upgrading from sarge to etch, which had been released about
half a year earlier.
Raphael: I know the DSA team has accomplished a lot over the last few years.
Can you share some interesting figures?
Peter: Indeed we have accomplished a lot. In my opinion the most important
of these accomplishment is that we re actually once again a team
nowadays. A team where people talk to one another and where nobody
should be a SPoF.
Since this year s debconf we are six people in the admin team: Tollef
Fog Heen (Mithrandir) and Faidon Liambotis (paravoid) joined the
existing members: Luca Filipozzi, Stephen Gran, Martin Zobel-Helas, and
myself. Growing a core team, especially one where membership comes with
uid0 on all machines, is not easy and that s why I m very glad we
managed to actually do this step.
I also think the infrastructure and our workflows have matured well over
the last four years.
We now have essential monitoring as a matter of course: Nagios not only
checks whether all daemons that should be running are in fact running,
but it also monitors hardware health of disks, fans, etc. where
possible. We are alerted of outstanding security updates that need to
be installed and of changes made to our systems that weren t then
explicitly acked by one of us.
We have set up a centralized configuration system, puppet, for some of
our configuration that is the same, or at least similar, on all our
machines.
Most, if not all, pieces of software, scripts and helpers that we use on
debian.org infrastructure is in publicly accessible git repositories.
We have good communication with other teams in Debian that need our
support, like the ftp folks or the buildd people.
As for figures, I don t think there s anything spectacular. As of the
time of our BoF at this year s DebConf, we take care of approximately
135 systems, about 100 of them being real iron, the other virtual
machines (KVM). They are hosted at over 30 different locations, tho we
are trying to cut down on that number, but that s a long and difficult
process.
We don t really collect a lot of other figures like web hits on
www.debian.org or downloads from the ftp archive. The web team might do
the former and the latter is pretty much impossible due to the
distributed nature of our mirrors, as you well know.
Raphael: The DSA team has a policy of eating its own dog food, i.e. you re trying to rely only on what s available in Debian. How does that work out and what are the remaining gaps?
Peter: Mostly Debian, the OS, just meets our needs. Sure, the update frequency
is a bit high, we probably wouldn t mind a longer release cycle. But on
the other hand most software is recent enough. And when it s not,
that s easy to fix with backports. If they aren t on backports.debian.org
already, we ll just put them there (or ask somebody else to prepare a
backport for us) and so everybody else benefits from that work too.
Some things we need just don t, and probably won t, exist in Debian.
These are mainly proprietary hardware health checks like HP s tools for
their servers, or various vendors programs to query their raid
controller. HP actually makes packages for their stuff which is very
nice, but other things we just put into /usr/local, or if we really need
it on a number of machines, package ourselves.
The push to cripple our installers and kernels by removing firmware was
quite annoying, since it made installing from the official media next to
impossible in some cases. Support for working around these limitations
has improved with squeeze so that s probably ok now.
One of the other problems is that especially on embedded platforms most
of the buildd work happens on some variation of development boards,
usually due to increased memory and hard disk requirements than the
intended market audience. This often implies that the kernel shipped
with Debian won t be usable on our own debian.org machines. This makes
keeping up with security and other kernel fixes way more error prone and
time intensive. We keep annoying the right people in Debian to add
kernel flavors that actually boot on our machines, and things are
getting better, so maybe in the future this will no longer be a problem.
Raphael: If you could spend all your time on Debian, what would you work on?
Peter: One of the things that I think is a bit annoying for admins that
maintain machines all over the globe is mirror selection. I shouldn t
have to care where my packages come from, apt-get should just fetch them
from a mirror, any mirror, that is close by, fast and recent. I don t
need to know which one it was.
We have deployed geodns for security.debian.org a while ago, and it
seems to work quite well for the coarse granularity we desired for that
setup, but geodns is an ugly hack (I think it is a layer violation), it
might not scale to hundreds or thousands of mirrors, and it doesn t play
well with DNSSEC.
What I d really like to see is Debian support apt s mirror method that
I think (and I apologize if I m wronging somebody) Michael Vogt implemented
recently. The basic idea is that you simply add deb
mirror://mirror.debian.org/ or something like that to your
sources.list, and apt goes and asks that server for a list of mirrors it
should use right now.
The client code exists, but I don t know how well tested it is. What is
missing is the server part. One that gives clients a mirror, or list of
mirrors, that are close to them, current, and carry their architecture.
It s probably not a huge amount of work, but at the same time it s also
not entirely trivial. If I had more time on my hands this is something
that I d try to do. Hopefully somebody will pick it up.
Raphael: What motivates you to continue to contribute year after year?
Peter: It s fun, mostly. Sure, there are things that need to be done regularly
that are boring or become so after a while, but as a sysadmin you tend
to do things once or twice and then seek to automate it.
DSA s users, i.e. DDs, constantly want to play with new services or
approaches to make Debian better and often they need our support or help
in their endeavors. So that s a constant flow of interesting
challenges.
Another reason is that Debian is simply where some of my friends are.
Working on Debian with them is interacting with friends.
I not only use Debian at debian.org. I use it at work, I use it on my
own machines, on the servers of the Tor project. When I was with OFTC
Debian is what we put on our machines. Being a part of Debian is one
way to ensure what Debian releases is actually usable to me,
professionally and with other projects.
Raphael: Is there someone in Debian that you admire for their contributions?
Peter: That s a hard one. There are certainly people who I respect greatly for
their technical or other contributions to Debian, but I don t want to
single anybody out in particular. I think we all, everyone who ever
contributed to Debian with code, support or a bug report, can be very
proud of what we are producing one of the best operating systems out
there.
Thank you to Peter for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

21 July 2011

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004.
He s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details.
Raphael: Who are you?
Martin: I m Martin Michlmayr. I m 32, originally from Austria, and currently living in the UK.
I ve contributed to various free software projects over the years but
Debian is without doubt the one I m most passionate about. I joined Debian
in 2000 when I was a student. I worked on Debian more or less full time
for a few years while I was pretending to study. Later I started a PhD to
do research about quality and management aspects of volunteer free software
projects. I investigated the release process in several free software
projects, in particular looking at time-based releases. After finishing my
PhD in 2007, I joined Hewlett-Packard. I m part of HP s Open Source
Program Office and work on various free software and open source
activities, both internally and within the community.
Raphael: How did you start contributing to Debian?
Martin: I first used Debian in the days of 0.93R6, some time around the end of
1995. The 0.93R6 release was still based on a.out but I needed an
ELF-based system for some application, so I moved to Slackware. I then
quickly moved to Red Hat Linux where I stayed for several years. I
rediscovered Debian in 2000 and quickly decided to join the project. I
cannot recall how I rediscovered Debian but when I did, it was clear to me
that Debian was the ideal project for me: I could identify with its
philosophy, I liked the volunteer nature of the project, and I found the
size and diversity of Debian interesting since a large project offers a lot
of different challenges and opportunities.
I remember how many new things there were to learn and back then the
documentation and other resources for new contributors were nowhere as good
as they are today. My application manager, Julian Gilbey, was a great
help he was incredibly friendly and passionate about Debian. I also
remember meeting up with Peter Palfrader (weasel) for key signing when we
were both in the New Maintainer queue. I was incredibly lucky with my New
Maintainer process and soon became an official Debian Developer. Because
there was a shortage of application managers, my first major contribution
in Debian was to become an application manager myself and help other people
join the project.
Debian is a large project with a long history and a rich culture, so new
contributors should expect that it will take some time to become familiar
with everything. Fortunately, there are many resources, such as
documentation and the debian-mentors list, for new contributors. Another
great way to become familiar with the way things are done in Debian is to
subscribe to various Debian mailing lists and ideally to read some mailing
list archives. It s also a great idea to attend the Debian Conference or
other conferences since meeting people in real life is a great way to
integrate. I remember attending Debian Conference 1 in Bordeaux where I
gave my first public talk.
Finally, new contributors should find an area where they can make a unique
contribution. Most people in Debian maintain packages but there are so
many other ways to contribute. For example, most of my contributions were
not technical but were about coordination and other organizational
activities.
Raphael: What s your biggest achievement within Debian?
Martin: I m particularly proud of a number of achievements:

New Maintainer: I helped a lot of people join Debian. It s great to
help someone join the project and then see how they contribute. Of course,
some people join Debian and then quickly become inactive or retire you
never know in advance how it will work out. But I had the pleasure to help
some truly outstanding contributors to join Debian.

Quality Assurance: I helped improve QA processes within Debian. In
particular, I realized a few years ago that a lot of packages had
maintainers who were inactive and that nobody did anything about it. I
started to write to those maintainers to see what could be done. It s hard
because you don t know the circumstance of someone they may be inactive
because of an illness or for other good reasons so you have to be
friendly, but yet persistent. Fortunately, most maintainers I contacted
were truly inactive and so they couldn t complain when I took their
packages away.

DPL: I acted as the Debian Project Leader for two years. I m
particularly proud of this because Debian is a great project and it was an
honour to represent it. I performed important organizational and
coordination tasks. I also traveled to a lot of conferences and had the
pleasure to meet many Debian Developers as well as users of Debian. It s
very motivating to meet users and to hear how they use Debian and how we
can further improve it.

Debian on NAS: Debian is without the doubt the Linux distro with the
best support for NAS (Network Attached Storage) devices. I was always
impressed by what the OpenWRT folks have done to support wireless routers
and wanted to do something similar for Debian. Unfortunately, wireless
routers just don t have enough storage for a full distro. But then NAS
devices came along and they obviously have enough space since they are
meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help?
Martin: There are plenty of instructions on the Internet to install Linux
distributions on NAS or various embedded devices by connecting a serial
console and then typing in hundreds of commands. What I found is that such
instructions significantly limit the user base because they are way too
complicated for most users. There are just too many steps that can go wrong.
So instead, in Debian, we provide a solution that just works: usually, you
download a firmware image for your NAS device from Debian and when you
upgrade you get the Debian installer. You connect to the installer via SSH
and perform a normal installation. The installer knows about the device
and will prepare everything for you automatically for example, it knows
if the device has requirements for the partition layout and it will install
the kernel where the device expects to find it; unfortunately, NAS devices
are not like PCs, so the requirements are different for almost every device
and therefore you need special code to support a new device. Finally,
there are detailed installation guides and we provide help on our mailing
lists.
There are a number of technical areas for improvement. The installation
could be made even easier, and it would be nice to support new platforms
and devices.
A bigger problem is that while we ve implemented a great solution for NAS
devices, we haven t really extended this work to support other classes of
devices. For example, tablets and mobile phones are getting incredibly
popular and we don t have a compelling solution for such devices, mostly
because of the lack of an appropriate GUI.
Raphael: What are your plans for Debian Wheezy?
Martin: I ve recently been asked by Stefano Zacchiroli, our current Debian Project
Leader, to coordinate the care-taking of Debian finances. Debian, as a
volunteer project, relies on donations and in-kind gifts (e.g. hardware) to
maintain its infrastructure and to support various development efforts,
such as funding sprints and other developer gatherings. Debian s money and
other assets are held by affiliate organizations around the world.
My responsibility will be to keep track of money and other assets (e.g.
hardware and trademarks), work with the DPL to establish procedures related
to the use of Debian s assets, and make sure that the procedures are
followed. Finally, we want to publish public statements so our donors know
how we use their donations to further improve Debian. I just started
working on this and this will be my main activity in Debian in the coming
months.
Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support?
Martin: First of all, I should make it clear that I don t decide how Debian spends
its money. This is up to the DPL to decide together with the project at a
whole. I ll just make sure that procedures are followed and expenses
tracked and reported properly.
Having said that, in my opinion, it s unlikely that Debian as a project will
fund this effort. It would be inconsistent with the position of the
project not to fund work directly (only some related expenses, such as
travel costs to allow Debian teams to organize face-to-face meetings).
Whether Debian should support the fundraising effort by helping to promote
it is another question and that s probably not as clear cut. It looks like
a worthwhile effort, but on the other hand it would be unfair for authors
of other Debian books for Debian to put its weight behind one and there
are many other efforts that are worth promoting if you promote one,
where do you stop? So while it sounds worthwhile, it s probably better for
Debian to stay out of it.
But somehow related to this, I sometimes worry about the fact that there are so
few paid opportunities around Debian. If you contribute to the Linux
kernel for a while, you have an excellent chance to get hired by someone
and to work on the kernel full time. The kernel may be an extreme example
but there are a lot of projects that have more paid opportunities than
Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE.
Obviously, there are some Debian Developers who can spend some time on
Debian as part of their job. I know that some Canonical employees
contribute to Debian, that support companies like credativ improve Debian
as part of their work, and that system administrators fix bugs or package
new software as they deploy Debian. But I think this is a minority of
contributors and even they don t work full time on Debian. Instead what I
see is that a lot of people leave university, get a job and then no longer
have time for Debian or people start a family and no longer have time.
I can take myself as an example since I don t have nearly as much time as I
did in the past when I was a student.
I guess there are different ways to deal with this problem one would be
to create more paid opportunities around Debian outside the project, another
one might be to make it easier for new volunteers to join the project. I
don t have the answers to these questions but it s something I wonder
about, and I also wonder whether pure volunteer projects can still keep up
with projects with a lot of full time contributors.
Raphael: What motivates you to continue to contribute year after year?
Martin: Debian is a great project with a great mission, goals and people. I
contribute to make Debian a better solution and to promote the free
software philosophy. Finally, the community around Debian provides a lot
of motivation. It s amazing how much I ve learned about other cultures
because of my involvement in Debian and how many friends I ve made over the
years all around the world.
Raphael: Do you have wishes for Debian Wheezy?
Martin: Not really. I m pretty happy with the way things are going at the moment.
We have made a lot of organizational changes in the last few years from
which the project has greatly benefited. I m particularly pleased about
the plans to adopt a time-based freeze.
Raphael: Is there someone in Debian that you admire for their contributions?
Martin: There are many people I admire greatly. I d like to mention Joey Hess
because he s a great example to follow. He doesn t get involved in
politics, is easy to work with and does great technical work. In fact, he
has made not one but several contributions that have completely changed
Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has
a lot of contributors who have done great work over the years but who are
not very vocal about it. People like Colin Watson or Peter Palfrader.
Debian has many unique contributors and the list of people I admire is much
longer than the few people I just mentioned.
Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.