Re: sbox2 maemo
On 31/07/07 13:11 +0300, Lauri Leukkunen wrote: On 31/07/07 11:56 +0300, ext Marius Vollmer wrote: That way, all binaries can be replaced that are used a lot during compilation and are too slow to be emulated: /bin/sh, m4, awk, make, perl, gcc, binutils, but not much more. Packages like autoconf, automake, libtool are never redirected since they are interpreted anyway. You could implement this as a mapping mode for sb2, by simply doing export SBOX_MAPPING_MODE=your_mode you could switch to whatever you like. Just put your custom rules into scratchbox/shared/scratchbox2/redir_scripts/preload/your_mode and you're all set. You could take the current emulate mode as a template and start adding to that your exceptions. I'll add a command line switch for sb2 to support selecting the mapping mode. It's now in the sbox2 git. sb2 -m your_mode sb2 -e is equivalent to running sb2 -m emulate If you want to store your custom redir_scripts in $HOME/redir_scripts, you could setup a bash alias: alias sb2='sb2 -m your_mode -s $HOME/redir_scripts' then run sb2 as usual. To make maintenance easier you could make $HOME/redir_scripts/main.lua a symlink to the installed one. The mapping cache may sometimes fail to update itself correctly, deleting it manually from $BUILDROOT/.sb2cache will solve the problem. I'm working on fixing this. /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
Lauri Leukkunen [EMAIL PROTECTED] writes: On 31/07/07 11:56 +0300, ext Marius Vollmer wrote: Also, both sbox1 and sbox2 redirect whole packages, not just binaries (if I understand sbox2 correctly). E.g., when redirecting the perl command, the redirected-to perl will take its modules from the redirected-to prefix, not from the redirected-from prefix. It's all per-file based, you could write the sb2 rules so that only specific files are accessed from the host. It's all quite flexible. Hmm, the redirecting itself is quite trivial in my scenario: just make some symlinks. I'd rather not have a magic tool in the middle. Also, I don't want to access any files from the host except my home directory. Correct me if I am wrong: the main point of the redirection magic of sb2 is to fake chroot, no? That way, all binaries can be replaced that are used a lot during compilation and are too slow to be emulated: /bin/sh, m4, awk, make, perl, gcc, binutils, but not much more. Packages like autoconf, automake, libtool are never redirected since they are interpreted anyway. You could implement this as a mapping mode for sb2, Yes, I could. I also _could_ write my own FUSE filesystem that implements the mapping I want, or use symlinks or bind mounts. Right now, symlinks is all I need. by simply doing export SBOX_MAPPING_MODE=your_mode you could switch to whatever you like. Just put your custom rules into scratchbox/shared/scratchbox2/redir_scripts/preload/your_mode and you're all set. I know it's simple for you, but for me the value of sb2 is that it does something useful right out of the box. If I have to write my own rules in a language that I don't know for a system that doesn't have good documentation yet(!) just to get the effect of a couple of symlinks, I don't feel like doing it. Speaking of 'right out of the box': I understand that you are happy that sb2 is in Debian testing and that fact is actually what make me consider trying it out. Nut I'd say as long as there isn't a suitable version of qemu, libtool and a suitable toolchain also in Debian testing, sb2 is not there yet for me. (The toolchain from Codesourcery that I downloaded couldn't compile libtool's libltdl because dirent.h is not supported or something, and the toolchain for the maemo SDK wasn't supported by sb2 because of TLS data or something. I guess you are happy with your own toolchain; could you provide it for ia32 as well?) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
ext Lauri Leukkunen [EMAIL PROTECTED] writes: Continuing on the topic of build dependencies, SB2 has an open design issue regarding them. [...] I played a bit with sbox2 and I failed in the end, probably because I didn't use the right toolchain, but while doing that, a picture slowly formed in my head how I would like things to work. I don't like sbox1 because it redirects a lot of things into devkits, which are essentially untouchable and hard to update. Sbox2 is better since it redirects into the host system, which is much easier to maintain than the devkits. But it still redirects from one system to another. Also, both sbox1 and sbox2 redirect whole packages, not just binaries (if I understand sbox2 correctly). E.g., when redirecting the perl command, the redirected-to perl will take its modules from the redirected-to prefix, not from the redirected-from prefix. There are two reasons for redirecting: to avoid emulating the compiler and other build tools since that is quite slow, and for bootstrapping where you start with an empty root directory but still have all the tools at hand to fill it by compiling packages from source. I am not interested in bootstrapping from source here since that is not done very often in a binary distribution. To speed up build tools, it would be much better to only redirect the machine code files, and nothing else. I made a small experiment which should explain better what I have in mind. I made a sid armel chroot with debootstrap, copied a x86 qemu-arm into it together will all the needed libraries, and registered qemu-arm as a binfmt_misc interpreter. Then I could chroot into the sid armel chroot and after some more tweaking I had a system that could compile Debian source packages. Every executable was emulated, sh, perl, the compiler, everything. That setup was clean but slow, about ten times slower than compiling natively. The setup was clean because everything in it was coming from one Debian distribution. Apt-get is able to keep everything up to date, except qemu. It was slow because every single executable was emulated. I started speeding it up by replacing selected executables with x86 versions. For example, I copied /usr/bin/perl into the chroot, and a matching POSIX.so. I left all the interpreted Perl code alone, since the point was to speed up the execution of the perl binary, not to redirect to an entirly different version of perl. This worked nicely and sped up the compilation of my test package by one minute or so. Replacing binaries like this breaks the cleanliness of the setup of course, and needs to be done in a better maintainable way. I would do it this way: In addition to the perl-base package which contains the normal armel binaries there is also a perl-base-accel-i386 package in the armel architecture that contains the binaries of the perl-base package, but as i386 machine code and in different locations so that both perl-base and perl-base-accel-i386 can be installed at the same time. Then there would be a way for the user to select whether or not to make /usr/bin/perl be the armel or i386 version. The perl-base and perl-base-accel-i386 packages would be produced by the same maintainer, ideally, and would be forced to be nicely in sync by package dependencies. Building the perl-base-accel-i386 package could be done by fetching the i386 perl-base package and hand picking the needed binaries. This all happens within one distribution, so this is easy to coordinate. That way, all binaries can be replaced that are used a lot during compilation and are too slow to be emulated: /bin/sh, m4, awk, make, perl, gcc, binutils, but not much more. Packages like autoconf, automake, libtool are never redirected since they are interpreted anyway. Documentation tools like the monster docbook machinery might not even be needed on armel since documentation is architecture independent and build on i386. All documentation tools should of course be available for armel, and the only consequence of not having a -accel-i386 package is that things are a bit slow. Assuming that this all works out, people will want to maintain multiple chroots, and there needs to be a way to mirror the home directory into these chroots, etc. In the end, it might look very much like sbox1 except the horrible redirection into devkits is gone and the chroots are properly self-contained and upgradeable with apt-get from a single source. S, what do you think? Am I on crack again? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On 31/07/07 11:56 +0300, ext Marius Vollmer wrote: Also, both sbox1 and sbox2 redirect whole packages, not just binaries (if I understand sbox2 correctly). E.g., when redirecting the perl command, the redirected-to perl will take its modules from the redirected-to prefix, not from the redirected-from prefix. It's all per-file based, you could write the sb2 rules so that only specific files are accessed from the host. It's all quite flexible. That way, all binaries can be replaced that are used a lot during compilation and are too slow to be emulated: /bin/sh, m4, awk, make, perl, gcc, binutils, but not much more. Packages like autoconf, automake, libtool are never redirected since they are interpreted anyway. You could implement this as a mapping mode for sb2, by simply doing export SBOX_MAPPING_MODE=your_mode you could switch to whatever you like. Just put your custom rules into scratchbox/shared/scratchbox2/redir_scripts/preload/your_mode and you're all set. You could take the current emulate mode as a template and start adding to that your exceptions. I'll add a command line switch for sb2 to support selecting the mapping mode. This way there's no need to chroot into anything. /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On Tue, Jul 31, 2007 at 11:56:12AM +0300, ext Marius Vollmer wrote: Then there would be a way for the user to select whether or not to make /usr/bin/perl be the armel or i386 version. I know this sounds like a trite reply, but I have actually read your entire mail. However: Sounds like you want multiarch. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On Tue, 2007-07-31 at 13:11 +0300, ext Lauri Leukkunen wrote: You could take the current emulate mode as a template and start adding to that your exceptions. Maybe it's a matter of sb developer's vs sb user's point of view, but I would rather consider sb to be the exception ... -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On 31/07/07 13:52 +0300, Igor Stoppa wrote: On Tue, 2007-07-31 at 13:11 +0300, ext Lauri Leukkunen wrote: You could take the current emulate mode as a template and start adding to that your exceptions. Maybe it's a matter of sb developer's vs sb user's point of view, but I would rather consider sb to be the exception ... I meant exception from using files from $BUILDROOT, basically on a per file basis breaking out of the chroot. /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
Daniel Stone [EMAIL PROTECTED] writes: Sounds like you want multiarch. Yes, I know I want multiarch. :) Is it ready? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
components should be pushed to debian and ubuntu and get those bigger communities involved in their development. One day we will anyway be Indeed. When it comes to Hildon that is certainly starting to happen now. This should be the default mode for most of the stuff we do. Arguing that we need to keep something in-house for competitive advantage is bollocks. Nokia has a few completely proprietary software platforms already. No need create another one. Anyway almost all of the proprietary components in maemo are of dubious quality, maybe there's a reason for that... I understand platform as not to include applications, basically covering the scope of Maemo. The vast majority of the Maemo platform is open and the trend has been towards completeness. Within that platform scope, I too think that diverging from upstream is silly and that alignment of packaging with Debian makes sense. What happens on top of the Maemo platform is a different discussion altogether. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
ext Andrew J. Barr wrote: On 7/31/07, Carlos Guerreiro [EMAIL PROTECTED] wrote: What happens on top of the Maemo platform is a different discussion altogether. FWIW, I think that there is a distinction between maemo the platform and the ITOS firmware that not everyone has grasped. Maemo is mostly open, a lot more open than the ITOS firmware. I think most of the people agitating for Nokia to open stuff want to be able to run free software exclusively on their device (at least, that's what I want). This could be a different distribution (e.g. Angstrom), or just a different environment (e.g. GPE). I think many people want usable stuff they can use on their device, not just SDK stuff for developers. My two cents, anyway. At least, this is what I assume you mean when you talk about what is on top of the Maemo platform. Yes, that was exactly my point, thanks. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: sbox2 maemo
Lauri, I can see you've been away for too long and missed some of the action ;-) That's probably true, but I'm not afraid to raise old issues that may or may not have been 100% addressed. Worst thing that can happen is that things are actually not as bad as I thought. I'm just one voice here, I think there are enough yes-men to go around so it doesn't hurt if I object even when there was no need ;) Your voice is welcome. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lauri Leukkunen schreef: Also note that SB2 is totally not interested in doing x86-x86 development, like what many people are doing today with SB1. People need to wake up, smell the coffee, integrate with debian proper and get with the program. I agree with that It's stupid to maintain a lame x86 port of maemo which nobody wants when all the components should be pushed to debian and ubuntu and get those bigger communities involved in their development. The big problem is that hildon depends on an old, forked version of gtk+ that nobody in their right mind wants on their x86 systems. The nokia people at guadec were unable to give me an ETA on when that will be fixed :( One day we will anyway be running debian/stable with a few custom components on the tablets. You mean switching back to OABI? That was the aim with this whole debian thing in the first place, remember? Not marketing targeted at geeks? regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGqFVxMkyGM64RGpERAnQsAJwN6pV7jGNvhAsj9L3B2apdBEngWACcD7LI UJYH2aGwUWyMgVEehMoEpXY= =oMOm -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
Marius Vollmer wrote: There are two kinds of borders: one kind isolates OSs from each other; this could be done with some virtualization tool like xen, uml, or maybe chroot. The other kind isolates different architectures within the same distribution; this is what SB2 does. There has been some thinking about this dilemma, and we have pretty much decided that we will not implement anything that does the first kind of isolation in sb2. A separate tool can be created for that purpose. Lets try to keep sb simple this time :) In order for me to use SB2 and still retain control over my host OS, I would have to install the OS that SB2 wants as its host inside a virtual machine. That's not a problem, of course. I think I found my weekend project... That is not that different than what Debian/Ubuntu developers already do. Their host OS is whatever it is (etch/testing/sid or dapper/gutsy or whatever), with whatever crap and extra hacks installed. When building packages to distro, a clean chroot of target distro or pbuilder is used. So, in the end, I think it's actually all quite simple: we make a OS that runs on real x86 hardware, inside Xen on x86 and on a Internet Tablet arm device and can be used both as a development environment as well as the basis for IT OS. That OS includes sb2 which is used to 'cross-compile' software from i386 to armel. The *main* point here needs to be that all development tools inside the X86 development system need to unmodified packages from some mainstream distro. Else we end up maintaining a similar soup of patched and hacked packages that nobody dares to upgrade. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On 7/26/07, Marius Vollmer [EMAIL PROTECTED] wrote: From my point of view, the host and target distributions should be as independent as possible. The host could be Debian, or Redhat, or Nokia's internal Linux, or OSX, or even Windows. There are many, many ways to solve this, starting from running a chroot and continuing all the way up to vmware co. SB2 would then be used in that virtualized environment. The SB2 idea seems to be that there is only one distribution, and SB2 is a clever hack to allow you to compile for a different target architecture than the host one without having to worry about cross-compilation complexities too much. Pretty much yes. SB1 tried to pretend that it's a generic cross-compilation tool, but ended up being neither generic nor specific. Thus, from what I understand about SB2, I would characterize the situation so that the sb2 command takes you from the host architecture to the target architecture, but stays in the same distribution. The host and target architecture environments are separate installations of this one distribution, and you need to make sure that both of them are properly up-to-date and syncronized. All target distributions have build requirements, of course we could construct maemo to be a totally non-debian distro but still use debian/unstable as build requirements. It would be weird, but certainly possible. It's pointless to pretend that we could construct a new distro that could use any linux distro from the past five years as build requirements. That just won't work. Using something like the project-builder from ubuntu might be a way to provide the build deps on a number of different host distros. Programs that run inside the target architecture environment get a native environment to run in and a properly emulated CPU to run on. Thus, they never know that they are effectively being cross-compiled. This is too slow for some programs like the compiler, so here comes the clever part of SB2: there is a conceptual second layer of emulation that emulates the host architecture on the target architecture with the magical property that the two layers of emulation cancel each other out and performance actually increases. Well, by default we're really staying in the host as much as possible, it's all path based, so if you access files from let's say /usr/share they are by default the target files, with quite a few exceptions to support running the build tools. I've tried to make sure the build tools get their own files from the host always, this reduces the number of packages that need to be installed for the target, and it's the right thing anyway. This is a good and simple model, the only thing I don't like about it is that I can't choose or configure my host environment independently from the target environment. There are ways to work around this as described above, it would not be smart to include yet another way into sb2. That would only make it bigger with all the downsides of SB1. /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On 7/26/07, Carlos Guerreiro [EMAIL PROTECTED] wrote: As long as Nokia works in the current, essentially forked, mode, nothing will happen. Nokia needs to look at the way it interacts with upstream projects and change. Sure it can be painful, but hiding behind a smoke-screen of product program priorities is just not helping to solve the real issues. Lauri, I can see you've been away for too long and missed some of the action ;-) That's probably true, but I'm not afraid to raise old issues that may or may not have been 100% addressed. Worst thing that can happen is that things are actually not as bad as I thought. I'm just one voice here, I think there are enough yes-men to go around so it doesn't hurt if I object even when there was no need ;) One day we will anyway be running debian/stable with a few custom components on the tablets. You mean switching back to OABI? Not really =) This needs the current armel port to mature and be accepted to debian. Nokia pushing it and putting resources into it would seriously help, I think. So far Nokia has done next to nothing right in the distro Fair enough. For the sake of presenting an argument I may push things a bit too far, but I believe that the Original Idea(TM) behind the debian choice was distorted by the product requirements and it needs to be raised again now that things have evolved. We shouldn't be afraid to throw away a lot of our custom stuff and development processes if it turns out to be slowing us down. Corporations are notoriously bad with this, we are no exception. maintenance area. If SB1 somehow contributed to this state of affairs I'm really sorry about it, SB2 is trying hard to change things around by removing an obscure layer from between the host and the target distros, hopefully forcing a tighter coupling of them. At least it should be possible to I'm afraid things don't work like that. Alignment needs to happen for its own sake. It just makes sense to simplify and streamline our work and work shoulder to shoulder with upstream and other distros. Forcing that alignment through tools before it's there just means the tools don't get adopted. Sure, I'm not saying that SB2 will necessarily force this stuff on people, just that SB1 probably tilted the table so that it encouraged sub-optimal way of working. This is very fuzzy of course :) /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
Koen Kooi wrote: The big problem is that hildon depends on an old, forked version of gtk+ that nobody in their right mind wants on their x86 systems. The nokia people at guadec were unable to give me an ETA on when that will be fixed :( Guadec of what year? :P http://packages.ubuntu.com/gutsy/x11/hildon-desktop looks like a recent enough non-forked gtk to me...[1] One day we will anyway be running debian/stable with a few custom components on the tablets. You mean switching back to OABI? unofficial[2] Debian EABI port is pretty much ready for what tablet's would need from it. D-I, java (argh, but being worked on) and FORTRAN (Argh!!) are the main incomplete things, but they do not really touch tablet usage. What _is_ missing for tablet usage is free UI's for selected things (input, wifi/bluetooth network connectivity etc), which I expect the Ubuntu mobile people already be working on. [1] Well it's still patched but the patches are included in mainstream distros' gtk and being integrated upstream. [2] http://lists.debian.org/debian-arm/2007/07/msg00076.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
ext Lauri Leukkunen [EMAIL PROTECTED] writes: At least it should be possible to build a package for both host and target distros like this: cd my_package dpkg-buildpackage -rfakeroot sb2 dpkg-buildpackage -rfakeroot Hmm, I am still quite fuzzy about what SB2 is all about. Maybe you can hep me out a bit. From my point of view, the host and target distributions should be as independent as possible. The host could be Debian, or Redhat, or Nokia's internal Linux, or OSX, or even Windows. The target distribution right now is the existing maemo mess, but we could collectively move to Debian or Ubuntu. In any case, people might use whatever host OS works for them, but would work all on the same target distribution. The SB2 idea seems to be that there is only one distribution, and SB2 is a clever hack to allow you to compile for a different target architecture than the host one without having to worry about cross-compilation complexities too much. Thus, from what I understand about SB2, I would characterize the situation so that the sb2 command takes you from the host architecture to the target architecture, but stays in the same distribution. The host and target architecture environments are separate installations of this one distribution, and you need to make sure that both of them are properly up-to-date and syncronized. Programs that run inside the target architecture environment get a native environment to run in and a properly emulated CPU to run on. Thus, they never know that they are effectively being cross-compiled. This is too slow for some programs like the compiler, so here comes the clever part of SB2: there is a conceptual second layer of emulation that emulates the host architecture on the target architecture with the magical property that the two layers of emulation cancel each other out and performance actually increases. This second layer of emulation makes use of the programs installed in the host distribution. This is the reason why everybody needs to agree on the host distribution as well as on the target distribution, but the two distributions don't need to be the same for this reason. The two distributions need to be the same since the host distribution is directly used for development of the same software that is compiled in the target architecture environment. The host environment is much nicer for testing and debugging, since the SB2 emulation is good enough for compiling, but not for really booting and running the distribution. This is a good and simple model, the only thing I don't like about it is that I can't choose or configure my host environment independently from the target environment. There are two kinds of borders: one kind isolates OSs from each other; this could be done with some virtualization tool like xen, uml, or maybe chroot. The other kind isolates different architectures within the same distribution; this is what SB2 does. In order for me to use SB2 and still retain control over my host OS, I would have to install the OS that SB2 wants as its host inside a virtual machine. That's not a problem, of course. I think I found my weekend project... [ There is another picture in my head that I think might work: we keep the current SB1 setup but instead of having SB1 redirect tools into devkits, it redirects tools into a second target. That second target can then be maintained in the usual way. But I like the full-virtualization approach much better than the half-assed SB1 emulation. ] So, in the end, I think it's actually all quite simple: we make a OS that runs on real x86 hardware, inside Xen on x86 and on a Internet Tablet arm device and can be used both as a development environment as well as the basis for IT OS. That OS includes sb2 which is used to 'cross-compile' software from i386 to armel. As a bonus, we could extend the range of supported hardware platforms (Xen on PowerPC, Intels x86 mobile platform, sb2 from powerpc to i386...) Debian GNU/Linux is pretty close to these requirements: it doesn't run on Internet Tablets yet and it probably can't be the basis for IT OS if it would. Both issues should be straightforward to address. (I hope I don't have to explain why they are worth addressing. :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
As long as Nokia works in the current, essentially forked, mode, nothing will happen. Nokia needs to look at the way it interacts with upstream projects and change. Sure it can be painful, but hiding behind a smoke-screen of product program priorities is just not helping to solve the real issues. Lauri, I can see you've been away for too long and missed some of the action ;-) One day we will anyway be running debian/stable with a few custom components on the tablets. You mean switching back to OABI? Not really =) This needs the current armel port to mature and be accepted to debian. Nokia pushing it and putting resources into it would seriously help, I think. So far Nokia has done next to nothing right in the distro Fair enough. maintenance area. If SB1 somehow contributed to this state of affairs I'm really sorry about it, SB2 is trying hard to change things around by removing an obscure layer from between the host and the target distros, hopefully forcing a tighter coupling of them. At least it should be possible to I'm afraid things don't work like that. Alignment needs to happen for its own sake. It just makes sense to simplify and streamline our work and work shoulder to shoulder with upstream and other distros. Forcing that alignment through tools before it's there just means the tools don't get adopted. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
