Hi Johnx,

thank you for your information. I guessed that Nokia does patch components, but I am not aware of how large these patches are, is it possible to upstream those, etc.

Did you (or anyone) try to actually gather information of these patches in one place, to have an overview?

Thank you, John!
yes, I'm not very familiar with the Mer project and its history, but I think Mer, Easy Debian and Moebian have similar goals - to enable access to up to date open-source software from Debian.
Each project may use a different approach, but we should share as much knowledge and work as possible.
Instead of starting from scratch, we would start with copy of Maemo5 that we can modify without bricking our devices and fix the opt problem by moving root to eMMC/SD.
This would be already a small but useful achievement.

Then we would upgrade the essential components and if possible, send necessary Nokia patches upstream. I guess most critical modifications, which Nokia did not send upstream, affect Glib/Gtk/Hildon? In that case we could keep two separate versions of Gtk/Hildon and link the Maemo apps with the Nokia hildon, while we try to port as many as possible patches to the Debian hildon.

I don't have the time and energy to fix all flaws of Maemo, but we should merge as much as what is possible with reasonable effort, and keep the rest separated.
In the worst case, we'll just be able to install only non-GUI applications and libraries,
which good enough for me, because GUI apps would need to be modified to work on the small screen, anyway.

While trying to upgrade some Maemo components to the latest upstream I noticed that they are often based on so outdated Debian versions that it was impossible find the original Debian sources to find the Nokia specific patches in the diff. How did you extract the Nokia modifications?

(quick post 'cause I'm at work. more later.)
AFAIK, Nokia *tried* to push their gtk+ patches upstream, but upstream wasn't interested because they change some really core gtk+ stuff. Essentially Nokia's gtk+ is a minor, incompatible fork for all intents and purposes. I have a feeling you'll find this situation in a lot of other parts of the system as well. We really did try to use Ubuntu packages, except where using an Ubuntu package would cause us to have reduced compatibility with Maemo 5 software. Even with those guidelines, Mer has hundreds of packages. Please, look at the Mer project. Look at our repositories, and our OBS page (the builder we used).

-John

John, do you think it would make more sense to start with Mer and repackage and integrate the Nokia binaries so that we get a fully functional device?

Many thanks to Mer people for the warning about incompatibilities and issues. Of course we will try to learn from you and use whatever knowledge you've accumulated.

I still think that is it more important to keep original software working from the beginning and through entire process. Think this as refactoring. Make small changes and ensure that those don't break working things.

For my best knowledge, Mer on N900, as of it's today state, seriously limits device functionality. No phone calls, etc. I'm not comfortable with this. N900 is a mobile communication device, and at first must serve as such; everything else goes after that.

Please correct me if I'm wrong.

@titan:
Well, that seemed like the logical thing to do from my point of view, but then again...it didn't really work for us. And at this point I think most of the Mer people are going to be putting their effort behind Meego (Stskeeps and lbt especially). Honestly, I don't really feel like I'm in a position to tell anybody what they *should* do, just what they should avoid. So, in that spirit, what to avoid:

• Over-engineering (also "falling down the rabbit hole")
• Hacks you'll regret later
• going a long time without releases (loses

By falling down the rabbit hole, I mean setting out to add some packages to a distro and ending up creating a build system. Use tools that are already out there whenever possible, even if they aren't perfect. Set limits on what falls inside the scope of the project.

At the same time, don't put hacks in place just to make something work. Solve problems before you waste time making a hundred "quick hacks." And if you figure out how to walk the thin line between those two extremes, tell me the secret.

The other thing to avoid is going too long without making some kind of working release. Cleaning things up for a release isn't easy, but each release is a chance to attract new developers, and if you miss that chance you'll be working on your project alone for years.

That's really all the general wisdom I've gleamed from working on the Mer project. There's a lot of specifics, but I figure it's easier if you just ask questions and I answer them rather than trying to guess what you'll ask.

All that being said, I just want to throw this out here one more time: You need to set your goals as clearly as possible. Is your goal to bring Maemo 5 to Debian on the N900? Is your goal to bring Meego to Debian? If you don't start with a narrow focus and clear goals you'll fall down the rabbit hole or end up hacking stuff up instead of making something that's architecturally sound.

I'll get off the soap box for now, but I'm open to questions, and I'll try and meet you on #mer or #maemo if you want some more "real-time" Q&A.

-John

I think that goal is - "bring as much as possible of Debian into n900 while keeping original software that comes with device full-functional".

That's very ambitious but that's exactly the kind of clear goal you need to set in advance. But if you set a goal of never breaking compatibility with Maemo 5, you're not going to get anywhere close to compatible with binary debian packages I think. It would be a very interesting undertaking though, and honestly I think you should just dive in and see how far you get.

-John

In the worst case we would end up with an inverse Easy Debian:
Debian or Ubuntu as the base system with all fremantle hardware services (x11, pulseaudio, bme, camera daemon etc) integrated and the rest of Maemo5 (GUI apps and toolkits) running in a chroot environment.

@johnx:
* I definitely don't want to reinvent the wheel. I cannot spend too much time for the project anyway.
* Maemo5 is a ugly hack, so it can't get much worse
I have already tried to fix some of Maemo5's flaws but I'm fed up with implementing thousands of workarounds. This project would make it easier to test some novel, cleaner solutions.
* by not breaking Maemo5 we should always have access to a large pool of beta testers.
Starting from scratch would be crazy as the first Harmattan or MeeGo devices would probably be released before we could even have basic phone functionality.

@titan and @yoush:
Well, it sounds like you guys have your goals down pretty well. I think the next thing to do is really roll up your sleeves and see how far you can get. Best of luck!

-John