Today, 4PM. Jacob and Oliver excitedly peer at the box in our kitchen a really big box, taller than them. Inside is is the first model airplane I d ever purchased. The three of us hunkered down on the kitchen floor, opened the box, unpacked the parts, examined the controller, and found the manual with cryptic assembly directions. Oliver turned some screws while Jacob checked out the levers on the controllers. Then they both left for a bit to play with their toy buses. A little while later, the three of us went outside. It was too windy to fly. I had never flied an RC plane before only RC quadcopters (much easier to fly), and some practice time on an RC simulator. But the excitement was too much. So out we went, and the plane took off perfectly, climbed, flew over the trees, and circled above our heads at my command. I even managed a good landing in the wind, despite about 5 aborted attempts due to coming in too high, wrong angle, too fast, or last-minute gusts of wind throwing everything off. I am not sure how I pulled that all off on my first flight, but somehow I did! It was thrilling! I ve had a lot of hobbies in my life. Computers have run through many of them; I learned Pascal (a programming language) at about the same time I learned cursive handwriting and started with C at around age 10. It was all fun. I ve been a Debian developer for some 18 years now, and have written a lot of code, and even books about code, over the years. Photography, music, literature, history, philosophy, and theology have been interests for quite some time as well. In the last few years, I ve picked up amateur radio, model aircraft, etc. And last month, Laura led me into Ada s Technical Books during our visit to Seattle, resulting in me getting interested in Arduino. (The boys and I have already built a light-activated crossing gate for their HO-gauge model trains, and Jacob can now say he s edited a few characters of C!) Sometimes I find ways to merge hobbies; I ve set up all sorts of amateur radio systems on Linux, take aerial photographs, and set up systems to stream music in my house. But I also have a lot less time for hobbies overall than I once did; other things in life, such as my children, are more important. Some of the code I once worked on actively I no longer use or maintain, and I feel guilty about that when people send bug reports that I have no interest in fixing anymore. Sometimes I feel a need to cut down, and perhaps have; and then, I get an interest in RC aircraft and find an airplane that is great for a beginner and fairly inexpensive. Perhaps it is the curse of being a curious person living in an interesting world. Do any of the rest of you have a large number of hobbies? How do you feel about that?

Laptop, I demand that you suspend! Dear Lazyweb, Sometimes some application prevents suspend on my laptop. I want to disable that feature: how? I understand that there may exist some people who like that feature. I, on the other hand, consider a scenario like this inconceivable:

1. I'm on a plane working with my laptop, the captain announces preparations for landing, so I quickly hit the suspend button (or close the lid) on my laptop and stow it away.
2. One connecting flight later, I pick up my backpack, I feel it unusually hot and realise that my laptop has been on all along, and is now dead from either running out of battery or thermal protection.
3. I think things that, if spoken aloud in front of a pentacle, might invoke major lovecraftian horrors.

I do not want this scenario to ever be possible. I want my suspend button to suspend the laptop no matter what. If a process does not agree, I'm fine with suspending it anyway, or killing it. If I want my laptop to suspend, I generally have a good enough real-world reason for it, and I cannot conceive that a software could ever be allowed to override my command. How do I change this? I don't know if I should look into systemd, upowerd, pm-utils, the kernel, the display manager or something else entirely. I worry that I cannot even figure where to start looking for a solution. This happened to me multiple times already, and I consider it ridiculous. I know that it can cause me data loss. I know that it can cause me serious trouble in case I was relying on having some battery or state left at my arrival. I know that depending on what is in my backpack, this could also be physically dangerous. So, what knob do I tweak for this? How do I make suspend reliable? Update Systemd has an inhibitor system, and systemd-inhibit --list only lists 'delay' blocks in my system. It is an interesting feature that seems to be implemented in the right way, and it could mean that I finally can get my screen to be locked before the system is suspended. It is possible to configure the inhibitor system in /etc/systemd/logind.conf, including ways to ignore inhibitors, and a maximum time after which inhibitors are ignored if not yet released. Try as I might to run everything that I was running on the plane that time, I could not manage to see anything take an inhibitor block that could have prevented my suspend. I now suspect that what happened to me was a glitch caused by something else (hardware? kernel? cosmic rays!) during that specific suspend. When I had this issue in the past it looks like the infrastructure at the time was far more primitive that what we have now with systemd, so I guess that when writing my blog post I had simply correlated my old experiences with a one-off suspend glitch. If I want to investigate or tune further, to test the situation with a runaway block, I can use commands like systemd-inhibit --mode=block sleep 3600. I'm quite happy to see that we're moving to a standard and sane system for this. In the meantime, I have learnt that pm-utils has now become superfluous and can be deinstalled, and so can acpi-support and acpi-support-base. Thanks vbernat, mbiebl, and ah, on #debian-devel for all the help.

It is time for another report on Listaller, the cross-distro 3rd-party package installer, which is now in development for depending how you count 5-6 years. This will become a longer post, so you might grab some coffee or tea The original idea The Listaller project was initially started with the goal to make application deployment on Linux distributions as simple as possible, by providing a unified package installation format and tools which make building apps for multiple distributions easier and deployment of updates simple. The key ideas were:

• Seamless integration of all installation steps into the system users shouldn t care about the origin of their application, they just handle all installed apps with the same tool and update all apps with the same interface they use for updating the system.
• Out-of-the-boy sandboxing for all 3rd-party apps
• Easy signing and key-validation for Listaller packages
• Simple creation of updates for developers
• Resource-sharing: It should always be clear which application uses which library, duplicates should be avoided. The distribution-provided software should take priority, since it is often well-maintained and receives security updates.

The current state The current release of Listaller handles all of this with a plugin for PackageKit, the cross-distro package-management abstraction layer. It hooks into PackageKit and reads information passing through to the native distributor backend, and if it encounters Listaller software, it handles it appropriately. It can also inject update information. This results in all Listaller software being shown in any PackageKit frontends, and people can work with it just like if the packages were native packages. Listaller package installations are controlled by a machine policy, so the administrator can decide that e.g. only packages from a trusted source (= GPG signature in trusted database) can be installed. Dependencies can be pulled from the distributor s repositories, or optionally from external sources, like the PyPI. This sounds good on paper, but the current implementation has various problems. The issues The current Listaller approach has some problems. The biggest one lies in the future: Soon, there will be no PackageKit plugins anymore! PackageKit 1.0 will remove support for them, because they appear to be a major source for crashes, even the in-tree plugins cause problems. Also, the PackageKit service itself is currently being trimmed of unneeded features and less-used code. These changes in PackageKit are great and needed for the project (and I support these efforts), but they cause a pretty huge problem for Listaller: The project relies on the PackageKit plugin if used without it, you loose the system-integration part, which is one of the key concepts of Listaller, and a primary goal. But this issue is not the only one. There are more. One huge problem for Listaller is dependency-solving: It needs to know where to get software from in case it isn t installed already. And that has to be done in a cross-distributional way. This is an incredibly complex task, and Listaller contains lots of workarounds for various quirks. It contains so much hacks for distro-specific stuff, that it became really hard to understand. The Listaller dependency model also became very complex, because it tried to handle many corner-cases. This is bad, of course. But the workarounds weren t added for fun, but because it was assumed to be easier than to fixing the root cause, which would have required collaboration between distributors and some changes on the stack, which seemed unlikely to happen at the time the code was written. The systemd effort Also a thing which affects Listaller, is the latest push from the systemd team to allow cross-distro 3rd-party installations to happen. I definitively recommend reading the linked blogpost from Lennart, if you have some spare time! The identified problems are the same as for Listaller, but the solution they propose is completely different, and about three orders of magnitude more invasive than whatever the Listaller project had in mind (I make these numbers up, so don t ask!). There are also a few issues I see with Lennarts approach, I will probably go into detail about that in another blogpost (e.g. it requires multiple copies of a library lying around, where one version might have a security vulnerability, and another one doesn t it s hard to ensure everything is up to date and secure that way, even if you have a top-notch sandbox). I have great respect for the systemd crew and especially Lennart, and I hope them to succeed with their efforts. However, I also think Listaller can achieve a similar things with a less-invasive solution, at least for the 3rd-party app-installations (Listaller is one of the partial-fix solutions with strict focus, so not a direct competitor to the holistic systemd approach. Both solutions could happily live together.) A step into the future Some might have guessed it already: There are some bigger changes coming to Listaller! The most important one is that there will be no Listaller anymore, at least not in its old form. Since the current code relies heavily on the PackageKit plugin, and contains some ugly workarounds, it doesn t make much sense to continue working on it. Instead, I started the Listaller.NEXT project, which is a rewrite of Listaller in C. There are a some goals for the rewrite:

• No stupid hacks and workarounds: We will not add any workaround. If there is a problem, we will fix it at its source, even if that might be more invasive.
• Trimmed down project: The new incarnation of Listaller will only support installations of statically linked software at the beginning. We will start with a very small, robust core, and then add more features (like dependency-solving) gradually, but only if they are useful. There will be no feature-creep like in the previous version.
• Faster development cycle: Releases will happen much faster, not only two or three times a year
• Integration: Since there is no PackageKit plugin anymore, but integration is still one of Listaller s key concepts, we will integrate Listaller into downstream tools, ranging from Apper to GNOME-Software. Richard Hughes will help with the integration and user interfaces, so Listaller applications get displayed properly.
• AppStream-first: AppStream is the ultimate tool for Listaller to detect dependencies. With the 0.6 release, the Listaller component-concept was merged into it, which makes it a very powerful and non-hackish solution for dependency-detection. We will advance the use of its metadata, and probably use it exclusively, which would restrict Listaller to only work properly on distributions which ship AppStream metadata.
• No desktop-only focus: The previous Listaller was focused only on desktop GUI apps. The new version will be developed with a much larger target audience in mind, including server deployments ( Can I use it to deploy my server app is one very frequently asked questions about Listaller with the new version, the answer is yes)
• We will continue to improve the static-linking and cross-distro development toolchain (libuild, with ligcc, lig++ and binreloc), to make building portable apps easier.

I made a last release of the 0.5.x series of Listaller, to work with PackageKit 0.9.x the future lies in the C port. If you are using Listaller (and I know of people who do, for example some deploy statically-linked stuff on internal test-setups with it), stay tuned. The packaging format will stay mostly compatible with the current version, so you will not see many changes there (the plan is to freeze it very soon, so no backwards-incompatible changes are made anymore). The o.5.x series will receive critical bugfixes if necessary. Help needed! As always, there is help needed! Writing C is not that difficult But user feedback is welcome as well, in case you have an idea. The new code will be hosted on Github in the new listaller-next branch (currently not that much to find there). Long-term, we will completely migrate away from Launchpad. You can expect more blogposts about the Listaller concepts and progress in the next months (as soon as I am done with some AppStream-related things, which take priority).

It has been one week since I m back from DebConf14 and I m still recovering and catching up with things. DebConf14 has been amazing, it has been great to be back after missing it for two years. Thanks a lot to everybody who helped to make it real. On my side, I helped a bit in the talks team. During DebConf14, I got the opportunity to discuss with Rene Mayorga about the MIA work-flow and we also got some feedback in the MIA BoF. We have plenty of ideas to implement and we re aiming to improve things during this next year. This summer has been also 10 years since I started contributing to Debian. It s hard to believe. Ten years ago I barely knew where to start helping and now I have an endless TODO list of things I would like to do. And always during DebConf this list seems to grow ten times faster than usual. Thankfully, also motivation increases a lot :)

Unfortunately I was not able to attend debconf this year but thanks to the awesome video team the all the talks are available for your viewing pleasure. In order to recreate an authentic Portland experience, I took my laptop into the shower along with a vegan donut and had my children stand outside yelling excerpts from salon.com in whiny Canadianesque accents. Here are some notes I took as I watched the talks. Welcome Talk

• Why is everyone on stage wearing shorts? Is this a thing now?
• Langasek is pronounced with a 'sh' I did not know that.
• Kees is pronounced 'case' I also did not know that.
• Steve missed a good opportunity for a "Who moved my cheese?" joke. (Hey its not any more obscure than the "white Chevy Nova" joke.)
• A well-deserved award to Russ Allbery from some of the UK people for being the voice of reason on the mailing lists. See Vincent Sanders blog for details.
  

Debian in the Dark Ages of Free software - Stefan Zacchiroli

• More shorts. I am starting to feel overdressed.
• Stefan reminisces about how he got involved in Free Software and his philosophy of the same. A good introduction for anyone wondering what
  makes a Debian hacker tick.
• We should be concerned about software freedom in the new "cloud" environments. Debian can play an important role in this by making it really simple for
  users to set up their own cloud environments. My take: the focus should
  be on free standards and protocols. The power that Google, Facebook etc.
  have is drastically reduced if it is easy to jump ship.

Weapons of the Geek - Gabriella Coleman

• pro: no shorts con: womens slacks
• Intriguing anthropological investigation into Anonymous and how it/they relate to Free Software.
• Coc acknowledged then ignored. Why do we need it again?
• "Anonymous has cabals ... [that] make the cabals within Debian look like childs play."

bugs.debian.org -- Database Ho! - Don Armstrong

• I would settle for a lungi at this point but noooo shorts again. (plaid to boot.)
• The return of my yearly guilt about undertaking to Don to add RSS support to debbugs way back at debconf 10 and not following up on it. Damn it, I am going to get this done now.
• Sadly, the initial part of the stream is missing and it begans right in the middle of Don saying something interesting.


• "I have to admit my primary motivation for giving a talk was to try to force myself into actually doing the work I'm talking about."
• Stats porn. The BTS is growing at a phenomenal rate. bugs opened 142/day. But only 95/day closed.

Grub Ancient and Modern - Colin and Watson

• pro: no shorts con: kilt
• I was interested in this talk because one of these days I want to get GRUB 2 running on Debian Minix but a lot went over my head so I'll have to do some
  more research first.

One year of fedmsg in Debian - Nicolas Dandrimont

• trouser status: undetermined
• Problem: There are many different services providing information in Debian but they do not interop very well.
• fedmsg is a unified message bus originally developed by Fedora who were facing a similar problem.


• It has now been implemented in Debian.

Coming of Age: My Life with Debian - Christine Spang

• trouser sta- oh the hell with this.
• Another talk which is more biographical than technical. Again, useful to help understand the motivations of hackers.
• What interests me is that for younger generations it was open source which was a novel idea whereas for those of who grew up in the 8-bit era, having
  to hack on a computer was expected (whether you wanted to or not and it was
  proprietary software you couldn't share which was considered new and strange.

Status report of the Debian Printing Team - Didier Raboud

• Ou est les pantalons? Je ne sais pas. (Apologies to Mme Terzini.)
• Kudos to Didier for taking up this augean task mostly on his own. Despite the long-promised "paperless" office I need to be able to print and I was
  pleasantly surprised that my new xerox all-in-one worked under Debian with
  very little hassle.
• Brother sucks. Don't buy their printers. Ditto for Epson and Samsung.
• Buy HP instead.

Bluetooth network error. I think it's a network-manager feature to be able to use bluetooth tethering. I think it's a network-manager bug that when bluetooth tethering fails due to some error, and does not report that error. Yesterday I finally figured out what was going wrong after staring at hcidump. It was obvious after I did. I've reset my tablet so bluetooth PIN was wrong. If only the GUI told me that.

A few days ago I watched a Q/A session with Linus Torvalds at Debconf 14. One of the main complaint of Linus towards Linux distribution was the way that distribution ends up using different versions of libraries than what has been used during application development. And the fact that it s next to impossible to support properly all Linux distributions at the same time due to this kind of differences.
And now I just discovered a new proposal of the systemd team that basically tries to address this: Revisiting how we put together Linux Systems. They suggest to make extensive use of btrfs subvolumes to host multiple variants of the /usr tree (that is supposed to contain all the invariant system code/data) that you could combine with multiple runtime/framework subvolumes thanks to filesytem namespaces and make available to individual applications. This way of grouping libraries in runtime subvolumes reminds me a bit of the concepts of baserock (they are using git instead of btrfs) and while I was a bit dubious of all this (because it goes against quite a few of the principles of distribution integration) I m beginning to believe that there s room for both models to work together. It would be nice if Debian could become the reference distribution that upstream developers are using to develop against Linux. This would in turn mean that when upstream distribution their application under this new form, they will provide (or reference) Debian-based subvolumes ready for use by users (even those who are not using Debian as their main OS). And those subvolumes would be managed by the Debian project (probably automatically built from our collection of .deb). We re still quite far from this goal but it will interesting to see this idea mature and become reality. There are plenty of challenges facing us.

18 comments Liked this article? Click here. My blog is Flattr-enabled.

After spending a while fighting with upstart, at work, I decided that systemd couldn't be any worse and yesterday morning upgraded one of my servers to run it. I have two classes of servers:

• Those that run standard daemons, with nothing special.
• Those that run different services under runit
  • For example docker guests, node.js applications, and similar.

I thought it would be a fair test to upgrade one of each systems, to see how it worked. The Debian wiki has instructions for installing Systemd, and both systems came up just fine. Although I realize I should replace my current runit jobs with systemd units I didn't want to do that. So I wrote a systemd .service file to launch runit against /etc/service, as expected, and that was fine. Docker was a special case. I wrote a docker.service + docker.socket file to launch the deamon, but when I wrote a graphite.service file to start a docker instance it kept on restarting, or failing to stop. In short I couldn't use systemd to manage running a docker guest, but that was probably user-error. For the moment the docker-host has a shell script in root's home directory to launch the guest:

#!/bin/sh
#
# Run Graphite in a detached state.
#
/usr/bin/docker run -d -t -i -p 8080:80 -p 2003:2003 skxskx/graphite

Without getting into politics (ha), systemd installation seemed simple, resulted in a faster boot, and didn't cause me horrific problems. Yet. ObRandom: Not sure how systemd is controlling prosody, for example. If I run the status command I can see it is using the legacy system:

root@chat ~ # systemctl status prosody.service 
prosody.service - LSB: Prosody XMPP Server
      Loaded: loaded (/etc/init.d/prosody)
      Active: active (running) since Wed, 03 Sep 2014 07:59:44 +0100; 18h ago
      CGroup: name=systemd:/system/prosody.service
            942 lua5.1 /usr/bin/prosody

I've installed systemd and systemd-sysv, so I thought /etc/init.d was obsolete. I guess it is making pretend-services for things it doesn't know about (because obviously not all packages contain /lib/systemd/system entries), but I'm unsure how that works.

my setup, take #1 Among the various things I've catched up with during the summer, I've finally managed to set aside some time to answer a pending interview request for The [GNU/]Linux Setup: a blog run by Steven Ovadia that collects interviews about how people use GNU/Linux-based desktops. In the interview I discuss my day to day work-flow, from GNOME Shell to Mutt, from Emacs to Notmuch, and the various glue code tools I've written for integrating them. Enjoy! Feedback is most welcome.

exercism.io is a croud-sourced mentorship platform for learning to program. In my opinion, they do a lot of things right. In particular, an exercise on exercism.io consists of a descriptive README file and a set of test cases implemented in the target programming language. The tests have two positive sides: You learn to do test-driven development, which is good. And you also have an automated validation suite. Of course, a test can not give you feedback on your actual implementation, but at least it can give you an idea if you have managed to implement what was required of you. But that is not the end of it. Once you have submitted a solution to a particular exercise, other users of exercism.io can comment on your implementation. And you can, as soon as you have submitted the first implementation, look at the solutions that other people have submitted to that particular problem. So knowledge transfer can happen both ways from there on: You can learn new things from how other people have solved the same problem, and you can also tell other people about things they might have done in a different way. These comments are, somewhat appropriately, called nitpicks on exercism.io. Now, exercism has recently gained a C++ track. That track is particularily fun, because it is based on C++11, Boost, and CMake. Things that are quite standard to C++ development these days. And the use of C++11 and Boost makes some solutions really shine.

After becoming a DM at Debconf12 in Managua, Nicaragua and entering the NM queue during Debconf13 in Vaumarcus, Switzerland I received the mail about 24 hours too late to officially become a DD during Debconf14 in Portland, USA. Nevertheless it was a very pleasant surprise to find the mail in my INBOX this morning confirming that my account had been created and that I was officially ijc@debian.org. Thanks to everyone who helped/encouraged me along the way! I don't imagine much will change in practice, I intend to remain involved in the kernel and Debian Installer efforts as well as continuing to contribute to the Xen packaging and to maintain qcontrol (both in Debian and upstream) and sunxi-tools. I suppose I also still maintain ivtv-utils and xserver-xorg-video-ivtv but they require so little in the way of updates that I'm not sure they count.

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (65.55 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Distro Tracker Even though I was officially in vacation during 3 of the 4 weeks of August, I spent many nights working on Distro Tracker. I m pleased to have managed to bring back Python 3 compatibility over all the (tested) code base. The full test suite now passes with Python 3.4 and Django 1.6 (or 1.7). From now on, I ll run tox on all code submitted to make sure that we won t regress on this point. tox also runs flake8 for me so that I can easily detect when the submitted code doesn t respect the PEP8 coding style. It also catches other interesting mistakes (like unused variable or too complex functions). Getting the code to pass flake8 was also a major effort, it resulted in a huge commit (89 files changed, 1763 insertions, 1176 deletions). Thanks to the extensive test suite, all those refactoring only resulted in two regressions that I fixed rather quickly. Some statistics: 51 commits over the last month, 41 by me, 3 by Andrew Starr-Bochicchio, 3 by Christophe Siraut, 3 by Joseph Herlant and 1 by Simon Kainz. Thanks to all of them! Their contributions ported some features that were already available on the old PTS. The new PTS is now warning of upcoming auto-removals, is displaying problems with uptream URLs, includes a short package description in the page title, and provides a link to screenshots (if they exist on screenshots.debian.net). We still have plenty of bugs to handle, so you can help too: check out https://tracker.debian.org/docs/contributing.html. I always leave easy bugs for others to handle, so grab one and get started! I ll review your patch with pleasure. Tryton After my last batch of contributions to Tryton s French Chart of Accounts (#4108, #4109, #4110, #4111) C dric Krier granted me commit rights to the account_fr mercurial module. Debconf 14 I wasn t able to attend this year but thanks to awesome work of the video team, I watched some videos (and I still have a bunch that I want to see). Some of them were put online the day after they had been recorded. Really amazing work! Django 1.7 After the initial bug reports, I got some feedback of maintainers who feared that it would be difficult to get their packages working with Django 1.7. I helped them as best as I can by providing some patches (for horizon, for django-restricted-resource, for django-testscenarios). Since I expected many maintainers to be not very pro-active, I rebuilt all packages with Django 1.7 to detect at least those that would fail to build. I tagged as confirmed all the corresponding bug reports. Looking at https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-django@packages.debian.org;tag=django17, one can see that some progress has been made with 25 packages fixed. Still there are at least 25 others that are still problematic in sid and 35 that have not been investigated at all (except for the automatic rebuild that passed). Again your help is more than welcome! It s easy to install python-django 1.7 from experimental and they try to use/rebuild the packages from the above list. Dpkg translation With the freeze approaching, I wanted to ensure that dpkg was fully translated in French. I thus pinged debian-l10n-french@lists.debian.org and merged some translations that were done by volunteers. Unfortunately it looks like nobody really stepped up to maintain it in the long run so I did myself the required update when dpkg 1.17.12 got uploaded. Is there anyone willing to manage dpkg s French translation? With the latest changes in 1.17.13, we have again a few untranslated strings:
$ for i in $(find . -name fr.po); do echo $i; msgfmt -c -o /dev/null --statistics $i; done
./po/fr.po
1083 translated messages, 4 fuzzy translations, 1 untranslated message.
./dselect/po/fr.po
268 translated messages, 3 fuzzy translations.
./scripts/po/fr.po
545 translated messages.
./man/po/fr.po
2277 translated messages, 8 fuzzy translations, 3 untranslated messages.
Misc stuff I made an xsane QA upload (it s currently orphaned) to drop the (build-)dependency on liblcms1 and avoid getting it removed from Debian testing (see #745524). For the record, how-can-i-help warned me of this after one dist-upgrade. With the Django 1.7 work and the need to open up an experimental branch, I decided to switch python-django s packaging to git even though the current team policy is to use subversion. This triggered (once more) the discussion about a possible switch to git and I was pleased to see more enthusiasm this time around. Barry Warsaw tested a few workflows, shared his feeling and pushed toward a live discussion of the switch during Debconf. It looks like it might happen for good this time. I contributed my share in the discussions on the mailing list. Thanks See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

This time, for personal reasons I wasn t able to attend the full DebConf, which started on the Saturday August 22nd. I arrived at Portland on the Tuesday the 26th by noon, at the 4th of the conference. Even though I would like to arrive earlier, the loss was alleviated by the work of the amazing DebConf video team. I was able to follow remotely most of the sessions I would like to attend if I were there already. As I will say to everyone, DebConf is for sure the best conference I have ever attended. The technical and philosophical discussions that take place in talks, BoF sessions or even unplanned ad-hoc gathering are deep. The hacking moments where you have a chance to pair with fellow developers, with whom you usually only have contact remotely via IRC or email, are precious. That is all great. But definitively, catching up with old friends, and making new ones, is what makes DebConf so special. Your old friends are your old friends, and meeting them again after so much time is always a pleasure. New friendships will already start with a powerful bond, which is being part of the Debian community. Being only 4 hours behind my home time zone, jetlag wasn t a big problem during the day. However, I was waking up too early in the morning and consequently getting tired very early at night, so I mostly didn t go out after hacklabs were closed at 10PM. Despite all of the discussion, being in the audience for several talks, other social interactions and whatnot, during this DebConf I have managed to do quite some useful work. debci and the Debian Continuous Integration project I gave a talk where I discussed past, present, and future of debci and the Debian Continuous Integration project. The slides are available, as well as the video recording. One thing I want you to take away is that there is a difference between debci and the Debian Continuous Integration project:

• debci is a platform for Continuous Integration specifically tailored for the Debian repository and similar ones. If you work on a Debian derivative, or otherwise provides Debian packages in a repository, you can use debci to run tests for your stuff.
  • a (very) few thinks in debci, though, are currently hardcoded for Debian. Other projects using it would be a nice and needed peer pressure to get rid of those.
• Debian Continuous Integration is Debian s instance of debci, which currently runs tests for all packages in the unstable distribution that provide autopkgtest support. It will be expanded in the future to run tests on other suites and architectures.

A few days before DebConf, C dric Boutillier managed to extract gem2deb-test-runner from gem2deb, so that autopkgtest tests can be run against any Ruby package that has tests by running gem2deb-test-runner --autopkgtest. gem2deb-test-runner will do the right thing, make sure that the tests don t use code from the source package, but instead run them against the installed package. Then, right after my talk I was glad to discover that the Perl team is also working on a similar tool that will automate running tests for their packages against the installed package. We agreed that they will send me a whitelist of packages in which we could just call that tool and have it do The Right Thing. We might be talking here about getting autopkgtest support (and consequentially continuous integration) for free for almost 2000 4000 packages. The missing bits for this to happen are:

• making debci use a whitelist of packages that, while not having the appropriate Testsuite: autopkgtest field in the Sources file, could be assumed to have autopkgtest support by calling the right tool (gem2deb-test-runner for Ruby, or the Perl team s new tool for Perl packages).
• make the autopkgtest test runner assume a corresponding, implicit, debian/tests/control when it not exists in those packages

During a few days I have mentored Lucas Kanashiro, who also attended DebConf, on writing a patch to add support for email notifications in debci so maintainers can be pro-actively notified of status changes (pass/fail, fail/pass) in their packages. I have also started hacking on the support for distributed workers, based on the initial work by Martin Pitt:

• updated the amqp branch against the code in the master branch.
• added a debci enqueue command that can be used to force test runs for packages given on the command line.
• I sent a patch for librabbitmq that adds support for limiting the number of messages the server will send to a connected client. With this patch applied, the debci workers were modified to request being sent only 1 message at a time, so late workers will start to receive packages to process as soon as they are up. Without this, a single connected worker would receive all messages right away, while a second worker that comes up 1 second later would sit idle until new packages are queued for testing.

Ruby I had some discusion with Christian about making Rubygems install to $HOME by default when the user is not root. We discussed a few implementation options, and while I don t have a solution yet, we have a better understanding of the potential pitfalls. The Ruby BoF session on Friday produced a few interesting discussions. Some take away point include, but are not limited to:

• Since the last DebConf, we were able to remove all obsolete Ruby interpreters, and now only have Ruby 2.1 in unstable. Ruby 2.1 will be the default version in Debian 8 (jessie).
• There is user interest is being able to run the interpreter from Debian, but install everything else from Rubygems.
• We are lacking in all the documentation-related goals for jessie that were proposed at the previous DebConf.

Redmine I was able to make Redmine work with the Rails 4 stack we currently have in unstable/testing. This required using a snapshot of the still unreleased version 3.0 based on the rails-4.1 branch in the upstream Subversion repository as source. I am a little nervous about using a upstream snapshot, though. According to the "roadmap of the project ":http://www.redmine.org/projects/redmine/roadmap the only purpose of the 3.0 release will be to upgrade to Rails 4, but before that happens there should be a 2.6.0 release that is also not released yet. 3.0 should be equivalent to that 2.6.0 version both feature-wise and, specially, bug-wise. The only problem is that we don t know what that 2.6.0 looks like yet. According to the roadmap it seems there is not much left in term of features for 2.6.0, though. The updated package is not in unstable yet, but will be soon. It needs more testing, and a good update to the documentation. Those interested in helping to test Redmine on jessie before the freeze please get in touch with me. Noosfero I gave a lighting talk on Noosfero, a platform for social networking websites I am upstream for. It is a Rails appplication licensed under the AGPLv3, and there are packages for wheezy. You can checkout the slides I used. Video recording is not available yet, but should be soon. That s it. I am looking forward to DebConf 15 at Heidelberg. :-)

Part 1 - Debconf 2014 This year I went to my first Debconf, which took place in Portland, OR during the last week of August 2014. All in all I have to rate my experience as very enlightening and in the end quite fun. First of all, it was a little daunting to go to a conference in 1 - A city I d never been to before; 2 - A conference with 300+ people, only 3 of which I knew and even then I only knew them virtually. Not to mention I was in the presence of some extremely brilliant and known contirbutors in the Debian community which was somewhat intimidating. Just to give you an idea, Linus Torvalds showed up for a Q&A session last Friday morning! Jealous? Actually I missed that too. It was kind of a last minute thing, booked for coincidentally the exact time I d be flying out of Portland. I found out about it much too late. But luckily for me and maybe you, the session was filmed and can be seen here. Isn t that a treat? Point made, there are lots of really talented people there, both techies and non-techies. It s easy to feel you re out of league, at least I did. But I d highly encourage you to ignore such feelings if you re ever in the same situation. Debian has been built on for a long time now, but although a lot has been done, a lot still needs to be done. The Debian community is very welcoming of new contributors and users, regardless of the level of expertise. So far I haven t been snubbed by anyone. To the contrary, all my interactions with the Debian community members has been extremely positive. So go ahead and attend the meetings and presentations, even if you think it s not your area of expertise. Debconf was organized (or at least this one was) as a series of talks, meet ups and ad hoc sessions, some of which occured simultaneously. The sessions were all about different components of the Debian universe, from presenting new features to overviews of accomplishments to discussing issues and how to fix them. A schedule with the location and description of each session was posted on the Debconf wiki. Sometimes none of the sessions at a certain time was on a topic I knew very much about. But I d sit in anyways. There s no rule to attending the sessions, no minimum qualifications required. You ll likely learn something new and you just might find out there is something you can do to contribute. There are also hackathons that are quite the thing or so I heard. Or you could walk about and meet new people, do some networking. I have to say networking was the highlight of the Debconf for me. Remember I said I knew about 3 people who were at the conference? Well, I had actually just corresponded with those people. I didn t really know them. So on my first day I spent quite some time shyly peeking at people s name tags, trying to recognize someone I had met over email or IRC. But with 300 or so people at the conference, I was unsuccessful. So I finally gave up on that strategy and walked up to a random person, stuck out my hand and said, Hi. My name is Juliana. This is my first Debconf. What s your name and what do you do for Debian? This may not be according to protocol, but it worked for me. I got to meet lots of people that way, met some Debian contributos from my home country (Brazil), some from my current city (NYC), and yet others that had similar interests as I do who I might work with in the near future. For example, I love Machine Learning, I m currently beginning my graduate studies on that track. Several Debian contributors offered to introduce me to a well known Machine Learning researcher and Debian contributor who is in NYC. Others had tried out JSCommunicator and had lots of suggestions for new features and fixes, or wanted to know more about the project and WebRTC in general. Also, not everyone there is a super experienced Debian contributor or user. There are a lot of newbies like me. I got to do a quick 20-min presentation and demo of the work I had done on JSCommunicator during GSoC 2014. Oh my goodness that was nerve-wracking, but not half as painful as I expected. My mentor (Daniel Pocock) wisely suggested that when confronted with a question I didn t know how to answer, to redirect the question to to the audience. Chances are, there is someone there that knows the answer. If not, it will at least spark a good discussion. When meeting new people at Debian, a question almost everyone asked is How did you start working with/for Debian? . So I thought it would be a good topic to post about. Part 2 - How I Became a Debian Contributor Sometime in late October of 2013 (I think) I received an email from one of my professors at UNIRIO forwarding a description of the Outreach Program for Women. OPW is a program organized by the GNOME which endeavors to get more women involved in FOSS. OPW is similar to Google Summer of Code; you work remotely from home, guided by an assigned mentor. Debian was one of the 8 participating organizations that year. There was a list of project proposals which I perused, a few of them caught my eye and these projects were all Debian. I d already been a fan of FOSS before. I had used the Ubuntu and Debian OS, I d migrated to GIMP from Photoshop and to Open Office from Microsoft Office, for example. I d strongly advocated the use of some of my prefered open source apps and programs to my friends and family. But I hadn t ever contributed to a FOSS project. There s no time like the present, so I reached out the the mentor responsible for one of the projects I was interested in, Daniel Pocock. Daniel guided me through making a small contribution to a FOSS project, which serves as a token demonstration of my abilities and is part of the application process. I added a small feature to JMXetric and suggested a fix for an issue in the xTuple project. Actually, I had forgotten about this. Recently I made another contribution to xTuple, it s funny to see things come full circle. I also had to write a profile-ish description of my experience and how I intended on contributing during OPW on the Debian wiki, if you d like you can check it out here. I wouldn t follow my example to a T, because in the end I didn t make the OPW selection. Actually, I take that back. The fact I wasn t chosen for OPW that year doesn t mean I was incompetent or incapable of making a valuable contribution. OPW and GSoC do not have unlimited resources; they can t include everyone they d like to. They receive thousands of proposals from very talented engineers and not everyone can participate at a given moment. But even though I wasn t selected, like I said, I could still pitch in. It s good to keep in mind that people usually aren t paid to contribute to FOSS. It s usually volunteer based, which I think is one of the beauties of the FOSS community and in my opinion one of the causes of it s success and great quality. People contribute because they want to, not because they have to. I will say I was a little disappointed at not being chosen. But after being reassured that this rejection wasn t due to any lack on my part, I decided to continue contributing to the Debian project I d applied to. I was begining the final semester of my undergraduate studies which included writing a thesis. To be able to focus on my thesis and graduate on time, I d stopped working temporarily and was studying full time. But I didn t want to lose practice and contributing to a FOSS project is a great way to stay in coding shape while doing something useful. So continue contributing I did. It paid off. I gained experience, added value to a FOSS project and I think my previous contributions added weight to the application I later made for GSoC 2014. I passed this time. To be honest, I really wasn t counting on it. Actually, I was certain I wouldn t pass for some reason - insecure much? But with GSoC I wasn t too anxious about it as I was with the OPW application because by then, I was already hooked . I d learned about all the benefits of becoming a FOSS contributor and I wasn t stopping anytime soon. I had every intention of still working on my FOSS project with or without GSoC. GSoC 2014 ended a week ago (August 18th 2014). There s a list of things I still want to do with JSCommunicator and you can be sure I ll keep working on them. P.S. This is not to say that programs like OPW and GSoC aren t amazing programs. Try it out if you can, it s really a great experience.

= 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,

AddThis:

Categories:

• Debian-Blog
• Tools

Keywords:

• apt-offline
• Offline APT Package Manager
• offline package manager

Matt Palmer wrote a good overview of DNSSEC [1]. Sociological Images has an interesting article making the case for phasing out the US $0.01 coin [2]. The Australian $0.01 and $0.02 coins were worth much more when they were phased out. Multiplicity is a board game that s designed to address some of the failings of SimCity type games [3]. I haven t played it yet but the page describing it is interesting. Carlos Buento s article about the Mirrortocracy has some interesting insights into the flawed hiring culture of Silicon Valley [4]. Adam Bryant wrote an interesting article for NY Times about Google s experiments with big data and hiring [5]. Among other things it seems that grades and test results have no correlation with job performance. Jennifer Chesters from the University of Canberra wrote an insightful article about the results of Australian private schools [6]. Her research indicates that kids who go to private schools are more likely to complete year 12 and university but they don t end up earning more. Kiwix is an offline Wikipedia reader for Android, needs 9.5G of storage space for the database [7]. Melanie Poole wrote an informative article for Mamamia about the evil World Congress of Families and their connections to the Australian government [8]. The BBC has a great interactive web site about how big space is [9]. The Raspberry Pi Spy has an interesting article about automating Minecraft with Python [10]. Wired has an interesting article about the Bittorrent Sync platform for distributing encrypted data [11]. It s apparently like Dropbox but encrypted and decentralised. Also it supports applications on top of it which can offer social networking functions among other things. ABC news has an interesting article about the failure to diagnose girls with Autism [12]. The AbbottsLies.com.au site catalogs the lies of Tony Abbott [13]. There s a lot of work in keeping up with that. Racialicious.com has an interesting article about Moff s Law about discussion of media in which someone says why do you have to analyze it [14]. Paul Rosenberg wrote an insightful article about conservative racism in the US, it s a must-read [15]. Salon has an interesting and amusing article about a photography project where 100 people were tased by their loved ones [16]. Watch the videos.

• [1] http://www.hezmatt.org/~mpalmer/blog/2014/06/29/adventures-in-dnssec.html
• [2] http://thesocietypages.org/socimages/2012/05/05/a-case-against-the-penny/
• [3] http://www.molleindustria.org/blog/multiplicity/
• [4] http://carlos.bueno.org/2014/06/mirrortocracy.html
• [5] http://tinyurl.com/mrxjuff
• [6] http://tinyurl.com/k6abj26
• [7] https://play.google.com/store/apps/details?id=org.kiwix.kiwixmobile
• [8] http://www.mamamia.com.au/news/world-congress-of-families-conference/
• [9] http://tinyurl.com/n7sczw4
• [10] http://tinyurl.com/k3k36sq
• [11] http://tinyurl.com/k3k36sq
• [12] http://tinyurl.com/l42mckp
• [13] http://www.abbottslies.com.au/
• [14] http://www.racialicious.com/2009/12/21/and-we-shall-call-this-moffs-law/
• [15] http://tinyurl.com/karyryk
• [16] http://tinyurl.com/puydo94

After an intensive evening of brainstorming by the 5th floor cabal, I am happy to release the very first version of the Debian Trivia, modeled after the famous TCP/IP Drinking Game. Only the questions are listed here maybe they should go (with the answers) into a package? Anyone willing to co-maintain? Any suggestions for additional questions?

• what was the first release with an and-a-half release?
• Where were the first two DebConf held?
• what are Debian releases named after? Why?
• Give two names of girls that were originally part of the Debian Archive Kit (dak), that are still actively used today.
• Swirl on chin. Does it ring a bell?
• What was Dunc Tank about? Who was the DPL at the time? Who were the release managers during Dunc Tank?
• Cite 5 different valid values for a package s urgency field. Are all of them different?
• When was the Debian Maintainers status created?
• What is the codename for experimental?
• Order correctly lenny, woody, etch, sarge
• Which one was the Dunc Tank release?
• Name three locations where Debian machines are hosted.
• What does the B in projectb stand for?
• What is the official card game at DebConf?
• Describe the Debian restricted use logo.
• One Debian release was frozen for more than a year. Which one?
• name the kernel version for sarge, etch, lenny, squeeze, wheezy. bonus for etch-n-half!
• What happened to Debian 1.0?
• Which DebConfs were held in a Nordic country?
• What does piuparts stand for?
• Name the first Debian release.
• Order correctly hamm, bo, potato, slink
• What are most Debian project machines named after?

Modern web applications are much more complicated than the simple Perl CGI scripts or PHP pages of the past. They usually start with a framework and include lots of external components both on the front-end and on the back-end. Here's an example from the Node.js back-end of a real application:

$ npm list   wc -l
256

What if one of these 256 external components has a security vulnerability? How would you know and what would you do if of your direct dependencies had a hard-coded dependency on the vulnerable version? It's a real problem and of course one way to avoid this is to write everything yourself. But that's neither realistic nor desirable. However, it's not a new problem. It was solved years ago by Linux distributions for C and C++ applications. For some reason though, this learning has not propagated to the web where the standard approach seems to be to "statically link everything". What if we could build on the work done by Debian maintainers and the security team?

Case study - the Libravatar project As a way of discussing a different approach to the problem of dependency management in web applications, let me describe the decisions made by the Libravatar project.

Description Libravatar is a federated and free software alternative to the Gravatar profile photo hosting site. From a developer point of view, it's a fairly simple stack:

• Apache
• Postgres
• Django
• Python
• Gearman

The service is split between the master node, where you create an account and upload your avatar, and a few mirrors, which serve the photos to third-party sites. Like with Gravatar, sites wanting to display images don't have to worry about a complicated protocol. In a nutshell, all that a site needs to do is hash the user's email and add that hash to a base URL. Where the federation kicks in is that every email domain is able to specify a different base URL via an SRV record in DNS. For example, francois@debian.org hashes to 7cc352a2907216992f0f16d2af50b070 and so the full URL is:

http://cdn.libravatar.org/avatar/7cc352a2907216992f0f16d2af50b070

whereas francois@fmarier.org hashes to 0110e86fdb31486c22dd381326d99de9 and the full URL is:

http://fmarier.org/avatar/0110e86fdb31486c22dd381326d99de9

due to the presence of an SRV record on fmarier.org.

Ground rules The main rules that the project follows is to:

1. only use Python libraries that are in Debian
2. use the versions present in the latest stable release (including backports)

Deployment using packages In addition to these rules around dependencies, we decided to treat the application as if it were going to be uploaded to Debian:

• It includes an "upstream" Makefile which minifies CSS and JavaScript, gzips them, and compiles PO files (i.e. a "build" step).
• The Makefile includes a test target which runs the unit tests and some lint checks (pylint, pyflakes and pep8).
• Debian packages are produced to encode the dependencies in the standard way as well as to run various setup commands in maintainer scripts and install cron jobs.
• The project runs its own package repository using reprepro to easily distribute these custom packages.
• In order to update the repository and the packages installed on servers that we control, we use fabric, which is basically a fancy way to run commands over ssh.
• Mirrors can simply add our repository to their apt sources.list and upgrade Libravatar packages at the same time as their system packages.

Results Overall, this approach has been quite successful and Libravatar has been a very low-maintenance service to run. The ground rules have however limited our choice of libraries. For example, to talk to our queuing system, we had to use the raw Python bindings to the C Gearman library instead of being able to use a nice pythonic library which wasn't in Debian squeeze at the time. There is of course always the possibility of packaging a missing library for Debian and maintaining a backport of it until the next Debian release. This wouldn't be a lot of work considering the fact that responsible bundling of a library would normally force you to follow its releases closely and keep any dependencies up to date, so you may as well share the result of that effort. But in the end, it turns out that there is a lot of Python stuff already in Debian and we haven't had to package anything new yet. Another thing that was somewhat scary, due to the number of packages that were going to get bumped to a new major version, was the upgrade from squeeze to wheezy. It turned out however that it was surprisingly easy to upgrade to wheezy's version of Django, Apache and Postgres. It may be a problem next time, but all that means is that you have to set a day aside every 2 years to bring everything up to date.

Problems The main problem we ran into is that we optimized for sysadmins and unfortunately made it harder for new developers to setup their environment. That's not very good from the point of view of welcoming new contributors as there is quite a bit of friction in preparing and testing your first patch. That's why we're looking at encoding our setup instructions into a Vagrant script so that new contributors can get started quickly. Another problem we faced is that because we use the Debian version of jQuery and minify our own JavaScript files in the build step of the Makefile, we were affected by the removal from that package of the minified version of jQuery. In our setup, there is no way to minify JavaScript files that are provided by other packages and so the only way to fix this would be to fork the package in our repository or (preferably) to work with the Debian maintainer and get it fixed globally in Debian. One thing worth noting is that while the Django project is very good at issuing backwards-compatible fixes for security issues, sometimes there is no way around disabling broken features. In practice, this means that we cannot run unattended-upgrades on our main server in case something breaks. Instead, we make use of apticron to automatically receive email reminders for any outstanding package updates. On that topic, it can occasionally take a while for security updates to be released in Debian, but this usually falls into one of two cases:

1. You either notice because you're already tracking releases pretty well and therefore could help Debian with backporting of fixes and/or testing;
2. or you don't notice because it has slipped through the cracks or there simply are too many potential things to keep track of, in which case the fact that it eventually gets fixed without your intervention is a huge improvement.

Finally, relying too much on Debian packaging does prevent Fedora users (a project that also makes use of Libravatar) from easily contributing mirrors. Though if we had a concrete offer, we would certainly look into creating the appropriate RPMs.

Is it realistic? It turns out that I'm not the only one who thought about this approach, which has been named "debops". The same day that my talk was announced on the DebConf website, someone emailed me saying that he had instituted the exact same rules at his company, which operates a large Django-based web application in the US and Russia. It was pretty impressive to read about a real business coming to the same conclusions and using the same approach (i.e. system libraries, deployment packages) as Libravatar. Regardless of this though, I think there is a class of applications that are particularly well-suited for the approach we've just described. If a web application is not your full-time job and you want to minimize the amount of work required to keep it running, then it's a good investment to restrict your options and leverage the work of the Debian community to simplify your maintenance burden. The second criterion I would look at is framework maturity. Given the 2-3 year release cycle of stable distributions, this approach is more likely to work with a mature framework like Django. After all, you probably wouldn't compile Apache from source, but until recently building Node.js from source was the preferred option as it was changing so quickly. While it goes against conventional wisdom, relying on system libraries is a sustainable approach you should at least consider in your next project. After all, there is a real cost in bundling and keeping up with external dependencies. This blog post is based on a talk I gave at DebConf 14: slides, video.