Ticket #1756 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

Qtopia GUI (qpe) broken after 'opkg upgrade'

Reported by: aeneby Owned by: openmoko-devel
Priority: high Milestone:
Component: Qtopia Version: GTA02v5
Severity: major Keywords: Qtopia, qpe
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

After running 'opkg update' and 'opkg upgrade' on a fresh Qtopia 4.3.2 GTA02 image, qpe will no longer load. The qpe init script (/etc/init.d/qpe) enters an infinite loop trying to start/restart qpe, and the qpe process terminates with the following error:

qpe: symbol lookup error: /opt/Qtopia/lib/libqtopiapim.so.4: undefined symbol: _ZN11QListWidget9dropEventEP10QDropEvent

This bug is reproducible by installing Qtopia and running the upgrade. Looks like a broken ABI after something changed in the upgrade?

Change History

comment:1 Changed 6 years ago by zecke

Which image (URL) did you flash? Which feed do you use for upgrades (URL)? I don't think that we as in Openmoko distribute Qtopia images or provide a feed for them? So it might be best to take this on with the providers of the feed?

comment:2 Changed 6 years ago by aeneby

The image is the one available from http://www.qtopia.net/modules/mydownloads/viewcat.php?cid=6 (bottom of the page) which contains the GTA02 kernel and rootfs images. The feeds were the standard http://buildhost.openmoko.org/daily-feed/ sources.

I have also alerted Trolltech to this issue and you're right, strictly it is a Trolltech issue - however the reason I posted here as well is because it's something that has changed in the past few Openmoko builds which is causing this error. I could previously run 'opkg upgrade' on Qtopia with no problems and I thought someone might know what had changed to cause this.

comment:3 Changed 6 years ago by zecke

  • Owner changed from zecke to openmoko-devel
  • Status changed from new to assigned

I just wonder how Openmoko can help. I had a look at the feed and can't find anything that would explain a partial upgrade of Qtopia base libraries resulting in the breakage you see. I think the only bet is to take it on with Nokia/Trolltech?.

comment:4 Changed 6 years ago by lpotter

Yes, this is mostly a Troll/nokia issue. A few things could resolve.

1) put qtopia-xx1 and qtopia in different places (./configure -prefix).
2) could better remove opkg packages in flash images TT releases.
3) package qtopia in opkg (will happen in 4.4) with proper conflicts

comment:5 Changed 6 years ago by yarikoptic

I want to complement to lpotter's words: /opt is commonly used in distributions to carry 3d party applications, ie which are not a part of the distribution. Thus indeed native qtopia is shipped 'correctly' by lpotter under /opt. OM does provide a distribution, thus it would be much better if none of the OMs packages installs under /opt, but rather uses /usr/ hierarchy (e.g. /usr/lib/qtopia).
That can help to avoid similar issues in the future.

For users to resolve the situation if you want to run native qtopia:

  1. remove all qtopia packages installed from OM's repositories:

opkg list_installed | awk '{print $1;}' | xargs opkg remove
NB typing from memory thus could be incorrect. you might also need to force removal disrespecting dependencies

  1. to make sure that all libraries links are reincarnated correctly -- reinstall /opt/Qtopa using freshly provided "binary update" script http://www.qtopia.net/modules/mydownloads/visit.php?lid=76

comment:6 Changed 6 years ago by zecke

1.) Unlikely, can Qtopia be installed to adhere to FHS (plugin dirs, etc dir, share dir)? Can it be build against the system Qt version (that would be installed to /usr/lib)?

2.) opkg remove task-openmoko-qtopia-x11 should remove everything from "Openmoko's Qtopia", also openmoko-asu-image can be easily changed to not install task-openmoko-qtopia-x11

3.) Happy release.

comment:7 Changed 6 years ago by zecke

  • Status changed from assigned to closed
  • Resolution set to fixed

Anyway, this is outside of Openmoko's scope.

Note: See TracTickets for help on using tickets.