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 #2056: /etc/resolv.conf is empty on first
boot (Openmoko Public Trac)
2. Re: Openmoko Bug #2056: /etc/resolv.conf is empty on first
boot (Openmoko Public Trac)
3. Re: Openmoko Bug #1795: 2008.8 Qtopia keyboard - missing keys
(Openmoko Public Trac)
4. Re: Openmoko Bug #1820: [Keyboard] add manual keyboard for
switching through options (Openmoko Public Trac)
5. Openmoko Bug #2057: 1bit errors in files (Openmoko Public Trac)
6. Re: Openmoko Bug #1244: Xglamo doesn't handle switch to
landscape mode correctly (was: Swap orientation horizontal view
not calibrated) (Openmoko Public Trac)
7. Re: Openmoko Bug #2012: 2008 updated and FDOM failure to
register to vodafone Australia (Openmoko Public Trac)
8. Re: Openmoko Bug #2012: 2008 updated and FDOM failure to
register to vodafone Australia (Openmoko Public Trac)
--- Begin Message ---
#2056: /etc/resolv.conf is empty on first boot
------------------------+---------------------------------------------------
Reporter: rwhitby | Owner: julian_chu
Type: defect | Status: new
Priority: normal | Milestone:
Component: Distro | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by newkirk):
If wlan utilizes resolvconf, then resolvconf itself will ensure that the
DNS servers associated with the wlan connection are used, NOT the DNS
server(s) associated with usb0. That's much of its purpose.
Whatever active interface (assuming they all interact with resolvconf, not
difficult) is highest in the list /etc/resolvconf/interface-order will
have its DNS servers inserted in /etc/resolv.conf - lower-priority (lower
in the list) interfaces will NOT, until/unless the higher-priority
interface goes down. (Again, presuming it cooperates with resolvconf)
The result is that usb0 tells resolvconf "use nameserver 192.168.0.254",
and resolvconf sets up to use that nameserver initially. Then eth0 comes
online, and DHCP provides DNS, so eth0 tells resolvconf "use nameserver
172.31.254.2", and resolvconf stuffs that into /etc/resolv.conf INSTEAD of
192.168.0.254. Then eth0 goes back down, and resolvconf knows to restore
the nameserver associated with usb0, since no higher-priority interface is
available.
I agree that 192.168.0.200 as nameserver is just offloading the headache
on the user, who must then deal with it in some fashion on the desktop -
not entirely unreasonable for linux developers, but it IS entirely
unreasonable for the run-of-the-mill phone user who just wants to upgrade
some things.
The 'simplest' solution is just to hardcode publicly-accessible caching
DNS server(s) like opendns.org in etc/resolv.conf. But unless all
interfaces leave it alone, it will still get broken when, for instance,
GPRS ppp stuffs the cell-carrier's DNS servers in there, then purges them
(or not!) on disconnect.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2056#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2056: /etc/resolv.conf is empty on first boot
------------------------+---------------------------------------------------
Reporter: rwhitby | Owner: julian_chu
Type: defect | Status: new
Priority: normal | Milestone:
Component: Distro | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by zecke):
Let me repeat (I might be wrong):
- usb0 is _on_ by default. Regardless of a usb cable being plugged or
not. (defaultroute)
- having a dns entry (using resolvconf or not) /etc/resolv.conf (no
matter where this content comes from)
- DNS times out after ~60 seconds by default (wlan off, bluetooth off,
usb unplugged)
is there a way to make both sides happy?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2056#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1795: 2008.8 Qtopia keyboard - missing keys
-------------------------------------------------+--------------------------
Reporter: Sander Hepp | Owner: openmoko-devel
Type: enhancement | Status: in_testing
Priority: normal | Milestone: Om2008.10
Component: Qtopia | Version: Om2008.8
Severity: normal | Resolution:
Keywords: keyboard 2008.8 missing keys, pm | Blockedby: 1820
Reproducible: | Blocking:
-------------------------------------------------+--------------------------
Changes (by zecke):
* status: assigned => in_testing
Comment:
I enabled the "keyboard" in the Qtopia source tree and I can input text
and navigate with it.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1795#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1820: [Keyboard] add manual keyboard for switching through options
----------------------------+-----------------------------------------------
Reporter: will | Owner: tick
Type: enhancement | Status: accepted
Priority: normal | Milestone: Om2008.10
Component: Qtopia | Version:
Severity: normal | Resolution:
Keywords: keyboard | Blockedby:
Reproducible: | Blocking: 1795
----------------------------+-----------------------------------------------
Comment(by zecke):
I have added a class that allows to switch the Qtopia keyboard via dbus. I
have not verified that illume is coping with the switch and om-settings
will need a way to switch the keyboard. The next step should be to hack
om-settings.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1820#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2057: 1bit errors in files
------------------------------+---------------------------------------------
Reporter: Richard.Kralovic | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Keywords: file corruption, 1bit errors
Blockedby: | Reproducible: rarely
Blocking: |
------------------------------+---------------------------------------------
After some time of usage, I notice 1 bit errors in some binaries/libraries
(affected application crashes, restarting the application does not, help,
of course). Files are correct after rebooting Neo again; even without
reflash.
I experienced this bug with different distributions (FSO, ASU...) and
different kernels (downloaded Om2008.9-gta02-20080916.uImage.bin, custom
built uImage-2.6.24+git0+a1e97c611253511ffc2d8c45e3e6d6894fa03fa3-r1.01
-om-gta02.bin, etc.).
There is no relevant information in dmesg output. I also added warning
messages to the software ECC correcting code (drivers/mtd/nand/nand_ecc.c)
to the custom build kernel, but none of them appeared in dmesg.
The bug is hard to reproduce on demand, but usually occurs after several
hours/days of usage.
Observed file corruption was always a single bit flip from 0 to 1, at
offset 0x????0c2 or 0x????8c2 of the affected file, e.g. as follows:
< 00008c0: 0200 0200 0000 0000 0300 0300 0100 0000 ................
---
> 00008c0: 0200 2200 0000 0000 0300 0300 0100 0000 ..".............
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2057>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1244: Xglamo doesn't handle switch to landscape mode correctly (was: Swap
orientation horizontal view not calibrated)
-------------------------------+--------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: reopened
Priority: highest | Milestone:
Component: System Software | Version:
Severity: major | Resolution:
Keywords: | Blockedby:
Blocking: |
-------------------------------+--------------------------------------------
Comment(by scarlson):
Replying to [comment:47 chgros]:
> Any chance this patch might make it into 2008.10 or whatever the next
update is? It's important as it allows to play vga resolution games.
Thanks!
I second that! I have a few game ports to release!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1244#comment:48>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2012: 2008 updated and FDOM failure to register to vodafone Australia
-----------------------------+----------------------------------------------
Reporter: billk | Owner: zecke
Type: defect | Status: new
Priority: normal | Milestone:
Component: Qtopia | Version: GTA02v5
Severity: major | Resolution:
Keywords: GSM Register | Blockedby:
Reproducible: always | Blocking:
-----------------------------+----------------------------------------------
Comment(by BillK):
Yes.
First, Ive just replaced the circa 1999 Vodafone SIM with a new 128K and
its vastly improved - enough for me to say its mostly a SIM problem
Yes, it seems to be a timing issue because if I power the GSM, then wait
30 seconds before stating qpe it has a greater success rate (not perfect!)
The new SIM improves it with the standard startup, but sometimes takes a
few reboots until the sim dialog pops up.
With no sim PIN set, it has never connected.
Next rebbot that fails I'll geberate a logread.
BillK
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2012#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2012: 2008 updated and FDOM failure to register to vodafone Australia
-----------------------------+----------------------------------------------
Reporter: billk | Owner: zecke
Type: defect | Status: new
Priority: normal | Milestone:
Component: Qtopia | Version: GTA02v5
Severity: major | Resolution:
Keywords: GSM Register | Blockedby:
Reproducible: always | Blocking:
-----------------------------+----------------------------------------------
Comment(by zecke):
Please read http://wiki.openmoko.org/wiki/Bug_Filing_Policy. You still
miss the output of logread and I'm not willing to do handwaving. Please
read the http://wiki.openmoko.org/wiki/Bug_Filing_Policy and attach the
output of logread once for a successfull and once for a non-successful
start.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2012#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
