Active Topics
-
Maemo 20th Anniversary (4)
to Brainstorm by teroyk - 3 hrs, 43 mins ago -
Nokia Booklet 3G (RX-75) Drivers (64)
to Alternatives by teroyk - 3 hrs, 59 mins ago -
Porting apps to Leste (46)
to Maemo 7 / Leste by teroyk - 2 days, 7 hrs ago -
Maemo repository (8)
to Community by Maemish - 6 days, 1 hr ago - more...
| The Following 12 Users Say Thank You to AapoRantalainen For This Useful Post: | ||
|
2012-01-24
, 23:32
|
|
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.
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: | ||
|
|
2012-01-25
, 18:30
|
|
Posts: 1,101 |
Thanked: 1,185 times |
Joined on Aug 2008
@ Spain
|
#3
|
Originally Posted by AapoRantalainen
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.
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?
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: | ||
|
|
2012-01-28
, 01:00
|
|
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: | ||
|
|
2012-01-28
, 02:04
|
|
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!
@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: | ||
|
|
2012-01-28
, 08:02
|
|
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)
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: | ||
|
|
2012-01-28
, 08:02
|
|
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.
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.
|
|
2012-01-28
, 10:34
|
|
Posts: 839 |
Thanked: 3,386 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.
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: | ||
|
|
2012-01-28
, 11:15
|
|
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.
Last edited by MartinK; 2012-01-28 at 11:27.
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)
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: | ||
|
|
2012-01-28
, 12:41
|
|
Posts: 1,225 |
Thanked: 1,905 times |
Joined on Feb 2011
@ Quezon City, Philippines
|
#10
|
Originally Posted by MartinK
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.)
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.
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.
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
--
On Fremantle we have
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:
#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 > wappushdWhen 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?