Ticket #2088 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

[Testing] The settings app cannot be started

Reported by: dolfje Owned by: marek
Priority: normal Milestone:
Component: Settings Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:


I cannot start the settings application on my 'testing image' of 26 okt 08.

ps. I don't know what the command of the settings application is, so I'm unable to give you the command line output. If someone can tell, I'm eager to dump it here. ;)


Mon Oct 27 15-14-29 EST 2008.log (35.3 KB) - added by regina_kim 6 years ago.

Change History

comment:1 Changed 6 years ago by zecke

One can use opkg to query installed files of a specific package, /usr/bin/exposure.py should be the answer then and the starting is a bit special as it is forking off a python a process for faster start.

So with some luck some log (x.log or such in /var/log) should have an error message already.

comment:2 Changed 6 years ago by marek

  • Status changed from new to accepted
  • Owner changed from openmoko-devel to marek
  • Component changed from unknown to Settings

I just installed that image and tested it. Settings starts fine.

To debug your error kill exposure and start it from the command line:

killall exposure.py

exposure.py -f run

Changed 6 years ago by regina_kim

comment:3 Changed 6 years ago by regina_kim

u flashed base image (2008.10.27 kernel & rootfs) still happen. can not open setting.
step : 1.flash base image

2.turn on neo
3.press setting

comment:4 Changed 6 years ago by dolfje

It's probably something wrong with the upgrade path I took.

I had a testing image from 13 okt and upgraded it yesterday and I had a small top bar and really small icons.

Today I tried a flash of the newest image and it could start the settings app.

So sorry, I'm not able to reproduce this with the newest image.

comment:5 Changed 6 years ago by john_lee

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

i believe this is because of the recent change of EFL ABI. anyway this should already be sorted out in testing repo. Please reopen if you see this again.

comment:6 Changed 6 years ago by pooze

I have the same problem. Updated to the testing repo just a few hours ago. Struggled getting my icons back. Now they are back, but still cannot open Settings. Tried running it from the commandline, which gives me the following output:

root@om-gta02:~# exposure.py -f run
Traceback (most recent call last):

File "/usr/bin/exposure.py", line 304, in <module>

import etk

File "/usr/lib/python2.5/site-packages/etk/init.py", line 1, in <module>

from core import *

File "/usr/lib/python2.5/site-packages/etk/core.py", line 1, in <module>

import c_etk

ImportError?: /usr/lib/python2.5/site-packages/etk/c_etk.so: undefined symbol: evas_list_append

Hope this is helpfull. I have no permission to re-open though.

comment:7 Changed 6 years ago by marek

  • Status changed from closed to reopened
  • Resolution fixed deleted

Yes, it is helpful indeed. It shows that the etk binding does not work properly (c_etk.so: undefined symbol). Its propably related to the recent EFL changes. I think John can say more about it.

comment:8 Changed 6 years ago by marek

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

As no more complaints came in I guess its solved for everyone now.

comment:9 Changed 6 years ago by gromgull

Actually, I still have this problem with the latest packages from testing:

Traceback (most recent call last):
  File "/usr/bin/exposure.py", line 304, in <module>
    import etk
  File "/usr/lib/python2.5/site-packages/etk/__init__.py", line 1, in <module>
    from core import *
  File "/usr/lib/python2.5/site-packages/etk/core.py", line 1, in <module>
    import c_etk
ImportError: /usr/lib/python2.5/site-packages/etk/c_etk.so: undefined symbol: evas_list_append

opkg update'd today.

comment:10 Changed 6 years ago by marek

I guess you updated from stable at some point ?
Could you please check whether you are experiencing bug #2127 ?

comment:11 Changed 6 years ago by yarikoptic

PS Doh -- I would love to reopen it but apparently I don't have 'the permission'... imho that is silly... should I just file a new one then???

Today I hit the same issue here: I was running 'latest' FDOM and decided to try my luck again -- added all 'testing' opkg sources and did opkg upgrade... came to the point you know -- running exposure.py does nothing -- exists after 1-2 seconds

the issue was that python-etk installed was
so it is epoch 1:
is that the one from old 'stable'?
in any case, testing has now

But "opkg install", while 1:0.... is installed, fails to install even if I say -force-downgrade. So I just did manually

wget http://downloads.openmoko.org/repository/testing/armv4t/python-etk_0.3.0+svnr36882-r0.
opkg purge -force-depends python-etk
opkg install python-etk_0.3.0\+svnr36882-r0.01_armv4t.opk

now it starts fine...

I wonder if you should have used also epoch 1: for the correct upgrade from old stable?
can't compare for sure since documented feature of opkg causes segfault:

/usr/lib/python2.5/site-packages/etk#opkg compare_versions 1 '<=' 2
Segmentation fault


opkg compare_versions 1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03 '<=' 0.3.0+svnr36882-r0.01 && echo yes

Segmentation fault

at least on debian it would be indeed the case:

>dpkg --compare-versions '1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03' lt '0.3.0+svnr36882-r0.01' && echo yes || echo no

and if you add epoch -- you are safe:

>dpkg --compare-versions '1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03' lt '1:0.3.0+svnr36882-r0.01' && echo yes || echo no

So, imho, correct resolution would be to include epoch "1:" or even "2:" into the version of python-etk

comment:12 Changed 6 years ago by marek

This bug is closed because it was fixed. You experience an upgrade problem. A new bug was opened for that (#2127).

Note: See TracTickets for help on using tickets.