Debian Edu / Skolelinux keep gaining new users. Some weeks ago, a person showed up on IRC, #debian-edu, with a wish to contribute, and I managed to get a interview with this great contributor Roger Marsal to learn more about his background. Who are you, and how do you spend your days? My name is Roger Marsal, I'm 27 years old (1986 generation) and I live in Barcelona, Spain. I've got a strong business background and I work as a patrimony manager and as a real estate agent. Additionally, I've co-founded a British based tech company that is nowadays on the last development phase of a new social networking concept. I'm a Linux enthusiast that started its journey with Ubuntu four years ago and have recently switched to Debian seeking rock solid stability and as a necessary step to gain expertise. In a nutshell, I spend my days working and learning as much as I can to face both my job, entrepreneur project and feed my Linux hunger. How did you get in contact with the Skolelinux / Debian Edu project? I discovered the LTSP advantages with "Ubuntu 12.04 alternate install" and after a year of use I started looking for an alternative. Even though I highly value and respect the Ubuntu project, I thought it was necessary for me to change to a more robust and stable alternative. As far as I was using Debian on my personal laptop I thought it would be fine to install Debian and configure an LTSP server myself. Surprised, I discovered that the Debian project also supported a kind of Edubuntu equivalent, and after having some pain I obtained a Debian Edu network up and running. I just loved it. What do you see as the advantages of Skolelinux / Debian Edu? I found a main advantage in that, once you know "the tips and tricks", a new installation just works out of the box. It's the most complete alternative I've found to create an LTSP network. All the other distributions seems to be made of plastic, Debian Edu seems to be made of steel. What do you see as the disadvantages of Skolelinux / Debian Edu? I found two main disadvantages. I'm not an expert but I've got notions and I had to spent a considerable amount of time trying to bring up a standard network topology. I'm quite stubborn and I just worked until I did but I'm sure many people with few resources (not big schools, but academies for example) would have switched or dropped. It's amazing how such a complex system like Debian Edu has achieved this out-of-the-box state. Even though tweaking without breaking gets more difficult, as more factors have to be considered. This can discourage many people too. Which free software do you use daily? I use Debian, Firefox, Okular, Inkscape, LibreOffice and Virtualbox. Which strategy do you believe is the right one to use to get schools to use free software? I don't think there is a need for a particular strategy. The free attribute in both "freedom" and "no price" meanings is what will really bring free software to schools. In my experience I can think of the "R" statistical language; a few years a ago was an extremely nerd tool for university people. Today it's being increasingly used to teach statistics at many different level of studies. I believe free and open software will increasingly gain popularity, but I'm sure schools will be one of the first scenarios where this will happen.

Whups, I seem to have built a configuration management system this evening! Propellor has similar goals to chef or puppet or ansible, but with an approach much more like slaughter. Except it's configured by writing Haskell code. The name is because propellor ensures that a system is configured with the desired PROPerties, and also because it kind of pulls system configuration along after it. And you may not want to stand too close. Disclaimer: I'm not really a sysadmin, except for on the scale of "diffuse administration of every Debian machine on planet earth or nearby", and so I don't really understand configuration management. (Well, I did write debconf, which claims to be the "Debian Configuration Management system".. But I didn't understand configuration management back then either.) So, propellor makes some perhaps wacky choices. The least of these is that it's built from a git repository that any (theoretical) other users will fork and modify; a cron job can re-make it from time to time and pull down configuration changes, or something can be run to push changes. A really simple configuration for a Tor bridge server using propellor looks something like this: Since it's just haskell code, it's "easy" to refactor out common configurations for classes of servers, etc. Or perhaps integrate reclass? I don't know. I'm happy with just pure functions and type-safe refactorings of my configs, I think. Properties are also written in Haskell of course. This one ensures that all the packages in a list are installed. Here's one that ensures the hostname is set to the desired value, which shows how to specify content for a file, and also how to run another action if a change needed to be made to satisfy a property. Here's part of a custom one that I use to check out a user's home directory from git. Shows how to make a property require that some other property is satisfied first, and how to test if a property has already been satisfied. I'm about 37% happy with the overall approach to listing properties and combining properties into larger properties etc. I think that some unifying insight is missing -- perhaps there should be a Property monad? But as long as it yields a list of properties, any smarter thing should be able to be built on top of this. Propellor is 564 lines of code, including 25 or so built-in properties like the examples above. It took around 4 hours to build. I'm pretty sure it was easier to write it than it would have been to look into ansible and salt and slaughter (and also liw's human-readable configuration language whose name I've forgotten) in enough detail to pick one, and learn how its configuration worked, and warp it into something close to how I wanted this to work. I think that's interesting.. It's partly about NIH and I-want-everything-in-Haskell, but it's also about a complicated system that is a lot of things to a lot of people -- of the kind I see when I look at ansible -- vs the tools and experience to build just the thing you want without the cruft. Nice to have the latter!

With the release of GNOME-Software 3.12, it s also time for another update about what is going on behind the scenes of Appstream, the project providing all the data needed to make software-centers work. So here is the long overdue update If you have attended my FOSDEM talk or seen the slides, you know about the concept of component metadata to describe (almost) all software components which make up a Linux system, as well as their public interfaces they provide for users and other software to access. This metadata specification was originally designed as part of the Listaller project for use with the 3rd-party software installer.
But we already have the Appstream specification, which describes applications available on a distribution. And technically, applications are nothing but specialized components.
When I was asked about extending the Appstream spec with fonts and codecs, I decided to give up the Listaller components concept and merge it with the Appstream project, effectively creating a single source of metadata for all software in distributions. Appstream and components were separate, because Appstream was designed just for application metadata shown in software-centers, while component-metadata was more technical and not user-visible. This separation, however, did not reflect reality. Software centers want to show things components were designed for (codecs, fonts, ), and application meta-information also can contain technical items not shown in a software-center, but useful for other functionality (e.g. for mimehandler finding). So, if you like clear naming of things (like I do), you can now think of the upcoming Appstream release 0.6 as Appstream not being a stream of application metadata, but rather metadata provided for use in applications. Extending Appstream with components has a number of benefits:
First of all, users will soon get systems which are able to automatically install missing firmware, codecs, fonts and even libraries or Python-modules. This happens in a distro-agnostic way, so any application can request installations of missing components through Appstream and PackageKit without having to care about distribution details. For distributors, you will get more information about the software upstream provides: Which public interfaces does it make available? What is the upstream s homepage? Summary? Short release-descriptions? Exposed library symbols? etc. This data was available before, of course, but we made it machine-readable and standardized now. This will also allow us to match software across distributions quickly, allowing efficient exchange of patches between distributions, and answering questions upstream has like in which distribuions is my software available, and in which version? . Tracking upstream software is also easier now. Last but not least, the metadata format gives upstreams a small say in how their software gets packaged (= how it gets split / if there is a metapackage depending on the split parts). For upstream authors, it is much easier to maintain just a few Appstream XML metafiles, instead of adding a Listaller component file as well (which was not XML). Most data for creating the metainfo files is already available, some can even be filled in automatically by the build-system. With all the advantages this new system has comes a small disadvantage: These changes broke the backwards-compatibility of the Appstream spec, so to use Appstream data in version 0.6 or higher, you need to adjust your parsers. But of course you are using a library to access the data anyway, which already does that for you GNOME-Software 3.12 has almost complete support for the new (but still not released) Appstream 0.6 spec through it s libappstream-glib library. The libappstream library in Appstream s Git branch will get 0.6 support as well very soon. The only thing you need to do is adjust your code for the new library version, which broke it s API as well due to a rewrite in C (I hope that we can provide language bindings again very soon).
Soon, there will also be a Qt library for accessing Appstream, since some people expressed a demand for it (and working with GObject in Qt C++ code always feels a litle bit odd).
The 0.6 specification is still being fine-tuned to iron out some issues which might come up and mainly to improve the documentation and adjust all tools. It will be released in 2-3 weeks, and bring not only components support, but also lots of other small improvements and additions for better description of applications/components. In some cases, tag names have changed to have less ambiguous names. Thanks to Richard Hughes for helping with the spec our discussions about the Appstream spec are highly productive and in the end lead to a better specification. Also, the new 0.6 specification includes many extensions used in GNOME-Software by default now, which makes it easier for other distributions to provide them for GS. The current draft for the Appstream 0.6 specifications can be found here. Some details might still change before the final release. As soon as the spec is final, there will be a ML announcement for distributors as well (watch the XDG distributions list), so there is enough time for distributors to future-proof their Appstream distro-data generators (I will also describe the changes more detailed then). If you are confused now about the whole components stuff: Fear not! I will do some more detailed posts in a few weeks explaining upstream projects how to provide metadata properly (after the 0.6 release). I will also finish the wiki page for Appstream AppData in KDE projects, where we can then use 0.6-style data in KDE right away.

Since I have to do a lot of backports for the OpenStack packages in Debian Wheezy, I got tired of doing them by hand. Therefore, I have created a script to automate the task. I m not particularly proud (or ashamed) of that script, but I just want to share it. Probably some fellow readers will happily provide me with enhancements and ideas. Note that the use of mk-build-deps implies that the equivs package has to be installed. What I do is run this build-backport script within a cowbuilder, to make sure I always have a clean backport environment.

#!/bin/sh
set -e
set -x
PKG_NAME=$ 1 
BPO_DISTRO=wheezy-backports
BPO_POSTFIX=bpo70+1
REPO_ROOT=/home/ftp
REPO_DEST=icehouse-backports
if [  whoami  = "jenkins" ] ; then
        BUILD_ROOT=/var/lib/jenkins/jobs/openstack-pkg-tools/builds/$ BUILD_NUMBER 
else
        BUILD_ROOT=~/sources
fi
# Get info from packages.debian.org
PKG_INFO_FILE= mktemp -t pkg_info_file.XXXXXX 
wget --no-check-certificate -O $ PKG_INFO_FILE  http://packages.debian.org/sid/$ PKG_NAME 
DEB_VERSION= rmadison $ PKG_NAME    grep sid   awk ' print $3 ' 
UPSTREAM_VERSION= echo $ DEB_VERSION    cut -d'-' -f1    cut -d":" -f2 
DSC_URL= cat $ PKG_INFO_FILE    grep dsc   cut -d'"' -f2 
rm $ PKG_INFO_FILE 
# Prepare build folder and go in it
MY_CWD= pwd 
rm -rf $ BUILD_ROOT /$PKG_NAME
mkdir -p $ BUILD_ROOT /$PKG_NAME
cd $ BUILD_ROOT /$PKG_NAME
# Download the .dsc and extract it
dget -d -u $ DSC_URL 
PKG_SRC_NAME= ls *.dsc   cut -d_ -f1 
PKG_NAME_FIRST_CHAR= echo $ PKG_SRC_NAME    awk ' print substr($0,1,1) ' 
dpkg-source -x *.dsc
echo "Now running mk-build-deps -i $ PKG_SRC_NAME -$ UPSTREAM_VERSION /debian/control"
mk-build-deps -i $ PKG_SRC_NAME -$ UPSTREAM_VERSION /debian/control
# Build the package as backport using cowbuilder
cd $ PKG_SRC_NAME -$ UPSTREAM_VERSION 
dch --bpo -m "Backported for $ BPO_DISTRO ."
dpkg-buildpackage
cd ..  
PKG_FINAL_DEST=$ REPO_ROOT /debian/pool/$ REPO_DEST /main/$ PKG_NAME_FIRST_CHAR /$ PKG_SRC_NAME 
ssh archive.gplhost.com "mkdir -p $ PKG_FINAL_DEST "
scp *.orig.tar.* *$ DEB_VERSION ~$ BPO_POSTFIX * archive.gplhost.com:$ PKG_FINAL_DEST 

There is a rather infamous multilingualisation bug in almost every screen reader I have ever used. As a german native speaker, I usually set my operating system user interface language to german. However, since I do a lot of technical work, I frequently end up on english websites. But if I temporarily switch my speech synthesis language to english, certain user interface elements and key names are not translated! So the screen reader continues to say "Eingabe" or "Leertaste", but with an english accent! I consider this behaviour hilarious, especially in 21st century. To demonstrate how hilarious it actually is, I have made a little browser audio game. Voice snippets have been contributed by my girlfriend. A natural voice is still a lot better than sampled speech synthesizers, and sounds more fun as we think. The idea is simple: Angela will announce a key name, and you are supposed to hit it on the keyboard as fast as possible. After a round of 50 guesses (time to answer will decrease with every guess) a final score will be announced. I usually don't write any JavaScript. I still managed to hack this up (with a little help from Simon) in roughly 2 hours of browsing Stackoverflow. The game is here. The code is on GitHub. If you have any problems getting this to work, please let me know or send a pull request. I'd like to get it working at least on iOS as well (after all, it is the touch device platform with best accessibility support currently), however, I could not get mobile safari to behave. So patches to enable use on touch devices are welcome. It should be simple, just add a few buttons which call the pressed function with the appropriate character as parameter. However, I tried, and something is fishy regarding window.setTimeout since it does not behave the same way as if you use it with Firefox. Oh, and my favourite key name is "Runt Glamour Zoo" :-) Now, this was funny. But it is also very sad. If you play this game, remember that blind and visually impaired computer users really have to cope with such accented pronounciations on a daily basis. We grew used to it, but if I take a step backward, it's really unacceptable that we still have to cope with this daily. And this is the simple part of the bug, since it is only dealing with key labels, which are internal to the system. It gets much worse if you want your screen reader to automatically switch to the correct synthesis language. Language detection is apparently not good enough to be implemented, at least that's what they tell me. And if the document (HTML) specifies a language, it's wrong in more than 50% of the cases. This is a disaster. Come to think of it, that is probably a reason why I prefer braille over speech. With braille, this problem goes away completely.

Recently I ve been doing some hacking for Chamilo LMS, a Free Software E-Learning system. For various reasons I had to do this on OSX, which meant setting up a web development environment. This lead me to MAMP, an OSX bundle with Apache + MySQL + PHP. However MAMP had many weird quirks that forced me to maintain a local set of patches just to get things working. I finally had the time to look into a saner option, take some notes in the process, and write a blog post. A popular alternative was using OSX s installed Apache with a newer PHP version from Homebrew. This sounded dangerous because you can t just apt-get install --reinstall apache if you break something. I preferred a pure Homebrew installation also because:

• No need for root. Everything is user writable in /usr/local.
• Vanilla versions for everything, and easy to keep up to date with upstream.
• Easy to destroy and replicate.
• Usable, non root, PEAR.
• You would brew most of this for a hybrid setup anyway.

I couldn t find a simple and straightforward resource for this specific setup, so I present you with my tutorial/recipe to get Apache + MySQL + PHP, via Homebrew, running on OSX. I took these notes on OSX 10.7.5 while building Apache/2.2.26 (Unix) with PHP 5.5.10 and MySQL 5.6.16. #1- A healthy Homebrew install First of all you need to install Homebrew. Head over to Homebrew s homepage for instructions. Even if you already have it, I recommend a health check and an update+upgrade: $ brew doctor
$ brew update && brew upgrade Pay attention to whatever that says and follow the instructions if there s any. You also want to add Homebrew binary paths to your $PATH, even if the directories don t exist yet. Add this to .bash_profile or whatever your shell uses:
PATH=/usr/local/opt/php55/bin/:/usr/local/sbin:/usr/local/bin:$PATH #2- PHP and all its additional recipes The PHP recipes are maintained in a different repo, but don t worry, this is not a duct taped chaos, it s properly maintained: $ brew tap jgonzales/php
$ brew install php55 --with-intl You might want to add --with-pgsql if you want to work with PostgreSQL. MySQL, Apache and CLI support is built by default. After the installation there are two quick things to do. First, timezone configuration:
(editing /usr/local/etc/php/5.5/php.ini)
date.timezone = America/Lima (or whatever works for you) And second, PEAR permissions:
$ chmod -R ug+w /usr/local/Cellar/php55/5.5.10/lib/php #3- Setting up boring MySQL Now let s brew MySQL:
$ brew install mysql With that done, go ahead and start the server so we can initialize the basic tables, and secure the installation defaults:
$ unset TMPDIR
$ mysql_install_db --verbose --user= whoami --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp
$ mysql.server start
$ mysql_secure_installation

Remember: You shouldn t use sudo, so be careful with your muscle memory! #4- Brewing Apache (httpd) And finally, it s time to brew Apache. You can do so with:
$ brew install httpd When that s done burning your lap, you can start configuring Apache. I chose to keep httpd.conf as pristine as possible and do everything in a VirtualHost. Remember you need to run this on something other than port 80 because you won t run httpd as root:

• httpd.conf changes in a GitHub gist (diff)
• httpd-vhosts.conf is in this other GitHub gist (full file)

Note that I m enabling virtual hosts and using my own paths. If you want to configure Apache differently, you probably know what you are doing. So, get off my lawn you damn kid. #5- Brownie points: PHPMyAdmin In my virtual hosts configuration I included some lines for PHPMyAdmin. That s because I m old school and I love PHPMyAdmin. You can follow into my wrinkled foot steps with:
$ brew install phpmyadmin #6- Profit You can check everything is fine by creating an index.php with a call to phpinfo() inside your configured root from httpd-vhosts.conf. Make sure OSX s Apache is not running and start (or restart) the servers:
$ apachectl start/stop/graceful(restart)
$ mysql.server start/stop/restart Now open go to http://localhost:8000/ and http://localhost:8000/phpmyadmin. Enjoy your success. Maybe do a victory dance: This might seem like a lot of work, but it s fairly quick with this cheat sheet. It s also very safe and easy to keep updated with brew update && upgrade. A final note: All the suggestions and instructions that are printed after installing each package can be read again with brew info <recipe>. No need to write them down. Happy hacking!

My yoga teacher was out sick this morning. I had grand plans of instead biking to the pool and going for a swim, but when my alarm went off, and the weather outside was grey and miserable, having an extra half an hour lie in seemed more attractive. I think I made the right choice, because I felt like a million bucks today. I did all of the preparation to bake a batch of carrot and kale muffins before Zoe arrived, and we baked a batch as soon as she arrived and had them out of the oven in time to drive to Playgroup. I was expecting a larger crowd today on account of the wet weather, but it turned out quite the opposite. That said, Zoe still had a good time. There's really no other kids her age though, so it's still winding up as a "play with Dad in a different environment". My ABN came through yesterday, so after Playgroup we walked to the bank to give it to them and sort out a business credit card. Zoe was super well behaved while I did that, so we grabbed a fresh hot cross bun from Brumby's across the street afterwards. I needed some more stamps, so I figured we could just walk down to the post office down the other end of Oxford Street while we were there. That was slow going, but Zoe was enjoying walking with her umbrella in the rain. We got to the post office, and I discovered that postage is going up to 70 cents next week, and they couldn't sell be 70 cent stamps yet, and buying 60 cent stamps would be pointless after Monday, so I left empty handed. Zoe was eyeing off the umbrellas they had for sale in the post office. No sooner had we walked out of the post office and Zoe managed to walk all over her umbrella and totally destroy it. If I hadn't seen it happen, I'd have said she did it deliberately to get a new umbrella, but it really was an accident, so we had to turn around and buy one of the umbrellas from the post office. We made our way back down Oxford Street, and stopped in the boutique toy shop there. Zoe was particularly enthralled by the musical jewelery boxes, and really wanted one. I negotiated with her for it to be a birthday present, and got it gift wrapped. She seemed fine with the idea of not being able to have it until her birthday. We then made our way back to the car and drove home for a rather late lunch. I'm glad Zoe had the hot cross bun after the bank to keep her going, as she didn't seem to mind the late lunch at all. I made fritters with some left over corned beef, and then after we'd had lunch I thought we might as well get out of the house. Zoe's Kindergarten has a working bee on Saturday (I'm expecting it'll get canceled due to the wet weather, though). Incidentally, I have no idea where the "bee" in "working bee" comes from. Megan's Dad is Welsh, and I was lost for words when it came to explaining what a working bee was. Anyway, I wanted to get some gardening gloves, so we went to Bunnings. I managed to find some cute little kids ones as well, so Zoe can help. After Bunnings, we went to the pet shop to get some more cat litter. The pet shop seems to be a great source of entertainment for Zoe. She absolutely loved playing around with the hutches they had on display, and checking out all the fish, and the aquarium accessories. We eventually made it out of the pet shop, and we went around to the adjacent shopping mall in search of some craft supplies at some of the cheap shops there. It turns out the cheap shops are also a great source of entertainment. By the time we were done there, it was time to get home so Sarah could pick Zoe up, so we headed home. There was enough time for Zoe to watch a little bit of TV before Sarah arrived. So despite the weather, and no real plan for the day, we managed to completely fill the day, and Zoe had a great time. She seemed no worse for wear for powering through without a nap. There was a few small tantrums at Bunnings, but that mostly revolved around her tipping over her miniature shopping trolley.

I am often asked about my accent . The most common guess is that it s a British accent, while I lived in London for about a year I don t think that my accent changed much during that time (people have commented on the way I speak since I was in primary school). Also there isn t a British accent anyway, the Wikipedia page of Regional Accents of English has the first three sections devoted to accents in the island of Britain (and Northern Ireland is part of the United Kingdom which people often mean when they sat Britain ). The Received Pronounciation is the main BBC accent and the accent that is most associated with Britain/England/the UK (which are three different things even though most people don t know it) and I don t think that I sound like that at all. I ve had various other guesses, the Netherlands (where I lived for a few years but mostly spoke to other foreigners), New Zealand (which I ve visited a couple of times for conferences), Denmark (the closest I got was attending a conference in Sweden), and probably others I can t remember. If I actually had developed an accent from another country then it would probably be from the US. The amount of time I ve spent watching Hollywood movies and watching US TV shows greatly exceeds the amount of time I ve spent listening to people from all other countries. The fact that among all the people who wanted to try and guess where my accent supposedly originated none have ever included the US seems like strong evidence to suggest that I don t have any sort of accent that really derives from another country. Also I have never had someone mistake me for being a resident of their own country based on accent which seems like clear evidence that all claims about me having a foreign accent are bogus. Autism forums such as WrongPlanet.net [1] always turn up plenty of results for a search on accent . In such discussions it seems that a British accent is most common mistake and there are often theories raised about why that is often related to speaking in a formal or precise way or by using a large vocabulary. Also in such discussions the list of countries that people supposedly have accents from is very inclusive, it seems that any country that the listener has heard of but doesn t know that well is a good candidate. The fact that Aspies from outside the US are rarely regarded as having an American accent could be due to the fact that Hollywood has made most of the world population aware of what most American accents sound like. Also if I really had some sort of accent from another country then probably someone would comment on that when I m outside Australia. When I m travelling people tend to recognise my accent as Australian, while it doesn t please me when someone thinks that I sound like Crocodile Dundee (as happened in the Netherlands) it might not be entirely inaccurate. This is Annoying The way the issue of accent is raised is generally in the form of people asking where I m from, it seems to imply that they don t think I belong in Australia because of the way I speak. It s particularly annoying when people seem unable to realise that they are being obnoxious after the first wrong guess. When I reply no to the first are you from $COUNTRY question and don t offer any further commentary it s not an invitation to play 20 questions regarding where I m supposedly from, it s actually an indication that I m not interested in a conversation on that topic. A Social Skills 101 course would include teaching people that when someone uses one-word answers to your questions it usually means that they either don t like your questions or don t want to talk to you. Social Skills vs Status The combination of persistence and misreading a social situation which are involved when someone interrogates me about my supposed accent are both parts of the diagnostic criteria for Autism. But I generally don t get questions about my accent in situations where there are many Aspies (IE anything related to the Free Software community). I think that this is because my interactions with people in the Free Software community are based around work (with HR rules against being a jerk) and community events where no-one would doubt that I belong. I mostly get questions about my accent from random middle-class white people who feel entitled to query other people about their status who I meet in situations where there is nothing restraining them from being a jerk. For example random people I meet on public transport.

• [1] http://www.wrongplanet.net/

Packaging LAVA for Debian unstable with notes on other distributions I ve been building packages for LAVA on Debian unstable for several months now and I ve been running LAVA jobs on the laptop and on devices in my home lab and on an ARMv7 arndale too. Current LAVA installations use lava-deployment-tool which has only supported Ubuntu 12.04 LTS Precise Pangolin. There has been a desire in LAVA to move away from a virtual environment, to put configuration files in FHS compliant paths, to use standard distribution packages for dependencies and so to make LAVA available on more platforms than just precise. Packaging opens the door to installing LAVA on Debian, Ubuntu, Fedora and any other recent distribution. Despite LAVA currently being reliant on 12.04 Precise, some of the python dependencies of LAVA have been able to move forward using the virtual environment provided by builtout and pypi. This means that LAVA, as packaged, requires a newer base OS suite than precise for Ubuntu, the minimal base is Saucy Salamander 13.10 and for Debian it would be Jessie (testing) although there is currently a transition ongoing in Debian which means that uwsgi is not in testing and Debian unstable would be needed instead. The work to migrate configuration snippets out of deployment-tool and to ensure that the tarball built using setuptools contains all of the necessary files for the package has already been done. The packaging itself is clean and most of the work is done upstream. There is, as ever, more to do but the packages work smoothly for single install LAVA servers where the dispatcher is on the same machine as the django web frontend. The packages have also migrated to Django1.6, something which is proving difficult with the deployment-tool as it has not kept pace with the changes outside the virtual environment, even if other parts of LAVA have. LAVA will be switching to packages for installation instead of deployment-tool and this will mean changes to how LAVA works outside the Cambridge lab. When the time comes to swich to packaging, the plan is to update deployment-tool so that it no longer updates /srv/lava/ but instead migrates the instance to packages. Main changes

1. Configuration files move into /etc/
   • Device configuration files /etc/lava-dispatcher/devices/
   • Instance configuration files/etc/lava-server/
2. Log files move into /var/log/
   • Adding logrotate support no more multi-Gb log files in /srv/lava/
3. Commitment to keeping the upstream code up to date with dependencies
4. Support for migrating existing instances, using South.
5. Packaging helpers
   • add devices over SSH instead of via a combination of web frontend and SSH.
   • Developer builds with easily identifiable version strings, built as packages direct from your git tree.
6. New frontend
   • Although django1.6 does not change the design of the web frontend at all, LAVA will take the opportunity to apply a bootstrap frontend which has greater support for browsers on a variety of devices, including mobile. This also helps identify a packaged LAVA from a deployment LAVA.
7. Documentation and regular updates

The Plan LAVA has made regular releases based on a monthly cycle and these will be provided as source tarballs at http://www.linaro.org/downloads/ for distributions to download. The
official monthly release and any intervening updates will be made available for distributions to use for their own packaging. Additionally, Debian packages will be regularly built for use within LAVA and these will be available for those who choose to migrate from Ubuntu Precise to Debian Jessie. LAVA will assist maintainers who want to package LAVA for their distributions and we welcome patches from such maintainers. This can include changes to the developer build support script to automate the process of supporting development outside LAVA. Initially, LAVA will migrate to packaging internally, to prove the process and to smooth out the migration. Other LAVA instances are welcome to follow this migration or wait until the problems have been ironed out. The Issues

• Remote workers this is work to be completed during the migration to packaging within LAVA as well as pending work upstream on the internals of the connection between a remote worker and the master scheduler. Expect some churn in this area whilst the code is being finalised. A lava-worker package is being prepared which borrows enough code from lava-server to run the lava-scheduler-daemon on the remote worker, until such time as the remote worker communications are refactored.
• Integration there are plans to integrate some of the modules which LAVA uses which are not commonly packaged: linaro-dashboard-bundle and linaro-django-xmlrpc
• OpenID the certificates which underpin OpenID use with Launchpad have been removed in Debian and LAVA is currently investigating alternatives.
• json-schema-validator currently has a broken test suite, so this will need to be patched by LAVA to allow the package to build. The code may be replaced with a different validator if the issue persists.
• namespace handling the current package install is unnecessarily noisy with complaints about the lava namespace. This will need a fix but does not affect current operation.
• Unit tests LAVA is working hard to add a much larger coverage of internal unit tests. These use a temporary database which is not generally available during the build of a distribution package. LAVA is already running continuous integration tests to ensure that these tests continue to pass and the packages will gain documentation on how to run these tests after installation.

Build Dependencies For Debian unstable, the list of packages which must be installed on your Debian system to be able to build packages from the lava-server and lava-dispatcher source code trees are:

debhelper (>= 8.0.0) python   python-all   python-dev   python-all-dev 
python-sphinx (>= 1.0.7+dfsg)   python3-sphinx python-mocker 
python-setuptools python-versiontools

(python-versiontools may disappear before the packages are finalised) In addition, to be able to install lava-server, these packages need to be built from tarballs released by Linaro (the list may shorten as changes upstream are applied)

linaro-django-pagination, 
python-django-restricted-resource (>= 0.2.7), 
lava-tool (>= 0.2), lava-utils-interface (>= 1.0), 
linaro-django-xmlrpc (>= 0.4),
python-versiontools (>= 1.8),
python-longerusername,
linaro-dashboard-bundle (>= 1.10.2), 
lava-dispatcher (>= 0.33.3)
lava-coordinator, lava-server-doc

The list for lava-dispatcher is currently:

python-json-schema-validator, lava-tool (>= 0.4), 
lava-utils-interface, linaro-dashboard-bundle (>= 1.10.2), 

The packages available from my experimental repository are using a new packaging branch of lava-server and lava-dispatcher where we are also migrating the CSS to Bootstrap CSS. Installing LAVA on Debian unstable
$ sudo apt-get install emdebian-archive-keyring
Add the link to my experimental repository (amd64, i386, armhf & arm64) to your apt sources, e.g. by creating a file /etc/apt/sources.list.d/lava.list containing:

deb http://people.linaro.org/~neil.williams/lava sid main
Update with the new key

$ sudo apt-get update
It is always best to install postgresql first:

$ sudo apt-get install postgresql
There are then three options for the packages to install (Please be careful with remote worker setup, it is not suitable for important installations at this time.):

1. Single instance, server and dispatcher with recommended tools
   apt-get install lava
   Installs linaro-image-tools and guestfs tools.
2. Single instance, server and dispatcher
   apt-get install lava-server
   Installs enough to run LAVA on a single machine, running jobs on boards on the same LAN.
3. Experimental remote worker support
   apt-get install lava-worker
   Needs a normal lava-server installation to act as the master scheduler but is aimed at supporting a dispatcher and boards which are remote from that master.

The packages do not assume that your apache2.4 setup is identical to that used in other LAVA installations, so the LAVA apache config is installed to /etc/apache2/sites-available/ but is not enabled by default. If you choose to use the packaged apache config, you can simply run:

$ sudo a2ensite lava-server
$ sudo apache2ctl restart
(If this is a fresh apache install, use a2dissite to disable to default configuration before restarting.) Information on creating a superuser, adding devices and administering your LAVA install is provided in the README.Debian file in lava-server:

$ zless /usr/share/doc/lava-server/README.Debian.gz
Provisos and limitations Please be aware that packaged LAVA is still a work-in-progress but do let us know if there are problems. Now is the time to iron out install bugs and other issues as well as to prepare LAVA packages for other distributions. It will be a little while before the packages are ready for upload to Debian I ve got to arrange the download location and upload the dependencies first and some of that work will wait until more work has gone in upstream to consolidate some of the current dependencies.

Kerberos is a great protocol for single sign-on authentication. It's supported by many protocols, allowing you to not have to enter a password to each and every one of them; instead, the protocols behind the scenes (not "just" Kerberos, but also the things that embed tickets, such as GSSAPI, or the things that embed GSSAPI, such as SASL or SPNEGO) use your ticket-granting-ticket to ask for security credentials for the service you're trying to use, magic happens, and you're authenticated. I blogged about kerberos before (even if it was ages ago); since then, I've not only used it on my own systems, but also on the systems of various customers. One thing I've learned in that time, however, is that most web application developers have a bad case of NIHilism when it comes to authentication. Most webservers that I've seen have a wide range of methods to do authentication in the webserver through various means, including things like certificate-based authentication, one-time password modules, and, yes, kerberos. Yet almost no webapp out there will look at the magic variables that those webservers set to explain we're authenticated, instead reinventing the wheel through webforms and other various stupid means. Sigh. So, that means, no kerberos authentication for webapps. Worse, if the application has no way to pass on authentication to something external, that means users will now have to learn another password: one for Kerberos, one for the webapp. And, probably, one for this other webapp, too -- because once you add one webapp, people expect you to add more of them. Well, mostly. In some cases, webapps do have ways to externalize authentication. In most cases this means "store passwords in a database", or "try authenticating against this other service here". When "this other service here" is an IMAP server, then all you need to do is make sure cleartext authentication on the IMAP server eventually ends up trying to authenticate against the Kerberos server, and you're all set. When "this other service here" is an LDAP server, however, you're out of luck. Right? It turns out that no, you're not. I recently learned that OpenLDAP can, in fact, check "simple" bind requests by checking some other service, and that this other service can be a Kerberos realm. Doing so is called "Pass-through authentication" in the OpenLDAP documentation, and this is how you do it:

• Add a "userPassword" attribute to the user who will authenticate, with a value of the form " SASL principal@KERBEROS.REALM". That is, take the user's principal name, tack " SASL " in front of it, and put that in the userPassword attribute.
• Make sure you have saslauthd installed and running, with the kerberos5 mechanism active. In Debian, that means you have to install sasl2-bin, and edit /etc/default/saslauthd, so it has the variable START set to yes (yuck), and the variable MECHANISMS set to kerberos5.
• Create a file /etc/ldap/sasl/slapd.conf, and add the following contents:

mech_list: plain
pwcheck_method: saslauthd

This directs the SASL libraries, loaded by slapd, to talk to saslauthd when trying to authenticate some SASL things - Make sure slapd has the correct permissions to access the saslauthd unix domain socket. On Debian, that means you need to add the "openldap" user to the "sasl" group:

 adduser openldap sasl 

(obviously that won't be active until the next slapd restart) And that's it; if you now try a simple bind against the LDAP directory, and enter your Kerberos password, you should be in. If it doesn't work, try running "testsaslauthd"; if that works, it means the error is in your slapd configuration. If it doesn't, then the problem is in saslauthd. Some notes:

• this is not the same thing as using Kerberos authentication for LDAP. OpenLDAP has the ability to allow SASL binds for LDAP, which is way more interesting (since it allows authentication to actually be done by Kerberos rather than by "entering a password"); instead, with this method, it is possible to verify a password for a simple bind against a Kerberos password.
• Since this can't use hashed passwords, this method is inherently insecure. Only use it if all else fails, and for the love of $DEITY, at least make sure all the network connections which are going to contain such passwords are encrypted with SSL or TLS or similar. Otherwise, everyone who can sniff anything on your network will learn all the Kerberos passwords, which is a very very bad thing.

Oh, and if you're a webapp developer: please please please make it easy for me to use an external authentication mechanism. This isn't hard; all you need is a separate page that will read the magic variables (probably REMOTE_USER if you're using apache), set a session variable or whatever, and then redirect to your normal "we've just logged in" page. ikiwiki gets this right; you can too! (for added bonus points, have some way to declare a mapping from REMOTE_USER values to internal, readable, usernames, but it's not too crucial)

Further improvements to the shared infrastructure I use for my various packages. This release adds new Autoconf macros for detecting SQLite. These use the same strategy that I used for libevent, and which I'm slowly adopting for all libraries that support pkg-config. pkg-config is tried first if available, and unless the Autoconf flags to point to particular install paths for the library are given. Autoconf then falls back on manual probing. Also in this release are all the changes to the Perl support modules for test programs and the various generic Perl tests to implement the change that I started in the last Term::ANSIColor release: using the Lancaster Consensus environment variables to control whether tests run when they don't directly test package functionality, and skipping a lot more tests for the average end user who doesn't really care if, say, the POD syntax is correct or all the supporting Perl scripts past strictness checks. You can get the latest release from the rra-c-util distribution page.

And today from our ever-growing collection of what the fuck is wrong with you people?!... This is wrong on so many levels, I can't even begin to describe it. Sadly, it seems that this will get funded. And if it does not, technology will only become cheaper over time...

Did you ever need to store logs or other files in a way that would allow it to be used as evidence in court, and needed a way to demonstrate without reasonable doubt that the file had not been changed since it was created? Or, did you ever need to document that a given document was received at some point in time, like some archived document or the answer to an exam, and not changed after it was received? The problem in these settings is to remove the need to trust yourself and your computers, while still being able to prove that a file is the same as it was at some given time in the past. A solution to these problems is to have a trusted third party "stamp" the document and verify that at some given time the document looked a given way. Such notarius service have been around for thousands of years, and its digital equivalent is called a trusted timestamping service. The Internet Engineering Task Force standardised how such service could work a few years ago as RFC 3161. The mechanism is simple. Create a hash of the file in question, send it to a trusted third party which add a time stamp to the hash and sign the result with its private key, and send back the signed hash + timestamp. Both email, FTP and HTTP can be used to request such signature, depending on what is provided by the service used. Anyone with the document and the signature can then verify that the document matches the signature by creating their own hash and checking the signature using the trusted third party public key. There are several commercial services around providing such timestamping. A quick search for "rfc 3161 service" pointed me to at least DigiStamp, Quo Vadis, Global Sign and Global Trust Finder. The system work as long as the private key of the trusted third party is not compromised. But as far as I can tell, there are very few public trusted timestamp services available for everyone. I've been looking for one for a while now. But yesterday I found one over at Deutches Forschungsnetz mentioned in a blog by David M ller. I then found a good recipe on how to use the service over at the University of Greifswald. The OpenSSL library contain both server and tools to use and set up your own signing service. See the ts(1SSL), tsget(1SSL) manual pages for more details. The following shell script demonstrate how to extract a signed timestamp for any file on the disk in a Debian environment:

#!/bin/sh
set -e
url="http://zeitstempel.dfn.de"
caurl="https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt"
reqfile=$(mktemp -t tmp.XXXXXXXXXX.tsq)
resfile=$(mktemp -t tmp.XXXXXXXXXX.tsr)
cafile=chain.txt
if [ ! -f $cafile ] ; then
    wget -O $cafile "$caurl"
fi
openssl ts -query -data "$1" -cert   tee "$reqfile" \
      /usr/lib/ssl/misc/tsget -h "$url" -o "$resfile"
openssl ts -reply -in "$resfile" -text 1>&2
openssl ts -verify -data "$1" -in "$resfile" -CAfile "$cafile" 1>&2
base64 < "$resfile"
rm "$reqfile" "$resfile"

The argument to the script is the file to timestamp, and the output is a base64 encoded version of the signature to STDOUT and details about the signature to STDERR. Note that due to a bug in the tsget script, you might need to modify the included script and remove the last line. Or just write your own HTTP uploader using curl. :) Now you too can prove and verify that files have not been changed. But the Internet need more public trusted timestamp services. Perhaps something for Uninett or my work place the University of Oslo to set up?

I ve just been given an Armourdillo Hybrid case for the Nexus 5 [1] to review. The above pictures show the back of the case, the front of the case, the stand, and the front of the case with the screen blank. When I first photographed the case the camera focused on a reflection of the window, I include that picture for amusement and to demonstrate how reflective the phone screen is. This case is very hard, the green plastic is the soft inner layer which is still harder than the plastic in a typical gel case . The black part is polycarbonate which is very hard and also a little slippery. The case is designed with lots of bumps for grip (a little like the sole of a running shoe) so it s not likely to slip out of your hand. But the polycarbonate slides easily on plastic surfaces such as the dash of a car. It s fortunate that modern cars have lots of cup holders that can be used for holding a phone. I haven t dropped the phone since getting the new case, but I expect that the combination of a hard outer shell and a slightly softer inner shell (to cushion the impact) will protect it well. All the edges of the case extend above the screen so dropping the phone face down on a hard flat surface shouldn t cause any damage. The black part has a stand for propping the phone on it s side to watch a movie. The stand is very solid and is in the ideal position for use on soft surfaces such as a doona or pillow for watching TV in bed. Appearance This case is mostly designed to protect the phone and the bumps that are used for grip detract from the appearance IMHO. I think that the Ringke Fusion case for my Nexus 4 [2] looks much better, it s a trade-off between appearance and functionality. My main criteria for this case were good protection (better than a gel case) and small size (not one of the heavy waterproof cases). It was a bonus to get a green case for the Enlightened team in Ingress. NB Armourdillo also offers a blue case for the Resistance team in Ingress as well as other colors. MobileZap also have a number of other cases for the Nexus 5 [3].

• [1] http://tinyurl.com/k8sy7ry
• [2] http://etbe.coker.com.au/2013/08/13/nexus-4-ringke-fusion-case/
• [3] http://www.mobilezap.com.au/34606/google/nexus-5/covers.htm

There was quite the torrential downpour overnight. It woke me up, and it woke Zoe up too, and at about 1:45am she ended up in bed with me. I think she managed to invent a new baby sleep position, where she was on my pillow, perpendicular to me along the bed head, and had somehow ejected the pillow that was on her side of the bed. We got up, with a slow start, and the weather was still looking a bit dicey, so Zoe wanted to go to Kindergarten by car. That actually meant we were the first ones there, because I'd been working to a timetable of leaving home by bike. One of the chickens was starting to hatch (and subsequently hatched around noon) so that was exciting. Funnily enough, Zoe had spent all morning telling me how she didn't want to go to Kindergarten, but by the time we got there, she didn't seem to mind being there all that much. After I got home from Kindergarten, I biked down to Bulimba to go to the bank to finalise opening my business bank accounts. I've since discovered that one can't do much without an ABN, I can't even get a cheque book, so I've sicked my accountant on that one for me. I got stuck into my US taxes some more today, and made a very satisfactory amount of progress on them. I think I should be able to finish them off in the next session I get to work on them. I felt like getting out of the house after that. It was looking quite like rain again, making picking up Zoe by bike out, so I ran a few errands in the car before getting to Kindergarten quite early. Zoe was fast asleep, but I let her have a long, slow wake up, and that made our departure much easier. She got to have a little hold of one of the baby chicks before we left. Today I learned that baby chicks smell absolutely divine. We got home, and Zoe did some self-directed craft for a bit, and then wanted to play hide and seek, so we did that and finally got around to looking at all of the Woolworths DreamWorks Heroes cards she's been collecting. I was disappointed to discover there's only a single card per pack, so that's going to mean I have to spend at least $840 on groceries, excluding duplicates, before we get all of them. I'm glad the checkout operators aren't sticking to the rules and are handing them out a little more generously than that. After that, we did a bit more rough and tumble play, and then it was time to start making dinner, so Zoe watched a DVD. We got dinner out of the way relatively early, so I practiced plaiting her hair (I've surprised myself with the half-decent job I can do) and then did bath time and bed time. Bed time was a little protracted (she didn't like her bedroom and wanted to sleep in my bed) but otherwise seems to have gone smoothly.

In a project I recently worked on we wanted to provide a jenkins-debian-glue based setup on Amazon s EC2 for building Debian and Ubuntu packages. The idea is to keep a not-so-strong powered Jenkins master up and running 24 7, while stronger machines serving as Jenkins slaves should be launched only as needed. The project setup in question is fully open sourced (more on that in a separate blog post), hereby I am documenting the EC2 setup in usage. Jenkins master vs. slave Debian source packages are generated on Jenkins master where a checkout of the Git repository resides. The Jenkins slaves do the actual workload by building the binary packages and executing piuparts (.deb package installation, upgrading, and removal testing tool) on the resulting binary packages. The Debian packages (source+binaries) are then provided back to Jenkins master and put into a reprepro powered Debian repository for public usage. Preparation The starting point was one of the official Debian AMIs (x86_64, paravirtual on EBS). We automatically deployed jenkins-debian-glue on the system which is used as Jenkins master (we chose a m1.small instance for our needs). We started another instance, slightly adjusted it to already include jenkins-debian-glue related stuff out-of-the-box (more details in section Reduce build time below) and created an AMI out of it. This new AMI ID can be configured for usage inside Jenkins by using the Amazon EC2 Plugin (see screenshot below). IAM policy Before configuring EC2 in Jenkins though start by adding a new user (or group) in AWS s IAM (Identity and Access Management) with a custom policy. This ensures that your EC2 user in Jenkins doesn t have more permissions than really needed. The following policy should give you a starting point (we restrict the account to allow actions only in the EC2 region eu-west-1, YMMV):

 
  "Version": "2012-10-17",
  "Statement": [
     
      "Action": [
        "ec2:CreateTags",
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeKeyPairs",
        "ec2:GetConsoleOutput",
        "ec2:RunInstances",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances"
      ],
      "Effect": "Allow",
      "Resource": "*",
            "Condition":  
                "StringEquals":  
                    "ec2:Region": "eu-west-1"
                 
             
     
  ]
 

Jenkins configuration Configure EC2 access with Access Key ID , Secret Access Key , Region and EC2 Key Pair s Private Key (for SSH login) inside Jenkins in the Cloud section on $YOUR_JENKINS_SERVER/configure. Finally add an AMI in the AMIs Amazon EC2 configuration section (adjust security-group as needed, SSH access is enough): As you can see the configuration also includes a launch script. This script ensures that slaves are set up as needed (provide all the packages and scripts that are required for building) and always get the latest configuration and scripts before starting to serve as Jenkins slave. Now your setup should be ready for launching Jenkins slaves as needed: NOTE: you can use the Instance Cap configuration inside the advanced Amazon EC2 Jenkins configuration section to place an upward limit to the number of EC2 instances that Jenkins may launch. This can be useful for avoiding surprises in your AWS invoices. Notice though that the cap numbers are calculated for all your running EC2 instances, so be aware if you have further machines running under your account, you might want to e.g. further restrict your IAM policy then. Reduce build time Using a plain Debian AMI and automatically installing jenkins-debian-glue and further jenkins-debian-glue-buildenv* packages on each slave startup would work but it takes time. That s why we created our own AMI which is nothing else than an official Debian AMI with the bootstrap.sh script (which is referred to in the screenshot above) already executed. All the necessary packages are pre-installed and also all the cowbuilder environments are already present then. From time to time we start the instance again to apply (security) updates and execute the bootstrap script with its &dash&dashupdate option to also have all the cowbuilder systems up2date. Creating a new AMI is a no-brainer and we can then use the up2date system for our Jenkins slaves, if something should break for whatever reason we can still fall back to an older known-to-be-good AMI. Final words How to set up your Jenkins jobs for optimal master/slave usage, multi-distribution support (Debian/Ubuntu) and further details about this setup are part of another blog post. Thanks to Andreas Granig, Victor Seva and Bernhard Miklautz for reading drafts of this.

I was awarded the Free Software Foundation Award for the Advancement of Free Software this weekend[1]. I'd been given some forewarning, and I spent a bunch of that time thinking about how free software had influenced my life. It turns out that it's a lot.

I spent most of the 90s growing up in an environment that was rather more interested in cattle than in computers, and had very little internet access during that time. My entire knowledge of the wider free software community came from a couple of CDs that contained a copy of the jargon file, the source code to the entire GNU project and an early copy of the m68k Linux kernel.

But that was enough. Before I'd even got to university, I knew what free software was. I'd had the opportunity to teach myself how an operating system actually worked. I'd seen the benefits of being able to modify software and share those modifications with others. I met other people with the same interests. I ended up with a job writing free software and collaborating with others on integrating it with upstream code. And, from there, I became more and more involved with a wider range of free software communities, finding an increasing number of opportunities to help make changes that benefited both me and others.

Without free software I'd have started years later. I'd have lost the opportunity to collaborate with people spread over the entire world. My first job would have looked very different, as would my entire career since then. Without free software, almost everything I've achieved in my adult life would have been impossible.

To me, free software means I've lived a significantly better life than would otherwise have been the case. But more than that, it means doing what I can to make sure that other people have the same opportunities. I am here because of the work of others. The most rewarding part of my continued involvement is the knowledge that I am part of a countless number of people working to make sure that others can tell the same story in future.

[1] I'd link to the actual press release, but it contains possibly the worst photograph of me in the entire history of the universe

comments

This is a fairly small Perl module that provides a more convenient interface to the ANSI color escape sequences. The primary change in this release is interesting for me but not so much for anyone else. It's the first of my core Perl modules that I've converted to Module::Build and to the new Perl test infrastructure that's now maintained in rra-c-util. (Yes, I know that Module::Build is apparently going to be dropped from Perl core, but the package also generates a Makefile.PL for backward compatibility.) Starting with this release, all my subsequent package releases will start using the Lancaster Consensus environment variables to control whether to run non-default tests (namely AUTOMATED_TESTING, RELEASE_TESTING, and AUTHOR_TESTING). Hopefully this won't cause me too many problems. I'm currently setting AUTHOR_TESTING unconditionally, since I really want to see the results of those tests for all my code, but it's possible that will cause me too many problems with other people's code. (It would have been nice if the spec for AUTHOR_TESTING would let you set the value of the variable to the identity of the author whose tests you want run.) I like having all my release tests run by automated testing so that I can identify any problems with the code to conditionally skip them, so I enable all the release tests when AUTOMATED_TESTING is set. This is probably peculiar to me. The other changes in this release are all documentation and test suite fixes. There are no code changes in this release. Thanks to Olivier Mengu and David Steinbrunner for various bug reports. You can get the latest release from the Term::ANSIColor distribution page.

since people keep talking to me about my RC bug fixing activities, I thought it might be time again for a short report. to be honest, I mostly stopped my almost daily work at some point in december, partly because the overall number of RC bugs affecting both testing & unstable is quite low (& therefore the number of easy-to-fix bugs), due to the auto-removal policy of the release team (kudos!). but I still kept track about RC bugs I worked on, & here's the list; as you can see, mostly pkg-perl bugs

• #711430 src:libcgi-cookie-splitter-perl: "libcgi-cookie-splitter-perl: FTBFS with perl 5.18: test failures"
  add patch from CPAN RT (pkg-perl)
• #711436 src:libdbix-abstract-perl: "libdbix-abstract-perl: FTBFS with perl 5.18: test failures"
  upload new upstream release (pkg-perl)
• #711444 src:libgraph-readwrite-perl: "libgraph-readwrite-perl: FTBFS with perl 5.18: test failure"
  upload new upstream release (pkg-perl)
• #711620 src:libthread-queue-any-perl: "libthread-queue-any-perl: FTBFS with perl 5.18: test failures"
  upload new upstream release (pkg-perl)
• #724137 src:libschedule-cron-perl: "libschedule-cron-perl: FTBFS: Tests failures"
  upload new upstream release
• #725570 src:pgfincore: "build postgresql-9.3 extension only"
  send improved debdiff to the bug, thanks to Martin Pitt
• #730906 src:libredis-perl: "libredis-perl: FTBFS: Failed tests"
  upload new upstream release (pkg-perl)
• #730925 src:libgeo-ip-perl: "libgeo-ip-perl: FTBFS: Failed tests"
  upload new upstream release (pkg-perl)
• #731794 libanyevent-perl: "FBFTS: AnyEvent fails t/81_hosts.t on system with OpenDNS"
  upload new upstream release prepared by Xavier Guimard (pkg-perl)
• #733364 src:libjxp-java: "libjxp-java: FTBFS: [javac] / PKGBUILDDIR /src/java/org/onemind/jxp/servlet/JxpServlet.java:29: error: package javax.servlet does not exist"
  add missing build dependency (pkg-java)
• #733379 src:libonemind-commons-java-java: "libonemind-commons-java-java: FTBFS: [javac] / PKGBUILDDIR /src/java/org/onemind/commons/java/util/ServletUtils.java:28: error: package javax.servlet does not exist"
  add missing build dependency (pkg-java)
• #733429 src:libcatalyst-modules-perl: "libcatalyst-modules-perl: FTBFS: Tests failed"
  upload new upstream release (pkg-perl)
• #735054 src:libpoet-perl: "libpoet-perl: FTBFS: test failures: t/App.t"
  add missing (build) dependency (pkg-perl)
• #735367 bti: "bti: stopped working after SSL/TLS traffic restriction, due to obsolete URL"
  upload new upstream release
• #735823 src:libgtk3-perl: "libgtk3-perl: FTBFS: Tests failures"
  set HOME for tests (pkg-perl)
• #736275 libmarc-xml-perl: "libmarc-xml-perl: CVE-2014-1626: XML External Entity privilege escalation"
  upload new upstream release (pkg-perl)
• #736718 libalien-sdl-perl: "libalien-sdl-perl: depends on libtiff4 which is going away"
  fix dependencies (pkg-perl)
• #736820 libnet-frame-perl: "libnet-frame-perl: package seems to depend on things that are not packaged"
  upload new upstream release prepared by Daniel Lintott (pkg-perl)
• #736866 src:libjpfcodegen-java: "[src:libjpfcodegen-java] Sourceless file (minified)"
  drop sourceless minified .js files (pkg-java)
• #737739 src:mumble: "mumble: CVE-2014-0044 CVE-2014-0045"
  sponsor security upload for Chris Knadle
• #738419 src:libsvn-hooks-perl: "libsvn-hooks-perl: FTBFS: Tests failures"
  fix (build) dependencies (pkg-perl)
• #738431 src:latex-make: "latex-make: FTBFS: Font T1/cmr/m/n/10=ecrm1000 at 10.0pt not loadable: Metric (TFM) file not found"
  propose patch, then fixed by maintainer
• #739144 src:librpc-xml-perl: "librpc-xml-perl: FTBFS: Test failure"
  upload new upstream release (pkg-perl)

ps: the how-can-i-help package is a nice tool for finding RC bugs in packages you care about. install it if you haven't so far!

Aldi Mobile has made a significant change to their offerings. They previously had an offer of $35 for unlimited calls and 2.5G of data in a month for which they had to publicly apologise for misleading customers as 2500 minutes of calls a month (83 minutes per day) is no-where near unlimited [1]. They also had an offer of $15 for 2G of data. In an email about this Aldi said Many of our customers are using a lot less than what is included in our current $35 plan. So we will soon be introducing new Value Packs with more flexible options; meaning you only pay for what you really need and they start from just $10. . That is grossly misleading, if they offered new plans in addition to the old ones and allowed customers to choose the plan that is the best match then it would be useful to some customers. But removing the supposedly unlimited plan and the $15 for 2G of data option is removing affordable options for people who want to use their phones for lots of calls or very few calls but moderate amounts of data use. New Plans The base rate for calls on Aldi pre-paid is $0.12 per minute and $0.12 per SMS, consider every mention of minute in this section to be minute or SMS . The Aldi Newplans page [2] starts with a $10 per month plan which offers 100 minutes of calls which would be $12 at the previous rate of $0.12 per minute. That is OK value when compared to just using the pre-paid calls if you consistently use more than 83 minutes of calls per month. However if you don t use 84 minutes of calls (EG you don t speak much on the phone and use Google Hangouts instead of SMS) then it s not good value. Also the advertised data use is $5 per 100MB, which is way below what is needed for a typical user with an Android phone. My mother in law was barely able to stick within a limit of 300MB/month when that was her limit, but while using the Aldo 2G/month bolt-on she s increased her data usage. The smallest of the new plans costs $20 per month, it provides 300 minutes of calls and includes 300MB of data. For an extra $7 you can get another 300MB of data. For my mother in law it seems that the cheapest option on the new plans would be $27 per month, that would cover the 60 minutes of calls she might make and the 450MB of data she s probably using. That s significantly more expensive than her previous cost of $15 for 2G of data and $7.20 for calls and has the additional difficulty that I would have to be more involved in helping her avoid excessive data use. The 2G data bolt-on was really good for some of my relatives, when they use that and configure their phones not to update software over 3G they never had to ask me about any problems related to excess data use. So my mother in law is facing an extra $5 per month (or maybe more depending on data use) and more time spent calling me for tech support. The data bolt on that Aldi is going to offer in future is $30 for 3G of data to replace the previous offer of $15 for 2G of data. The cost will be unchanged for anyone who uses between 2G and 3G a month, for everyone who uses less than 2G or more than 3G the data bolt-on will cost more. There is simply no possibility for any Aldi data-only customer to save on data use. The only way someone who uses a moderate amount of data could save money is if they use more than 160 minutes of calls and less than 1G of data. Disclaimer My analysis above is based on interpreting the Aldi web site. As with most telcos they aren t trying to make things easy in this regard, it seems that the consensus of opinion among telcos is to use complex pricing to make it difficult to compare and reduce competitive pressure. I blame any inaccuracies in my analysis on the Aldi web site. Why Aldi Shouldn t Mislead Customers Aldi isn t primarily a mobile phone company, their main business is running a supermarket. The trust of customers is important to them, raising prices when competition goes away is one thing, but misleading customers about it is another. If Aldi were to honestly say now that Kogan Mobile no longer exists there is nothing forcing us to have low prices then I d have a lot more respect for their company and be more inclined to shop at their supermarket. It s a sad indictment of our society that I need to include a why lying is wrong section in such a blog post.

• [1] https://www.aldimobile.com.au/corrective-notice
• [2] https://www.aldimobile.com.au/newplans