Active Topics

 


Reply
Thread Tools
Posts: 838 | Thanked: 3,384 times | Joined on Mar 2009
#1
GLib is 'software utility library'. Read more: https://en.wikipedia.org/wiki/GLib
--
On Fremantle we have
Code:
apt-cache policy libglib2.0-0
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:
Code:
#list of packages using glib
apt-cache showpkg libglib2.0-0 | uniq | tail -n +9 | head -n -5 | sed 's/,.*//' | sort | uniq | sed 's/  //' > glib_dependant.txt
#merge lists (and sort)
cat closed_fremantle.txt glib_dependant.txt | sort > merged_sorted.txt
#drop duplicates
uniq merged_sorted.txt > merged_uniq.txt
#check difference (dropped duplicates)
diff merged_uniq.txt merged_sorted.txt | grep ">" | nl

     1  > adobe-flashplayer
     2  > alsa-policy-enforcement
     3  > applet-datetime
     4  > as-config-applet-0
     5  > as-daemon-0
     6  > as-utils
     7  > browser-neteal
     8  > calendar
     9  > calendar-home-applet
    10  > calendar-ui
    11  > camel-as-provider-0
    12  > camelisync
    13  > camera-ui
    14  > cherry
    15  > clockd
    16  > clock-ui
    17  > connui-btsettings
    18  > connui-cellular-settings
    19  > connui-conndlgs
    20  > connui-conndlgs-bluetooth
    21  > connui-conndlgs-cellular
    22  > connui-conndlgs-wlan
    23  > connui-home-cellular
    24  > connui-iapsettings
    25  > connui-iapsettings-gprs
    26  > connui-iapsettings-wlan
    27  > connui-statusbar-bluetooth
    28  > connui-statusbar-cellular
    29  > connui-statusbar-internet
    30  > evolution-data-server-addressbook-backend-sim
    31  > fmtx-middleware
    32  > google-search-widget
    33  > gprs-provisioning
    34  > gst-nokia-wm
    35  > gstreamer0.10-dsp
    36  > gstreamer0.10-ipp-nokia
    37  > gstreamer0.10-nokia-speech
    38  > gstreamer0.10-wma
    39  > hald-addon-bme
    40  > hildon-control-panel-personalisation
    41  > hildon-im-common-virtual-settings
    42  > hildon-im-fkb
    43  > hildon-im-keyboard-assistant
    44  > hildon-im-keyboard-assistant-scv
    45  > hildon-input-method-configurator
    46  > hildon-plugins-notify-sv
    47  > hildon-startup-progress
    48  > hildon-status-bar-usb
    49  > icd2
    50  > imageviewer
    51  > libaccounts0
    52  > libaccounts-glade
    53  > libas-common-ui-0
    54  > libas-common-utils-0
    55  > libcityinfo0-0
    56  > libclockcore0-0
    57  > libcodelockui1
    58  > libconbtui0
    59  > libconnui
    60  > libconnui-cellular
    61  > libcumulus0
    62  > libdevlock1
    63  > libdevlock-bin
    64  > libdres0
    65  > libgpx0
    66  > libhildon-im-vkbrenderer3
    67  > libhildon-time-zone-chooser0-0
    68  > libi18n0
    69  > libi18n-locale-resolver0
    70  > libicd2
    71  > libicd-network-gprs
    72  > libimengines4
    73  > libimengines-wp4
    74  > libimlayouts0
    75  > libisi-glib0
    76  > liblas1
    77  > liblocation0
    78  > liblomesa0
    79  > libmaemosec-certman0
    80  > libmaemosec-certman-applet0
    81  > libmaesync
    82  > libnavigation0
    83  > libomap3cam
    84  > libosso-abook
    85  > libprolog0
    86  > librtcom-accounts-ui-client0
    87  > librtcom-accounts-widgets0
    88  > librtcom-call-ui0
    89  > libsharing0
    90  > libsignon-glib0
    91  > libssoautologin
    92  > libtopos0
    93  > location-control
    94  > location-daemon
    95  > location-home-applet
    96  > location-proxy
    97  > location-status
    98  > location-ui
    99  > maemo-applet-fmtx
   100  > maemo-applet-profiles
   101  > maemo-applet-tvout
   102  > maemo-input-sounds
   103  > maemo-installer-utils
   104  > maemosec-certman-applet
   105  > maemosec-certman-tools
   106  > maemo-statusmenu-fmtx
   107  > maemo-statusmenu-headset
   108  > maemo-statusmenu-volume
   109  > maesync-backend
   110  > maesync-controller
   111  > mce
   112  > mediaplayer
   113  > mediaplayerhomeapplet
   114  > mediaplayer-restore
   115  > modest-as-plugin-0
   116  > modest-home-applet
   117  > modest-nokiamessaging-plugin
   118  > mp-fremantle-generic-pr
   119  > nokia-maps-core
   120  > nokiamaps-navigation-provider
   121  > nokiamessaging
   122  > ohm-plugin-prolog
   123  > ohm-plugin-resolver
   124  > ohm-plugins-misc
   125  > osso-abook-home-applet
   126  > osso-accounts-plugin-skype
   127  > osso-addressbook
   128  > osso-applet-device
   129  > osso-applet-devicelock
   130  > osso-applet-display
   131  > osso-applet-languageregional
   132  > osso-applet-memory
   133  > osso-applet-notificationlight
   134  > osso-applet-textinput
   135  > osso-backup
   136  > osso-bookmark-engine
   137  > osso-calculator-ui
   138  > osso-filemanager-ui
   139  > osso-maesync-plugin
   140  > osso-maesync-ui
   141  > osso-mission-control
   142  > osso-notes
   143  > osso-sketch
   144  > osso-startup-wizard
   145  > osso-systemui
   146  > osso-systemui-actingdead
   147  > osso-systemui-alarm
   148  > osso-systemui-devlock
   149  > osso-systemui-emergency
   150  > osso-systemui-modechange
   151  > osso-systemui-powerkeymenu
   152  > osso-systemui-splashscreen
   153  > osso-systemui-tklock
   154  > osso-wlan-security
   155  > ota-settings
   156  > ovi-promotion-widget
   157  > profiled
   158  > prolog-extensions
   159  > rtcom-abook-skype-plugin
   160  > rtcom-accounts-plugin-gtalk
   161  > rtcom-accounts-plugin-jabber
   162  > rtcom-accounts-plugin-nokiachat
   163  > rtcom-accounts-plugin-sip
   164  > rtcom-accounts-ui
   165  > rtcom-call-ui
   166  > rtcom-messaging-ui
   167  > rtcom-notification-ui
   168  > rtcom-presence-ui
   169  > sharing-account-manager
   170  > sharing-dialog
   171  > sharing-manager
   172  > sharing-rtcom
   173  > sharing-service-flickr
   174  > sharing-service-ovi
   175  > signond0
   176  > skyhost-vengine
   177  > sms-manager
   178  > status-area-applet-activesync-0
   179  > status-area-applet-battery
   180  > statusbar-alarm
   181  > status-menu-applet-profiles
   182  > sysinfod
   183  > sysinfo-tool
   184  > tablet-bookmark-manager
   185  > tablet-browser-controls
   186  > tablet-browser-daemon
   187  > tablet-browser-default-plugin
   188  > tablet-browser-dialogs
   189  > tablet-browser-mediaplayer-plugin
   190  > tablet-browser-ui
   191  > tablet-browser-view
   192  > tablet-browser-widgets
   193  > telepathy-ring
   194  > telepathy-spirit
   195  > tone-generator
   196  > tutorial-home-applet
   197  > wappushd
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?
 

The Following 12 Users Say Thank You to AapoRantalainen For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#2
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.

Last edited by szopin; 2012-01-24 at 23:38.
 

The Following 5 Users Say Thank You to szopin For This Useful Post:
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#3
Originally Posted by AapoRantalainen View Post

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?
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.
 

The Following 11 Users Say Thank You to maacruz For This Useful Post:
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#4
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.
 

The Following 2 Users Say Thank You to Mentalist Traceur For This Useful Post:
Posts: 560 | Thanked: 422 times | Joined on Mar 2011
#5
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!
 

The Following 2 Users Say Thank You to demolition For This Useful Post:
Posts: 1,397 | Thanked: 2,126 times | Joined on Nov 2009 @ Dublin, Ireland
#6
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)
 

The Following 4 Users Say Thank You to ivgalvez For This Useful Post:
Posts: 1,397 | Thanked: 2,126 times | Joined on Nov 2009 @ Dublin, Ireland
#7
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.

Last edited by ivgalvez; 2012-01-28 at 08:05.
 
Posts: 838 | Thanked: 3,384 times | Joined on Mar 2009
#8
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.
 

The Following 6 Users Say Thank You to AapoRantalainen For This Useful Post:
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#9
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.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)

Last edited by MartinK; 2012-01-28 at 11:27.
 

The Following 4 Users Say Thank You to MartinK For This Useful Post:
Posts: 1,225 | Thanked: 1,905 times | Joined on Feb 2011 @ Quezon City, Philippines
#10
Originally Posted by MartinK View Post
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.
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!
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 11:40.