Although there wasn't too many comments on my what would you pay for? post I did get some mails. I was reminded about this via Mario Langs post, which echoed a couple of private mails I received. Despite being something that I take for granted, perhaps because my hosting comes from the Bytemark, people do seem willing to pay money for DNS hosting. Which is odd. I mean you could do it very very very cheaply if you had just four virtual machines. You can get complex and be geo-fancy, and you could use anycast on a small AS, but really? You could just deploy four virtual machines0 to provide a.ns, b.ns, c.ns, d.ns, and be better than 90% of DNS hosters out there. The thing that many people mentioned was Git-backed, or Git-based DNS. Which would be trivial if you used tinydns, and no much harder if you used bind. I suspect I'm "not allowed" to do DNS-things for a while, due to my contract with Dyn, but it might be worth checking... ObRandom: Beat me to it. Register gitdns.io, or similar, and configure hooks from github to compile tinydns records. In other news I started documenting early thoughts about my caching reverse proxy, which has now got a name stockpile. I wrote some stub code using node.js, and although it was functional it soon became callback hell:

• Is this resource cachable?
• Does this thing exist in the cache already?
• Should we return the server's response to the client, archive to memcached, or do both?

Expressing the rules neatly is also a challenge. I want the server core to be simple and the configuration to be something like:

is_cachable ( vhost, source, request, backened )
 
    /**
     * If the file is static, then it is cachable.
     */
    if ( request.url.match( /\.(jpg png txt html? gif)$/i ) )  
        return true;
     
    /**
     * If there is a cookie then the answer is false.
     */
    if ( request.has_cookie? )   return false ;  
    /**
     * If the server is alive we'll now pass the remainder through it
     * if not then we'll serve from the cache.
     */
    if ( backend.alive? )  
        return false;
     
    else  
        return true;
     
 

I can see there is value in judging the cachability based on the server response, but I plan to ignore that except for "Expires:", "Etag", etc ,etc) Anyway callback hell does make me want to reexamine the existing C/C++ libraries out there. Because I think I could do better.

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 

Today was another wet day. Sarah dropped Zoe around in the morning, and she watched a little bit of TV before we drove to Brazilian Jiu-Jitsu class. My cycling fitness is going to go completely to hell. Zoe's really taken to her teacher, Patrick. The classes have pretty much been just Zoe and I on Friday's, with the occasional other kids, and so she's formed a pretty close relationship with her teacher. The last few weeks, Zoe's really liked to help Patrick set up and tidy up the space before and after the classes. She loves to tell Patrick about what's been going on in her life. It's really sweet to watch. Today there was another 3 year old boy, but he was much less focused than Zoe. I will miss the classes, because I've seen real self-defense value in what they've been teaching. For proper comparison, I should see tae kwon do clases as well, but currently I'd be pretty happy with what I've seen taught in Brazilian Jiu-Jitsu. I can see the practical application of it. We're going to go watch Patrick compete in May, and I'm looking forward to seeing some adult-level stuff. Megan's Dad was looking for something to do with his kids, so I suggested we meet at Lollipops Playland & Cafe in Cannon Hill after BJJ class. We were a bit late in getting there, mostly because Zoe wanted to hang around after class for a bit, but we got there eventually, and Zoe and Megan had a great time. We stayed for lunch and the girls played a bit more. It's the first time I've used a play cafe since coming back to Australia, and I found it almost overwhelmingly loud and busy. These places must love it when it rains. It was nice that Zoe's at an age now where she can go off and play on her own. Having Megan there was a great help in that regard, but the girls did keep losing each other, although that wasn't a big problem for either of them. While we were at the play cafe, I received an email saying that the Kindergarten working bee for tomorrow had been canceled on account of the wet weather, so that's opened up our Saturday significantly. After that, we headed down to Bunkers to place the order for the bunk bed I want to get Zoe for her birthday. I'd expected with all the morning's activities, for her to pass out in the car immediately, but surprisingly she lasted the distance, and had a great time sampling all the different bunk beds at the store. Even on the way back home, it took her a little while to fall asleep, so I extended the car ride by driving around the Port of Brisbane to see how much there was to see that might be interesting for Zoe when she's awake. After that, we went to the car wash to get the car cleaned, because it's been a while. Zoe had a babyccino and we sorted through the DreamWorks cards we'd traded with Megan that morning. It was time for dinner after the car wash, so we headed home, and Zoe watched some TV while I prepared dinner. At bath time, I realised that we hadn't had time to do anything for Science Friday. Yesterday at Bunnings I bought a roll of clear tubing for the heck of it, so we made a siphon in the bath. Zoe thought the tube was great fun, and had a good time blowing bubbles in the bath with it. Tomorrow we'll have to use some bubble bath for added entertainment. Bedtime went smoothly enough.

A number of talks about Rcpp are scheduled over the next couple of months:

• Our sixth internation conference R/Finance, will take place May 16 and 17, 2014, at UIC in Chicago. See the current draft agenda for details of the program---which once again will be preceded by one-hour workshops. And as in the past, I will offer a one-hour gentle introduction to Rcpp. This workshop requires registration and a fee, and registraion details should be available at the conference website in the next few days.
• A few days later, on May 20, 2014, I will present a one-hour webinar which is part of a series organized by Ray DiGiacomo and the Orange County R Users Group. See this page for details and registration information; the talk itself will be free of charge.
• Later in the month, on May 30, 2014, I will give a talk / guest lecture about Rcpp and RcppArmadillo and over in Economics at the University of Chicago. I reckon that this event is not open to anybody not part of U of C.
• Another three-hour tutorial is scheduled for the tutorial day preceding useR! 2014 at UCLA in early July. This tutorial will also require registration as part of the annual useR! conference.
• Last but not least I am very honoured to have been asked to give one of the invited keynotes at useR! 2014. The talk may (or may not) cover at least some aspects of Rcpp.

So the month of June is still pretty open. If someone wants me to talk somewhere else, preferably on a Saturday, feel free to get in touch.

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

As some of you know, I ve started to take Sundays off, and this is mostly a post to continue to hold myself accountable, and to assure everyone that yes! That s still going on! I ve found my Saturdays to be more productive, and my Sundays to be much more enjoyable and stress-free. For those that don t know, I m not even using any computer through my Sundays (hilariously dubbed paul-tag by my friends (only Germans would find this funny, though :) )), but my tablet and phone seem to be OK (but I actively avoid email) If anyone s on the fence, I highly recommend doing this, it s really great.

I've been with Flickr since 2005 now, posting a lot of my photos there, so that other poeple from the events, that I usually take photos of, could enjoy them. But lately I've become annoyed with it. It is very slow to uplaod to and even worse to get photos out of it - there is no large shiny button to Download a set of photos, like I noticed in G+. So I decided to try and copy my photos over. I am not abandoning or deleting my Flickr account yet, but we'll see. The process was not as simple as I hoped. There is this FlickrToGpluss website tool. It would have been perfect .. if it worked. In that tool you simply log in to both services, check which albums you want to migrate over and at what photo size and that's it - the service will do the migration directly on their servers. It actually feeds Google the URLs of the Flickr photos so the photos don't even go trought the service itself, only metadata does. Unfortunately I hit a couple snags - first of all the migration stopped progressing a few days and ~20 Gb into the process (out of ~40 Gb). And for the photos that were migrated their titles were empty and their file names were set to Flickr descriptions. Among other things that meant that when you downloaded the album as a zip file with all the photots (which was the feature that I was doing this whole thing for) you got photos in almost random order - namely in the order of their sorted titles. Ugh. So I canceled that migration (by revoking priviledges to that app on G+, there is no other way to see or modify progress there) and sat down to make a manual-ish solution. First, I had to get my photos out of Flickr. For that I took Offlickr and ran it in set mode:

./Offlickr.py -i 98848866@N00 -p -s -c 32

The "98848866@N00" is my Flickr ID which I got from this nice service, then -p to download photos (and not just metadata), -s to download all sets and -c 32 to do the download in 32 parallel threads. An important thing to do is to take all you photos that are not in a set in Flickr and add them to a new 'nonset" so that those photos are also picked up here, there is an option under Organize to select all non-set photos. It worked great, but there were a couple tiny issues:

1. There is a bug in Offlickr that it does not honor pages in Flickr sets, so it only downloads first 500 images in each set, fix for that is in that bug;
2. It also wanted Python2.6 for some reason, but worked fine with Python2.7
3. With that number of threads sometimes Flickr actually failed to respond with the photo, serving a 500 error page instead. Offlickr does not check return code and happily daves that HTML page as the photo. To work around that I simply deleted the HTML errors and then ran the same Offlickr command again so that it re-downloads the missing files. Had to repeat that a few times to get all of them:

ack-grep -l -R "504 Gateway Time-out" dst/   xargs rm

After all that I had my photos, all 40 Gb of them on my computer. Should I upload them to G+ now? Not yet! See the photos all had lost their original file names. It turns out Flickr simply throws that little nugget of information away. It is nowhere to be found, neither in metadata or the UI or the Exif of the photos. Also some of my photos had clever descriptions that I did not want to loose or re-enter in G+ and also geolocation information. Flickr does not embed that info into the Exif of the image, instead it is provided separately - Offlickr saves that as an XML file next to each image. So I wrote a simple and hacky script to re-embed that info. It did 3 things:

1. Embed title of the photo into the Description EXIF tag, so that G+ automatically picks it up as title of the photo;
2. Embed the GEO location information into the proper EXIF tags, so that G+ picks that up automatically;
3. Create a new file name based on original picture taken datetime and EXIF Canon FileNumber field (if such exists), so that all photos in an album are sequential.

It uses exiftool for the actual heavy lifting. After all that was finished I tested the result by uploading a few images to G+ and testing that their title is being set correctly, that they have a sane file name and that geo information works. After that I just uploaded them all. I tried figuring out the G+ API (they actually have it) but I was unable to pass the tutorial, so I abandoned it and simply uploaded the photos of each set int their own tab via a browser. That took a few hours. But that is much faster that with Flickr. Like 4 MB/s versus 0.5 MB/s faster. And here is the result. So far I kind of like it. We'll see how it goes after a year or so. Now on to an even more fun problem - I now have ~40 Gb of photos from Flickr/G+ and ~100 Gb of photos locally. Those sets partially intersect. I know for a fact that there are photos in Flickr set that are not in my local set and it is pretty obvoious that there are some the other way round. Now I need to find them. Oh and I cann't use simple hashes, because Exif has changed and so have the file names for most of them. And not to forget that I often take a burst of 3-4 pictures, so there are bound to be a some near-duplicate photos in each set too. This shall be fun :)

So a good friend of mine talked about something in the debian-private mailing list. And we should not disclose that something outside such a sensible space without his approval. But Jakub is right. Once the discussion goes over to only messages talking about non-private stuff, the discussion should be moved to a non-private area. After all, we will not hide problems yada yada, right? So, not knowing where in the Debian lists this should go to, it will land on my blog, reformatting mail to make sense in this media:

Luca Filipozzi dijo [Wed, Mar 26, 2014 at 03:36:49PM +0000]:

Or don't use a mouse. When I started getting shoulder strain from using a mouse too much, I switched to an Adesso touchpad keyboard and was very happy with the positive outcome. I'm a touch (that's punny) less efficient with the touchpad compared to a mouse, but the lack of permanent injury and ongoing pain is worth it.

Right. I also have this keyboard (same brand even, different model). The keyboard is not that good (keys are not as smooth as in my previous, stock-Dell keyboard), but not having to move my right hand just to feed the rodent has made my back way way happier. I even feel better using a trackpad than a mouse (mabye because I use too much my netbook?). Luca, just out of curiosity: Did you ever manage to recognize the keyboard under the Synaptics driver, or to get it running under ChordMiddle or Emulate3Buttons? I had to fall to a ugly hack, mapping the "XF86Search" key to the middle button by telling my window manager (i3) to "bindsym X86Search exec xdotool click 2".

[ this can be declassified at any time ]

my contributions to this thread too...

my contribution unclassified, also

My classifications remain contributed. Do as you will with my bits of this message.

I've added a new page to my site to clarify that yes, you can do things with my cooking recipes, even if they are not yet under a free license:

Trueelena: Copyright and Cooking Recipes

The reason why I haven't felt the need to release my recipes under a different license is related to the way copyright works in relation with cooking recipes: copyright covers the creative expression of an idea, not the idea itself.

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/

Yesterday I took a diversion from thinking about my upcoming cache project, largely because I took some pictures inside my house, and realized my offsite backup was getting full. I have three levels of backups:

• Home stuff on my desktop is replicated to my wifes desktop, and vice-versa.
• A simple server running rsync (content-free http://rsync.io/).
• A "peering" arrangement of a small group of friends. Each of us makes available a small amount of space and we copy to-from each others shares, via rsync / scp as appropriate.

Unfortunately my rsync-based personal server is getting a little too full, and will certainly be full by next year. S3 is pricy, and I don't trust the "unlimited" storage people (backblaze,etc) to be sustainable and reliable long-term. The pricing on Google-drive seems appealing, but I guess I'm loathe to share more data with Google. Perhaps I could dedicated a single "backup.account@gmail.com" login to that, separate from all-else. So the diversion came along when I looked for Amazon S3-comptible, self-hosted, servers. There are a few, most of them are PHP-based, or similarly icky. So far cloudfoundry's vlob looks the most interesting, but the main project seems stalled/dead. Sadly using s3cmd to upload files failed, but certainly the curl based API works as expected. I looked at Gluster, CEPH, and similar, but didn't yet come up with a decent plan for handling offsite storage, but I know I have only six months or so before the need becomes pressing. I imagine the plan has to be using N-small servers with local storage, rather than 1-Large server, purely because pricing is going to be better that way. Decisions decisions.

My late biological maternal grandmother ("Nana"), remarried late in her life to a long-time friend named Bryce. I was probably an early teenager. He was a nice guy, and I kept in loose contact with him after my Nana passed away. After my Nana passed away, he moved out of the retirement home he'd been living in with my Nana, and in with one of his sons. Sometime before I moved back to Australia, in ailing physical health, he moved from his son's place into Masonic Care's aged-care hostel in Sandgate. He turned 90 last year. Mentally, he's doing pretty good. Physically, he's very wobbly on his legs. He's had a few falls, which was the main catalyst for moving from his son's place to the aged-care hostel. Other than that, he's in pretty good physical health though. I remember the first time I visited him in the hostel. After I left, I wept uncontrollably. Here was a man who was literally just waiting out the rest of his life in a small cupboard of a room. I was appalled at how small the room was, and the fact that he was just sitting around waiting to die really upset me. I've visited him a few times since I've been back. I've taken him over to my parent's place when I've taken Zoe to visit them, just so he gets out. I should say that I'm sure his own family do spend some time with him, so it's not like he's spending all his time rotting in this place, but probably still a fair chunk of it. Growing old sucks. Yesterday, when the weather forecast for today was looking like it was going to be pretty wet and miserable, I decided I'd use the day to take Zoe to Underwater World (which I've since learned has rebranded it self as "Sea Life: Mooloolaba". I had the presence of mind to call up Bryce yesterday to see if he'd like to join us today. We had to pass in his general direction to get up there, so it wasn't particularly out of my way. He informed me that he was now in a wheelchair, which I thought was fine for this excursion. So this morning, after we got ourselves going, we stopped at Sandgate to pick up Bryce, and made it to Underwater World by about 10am. I was a bit leery of the drive, because from home, it was another 30 minutes on top of the drive to Wet and Wild, and 15 minutes on top of the drive to Sea World, so I wasn't sure how Zoe would take that length car trip. It turned out that she took it pretty well. She started getting a bit restless in the last 30 minutes, but it was manageable. I was a little apprehensive about how wrangling Zoe and looking after a frail 90 year old in a wheelchair was going to work out. It turned out it worked out just fine. I could leave Bryce wherever he was, if I had to chase after Zoe, and Zoe quite liked helping push the wheelchair around. Towards the end of the day, when she got tired, I could just pop her in Bryce's lap, and push the pair of them around. It was a really good outing. I have only vague memories of visiting the place in my childhood, and it's become significantly better since then. Zoe really enjoyed going through the glass tunnels under the main ocean exhibit. We did several laps of that. We were fortunate enough to catch the sting ray feeding almost immediately upon arrival, and we also saw the seal show and made the otter feeding. The place was more focused on salt water aquatic life, hence the name, but there was also some freshwater exhibits. I never thought that much of the Monterey Aquarium, much preferring the California Academy of Science's aquariums, especially in terms of drive time accessibility. If you ignore the freshwater/salt water diversity, I think Sea Life is even better than the California Academy of Sciences. We left at about 2pm, and after a lot of hunting around, tracked down the photo they took when we entered, and then drove home closer to 3pm. To my surprise, Zoe didn't fall asleep immediately, but she did fall asleep on the way back to Bryce's place. She woke up to say goodbye to him, and then we drove home, stopping off in the Valley to check my post office box along the way, and arrived back home about 15 minutes before Sarah arrived to pick her up. It ended up being a very full day. Bryce really enjoyed himself, and I felt really happy that I was able to relatively easily brighten up his day. I've resolved to try another such outing again, I just need to figure out what to do. I thought I'd try for a 10km run, but it started to rain at the 4km mark. I was also not feeling particularly confident about lasting the distance, so I decided to just turn it into a 5km run instead.

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)

I used to host my internet infrastructure at Hurricane Electric. It all started in october 1998 with POP3/SMTP, HTTP and DNS. In the coming years, I began to host all services except DNS on my own. But I kept using he.net for its DNS management interface. It was dead simple, and therefore accessible. All they had was a basic textarea with BIND alike configuration in it. I could log in to their admin interface and change my DNS records as desired. A few years ago, they auto-upgraded my account to their new shiny DNS panel, which, surprise surprise, is no longer accessible with a simple text browser. After a bit of bitching with support, they ended up downgrading my account back to the old functionality, so I was happy again. However, as you might guess, last time I needed to change a DNS record, I found that the DNS panel has been ugpraded yet again and is again no longer accessible to me. So it was time to leave the sinking ship. But I needed to find an accessible DNS hosting service. Not an easy task, given that everyone seems to do more or less the same thing these days.

krb5-strength is the password strength checking code that we use at Stanford for our primary Kerberos realm. We've had quite a lot of difficulty deciding exactly what password strength checking we want to do and how we want to handle password history. The good part is that this is to the advantage of everyone else, since now more flexible password strength checking code is available. The major change in this release is the addition of a password history implementation for Heimdal. Implemented as an external password quality check program, it can stack with other password quality check programs, such as the one included in this distribution. Previous passwords are hashed with PBKDF2 with SHA-2. Note that this has somewhat extensive Perl module dependencies, since it was originally written as a separate project. Also in this release is yet another password dictionary type: SQLite. This is probably a bit slower than straight lookups in CDB, and it's definitely less space-efficient since it stores each word both forward and reversed, but it can reject any password that is within edit distance one of a dictionary word. (Edit distance one means that the word can be formed from the password by adding, removing, or changing a single character.) The cdbmake-wordlist utility has been renamed to krb5-strength-wordlist and can now generate the SQLite dictionary as well as the CDB dictionary. Finally, another configuration option has been added: minimum_different. If set, passwords must contain at least this many different characters. This can be used to reject passwords that are long strings of the same character or short repeating patterns, which are otherwise difficult to detect with a straight dictionary-driven approach. You can get the latest release from the krb5-strength distribution page.

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.