The question is whether it makes sense at all to use udev for a fixed-hardware device like the N900.

In the old days I actively refused to install udev on my PCs (but I also refused to update to kernel 2 because I hated modules . I don't know how dependant Maemo/Debian is on udev though, so if it has to stay there, so be it.

But I honestly cannot believe that udev doesn't allow a separate /usr partition. That's like so, how can I say, anti-Unix.

FWIW, it's possible to separate /usr on a udev system.
(IIRC, there is a warning added that will simply complain about it.)

The downside is that you'll have to use the /sbin/preinit kludge to set up the mountpoints before you run /sbin/init.
(This is the method a certain Lennart suggested on his original article about systemd.)

Whether such a kludge would be supported by the Maemo developer community is up for (heated) debate.

IMO, stuff / and everything else except for MyDocs into mmcblk0p2, and disregard the OneNAND space. It's tiny, even for a base Debian install. (or turn it into a big RescueOS, that's another idea)

So look at how Lennart Poettering crippled udev and how he writing programs/daemons. He does not care about unix standards and other unix systems (bsd, ...).

Really now when udev is part of systemd, /usr and / must be on same partition (or /usr must be mounted before starting udev). But in systemd mount process is done after starting udev which creating files in /dev (also device for /usr).

And now all linux distributions (except small epsilon) depends on udev...

I started own thread about libc: http://talk.maemo.org/showthread.php?p=1329134

I have postponed optification issue, maybe it is worth of own thread.

-----
I reread what I know about gcc-4.7 and thumb, and realized that gcc-4.7 is not producing thumb-code as default, so there are no reason to use gcc-4.2 (unless some specific package is really needing it).


I have started to build packages from squeeze, ready packages goes to my repository (link in first post). There are not many for the device.

I have learned that Debian is not ready for fully built from scratch, e.g. there are circular build-dependencies, read more: http://wiki.debian.org/DebianBootstrap

So some packages can't be built with sbdmock, but they need to tuned and compiled manually, without some of the dependencies. Typically documenting tools cause harm as they are used by many package, but compiling them need other packages.

----
Some details for sbdmock
*create own local repository containing e.g. newer dpkg-dev and other libraries.
Creating local repository:
And row to the /etc/apt/sources.list (or sbdmock-conf)
And then use apt-get source PACKAGE_NAME

*there are packages that are not listed in debian/control, but still needed to build package, e.g. man-db, fakeroot and (working) gettext. Unpack them to the rootstrap-file.

*Downloading squeeze source packages.
On host, disable other deb-src on /etc/apt/sources.list and use only:
(use server near to you).

----
Not using wheezy, is because it needs newer debhelper and debhelper comes from scratchbox (devkits: debian-squeeze). Current situation of scratchbox is not good (e.g. check: scratchbox.org hint:dead).

--------
[EDIT there was false information before]
I separated Maemo5 open packages, there are 199 packages which is also in Debian Squeeze. And 1188 packages only for Maemo. This does not count renamed packages:
http://paste.ubuntu.com/5617449/
[/EDIT]

Off topic, but this information may be useful for the Alopex guys as they're targeting thumb only at the moment because of reliance of its' gcc version.

With regards to circular dependencies, this is the same sort of issue I was facing when trying to build Debian from scratch a few years back, dropping i386 support in favour of a pure i686 build instead of only certain packages. I just had some time to kill whilst playing about IIRC I had built a toolchain using a mix of LFS and Debian patches with its own version feature stripped version of apt and dpkg. This way I could use dpkg-buildpackage to build the debs of the system but install them using a different root. I think I hit an issue when rebuilding apt or dpkg because of a dependency on po4a (again...IIRC) but it needed dpkg to be built with certain features enabled, which couldn't be done without po4a built.

Glad they now make this clearer on the wiki.

Just wanted to chip in...you're doing what I've wanted to do for the last couple of years, but life's been conspiring against me for awhile now. Well done though...and I look forward to contributing to your project in the future

Or maybe ubuntu oneiric?

There are many patches in the Maemo (or even Harmattan) gitorious repos. And sometimes originally nokia-binaries (was an occurence in Harmattan) get open-sourced in gitorious. E.g. libbme got open sourced but w/o packaging...

Maybe we can pull the Nokia packages from Harmattan if possible?

I think basing on debian is better, i really dont like the way ubuntu is going, plus there is no gain in rebasing maemo on ubuntu over debian is there?

Now I have more than 300 packages on my own repository (check opening post). Most of them are Debian-squeeze packages compiled with (Maemo's) gcc-4.7.2. Not much of them are meant to be installed to the device, but they are helpers for SDK.


There are couple of packages fetched straight from debian armel. (Because they had circular dependency loops, or some other critical compiling issue)

And couple of packages comes (sources) from Ubuntu Precise (if debian's version has something weird, e.g. gzip depends mingw or I know that I want newer version just now, e.g. cmake).

I have installed almost every package to scratchbox but it is possible that there are still non-installable packages (and there are also packages conflicting each other, which is typical on every debian-based system).

-------
Technical details: If you install (let say) perl to scratchbox, you need to disable scratchbox's perl. Some packages can be disabled just dropping them out of devkit-list, some needs more force (sudo rm /scratchbox/tools/bin/gzip).

And same way there are now debhelper8 which can replace scratchbox's older debhelper (so wheezy/sid is just around the corner).

What about upgrading the whole scratchbox as a next step? Current Fremantle qemu is a little buggy (Harmattan target fails to work with it, in Fremantle target lupdate segfaults, and so on)

Plus if we add newer versions to "our" scratchbox we may not need to have all these SBOX_REDIRECT_IGNORE