glib/GTK update tentative [Split from Pidgin thread]

[EvilDragon]

First issue found:

When copy / pasting a file with Thunar, it crashes (AfTER copying the file).

The copy is made successfully, but Thunar crashes right after it.

Error:

 
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_cond_timedwait': Invalid argument.  Aborting.

 

[levi]

On my old profile, I changed some things such as font sizes, etc.

Seems like the profiles are not 100% compatible, so for an official update, we probably need to delete custom XFCE4-Settings before the upgrade.

Ah, I've only moved panels around in my xfce install.  Booted fine for me first time.

I've just reproduced your Thunar crash.  Cutting and pasting a file crashed it after moving the file.  FWIW I was then able to delete another file okay, so the common maneuver so far does seem to be the copy.  On the command line, mv works as you would expect, unsurprisingly.

 

[notaz]

Just upgraded as well and have to give out a small warning:

After upgrading and rebooting, XFCE4 didn't run (always went back to the login screen).

I've seen this too, seems to be caused by old files in ~/Applications/Cache . If you still have your old home dir that causes the crash, could you check if removing that Cache directory helps? I've already changed xfce4-session update script (xfce4-session is the process that I saw crashing) to remove that directory.

First issue found:

When copy / pasting a file with Thunar, it crashes (AfTER copying the file).

The copy is made successfully, but Thunar crashes right after it.

This one was a bug in Thunar, it was using glib function incorrectly, and probably worked with old glib due to luck. Could you run the update and check again?

Bigger issue was that file notification was broken, so inserting/removing SD card would not update Xfce menus with PNDs, and Thunar would not see when files changed in directory. That one took most of the day to find/debug (really hard when you have no clue where the problem is coming from as there are no error messages anywhere). Turned out to be a deadlock caused by recursive locking in gamin daemon, which Xfce uses for notifications.. I guess it worked on old glib because it didn't mind recursive locking.

 

[levi]

Just updated.  Thunar seems to be able to copy files fine now (tested both small files, and large collections that bring up the estimator thingy).  I'll have to reboot before testing Thunar observing directory changes I guess.

During the upgrade, I got the following on STDERR:

run-parts: /etc/dbus-1/event.d/20hal exited with code 1

I had most optional hardware switched off other than USB host, which I was using for wifi to download the updates.

 

[notaz]

Thanks for testing. I've pushed an update for missing brightness control icon and also split SGX packages so that 1GHz gets a working driver by default (other units should get same default as before).

There is also full flash image available if anyone wants to test:

http://boards.openpandora.org/topic/8701-pidgin-2109/?p=359295/URL]

During the upgrade, I got the following on STDERR:


run-parts: /etc/dbus-1/event.d/20hal exited with code 1

There are even more problems if you try to use the system after upgrade without reboot, as some desktop stuff still has old libs in memory and others already load new ones, hopefully all goes well after reboot..

 

[TrashyMG]

Split from Pidgin thread on request.

 

[levi]

Thanks, Trashy.  You've left my first post about this in the old thread though - I mention Pidgin, but only as an aside really.  It's mainly about this update, so a little out of place still in the old thread.

Just updated again and rebooted.  Booted up fine again for me.  Thanks for the brightness icon.  And Thunar observes directory updates properly now on my machine.

I saw it do something unusual with the GPU driver packages during the upgrade, so I think that worked correctly on my Ghz machine.  Eki's Model Check doesn't seem to be able to work out which driver this is though.  I'll have to test some games that I know break on the old driver version.

 

[notaz]

Since I believe all major issues have been fixed, I'm going to push this to the main feeds sometime tomorrow.

 

[ekianjo]

Since I believe all major issues have been fixed, I'm going to push this to the main feeds sometime tomorrow.

Will try the reflash this weekend on my side. Did the latest fixes already apply there too ?

 

[ptitSeb]

Since I believe all major issues have been fixed, I'm going to push this to the main feeds sometime tomorrow.

Sorry, I didn't got any time to test that

 

[notaz]

Will try the reflash this weekend on my side. Did the latest fixes already apply there too ?

Yes the test full flash ( http://notaz.gp2x.de/tmpfeeds/test_fullflash.zip ) has everything.

 

[ekianjo]

Will try the reflash this weekend on my side. Did the latest fixes already apply there too ?

Yes the test full flash ( http://notaz.gp2x.de/tmpfeeds/test_fullflash.zip ) has everything.

Great, thanks, I will report my progress during the weekend and let you know if anything breaks

 

[notaz]

I've deleted the test feeds and image as 1.62RC has been released with all this stuff:

http://boards.openpandora.org/topic/17176-superzaxxon-v162rc-released/

To switch from test feeds back to normal ones, /etc/opkg/openpandora.org-feed.conf needs to have this:

src/gz pandora-all http://openpandora.org/feeds/unstable/all
src/gz pandora-armv7a http://openpandora.org/feeds/unstable/armv7a
src/gz pandora-omap3-pandora http://openpandora.org/feeds/unstable/omap3-pandora

 

[ptitSeb]

@notaz: is there an way, from the starting script of a PND, to check if the firrmware is 1.62+ so I can warn the user if the firmware is too old?

 

[EvilDragon]

@notaz: is there an way, from the starting script of a PND, to check if the firrmware is 1.62+ so I can warn the user if the firmware is too old?

There is (forgot which file it is right now). Something like that should be included in pnd_run.sh, ideally.

It should read out the minimum OS tag from the PXML and compare it to the installed OS version.

 

[notaz]

It's in /etc/op-version

Ideally you should check for the libs you need, not some OS version which who knows what it means. A small program that does dlopen() on /usr/lib/libglib-2.0.so.0 and calls glib_check_version() would be nice, similar for other libs. Could maybe include something like that in firmware itself for easy use from run scripts, which could look like:

if test -e /usr/bin/op_version_checker && /usr/bin/op_version_checker glib 2.40; then
  ok="true"
fi
 
if [ "$ok" != "true" ]; then
  zenity --info --text="Your firmware is too old"
  exit 1
fi

Although that won't tell you if user's combination of libs would work, so maybe op-version is also an option.
 

Something like that should be included in pnd_run.sh, ideally.
It should read out the minimum OS tag from the PXML and compare it to the installed OS version.

I don't think it's a good idea, unless somebody audits all released PNDs. As the field wasn't well defined and is ignored, people put pretty much random stuff there. I saw some PNDs have their own version there. The only sensible thing to do with PXML osversion field is to ignore it..

 

[ptitSeb]

It's in /etc/op-version

Ideally you should check for the libs you need, not some OS version which who knows what it means. A small program that does dlopen() on /usr/lib/libglib-2.0.so.0 and calls glib_check_version() would be nice, similar for other libs. Could maybe include something like that in firmware itself for easy use from run scripts, which could look like:


if test -e /usr/bin/op_version_checker && /usr/bin/op_version_checker glib 2.40; then
  ok="true"
fi
 
if [ "$ok" != "true" ]; then
  zenity --info --text="Your firmware is too old"
  exit 1
fi

Although that won't tell you if user's combination of libs would work, so maybe op-version is also an option.


random stuff there. I saw some PNDs have their own version there. The only sensible thing to do with PXML osversion field is to ignore it..

Looks nice indeed. With the updated glib, there is no need to include it in the PND anymore, so the test make sense. I like that. I guess op-version is usable too, but the test here is more simply binary, is the firmware 1.62+ or not.

 

[EvilDragon]

Well, right now, we're on 1.62RC, maybe it makes sense including that script into 1.62 Final?

 

[notaz]

Well, right now, we're on 1.62RC, maybe it makes sense including that script into 1.62 Final?

op_version_checker does not exist, somebody needs to code it.

 

[ekianjo]

Looks nice indeed. With the updated glib, there is no need to include it in the PND anymore, so the test make sense. I like that. I guess op-version is usable too, but the test here is more simply binary, is the firmware 1.62+ or not.

But that's a broken solution, since now everyone who makes and updates PNDs has to do this check every single time. :/ not ideal but I don't think we have many other solutions at this stage. For upcoming firmwares, however, we need a more built-in solution.