studies about newer libglib on fremantle
 

GLib is 'software utility library'. Read more: https://en.wikipedia.org/wiki/GLib
--
On Fremantle we have
Installed: 2.20.3-1maemo5+0m5
which is pretty old (e.g. current Ubuntu is using 2.30.0-0ubuntu4)

There are applications which can't be (easily) compiled/ported to N900, because they use newer glib than we have.

GLib is open source, and every Maemo modifications can be put on newer version. But programs compiled against old version won't work with newer version (who confirms is this true with every programs?), but they must be recompiled. So, hard part will be closed parts of Fremantle. According to this list http://wiki.maemo.org/Fremantle_closed_packages there are 355 packages.

I put them to the sorted list, each name on own row -> closed_fremantle.txt

On the phone:
This is list of packages which prevent us to use newer libglib. Some of them can be replaced with open alternative, some are useless (and with luck(?) some will work against different version of glib).

When we have truly open Maemo5, this will happen, but it not seems short term plan.
------------------------
Another approach could be use parallel versions of glib, as far as I know, nobody have done this and it might be impossible. I once started 'rebranding' glib-2.26 to the new name, so package can be made and installed parallel, but it never really worked:
https://gitorious.org/clutter-for-maemo/glib-226

Even program X is compiled against new version, X can also use library Y, which is compiled against old version -> crash!
----------------
Third approach is make own glib which contains everything from old and new glib and programs compiled against either will work with it. (This approach is called "backport new features from new to the old"). It is possible there are modifications which can't exists in the same time. This will need (deep) knowledge about glib.
-----------------
GLib is licensed under LGPL, so it is legal to take (part of) it and bundle (compile statically) it inside GPL applications. Generally speaking statically linking is stupid (as we have so good dynamic linking), but could this work? Could this be automatic (=transparency to developer and user)?
---------------
Anything else?

Re: studies about newer libglib on fremantle
 

Wish portrait mode requestors were back to make fuss around this and similar problems. This could extend the life of our devices considerably, if all those devs out there concentrated on such probs we could really say: F Y Nokia.

EDIT: oh btw, CSSU devs are going to recompile every component (open source at least) as thumb2 is now possible, maybe those hundreds of components could be upgraded too? Would breathe new life for sure.

Re: studies about newer libglib on fremantle
 

I hate this new trend of shamelessly breaking the ABI and don't bothering to change the soname, as if there were a shortage of version numbers.
This page http://linuxtesting.org/upstream-tra...ions/glib.html tracks API and ABI changes and highlights problems. Look at the "API changes column", clicking a "x changes" link will show what those changes are and what the problem is (most cases are inserting a parameter in the middle of the stack in a function definition).

The new libs can be installed in a different path (say /opt/glib-2.30) and then you can use LD_LIBRARY_PATH tricks to make the program use that. To avoid the problem with old library Y linked to old X, you should also put a new Y there.

Re: studies about newer libglib on fremantle
 

I feel that efforts are better spent recoding closed source components and pushing for maintainers to recompile their old packages against a new GLib when the time has come, then making an unideal situation just more convoluted by making the new GLib and all libs compiled against it sit in a special folder.

Re: studies about newer libglib on fremantle
 

Fair point about the naming system.
@AapoRantalainen: Is there any reason to go against it?

@Mentalist Traceur
As for OSSing CSS packages, again, good point but one must assume that the OP has an interest in what a new GLib can offer...
@AapoRantalainen
If you've got the time and energy to port more recent libraries - great. There is a space issue on the N900 so best to have only one version installed at a time. Please ensure software that currently relies on existing libraries will run just fine with the update. I also hope this doesn't lead to requiring a recompile of all maemo5 packages because that isn't going to happen, so we'd have lots of crashes from a library mismatch!

Re: studies about newer libglib on fremantle
 

Please don't forget that there are also closed source applications from OVI that might not work with new version of GLib. I don't know if that could also affect WebOS games.

In my opinion, a complete move to a newer GLIB which breaks ABI and API compatibility is completely useless. We need to keep actual GLib and use new one only for rebuilt OSS packages using either naming or LD_LIBRARY_PATH tricks (please check this useful post)

Re: studies about newer libglib on fremantle
 

Please don't forget that there are also closed source applications from OVI that might not work with new version of GLib. I don't know if that could also affect WebOS games.

In my opinion, a complete move to a newer GLIB which breaks ABI and API compatibility is completely useless. We need to keep actual GLib and use new one only for rebuilt OSS packages using either naming or LD_LIBRARY_PATH tricks (please check this useful post)

Edit: Sorry, double posting due to connection issues.

Re: studies about newer libglib on fremantle
 

Seems this thread is now part in bigger concept than libglib only.
Question is: Will there be someday Maemo5-Fremantle without closed source packages?

case yes: Then it is possible to recompile everything. (Then issue is packages without maintainers who handle potential issues with new API.)

case no: a) Some preinstalled package can't be switched, no open alternative exists (technical). b) Some package in non-free extras is too good to be dropped and developer is not interested in to upgrade it (social). c) Some closed package in OVI is too good (social).

case who cares, there are nemo and debian: This discussion happens on TMO, so it is relevant.

----
Meanwhile waiting this FrEEmantle happening, there could be another newer version of libglib parallel with old one, installed to the opt (and hopefully working transparency to the user). Then developer can make decision which version to use. My opening post describes how this could be accomplished, but I'm still not know how hard any of those will be.

Re: studies about newer libglib on fremantle
 

Provided the closed graphics driver is probably not glib dependent, a completely OSS Fremantle is theoretically possible.

No idea about things like telephony framework, skype, etc.

Also while I tried to port a newer Clutter version to Fremantle some time ago, the glib version was one of the main blocking issues, preventing Clutter past 1.4 from running (together with some missing EGL header files). IIRC Hildon is currently using Clutter 0.8 so upgrading Clutter & making Hildon use the newer version might be also useful, while not easy.

Re: studies about newer libglib on fremantle
 

Once you start upgrading quite a few files, it becomes easier to simply port the Hildon stack to GTK3 and use the MeeGo dialer instead of trying to work with the crazy mess that is Maemo 5. (plus we'd be able to do crazy **** like use btrfs as root, run on armv7tnhl kernels, use wayland and systemd, etc.)
Has anyone at Nokia seriously looked at what they made and not said WTF? You have shell scripts using dbus holding the whole thing together!

Re: studies about newer libglib on fremantle
 

I'm sure some people who worked on the N900 and then N950/N9 did just that, but the upper decisions are obviously being made by the same people that thought Windows Phone OS was a good idea... so you're already guaranteed their internal bureaucracy is biased against making good decisions....

- Edit -

While I don't like it as much for aesthetic purposes, I am inclined to agree that a seperate file for a new GLib with fancy voodoo to get different programs using different versions, might be better for the time being.

I don't like it, but if it becomes possible to make the move to truly open Maemo 5, I'm sure a more cleaner setup will naturally follow, but in the meantime working with what we do have is probably better than me insisting that a new GLib break all the old stuff for everyone on the off chance that it motivates updates/OSS-recodes faster.

Re: studies about newer libglib on fremantle
 

They will never release the source of every program. That simple. Forget about it. But as said, LD_LIBRARY_PATH might be a way. For example, from time to time I mount a debian system on /mnt/, and use this:

./debianwrap /mnt/usr/bin/xchat
Oh no!

Maemo's software stack will keep aging and there is not much we can do about that (besides learning to live with it).

Re: studies about newer libglib on fremantle
 

We are not waiting they release every source. We are writing open alternatives for rest of them. Are there something that can't be reimplemented (and is essential)?

Re: studies about newer libglib on fremantle
 

NOLO, and dem PowerVR SGX drivers.
For everything else, we can probably live with the stuff Nemo puts out, and backport it to Fremantle (or port Fremantle to meet Nemo's ABI)

Re: studies about newer libglib on fremantle
 

There's nothing inherently wrong with that, plus it has the advantage that makes it easy to fiddle with.

Re: studies about newer libglib on fremantle
 

I think biggest issues as far as closed source software:
Bootloader (NoLo)
Hardware blobs (PowerVR drivers, wl2151-cal etc)
Communications and internet stack (csd, icd, dialer, telepathy-ring, messenger, contacts, browser UI etc)
GPS stack (location-daemon, location-proxy, gps/maps app)

Re: studies about newer libglib on fremantle
 

udisks requires libglib 2.31.13, available on Precise (.18) in armel flavour. Going to backup and try forcing it later on today. If that is just 'not going to work' let me know guys, reverting backups is not always successfull and would hate to have to resort to flashing/reinstalling everything

Re: studies about newer libglib on fremantle
 

Wait, hold on there.
You'll need udisks, a very new udev and take out HAL.
That last one will probably break Maemo.

Re: studies about newer libglib on fremantle
 

Want to try forcing libglib 2.31.18 for now and see if this bricks the phone. Would also allow me to pass one step further in configuration of udisks, there are most likely further blocks on the way to building it, so this can wait. If latest libglib doesn't brick the phone it would be a good info though, so fingers crossed

Re: studies about newer libglib on fremantle
 

Post results! I'm betting on a brick afterwards, though, if symlinks in /lib were changed.

Re: studies about newer libglib on fremantle
 

Yup. Loading backup atm, so not even full reflash-worthy idea. Next try with 2.30.... oh wait... errors on BackupMenu. Dammit :D Seems reflash-worthy idea after all. Still going to try debian libglib. Just in case

backupmenu errors seem about datestamp in the future, might work???

EDIT: worked. Time for wheezy

Nope. Same thing. Crying about not finding libgmodule... BackupMenu is wonderful yet again

Re: studies about newer libglib on fremantle
 

i dont understand why people are doing all the can to hang onto Maemo, what I love about it is Hildon, and that is being worked on in the Cordia project, then load it up on the Mer base, and everyone goes home happy, people should just be patient.

Re: studies about newer libglib on fremantle
 

Cordia is dead afaik due to hw contractors issues. So waiting can be an exercise in pointlessnesss even bigger than --force-breaking newer libs, sadly

Re: studies about newer libglib on fremantle
 

Ok, forcing is futile, what if symlinks to libgmodules etc were updated beforehand (or just duplicates created before forcing)? Is there any known backwards incompatible change to libglib 2.20+? If it's just a matter of symlinks/names, we should be good.

Aapo wrote in first post here:

GLib is open source, and every Maemo modifications can be put on newer version. But programs compiled against old version won't work with newer version (who confirms is this true with every programs?)

I would like to challenge that. Can you provide me with latest libglib for maemo? Using LD_LIBRARY_PATH trick we should be able to either confirm this or refute. If the latter (still hoping backwards compatibility is an issue with critical component's programmers) upgrading libglib should become a priority. As stated in here (http://maemo.org/community/maemo-dev...lib_on_maemo5/) required libglib version is not really required most of the times, just earliest version that was tested. And maintainers on debian/ubuntu tend to have their versions of all libs up to date. (vide: requirement of experimental 2.31.13 for udisks when stable is at 2.30)

Re: studies about newer libglib on fremantle
 

really? I mean really? Have you checked the project, I don't mean cordia the independant hardware, I just mean Hildon over Mer. In that manor Cordia is alive and kicking, and some nice progress has been made, check it out.

Re: studies about newer libglib on fremantle
 

I don't want to derail this thread, but cordia devs themselves announced end to the project as it was meant to be. If they can put hildon on raspberry-pi, mer, nemo... more power to the people. I support these efforts wholeheartedly, but latest info on 'Cordia' was: our hw suppliers fked us over. No way to go forward.
This is what I was referencing. If hildon gets put on Veer/webOS 3 let me know, would love to see it

Re: studies about newer libglib on fremantle
 

Not to mention, that there are many people around, who doesn't believe in any *usable* version of CordiaHD (not only CordiaTAB) being released at all. Haven't You wondered, why Cordia banner disappeared from maemo.org?

I know it's quite off-topic here, but trying to use it as de-motivating argument for Maemo related project is not only impolite, but also naive, not to say silly.

/Estel

Re: studies about newer libglib on fremantle
 

its not to derail at all, but its just an easier way than practically ripping out a vital function and putting another in place while serious breaking compatability.

Re: studies about newer libglib on fremantle
 

edit: DO NOT FOLLOW THESE INSTRUCTIONS, BACKUPMENU GETS BORKED FULL REFLASH REQUIRED

I'm back. Sorry guys, gonna beat this dead horse a bit more.

So forcing libglib is futile. Especially when one notices all libs ending in arm-linux-gnueabi subfolder instead of /usr/lib as maemo likes it. So we change all .so files from libglib2.0 overwriting maemo symlinks to the newer libs (in /lib and /usr/lib). Cries libc6 problem. No problem, get precise armel libc6 substituting as above. So far so good. Either I screwed up libc6 substitution or trying this on device with pr1.3.1 kernel is a bad idea, but new message appears:

FATAL: kernel too old

Maybe going for precise was a bad choice and trying this on stable releases would give a better chance, but this is new. After backupmenuing going to try on .50 kernel, wish me luck. Or maybe we could succeed with bit less experimental versions (.1.18 from latest stable glib version could be too much). If you know for certain this approach is doomed, let me know, we all appreciate our time.

Re: studies about newer libglib on fremantle
 

Just a word of warning: libc6 substitution kills BackupMenu, full-reflash-worthy idea finally. Do not try this on main device.

Re: studies about newer libglib on fremantle
 

Seriously: do not try this. I was lucky that I had reasonable battery charge. Messing with libc6 made even charging impossible. Reflashing was another great story with vista spewing 'ERROR: Createfile error = 5' without end, thank dice I have dualboot and flasher in ubuntu worked flawlessly, yet again. Now onto .50 kernel...

Re: studies about newer libglib on fremantle
 

And even newer news: after trying the above steps on pre50 kernel, FATAL disappears, now the problem seems: error while loading shared libraries: libpcre.so.3 cannot open...
Seems like our latest kernel is enough (to an extent at least)

Re: studies about newer libglib on fremantle
 

Seems latest (experimental even) libglib and libc6 (and libpcre) run well on Ubuntu 12.04 (precise) on N900. For this kernel 2.6.35 is needed though. Does anybody know how to flash this thing onto Fremantle? I will probably get to it, but will take weeks of reading of how it is done, which means months realtime for me. If anyone has a quickie instructions and it by any chance works we could save quite a lot of time. I can crash test possible solutions, flashing takes a few minutes. Digging properly into kernel stuff is a huge task, please share your insights.

Re: studies about newer libglib on fremantle
 

Pali said on maemo irc that /proc/bootreason needs to be added to 2.6.35 to get Maemo 5 to boot it.

Not on my desktop machine, cba to check it in the logs.

Re: studies about newer libglib on fremantle
 

This: https://mg.pov.lt/maemo-irclog/%23ma...03-04.log.html ?

Re: studies about newer libglib on fremantle
 

Yes, that would be it.

SIDE NOTE: does a kernel have to be built with the corresponding system binutils to actually boot?

Not much experience in cross-compiling Linux kernels, is all.

Re: studies about newer libglib on fremantle
 

Most likely yes(?). Easy to test though, post .28 version built on newer binutils, I'll test it, if it runs - NO, if it fails - YES. Not 100% sure answer, but in case of running, quite likely (if you can also build it on older than .28 chain would be more convincing if answers don't change)

Re: studies about newer libglib on fremantle
 

Have you seen this post related to an updated version of GLib?, might be useful for you.