Petter Reinholdtsen

Here in Norway, electronic invoices are spreading, and the solution promoted by the Norwegian government require that invoices are sent through one of the approved facilitators, and it is not possible to send electronic invoices without an agreement with one of these facilitators. This seem like a needless limitation to be able to transfer invoice information between buyers and sellers. My preferred solution would be to just transfer the invoice information directly between seller and buyer, for example using SMTP, or some HTTP based protocol like REST or SOAP. But this might also be overkill, as the "electronic" information can be transferred using paper invoices too, using a simple bar code. My bar code encoding of choice would be QR codes, as this encoding can be read by any smart phone out there. The content of the code could be anything, but I would go with the vCard format, as it too is supported by a lot of computer equipment these days.

The vCard format support extentions, and the invoice specific information can be included using such extentions. For example an invoice from SLX Debian Labs (picked because we ask for donations to the Debian Edu project and thus have bank account information publicly available) for NOK 1000.00 could have these extra fields:

X-INVOICE-NUMBER:1
X-INVOICE-AMOUNT:NOK1000.00
X-BANK-ACCOUNT-NUMBER:16040884339
X-BANK-IBAN-NUMBER:NO8516040884339
X-BANK-SWIFT-NUMBER:DNBANOKKXXX

The X-BANK-ACCOUNT-NUMBER field was proposed in a stackoverflow answer regarding how to put bank account information into a vCard.

The complete vCard could look like this:

BEGIN:VCARD
VERSION:2.1
ORG:SLX Debian Labs Foundation
ADR;WORK:;;Gunnar Schjelderups vei 29D;OSLO;;0485;Norway
URL;WORK:http://www.linuxiskolen.no/slxdebianlabs/
EMAIL;PREF;INTERNET:sdl-styret@rt.nuug.no
REV:20130212T095000Z
X-INVOICE-NUMBER:1
X-INVOICE-AMOUNT:NOK1000.00
X-BANK-ACCOUNT-NUMBER:16040884339
X-BANK-IBAN-NUMBER:NO8516040884339
X-BANK-SWIFT-NUMBER:DNBANOKKXXX
END:VCARD

The resulting QR code created using qrencode would look like this, and should be readable (and thus checkable) by any smart phone, or for example the zbar bar code reader and feed right into the approval and accounting system.

The extension fields will most likely not show up in any normal vCard reader, so those parts would have to go directly into a system handling invoices. I am a bit unsure how vCards without name parts are handled, but a simple test indicate that this work just fine.

For et halvt år siden satte jeg opp et system for å lage en database med informasjon om offentlige anbud fra Doffin ved hjelp av Scraperwiki. Nå er databasen så vidt jeg kan se komplett, med data helt tilbake til 2008. Her er litt statistikk over antall anbud publisert hver måned:

Publiseringsmåned	Antall
2013-01	1015
2012-12	756
2012-11	979
2012-10	1093
2012-09	1023
2012-08	951
2012-07	1103
2012-06	1334
2012-05	1435
2012-04	1169
2012-03	1573
2012-02	1335
2012-01	1147
2011-12	1045
2011-11	1114
2011-10	1230
2011-09	1165
2011-08	966
2011-07	1148
2011-06	1410
2011-05	1536
2011-04	1350
2011-03	1574
2011-02	1370
2011-01	1049
2010-12	992
2010-11	1089
2010-10	1110
2010-09	1132
2010-08	883
2010-07	1126
2010-06	1440
2010-05	1236
2010-04	1249
2010-03	1556
2010-02	1256
2010-01	1140
2009-12	1013
2009-11	1220
2009-10	1320
2009-09	1294
2009-08	953
2009-07	1162
2009-06	1605
2009-05	1568
2009-04	1522
2009-03	1599
2009-02	1376
2009-01	1080
2008-12	1028
2008-11	949
2008-10	1047
2008-09	965
2008-08	725
2008-07	1015
2008-06	1304
2008-05	323

Her er tilsvarende tall per år, som viser en liten nedgang i antall anbud:

Publiseringsår	Antall
2012	13898
2011	14957
2010	14209
2009	15712
2008	7356

Jeg droppet den ufullstendige måneden og året fra tabellen. Se lenken for oppdaterte tall.

With kids in the house, one challenge is getting them to sleep during the night and wake up when it is morning. I mean, when I believe it is morning, and not two hours earlier. In our household we have decided that 07:00 is the turning point, but getting the kids to sleep until 07:00 is a small challenge every day. They have adapted quite well, and rarely wake up at 05:00 any more, but some times wake up at times like 05:50, 06:15, 06:30 or 06:45, and it is hard to put the awake one to bed again without disturbing and waking the rest. And I understand perfectly well that they fail to sleep until 07:00 some times, as there is no way for them to know if it is before or after the magic moment without coming and asking us parents.

But yesterday I came up with a method to solve this problem. It involve home automation. A few years ago I bought a Tellstick and RF switches at the local Clas Ohlson shop, allowing me to control lights and other electrical gadgets using my Linux server. When I moved from the old flat to a small house, I put away all this equipment as most of the lighting in the house was not using wall sockets and thus not easy to connect to the gadgets I had. But recently I bought a Tellstick Net to be able to read sensor input as well as control power sockets. I want to control ovens in the basement to avoid the pipes to freeze, and monitor the humidity to detect flooding. The default setup for Tellstick Net is to be controlled by the vendor web service, which to me is a security problem, but it is also possible to build ones own firmware with local access instead of being controlled by a Swedish company, thanks to the release of the GPL licensed firmware source code. I plan to get that running before I let it control anything important. But while working on this, one idea to make it easier for the kids came to me yesterday. We can set up a night light controlled by the computer, and turn it automatically on at 07:00. The kids can then check the light in the morning to know if they are supposed to get up or not. They joined me in setting everything up, and I repeated the concept several times before bed times to make sure they remembered to check the light before getting up in the morning.

We tested it this morning, and all the kids stayed in bed until after 07:00, and every one of them commented on the fact that the "morning light" was turned on and signalled that the morning had arrived. So this look like a success, and I am excited to see how this develops the next few days. :) I really hope this can allow us all to sleep a bit longer in the morning.

A nice advantage of this setup is that we can remote control when to tell the kids to get up. We do not have to wait until 07:00, and can also delay it if we want to.

Nytt stortingsvalg er på trappene, og folket får igjen mulighet til å påvirke sammensetningen i vår lovgivende forsamling. Da er det relevant å vite hvilke representanter og partier som har støttet innføringen av brev- og besøkskontroll av hele den norske befolkningen, det vil si datalagringsdirektivet.

Hvis du vil vite hva hver enkelt stortingsrepresentant har stemt i stortingsvoteringene om datalagringsdirektivet, så har nettstedet til Holder De Ord den (så vidt jeg vet) eneste komplette oversikten på sin temaside om innføringen av datalagringsdirektivet. Den har detaljene fra de 11 relevante forslagene som har vært fremmet så lagt. De har vært votert over 2011-04-04, 2011-04-11, 2012-06-11, 2012-10-05 og 2012-12-06.

Hvis du lurer på hva som er problemet med datalagringsdirektivet, anbefaler jeg å lese artiklene fra Jon Wessel-Aas om temaet, samt informasjon fra foreningen Digitalt Personvern.

Jeg ser med gru at Arbeiderpartiet, Høyre og Fremskrittspartiet applauderer tollvesenets forslag om å øke overvåkningen i Norge nok et hakk. Det er ikke så rart, da de som uttaler seg jo også har støttet innføringen av datalagringsdirektivet eller i hvert fall ikke veldig aktivt har motarbeidet det. Innføringen av datalagringsdirektivet er en lovendring som innebærer brev og besøkskontroll for hele befolkningen.

Datalagringsdirektivet har vært oppe til votering i stortinget tre ganger så langt. Det ble vedtatt første gang 2011-04-04 og andre gang 2011-04-11 (lovendringer voteres to ganger), og forslag om å stoppe loven ble nedstemt 2012-12-06 (se også oversikt fra Holder De Ord).

Jan Bøhler i Arbeiderpartiet stemte for å innføre datalagringsdirektivet i lovverket i første votering, var ikke tilstede i andre votering og støttet loven i tredje votering. André Oktay Dahl i Høyre var ikke til stede i første og andre votering men støttet loven i tredje votering. Ulf Leirstein i Fremskrittspartiet stemte mot loven i første votering men var ikke til stede i andre og tredje votering.

Hvis du lurer på hva som er problemet med datalagringsdirektivet, anbefaler jeg å lese artiklene fra Jon Wessel-Aas om temaet, samt informasjon fra foreningen Digitalt Personvern.

Oppdatering 2013-03-09: Endret lenke til Holder De Ord, som har byttet mange lenker i forbindelse med import av voteringsdata for 2010-2011.

My last bitcoin related blog post mentioned that the new bitcoin package for Debian was waiting in NEW. It was accepted by the Debian ftp-masters 2013-01-19, and have been available in unstable since then. It was automatically copied to Ubuntu, and is available in their Raring version too.

But there is a strange problem with the build that block this new version from being available on the i386 and kfreebsd-i386 architectures. For some strange reason, the autobuilders in Debian for these architectures fail to run the test suite on these architectures (BTS #672524). We are so far unable to reproduce it when building it manually, and no-one have been able to propose a fix. If you got an idea what is failing, please let us know via the BTS.

One feature that is annoying me with of the bitcoin client, because I often run low on disk space, is the fact that the client will exit if it run short on space (BTS #696715). So make sure you have enough disk space when you run it. :)

As usual, if you use bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Yesterday, I asked for testers for my prototype for making Debian better at handling pluggable hardware devices, which I set out to create earlier this month. Several valuable testers showed up, and caused me to really want to to open up the development to more people. But before I did this, I want to come up with a sensible name for this project. Today I finally decided on a new name, and I have renamed the project from hw-support-handler to this new name. In the process, I moved the source to git and made it available as a collab-maint repository in Debian. The new name? It is Isenkram. To fetch and build the latest version of the source, use

git clone http://anonscm.debian.org/git/collab-maint/isenkram.git
cd isenkram && git-buildpackage -us -uc

I have not yet adjusted all files to use the new name yet. If you want to hack on the source or improve the package, please go ahead. But please talk to me first on IRC or via email before you do major changes, to make sure we do not step on each others toes. :)

If you wonder what 'isenkram' is, it is a Norwegian word for iron stuff, typically meaning tools, nails, screws, etc. Typical hardware stuff, in other words. I've been told it is the Norwegian variant of the German word eisenkram, for those that are familiar with that word.

Update 2013-01-26: Added -us -us to build instructions, to avoid confusing people with an error from the signing process.

Update 2013-01-27: Switch to HTTP URL for the git clone argument to avoid the need for authentication.

Early this month I set out to try to improve the Debian support for pluggable hardware devices. Now my prototype is working, and it is ready for a larger audience. To test it, fetch the source from the Debian Edu subversion repository, build and install the package. You might have to log out and in again activate the autostart script.

The design is simple:

• Add desktop entry in /usr/share/autostart/ causing a program hw-support-handlerd to start when the user log in.
• This program listen for kernel events about new hardware (directly from the kernel like udev does), not using HAL dbus events as I initially did.
• When new hardware is inserted, look up the hardware modalias in the APT database, a database available via HTTP and a database available as part of the package.
• If a package is mapped to the hardware in question, the package isn't installed yet and this is the first time the hardware was plugged in, show a desktop notification suggesting to install the package or packages.
• If the user click on the 'install package now' button, ask aptdaemon via the PackageKit API to install the requrired package.
• aptdaemon ask for root password or sudo password, and install the package while showing progress information in a window.

I still need to come up with a better name for the system. Here are some screen shots showing the prototype in action. First the notification, then the password request, and finally the request to approve all the dependencies. Sorry for the Norwegian Bokmål GUI.

The prototype still need to be improved with longer timeouts, but is already useful. The database of hardware to package mappings also need more work. It is currently compatible with the Ubuntu way of storing such information in the package control file, but could be changed to use other formats instead or in addition to the current method. I've dropped the use of discover for this mapping, as the modalias approach is more flexible and easier to use on Linux as long as the Linux kernel expose its modalias strings directly.

Update 2013-01-21 16:50: Due to popular demand, here is the command required to check out and build the source: Use 'svn checkout svn://svn.debian.org/debian-edu/trunk/src/hw-support-handler/; cd hw-support-handler; debuild'. If you lack debuild, install the devscripts package.

Update 2013-01-23 12:00: The project is now renamed to Isenkram and the source moved from the Debian Edu subversion repository to a Debian collab-maint git repository. See build instructions for details.

This Christmas my trusty old laptop died. It died quietly and suddenly in bed. With a quiet whimper, it went completely quiet and black. The power button was no longer able to turn it on. It was a IBM Thinkpad X41, and the best laptop I ever had. Better than both Thinkpads X30, X31, X40, X60, X61 and X61S. Far better than the Compaq I had before that. Now I need to find a replacement. To keep going during Christmas, I moved the one year old SSD disk to my old X40 where it fitted (only one I had left that could use it), but it is not a durable solution.

My laptop needs are fairly modest. This is my wishlist from when I got a new one more than 10 years ago. It still holds true.:)

• Lightweight (around 1 kg) and small volume (preferably smaller than A4).
• Robust, it will be in my backpack every day.
• Three button mouse and a mouse pin instead of touch pad.
• Long battery life time. Preferable a week.
• Internal WIFI network card.
• Internal Twisted Pair network card.
• Some USB slots (2-3 is plenty)
• Good keyboard - similar to the Thinkpad.
• Video resolution at least 1024x768, with size around 12" (A4 paper size).
• Hardware supported by Debian Stable, ie the default kernel and X.org packages.
• Quiet, preferably fan free (or at least not using the fan most of the time).

You will notice that there are no RAM and CPU requirements in the list. The reason is simply that the specifications on laptops the last 10-15 years have been sufficient for my needs, and I have to look at other features to choose my laptop. But are there still made as robust laptops as my X41? The Thinkpad X60/X61 proved to be less robust, and Thinkpads seem to be heading in the wrong direction since Lenovo took over. But I've been told that X220 and X1 Carbon might still be useful.

Perhaps I should rethink my needs, and look for a pad with an external keyboard? I'll have to check the Linux Laptops site for well-supported laptops, or perhaps just buy one preinstalled from one of the vendors listed on the Linux Pre-loaded site.

Some times I try to figure out which Iceweasel browser plugin to install to get support for a given MIME type. Thanks to specifications done by Ubuntu and Mozilla, it is possible to do this in Debian. Unfortunately, not very many packages provide the needed meta information, Anyway, here is a small script to look up all browser plugin packages announcing ther MIME support using this specification:

#!/usr/bin/python
import sys
import apt
def pkgs_handling_mimetype(mimetype):
    cache = apt.Cache()
    cache.open(None)
    thepkgs = []
    for pkg in cache:
        version = pkg.candidate
        if version is None:
            version = pkg.installed
        if version is None:
            continue
        record = version.record
        if not record.has_key('Npp-MimeType'):
            continue
        mime_types = record['Npp-MimeType'].split(',')
        for t in mime_types:
            t = t.rstrip().strip()
            if t == mimetype:
                thepkgs.append(pkg.name)
    return thepkgs
mimetype = "audio/ogg"
if 1 < len(sys.argv):
    mimetype = sys.argv[1]
print "Browser plugin packages supporting %s:" % mimetype
for pkg in pkgs_handling_mimetype(mimetype):
    print "  %s" %pkg

It can be used like this to look up a given MIME type:

% ./apt-find-browserplug-for-mimetype 
Browser plugin packages supporting audio/ogg:
  gecko-mediaplayer
% ./apt-find-browserplug-for-mimetype application/x-shockwave-flash
Browser plugin packages supporting application/x-shockwave-flash:
  browser-plugin-gnash
%

In Ubuntu this mechanism is combined with support in the browser itself to query for plugins and propose to install the needed packages. It would be great if Debian supported such feature too. Is anyone working on adding it?

Update 2013-01-18 14:20: The Debian BTS request for icweasel support for this feature is #484010 from 2008 (and #698426 from today). Lack of manpower and wish for a different design is the reason thus feature is not yet in iceweasel from Debian.