I am no longer closely involved with the venerable, aging, and often renamed Hildon Application Manager; Víctor has very successfully
stepped into bigger shoes and is maintaining it now.  Nevertheless, I
can’t stop myself from giving a brief rundown of its new Fremantle
Read the rest of this entry »


Ok, this is a long one.  This was floating around my brain for a while, and it is time to lay it to rest.  Get a coffee and make yourself comfortable.

Scratchbox is a success, and life has adapted to its kinks.  Our software has formed calluses around the places where Scratchbox used to cause pain.

If all goes according to plan, then the Maemo SDK will move from Scratchbox 1 to Scratchbox 2 in the near future.  This might require our software to develop calluses in new places, but that is OK.  The benefits of SDK+ will hopefully outweigh the cost of switching.

So I think this is a good opportunity as any to take a look at what Scratchbox and the Maemo SDK get wrong, in my opinion.

The big sin of Scratchbox 1 is wanton redirection to places that are outside the target.  The Maemo SDK inherited that sin without questioning it, and I am afraid the Maemo SDK+ will continue with it, even tho Scratchbox 2 would allow us to repent.

By way of example, consider how Scratchbox and the Maemo SDKs handle “autoconf”.

The nice trick of Scratchbox 1 and 2 is to put you in an environment that looks and feels like a native ARM machine (say) by emulating the CPU, but processor-hungry tools like the compiler are still natively fast.  This trick is achieved by provisioning alternative binaries of the processor-hungry tools. These alternative binaries are functionally equivalent to the real ones, but they use the instruction set of the native CPU, not the emulated one.  Scratchbox magically executes them instead of the real binaries and thus avoids the emulation overhead.

So, how would you expect Scratchbox to handle autoconf, which is a shell script?

I would expect Scratchbox to do nothing about the /usr/bin/autoconf script itself.  The desired speed up comes from having a alternative binary for /bin/sh, the interpreter.

Still, Scratchbox has autoconf in /scratchbox/tools/bin/ and accesses to /usr/bin/autoconf get redirected to /scratchbox/tools/bin/autoconf. Why?

The only reason can be bootstrapping or more generally, supporting incomplete systems.  This is another basic trick of Scratchbox: you have a running autoconf even when your /usr/bin is still empty.  This can be a great help when breaking the cyclic dependencies so typical of bootstrapping.

But, do we need the redirection magic for this?  After all, if /usr/bin is empty, the shell will not find autoconf there and will not even attempt to run /usr/bin/autoconf.  That’s why /scratchbox/tools/bin is included in your PATH by default, and autoconf and a host of other much more useful tools such as ls, cp, and mkdir are available to you from there even if your root filesystem is empty.

But, as soon as you have bootstrapped your system enough to have its own mkdir or autoconf, Scratchbox should step back and hand control over to the growing system.  The emulation magic of Scratchbox will make sure that the system’s tools can be used even when they are compiled for a different architecture.

Thus, redirection is not really useful for bootstrapping or incomplete systems, and should not be used to make ghosts of binaries available in places that are really empty.  Stepping back and handing over control can then be as simple as putting /scratchbox/tools/bin at the end of PATH.

This is not what Scratchbox does, and I frankly don’t know why.  It’s easy to fix, by changing the default path and redirection rules, but still it puzzles me why the defaults for the Maemo SDK are the way they are.  Defaults matter a lot when build bots enter the picture that run the Maemo SDK in its default configuration.

The way Scratchbox tries to stay in control of your growing system, you might think it is jealous and doesn’t want it to grow up enough to become independent.  With the current setup, you are bound to grow not only incomplete, but also inconsistent systems that are forever bound to run nowhere else but in Scratchbox.

As a simple example, some portable programs hardcode the location of perl into their scripts.  If you need these programs during early phases of bootstrapping, before you have added perl itself to the system, they will pick up /scratchbox/tools/bin/perl and will happily go to work bootstrapping the system further.  Later, after bringing perl into the system, you will retrace the dependency cycle so that the programs will now hardcode /usr/bin/perl into their scripts, the real location of perl in the system that you are building.  With the default Scratchbox, this is not what is happening: even on the second round, the programs will hardcode /scratchbox/tools/bin/perl.  This of course will not work when the program is running in a real Maemo device that only has /usr/bin/perl.

(Incidentally, some scripts in the Maemo SDK+ rootstraps still refer to programs in /scratchbox/tools/bin.)

Worse, Scratchbox’s Perl might be sufficiently different from the one you want to have in your system, courtesy of devkits being a notoriously hard to maintain and slow distribution mechanism.

The same thing continues to happen even if bootstrapping should be long over.  Essentially, what used to be a perfectly portable program has to changed to compile correctly in the Maemo SDK.  This is a useless activity, much more useless than making a program cross-compilable.

Thus, /scratchbox/tools/bin etc should be at the end of PATH.  But, that is not enough: Scratchbox will still redirect /usr/bin/perl to /scratchbox/bin/perl and you still have to fight against the core devkit.  Except now everything turns to magic, “which” is lying to you, and you can spend the better part of the day figuring out why things don’t behave the way you expect them to.

So, redirection is useless and harmful and the default PATH inside Scratchbox is wrong.

But what about the first trick, avoiding the expensive CPU emulation for processor-hungry programs like the compiler?  The speedup is crucial and it is worth to tolerate a bit of redirection ugliness to get it.  If we can get the speedup in a non-ugly way, that would be better.

The first important thing to realize is that the list of binaries to speed up can be quite short and very explicit: /bin/sh, the coreutils, /usr/bin/make, /usr/bin/perl, /usr/bin/m4, /usr/lib/gcc/*/cc1, /usr/lib/gcc/*/cc1plus, /usr/bin/as, and /usr/bin/ld should get us pretty far.  It might even be enough.  There is no point to try to speed up interpreted programs and libraries like shell scripts and Perl modules.  Bootstrapping is over, the point of redirecting /usr/bin/perl is to speed it up, not because we don’t have it yet.

The second important point is that to speed up /usr/bin/perl in this way, it has to be replaced with a functionally equivalent program. Same version, same compile time configuration, same everything except for the target instruction set.  Improving qemu to do some JITing with caching would be great.  Taking the configured source and compiling it again but this time for Intel is probably a more realistic approach for the time being.

In other words, I don’t want to use Scratchbox’s i386 Perl binary to speed up Maemo’s armel Perl binary.  I obviously want to use Maemo’s i386 Perl to speed up Maemo’s armel Perl.

I also don’t want to use Debian’s Perl to speed up Maemo’s Perl.  This is what the Maemo SDK+ is doing and it is equally as wrong as using Scratchbox’s Perl.

Scratchbox 2 is not so much redirecting executables, what it does is better described as assembling a new filesystem according to mapping rules.  It does this in a much cleaner and much more flexible way than Scratchbox 1.

What the Maemo SDK+ does with it, however, is to again shadow parts of Maemo freely and massively with things from outside of Maemo.  Almost everything comes from a Debian etch chroot.  Why?

This time, the reason seems to be that someone tried to learn a lesson from devkits.  Devkits are hard to keep up-to-date and people continuously complained about them being behind Debian.  So, the solution was to replace the devkits with Debian.

This is still missing the point, though: For people working on Maemo, Debian is just as hard to maintain as the devkits, even more so.  Just try to seriously answer the question which Debian distribution we should be using exactly for (half of) our build dependencies.  Stable? Come on, even devkits are more recent.  Testing?  Maybe, but why not unstable?  Maybe some packages from unstable and some from testing? Maybe people can decide on their own?

The complaint that devkits are out-of-date should be countered by removing devkits from the picture, but we shouldn’t stop there. General redirection to places outside of Maemo needs to stop.  Maemo itself should contain exactly what we need.  Build dependencies in devkits: bad, build dependencies in a distribution: hmmkay-ish.  Build dependencies in our own distribution: for the win!

We should not use Perl from Debian, we should use our own Perl.  It’s part of Maemo and not using it in the SDK is schizophrenic.  If we need something from Debian, we should import it and make it part of Maemo, explicitly and in a controlled way, like we have been doing it since the dawn of Maemo for packages that are primarily meant for the devices.

To put it another way: I want a simple setup that allows us to work on Maemo itself.  I don’t want a SDK that is a mix of packages from an old version of Debian and from Maemo, implemented via obscure and overly specific hacks to high level tools like dpkg-checkbuilddeps, and having to switch between under documented virtualization modes depending on whether I want to run “make all” or “make install”. Maemo can and should be big enough to contain its own build dependencies, and the virtualization tools should behave in a simple way.
So here is what I did as an experiment:

  • I installed the maemo SDK+ with both diablo_4.1.1 rootstraps.
  • I modified the configuration so that the armel rootstrap uses the i386 rootstrap as its “tool root”, and I disabled the gcc magic that Scratchbox 2 usually does.
  • I wrote a new mapping mode for Scratchbox 2 that essentially gives you the following layout:
    / -> diablo_4.1.1_armel rootstrap
    /home -> host
    /dev -> host
    /proc -> host
    /sys -> host
    /etc/passwd -> host
    /etc/resolv.conf -> host
    /usr/share/scratchbox2 -> host

At this point, you should have a working, fully emulated Diablo 4.1.1 environment. (Maybe this is the same as the “emulate” mode of Scratchbox 2, but I prefer to start from scratch in order to understand the magic better.)

You can compile stuff, but it is slow. Also, qemu is less than transparent and can’t seem to run /usr/bin/make, for example, which is a bit of a show stopper. Also also, find, xarg, and md5sum are missing and some tools expect /scratchbox/tools/bin to be there… oh well.

  • The following mappings make native binaries visible inside the Scratchbox target:
    /tools -> diablo_4.1.1_i386 rootstrap, read only
    /opt/maemo/ -> host
  • Then some symlinks for speed:

    /bin/bash -> /tools/bin/bash
    /usr/bin/make -> /tools/usr/bin/make
    /usr/bin/m4 -> /tools/usr/bin/m4
    /usr/bin/perl -> /tools/usr/bin/perl
  • Also for Perl .so modules:
    /usr/lib/perl/5.8/auto/File/Glob/Glob.so -> /tools/...
  • For the compiler, I made a small wrapper since as a cross compiler, it doesn’t dare to look into the standard places for header files and libraries. This needs to be done more cleanly and more thoroughly of course and maybe I should be using Scratchbox’s magic instead. But for now I prefer it explicit:
    #! /bin/sh
    $cc -I/usr/include -L/usr/lib -Wl,-rpath-link -Wl,/usr/lib "$@"

With this, “dpkg-buildpackage” runs successfully and with no real slowdown. I am happy.

Open issues:

  • Fakeroot doesn’t seem to work. (I used the fantastic “sb -R” to get around this. Love it. But fakeroot just needs to be there as well for completeness.)
  • The cross-compiler toolchain needs to move into Maemo and needs to be properly tuned.
  • Some tools needs to be written to manage the symlinks, maybe in cooperation with the actual packages whose binaries we redirect.
  • The Maemo warts need to be removed, such as the missing /usr/bin/find.

That’s it! Thanks for reading, and happy crossing!

Minimal debian/rules?

Thursday, 27. Nov 2008

$ ls -l ./debian/rules
lrwxrwxrwx 1 mvo mvo 11 2008-11-27 02:50 ./debian/rules -> /usr/bin/dh

Lintian is not happy.


$ cat debian/rules
dh $1

works, too, since everybody seems to run debian/rules via /bin/sh anyway.
Lintian still not happy.

We don’t need no education.

Sunday, 15. Jun 2008

Bruce Perens has a good reply to Ari Jaaksi’s keynote, but I am sure that the ‘bright line’ approach is not new to Nokia.

I have not heard the keynote and I haven’t seen a transscript yet, but unless proven wrong, I want to believe that Ari has been misunderstood: with enough determination, you can read what he says as an attack on the mobile phone industry: He might have wanted to say that parts of the Open Source and Free Software communities have a hard time imagining how utterly backwards and behind the mobile phone industry is.

(Just look at what happened when the 3G spectrum licenses were auctioned offInsanity.)

When Ari says “Why do we need closed vehicles? We do.”,  I read this as: “I know there are no good reason, only bad ones, let’s not waste time arguing about it and hope the bad reasons go away by themselves.”

When he says “As an industry, we plan to use open-source technologies, but we are not yet ready to play by the rules”, he can’t be implying that Nokia is not going to honor the licenses of code that they are using. They have to and they do.  Maybe he means that Nokia can not yet afford to speak out against DRM and device lock-down without being hypocritical, but he knows that people are hoping for such statements.

Yeah, I have nice rose-colored glasses.  I hope Ari clarifies his message in the near future.

(In any case, switching your code to GPLv3 seems like a good thing to do when you are worried about Nokia pulling a Tivo.)

Update: After taking off my rose-colored glasses, I saw this.  Well, what can I say.  Ari, I guess it is better if you let Quim do the talking.

A pleasant surprise.

Wednesday, 7. May 2008

I just upgraded a N800 from Chinook to a internal Diablo pre-release with apt-get. This was never supposed to work, but it just does anyway. Nice!

It’s also quite easy:

  • Put the device into R&D mode and disable the lifeguard reset.
  • Make sure you have a lot of free space in / and/or move the apt archive cache from /var/cache/apt/archives to a memory card.
  • Run apt-get install osso-software-version-rx34-unlocked in a shell that doesn’t die when the network goes down.
  • Make some coffee, walk the dogs, plant a tree.
  • Updated: Run flash-and-reboot and let it flash the kernel and initfs.
  • File bugs.

I hope we can soon announce the repository that you need for this, but I can’t make any promises.

History Meme

Saturday, 19. Apr 2008

$ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
1 emacs

(If you read this in Planet maemo, the formatting is farked up. Please read the original.)

Summary: A dot-install file for package “<goo>” in “maemo Extras” should
look like this:

repo_name = maemo Extras
repo_deb = deb http://repository.maemo.org/extras/ mistral free non-free
repo_deb_3 = deb http://repository.maemo.org/extras/ bora free non-free
catalogues = maemo-extras
package = <goo>

name = maemo Extras
uri = http://repository.maemo.org/extras/
components = free non-free

The only variable here is “<goo>”, the rest should be copied verbatim.
Specifically, you should not list any other repository besides
“maemo-extras”. (And make sure you have the trailing slash in the uri.)

Read on if you are bored or want to know why. Read the rest of this entry »

You might have noticed that OS2008 can now backup and restore the names of the packages that you have installed. The Application Manager can take that list and install them all at once. The catalogue configuration of the Application Manager is also backed up and restored, of course.

There is one (small?) snag, though: the pre-configured catalogues are not backed up. This seems to be the right thing to do since we can assume that the new image has a better idea of what the pre-configured catalogues should be than the backup. Unfortunately, the maemo Extras catalogue is pre-configured as “disabled”, and thus, since it is not included in a backup, you always have to enable it explicitly after flashing.

Let me say that again: after flashing, you need to enable the maemo Extras catalogue before being able to restore packages from it. Unfortunately, the first-boot procedure doesn’t give you the opportunity to do this. What will probably work quite well is to perform the restore on first-boot to get all your settings back, but to not accept the offer to install the applications right now. Then open the Application Manager manually, enable the maemo Extras catalogue, and select “Tools > Restore applications…”.

That’s an accident, of course, it’s not by design. Sorry for that. We’ll figure out something for the next release. The easiest thing is to just include the “maemo Extras” repository in the backup, I guess. But then again, why not include all pre-configured catalgues? What do you think?

[ The full blogging experience, this time drunken as a brick layer.. :-]

Today I want to excrete my approach to the tacky problem of what should be done about reaching the limits of limited resources. Please excuse my grammar etc since my IQ has temprorarily been reduced below that of aspell and I am not writing this with Emacs which reduces my degrees of mental freedom even more.

Users of the full Desktop experience that are running Gnome, KDE, Gnustep, or even fvwm on a modern piece of PC hardware don’t really have to worry about running out of resources. They configure their system to be adequate for their needs and generally accept the fact that running out of resources, while painful, is a problem that they have to solve by upgrading their system or by adjusting their choice of software to be more suitable. Thus is the life of the savvy computerer.

Running desktop software on mobile consumer devices, on the other hand, poses the immediate challenge of how to cope with limited resources in the hand of users that shouldn’t care less about the amount of RAM they have. Today, it is accepted that owners of an iPod make an informed decision of how much storage that glorified mp3-decoder-plus-amplifier has, but actually, Apple knows the customer and is marketing the things in t-shirt sizes: hundreds of songs, thousands of songs, millions of songs,

The point being: people understand that devices have a limited amount of resources and that more is most of the time better, but how much they really need in hard MiBs is quitet the mystery. But still, running out of resources is not a surprise. Everybody is used to running out of monay after all.

When it happens, tho, the experience of actually running out of space should be so pleasant that you go and buy the next bigger model instead of giving up on the whole fad of digital entertainment entirely.

In my opinion, Unix has done quite well with coping with limited resources, AS LONG AS there is a knowledgable system administrator available that can migrate home directories to a bigger disk array, etc.

But what about devices like the Nokia N800 that attempt to put half of Gnome in the hands of Joe Couchpotatoe, without a sysadmin to be found?

When Joe runs out of resources, he is not going to check /var/log/messages and order a bigger flash chip from Samsung and solder it in. Unless he is convinced that he just requested something impossible from his device, he is going to catapult his device into a corner and write an angry blog post about it. (Oh, how I miss the days when posting something to the whole world required more skill than piggybacking some memory…)

So, finally, what can be done about running out of resources? The following is what I have written into a bug report about GConf behaving erratically when there is no storage for it it save its database. I would like the maemo architecture to evolve along these ideas…

Read the rest of this entry »

I am trying out this blog thing, so that I can rant in color.

I work for Nokia on the Internet Tablet OS as a hacker, and that’s what I will be blogging about here. Or about whatever seems appropriate.

Our topic for today shall be a short introduction to the new Application Manager features in the next major IT OS release that are of interest to package maintainers. This stuff is documented in more detail here.

More .install file capabilities

A .install file can now instruct the Application Manager to add more than one catalogue.

You might have noticed that I don’t think that having as many repositories as we have now is a good idea, so please don’t take this feature as in invitation to spread your packages over many many repositories.  If at all possible, put your packages into the maemo Extras repository.  This repository will be preconfigured in the next IT OS release, and we will likely pay more attention to packages in the Extras repository when making new IT OS releases (when checking compatibility, for example).

You can now leave the distribution name blank in .install files and the Application Manager will provide the name of the current distribution.  This will work across backup/flash/restore: your catalogue will then automatically start using the new distribution name.

Catalogue names are now localizable.

Pretty names

A package can specify a (localizable) string that will be displayed in the Application Manager UI instead of the package name.

Upgrade descriptions

A package can specify a alternate (and localizable) description that will be used instead of the normal description when showing the package in the “Check for updates” view.  This can be considered as the end-user friendly version of debian/changelog.

Localizable descriptions

The normal description of a package can now be localized.

Support for Conflicts/Replaces

The Application Manager is still a coward when it comes to automatically removing packages to resolve conflicts, but it now will remove a package when another package is to be installed that both “Conflitcs” with that package as well as “Replaces” it.

Miscellaneous Flags

A package can cause the Application Manager to perform some special tricks.  For example, setting the “reboot” flag will cause a reboot after installing or upgrading a package.  Other flags cause the Application Manager to take a backup or close all applications.  These flags are mostly intended for updates to system packages, but you might find them useful.

Checking for free space before installing

A package can declare how much free space must be available in the filesystem before the installation is allowed.  The Application manager doesn’t dare to use Installed-Size for this since doing so is not reliable in general.


The Application Manager tries to keep track of where a package has been originally installed from, and will not allow updates to a package from a different source.  This means you can no longer replace IT OS packages by providing them with a higher version number in your repository.

Of course, you still can do whatever you want with your package.  Packages don’t get special privileges depending on where they are installed from.  These additional checks are only there to catch some confusing situations that are best avoided.