Openmoko Bug #2088: [Testing] The settings app cannot be started

Openmoko Public Trac bugs at docs.openmoko.org
Wed Nov 26 22:35:25 CET 2008


#2088: [Testing] The settings app cannot be started
-------------------------+--------------------------------------------------
    Reporter:  dolfje    |        Owner:  marek 
        Type:  defect    |       Status:  closed
    Priority:  normal    |    Milestone:        
   Component:  Settings  |      Version:        
    Severity:  normal    |   Resolution:  fixed 
    Keywords:            |     Haspatch:  0     
   Blockedby:            |    Estimated:        
 Patchreview:            |     Blocking:        
Reproducible:            |  
-------------------------+--------------------------------------------------

Comment(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
 1:0.0.1+gitr101+8d36de2726003ad0356056fcf3ede5f2d3f4fca7-r1.03
 so it is epoch 1:
 is that the one from old 'stable'?
 in any case, testing has now
 0.3.0+svnr36882-r0.01

 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.
 01_armv4t.opk
 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

 or

 > 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
 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
 yes
 }}}

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

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2088#comment:11>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac


More information about the buglog mailing list