Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #1897: OM2008.8-upgrade (Openmoko Public Trac)
2. Re: Openmoko Bug #1524: unable to uninstall kobodeluxe
package through assassin (Openmoko Public Trac)
3. Re: Openmoko Bug #1890: gdb problems (single stepping and
debug symbol table) (Openmoko Public Trac)
4. Re: Openmoko Bug #1896: Can't enter the PIN (Openmoko Public Trac)
5. Re: Openmoko Bug #1415: Cannot power on GSM Antenna
(Openmoko Public Trac)
6. Re: Openmoko Bug #1419: [splinter] Saved tag as same place
will be overlap. (Openmoko Public Trac)
7. Re: Openmoko Bug #1884: [suspend/resume] if press power
batton right after suspend, the device won't wake up
(Openmoko Public Trac)
--- Begin Message ---
#1897: OM2008.8-upgrade
------------------------+---------------------------------------------------
Reporter: Yorick | Owner: zecke
Type: defect | Status: new
Priority: highest | Milestone: Om2008.9
Component: Qtopia | Version: Om2008.8
Severity: blocker | Resolution:
Keywords: PIN | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by Yorick):
looks like I shouldn't have opened this one also (I did it because
https://docs.openmoko.org/trac/ticket/1766#comment:86 said to do it, but
https://docs.openmoko.org/trac/ticket/1766#comment:87 seems to say it
doesn't need a new bug report)
So please close this ticket
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1897#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1524: unable to uninstall kobodeluxe package through assassin
---------------------------+------------------------------------------------
Reporter: wendy_hung | Owner: [EMAIL PROTECTED]
Type: defect | Status: closed
Priority: normal | Milestone: Om2008.8
Component: Installer | Version:
Severity: normal | Resolution: worksforme
Keywords: | Blockedby:
Reproducible: | Blocking:
---------------------------+------------------------------------------------
Comment(by raster):
blank icons - know about this. problem is... it's hard to solve - at least
on the e/illume end. here is what happens:
opkg installs a new .desktop file. the kernel sends a message to e
(because it is listening for new files/changes/deleted files) saying a new
file appeared. e now opens the file and looks at it. the .desktop file
says "use icon X". illume waits 1 second then refreshes its application
list widget - the problem is, the .desktop says to use icon X, BUT.. icon
X isn't installed yet, because install takes so long. so a .desktop file
that triggers the refresh refers to a file that it hasn't installed yet,
and it takes so long toinstall that e gets bored of waiting (1 second) and
refreshes anyway (there isn't any other mechanism with FDO/XDG etc. to
trigger a refresh that i know of, so monitoring files is the way to go).
now the big problem. we can make it 2 seconds, or 3 - then yu will
complain that it is slow to refresh/show a new icon and we just ask for
more bugs there. also if the package is very big - it may take longer, and
so 2 or 3 seconds isn't enough, so we just play a cat and mouse game of
the longest package install vs. time to wait. it's not a game you want to
play.
the other problem is - e looks for the icon, doesn't find it. this result
is cached. searching for icons is very slow and expensive given the FDO
standards, so to be sanely efficient you need to cache results. since the
search failed - it has to cache that result for sanity. so a necessity of
the standard used requires this.
A solution is to make sure packages install icons before they install
.desktops - they should install .desktops very much last. this solves all
the issues that can turn up. otherwise we either cause performance
problems by removing caches, adding special files that you touch in the
applications dirs on end of install, have some magic tool to run to send
dbus or whatever messages to all apps saying "now i'm finished installing"
etc. either way you have to fiddle with packages and how they install
stuff to really get this kind of thing fixed... and if you fiddle - the
easy solution is simple install .desktop last :)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1524#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1890: gdb problems (single stepping and debug symbol table)
-------------------------+--------------------------------------------------
Reporter: h.koenig | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
-------------------------+--------------------------------------------------
Comment(by h.koenig):
update:
> BTW: I "only" have gdb-6.6 installed while gdb-6.8 source is available,
> maybe gdb-6.8 would work just fine. gdb-6.6 is quite old and reporting
> "bugs" for 1+ year old software without testing current release ins't
> too kind either ;-)
I build gdb-6.8 myself with MokoMakefile (surprisingly easy once I
realized
that gdb-6.8 is alreay supported with a .bb file).
with gdb-6.8 instruction single stepping seems to work correct (at least
for that "bxcc lr" as some few tests showed)
why does Om 2008.8 still include gdb-6.6 ?
> - that my Xglamo binary and .debug/Xglamo really fit together (see my
question about different time stamp)
so next I rebuild Xglamo using MokoMakefile -- and now I get all symbols
in gdb.
as I suggested: the -dbg package did't seem to match the installed
binary:-(
for reference here are the md5sums of the files I tried before:
f3e4aa396f53cfe0e70b167bb130f1fb /usr/bin/Xglamo.
34457ec11ce9a0398ac2c3923fff81c2 /usr/bin/.debug/Xglamo.
so an upstream report to gdb is not neccessary.
now, where can I advocade to update gdb to version 6.8 in Om 2008.9 ???
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1890#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1896: Can't enter the PIN
--------------------------------+-------------------------------------------
Reporter: madis | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
--------------------------------+-------------------------------------------
Comment(by lynx):
Please read:
http://wiki.openmoko.org/wiki/Om_2008.8_Keyboard
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1896#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1415: Cannot power on GSM Antenna
-------------------------------+--------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: sean_chiang
Type: defect | Status: new
Priority: high | Milestone:
Component: GSM Modem | Version: GTA02v6
Severity: critical | Resolution:
Keywords: | Blockedby:
Blocking: |
-------------------------------+--------------------------------------------
Comment(by robolange):
Any update on this annoying bug? Any intuition why it is failing?
In my experience, I use `libgsmd-tool -m shell` and use the `O` command to
power up the antenna. Nondeterministically with probability about 0.9
(guess), it will fail and produce the error noted. With probability about
0.1, it will succeed. I just keep issuing the `O` command until it
succeeds, which is usually after around 10 or so tries. After that,
registration typically proceeds correctly.
I have device GTA02Bv5, firmware Moko8. I use OM2007.2 with the latest
updates from opkg.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1415#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1419: [splinter] Saved tag as same place will be overlap.
----------------------------------------+-----------------------------------
Reporter: [EMAIL PROTECTED] | Owner: jeremy
Type: defect | Status: in_testing
Priority: high | Milestone: Om2008.9
Component: Locations | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
----------------------------------------+-----------------------------------
Changes (by jeremy):
* status: assigned => in_testing
Comment:
I don't get it. What's the issue about this? What's the expected behavior
for this?
I don't know what I should do. At this point, I think it's not an issue
and we can close this issue.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1419#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1884: [suspend/resume] if press power batton right after suspend, the device
won't wake up
--------------------------------+-------------------------------------------
Reporter: wendy_hung | Owner: andy
Type: defect | Status: new
Priority: high | Milestone: Om2008.9
Component: System Software | Version: Om2008.8
Severity: critical | Resolution:
Keywords: | Blockedby:
Reproducible: sometimes | Blocking:
--------------------------------+-------------------------------------------
Comment(by Treviño):
I've the same using the latest kernels available in repositories or in
buildhost since long time, that's why until this evening I've always used
the mwester stable kernel (that btw had some issues too as you can read
[http://lists.openmoko.org/pipermail/community/2008-August/027925.html
here]).
This evening, in fact, I've tried to get the latest stable kernel from git
to which I've applied also the latest glamo patches
([http://git.openmoko.org/?p=kernel.git;a=commit;h=653f1f27b2c09b8f3ee1869f35ff6a0a50bb01b0
fix-glamo-turbo-host-interface.patch] and
[http://git.openmoko.org/?p=kernel.git;a=commit;h=5b9e0604ca4691782680e52cae6ffac32881a6b0
fix-glamo-crank-memory-to-90MHz.patch] taken from the andy branch in order
to try to fix my problems with (X)glamo that has always freezed to me
after few minutes of usage -
[http://lists.openmoko.org/pipermail/support/2008-July/000660.html more
here]).
Well, while using the latest mwester kernel I was able to make it suspend
and resume nicely only if it was never attached to USB power (read above)
- but I had the glamo freezes (I used Xfbdev infact) - now, using my own
compiled kernel (using the defconfig-2.6.24), I've never got a
glamo/xglamo freeze but I neither was ever able to wakeup the phone from a
suspension (like with the latest stable kernels)!!!
Pratically every time I press the power button to suspend, I've to remove
the battery to make it reboot again.
I could attach also my image for tests. Maybe only my Freerunner refuses
it :|.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1884#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
