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 #1895: Games with blank icons in
task-openmoko-games (Openmoko Public Trac)
2. Openmoko Bug #2244: otimed is poorly designed/implemented in
a way that affects its operation (Openmoko Public Trac)
3. Openmoko Bug #2245: [testing scripts] add package to feeds
(Openmoko Public Trac)
4. Re: Openmoko Bug #2244: otimed is poorly designed/implemented
in a way that affects its operation (Openmoko Public Trac)
5. Re: Openmoko Bug #2241: GSM "deregistring" after registring
(Openmoko Public Trac)
--- Begin Message ---
#1895: Games with blank icons in task-openmoko-games
----------------------------------------+-----------------------------------
Reporter: hadu...@… | Owner: Nytowl
Type: enhancement | Status: closed
Priority: normal | Milestone:
Component: Distro | Version:
Severity: normal | Resolution: community
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
----------------------------------------+-----------------------------------
Changes (by Nytowl):
* status: new => closed
* haspatch: => 0
* resolution: => community
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1895#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2244: otimed is poorly designed/implemented in a way that affects its operation
-------------------------+--------------------------------------------------
Reporter: BillK | Owner: openmoko-devel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-------------------------+--------------------------------------------------
In 2008.12 I used ntpd for accurate timekeeping - worked well, though not
perfectly. SHR does not keep time well at all (jitters all over the
place, and doesnt seem to compensate for clock drift), and it seems to be
down to the way otimed is designed.
1. tries to set my timezone some 3000km away from where I actually am.
gsm providers in Australia seem to set the system time near where their
head office is - 2hrs ahead of where I am, and ignore daylight saving
which is on a different schedule in different states anyway. Its good
that its controllable in frameworkd.conf. But overiding the manual
timezone link automaticly is not the way to do it.
2. otimed "grabs" the ntp port so you cant run ntpdate or ntpd to correct
the time properly. Needs redesigning in such a way that a manual update
can be triggered if necessary.
3. one shot time updates have a place, but should be use with care Any
one shot update runs the risk of hitting severe jitter - and its happening
with the FR due to the poor choice of time server (see next) Think logs
and database timestamps - the system time jumps forward a few minutes then
back ... ntpd should also be able to adjust for local clock slow/fast
rates - certainly did on 2008.12 - otimed doesnt seem to do so so the time
drifts when not connected.
4. The default ntp server is somewhere in europe (Germany?) - thats fine
for the Europeans but what about the rest of us? - its just too far away
to be useful. I also never let my FR out onto the internet alone - I
always work through local networks - with their owm timeservers - otimed
should also do so. Note that its considered good practise to use a local
timeserver wherever possible to reduce the number of clients hitting main
servers. Too much traffic to a server creates delays and affects
timekeeping accuracy for all clients to that server.
5. Hard coding an IP address - if you dont know why this is a bad idea ...
The ntp people have pool.ntp.org set so you can get a reasonably local
timeserver. Also check out http://en.wikipedia.org/wiki/NTP_vandalism -
have you contacted the ntp server owner you have used - putting thousands
of units pointing to their ntp server is similar to what d-link did - and
that had consequences. NetGears hard coded IP was seen as a DOS attack by
its target ...
6. I suggest it be looked at with the following goals:
a. use the industry standard ntp system
b. be fully controllable before its released (some settings system -
editing a system file to change the ntp server ...)
c. use a pool server by default and make it configurable
d. document it properly - there is not a lot around on otimed - had on ask
on IRC before I made any headway.
BillK
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2244>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2245: [testing scripts] add package to feeds
--------------------+-------------------------------------------------------
Reporter: marek | Owner: Nytowl
Type: task | Status: new
Priority: normal | Milestone:
Component: Distro | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
--------------------+-------------------------------------------------------
The testing team works on test scripts that should help to reproduce bugs
faster. The repos can be found here:
http://git.openmoko.org/?p=testing_scripts.git
Please package this repos with AUTOREV - the scripts are not critical but
we may want to spread them fast.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2245>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2244: otimed is poorly designed/implemented in a way that affects its operation
-------------------------+--------------------------------------------------
Reporter: BillK | Owner: openmoko-devel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-------------------------+--------------------------------------------------
Comment(by f.hackenber...@…):
Just a general question: What was the motivation to rewrite a core service
like ntp in the first place? ntpd provides a lot of information about it's
state using logging and monitoring (see [1]). Could someone please
elaborate?
[1] http://www.eecis.udel.edu/~mills/ntp/html/decode.html
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2244#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2241: GSM "deregistring" after registring
---------------------+------------------------------------------------------
Reporter: keroami | Owner: mickey
Type: defect | Status: assigned
Priority: normal | Milestone: FSO
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
---------------------+------------------------------------------------------
Comment(by keroami):
This seems to have resulted in a dbus message
org.freesmartphone.GSM.Network.Status which still contains
strength/act/lac/cid/mode/registration but without code/provider. All six
values make sense (strength/cid vary, the rest stays the same), I'm still
connected.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2241#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
