Interesting times.. While the big disasters are ongoing, little ones have been spicing up my life lately. A pleasant week by the beach ended with a tropical storm passing over the beach house. I've never experienced this before, and though Andrea was diminished by passing over land, it was still more wind than I've ever seen. I love wind, and this was thrilling, right on the edge of danger but not quite there. At least, if you have sense to stay out of the water. Leaving the beach, I heard of someone who tried to go surfing that day, and drowned. The night before last, I was startled to find nearly an inch of water seeping up from underneath the tile floor of the kitchen. Probably it has something to do with the pressure tank pumping system, which was repaired while I was away, and means I actually have indoor running water here. (Overrated.) This saw me scrambling to close every water valve, and out with a flashlight at 2 am closing the cutoff at the 1000 gallon water reservoir before it all drained into the house. While sopping up dozens of gallons of water from the floor at 3 am probably doesn't sound like fun, I found myself going through the motions elatedly.. Because this means I finally am coming to understand the source of the damp that infests the most earth-sheltered corner of this house. It's not condensation. It's bad plumbing! Then yesterday, I went out to try a dip in the river, stopped by the neighborhood eatery and bait shop, and ended up sitting out on the back deck eating ribs and listening to a band with "possum playboys" in their name (which makes the full name fairly irrelevant), while looking out over the river and the old-timey green metal bridge. Which was unexpected fun, and the kind of thing you have to take in when it happens, but getting stuck in a newly installed hole in my driveway was not. My car was spinning, and I gave up and called it a night. Here's the thing. I could feel my brain working on this stupid "underpowered car is stuck in a small rut" issue all night long. Same mental pathways activating that chew over bugs and design issues. Got up this morning with a set of plans and contingency plans all ready to go. The first one, of jacking it up and putting something under the tire was stymied; it seems I am missing a jack. But the second, of digging out all around the tire, and then filling in with gravel and cat litter (a tip from some offroading website I blearily surfed last night), and then riding the gas while releasing the bake, worked great. All of which is to say, bring em on! But I still prefer my disasters in the form of software bugs.

Hi folks, I used to work at F5, and I pulled a bunch of equipment out of the recycle bin while I was there in order to help me populate the customer end premesis device inventory for a carrier network / ISP I am setting up. They decided to terminate my employment at the end of August last year, and I ve been wondering what to do with all of this equipment. I figured that it s been long enough that I can give them a call, so I did. I asked them whether I should consider buying BIG-IP hardware off of e-Bay if it said that it did not come with a license. The customer service agent told me that I should probably not consider doing any such thing, since I would have to pay a hefty fee to F5 before they would even provide a license. It looks like I d have to shell out fifty thousand dollars to get a proper F5 Networks Inc. license for these many surplus BIG-IP devices I have. I guess I ll just have to go with an improper (or maybe I mean not for profit) operating system like Debian. I wonder if I can get the current linux kernel to pick up these broadcom 10GE chips or whether I ll have to wait for someone to release Free as in speech firmware for them that I can make use of. Do any of you DDs want a shell on a linux box with a 10-port 10GE switch attached by PCI-e? I bet I could get a Debian chroot environment running in the system s stock rescue firmware. I bet I could then determine why the watchdog timer keeps tripping when I boot with other kernels If you decide to accept the offer of a shell on this box, please try to avoid rebooting it. It tends to pop my breakers and I have to run to the shop before the UPSs run out of juice.

Recently, I ate at the somewhat famous London vegetarian restaurant Indian Veg Bhelpoori House in Islington (often referred to simply as Indian Veg ).

I couldn t help but imagine that the restaurant had hired Emanuel Bronner as their interior decorator.

If all goes well, a new release of dput-ng will hit the archive this week (depending on when I can find time to close the last 2 bigger bugs) - anyone interested in getting a new feature into dput-ng should email me (or file a reportbug bug at dput-ng) Small list of changes so far: * Add per-host loading of command files by partially parsing command line arguments. * Add disallowed_distributions. * Add codename groupping support. * Add codename groups to vital targets, limit security uploads to the right servers (Closes: #708575). * Implement dcut commands for Deb-o-Matic. * Add an override and a unset option to dput which overrules any profile key. This is an experimental option. * Be more precise about our configuration file inheritance in dput(5). * Fix dcut: manpage and help talk about -U and upload by replacing those parts in the text by the upload command (Closes: #699812) * Make the login name determination more portable (Closes: #709831) * Fix Allow to give out dm permissions without using local keyring by * documenting the force option in the man page (Closes: #711057) * Allow uploads to mentors to target every distribution * Add a space in debug s help message. * Fixed a typo (DEBNAME DEBFULLNAME) in the dcut(1) manpage. Thanks, y all!

... backups? did someone talk about backups? I'm sure I heard someone mention backups here somewhere. Backups! BACKUPS! BACKUPS ARE AWESOME!

That's a direct quote from my recent IRC history. I find backups quite interesting, particularly from an implementation point of view, and I may sometimes obsess about them a little bit. This is why I've written my own backup software. I'm unusual: most people find backups boring at best, and tedious most of the time. When I talk with people about backups, the usual reaction is "um, I know I should". There are a lot of reasons for this. One is that backups are a lot like insurance: you have to spend time, effort, money, up front, to have any use for them. Another is that the whole topic is scary: you have to think about when things go wrong, and that puts people off. A third reason is that while there are lots of backup tools and methods, it's not always easy. After all, backups are about answering the question, "what can I do to keep my data safe, whatever happens in the future?". I've spent a fair bit of the past several years thinking about backups. This is the first in a series of blog posts about backups, where I share my thinking about the topic. Perhaps it can be of some use to others. At least people will poke holes in my delusions. In this post, I'll define some terminology. I am not a backup scholar, and I may have invented some of these terms myself, and they may be different from what real sysadmins use. I'll define the words I use, so we can understand each other. Live data is the data you work with or keep. It's the files on your hard drive: the documents you write, the photos you save, the unfinished novels you wish you'd finish. A backup is a spare copy of your live data. If you lose some or all of your live data, you can get it back ("restore") from your backup. The backup copy is, by practical necessity, older than your live data, but if you made the backup recently enough, you won't lose much. Sometimes it's useful to have more than one old backup copy of your live data. You can have a sequence of backups, made at different times, giving you a backup history. Each copy of your live data in your backup history is a generation. This lets you retrieve a file you deleted a long time ago, but didn't realise you needed until now. If you only keep one backup version, you can't get it back, but if you keep, say, a daily backup for a month, you have a month to realise you need it, before it's lost forever. The place your backups are stored is the backup repository. You can use many kinds of backup media for backup storage: hard drives, tapes, optical disks (DVD-R, DVD-RW, etc), USB flash drives, online storage, etc. Each type of medium has different characteristics: size, speed, convenicence, reliability, price, which you'll need to balance for a backup solution that's reasonable for you. You may need multiple backup repositories or media, with one of them located off-site, away from where your computers normally live. Otherwise, if you house burns down, you'll lose all your backups too. You need to verify that your backups work. It would be awkward to go to the effort and expense of making backups and then not be able to restore your data when you need to. You may even want to test your disaster recovery by pretending that all your computer stuff is gone, except for the backup media. Can you still recover? You'll want to do this periodically, to make sure your backup system keeps working. Most live data is precious in that you'll be upset if you lose it. Some live data is not precious: your web browser cache probably isn't, for example. This distinction can let you limit the amount of data you need to back up, which can significantly reduce your backup costs. There is a very large variety of backup tools. They can be very simple and manual: you can copy files to a USB drive using your file manager, once a blue moon. They can also be very complex: enterprise backup products that cost huge amounts of money and come with a multi-day training package for your sysadmin team, and which require that team to function properly. You'll need to define a backup strategy to tie everything together: what live data to back up, to what medium, using what tools, what kind of backup history to keep, and how to verify that they work. That's the groundwork. In the next episode, I'll blather about what is a backup, and what isn't.

I've been singing for a long time. The first time I was a member of a choir was when I was around 6-7 years old, and it was as a member of the children's choir 'De Lambertijnen' in Ekeren, Belgium. Not by coincidence, Ekeren is where I grew up. However, I didn't remain a member of 'De Lambertijnen' for very long. After a year or two, I was over the maximum age for members of that choir, and "promoted" to Carmina, another children's choir of the same association. I didn't like that choir as much, though, and only remained a member for about a year or so, before I left that choir; and for a few years, choral music was no longer part of my interests. Then, when I turned sixteen, I was in a school where choral music was part of the curriculum; and through class, I found out that singing in a choir is something I actually love. By that time I was too old to join Carmina again, so I joined the C-koren's youth choir "Cantilene" under Luc Anthonis, instead. Luc is one of Belgium's finest choir conductors, and so I remained a member until my 26th birthday when, again, I was deemed too old to remain a member of that choir. At this point, the next choir in line was "Con Amore", a choir that does not have an age limit, but which in practice consists of mostly people who are retired (or nearly so, at least). As a result, most people who leave Cantilene do not join Con Amore, instead ending their foray into choral music. I was no exception. However, a year and a half (or so) later, the C-koren were extended with a new choir, "Caljent ", who jumpstarted their membership by contacting ex-Cantilene members (me amongst them), inviting them to join this new choir. I have been a member since the first official rehearsal of Caljent , and have always enjoyed it; enough so that when I moved out of Ekeren some five years ago, into a flat in Mechelen (a 30 minute car trip away), I did not quit the choir. I can, however, not deny that since moving out, my connection to Ekeren has become fairly strained, and that there have been times when I felt it difficult to motivate myself into driving all the way there for a rehearsal on friday night. I felt that to be unfair towards the conductor and towards the other members of the choir, and so it is with mixed feelings that I decided a month or so ago to remain a member only until the last rehearsal before the summer break this year. That last rehearsal was today (well, technically yesterday by now); and so, after a "career" of almost 20 years of nearly uninterrupted membership (including one 5-year stint as a member of Cantilene's governing board), I am now no longer a member of the C-koren. That's not to say I won't be singing anymore in fact, I've already joined a different choir whose rehearsal location just happens to be right around the corner from where I live but it does certainly feel weird to be putting an end to my C-koren membership. Ah well, we'll see what the future brings.

I've set up a windows machine yesterday (& today since this takes so long). on my own old laptop. at home. & it's running in my apartment. feels strange after living in windows-free apartments for quite some years. & I'm still not sure how I feel about it. the purpose of resurrecting my old laptop is to run a CPAN smoke tester. there are constant complaints in the perl community about the low amount of test reports from windows installations (& for older distributions, so I'm running CPAN::Reporter::Smoker with 'reverse' => 1, at least once). for the time being, I'm using non-free software to improve free software. let's see how this develops ps: I'm also running a CPAN smoke tester on my raspberry pi (under raspbian with a perlbrewed perl) since a few days. it's a bit slow but well :)

Seeing this piece in the news, about how Debian-Multimedia.org is now unsafe, I was reminded we don't have a tool to manipulate sources.lists entries. For example:

$ apt-sources list
..
deb http://ftp.uk.debian.org/debian/ squeeze main non-free contrib
deb-src http://ftp.uk.debian.org/debian/ squeeze main
deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main
..

How about listing only my repos?

$ apt-sources list steve.org.uk
deb-src http://packages.steve.org.uk/firefox-wrapper/squeeze/ ./
deb     http://packages.steve.org.uk/firefox-wrapper/squeeze/ ./
deb     http://packages.steve.org.uk/meta/squeeze/ ./
deb-src http://packages.steve.org.uk/meta/squeeze/ ./
deb-src http://packages.steve.org.uk/minidlna/squeeze/ ./
deb     http://packages.steve.org.uk/minidlna/squeeze/ ./

Now add in a command to delete lines matching a given pattern:

# apt-sources delete debian-multimedia.org

Doesn't that seem like a tool that should exist? I've added this quick hack to this repository which you can submit pull requests against, or use as a base. TODO: Write the "add" handler. Neaten. Ever felt jealous that Ubuntu users can add PPAs? Nows your chance to do something like this:

# apt-sources add "deb http://packages.steve.org.uk/lumail/wheezy/ ./"

The unofficial third party repository Debian Multimedia stopped using the domain debian-multimedia.org some months ago. The domain expired and it is now registered again by someone unknown to Debian. (If we're wrong on this point, please sent us an email so we can take over the domain! ;) ) This means that the repository is no longer safe to use, and you should remove the related entries from your sources.list file. After all, the need of an external repository for multimedia related packages has been greatly reduced with the release of Wheezy, which features many new and updated codecs and multimedia players. Not sure if you're using the debian-multimedia repository? You can easily check it by running: grep -i debian-multimedia.org /etc/apt/sources.list /etc/apt/sources.list.d/* If you can see debian-multimedia.org line in output, you should remove all the lines including it.

Dear lazyweb, my Nexus 4 just ate a brick and the screen is so broken that the capacitative sensing stopped working completely. That sucks a bit, especially considering that you can't really replace the screen according to ifixit... What sucks more is this: As my phone is both encrypted and passphrase-protected, I can't access my photos. Yes, yes, I should have set up git-annex on it by now, but that's of no help now. So... How do I get my data off of that phone? Again, I don't really care about much other than my photos.

Weblate is now year and half old, has quite many users and almost all features I wanted it to have. Now it's time to push it further to fit also other projects. Therefore I've decided to try crowdfunding on Catincan to see which of requested features are actually wanted most. Yes, you can vote with your money :-). The first set of features to fund is:

• Federated login using Facebook, Google, GitHub etc.
• Source strings tracking to improve experience for developers with source strings changes or prioritization
• Voting for suggestions to better support larger translation teams

This is my first experiment with crowdfunding, so I'm looking forward to it's results.

Filed under: English Weblate 0 comments Flattr this!

Another maintenance release of inline is now on CRAN and in already included in Debian. This release was triggered by a change in the development version of R which removed an argument to package.skeleton(). The complete NEWS entry is below.

Changes in inline version 0.3.12 (2013-06-12)

• Align package.skeleton with the R-devel version of the function which no longer has a NAMESPACE argument.
• Remove copy of LGPL in source archive as R CMD check now complains about it. License status continues to be specified in file DESCRIPTION.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. A few more details are available at the R-Forge page.

Hello Config::Model::Dpkg project (a Debian source package model based on Config::Model) is partly based on a ParseRec::Descent grammar. This grammar is used to parse the dependency of a Debian source package. This article will show how such a grammar is written, its limitation regarding error handling and how to improve the situation. Debian package main data is described in debian/control file. This file can feature a list of dependencies, i.e. a list of package that must be installed for the package to work. These dependencies are declared in fields like Build-Depends , or Depends as a list of package. For Dpkg model purpose, I needed only to parse one item of a dependency list at a time. This dependency item can be a simple package name: foo or a package name with a version requirement: foo ( > 1.24 ) or a package name with architectures restrictions: foo [alpha amd64 hurd-arm linux-armeb] or both: foo ( > 1.24 ) [alpha amd64 hurd-arm linux-armeb] or a list of alternate choices combining the possibilities above: foo ( > 1.24 ) bar [ linux-any] baz ( << 3.14 ) [ ! hurd-armel !hurd-armeb ] or a variable that is replaced during package build: $ perl-depends Writing a Parse::RecDescent grammar to parse this is relatively straightforward. The first production handles alternate dependencies separated by and raises an error if some text was not consumed by the dependencies:

dependency_item: depend(s /\ /) eofile  

A dependency as explained above is expressed as:

depend: pkg_dep   variable

A variable like $ foo or $ bar -1.24~ is parsed with:

variable: /\$ [\w:\-]+ [\w\.\-~+]*/

This rule handles a package name with optional version or arch restriction:

pkg_dep: pkg_name dep_version(?) arch_restriction(?) 
pkg_name: /[a-z0-9][a-z0-9\+\-\.]+/

The remaining rules are quite simple:

dep_version: '(' oper version ')' 
oper: '<<'   '<='   '='   '>='   '>>'
version: variable   /[\w\.\-~:+]+/
arch_restriction: '[' arch(s) ']'
arch:  /!?[\w-]+/
eofile: /^\Z/

The grammar above works well to parse the dependency. You can test it with this small Perl script:

#!/usr/bin/perl
use strict;
use warnings;
use 5.010 ;
use Parse::RecDescent ;
my $parser = Parse::RecDescent->new(join('',));
my $dep = shift ;
say "parsing '$dep'";
my $ret = $parser->dependency_item($dep) ;
say "result is ", $ret if $ref ;
__DATA__
# insert grammar here !!!

Unfortunately, any error in the optional parts (i.e version requirements and arch restriction) leads to an error message which is not very helpful. The error message only mention that some text could not be parsed:

parsing 'foo ( != 1.24 )   bar'
       ERROR (line 1): Invalid dependency item: Was expecting /\ / but found
                       "( != 1.24 )   bar" instead

or

parsing 'foo [ arm & armel]   bar'
       ERROR (line 1): Invalid dependency item: Was expecting /\ / but found
                       "[ arm & armel]   bar" instead

The problem comes from the fact that version requirements or arch restrictions are optional. For instance if a version requirement has a syntax error, Parse::RecDescent will try to parse it as an arch restriction. This arch restriction rule will also fail and the last terminal ( eofile ) will fail. So the error message does not hint at the actual syntax problem. To generate better error messages, I improved the suggestion made in Parse::RecDescent FAQ. Instead of calling a plain subroutine, I use a sub reference that will store the error messages in a closure. This sub ref is declared in a start-up action. Note that the sub ref explicitly returns undef. I ll explain why later.

 
    my @dep_errors ;
    my $add_error = sub  
        my ($err, $txt) = @_ ;
        push @dep_errors, "$err: '$txt'" ;
        return ;
      ;
 

The following production always fails while ensuring that the error list is reset. This production is always run at the beginning of the dependency parsing:

dependency:   @dep_errors = ();  

Here s the actual dependency production that is run when dependency method is called on the parser. It will return an array ref containing (1, data) if the dependency is valid or (0, errors) otherwise:

dependency: depend(s /\ /) eofile
   
    $return = [ 1 , @ $item[1]  ] ;
   
   
   
    push( @dep_errors, "Cannot parse: '$text'" ) unless @dep_errors ;
    $return =  [ 0, @dep_errors ];
   

The following productions don t change much:

depend: pkg_dep   variable
variable: /\$ [\w:\-]+ [\w\.\-~+]*/
pkg_dep: pkg_name dep_version(?) arch_restriction(?) 
dep_version: '(' oper version ')'

The first rule of this production parses the package name which must be followed by a space, end of string ( or ['. A positive look-ahead assertion is used so only the package name is consumed. If the first rule fails, the second rule provides a meaningful error message. The second rule will match anything which is not a space and create an error message. Since $add_error returns undef, the second rule returns undef and the production fails. So the text stored in the error message is not consumed:

pkg_name: /[a-z0-9][a-z0-9\+\-\.]+(?=\s \Z \( \[)/
      /\S+/   $add_error->("bad package name", $item[1]) ; 

The same trick is used with these productions:

oper: '<<'   '='   '>>'
      /\S+/   $add_error->("bad dependency version operator", $item[1]) ; 
version: variable   /[\w\.\-~:+]+(?=\s \) \Z)/
      /\S+/   $add_error->("bad dependency version", $item[1]) ; 

The action of this production is a little bit more tricky. The action ensures that '!' are either added before all arch or not at all. Otherwise an error message is generated and added to the list of errors:

arch_restriction: '[' osarch(s) ']'
     
        my $mismatch = 0;
        # $ref contains ['!',os,arch] or ['',os,arch]
        my $ref = $item[2] ;
        for (my $i = 0; $i < $#$ref -1 ; $i++ )  
            $mismatch  = ($ref->[$i][0] xor $ref->[$i+1][0]) ;
         
        my @a = map   ($_->[0]   '') . ($_->[1]   '') . $_->[2]   @$ref ;
        if ($mismatch)  
            $add_error->("some names are prepended with '!' while others aren't.", "@a") ;
         
        else  
            $return = 1 ;
         
     

The check above is possible only if the "osarch" production returns an array ref containing something like ('!','linux','any') for "!linux-any' or ('','linux','any') for "linux-any":

osarch: not(?) os(?) arch
     
        $return =  [ $item[1][0], $item[2][0], $item[3] ];
     
      /.?(?=\s \] \Z)/   $add_error->("bad arch specification: ", $item[1]) ;  
not: '!'

Here's the remaining of the grammar:

os: /(any uclibc-linux linux kfreebsd knetbsd etc...)-/
     /\w+/ '-'   $add_error->("bad os in architecture specification", $item[1]) ; 
arch: / (any  alpha amd64  arm\b  arm64  etc... )
        (?=(\]  ))
      /x
        /\w+/   $add_error->("bad arch in architecture specification", $item[1]) ; 
eofile: /^\Z/

That's all for grammar 2.0... Before someone yells: "Show me the message ! ", here are some example of bad dependencies and their error message generated by the parser:

parse 'foo ( != 1.24 )   bar'
result is: 0 bad dependency version operator: '!='
parsing 'foo [ arm & armel]   bar'
result is: 0 bad arch specification: : '&'
parsing 'foo [ arm armel ]   bar [!moo]'
result is: 0 bad arch specification: : ']' bad arch in architecture specification: 'moo'

The 2 first error messages are spot on the actual error. The second one has a false positive (']' is correct) but correctly highlights the wrong arch name ('moo'). Mission accomplished. In order to keep this post (relatively) simple, I've removed the part that actually store parsed data. They don't really matter for error handling. Nevertheless, you may see the whole grammar in Config::Model::Dpkg::Dependency module. All the best
Tagged: Config::Model, debian, dpkg, package, Parse::RecDescent, Perl

With the new gitweb version available on alioth after the upgrade to wheezy (thanks to the alioth admins for their work on alioth), there is a new feature available I want to advertise a bit here: listing only a subtree of all repositories. Before now one could only either look at a specific repository or get the list of all repositories and the list of all repositories is quite large and slow. With the new feature you can link to all the repositories in your alioth project. For example in reprepro's case that is http://anonscm.debian.org/gitweb/?pf=mirrorer. Much more I missed what is now possible with the link http://anonscm.debian.org/gitweb/?pf=debian-science: getting a list of all debian-science repositories (still slow enough, but much better than the full list).