As many of you know, I ve been spending some time hacking on a Lisp variant that s fully hosted in Python. If you want to read more about it, check out the slides I prepared for Boston Python s meetup in particular, pay attention to the magic REPL . I ve been pondering what to do next, and the natural instinct is for me to take a step back, and properly implement a few things I ve forgotten. Namely: Macros. Yes. Macros. It s a Lisp without Macros. I ve hit a few stumbling blocks in it s implementation, and it s been holding me up. I m mostly concerned with how Hy should treat quoted forms, in particular I m concerned about loosing the distinction between a vector and a list, since both convert into Python lists. There is of course the option to encode Lists as:

 (list foo bar baz)

but that seems wrong. I ve also got some concerns about derefing values in a quoted form I think this is just going to result in a lot of special casing for Macros. More to come soon.

I ll forgive you for not noticing the bus full of pirates at the Superbowl. Because, well, unless you saw my 6-year-old, you have a pretty good excuse for missing it. I ll give you the Goerzen Superbowl play-by-play, just to make sure you re caught up. It involved pirates, cops, tractors, cookies, a card game, and yes, even troubles with HDMI. We were invited to a Superbowl party, and were going to bring a party snack. The boys love to help cook, and I try to give them choices. I started naming off potential snacks, starting with healthy options. They listened attentively, until I mentioned cookies. COOKIES! ***COOKIES!*** Yes, cookies! This reaction was, I must say, not exactly a surprise. Then I asked them what KIND of cookies. Jacob immediately knew what he wanted, so of course Oliver took a minute to come up with something else. No matter; we could make two kinds of cookies. Jacob, of course, picked a kind of cookie that needs cherries, while Oliver picked one that needs chocolate chips. Thus they both had opportunities to have a small taste of ingredients while we prepared the batter. And so make cookies we did. Plus a loaf of bread. Anyhow, once we got to the party, Jacob and Oliver saw a huge tub of Legos and were at it in a flash. One of Jacob s friends was pretending everything was a tractor, but it wasn t long before Jacob started in on his evening s project: building the largest bus he could build. He was pleased when he got 4 lego people into it. Even more happy when he got 10 into it. And by the time he figured out how to get 35 into it, he was quite proud of himself indeed. Oliver, meanwhile, in classic little brother fashion, tried to corner the market on surplus lego people. He appears to have the hardline negotiation skill down already, and perhaps is appreciating the value of artificial scarcity in the lego market <grin> Eventually the bus seemed to hit the limits of engineering and joint strength, and Jacob gave up for a little while. He had a cookie and some carrots, commented on the exciting game of Uno going on, ( Who is the loudest? All of them! ), brought me some carrots, and periodically commented that The ball team is ahead of the SF team. Sure is. They have more points! (This from the BAL and SF text on the screen.) And then he went back to playing. And here s where the pirates come in. Jacob s new bus had a lego flag that he decided was a pirate flag. So the bus was a pirate bus. He built a platform out the back for them to use to steal things . So his pirate bus went around the lego area, stealing this from one pile, stealing that from another, until it got almost as long as his first bus. Pretty soon, along came a police boat to chase the pirates. But the police boat appeared to suffer a humorous series of logistical failures and never could quite disrupt the pirates. But never mind that, for little brother Oliver was getting bored with the lego mountain he was building and decided it would be more fun if he would disrupt the pirates. An opinion that Jacob quite strongly disagreed with. When it was time to go, Jacob tried to extract a promise from the party hosts to not let anyone take apart the pirate bus until next time we would be there. Then this morning, Jacob and I had a discussion about pirates. Dad, are pirates real? Yes, Jacob, they are. Do they steal things? Yes, but they are far away. There are no pirates here. Are there pirates in Kansas? No. There are some pirates in Africa though. Oh. What state is Africa in? Africa is so far away that it isn t even in a state. You d have to take a boat or a plane to get there. Or a train! Nope, a train couldn t get across the ocean. It s too wide! They d build a bridge! It s too wide for a bridge. It s more than a thousand miles! WOW a thousand miles! Great! OK dad, it s time for me to get on that school bus!

(This rant was originally part of the live streaming series, but I moved it to a separate article because people got stuck on it instead of responding to the actual subject of the article.) Before I get flamed for attacking Pulseaudio (PA), let's just settle this: I don't like it. I think PA is over-engineered and tries to do too many things at once. I used to (until just now) systematically purge pulseaudio-related packages from my system, mainly because PA has this awful tendency of automatically starting and staying around eternally, which wouldn't be so bad except PA has also the bad habit of hogging the audio device exclusively, which makes regular programs like mplayer, ogg123 fail to simply play audio, unless they go through the PA straight-jacket. (Update: this seems to be a bit better in newer versions of PA, where the audio device is released when sound is not being played. Thanks Philipp Kern for the correction.) In the GNU/Linux audio stack, we already have another system that supports multiple accesses: ALSA itself, so I believe that PA should at least behave nicely to other apps, and it seems I am always having problems with that. (The fact that ALSA itself is over-engineered is also telling of the poor state of the audio stack in GNU/Linux.) The other beef I have with PA is the Not Invented Here syndrome: instead of extending existing tools like ALSA or Jack, people just figured they could do everything better and start from scratch. So now we just have one more "standard" way of playing audio, good job Lennart.

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.

A good three weeks ago, we introduced the Rcpp Gallery. While this is a joint effort by several of us on the Rcpp team, the backend was conceived and implemented entirely by JJ who also bootstrapped it with same first content, drawing on posts by Hadley, Romain and myself. As the How to contribute page makes plain, this is all backed by GitHub and all logs are public anyway. So after it was up and working, JJ and I refined the look and feel, and I started to add more content so that would have something by the time the initial announcement came around. A few years I read about an (attributed) secret to Seinfeld's producitivity: "Don't break the chain". Just keep writing, and write every day. I made my goal of a post every day for just over a month, and created this sequences: <quote> (20 Dec) simulating-pi, (21 Dec) vector-minimum, (22 Dec) gsl-colnorm-example, (23 Dec) fibonacci-sequence, (24 Dec) random-number-generation, (25 Dec) armadillo-sparse-matrix, (26 Dec) timing-rngs, (27 Dec) stl-inner-product, (28 Dec) stl-transform, (29 Dec) stl-transform-for-subsetting, (30 Dec) stl-random-shuffle, (31 Dec) stl-random-sample, (01 Jan) stl-for-each, (02 Jan) armadillo-subsetting, (03 Jan) accessing-environments, (04 Jan) armadillo-eigenvalues, (05 Jan) r-function-from-c++, (06 Jan) using-the-rcpp-timer, (07 Jan) sugar-function-clamp, (08 Jan) using-rcout, (09 Jan) first-steps-with-C++11, (10 Jan) simple-lambda-func-c++11, (11 Jan) eigen-eigenvalues, (12 Jan) getting-attributes-for-xts-example, (13 Jan) intro-to-exceptions, (14 Jan) a-first-boost-example, (15 Jan) a-second-boost-example, (16 Jan) timing-normal-rngs, (17 Jan) creating-xts-from-c++, (18 Jan) gsl-for-eigenvalues, (19 Jan) accessing-xts-api, (20 Jan) custom-as-and-wrap-example, (21 Jan) passing-cpp-function-pointers, </quote> The Rcpp Gallery continues to grow, we now have 58 posts from 7 different authors. And it is open for business: new contributions are always welcome.

this week's report comes live from FOSDEM; which doesn't mean I've been doing any RC bug work here, I've looked at all the mentioned bugs below earlier this week. & as you can see, most was just a bit triaging

• #698631 typo3: "typo3: copyright file missing after upgrade (policy 12.5)"
  replace directory with symlink in postinst, upload to DELAYED/5
• #699252 src:ldiskfsprogs: "ldiskfsprogs: FTBFS: build-dependency not installable: lustre-dev"
  add some info to the bug report, then removed from testing
• #699254 src:libpdfbox-java: "libpdfbox-java: FTBFS: cp: missing file operand"
  replace removed packages with poppler-data in Build-Depends-Indep
• #699255 src:ruby-activeresource-2.3: "ruby-activeresource-2.3: FTBFS: test_load_yaml_array(BaseTest) fails"
  tag confirmed
• #699256 src:cglib: "cglib: FTBFS: 1) testFailOnMemoryLeak(net.sf.cglib.proxy.TestEnhancer)junit.framework.AssertionFailedError: Memory leak caused by Enhancer"
  investigate and tag unreproducible
• #699258 src:libio-async-loop-glib-perl: "libio-async-loop-glib-perl: FTBFS: test failed"
  confirm and forward upstream
• #699259 src:gnuradio: "gnuradio: FTBFS: XML parsing error"
  tag unreproducible
• #699261 src:dhelp: "dhelp: FTBFS: build-dependency not installable: libgettext-ruby-util"
  prepare patches
• #699263 src:pspp: "pspp: FTBFS: 293. expressions - datediff (evaluate.at:1560): FAILED (evaluate.at:1560)"
  tag confirmed

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:

Today we where packing back our holiday decorations into boxes. We also had a music box to put away. Do you see the defect in the picture? ;) No? Okay ... some years ago my oldest daughter broke it into some pieces and a friend of us (Hi muempf! ;) did glue all together. When he showed us the nice music box, it was recovered very well, but one detail was changed from original. One horseman wasn't reassembled as the other onces. If you you didn't found the defect, please have a look here. You had fun with this? Maybe this is another one for you, I took that photo on christmas eve when my youngest daughter had placed her new 'Lisa Plastic': Keep smiling!

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.

A pure maintenance release 0.1.6 of RcppExamples was made two weeks ago, and never announced. We merely moved the NEWS.Rd file into the proper location in the inst/ directory, and, while were at it, mentioned the new Rcpp Gallery in the DESCRIPTION file. Thanks to CRANberries, there is the standard diff to the previous release 0.1.5. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

digest version 0.6.2 came out a few days ago as an almost immediate follow-up to release 0.6.1. We used paste0() in a few places, and this is only available with newer versions of R. To not introduce as somewhat unnessecary dependency, we reverted this to plain old paste(). CRANberries provides the usual summary of changes to version 0.6.1. As usual, our package is available via the R-Forge page leading to svn and tarball access, my digest page, the local directory here as well as via Debian and its mirrors.

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

Today short before ending business hours I was noticed that there is a problem with a server system (domU). Login with unprivileged user was possible but using "su" didn't worked, also login in as root via privkey failed. Fortunately I was able to connect via xen console and login via tty. Looking into the bash history the reason revealed quickly:

4979 2013-02-01 15:03:39 cd /var/www/test.org/data/galleries/
4980 2013-02-01 15:03:43 chown www-data:www-data -R /var/www/test.org/data/galleries/
4981 2013-02-01 15:04:36 ls -la
4982 2013-02-01 15:04:46 ls -la
4983 2013-02-01 15:04:54 chown www-data:www-data -R /*
4984 2013-02-01 15:07:42 chown www-data:www-data -R /var/www/test.org/data/galleries/
4985 2013-02-01 15:36:55 chown www-data:www-data -R /var/www/test.org/data/galleries/

This made my day (and maybe parts of the rest of the weekend). For recovery our 1st Level mounted the domU-fs on the dom0 to '/tmp/recover' and did:

2131  2013-02-01 21:29:28 cd /tmp/recover
[...]
2142  2013-02-01 21:31:17 rm -r lib64/

The experienced reader may see the problem:

# ls -lad lib64
lrwxrwxrwx 1 root root 4 Jun 28  2011 /lib64 -> /lib

So also the dom0 was knocked out ... what a funny evening (and maybe night). Maybe our staff looked similar like here.