If under ubuntu, run Please be aware that this image is not ready for end-users ;-)

here is the result:


Yeah, I know!!!

it seems to work without the " > " but there is nothing on the card!!!!

sudo doesn't work very well with console redirection. Any of the following should work:

[EDIT]
Note: If you're running this on a PC /dev/mmcblk0 is not likely to be the name of the SD card device node. You can find out what name has been assigned using dmesg or fdisk.
[/EDIT]

Thanks.

Typing dmesg, i can see that the device is mmcblk0

I typed

The files has been copied to the card. When i plug it, I see two partition on it : Boot and System.

I will follow the steps to update the bootmenu and see if it works.
Thanks in advance :-)

Okay, everything seems to work. I have Unable to read file /boot/uIntrd **

I will try to copy them from first partition to boot folder on the second!!!

EDIT: Okay!! It seems to boot now. The solution was said here:

Thanks Guys for your help. I'M going to play a bit with!!!!

cordia:
https://github.com/Cordia
Talk: (50pages about running hildon-desktop on meego) http://talk.maemo.org/showthread.php?t=56822

There are plenty of git-repositories and I managed to build hildon-desktop top of GTK3 (it had some gtk2 functions left but I dropped them).

I got it running, but it is not looking anything yet.

I'm planning to push source level instructions and deb-packages, but I will double check them first and maybe I want some real milestone achieved also.

Short summary of building-order and origin of sources:
M=maemo5 (apt-get source)
C=cordia (git)
J=jessie (apt-get source)
S=squeezie (dget)

cairo [J] (need tuning for dependencies, or it uninstall mesa-GL)

hildon-libs-l10n-public [M]
osso-system-lock-l10n-public [M]
hildon-fm-l10n-public [M]
hildon-icons [S]
hildon-theme-plankton [S] (deb is not installable, but copy directory to right place)

clutter [C] (against GL, not GLES)

libhildon-1 [C] (gtk3)

(do not use libosso-gnomevfs2-dev but libgnomevfs2-dev)

libdsme [M]
libiphb [MEEGO] (was liberated for harmattan)
libhildondesktop [C]

libmatchbox2 [C] (against clutter-0.8, not 1.0)

libhildonmime-dev [M]

libhildondesktop1 [C]

hildondesktop [C] (without maemo-launcher)

*
(It seems to me that) hildon-desktop acts as a window manager and Matchbox2 is statically compiled inside hildon-desktop.
-there are no matchbox -process running on maemo
-hildon-desktop should be very next to start after X


Starting:
On device, as root, start X (command is 'X', not startx)
And then over ssh, as user, run hildon-desktop

I'm not sure what is next package, maybe hildon-home?

Here is some selection of log when hildon-desktop is started:
---------------
qildon:
https://gitorious.org/qildon
I tried to compile it (gtk2-dev not-installed) but compile aborted because of missing gtk2. a) I failed to configure it correctly OR b) it is depending on GTK.

I'm waiting more info about this until I continue. (Is somebody ever got this compiled and running on any system? How ready it is?)
---------------
bme:
Closed source on fremantle, liberated for harmattan. Sources:
bme-rx-51 https://gitorious.org/rx51-bme-replacement/bme-rx-51
hald-addon-bme https://gitorious.org/rx51-bme-repla...hald-addon-bme
libbmeipc0 https://gitorious.org/rx51-bme-replacement/libbmeipc

And some more: https://gitorious.org/rx51-bme-replacement

These depends on libhal, which is not anymore on jessie. Maybe version from squeeze is better than wheezy or fremantle.Got it build, but not yet tested installation.
---------------
mce:
From harmattan.

I quickly check that is has some tough dependency (I don't yet know where to get)
osso-systemui-modechange-dev
libdevlock-dev
osso-systemui-devlock-dev
osso-systemui-splashscreen-dev
libcal-dev (binary version from this can be installed from NOKIA-binaries)

It also needs hald-addon-bme-dev (from meego), not yet tested.

great news aapo but i have a couple of questions.

is hal really necessary though? if we (maemo5) are only using it to automount hotplugged devices, udev+udisks would be sufficient. to use old software maybe but are you risking recreating the whole fork/cross version situation we have already.

bme/mce: are those links the same as the replacements were using/got available on maemo5? i thought ours were RE'd.

Really? I thought it was used for more stuff... Is it really only used for automounting hotplugged devices? If so, this looks like a massive overkill...

One of the links Aapo wrote (bme-rx-51 one) is the replacement availabe on Maemo5 via cssu(-devel?). AFAIK the replacement was heavily based on the Harmattan open-source version, but you are right that some parts indeed had to be reverse engineered (however, unless my memories are wrong, these were only some parts of it, not the whole bme/mce...).

EDIT:
I'm not sure about the other ones, but I think dropping osso-systemui-splashscreen-dev as a dependency should be safe... The package osso-systemui-splashscreen only displays Nokia logo when phone is shutting down (see file /etc/event.replace.d/osso-systemui-splashscreen - it starts splash display on stopping of dbus or dbus-actdead services) Even if the /usr/lib/systemui/libystemuiplugin_splashscreen.so file in that package needs to provide some functionality, my guess is it should be safe to make a dummy .so file which does nothing (but again, this is software we're talking, so some dumb design flaw may have caused this file to do something important...).

EDIT2:
By the way, Aapo, have you read this thread: http://talk.maemo.org/showthread.php?t=82641 ? I don't want to sound like a douche telling you what to do, but it could be a nice idea to drop all the unneded packages at first stages of your project and not spend too much time on trying to get them working (this is just an idea to consider).

EDIT3:
I have used this link a million times, but maybe I will post it once again, maybe it will be usefull (a.d. your note about using libclutter in specific version): http://linuxtesting.org/compatibilit...at_report.html - it can help detecting which versions of software can be easily used in newer versions (e.g. from Jessie). See e.g. list of possible incompatibilities with newer versions of libc, libexif, libexempi, libglib... libncurses - funny thing is this one is supposed to be in the same version in Fremantle and Harmattan, but they are incompatible somehow... Also, when some libraries reach 1.x state, they sometimes change name in debian (e.g. ssl 0.9.8 is "libssl" and 1.0 is "libssl1" - this is the example that came to my head instantly when you wrote about clutter). I remember seeing (I think on the same server) a comparison of base-system packages compatibility between different version of Debian... that could also be useful here (so you could compare compatibility and then make a decision from which source you would like to build packages for this Jessie-based Maemo).

hal: may do more on maemo, i used it as an example really. my laptop doesn't have it, just relies on udisks, upower, rfkill and so on.

clutter: does using gl instead of gles make much difference in terms of performance? if we can build against a newer version even better.

finally, does anyone have instructions for setting up a build environment for this via vbox or scratchbox?