Petter Reinholdtsen

Sleep until morning - home automation for the kids
10th February 2013

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.

Tags: english.
Hva stemte hver stortingsrepresentant i voteringene om datalagringsdirektivet?
9th February 2013

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.

Tags: norsk, personvern, stortinget, surveillance.
Økt overvåkning applauderes igjen av Arbeiderpartiet, Høyre og Fremskrittspartiet
4th February 2013

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.

Tags: norsk, personvern, surveillance.
Bitcoin GUI now available from Debian/unstable (and Ubuntu/raring)
2nd February 2013

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.

Tags: bitcoin, debian, english.
Welcome to the world, Isenkram!
22nd January 2013

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.

Tags: debian, english, isenkram.
First prototype ready making hardware easier to use in Debian
21st January 2013

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:

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.

Tags: debian, english, isenkram.
Thank you Thinkpad X41, for your long and trustworthy service
19th January 2013

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.:)

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.

Tags: debian, english.
How to find a browser plugin supporting a given MIME type
18th January 2013

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.

Tags: debian, english.
What is the most supported MIME type in Debian?
16th January 2013

The DEP-11 proposal to add AppStream information to the Debian archive, is a proposal to make it possible for a Desktop application to propose to the user some package to install to gain support for a given MIME type, font, library etc. that is currently missing. With such mechanism in place, it would be possible for the desktop to automatically propose and install leocad if some LDraw file is downloaded by the browser.

To get some idea about the current content of the archive, I decided to write a simple program to extract all .desktop files from the Debian archive and look up the claimed MIME support there. The result can be found on the Skolelinux FTP site. Using the collected information, it become possible to answer the question in the title. Here are the 20 most supported MIME types in Debian stable (Squeeze), testing (Wheezy) and unstable (Sid). The complete list is available from the link above.

Debian Stable:

  count MIME type
  ----- -----------------------
     32 text/plain
     30 audio/mpeg
     29 image/png
     28 image/jpeg
     27 application/ogg
     26 audio/x-mp3
     25 image/tiff
     25 image/gif
     22 image/bmp
     22 audio/x-wav
     20 audio/x-flac
     19 audio/x-mpegurl
     18 video/x-ms-asf
     18 audio/x-musepack
     18 audio/x-mpeg
     18 application/x-ogg
     17 video/mpeg
     17 audio/x-scpls
     17 audio/ogg
     16 video/x-ms-wmv

Debian Testing:

  count MIME type
  ----- -----------------------
     33 text/plain
     32 image/png
     32 image/jpeg
     29 audio/mpeg
     27 image/gif
     26 image/tiff
     26 application/ogg
     25 audio/x-mp3
     22 image/bmp
     21 audio/x-wav
     19 audio/x-mpegurl
     19 audio/x-mpeg
     18 video/mpeg
     18 audio/x-scpls
     18 audio/x-flac
     18 application/x-ogg
     17 video/x-ms-asf
     17 text/html
     17 audio/x-musepack
     16 image/x-xbitmap

Debian Unstable:

  count MIME type
  ----- -----------------------
     31 text/plain
     31 image/png
     31 image/jpeg
     29 audio/mpeg
     28 application/ogg
     27 image/gif
     26 image/tiff
     26 audio/x-mp3
     23 audio/x-wav
     22 image/bmp
     21 audio/x-flac
     20 audio/x-mpegurl
     19 audio/x-mpeg
     18 video/x-ms-asf
     18 video/mpeg
     18 audio/x-scpls
     18 application/x-ogg
     17 audio/x-musepack
     16 video/x-ms-wmv
     16 video/x-msvideo

I am told that PackageKit can provide an API to access the kind of information mentioned in DEP-11. I have not yet had time to look at it, but hope the PackageKit people in Debian are on top of these issues.

Update 2013-01-16 13:35: Updated numbers after discovering a typo in my script.

Tags: debian, english.
Using modalias info to find packages handling my hardware
15th January 2013

Yesterday, I wrote about the modalias values provided by the Linux kernel following my hope for better dongle support in Debian. Using this knowledge, I have tested how modalias values attached to package names can be used to map packages to hardware. This allow the system to look up and suggest relevant packages when I plug in some new hardware into my machine, and replace discover and discover-data as the database used to map hardware to packages.

I create a modaliases file with entries like the following, containing package name, kernel module name (if relevant, otherwise the package name) and globs matching the relevant hardware modalias.

Package: package-name
Modaliases: module(modaliasglob, modaliasglob, modaliasglob)

It is fairly trivial to write code to find the relevant packages for a given modalias value using this file.

An entry like this would suggest the video and picture application cheese for many USB web cameras (interface bus class 0E01):

Package: cheese
Modaliases: cheese(usb:v*p*d*dc*dsc*dp*ic0Eisc01ip*)

An entry like this would suggest the pcmciautils package when a CardBus bridge (bus class 0607) PCI device is present:

Package: pcmciautils
Modaliases: pcmciautils(pci:v*d*sv*sd*bc06sc07i*)

An entry like this would suggest the package colorhug-client when plugging in a ColorHug with USB IDs 04D8:F8DA:

Package: colorhug-client
Modaliases: colorhug-client(usb:v04D8pF8DAd*)

I believe the format is compatible with the format of the Packages file in the Debian archive. Ubuntu already uses their Packages file to store their mappings from packages to hardware.

By adding a XB-Modaliases: header in debian/control, any .deb can announce the hardware it support in a way my prototype understand. This allow those publishing packages in an APT source outside the Debian archive as well as those backporting packages to make sure the hardware mapping are included in the package meta information. I've tested such header in the pymissile package, and its modalias mapping is working as it should with my prototype. It even made it to Ubuntu Raring.

To test if it was possible to look up supported hardware using only the shell tools available in the Debian installer, I wrote a shell implementation of the lookup code. The idea is to create files for each modalias and let the shell do the matching. Please check out and try the hw-support-lookup shell script. It run without any extra dependencies and fetch the hardware mappings from the Debian archive and the subversion repository where I currently work on my prototype.

When I use it on a machine with a yubikey inserted, it suggest to install yubikey-personalization:

% ./hw-support-lookup
yubikey-personalization
%

When I run it on my Thinkpad X40 with a PCMCIA/CardBus slot, it propose to install the pcmciautils package:

% ./hw-support-lookup
pcmciautils
%

If you know of any hardware-package mapping that should be added to my database, please tell me about it.

It could be possible to generate several of the mappings between packages and hardware. One source would be to look at packages with kernel modules, ie packages with *.ko files in /lib/modules/, and extract their modalias information. Another would be to look at packages with udev rules, ie packages with files in /lib/udev/rules.d/, and extract their vendor/model information to generate a modalias matching rule. I have not tested any of these to see if it work.

If you want to help implementing a system to let us propose what packages to install when new hardware is plugged into a Debian machine, please send me an email or talk to me on #debian-devel.

Tags: debian, english, isenkram.

RSS feed

Created by Chronicle v4.6