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.