When I was testing C code coverage analysis tools using WebAuth, I really should have investigated the segfault that I started getting in the test suite before releasing 4.4.1. But since valgrind didn't report any problems, I thought it was something specific to code coverage. Nope, uninitialized variable inside the WebKDC code. Which valgrind didn't catch at all for some reason. Now fixed, and I did check for similar issues, but it's sort of disturbing that valgrind completely missed it, particularly for a variable whose address is taken and therefore which I wouldn't think would be optimized away. Since I hate to release WebAuth to only fix one thing, I also tested out-of-tree builds for the first time in a while and fixed a pile of issues around how the Perl module builds work. There's got to be a better way. Maybe sometime I'll try to come up with some patches to teach Module::Build how to handle VPATH. I also imported some additional Autoconf glue that will hopefully help Hurd builds proceed farther, although I didn't promise anything in NEWS since WebAuth has not yet successfully built on Hurd. You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

This post is a quick status update on DebConf13, for those who aren t following the debconf-team mailing list. As you may know, this year s DebConf will be held at Le Camp, in Vaumarcus, Switzerland. Our concept for this DebConf is to hold it in a natural environment, away from distractions. We hope you will enjoy spending time together with other Debian collaborators in this beautiful part of Switzerland, on the shore of Lake Neuch tel. Dates DebConf13 will take place from Sunday 11. August 2013 to Sunday 18. August 2013. (We will use Saturday 10. August 2013 to prepare the venue for the conference.) You may notice that the dates don t cover two weeks like in the last few years (there is no separate DebCamp week). For budget reasons, current plans are to merge the two weeks activities into an 8 day period. If you think that s a pity, it s not too late to change it just join the fundraising team and start working quickly! Travel If you want to start arranging your travel to attend DebConf, some initial travel suggestions may be useful:

• We recommend that people from nearby countries take advantage of the excellent train connections to Switzerland, rather than looking for flights: the Swiss Federal Railways website, provides a very helpful international travel planner which knows about trains, but also about the local bus connections you will need to reach the DebConf venue.
• The best railway station to aim for is Yverdon-les-Bains. To get to the venue from there, take a local bus to the bus stop called Concise, Camp de Vaumarcus , which is very close to the venue. You can also directly use that name as your final destination in the above travel planner.
• Nearby airports include Geneva - GVA (1h30 from the venue by train), Zurich - ZRH (3h from the venue by train) and Basel-Mulhouse - BSL (3h from the venue by train).

The DebConf13 map shows the venue and the bus line (with some stops). Registration We expect to open registration around the start of March. Currently we are still evaluating some possible new conference management systems, which we hope might avoid the frustrations some attendees have had in the past with Pentabarf. Help welcome As always, the DebConf team is looking for volunteers. Some jobs need technical skills (e.g. testing conference management system setups, working on the website), but many DebConf tasks are about working to deadlines on non-technical issues (e.g. fundraising, budgeting, talk scheduling). You can see more information about some of the jobs to be done on the DebConf wiki. Please do think about getting involved and sharing your ideas with us, to help us make DebConf an even more useful event for Debian in the future. We look forward to welcoming you to Vaumarcus!

FOSDEM 2013 is over and it's time to look what interesting I have seen there on Sunday. Sunday was supposed to start for me with L20N, but it was postponed to 13:00 as the presenters weren't on time. I could have used one more hour of sleep, but at least I spent some time on coding. Detect merge conflicts in realtime was quite interesting talk, though I was pretty surprised that the conflict detecting does not at all care about underlying version control system, but does purely file based guesses. The Hardening MySQL talk pretty much described why security in MySQL sucks and what you should do to make it secure. Quite good introduction to the topic, but not much new information for me. Introduction of Firefox OS, was quite nice demo showing they have something working, though it had some problems with flaky network on FOSDEM. Looking forward to see phone being sold, though it will probably not be something I'd buy. To add some fun, I've stayed on systemd, Two Years Later presentation, which gave some summary of what is currently in systemd and where it wants to go. Still it did not move systemd from category of "I don't care as long as it works". Now followed delayed L20N talk - it showed new Mozilla's effort for localization. Which is quite powerful and has nice features, on the other side it put's quite more load to translators - now they would have to understand some basics of programming as well to be able to use the new features (or not so new ones as plurals). Their motivation is to remove localization effort from developers, but I'm not really convinced it will work nicely. After some meetings and lunch, I went to LibreOffice: cleaning and re-factoring a giant code-base, which showed some challenges LibreOffice has to take and how they dealt with that. I think it's pretty great job done and I'm looking forward to new releases. Being GNOME user, I could not skip Has the GNOME community gone crazy?. It of course tried to tell that they did not :-). Last, but not least my friend Dieter from phpMyAdmin had talk Present and future of phpMyAdmin. He listed some of the new features, demoed 3.5 and 4.0 version (of course the demo of 4.0 version broke due to some caching). Even when the talk had quite unpleasant timing, it has attracted some people and they even asked few questions. This years FOSDEM was again great and looking forward to be there next year.

Filed under: Debian English Phpmyadmin Suse Weblate 2 comments Flattr this!

Lots of exciting things are happening with and around Rcpp. I just added a new page about Upcoming Events to the recently-created Rcpp site. This events page has lots to cover: an upcoming talk at Columbia on March 8 (details still TBD), a day-long workshop in New York on March 9, a possible participation at a CERN / ROOT conference in Switzerland on May 11-14, an upcoming talk in May in Milwaukee, and last but not least the tutorial by Romain and Hadley at UseR! 2013 in Spain. Phew! With that, a few quick words about the upcoming master class in New York. It will be a full day, covering an introduction and motivation, details about the core data types, tools for working with and and extending Rcpp and of course applications galore, including RcppArmadillo and RInside. I have done the same one day class format a few times before, most recently (with Revolution Analytics) in San Francisco in late 2011, and also as a two-part seminar at UseR! 2012. This time, we plan on providing cloud-hosted RStudio instances for participants. Better still, RStudio's own JJ Allaire will be on deck as well for RStudio --- and Rcpp Attributes --- questions. Details and registration information for the New York class are at this page.

Since some people asked for it, and since it's (unfortunately) fairly nontrivial, here is the script that I'm using currently to transcode a .dv file into webm:

#!/bin/bash
set -e
newfile=$(basename $1 .dv).webm
wavfile=$(basename $1 .dv).wav
normalfile=$(basename $1 .dv)-normal.wav
normalfile=$(readlink -f $normalfile)
oldfile=$(readlink -f $1)
echo "Audio split"
gst-launch-0.10 uridecodebin uri=file://$oldfile ! progressreport ! audioconvert ! audiorate ! wavenc ! filesink location=$wavfile
echo "Audio normalize"
sox --norm $wavfile $normalfile
echo "Pass 1"
gst-launch-0.10 webmmux name=mux ! fakesink \
  uridecodebin uri=file://$oldfile name=demux \
  demux. ! ffmpegcolorspace ! deinterlace ! vp8enc multipass-cache-file=/tmp/vp8-multipass multipass-mode=1 threads=2 ! queue ! mux.video_0 \
  demux. ! progressreport ! audioconvert ! audiorate ! vorbisenc ! queue ! mux.audio_0
echo "Pass 2"
gst-launch-0.10 webmmux name=mux ! filesink location=$newfile \
  uridecodebin uri=file://$oldfile name=video \
  uridecodebin uri=file://$normalfile name=audio \
  video. ! ffmpegcolorspace ! deinterlace ! vp8enc multipass-cache-file=/tmp/vp8-multipass multipass-mode=2 threads=2 ! queue ! mux.video_0 \
  audio. ! progressreport ! audioconvert ! audiorate ! vorbisenc ! queue ! mux.audio_0
rm $wavfile $normalfile

It's fairly non-optimal, because many of these command-line A/V tools are either fairly badly documented, or have a horrific interface, or something similar. avconv is supposed to be able to do audio normalisation, but I haven't been able to figure out exactly how it's done. The options that are specified in the manpage seemingly have no effect. gstreamer has a 'ReplayGain' plugin which can do audio normalisation. Audio normalisation requires two passes; I could in theory just add the element in the gstreamer first-pass pipeline, add a '-t' to the gst-launch-0.10 invocation, and parse out the required gain value that I can then add to the second-pass pipeline. However, the elements that I can then pass that gain value to either have a different range for the gain (rgvolume's fallback-gain parameter) or expect a completely different unit of values with no obvious way to translate between the two (the 'volume' element's 'volume' parameter expects a multiplier, the replaygain plugin produces a dB value; a simple conversion seems wrong as it produces a value way out of range). The 'volume' element reportedly has an interface that takes a dB value, except you can't reach it from gst-launch-0.10. Bummer. So instead we split out the audio, do normalisation in sox, and mux that back in during the second pass of the video transcoding. Sox is good. Sox is easy. If all A/V command-line tools were like sox, I would be smiling now. What's missing from the above script is how to throw away the start or end of a file in case there's several minutes of uninterestingness there. This is easiest (in my experience) with avconv's -t and -ss options. I suspect gstreamer is capable of doing that, too; but I haven't figured out how, and this works. You may want to play with some of options of the vp8enc element. For instance, the threads= value can be increased (or decreased) depending on how many cores your transcoding machine has. You could probably also add a "target-bitrate" value if you find the quality is too low or the system uses too much diskspace. VP8 has several more options; the documentation lists them all. If you've done video recordings for a devroom at FOSDEM outside of the FOSDEM video team, note that FOSDEM is more than willing to host the videos. To do so, the easiest way is if the videos are online somewhere (this does not have to be a public system) that we can wget or scp them from; if you've done that, contact me with the location to the files and we'll put them on the FOSDEM video server.

For the second year in a row, I've led the team that organized video at FOSDEM. This year, most things went pretty smoothly; more so than last year. We definitely learned from some of our mistakes, and although I can't say that everything went better than it did last year, after having done a first look at things I can certainly say that overall, the result is better now than it was last year. Our setup was very similar to what it was last year. However, there were some key differences:

• Last year, we used two semi-professional cameras (with XLR audio inputs), two HD camcorders (with only mini-jack audio inputs), and one old SD-only camcorder (similarly, with only mini-jack audio input). This year, we decided to rent three XLR-capable cameras instead; while this drove the cost up, it seriously reduced the complexity for the audio setup. As a result, we had much less issues with talks that only had audio recorded.
• Due to some misunderstanding, last year the ULB's A/V department was not contacted to request access to their equipment. As a result, we had to do our own audio set-up in Janson and the K auditorium. This year, we made sure that this problem did not repeat itself; as a result, in the K auditorium and in Janson, all we had to do was connect an XLR feed to the camera, and we had audio.
• Last year, the machines doing transcoding were two rented laptops, one fairly recent spare laptop that I had lying around, and one somewhat older desktop machine. This was needlessly complex. This year, I rented less laptops but added a server with significant diskspace that we could do the flumotion recording on. This made the streaming and recording somewhat less complex to administer.
• Most critically, this year I had arranged for special green Videoteam t-shirts. This made it much easier to recognize who my trained videoteam volunteers were, and was instrumental in ensuring we didn't have the same volunteers man the same recording station all sunday afternoon, as was the case last year.

Unfortunately, that didn't mean all was well. The internal server would transcode the DV stream into WebM, which was then sent on to the Flumotion platform where it was going to be transcoded to Ogg Theora, before being streamed in both formats. Due to an issue which we could not track down (possibly something incorrect in my configuration), the transcoding into Ogg Theora did not work smoothly, and even had the unwanted effect of disrupting the WebM streaming. Since this made it difficult to debug without disrupting service, eventually we decided to give up on Ogg Theora and only provide WebM streams; I considered that to be a better solution than no streaming at all. In addition, apparently in the year since FOSDEM 2012, libav and gstreamer have changed significantly enough that the scripts that I used then had to be somewhat revisited in order to be able to transcode the existing recordings into WebM ready for video.fosdem.org. Oh well, I had to add in normalisation anyway; only it would've been nice if I didn't have to revisit it from scratch. Meh. At any rate, our streams seem to have been very popular. Some statistics:

Saturday

Sunday

Served traffic by country (over the whole weekend)

Served sessions by country (over the whole weekend)

As you can see from these graphs, watching the streams from Belgium seems to be happening fairly often; I suspect much of that is people at the conference watching a stream in a different room. Additionally, we peaked at 212 viewers, which is slightly more than the peak of 206 that we had last year. The final conclusion we can take home from these statistics is that the most popular talk on Saturday (at least according to people watching the streams) was the eudev one in the cross-distro room (with 68 viewers); on sunday, the talks in Janson were all fairly equally popular. The peak of 102 viewers was reached around 15:45. Overall, I'm quite happy with the result. Yesterday, Thomas Eug ne of NamurLUG (who used to do video for several years before I took over last year) helped me do the first review. What's left now is to do some transcoding and uploading; this will happen over the next few days and weeks.

After 27 hours of travel, I'm finally back from my first Linux.conf.au. This was a great conference! Some of my favorite highlights:

• Out for dinner the first night, my whole table started spontaneously talking about Haskell, including details of IO management frameworks like conduit and pipes, and a new one that's waiting in the wings. That just doesn't happen in the real world. A lot of us continued to do Haskell stuff in the hallway track, although for some reason there were no Haskell talks on the official schedule. Maybe it's time for a Haskell miniconf at LCA?
• Meeting Josh, Jamie, Sarah, Brendan, Craig, and others I've worked with online but never encountered IRL. Also reconnecting with old friends (some I'd not seen in 13 years) and finding new ones.
• The speaker's dinner in a revolving restaurant overlooking Canberra. Leave it to a restaurant full of geeks to invent an asychronous communications medium in such a setting. (Notes attached to windows to be read and answered by tables as they rotated by.)
• Meeting quite a lot of git-annex users, Kickstarter backers, and people interested in using git-annex. Thanks to everyone who came up to me for a chat.
• The evening pickup board game sessions. Especially my wiping out three other Tsuro players at once by forcing them all to end on the same square. ;) These were where I felt the most at home in Australia.
• Robert Llewellyn dropping in and mingling with fans of Red Dwarf and Scrapheap Challenge. One of the very few actors I could possibly fanboy on, and LCA not only somehow got him, but constructed an atmosphere that allowed for this photo of us.

---

My git-annex talk went ok, despite technical problems with the video output, which the video team did a great job of working around. The first demo went well, and the Q&A was excellent. The demo of the git-annex assistant webapp was marred by, apparently, a bad build of the webapp -- which I ironically used rather than my usual development build because I assumed it'd be less likely to fail. At least I may have a way to reproduce that hang somewhat reliably now, so I can get on with debugging it. I will be redoing a demo of the webapp as a screencast.

---

Here are some of the best talks I attended. (I have quite a lot more queued up to watch still, and had to cut several due to space.) Click titles for videos, or browse all the videos.

• Git for Ages 4 and Up
  Schwern has found a new, excellent way to explain git. I felt rather bad for using up a seat, especially once people were kicked out when the room was filled over capacity. But I enjoyed every minute of it. (Also has the best speaker intro ever. "Schwern once typed git pull --hard and pulled GitHub's sever room across the street.")

  BTW, I must confess: I left the red apple on teacher's desk.

• Radia Perlman's keynote
  Network protocol design and poetry from one of the quiet heros of our field. I knew Spanning Tree Protocol was used in ethernet, but it just works, so like many I never paid much attention to it. This talk felt like the best lectures, where you're learning from a master on multiple levels at once. Well done work often becomes an unremarked part of the landscape, which I sometimes find unrewarding, so it was great to have Radia give some perspective on what that's like over the course of decades.
• Lightning Talks
  A 90 second time limit really helps. Too many conferences have 5 minute talks, which is less exciting. If you still find them boring, skip forward to 13:50, where pjf does two talks in 90 seconds! (If a 20 second talk on depression is too .. manic, there's an encore at the end.)
• The IPocalypse 20 months later
  A reality check, with real data. Very important stuff here. We need to work to avoid this worst case scenario, and we also need to design around it.
• REPENT!!! FOR THE END OF THE UNIX EPOCH IS NIGH!!!
  Wildest talk beginning I've seen since RMS put the hard drive halo on his head. And to an important point: Any programs that deal with dates 25 years in the future already need to be fixed today to deal with the epoch rollover. This got me digging around in Haskell date libraries, to make sure they're ok.
• Building Persona: Federated and Privacy Sensitive Identity for the Web
  This talk and some previous conversation with Francois have convinced me that Persona (AKA Browserid) has a design that can succeed. I will be adding Persona login support to ikiwiki.
• Beyond Alt Text: What Every Project Should Know About Accessibility
  I missed the first half due to giving my talk, but the second half was full of rather a lot of excellent information, some of which I'd only guessed at before.
• Git: Not Just for Source Code Anymore
  Good overview of the new ways to use git. Also kept giving examples from my body of work, which is some nice ego stroking, thanks Josh. ;-)

FOSDEM 2013 is over and it's time to look what interesting I have seen there on Saturday. First of all the most important for me is to meet people. As usual, I came with SUSE folks, but it's not that unusual to meet people from company where you work :-). I've met some current and former phpMyAdmin developers and surprisingly I've met few Weblate users or people who consider using it on their project. This gave me some important feedback and one of first thing you will see in near future is remade Weblate website to give more information about some of it's unique features. As for the talks, I think I've managed to visit quite lot of them. How we made the Jenkins community explained some ways Jenkins has used to build good community - mostly focused on extensibility of the code and having everything as an extension, but with some focus on social things as well (and important thing that with Git people are not that motivated to join the team). Better software through user research was about various way to gather information of what your users hate on the software. It was pretty interesting, though many of that can not easily be used on small scale free software product. OSS code goes in and never comes out talk focused about licensing issues of various software as a service platforms. As I've never used Amazon cloud or such, it was quite surprising how these behave in relation to GPL and actually made me thing more about AGPL and attend related panel discussion later. An Integrated Localization Environment is Mozilla approach to online translation, quite different than anything we have before, but mostly for reasons which were explained later on Sunday talk on l20n. Maybe reverse ordering of these would make it easier to understand the motivation. Scale your Jenkins build pipeline automatically to minimize test time was not that useful as I thought - increasing test speed by buying EC2 instances and pushing part of the work to them is not something what will help me in near future. Trends in Open Source Security explained what is going on in distributions security, mostly focused on Redhat (but touching Debian as well). It has some interesting thoughts about sharing the information between vendors, so let's see if it will really work in future. QML s many faces showed some other ways to use QML besides using QtQuick. Some uses were quite interesting, though I'm not really fan of creating yet another buildsystem based on it. Panel Discussion: GNU Affero General Public License, version 3 was last thing I've visited on Sunday and it was really interesting to listen all that opinions on AGPL. Still I was not confirmed to consider switching to this license.

Filed under: Debian English Phpmyadmin Suse Weblate 0 comments Flattr this!

(Edit: It's been suggested that the title of this could give the wrong impression. "Don't like Secure Boot? That's not a reason to buy a Chromebook" may have been better)

People are, unsurprisingly, upset that Microsoft have imposed UEFI Secure Boot on the x86 market. A situation in which one company gets to determine which software will boot on systems by default is obviously open to abuse. What's more surprising is that many of the people who are upset about this are completely fine with encouraging people to buy Chromebooks.

Out of the box, Chromebooks are even more locked down than Windows 8 machines. The Chromebook firmware validates the kernel, and the kernel verifies the filesystem. Want to run a version of Chrome you've built yourself? Denied. Thankfully, Google have provided a way around this - you can (depending on the machine) either flip a physical switch or perform a special keystroke in the firmware to disable the validation. Doing so deletes all your data in the process, in order to avoid the situation where a physically present attacker wants to steal your data or backdoor your system unnoticed, but after that it'll boot any OS you want. The downside is that you've lost the security that you previously had. If a remote attacker manages to replace your kernel with a backdoored one, the firmware will boot it anyway. Want the same level of security as the stock firmware? You can't. There's no way for you to install your own signing keys, and Google won't sign third party binaries. Chromebooks are either secure and running Google's software, or insecure and running your software.

Much like Chromebooks, Windows 8 certified systems are required to permit the user to disable Secure Boot. In contrast to Chromebooks, Windows 8 certified systems are required to permit the user to install their own keys. And, unlike Google, Microsoft will sign alternative operating systems. Windows 8 certified systems provide greater user freedom than Chromebooks.

Some people don't like Secure Boot because they don't trust Microsoft. If you trust Google more, then a Chromebook is a reasonable choice. But some people don't like Secure Boot because they see it as an attack on user freedom, and those people should be willing to criticise Google's stance. Unlike Microsoft, Chromebooks force the user to choose between security and freedom. Nobody should be forced to make that choice.

(Updated to add that some Chromebooks have a software interface for disabling validation)

comments

Public service announcementWhen porting GNU/Linux applications to a new architecture, such as 64-Bit ARM, one gets familiar with the following error message:

checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration  aarch64-oe-linux': machine  aarch64-oe' not recognized
configure: error: /bin/sh config.sub aarch64-oe-linux failed

This in itself is trivial to fix - run autoreconf or just copy in new versions of config.sub and config.guess. However, when bootstrapping a distribution of 12000+ packages, this becomes quickly tiresome. Thus we have a small request:

If you are an upstream of a software that uses autoconf - Please run autoreconf against autotools-dev 20120210.1 or later, and make a release of your software. Aarch64 porters will be grateful as updated software trickles down to distributions. This was the most discussed point during my FOSDEM talk "Porting applications to 64-Bit ARM".

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 (84.25 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Debian Packaging In one of my customer projects, I had to use libwebsockets and since it was not packaged for Debian, I filed a Request For Package (RFP #697671). I discovered a fork of this library on github and decided to mail the original author and the author of the fork to learn a bit more about the reason of the fork. It turns out that they miscommunicated and that the original author was interested by most of the improvements. The fork still exists but the important fixes and most of the improvements have been merged (and he released a version 1.0 after that!). Furthermore the original author setup a bug tracker to better organize the project and so that the author of the fork can submit patches and be sure that they won t be forgotten (as it happened in the past). I spend quite some time discussing with both parties but at the end I m pleased to see that good progress has been made (although nobody stepped up to maintain this package in Debian). I packaged zim 0.59 (an important bugfix release) and wordpress 3.5.1 (with several security fixes). I updated the dpkg-dev squeeze backports to version 1.16.9~bpo60+1 on request of Daniel Schepler. This backport led me to file #698133 on kgb-client because the bot literally spammed the #debian-dpkg IRC channel for multiple hours by resending old commit notices that got merged in the squeeze-backports branch. BTW, they need help to get this issue fixed. I updated python-django-registration to fix a compatibility issue with python3-sphinx (see #697721 for details). Misc Debian Stuff Serious bug with salt. I filed a grave bug on salt (#697747 ) and prepared the upload to fix the issue on request of the maintainer. In the mean time, the maintainer orphaned the package. Franklin G. Mendoza already announced its willingness to take over but this package deserves multiple maintainers since this is a good piece of software that is getting more and more popular. net-retriever and alternate keyrings. I filed a wishlist bug (#698618) on net-retriever to request a way for derivatives to use another keyring package (i.e. not debian-archive-keyring-udeb) without having to fork net-retriever. Linux 3.7 on armel/armhf. I helped the kernel maintainers to fix the 3.7 kernel on armel/armhf by reporting on IRC the results of successive failing kernel rebuilds on those architectures (this kernel version is only in experimental). Carl9170 firmware. I also pinged the kernels maintainers about a missing firmware for the carl9170 driver (already reported in #635840) and Ben Hutchings took care of re-activating its inclusion in upstream s linux-firmware.git and then uploaded firmware-free 3.2 to Debian. Thanks Ben! New QA team member. And to finish with the miscellaneous stuff, I helped Holger Levsen to be added to the qa group so that he could integrate his awesome work on automated QA checks with Jenkins. Debian France Preparation for Solutions Linux. The people organizing the village of associations in the Solutions Linux conference have asked all organizations to apply for a booth if they wanted one. Last year Carl Chenet took care of organizing this and this time we had to find someone else. I made multiple call for volunteers (on the mailing list, on my blog) without much success but I finally managed to convince Tanguy Ortolo to take care of this. Thank you Tanguy! Get in touch with treasurer who disappeared. During the transition with the former Debian France officers, it has been said that Aur lien G r me another former treasurer of Debian France had entirely disappeared together with some papers that he never gave to his successor. I didn t want to give up on this without at least trying to get in touch by myself so after multiple tries (over IRC, phone, and snail mail), and some weeks without answers, he got back to me, explaining that he s currently in a foreign country and that he will take care of that next time that he comes in France. \o/ New website in preparation. Replacing the single-page website webpage with a more comprehensive website is an important goal. Alexandre Delano provided a basic ikiwiki setup inspired by dsa.debian.org. I cleaned it and integrated it in a git repository on our machine. There s thus a new test website on http://france.debian.net/test/. Tanguy Ortolo and Fernando Lagrange immeditaly made some small improvements but since then nobody stepped up to further complete the website. I ll try to do this in February and put the new website in production. Paypal and handling of members. We installed a paypal plugin in galette so that members can renew their membership online. I asked Christian Bayle to try it out and we found some issues that I reported upstream and that got fixed. But this is only the first step, we want to go much further and automate all the membership handling, from membership renewal mail reminders up to integration in the accounting system. To this end, I filed some new tickets in the Galette tracker and completed some that were already opened: #490, #368 and #394. We requested a quote for those tickets and Debian France is going to fund the work on those tickets so that we have a 100% free software solution for our needs. Thanks See you next month for a new summary of my activities.

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

The previous article was introducing basic streaming principles based on Icecast. The issue with this, of course, is lag and overhead of HTTP-based connexions. In this article we introduce RTP-based streaming system, (unfortunately) based on Pulseaudio and multicast. (Update: there was a rant here about Pulseaudio (PA) that I have moved out of this post because it's not what I was aiming to talk about. Those wanting to answer that troll are welcome to join the flamewar here.)

A word on multicast I took the opportunity of trying out Multicast (it's actually IP multicast, to be more precise), since I wanted to have only minimal configuration to perform on the client side. Plus, since the RTP frames are raw 44khz 16 bit audio, the traffic is actually quite heavy, 1.4mbps, to be more precise (punch in 44kHz * 16bit/Hz * 2 in the excellent Qalculate to see why), so I didn't want bandwidth to explode as more listeners joined in. As a comparison, also note that the Icecast Vorbis stream is around 64 or 128kbps depending on quality. Multicast allows packets to be sent only once for multiple listeners on the same network. It's actually quite cool, but doesn't work very well over the wider internet, for reasons that are still unclear to me. I presume that the fact there is virtual monopoly over traditional broadcasting systems (e.g. television and radio) means that multicast hasn't really kicked in yet... I hope this will make sense over the Montreal mesh, although the quality would probably need to be dialed down, or the audio streamed encoded instead of be sent as raw samples.

So why PA? VLC/pipe failures That aside, it seems that to stream through RTP, I have no choice. I have tried to use VLC as a pipe to stream data out of MPD as RTP, but somehow this config snippet just failed:

audio_output  
   type            "pipe"
   name            "RTP"
   command         "cvlc -q - --sout '#rtp dst=239.72.72.144,port=5004 '"
   encoder         "vorbis"                # optional, vorbis or lame
   format          "44100:16:2"
 

I don't know why - the multicast port wouldn't open properly and MPD would even hang when restarting. It seems the pipe plugin is somewhat broken. Note that the vlc command above actually works fine to stream audio content out through multicast, which is a good way to test if multicast works in the first place...

Shoving PA down MPD's throat Instead, I had to go to the clunky PA-way (also know as "my way or the highway"). The first step was to configure the default.pa to enable RTP streaming. I copied over the default /etc/pulse/default.pa file into ~mpd/.pulse/default.pa and uncommented the following lines:

# just to get the PA announced
load-module module-zeroconf-publish
# we need a null sink, no clue why, but without this glue, it fails
load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties="device.description='RTP Multicast Sink'"
# port is specified otherwise it is random (?!)
# loop=1 is to broadcast locally too
# other useful setting: destination (defaults to 224.0.0.56)
load-module module-rtp-send source=rtp.monitor port=5004 loop=1

See the rtp-send module documentation for more information here. Then we need MPD to connect to that sink:

audio_output  
    type            "pulse"
    name            "Pulsaudio RTP"
    sink            "rtp"
 

Also, now that we got into the PA kitchen sink, we are kind of forced to use it for the local sound card output too, so we'll add this as a sink to:

audio_output  
    type            "pulse"
    name            "Pulseaudio sound card"
    sink            "alsa_output.pci-0000_00_1b.0.analog-stereo"
 

(Take a moment to admire the nice sink name. Yours may be different, have fun finding it in the output of pacmd list-sinks, but that works only once PA is started!) So now you need to restart MPD for those changes to take effect. Note that if the mpd user has already started PA, you're in luck: it won't restart it by itself, and you need to:

service mpd stop
killall pulseaudio
service mpd start

... yep. Basically because pulseaudio just detaches completely from the parent process when spawned automatically. Lots of fun.

Testing and listening Of course, you can listen to the stream using... Pulseaudio. I assume this would magically show up on the network thanks to avahi, if you run Pulseaudio on (say) your laptop. Since I still want to stay away from it, I would rather use a straight commandline tool to listen to the stream. According to this page, there aren't that many clients that could listen to such a funky stream. I chose VLC, since its commandline options actually make sense. Here's the magic mantra to repeat every night before you go to bed:

cvlc rtp://@224.0.0.56:5004

Yes, that's all. Drop the c if you want a GUI. With mplayer, it's more complicated - you need to specify a bitmask using a hexadecimal string (fun stuff):

mplayer -demuxer rawaudio -rawaudio format=0x20776172 rtp://224.0.0.56:5004

Yes, good old 0x20776172...

Results! We want results! All this work reduced the lag from 15 seconds to around 1 second. It's still present, and confusing to listen to, but maybe more acceptable. It seems most of the lag is in the vlc client buffering, when I enable debugging, I see:

[0x963c7bc] main input debug: Stream buffering done (1001 ms in 976 ms)

I was able to reduce that delay significantly by using the --rtp-caching option of vlc, as such:

cvlc --rtp-caching=48  rtp://@224.0.0.56:5004

The value is in miliseconds. Anything below 48ms introduces audible artifacts (probably buffer underruns). With that setting, there's still a noticeable delay, especially with isolated sounds that are naturally more noticeable. With more harmonious music, it sounds more like an echo. I have also tried to fiddle with similar settings with mplayer and simply failed to get any results. --no-cache simply drops samples like crazy. --cache 64 is the lowest I could push it down to, and it still has noticeable delay, which I couldn't measure, but I would assume would be around 400ms at least. Also note that contrarily to the previous setup I had, based on Icecast, VLC will automatically resume streaming from the RTP stream as it is stopped or started, which is also very nice - as it allows me to disable remote RTP streams easily and harmlessly.

Troubled areas Speaking of insane nonsense, here are a few pitfalls to avoid. Take care to disable the ALSA output, if it's not yet commented out, because MPD will freak out with the following error message:

Feb 03 20:25 : output: "Sound card" [alsa] failed to play: Resource temporarily unavailable

I have not been able to find a way to make PA let go of the audio sound card. I would have prefered MPD to open ALSA directly if PA wasn't needed (I need it only for RTP streaming), but it seems that PA assumes you'll want to play stuff locally. I have tried commenting out the following in default.pa:

load-module module-udev-detect

Seems like it's not enough. Also note that PA is designed with "dumb users" in mind (read: you need a GUI to operate it), so in the context of MPD, it's really annoying to debug things unless you can actually fire up a X11 session as the MPD user (which strikes me as a crazy idea) to configure PA properly with paprefs and all the graphical gizmos. I just gave up and went with PA all the way, and just added the RTP sink through the commandlines. Other guides can show you screenshots to clikety your way through inane graphical interfaces to do the above, if you are into that kind of stuff. With PA, you will want to get familiar with the pacmd and pactl commands. Why there are two different commands to basically do the same thing is completely beyond me.

Reference and more reading I got a lot of information in the Pulseaudio MPD wiki page and the Pulseaudio user documentation. The VLC manual about RTP streaming (server) (client) was also useful for debugging. The Pulseaudio Network documentation has a set of recipes for using pulseaudio for everything. This Ask Ubuntu question explains how to clikety your way through paprefs to essentially do the above.

I have been using MPD for a good while as my media player, in conjunction with gmpc as a graphical interface (since MPD is just a server). It's really cute, works reasonably well, and is one of the only software that can handle my huge music collection gracefully. The cool thing with the setup is that, because MPD is a network-transparent server, I can control (and listen to!) my music remotely.

Basic HTTP / Icecast streaming For a while, I have also been streaming my music through Icecast so that I can basically listen to my music from anywhere there is an internet connection with sufficient bandwidth. This configuration is simple enough:

audio_output  
    type            "shout"
    name            "Currently listening to..."
    host            "localhost"
    port            "8000"
    mount           "/radio.ogg"
    password        "hackme"
    quality         "4.0"
    format          "44100:16:2"
    description     "My playlist of the day. High quality (4) OGG/Vorbis stream."
 

This will make a stream available at http://radio.example.com:8000/radio.ogg, provided Icecast is configured properly. That setup is a bit more complicated than necessary, because it needs an icecast server to be installed (which is just apt-get install icecast on Debian, but still). So an alternative, simpler setup, but which may not scale as well to many listeners, is:

audio_output  
   type            "httpd"
   name            "My HTTP Stream"
   encoder         "vorbis"                # optional, vorbis or lame
   port            "8000"
   quality         "5.0"                   # do not define if bitrate is defined
   bitrate         "128"                   # do not define if quality is defined
   format          "44100:16:1"
 

I haven't played around too much with that plugin, so I don't know how well it works - I am using the Icecast plugin instead.

Always on radio Another cool thing is that I have actually two MPD daemons running at the same time - one is my regular player, but the other is the "shuffle" player. The basic idea is that when the regular player stops, the shuffle starts, and vice versa, so there is always something playing on the stream. The shuffle, by default, doesn't play on the local sound card so that even though the radio stream is up, it doesn't blast random music through my living room speakers all day (and night!). This trick is accomplished through a hook in the Icecast daemon:

<mount>
    <mount-name>/radio.ogg</mount-name>
    <fallback-mount>/random.ogg</fallback-mount>
    <!-- when I listen to my radio, I turn off the random MPD stream to save CPU -->
    <on-connect>/home/anarcat/bin/mpd-stop-random</on-connect>
    <!-- ... and when I stop listening, the other stream just kicks in -->
    <on-disconnect>/home/anarcat/bin/mpd-start-random</on-disconnect>
    <!-- i put those here to try to display something on the stats page when there's no client, but it's not working -->
    <stream-name>Currently listening to...</stream-name>
    <stream-description>My playlist of the day. High quality (5) OGG/Vorbis stream. If I'm not listening to anything, you'll be redirected to the random playlist.</stream-description>
</mount>
<!-- final fallback: the random radio, which is started when the above playlist disconnects -->
<mount>
    <mount-name>/random.ogg</mount-name>
    <stream-name>Random!</stream-name>
    <stream-description>Random songs from a 33 days playlist</stream-description>
</mount>

The mpd-start-random script is rather idiotic:

#!/bin/sh
export MPD_HOST=hackme@radio.anarcat.ath.cx
export MPD_PORT=6601
mpc play

You can guess what the mpd-stop-random script does (hint: the opposite of play is pause). So that's the old way of doing things. The one problem I found with this setup is when I want to setup another listener in the same house - the problem is that the Icecast stream has significant delay: a good 14 seconds here, with ogg123 as a client. Here's the special configuration for the mpd-slave daemon that runs the random playlist:

# same as main player
music_directory         "/var/lib/mpd/music"
playlist_directory      "/var/lib/mpd/playlists"
# those need to be different
db_file                 "/var/lib/mpd-slave/tag_cache"
log_file                "/var/log/mpd/mpd-slave.log"
pid_file                "/var/run/mpd/slave.pid"
state_file         "/var/lib/mpd-slave/state"
# avoids having to update the database by hand all the time
auto_update    "yes"
# disabled by hand after daemon is started    
audio_output  
    type            "alsa"
    name            "Sound card"
 
# main icecast stream
audio_output  
    type            "shout"
    name            "Random!"
    host            "localhost"
    port            "8000"
    mount           "/random.ogg"
    password        "hackme"
    quality         "4.0"
    format          "44100:16:2"
    description     "Random songs from a 33 days playlist"
 
# another player for low bandwidth situations, disabled
audio_output  
    type            "shout"
    name            "Random! (lowfi)"
    host            "localhost"
    port            "8000"
    mount           "/random.ogg"
    password        "hackme"
    quality         "0.0"
    format          "44100:16:2"
    description     "Random songs from a 33 days playlist"
 
filesystem_charset "UTF-8"
user               "mpd"
default_permissions     "read"
port    "6601"
mixer_type                      "software"
volume_normalization            "yes"

The random playlist is done by simply adding the whole library to the playlist. MPD chokes a little the first time you do that, but it's surprisingly fast. I also went through the playlist to remove spoken words and other stuff I don't want to stumble upon, and after I shuffled the playlist.

Final notes Otherwise, this is a fairly standard MPD setup, although there are some special configuration that vary from the upstream default:

# this needs to be commented out for the server to be accessible from everywhere
#bind_to_address                "localhost"
# setup a password for remote access
password                "hackme@read,add,control"
# make sure the mixer controls don't affect the local hardware mixer
mixer_type                      "software"
# we are beyond the ASCII world, but MPD doesn't know
filesystem_charset              "UTF-8"
id3v1_encoding                  "UTF-8"

This is the first part of a series of articles I intend to write about my MPD configuration, next ones detail the configuration of a dumb player and RTP streaming.

It was interesting to read recently from Martin F. Krafft a botnet-like configuration management proposal. Professionally I've used CFEngine, which in version 2.x, supported a bare minimum of primitives, along with a distribution systme to control access to a central server. Using thse minimal primitives you could do almost anything:

• Copy files, and restart services that depend upon them.
• Make minor edits to files. (Appending lines not present, replacing lines you no longer wanted, etc)
• Installing / Removing packages.
• More ..

Now I have my mini cluster (and even before that when I had 3-5 machines) it was time to look around for something for myself. I didn't like the overhead of puppet, and many of the other systems. Similarly I didn't want to mess around with weird configuration systems. From CFEngine I'd learned that using only a few simple primitives would be sufficient to manage many machines provided you could wrap them in a real language - for control flow, loops, conditionals, etc. What more natural choice was there than perl, the sysadmin army-knife? To that end slaughter was born:

• Download polices (i.e. rules) to apply from a central machine using nothing more complex than HTTP.
• Entirely client-driven, and scheduled via cron.

Over time it evolved so that HTTP wasn't the only transport. Now you can fetch your policies, and the files you might serve, via git, hg, rsync, http, and more. Today I've added one final addition, and now it is possible to distribute "modules" alongside policies and files. Modules are nothing more than perl modules, so they can be as portable as you are careful. I envisage writing a couple of sample modules; for example one allowing you to list available sites in Apache, disable the live ones, enable/disable mod_rewrite, etc. These modules will be decoupled from the policies, and will thus be shareable. Anyway , I'm always curious to learn about configuration management systems but I think that even though I've reinvented the wheel I've done so usefully. The DSL that other systems use can be fiddly and annoying - using a real language at the core of the system seems like a good win. There are systems layered upon SSH, such as fabric, ansible, etc, and that was almost a route I went down - but ultimately I prefer the notion of client-pull to server-push, although it is possible in the future we'll launche a mini-daemon to allow a central host/hosts to initial a run.

This is the "too late because FOSDEM" edition. On the plus side, we will be ready to release Squeeze next week... The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 788
  • Affecting wheezy: 224 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 132 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 28 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 5 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 100 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting wheezy only: 92 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 62 bugs are in packages that are unblocked by the release team.
      • 30 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week	Squeeze	Wheezy	Diff
43	284 (213+71)	468 (332+136)	+184 (+119/+65)
44	261 (201+60)	408 (265+143)	+147 (+64/+83)
45	261 (205+56)	425 (291+134)	+164 (+86/+78)
46	271 (200+71)	401 (258+143)	+130 (+58/+72)
47	283 (209+74)	366 (221+145)	+83 (+12/+71)
48	256 (177+79)	378 (230+148)	+122 (+53/+69)
49	256 (180+76)	360 (216+155)	+104 (+36/+79)
50	204 (148+56)	339 (195+144)	+135 (+47/+90)
51	178 (124+54)	323 (190+133)	+145 (+66/+79)
52	115 (78+37)	289 (190+99)	+174 (+112/+62)
1	93 (60+33)	287 (171+116)	+194 (+111/+83)
2	82 (46+36)	271 (162+109)	+189 (+116/+73)
3	25 (15+10)	249 (165+84)	+224 (+150/+74)
4	14 (8+6)	244 (176+68)	+230 (+168/+62)
5	2 (0+2)	224 (132+92)	+222 (+132/+90)
6	release!

Graphical overview of bug stats thanks to azhag:

My last bitcoin related blog post mentioned that the new bitcoin package for Debian was waiting in NEW. It was accepted by the Debian ftp-masters 2013-01-19, and have been available in unstable since then. It was automatically copied to Ubuntu, and is available in their Raring version too. But there is a strange problem with the build that block this new version from being available on the i386 and kfreebsd-i386 architectures. For some strange reason, the autobuilders in Debian for these architectures fail to run the test suite on these architectures (BTS #672524). We are so far unable to reproduce it when building it manually, and no-one have been able to propose a fix. If you got an idea what is failing, please let us know via the BTS. One feature that is annoying me with of the bitcoin client, because I often run low on disk space, is the fact that the client will exit if it run short on space (BTS #696715). So make sure you have enough disk space when you run it. :) As usual, if you use bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

I lost my will roll against placing another book order a couple of weeks ago. There are just too many people writing too many fascinating things that I want to read! Elizabeth Bear Shoggoths in Bloom (collection)
David Graeber Debt: The First 5,000 Years (non-fiction)
Eric Hobsbawm The Age of Revolution 1789 1848 (non-fiction)
China Mi ville Kraken (sff)
John McPhee Annals of the Former World (non-fiction)
C.E. Murphy The Queen's Bastard (sff)
C.E. Murphy The Pretender's Crown (sff)
Steven Pinker Words and Rules (non-fiction)
David Roodman Due Diligence (non-fiction)
Rebecca Skloot The Immortal Life of Henrietta Lacks (non-fiction)
Richard G. Wilkinson & Kate Pickett The Spirit Level (non-fiction)
Fumi Yoshinaga oku: The Inner Chambers #1 (graphic novel) As you can see, mostly non-fiction. Which is, of course, the type of book that takes the longest to read. I'm so smart about managing a backlog. The Pinker was recommended by one of my favorite Teaching Company courses (Myths, Lies, and Half-Truths of Language Usage by John McWhorter), and I was interested enough in linguistics to want to read something a bit more intensive. John McPhee's Annals of the Former World is about geology, something I've wanted to know more about for a while, and won the Pulitzer for general non-fiction. It's also huge. It might take me a while to get to that. Of the fiction, I read the first Murphy a long time back, but it was a borrowed copy, and I want to re-read it before reading the second volume in the duology. I remember really enjoying it, but don't remember anything about what happened. oku is manga that won the Tiptree award, so that sounded too interesting to pass up. And since I own just about everything else Elizabeth Bear has published, I figured I should keep the streak alive, even if I'm a bit behind on reading it.

No, FOSDEM is not over yet, even if that title might suggest otherwise. I've just arrived home from a very long day. It started this morning at around 9:00 AM, when I went to my office, where we did a few final tests on our video setup, after which we loaded everything up and drove to the ULB campus. Most of the rest of the day was lost to setting up stuff, and more testing. We were mostly ready around 21:00, but also mostly tired. Whatever was left was some stuff in rooms that would only open at 13:00; so we decided to call it a day. I then went to the beer event, for about an hour or so. Not because I wanted to get drunk, but because I wanted to meet a few people. That worked, although I suspect most people that I know had left already, because I didn't see many people. Right now, it's time for bed. With a healthy dose of work, some determination, and a little bit of luck, this weekend everything will run smoothly. See you then.

Well I m back from LCA 2013 and what a great week it was. I learnt plenty of things over the week, including:

• Cloud computing into the government will be coming but will be hard to do in a significant way
• It wasn t just me that found the GTK 2 to 3 API change hard going
• OpenStack is the next cool kid on the block and there is a lot going on here
• Try out novaprova for testing C programs
• SELinux shouldnt slow my computer down and yes ill try it soon
• git-annex looks very interesting, I m just trying to find a use-case for it for me
• The development methods for Free Software have come a long way since a decade ago
• Test and release processes are important on large software projects
• Pretty much everyone I knew has changed companies, at least once.
• For multi-process communication, 0mq looks interesting

It was great to actually meet people who I ve known for years (over 10 for some) only as emails or irc chats as well. I ve not been to Mount Stromlo for almost as long and its somewhere I d like to visit again. Argh, the wordpress editor is still not fixed

i have a colleague who is forced by work situations to use Windows. Somehow, I'm the idiot^W^W^W^W^Wfriendly guy who gets tapped to fix it when things break. Well, this time, the power supply broke. As in, dead, no lights, no fan, no nothing. No problem, though, the disk is still good, and i've got a spare machine lying around; and the spare is actually superior hardware to the old machine so it'll be an upgrade in addition to a fix. Nice! So i transplant the disk and fire up the new chassis. But WinXP fails to boot with a lovely "0x0000007b" BSOD. The internet tells me that this might mean it can't find its own disk. OK, pop into the new chassis' BIOS, tell it to run the SATA ports in "legacy IDE" mode, and try again. Now we get a "0x0000007e" BSOD. Some digging on the 'net makes me think it's now complaining now about the graphics driver. Hmm. Well, i figure i can probably work around that by installing new drivers from Safe Mode. So i reboot into Safe Mode. Success! It boots to the login screen in Safe Mode. And, mirabile dictu, i happen to know the Administrator password. I put it in, and get a message that this Windows installation isn't "activated" yet -- presumably because the hardware has changed out from under it. And by the way, i'm not allowed to log in via safe mode until it's activated. So please reboot to "normal" Windows and activate it first. Except, of course, the whole reason i'm booting into safe mode was because normal Windows gives a BSOD. Grrrr. Who thought up this particular lovely catch-22? OK, change tactics. Scavenging the scrap bin turns up a machine with a failed mainboard, but a power supply with all the right leads. It's rated for about 80W less than the old machine's failed supply, but i figure if i rip out the DVD-burner and the floppy drive maybe it will hold. Oh, and the replacement power supply doesn't physically fit the old chassis, but it hangs halfway out the back and sort of rattles around a bit. I sacrifice the rest of the scrap machine, rip out its power supply, stuff the power supply into the old chassis, swap the original disk back in, and ... it boots successfully, finally. That was the shorter version of the story :P So now my colleague has a horrible mess of a frankencomputer which is more likely to fail again in the future, instead of a nice shiny upgrade. Why? Because Microsoft's need to control the flow of software takes priority over the needs of their users. This is what you get when you let Marketing and BizDev drive your technical decisions. Do i still need to explain why i prefer free software? Tags: griping, windows