Last week s autopkgtest 3.5 release (in Debian sid and Ubuntu Utopic) brings several new features which I d like to announce. Tests that reboot For testing low-level packages like init or the kernel it is sometimes desirable to reboot the testbed in the middle of a test. For example, I added a new boot_and_services systemd autopkgtest which configures grub to boot with systemd as pid 1, reboots, and then checks that the most important services like lightdm, D-BUS, NetworkManager, and cron come up as expected. (This test will be expanded a lot in the future to cover other areas like the journal, logind, etc.) In a testbed which supports rebooting (currently only QEMU) your test will now find an autopkgtest-reboot command which the test calls with an arbitrary marker string. autopkgtest will then reboot the testbed, save/restore any files it needs to (like the tests file tree or previously created artifacts), and then re-run the test with ADT_REBOOT_MARK=mymarker. The new Reboot during a test section in README.package-tests explains this in detail with an example. Implicit test metadata for similar packages The Debian pkg-perl team recently discussed how to add package tests to the ~ 3.000 Perl packages. For most of these the test metadata looks pretty much the same, so they created a new pkg-perl-autopkgtest package which centralizes the logic. autopkgtest 3.5 now supports an implicit debian/tests/control control file to avoid having to modify several thousand packages with exactly the same file. An initial run already looked quite promising, 65% of the packages pass their tests. There will be a few iterations to identify common failures and fix those in pkg-perl-autopkgtest and autopkgtestitself now. There is still some discussion about how implicit test control files go together with the DEP-8 specification, as other runners like sadt do not support them yet. Most probably we ll declare those packages XS-Testsuite: autopkgtest-pkg-perl instead of the usual autopkgtest. In the same vein, Debian s Ruby maintainer (Antonio Terceiro) added implicit test control support for Ruby packages. We haven t done a mass test run with those yet, but their structure will probably look very similar.

Happy to be back from our yearly hike with my friend, Ryan Neily, on the Bluff Wilderness Trail. We re proud of our achievement, hiking all four loops. Including the trip to and from the head of the trail, that was 30 km in all. Exhausting, but well worth it. On the trip we bumped into one of the people from WRWEO who helps to maintain the trail, and stopped for a bit to talk to swap stories and tips about hiking the trail. Kudos to Nancy for helping keep this trail beautiful and accessible. We really appreciate the tireless work of this organization, and the thought they ve put into it. It s a treasure!

AltOS 1.5 EasyMega support, features and bug fixes Bdale and I are pleased to announce the release of AltOS version 1.5. AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software. This is a major release of AltOS, including support for our new EasyMega board and a host of new features and bug fixes AltOS Firmware EasyMega added, new features and fixes Our new flight computer, EasyMega, is a TeleMega without any radios:

• 9 DoF IMU (3 axis accelerometer, 3 axis gyroscope, 3 axis compass).
• Orientation tracking using the gyroscopes (and quaternions, which are lots of fun!)
• Four fully-programmable pyro channels, in addition to the usual apogee and main channels.

AltOS Changes We've made a few improvements in the firmware:

• The APRS secondary station identifier (SSID) is now configurable by the user. By default, it is set to the last digit of the serial number.
• Continuity of the four programmable pyro channels on EasyMega and TeleMega is now indicated via the beeper. Four tones are sent out after the continuity indication for the apogee and main channels with high tones indicating continuity and low tones indicating an open circuit.
• Configurable telemetry data rates. You can now select among 38400 (the previous value, and still the default), 9600 or 2400 bps. To take advantage of this, you'll need to reflash your TeleDongle or TeleBT.

AltOS Bug Fixes We also fixed a few bugs in the firmware:

• TeleGPS had separate flight logs, one for each time the unit was turned on. Turning the unit on to test stuff and turning it back off would consume one of the flight log 'slots' on the board; once all of the slots were full, no further logging would take place. Now, TeleGPS appends new data to an existing single log.
• Increase the maximum computed altitude from 32767m to 2147483647m. Back when TeleMetrum v1.0 was designed, we never dreamed we'd be flying to 100k' or more. Now that's surprisingly common, and so we've increased the size of the altitude data values to fit modern rocketry needs.
• Continuously evaluate pyro firing condition during delay period. The previous firmware would evaluate the pyro firing requirements, and once met, would delay by the indicated amount and then fire the channel. If the conditions had changed state, the channel would still fire. Now, the conditions are continuously evaluated during the delay period and if they change state, the event is suppressed.
• Allow negative values in the pyro configuration. Now you can select a negative speed to indicate a descent rate or a negative acceleration value to indicate acceleration towards the ground.

AltosUI and TeleGPS EasyMega support, OS integration and more The AltosUI and TeleGPS applications have a few changes for this release:

• EasyMega support. That was a simple matter of adapting the existing TeleMega support.
• Added icons for our file types, and hooked up the file manager so that AltosUI, TeleGPS and/or MicroPeak are used to view any of our data files.
• Configuration support for APRS SSIDs, and telemetry data rates.

I previously forgot to mention that I was planning to attend DebConf14, having missed DebConf13. This year the conference was held in Portland, OR. This is a city I've been to many times before, and enjoy, but I hadn't spent any time wandering around its city centre as a pedestrian. I have to say I really prefer DebConfs that are held in middle of city. It always seems a bit of a shame to travel some distance to somewhere new and spend all the time there in a conference venue. Plus these days I have the added lure of going out and playing Ingress in a new location. DebConf14 didn't disappoint in these respects; the location was super easy to get to from the airport via public transportation, all of the evening social events were within reasonable walking distance (I'll tend to default to walking when possible) and the talk venue/accommodation were close to each other and various eating + drinking options. Throw in the fact at Portland managed to produce some excellent weather (modulo my Ingress session on the last Saturday morning, when rained on me) and it's impossible to fault the physicalities of DebConf this year. This year the conference format was a bit different; previous years have had a week long DebConf before the week of the conference itself. This year went for a 9 day talk schedule (Saturday -> Sunday) with various gaps of hacking time interspersed. I've found it hard to justify a full two weeks away in the past, so this setup worked a lot better from my viewpoint. Also I rarely go to DebConf with a predetermined list of things to do; the stuff I work on naturally falls out of talks I attend and informal discussions I have. Having hack time throughout the conference helped me avoid feeling I was having to trade off hacking vs talks. Naturally enough a lot of my involvement at DebConf was around OpenPGP. Gunnar and I spent a fair bit of time getting Daniel up to speed with the keyring-maint team (Gunnar more than I, I'll confess). We finally set a hard timeframe for freeing Debian of older 1024 bit keys. I was introduced to the Gnuk, which is a particularly interesting piece of open specification hardware with a completely Free software stack on top if it that implements the OpenPGP smartcard spec. Currently it's limited to 2K keys but it's hoped that 4K support can be added (and I ended up spending a couple of hours after the closing talk hacking on the source and seeing how much needs to change for 4K support, aided by the very patient Niibe). These are the sort of things that really benefit from the face time that DebConf offers to the Debian project. I've said it before, but I think it's worth saying again: Debian is a bit like a huge telecommuting organization and it's my opinion that any such organization should try and ensure its members actually spend some time together on a regular basis. It improves the ability to work remotely a hell of a lot if you can actually put a face to the entity you're emailing / IRCing and have some sort of idea where they're coming from because you've spent some time with them, whether that's in talks or over dinner or just casual hallway chats. For once I also found myself considering alternative employment while at DebConf and it was incredibly useful to be able to have various conversations with both old friends and people who were there with an eye on recruitment. Thanks to all those whose ears I bent about the subject (and more on the outcome in a future post). Thank you also to the many people involved with the organization of DebConf; I've been on the periphery a few times over the years and it's given me a glimpse into the amount of hard work all of the volunteers (be they global team, local organizing team, video team or just random volunteers) put into making DebConf one of my must-attend yearly conferences. If you're at all involved in Debian and haven't attended I strongly urge you to do so - I'll see you all next year at DebConf15 in Heidelberg!

I am sick of hearing apologies directed to me just after a dirty joke.

Usually, I don't mind dirty jokes in themselves: I *do* have a dirty mind and make my share of those, or laugh for the ones my friends with even dirtier minds make.

There are of course times and places where they aren't appropriate, but I'd rather live in a world where they are the exception (although a common one) rather than the norm.

Then there is the kind of dirty jokes strongly based on the assumptions that women are sexual objects, a nuisance that must be tolerated because of sex or both: of course I don't really find them fun, but that's probably because I'm a nuisance and I don't even give them reason to tolerate me. :)

Even worse that those, however, is being singled out as the only women in the group with an empty apology for the joke (often of the latter kind): I know you are not really sorry, you probably only want to show that your parents taught you not to speak that way in front of women, but since I'm intruding in a male-only group I have to accept that you are going to talk as appropriate for it.

P.S. no, the episode that triggered this post didn't happen in a Debian environment, it happened in Italy, in a tech-related environment (and not in a wanking club for penis owners, where they would have every right to consider me an intruder).

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.

Clang 3.5.0 has just been released. A new rebuild has been done highlight the progress to get Debian built with clang. tl;dr: Great progress. We decreased from 9.5% to 5.7% of failures. Full results are available on http://clang.debian.net At time of the rebuild with 3.4.2, we had 2040 packages failing to build with clang. With 3.5.0, this dropped to 1261 packages. Fixes With Arthur Marble and Alexander Ovchinnikov, both GSoC students, we worked on various ways to decrease the number of errors. Upstream fixes First, the most obvious way, we fixed programming bugs/mistakes in upstream sources. Basically, we took categories of failure and fixed issues one after the other. We started with simple bugs like 'Wrong main declaration', 'non-void function should return a value' or 'Void function should not return a value'.

They are trivial to fix. We continued with harder fixes like ' Undefined reference' or 'Variable length array for a non POD (plain old data) element'.

So, besides these one, we worked on:

• No support of nested C function
• Wrong C++ default declaration in a method
• Variable length array for a non POD (plain old data) element
• Tautological comparison
• Conflicting types
• Changes of default constructor
• Potential usage of an uninitialized variable
• Use of old GNU field designator
• Missing symbols at link time (inline in C99)
• and others

In total, we reported 295 bugs with patches. 85 of them have been fixed (meaning that the Debian maintainer uploaded a new version with the fix).

In parallel, I think that the switch by FreeBSD and Mac OS X to Clang also helped to fix various issues by upstreams. Hacking in clang As a parallel approach, we started to implement a suggestion from Linus Torvalds and a few others. Instead of trying to fix all upstream, where we can, we tried to update clang to improve the gcc compatibility.

gcc has many flags to disable or enable optimizations. Some of them are legacy, others have no sense in clang, etc. Instead of failing in clang with an error, we create a new category of warnings (showing optimization flag '%0' is not supported) and moved all relevant flags into it. Some examples, r212805, r213365, r214906 or r214907

We also updated clang to silent some useless arguments like -finput_charset=UTF-8 (r212110), clang being UTF-8 compliant.

Finally, we worked on the forwarding of linker flags. Clang and gcc have a very different behavior: when gcc does not know an argument, it is going to forward the argument to the linker. Clang, in this case, is going to reject the argument and fail with an error. In clang, we have to explicitly declare which arguments are going to be transfer to the linker. Of course, the correct way to pass arguments to the linker is to use -Xlinker or -Wl but the Debian rebuild proved that these shortcuts are used. Two of these arguments are now forwarded:

• -z keyword - r213198
• -u Force symbol to be entered in the output file as an undefined symbol - r211756. This one fixed most of the haskell build failures. It fixed the most common issue that we had (701 occurrences but this does not mean that all these packages build fine now, some haskell-based package are failing later in the process)

New errors Just like in other releases, new warnings are added in clang. With (bad) usage of -Werror by upstream software, this causes new build failures:

• Absolute value error - 6 occurences
• Tautological pointer comparison - 10 occurences

I also took the opportunity to add some further categorizations in the list of errors. Some examples:

• Header guard failure
• Unknown/unexpected directive
• Object is not a function or function pointer

Next steps The Debile project being close to ready with Cl ment Schreiner's GSoC, we will now have an automatic and transparent way to rebuild packages using clang. Conclusion As stated, we can see a huge drop in term of number of failures over time: Hopefully, Clang getting better and better, more and more projects adopting it as the default compiler or as a base for plugin/extension developments, this percentage will continue to decrease.
Having some kind of release goal with clang for Jessie+1 can now be considered as potentially reachable. Want to help? There are several things which can be done to help:

• Point me common error patterns in the Not categorized list of errors to create new categories
• Report and fix packages
• As an upstream, integrate clang as part of your continuous integration system
• Hack on cqa-scanlogs, the error detection tool to detect error patterns (example: Undetected error). This tool is used also for the regular rebuilds of the archive.
• Improve clang.debian.net website

Acknowledgments Thanks to David Suarez for the rebuilds of the archive, Arthur Marble and Alexander Ovchinnikov for their GSoC works and Nicolas S velin-Radiguet for the few fixes.

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).

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:

• Thorsten Alteholz: July / August
• Holger Levsen: July / August

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:

1. Paid contributors already handle almost 70% of the updates. Counting only on volunteers would not have worked.
2. 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:

• Gold sponsors:
  • The Positive Internet
• Silver sponsors:
  • AD&D David Ayers IntarS Austria
  • Blablacar
  • Domeneshop AS
  • Evolix
  • Universit Lille 3
• Bronze sponsors:
  • Freeside Internet Service
  • MyTux
  • Offensive Security
  • Seznam.cz, a.s.

Hopefully this list will expand over time! Any help to reach out to new companies and organizations is more than welcome.

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

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.

For weeks my Galaxy Tab 10.1 has reasonably consistently gone into safe mode. Not booting into it but I d use it fine then put it away and next time I looked at it, Safe Mode was there. It wasn t every time, but averaged to be about every second time. So the first thing was a bit of googling to see what this Safe Mode was. Most of the suggestions were around how to put it into safe mode during the boot process but my problem was opposite; it wasn t during booting and I wanted something to stop safe mode, not put the device into it. The closest I got to it was there was some misbehaving program that kicked the thing into safe mode. The problem was, I checked several times and there were no running programs. I really did start to worry I had a hardware fault or something wrong deep within the OS. When you have problems in IT, you re usually asked What s new? What s changed? . The answer is generally Nothing which gets a switch No really, what did change . The only answer I could come up with was a hardware keyboard. This slim aluminum uses bluetooth to communicate to the tablet and clips onto the front screen to protect it when not in use. Could this be the change I was looking for? The clue was that sometimes when you boot Android, if you hold down some keys it boots into safemode. It seems that holding down some combination of keys (volume up/down, power) puts into safe mode. The keyboard can clip onto the tablet in two ways, one long edge has some raised edges while one doesn t. If the raised edge was connected to the same side as the buttons, I d get safe mode sometimes as the edge pushed some of those buttons. More importantly, putting the raised edge on the side with no buttons meant no more safe mode. Not really a software or electrical fault, more one of just mechanics.

Another on-my-the-journey-back blog post; this time from the Frankfurt Airport Train Station my flight was delayed (if I knew that I could have watched the remaining Lightning Talks), and so was my train, but despite 5min of running through the Airport just not enough. And now that the free 30 Minutes of Railway Station Internet are used up, I have nothing else to do but blog... Last week I was attending ICFP 2014 in Gothenburg, followed by the Haskell Symposium and the Haskell Implementors Workshop. The justification to attend was the paper on Safe Coercions (joint work with Richard Eisenberg, Simon Peyton Jones and Stephanie Weirich), although Richard got to hold the talk, and did so quite well. So I got to leisurely attend the talks, while fighting the jet-lag that I brought from Portland. There were as expected quite a few interesting talks. Among them the first keynote, Kathleen Fisher on the need for formal methods in cars and toy-quadcopters and unmanned battle helicopters, which made me conclude that my Isabelle skills might eventually become relevant in practical applications. And did you know that if someone gains access to your car s electronics, they can make the seat belt pull you back hard? Stefanie Weirich s keynote (and the subsequent related talks by Jan Stolarek and Richard Eisenberg) on what a dependently typed Haskell would look like and what we could use it for was mouth-watering. I am a bit worried that Haskell will be become a bit obscure for newcomers and people that simply don t want to think about types too much, on the other hand it seems that Haskell as we know it will always stay there, just as a subset of the language. Similarly interesting were refinement types for Haskell (talks by Niki Vazou and by Eric Seidel), in the form of LiquidTypes, something that I have not paid attention to yet. It seems to be a good way for more high assurance in Haskell code. Finally, the Haskell Implementors Workshop had a truckload of exciting developments in and around Haskell: More on GHCJS, Partial type signatures, interactive type-driven development like we know it from Agda, the new Haskell module system and amazing user-defined error messages the latter unfortunately only in Helium, at least for now. But it s not the case that I only sat and listened. During the Haskell Implementors Workshop I held a talk Contributing to GHC with a live demo of me fixing a (tiny) bug in GHC, with the aim of getting more people to hack on GHC (slides, video). The main message here is that it is not that big of deal. And despite me not actually saying much interesting in the talk, I got good feedback afterwards. So if it now actually motivates someone to contribute to GHC, I m even more happier. And then there is of course the Hallway Track. I discussed the issues with fusing a left fold (unfortunately, without a great solution). In order to tackle this problem more systematically, John Wiegley and I created the beginning of a List Fusion Lab , i.e. a bunch of list benchmark and the possibility to compare various implementations (e.g. with different RULES) and various compilers. With that we can hopefully better assess the effect of a change to the list functions. PS: The next train is now also delayed, so I ll likely miss my tram and arrive home even later... PPS: I really have to update my 10 year old picture on my homepage (or redesign it completely). Quite a few people knew my name, but expected someone with shoulder-long hair... PPPS: Haskell is really becoming mainstream: I just talked to a randomly chosen person (the boy sitting next to me in the train), and he is a Haskell enthusiast, building a structured editor for Haskell together with his brother. And all that as a 12th-grader...

Before I start a short listing of (some of) the stuff I did during Debconf 14, I d like to say how much I enjoyed everyone there. You guys (all of you, really!) are just awesome, and it s always a real pleasure to see you all, each time. Anyway, here s a bits of the stuff I did. 1/ packaging of Google Cloud Engine client tools. Thanks to the presence of Eric and Jimmy, I was able to finish the work I started at Debconf 13 last year. All python modules are packaged and uploaded. Only the final client (the gcloud command line utility) isn t uploaded, even though it s already packaged. The reason is that this client downloads stuff from internet, so I need to get the full, bundled, version of it, to avoid this. Eric gave me the link, I just didn t have time to finish it yet. Though the (unfinished) package is already in the Git in Alioth. 2/ Tasksel talks We discussed improvements in Tasksel both during the conference, and later (in front of beers ). I was able to add a custom task on a modified version of the Tasksel package for my own use. I volunteered myself for adding a more task option in Tasksel for Jessie+1 because I really would like to see this feature, and nobody raised hand, but honestly, I have no idea how to do it, and therefore, I m not sure I ll be able to do so. We ll see Anyway, before this happen, we must make sure that we know what kind of tasks we want in this more tasks screen, otherwise it d be useless work for nothing. Therefore, I have setup a wiki page. Please edit the page and drop your ideas there. I ve already added entries for desktops and Debian blends, but I m sure there s more that we could add. 3/ Custom Debian CD I started experimentation on building my own Debian Wheezy CD image (well, DVD, since the resulting image is nearly 2GB). This was fun, but I am still having the issue that the installer fails to install Dash, so the CD is still unusable. I ll try to debug it. Oh I nearly forgot of course , the ISO image aims at including all OpenStack Icehouce packages backported to Wheezy, and the goal was to include the above custom Tasksel task, with an OpenStack proxy node task, and a OpenStack compute task. Let s hope I can figure out what the issue is, and finally release it. 4/ OpenStack talk Nothing special to say, just watch the video. I hope my talk was interesting enough. Of course, after watching myself, I hate everything I see, and would like to correct so many mistakes, but that s the usual, I guess. 5/ Some RC fixing Thanks to the nice work of our DPL rebuilding all the archive, I had to fix a couple of FTBFS issues on my own packages. 3 of them have been easy to fix (2 missing build-dependencies which I missed because my automated build environment has them by default, and a unit test failure), I still don t understand what s going on with Ceilometer. I also NMU-ed transmission (switching from 2.82 to 2.84, as upstream had the bugfix, and current maintainer was not responsive) which was the last blocker for the miniupnpc transition to Jessie. After the 5 days delay of the upload, it went in Sid, then migrated to Jessie, together with the miniupnpc library. I also fixed a trivial RC bug with python3-webob. 6/ Python team meeting It was nice to see everyone, and hopefully, we ll soon implement what we discussed. I hope to start migrating some of my OpenStack dependencies to the team once we move to Git (though please don t expect this to happen before the Juno release, which keeps me very busy these days). There s probably more stuff which I did during Debconf 14 (hacking or otherwise), but either it s not worth sharing, or I can t remember :)

I haven't made one of these in a long time, so I have some catching from random purchases to do, which includes a (repurposed) nice parting gift from my previous employer and a trip to Powell's since I was in the area for DebConf14. This also includes the contents of the Hugo voter's packet, which contained a wide variety of random stuff even if some of the novels were represented only by excerpts. John Joseph Adams (ed.) The Mad Scientist's Guide to World Domination (sff anthology)
Roger McBride Allen The Ring of Charon (sff)
Roger McBride Allen The Shattered Sphere (sff)
Iain M. Banks The Hydrogen Sonata (sff)
Julian Barnes The Sense of an Ending (mainstream)
M. David Blake (ed.) 2014 Campbellian Anthology (sff anthology)
Algis Budrys Benchmarks Continued (non-fiction)
Algis Budrys Benchmarks Revisited (non-fiction)
Algis Budrys Benchmarks Concluded (non-fiction)
Edgar Rice Burroughs Carson of Venus (sff)
Wesley Chu The Lives of Tao (sff)
Ernest Cline Ready Player One (sff)
Larry Correia Hard Magic (sff)
Larry Correia Spellbound (sff)
Larry Correia Warbound (sff)
Sigrid Ellis & Michael Damien Thomas (ed.) Queer Chicks Dig Time Lords (non-fiction)
Neil Gaiman The Ocean at the End of the Lane (sff)
Max Gladstone Three Parts Dead (sff)
Max Gladstone Two Serpents Rise (sff)
S.L. Huang Zero Sum Game (sff)
Robert Jordan & Brandon Sanderson The Wheel of Time (sff)
Drew Karpyshyn Mass Effect: Revelation (sff)
Justin Landon & Jared Shurin (ed.) Speculative Fiction 2012 (non-fiction)
John J. Lumpkin Through Struggle, the Stars (sff)
L. David Marquet Turn the Ship Around! (non-fiction)
George R.R. Martin & Raya Golden Meathouse Man (graphic novel)
Ramez Naam Nexus (sff)
Eiichiro Oda One Piece Volume 1 (manga)
Eiichiro Oda One Piece Volume 2 (manga)
Eiichiro Oda One Piece Volume 3 (manga)
Eiichiro Oda One Piece Volume 4 (manga)
Alexei Panshin New Celebrations (sff)
K.J. Parker Devices and Desires (sff)
K.J. Parker Evil for Evil (sff)
Sofia Samatar A Stranger in Olondria (sff)
John Scalzi The Human Division (sff)
Jonathan Straham (ed.) Fearsome Journeys (sff anthology)
Vernor Vinge The Children of the Sky (sff)
Brian Wood & Becky Cloonan Demo (graphic novel)
Charles Yu How to Live Safely in a Science Fictional Universe (sff) A whole bunch of this is from the Hugo voter's packet, and since the Hugos are over, much of that probably won't get prioritized. (I was very happy with the results of the voting, though.) Other than that, it's a very random collection of stuff, including a few things that I picked up based on James Nicoll's reviews. Now that I have a daily train commute, I should pick up the pace of reading, and as long as I can find enough time in my schedule to also write reviews, hopefully there will be more content in this blog shortly.

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.

I wanted to file a bug but Debian BTS doesn't seem to receive my SMTP mail for some reason. Somewhere between the MTA and the server something is wrong.

In i18nspector I try to support all the encodings that were blessed by gettext, but it turns out to be more difficult than I anticipated:

$ roundtrip()   c=$(echo $1   iconv -t $2); printf '%s -> %s -> %s\n' $1 $c $(echo $c   iconv -f "$2");  
$ roundtrip   EUC-JP
  -> \ -> \
$ roundtrip   SHIFT_JIS
  -> \ ->  
$ roundtrip   JOHAB
  -> \ ->  

Now let's do the same in Python:

$ python3 -q
>>> roundtrip = lambda s, e: print('%s -> %s -> %s' % (s, s.encode(e).decode('ASCII', 'replace'), s.encode(e).decode(e)))
>>> roundtrip(' ', 'EUC-JP')
  -> \ -> \
>>> roundtrip(' ', 'SHIFT_JIS')
  -> \ -> \
>>> roundtrip(' ', 'JOHAB')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
UnicodeEncodeError: 'johab' codec can't encode character '\u20a9' in position 0: illegal multibyte sequence

So is 0x5C a backslash or a yen/won sign? Or both? And what if 0x5C could be a second byte of a two-byte character? What could possibly go wrong?

Can't link qemu with static. I was puzzled but this looks wrong that pkg-config libssh2 doesn't output -lgpg-error. gcrypt depends on gpg-error.

With yesterday's announcement of littler 0.2.0, I kept thinking about a few not-so-frequently-asked but recurring questions about littler. And an obvious one if of course the relationship to Rscript. As we have pointed out before, littler preceded Rscript. Now, with Rscript being present in every R installation, it is of course by now more widely known. But there is one important aspect which I stressed once or twice in the past and which bears repeating. Due to the lean and mean way in which littler is designed and set-up, it actually starts a lot faster than either Rscript or R. How, you ask? Well we actually query the environement at build time and hardcode a number of settings which R and Rscript re-acquire and learn each time they start. Which is more flexible. But slower. So consider the following, really simple example. In it, we create a simple worker function f which launches the given (and simplest possible) R command of just quitting 250 times (by launching a shell command which loops). We then let littler, Rscript and R (in its just execute this expression mode) run this, and time it via one of the common benchmarking packages.

R> library(rbenchmark)
R> f <- function(cmd)   system(paste0("bash -c \"for i in \\$(seq 1 250); do ", cmd, " -e 'q()'; done\""));  
R> res <- benchmark(f("r"), f("Rscript"), f("R --slave"), replications=5, order="relative")
R> res
            test replications elapsed relative user.self sys.self user.child sys.child
1         f("r")            5  32.256    1.000     0.001    0.004     26.538     5.706
2   f("Rscript")            5 180.154    5.585     0.001    0.004    152.751    28.522
3 f("R --slave")            5 302.714    9.385     0.001    0.004    270.569    33.098
R> 

So there: littler does "nothing" about five times as fast as Rscript, and about nine times as fast as R. Not that this matters greatly -- but when you design something for repeated (unsupervised) execution, say in a cronjob, it might as well be lightweight.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.