Re: FR: Problems, problems: please help
On Tue, 24 Mar 2009 01:33:10 +0100
Toni Mueller supp...@oeko.net wrote {heavily snipped}:
about one or two weeks ago, I've purchased a new FR, but haven't
gotten it to work as much as to be usable as a phone yet. The only
application that seems to be reliable so far is sudoku, which I
don't need.
After investing some 20 hours or so, I'm now at a loss
and don't know what else to try.
hmmm. 1-2 weeks, 20 hours. Sounds about right... :) I've figured
that I average about 10 hours a week with my FreeRunner (plus a few on
the mailing lists), down from about 30 a week the first few months.
There were a few issues with uboot early on, but if yours shipped
with 2008.8 it probably has a fixed version. There may be an
argument for updating to Qi, but you are probably better off
sticking with uboot for the moment.
I read about Qi, but since it can't do the networking and flashing
stuff, according to the wiki, I didn't try. Currently, maintenance
facilities are of utmost importance to me.
I've been using Qi for a few months now - it's a bit faster, and a lot
'quieter' - near-zero console messages during boot, and no bootsplash.
(not as pretty, but saves several seconds) It offers no boot menu,
so left to its own it will look for a kernel in /boot in each of the
first three (ext2/ext3) partitions on uSD, and failing that it will boot
the kernel in NAND. If you want to experiment with two different images
at once, one NAND and one on uSD, uBoot is simpler. (if you want four
you need to log into the uboot boot prompt via USB and edit the boot
parameters to support more than one on uSD)
Qi doesn't set up DFU support on boot, so you can't flash using it, but
you only put Qi in NAND - you can still boot from the uBoot in NOR and
use that to flash. (turn on with power...+aux for NAND, aux+power for
NOR)
or the repositories may have moved. The URLs for the repositories
can be found in files under /etc/opkg. I can't comment on the
specifics for 2008.12 as I haven't used it.
Under /etc/opkg I find only the addresses of the repositories that
were configured by the system, but not the repositories that I should
try to access. IOW, I don't know what to write there.
True... :) However, I'm curious as to what IS there.
The new toolchain Angus Ainsley announced a few hours ago contains the
following in opkg.conf (I'm not running 2008.x so have no other
reference, and usually each feed is in a separate file):
arch all 1
src/gz all http://downloads.openmoko.org/repository/unstable/all
arch any 6
src/gz any http://downloads.openmoko.org/repository/unstable/any
arch noarch 11
src/gz noarch http://downloads.openmoko.org/repository/unstable/noarch
arch arm 16
src/gz arm http://downloads.openmoko.org/repository/unstable/arm
arch armv4 21
src/gz armv4 http://downloads.openmoko.org/repository/unstable/armv4
arch armv4t 26
src/gz armv4t http://downloads.openmoko.org/repository/unstable/armv4t
arch om-gta02 31
src/gz om-gta02
http://downloads.openmoko.org/repository/unstable/om-gta02
So it would seem that those are the feeds that an up-to-date toolchain
will build packages against.
The /repository/testing folders are (IIRC, someone may correct me here)
the ones for 2008.12, but were last updated Jan 20.
FWIW, I expect to be able to use the device as a phone, a
navigation system, a music player and voice recorder.
http://www.opkg.org/package_8.html - TangoGPS (tracking/mapping)
http://www.opkg.org/package_5.html - Navit (navigation)
http://www.opkg.org/package_140.html - voicenote recorder
http://www.opkg.org/package_1.html - pythm music player
Try some of the other distros. You may find it easier to boot off
SD rather than reflash every time, and you could even dual- or
multi-boot. See: http://wiki.openmoko.org/wiki/Booting_from_SD
This is also only mentioned, but I could find no mentioning of how to
_install_ something on the SD card in the first place, or at least, I
didn't find it yet. Likewise for selecting the right one out of
umpteen distros that I might have installed (I have an 8GB card in the
device).
http://wiki.openmoko.org/wiki/Booting_from_SD
Taking the simpler case of a single installation on uSD and one in
NAND, put the uSD into a reader on a desktop/laptop and partition it
and install files as below.
If using uBoot I believe you need separate /boot partition still, which
used to be vfat but now (newer uboot from factory or flashed over NAND
uboot) works with ext2/ext3 /boot - just place the kernel file in the
root of that partition (first on the card), then extract the image
tarball (download the tar.gz instead of the .jffs for an SD install)
into the second partition, ext2/ext3.
If using Qi it expects the kernel in /boot as a folder in the root
partition itself, so extract the image tarball to the first (or only)
partition, ext2/ext3, then put the kernel in /boot. (actually the
rootfs already contains the kernel, IIRC)
For multiboot beyond those two
Re: Om2009 release plan
On Mon, 02 Mar 2009 09:14:56 -0700 Angus Ainslie nyt...@openmoko.org wrote: The following features already have an owner and will be taken care of before the end of March: phone calls incoming and outgoing sms incoming and outgoing simple phone book (no images) call log charging suspend and resume alarm clock resume speed 2 seconds boot time 2 minutes screen lock battery indicator (gta01 and gta02 battery) gsm indicator Then there are still features looking for someone to help bring them in before the end of March: Settings application gprs edge user changeable ring tones bluetooth wifi led indication for missed calls or sms sliding in UI Two questions. What about package management GUI - is one planned to be included? Can you clarify sliding in UI? j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: FSO Milestone 5
If you manually invoke '/etc/init.d/checkroot.sh' once it's finished booting and is still read-only, it will correctly remount root to read/write... This is the same checkroot.sh that is called early during startup yet apparently fails to remount / rw at that time. If you insert the remount command near the top of checkroot.sh it WILL successfully remount during initial boot, so it IS executing checkroot.sh during startup, but something is different between then and the manual invocation from the terminal once booting has finished. What?? j On Fri, 06 Feb 2009 21:22:51 -0500, Simon Comeau Martel si...@comeau.info wrote: You are right; / is in read-only mode when I boot from Qi. (and in rw mode when I boot from uBoot) The problem is not in 'checkroot.sh' itself; I compared that file from Milestone 5 to the one I had on a previous testing version which worked fine, and the file is exactly the same... Something must have change elsewhere. -- Simon Comeau Martel si...@comeau.info https://comeau.info Joel Newkirk wrote: On Fri, 06 Feb 2009 18:57:03 -0500, Simon Comeau Martel si...@comeau.info wrote: I have no idea how it is possible. All I know is that if I boot Milestone 5 via Qi, get the following message in zhone: Usage: Requested ressource GSM with error. And the problem is reproducible; it happen every time. Read-only filesystem. Once you've booted and see the GSM error in Zhone, open a terminal and try touch test - you'll get an error noting that the rootfs is read-only. Qi mounts rootfs read-only at the start - I believe /etc/init.d/checkroot.sh is where it's supposed to be remounted read/write. Many things will be 'broken' in this state, like you cannot SSH into it because dropbear doesn't start properly when it can't write, and just about everything with frameworkd is broken. Presuming this is the case (I'm betting;) try mount -o remount,rw / /etc/init.d/frameworkd restart stop Zhone, restart it, and it should be able to activate GSM... I've not worked through the logic in /etc/init.d/checkroot.sh or anything yet to see where this is failing, but putting the remount command at the top of that script will restore your FR to usefulness, remounting / rw fairly early in the boot process. (checkroot.sh is supposed to check the rootfs for errors /if/ it's ext2/3, and remount r/w afterwards, but doesn't seem to remount root if it's booted from jffs2 in NAND. As I said I've not followed the logic of the script yet but am guessing that if it's not ext2/3 it never reaches the remount,rw statement there.) j I guess that there could be something causing some kernel module not to load? Maybe I should try upgrading to a more recent version of Qi? The one I use is: qi-s3c2442-master_2ad3ce6ff57753e3.udfu (md5sum: 88979a8310a98d7a2189977194cb2607) Let me know if there is anything I can do to diagnose that problem. Is FSO Milestone 5 working fine for someone who use Qi? -- Simon Comeau Martel si...@comeau.info https://comeau.info Andy Green wrote: Somebody in the thread at some point said: | My install of FSO M5 is not on a SD card. | | As I said, all my problems where related to the fact I was using Qi, | instead of uBoot. It's not immediately obvious how Qi can trash the GSM connection and leave everything else OK. As in, if that was a feature we wanted to add to Qi, I don't know how we would do that. -Andy ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Distro?
On Sun, 1 Feb 2009 01:39:21 -0500, Seth Rothenberg s...@pachai.net wrote: Dear friends, I'll be travelling and thought I would bring along FR. I'm considering which distro to bring. I hope to have *phone - even if it's just to know when I have to find a land line to call home. I can't access the SIM until I get there. *notepad - just something to reduce lost paper *wifi - possible? *vpnc - google seems to say, I need debian. That's OK with me if it has the phone apps. gps (I can dream, can't I?) I have FDOM back in October, and it worked. Doesn't seem to work for me now. (i.e., it crashes). Thanks for humoring me... Seth I'd second the endorsement of SHR-unstable. TangoGPS works great (as long as your clock is correctly set, including timezone) and phone functions work acceptably well. Wifi seems broken in the most recent (Jan29 IIRC) images, hoping that is resolved again soon. notepad - there're a handful of simple text editors around, I can't suggest one offhand. I've not yet managed to get navit working with SHR-unstable though, so GPS location and mapping works but maybe not directions. Openvpn works fine, but doesn't cover the same scenarios as vpnc... I've not seen vpnc for the FR yet. So I cross-compiled it a few minutes ago (from svn) and it seems to run on my FR, but I've nothing handy to test it against. If someone wants to do so, I stuffed the config and binaries in a tarball at http://newkirk.us/om/vpnc.tar.gz - it depends on libgcrypt, shouldn't need anything else. The only alterations required were commenting out CC=gcc and ./makeman.pl in the makefile (no man on FR anyway) and opkg-target install libgcrypt libgcrypt-dev. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Question about Apache in OM
On Tue, 13 Jan 2009 17:40:02 +0100, Sergio Martínez-Losa Del Rincón sergiomtz.l...@gmail.com wrote: Hi all Does somebody know how a way to install apacha in OM 2007.2??? i've found something in this link : http://platformx.sourceforge.net/Documents/Enhancements/ipkg.html But i'm not sure to get it work with that URL Thanks http://www.angstrom-distribution.org/repo/?pkgname=apache2 (armv4t packages work on Freerunner) I've successfully installed and run it, but as it lacks php it wasn't of any immediate use for me. In theory anything armv4t at Angstrom is usable on the FreeRunner. In practice though, try not to use any more packages from there than absolutely necessary - IE, fulfill dependencies from OM feeds whenever possible to reduce chance of breaking something. (safest is to NOT add Angstrom to /etc/opkg/*.conf, just pull individual files manually like opkg install http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/apache2_2.2.3-r6.1_armv4t.ipk;, then any dependencies it can't find in OM feed you manually add to that command and run it again) j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [2008.12] ssh instability
On Thu, 8 Jan 2009 09:25:02 -0500, Paul pault...@gmail.com wrote: On Wed, Jan 7, 2009 at 10:56 PM, Robin Paulson robin.paul...@gmail.com wrote: and everything worked fine after that, so i figure it's the networking on the ubuntu side. any suggestions how to fix it? I'm pretty sure it's not on the ubuntu/debian side. -- Paul Email - pault...@gmail.com I snipped the following log entries from my Ubuntu desktop from an occurrence of this issue. The FR was sitting on the desk at the time, tethered to the PC for about an hour with suspend set to 'off'. As I'm typing this it's about an hour later and oddly it's not done it again. (oddly because like others I've observed that it seems to either NOT do it, or do it repeatedly) The battery indicator shows it's charging. I've enabled syslog to file on the FR to see if anything interesting turns up there. j Jan 8 19:46:30 j kernel: [24034.344067] usb 4-2: USB disconnect, address 11 Jan 8 19:46:30 j kernel: [24034.350234] usb0: unregister 'cdc_ether' usb-:00:1d.3-2, CDC Ethernet Device Jan 8 19:46:30 j avahi-daemon[4694]: Interface usb0.IPv4 no longer relevant for mDNS. Jan 8 19:46:30 j avahi-daemon[4694]: Leaving mDNS multicast group on interface usb0.IPv4 with address 192.168.0.201. Jan 8 19:46:30 j nm-system-settings:SCPlugin-Ifupdown: devices removed (udi: /org/freedesktop/Hal/devices/net_ea_ab_ce_f3_66_e1) Jan 8 19:46:30 j nm-system-settings:Ifupdown: get unmanaged devices count: 0 Jan 8 19:46:30 j avahi-daemon[4694]: Withdrawing address record for fe80::e8ab:ceff:fef3:66e1 on usb0. Jan 8 19:46:30 j avahi-daemon[4694]: Withdrawing address record for 192.168.0.201 on usb0. Jan 8 19:46:33 j kernel: [24037.036039] usb 4-2: new full speed USB device using uhci_hcd and address 12 Jan 8 19:46:33 j kernel: [24037.281089] usb 4-2: configuration #1 chosen from 2 choices Jan 8 19:46:33 j kernel: [24037.300861] usb0: register 'cdc_ether' at usb-:00:1d.3-2, CDC Ethernet Device, ea:ab:ce:f3:66:e1 Jan 8 19:46:33 j nm-system-settings:SCPlugin-Ifupdown: device added (udi: /org/freedesktop/Hal/devices/net_ea_ab_ce_f3_66_e1, iface: usb0): well known Jan 8 19:46:33 j nm-system-settings:Ifupdown: get unmanaged devices count: 1 -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [2008.12] ssh instability
On Wed, 7 Jan 2009 10:21:31 -0500, Paul pault...@gmail.com wrote: I can also confirm this. On Wed, Jan 7, 2009 at 5:26 AM, Joachim Ott jo.o...@googlemail.com wrote: 2009/1/7 Robin Paulson robin.paul...@gmail.com i'm having a lot of problems with my ssh connection over usb - it usually takes several attempts to connect, and will hang mid-way through operations very often sometimes un-plugging and re-plugging usb will sort it, sometimes leaving it for a minute or two, or suspending and resuming. sometimes it takes a reboot is this a known problem with the release, or more likely some specific problem here? it worked great with 2008.9, i never had a single problem Does ssh -v r...@neo 2ssh.log give you a hint, when the error occurs? And here I was blaming it on Ubuntu. I've noticed that when it happens the IP on usb0 on the HOST is lost - this suggests to me that it's NOT just losing the network link, certainly not just SSH, but rather that the USB connection itself is dropping out momentarily. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: SHR - Keyboard
but yell at this tiny pokey keyboard i can barely hit with a finger - and the device has no place for a stylus (and the one that comes with it is so huge i wouldn't be seen dead carrying it). :) you can't win. you make lot A happy, then lot B unhappy. thats why there are multiple layouts to at least give the options to both. the default lean is towards using it as a PHONE - not as a terminal. i would assume the nerds have enough braincells to rub together to switch layout :) I never said it was easy ;-) The corrective keyboard and the alternate keyboard layouts are hugely better than the matchbox keyboard, but there is a barrier to entry that the matchbox keyboard doesn't have. The matchbox keyboard is intuitive but ultimately limited as an input method as you say. The challenge is to lower the initial barrier for the illume keyboard so that more people get to see the advantages on the other side rather than giving up and ditching it for the matchbox one, only to run into its limitations at a later date. I think that in the long term if ordinary users are provided with some instruction how to navigate the multiple keyboards and the corrective typing feature that the Illume keyboard would be a hit. (given options to change default layout, language of layout, language of dictionary, etc, and maybe tweaked corrective layouts) IMHO the only thing the matchbox keyboard has over the Illume - with Terminal as default - is that it takes up a bit less room. I'd like to reclaim that space just on the terminal keyboard, and enlarge the keys on the others, but once I understood what the corrective keyboard was doing I was just fine with it. It rarely meets my needs, but I'm usually typing in shell commands, not texting. j PS - I was trying to explain the corrective feature to a coworker some time ago, and ended up using the simile of Wheel of Fortune: held letters are 'known', others are unknown but it knows they're near a given point on the keyboard layout, so it lists the words it can think of that fit. She instantly got it. (sorry if that loses something in translation - I realize a tv gameshow guessing hidden English phrases has limited appeal in non-english-dominated parts of the globe;) -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
On Tue, 16 Dec 2008 09:43:32 +1100, Dale Maggee anti...@internode.on.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karthik Kumar wrote: I know better. I could debate that at great length, cuz it's pretty god damn obvious to us all that you don't know shit, but I've had a better Idea - I'm just gonna create a filter to automatically delete anything sent by you. I hope for your sake you never have a problem with NeoTool. bye now. I did that several days ago - he joined 'dip^H^H^Hnishit dave' in my filter list. nothing like a good old fashioned shunning. :) j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklBQ4oACgkQOjLpvpq7dMpMqwCeJRix5jq8OH4JHR9OZiy+ylQS KYIAnjwxIPRXmY/qiBsDF0yAXhg1AUIB =JLh7 -END PGP SIGNATURE- ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support -- Karthik http://guilt.bafsoft.net ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Neo due-2 - NG - last chance
On Tue, 9 Dec 2008 11:31:51 -0800 (PST), GreyCardinal [EMAIL PROTECTED] wrote: No more ideas? -- View this message in context: http://n2.nabble.com/Neo-due-2---NG---last-chance-tp1630257p1635415.html Sent from the Openmoko Support mailing list archive at Nabble.com. While SSH'd into the blank FR, take a look in /sys/class/backlight/ and see what brightness is set to, and try to echo a different value to it. If it shows brightness already set to 100 or something and your display is unlighted I'd say it's likely your backlight is done, talk to OM or distributor about warranty. If you have no backlight when you boot up to NOR bootrom I'd say it's pretty certain already, but if you can SSH in and poke at the settings you can more readily assure yourself of that. Sorry I don't have more or better to offer, but I honestly think you're hit with a backlight failure at the hardware level. j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: dfu-util refusing to flash correct qi image
On Sat, 06 Dec 2008 22:24:44 +0100, Jelle De Loecker [EMAIL PROTECTED] wrote: Hi everyone, I'm trying to flash qi on my freerunner. I first tried the s3c6410 file, I thought that was the standard in all the freerunners. When *nothing* happened with that one I looked through my dmesg: s3c2410-ohci s3c2410-ohci: S3C24XX OHCI s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1 s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x4900 So, I tried the s3c2410 qi image, but then dfu-util says it's not meant for this device. Anyhow, no matter what qi image I try, nothing works. The kernel doesn't boot (and, yes, it's in the /boot folder), and I get NO blinking leds. Greetings, Jelle De Loecker Still one left to try, though: qi-s3c2442-master_2ad3ce6ff57753e3.udfu... ;) I'm using qi-s3c2442-andy_0d3272a8a81dab25.udfu (nov25) on my FR right now. :) j -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: why is my freerunner magnetic?
On Tue, 2 Dec 2008 19:33:25 +1300, Robin Paulson [EMAIL PROTECTED] wrote: 2008/12/2 Joel Newkirk [EMAIL PROTECTED]: the area in question is directly behind the battery connectors (i.e. away from the battery), pretty much behind the bottom-left corner of the screen, and is about 30mm x 30mm. it's more noticeable with the back taken off There are two speakers, you know... ;) not in the freerunner: http://wiki.openmoko.org/wiki/Neo_1973_vs_Neo_FreeRunner Yes, in the FreeRunner. The 1973 has stereo speakers AND the handset speaker, the FreeRunner has a Mono speaker AND the handset speaker. When you play an audio file on the FreeRunner without a headset, the sound comes out of the bottom of the FR, NOT out of the earpiece - that's the loudspeaker, located near the bottom of the screen. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: why is my freerunner magnetic?
On Tue, 2 Dec 2008 17:59:34 +1300, Robin Paulson [EMAIL PROTECTED] wrote: this probably seems like an odd question, but why does metallic stuff stick to the back of my freerunner? i noticed yesterday, that it had picked up a usb connector that was lying next to it. it wasn't near the speaker, so i know it's not the magnet in that. the area in question is directly behind the battery connectors (i.e. away from the battery), pretty much behind the bottom-left corner of the screen, and is about 30mm x 30mm. it's more noticeable with the back taken off There are two speakers, you know... ;) j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Sad Story
On Mon, 1 Dec 2008 11:40:08 -0600, Rene Horn [EMAIL PROTECTED] wrote: So sorry to hear that. [?] I would be pretty upset too if that happened to me. As far as anti-theft protection goes, has anyone heard of Adeona http://adeona.cs.washington.edu/index.html? That might be the way to go. Rene I was thinking along similar lines, utilizing my own server (which lives at a static IP) - but Adeona looks like a good starting point for a more widely useful solution. Their software needs additions to support GPS. IMHO that would benefit laptops as well - particularly if it could automatically look for bluetooth GPS and try to query position. (you never know - for that matter, log every bluetooth device it can see - some of which will be thieves cellphones) Another beneficial addition to both our purpose and laptops would be audio-recorder option. For Mac and Linux their software supports pulling images from a built-in webcam but no mention of audio. I'm thinking in terms of turning on the mic and feeding it over GPRS as a speex-encoded stream, accompanied by packets of data containing GPS/CellTower/Wifi data, obviously on-demand rather than always... j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Qt Extended] Take a screenshot?
On Wed, 29 Oct 2008 16:04:49 +1000, Lorn Potter [EMAIL PROTECTED] wrote: Joel Newkirk wrote: DISPLAY=:0 gpe-scap thats all fine and dandy, except gpe-scp does not run in Qt Extended (hence the [Qt Extended] in the subject) D'oh! Sorry about that, for some reason I missed that, my brain just blanked it out. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [Qt Extended] Take a screenshot?
On Wed, 29 Oct 2008 12:04:25 +0800, xiangfu [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jette, you can ssh the Freerunner, run the screenshot command under the ssh, it's will take the Freerunner screenshot. but i forget what the command it. Jette Derriche wrote: I am sure this is a trivial thing to do, but I just cant figure it out. If I select 'screenshot' it immediatly takes a screenshot of the current screen which is 'Applications'. How to I take a screenshot of any other screen? /Jette DISPLAY=:0 gpe-scap j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: tango
On Sun, 19 Oct 2008 00:56:19 -0400, Seth Rothenberg [EMAIL PROTECTED] wrote: so, how to upgrade if usb networking is unstable? Now, a few days later, it won't stay up long enough to... run neotool. From the time I bring up networking, until I click over to another window, it now fails. (I am on Ubuntu, 8.04) Does your network dropping happen with the FR running, or at boot menu? If while running, how are you starting it on the Hardy box? If manually, what command, and if via changed /etc/network/interfaces, can you paste your usb0 section? You don't use neotool (or dfu-util) to flash the Freerunner with USB networking. The Freerunner has to be at the NAND or NOR boot menu - it'll only stay there for 30 seconds unless you periodically press AUX, btw, until it's started flashing, so do this after selecting files to flash and just before clicking 'start' to begin flashing. If you're trying to bring up usb0 on the host machine at this point, there's nothing for it to talk to. So to flash, download a new image (like http://downloads.openmoko.org/releases/Om2008.8-update/ - you need 'gta02' versions of rootfs and uImage and rootfs may be .jffs2 or .jffs2.summary) and fire up Neotool. Tell it to flash, select the files, and it will tell you to prepare the Freerunner. At this point the FR should be off, and plugged into USB. Hold down 'aux', press and hold power now until the NOR boot menu appears, then release both. Click 'start' (or whatever the button is) in neotool and it will start flashing. rootfs will take quite some time. Once you've confirmed it finished correctly and boots the FR, consider also flashing the latest uboot bootloader - same procedure. Do I need to just get an SD card reader to copy the new image on? - will that help me? (will I need a bigger SD card? :-). no I don't suppose the FR will allow me to use the SD from the host without bringing up USB networking? no related - I saw a page about buying or building a USB crossover cable, so the FR could be a host. Could I then upgrade from a USB stick? AFAIK the FreeRunner currently has no way to flash itself from an image, regardless of where it's located. At best you'd only be able to flash bootsplash and uboot bootloader while the OS is running from the internal flash you'd be overwriting. Such a flash feature would need to be in the bootloader itself and (currently at least) is not. (uboot) Dfu-util is it, and neotool as GUI and extension for it. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: tango
On Sun, 19 Oct 2008 13:23:55 +0200, Joachim Ott [EMAIL PROTECTED] wrote: 2008/10/19 Joel Newkirk [EMAIL PROTECTED] AFAIK the FreeRunner currently has no way to flash itself from an image, regardless of where it's located. At best you'd only be able to flash bootsplash and uboot bootloader while the OS is running from the internal flash you'd be overwriting. Such a flash feature would need to be in the bootloader itself and (currently at least) is not. (uboot) Dfu-util is it, and neotool as GUI and extension for it. I haven't tried this yet, but when I've booted from SD (a bigger one than the original 512 MB that's delivered with the FR), why shouldn't I be able to erase and flash /dev/mtd kernel and rootfs like I'm doing with uboot environment? I'll give it a try next time I've mashed up the Om2008.8 that I have currently in NAND. Yes, if you've booted entirely off the SD card then changes to internal flash wouldn't hose your running environment. I've been imagining a flash util plus kernel in a uImage on SD, net result that you stuff the flash util uImage and the rootfs, kernel uImage or whatever on the SD with it, boot the FR from SD and it pops up the flash menu. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Re-registering to GSM network
On Tue, 14 Oct 2008 22:35:43 -0400, Joel Newkirk [EMAIL PROTECTED] wrote: On Tue, 14 Oct 2008 10:34:17 -0700, Michael Shiloh [EMAIL PROTECTED] wrote: Marco Trevisan (Treviño) wrote: Leonti Bielski wrote: As I get it it is unfortunately impossible to upgrade the firmware at home because of NDA - only Openmoko Inc. employee can do that. I hope (but doubt it ) it will will be available to the public someday in the future. Why? Isn't it a binary blob? I can't understand why they can't release the firmware binary... Two issues: 1. If we allow you to update the firmware, then our own standard of openness requires that we give you the source. Due to NDA with chip manufacturer, and probably FCC regulations as well, we're not allowed to give you the source, so therefore we chose not to allow you to update the firmware. 2. The NDA with the chip manufacturer does not allow us to distribute the update utility. Michael I'm very curious if that restriction extends to Openmoko performing the update via remote connection to the user's host computer or Freerunner... ;) Something along the lines of a 'firmware update installer' that we run locally, which tunnels to OM and triggers a firmware update run by managed by OM, but executing on the local host system or directly on the Freerunner. I'd have no objection to setting up remote login to my FR if that were needed for such an unusual circumstance as updating GSM firmware. (If it could be fully automated at your end so much the better, but even requiring manual action at your end it would probably be faster and cheaper for you, and certainly for us, than shipping every Freerunner suffering this issue back to OM for the update, always assuming that turns out to be the needed resolution of course...) I'm wondering if the restriction is more to protect the firmware itself or the utility that performs the update. j I'm starting to think of this as BUG#1. I tested the other evening, and with nominal full-strength GSM signal, 45% of my inbound calls (9 of 20) never reached the phone because it was re-registering. And I'm damned sure NOT happy with the prospect of another 2-week+ RMA cycle to get the firmware bug addressed. (worse I expect for other who bought from a distributor instead of direct - I assume you have to RMA through the distributor, who would then need to ship back to OM for firmware update, then back to distrib, then back to customer?? How long, 4 weeks??) Are any other options being explored? (Can unpaid interns at Openmoko perform the operation under the terms of the NDA? If so, how many offsite interns can you get away with having? ;) j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Re-registering to GSM network
On Fri, 17 Oct 2008 02:06:47 +0200, Marco Trevisan (Treviño)
[EMAIL PROTECTED] wrote:
Leonti Bielski wrote:
It's nr. 1 bug for me too. I have qTopia insalled, so in theory I've got
working phone. But, I can't use it as such, because It constantly
re-registers.
Well, honestly I've to say that I've never seen this in my phone.
Looking at logread it often repeats my operator name but it generally
stays up. I really have lost some calls, but I figure that
re-registering was never the cause.
So, is there a way to read the firmware version/timestamp? Just to
compare different behaviors!
BTW have you tried the mwester fix/workaround for this? It's available
for qtopia too (also in binary form).
http://wiki.openmoko.org/wiki/GSM_network_registration
With FSO/Frameworkd the two following commands are useful:
[EMAIL PROTECTED]:~# mdbus -s org.freesmartphone.ophoned
/org/freesmartphone/GSM/Device GetInfo
{ 'imei': '3546510',
'manufacturer': 'FIC/OpenMoko',
'model': 'Neo1973 GTA02 Embedded GSM Modem',
'revision': 'HW: GTA02BV5, GSM:
gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko8'}
[EMAIL PROTECTED]:~# mdbus -s org.freesmartphone.ogsmd
/org/freesmartphone/GSM/Device GetStatus
{'mode': 'automatic', 'registration': 'unregistered', 'strength': 61}
Note the 'Moko8' at the end of 'revision', returned by GetInfo. Normally
GetStatus should return something like:
[EMAIL PROTECTED]:~# mdbus -s org.freesmartphone.ogsmd
/org/freesmartphone/GSM/Device GetStatus
{ 'mode': 'automatic',
'provider': 'SunCom',
'registration': 'roaming',
'strength': 64}
(mdbus is in the ipk 'mickeydbus'
j
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: 2008.9: duplicate icons
On Wed, 15 Oct 2008 17:52:29 +0800, William Kenworthy [EMAIL PROTECTED] wrote: After a crash I have two icons for one application on the desktop - both work. Checking /usr/share/applications shows only one .desktop file. Is there a cache somewhere that needs cleaning out? - restarting the device doesnt help. BillK take a look in the .desktop file itself. Likely you'll find that multiple entries in categories= to be the cause, like categories=applications;network; - in which example my FR shows the icon twice, once for app and once for network. (I've encountered that before, as well as the oddity that Raster's test image at least doesn't recognize 'application' as a valid category, but requires 'applications' instead) I'm not sure what categories are actually valid at this time, but AFAIK they're all clumped together on the single lanuch screen regardless of category, and those with multiple categories may appear twice, depending on the categories themselves. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Re-registering to GSM network
On Tue, 14 Oct 2008 10:34:17 -0700, Michael Shiloh [EMAIL PROTECTED] wrote: Marco Trevisan (Treviño) wrote: Leonti Bielski wrote: As I get it it is unfortunately impossible to upgrade the firmware at home because of NDA - only Openmoko Inc. employee can do that. I hope (but doubt it ) it will will be available to the public someday in the future. Why? Isn't it a binary blob? I can't understand why they can't release the firmware binary... Two issues: 1. If we allow you to update the firmware, then our own standard of openness requires that we give you the source. Due to NDA with chip manufacturer, and probably FCC regulations as well, we're not allowed to give you the source, so therefore we chose not to allow you to update the firmware. 2. The NDA with the chip manufacturer does not allow us to distribute the update utility. Michael I'm very curious if that restriction extends to Openmoko performing the update via remote connection to the user's host computer or Freerunner... ;) Something along the lines of a 'firmware update installer' that we run locally, which tunnels to OM and triggers a firmware update run by managed by OM, but executing on the local host system or directly on the Freerunner. I'd have no objection to setting up remote login to my FR if that were needed for such an unusual circumstance as updating GSM firmware. (If it could be fully automated at your end so much the better, but even requiring manual action at your end it would probably be faster and cheaper for you, and certainly for us, than shipping every Freerunner suffering this issue back to OM for the update, always assuming that turns out to be the needed resolution of course...) I'm wondering if the restriction is more to protect the firmware itself or the utility that performs the update. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Re-registering to GSM network
On Tue, 14 Oct 2008 04:58:51 +1000, Lorn Potter [EMAIL PROTECTED] wrote: Michael 'Mickey' Lauer wrote: This is Openmoko bug #1024, which essentially seems to be a bug in the TI firmware. It depends on the TI Calypso sleep mode, the traffic in the cell you're logged into, and probably also your network operator's software running on the cell towers. We're experimenting with a band-aid atm (see bug-report for the entire gloryness...). I would say it has more to do with firmware. I have a gta01 that does this, a gta02 prototype that does it and a production FR that does not. All using the same gui, same sim, same tower, same operator, same network traffic. Using sleep mode on my production FR, stops it from properly waking up on phone calls and sms, so this is not reliable in stopping the bouncy calypso. I'm assuming that said firmware is field-upgradeable, right? :) So once a fix is devised it won't be just for newly-produced handsets, as might be the case with 'ordinary' cellphones. ;) I'm seeing this issue on a GTA02v6 (August production) with frameworkd and zhone. Don't recall ever observing it on my previous (pre-RMA, June production) GTA02v5, but it's possible that it's just frameworkd+zhone making it more visible to me. Inquiry shows me HW: GTA02BV5, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko8, though /proc/cpuinfo lists revision 0360. Carrier is T-Mobile in US, but I'm permanently roaming on either Suncom (being folded into T-Mobile now) or Cingular/ATT, and I've seen this happening on both roaming networks. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Backup Gordon
On Fri, 10 Oct 2008 18:21:48 -0700 (PDT), mrintensity [EMAIL PROTECTED] wrote: A note on the subject line: I figured if I had questions on flashing my FR, I would use the subject line Flash Gordon. Instead I have a question on backing up the FR. :-P When flashing, they make a big deal about having to use the the version of dfu-util that goes with the distro you are flashing. For example, to upgrade from om2007.2 to om2008.8 (ASU), you need to download the dfu-util for om2008.8. Umm, who is 'they' and where do they 'make a big deal'? I've not seen it anywhere, and can attest that I've never paid the slightest attention to what version of dfu-util I've used. I've flashed my FR at least 16 times, several different distros, no problems with dfu-util or the flashing process. What about backups? I downloaded om2007.8 and its associated dfu-util, and I want to use that dfu-util to back up my current om2007.2 image. Is that doable, or do I have to download the 2007.2 dfu-util just to back up 2007.2? That's a different matter - 'upload' (reading the flash memory and creating a jffs image on the host of the rootfs) is still broken in dfu-util.(http://docs.openmoko.org/trac/ticket/676) http://wiki.openmoko.org/wiki/Pre-Flash_Backup covers using dfu-util or other approaches to backup the current flash, (and warns that upload is broken) and http://wiki.openmoko.org/wiki/NeoTool covers NeoTool - a handy GUI that runs the console-only dfu-util for you. NeoTool also supports the tar-based backup, which is known to work reliably. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Trying to make DNS work
Just to clarify, when you're working on the FreeRunner via SSH, you're already root (superuser) so sudo is unnecessary, and as you discovered it can even cause problems. (with redirection) And it is possible to restart networking via SSH: /etc/init.d/networking restart should do it, but failing that you can use: /etc/init.d/networking stop; /etc/init.d/networking start When it stops, your SSH session is in limbo, with networking down. With both on one commandline, or with restart, your session will be interrupted then resume. (cursor may be unresponsive for several seconds, anything typed will queue up and happen when SSH session recovers) ;) j On Wed, 8 Oct 2008 04:31:38 -0700 (PDT), bum [EMAIL PROTECTED] wrote: Whoa! It works! Thanks a lot guys! Really appreciate it! =D On Wed, Oct 8, 2008 at 1:27 PM, Marc Verwerft [EMAIL PROTECTED][EMAIL PROTECTED] wrote: It's a typo. It should be /etc/init.d not /etc/inti.d Regards, Marc On Wed, Oct 8, 2008 at 1:19 PM, bum [EMAIL PROTECTED]http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=1306321i=0 wrote: I got the file edited now! But when I do: [EMAIL PROTECTED]:~# /etc/inti.d/networking restart -sh: /etc/inti.d/networking: not found Should I just disconnect and shut down the phone now? On Wed, Oct 8, 2008 at 1:05 PM, David Samblas-3 [EMAIL PROTECTED]http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=1306321i=1 [EMAIL PROTECTED]http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=1306321i=2 wrote: If you have a terminal app on the neo do /etc/inti.d/networking start from it and the connection will come back if no terminal app shutdown and restart again to edit files trough ssh session or trough the terminal app you can use vi #vi /etc/network/interfaces then put the cursor on the line you want to began to edit and press i then you can edit the file and can put the echo nameserver blablabla... lines when done and to save the file press esc and then :wq /etc/inti.d/networking restart El mié, 08-10-2008 a las 03:50 -0700, bum escribió: Okay. How shall I put the up echo in the file through neo? I log in with ssh then...? Regularly I'd use gedit but now I can't. I did the echo in the neo then /etc/init.d/networking stop But then the connection just hung... On Wed, Oct 8, 2008 at 12:38 PM, David Samblas-3 [EMAIL PROTECTED] http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=1306274i=0 [EMAIL PROTECTED] http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=1306274i=1 wrote: El mié, 08-10-2008 a las 03:05 -0700, bum escribió: Hello, ubuntu and openmoko newcomer here. I can successfully login to my freerunner with ssh and ping (ping 74.125.19.147) to the outside world but I can't ping to an address (ping www.google.com). I've tried most of the things http://wiki.openmoko.org/wiki/USB_Networking#Configure_Default_Neo_DNS here : My IP changes so I can't use echo nameserver 'myIP' /etc/resolv.conf. echo nameserver 208.67.222.222 /etc/resolv.conf echo nameserver 208.67.220.220 /etc/resolv.conf even if I don't understand it, but no luck. Getting error [EMAIL PROTECTED]:~$ sudo echo nameserver 208.67.222.222 /etc/resolv.conf bash: /etc/resolv.conf: Permission denied even with sudo... I dunno... You have to do the echo stuff in the neo not in you pc Tried placing up echo nameserver 208.67.222.222 /etc/resolv.conf up echo nameserver 208.67.220.220 /etc/resolv.conf in /etc/network/interfaces but no luck. this too has to be done in the neo after the interface modification do the following to make it active on the neo: /etc/init.d/networking stop /etc/init.d/networking start Proxying from desktop/laptop is the thing I'd want though as I have a laptop :-D Tried dnrd but don't know if I did it right... [EMAIL PROTECTED]:~$ sudo gedit /home/treeman/dnrd [sudo] password for treeman: (paste http://buildhost.automated.it/gta01 dnrd script ) [EMAIL PROTECTED]:~$ sudo chmod +x /home/treeman/dnrd [EMAIL PROTECTED]:~$ sudo /home/treeman/dnrd /home/treeman/dnrd: line 97: -a: command not found UDP forwarding link didn't work. Iptables: iptables -t nat -A PREROUTING -p tcp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1 iptables -t nat -A PREROUTING -p udp -s 192.168.0.202 -d 192.168.0.200 --dport domain -j DNAT --to-destination 192.168.0.1 no errors but didn't work. Also edited /etc/network/interfaces and added: # freerunner auto usb0 iface usb0 inet static address 192.168.0.200 netmask 255.255.255.192 post-up
Re: Duplicates
On Wed, 10 Sep 2008 02:57:27 -0700 (PDT), Yann Neveu [EMAIL PROTECTED] wrote: Ok so it does affect non gmail users too... I've posted precedent message using my ISP relayhost (free.fr) and according to the mail headers, the relay host sent 3 times the mail to sita.openmoko.org. I suppose sita replied the mail was not accepted, try later bla bla bla but finally dit it. So the server resent it 10 minutes later and 20 minutes later. Is there misconfigured greylisting on list? I'll try later with my own stmp to see the sita's responses cheking the logs. I tested it out pretty thoroughly (for being 'outside' the mailserver itself) and posted a long description on Sep1 Re: Duped Messages (OffTopic but important to lists.openmoko.org operations) on the Community list. The problem is that the mailserver sita.openmoko.org is sometimes taking a VERY long time to send the '250 OK' response after receiving a message, and the sending mailservers are giving up waiting and try to redeliver. Strictly speaking, they are supposed to wait for that response for up to 10 minutes before considering the delivery failed, but I consider that an antiquated spec, deriving from the SMTP RFC all the way back in 1982. Very few mailservers will actually sit and wait out the 10 minutes before giving up. In my telnet-to-smtp tests I gave up after 4+ minutes the 20% or so of attempts that it did this - the other 80% or so it responded with the '250 OK' almost immediately. It's likely that some virus or spam filtering measures on the receiving server (sita.openmoko.org) are getting hung up sometimes - especially since it doesn't always happen, even to the same sender from the same sending server. It's counter-intuitive, but the fix is often to limit the server to fewer simultaneous inbound connections, which has the effect of using less resources on the server. (sending servers will automatically retry, as we've seen) j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Duplicates - they won't be fixed on the server, so fix it locallyor live with it
On Wed, 10 Sep 2008 21:11:55 +0930, Rod Whitby [EMAIL PROTECTED] wrote: Q: How long has there been duplicates on the Openmoko mailing lists? A: Since the list got so big that sita.openmoko.org can't handle it. Q: How long has that been? A: At least a year, maybe more. Q: Has Openmoko done anything about it? A: Doesn't seem so. Must be a hard problem. Q: Is Openmoko likely to fix it? A: If they haven't fixed it by now, then chances are they probably won't. Q: What should I do about it? A: Don't email the list about - we all know already. Q: How can I fix it locally for me? A: Get a mail reader that understands that a message with a duplicate Message-Id header field doesn't need to be displayed to the user. Can we stop now? -- Rod The problem with that approach is that the situation will only get worse - exponentially. If the proximate cause is load on the server, then the same messages being delivered 2-4 times just increases that load, which will cause more messages to suffer the same effect - increasing the load, et cetera ad immobilium. Filtering out dupes at the recipient end is effective for not seeing the dupes (if available to the subscriber) but the underlying problem gets continually worse, using up more server and network resources. (not even factoring in increasing numbers of subscribers and posters) I've built and administered dozens of mailservers at ISPs, processing at one point over a million SMTP connections a day, so I've got some idea how 'hard' the problem is. I also know what happens to servers and their resources when they're overtaxed. But even from a more general perspective, hiding a problem never makes it go away. I realize this thread is utterly off-topic of Openmoko support, and believe me I was hesitant to bring it up again for that reason. But it really DOES need to be fixed, and this list is a reliable way of reaching several persons at Openmoko, persons who presumably have observed the effect themselves and can grasp the problem. Even with every message in this thread, it's still less than the number of duplicate messages received in a day... ;) And if your mail reader is advanced enough to offer duplicate-removal, it likely lets you ignore selected threads as well. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Om2008.8 wifi ... mschapv2
Apologies, I stand corrected. Can anyone confirm success connecting to an 802.11b AP? I recall several people being unable to connect except with G, and most of the info I googled on AR6000-series was the g-only 6002g. (and at the time I couldn't find a part number anywhere on the wiki) j On Tue, 09 Sep 2008 14:00:31 +0800, Neng-Yu Tu (Tony Tu) [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Joel- Check if the campus APs are supporting 802.11G connections. The Atheros AR6000 series chips are either G-only or A/G, they don't support 802.11B. (AR6002G is G-only, AR6002X is A/G, Freerunner uses 6002G) Unfortunately, the wiki indicate B/G in several places, such as http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware#WiFi_802.11_b.2Fg_transceiver http://wiki.openmoko.org/wiki/Wifi and http://wiki.openmoko.org/wiki/FreeRunner_Overview... FR using AR6001 instead of AR6002 - -- Neng-Yu Tu (Tony Tu) Openmoko, Inc. Support. Some questions could be answered by reference following link: Wiki - http://wiki.openmoko.org Download - http://downloads.openmoko.org Freerunner Introduction - http://wiki.openmoko.org/wiki/Getting_Started_with_your_Neo_FreeRunner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjGEP8ACgkQmV6sZhhBn2/GyQCgqrf8AzHBwUMWmcWU5E05Oqn+ HpkAnRr6D0kD4Olw9q+OCW0jn9/Hbiq7 =IP3N -END PGP SIGNATURE- ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Duplicates
Has any effort been made at addressing the duplicate message situation on lists.openmoko.org? (server sita.openmoko.org) I'd posted an analysis of the problem a couple weeks ago, (community lists, IIRC) but it's still happening and I've not seen any official word on the lists about it. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Om2008.8 wifi ... mschapv2
On Mon, 8 Sep 2008 12:31:48 -0500, Savio Monteiro [EMAIL PROTECTED] wrote: Hi, I recently bought the new openmoko freerunner and was trying to connect to my campus wifi n/w with the following /etc/network/interfaces and /etc/wpa_supplicant/wpa_supplicant.conf ... * Any Suggestions anybody? Would appreciate the help. The same configuration of interfaces and wpa_supplicant.conf works very well on my ubuntu laptop. Thanks a million for the support. Savio Monteiro. Check if the campus APs are supporting 802.11G connections. The Atheros AR6000 series chips are either G-only or A/G, they don't support 802.11B. (AR6002G is G-only, AR6002X is A/G, Freerunner uses 6002G) Unfortunately, the wiki indicate B/G in several places, such as http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware#WiFi_802.11_b.2Fg_transceiver http://wiki.openmoko.org/wiki/Wifi and http://wiki.openmoko.org/wiki/FreeRunner_Overview... j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Gesture Listener
Jim Colton wrote: So that the GUI applications work right, seems to me that they need to be built using Layout managers, the top manager in the GUI being called with the new dimensions by this gesture listener... after the orientation has changed. Each manager calls doLayout() on each of it's children. What do you think happens when a window is resized? ;) It's usually an oversight if an app is written with the expectation of permanent unchanging window dimensions. (even console-based Midnight Commander redraws itself to fit if its containing console is resized, though without the patch I'm polishing up it can't switch from horizontal to vertical layout automatically, just reshapes itself to fit) Even developing for a purely cellphone environment with modal apps you shouldn't presume you'll always have the same dimensions - in three months there might be an updated model with a higher resolution, for example. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Illume keyboard Disappeared
On Wed, 27 Aug 2008 09:28:55 +1000, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2008 16:00:08 -0400 Alex Fitzpatrick as best i know there is no way to turn qpe's keyboard off. until that happens there will always be fighting between illume's own keyboard and qpe's (As the vkbd system is generic allowing for any keyboard window - and illume just creates one of its own that gets picked up by the generic system). -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] Right now, that's an IMMENSE irritation for me. (and to judge by mailinglist traffic, for many many others as well) I had xterm running today, typing on the 'full qwerty' keyboard, and while I was staring at the screen that keyboard went away and the 'letters only' one appeared, and the only way I could get cursor keys back was to reboot the goddammed thing. I dare anyone to try editing a file with that useless excuse for a keyboard. It may be good for text messaging and naming entries in Contacts, but even there it has shortcomings, mostly caused by the dictionary interaction. The predictive error introduction and the need to switch keyboards for punctuation and numbers means it takes a painfully long time to type something like 'ip r d default via 192.168.0.201'. If the damned thing would just stay shut off when disabled it'd be acceptable. I've been seriously considering flashing to a different OS just because of the keyboard. Any OS that intermittently removes cursor keys requiring reboot to restore them is broken. j PS - I realize this and similar posts are mostly 'preaching to the choir'. Since a polling mechanism isn't readily available, would it be useful to start a 'qtopia keyboard vote' thread where people can be encouraged to post a simple 'make it die' or 'I love it' or whatever as a vote? Clearly someone controlling such decisions at Openmoko is insufficiently aware of the general loathing within the community toward that keyboard. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Illume config?
On Wed, 27 Aug 2008 09:27:32 +1000, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2008 21:12:50 +0430 Armin ranjbar [EMAIL PROTECTED] babbled: yes - because that spanner was never meant to be accessible or exist. it is sheer bi-product of the way asu was released that you could get it back through a theme change. so as such that illume-config theme is really a bug - or exposes a bug that was hidden. you can argue that but that config gives me all sorts of useful stuff etc. but that is not what om wanted - they explicitly did NOT want that config tool. (it's actually just part of e/illume - an internal dialog window). you can switch to the illume profile (the default profile changed to asu - see /etc/enlightenment/default_profile) and you'll get it back. It seems clear to me that someone in authority at Openmoko is trying to make a smartphone, without regard to the fact that probably 95% of sales to date are to developers who want to help MAKE that smartphone plus potentially much more, but have requirements which that authority is ignoring. (IE, they want pocket computer functionality, ready access to extensive configuration options, and - oh yeah, a usable keyboard that doesn't vanish at random) This falls under the heading how to kill a great product. I predict that if Openmoko fails, it will be due to abandonment by thousands of developers frustrated with narrowminded corporate decisions imposing intolerable limits. WTF - is their concept of 'Open' one where if we don't like their impositions that we should flash to Debian and abandon any development efforts for the 'official' distro?? If they don't want the developer community, I'm sure it will go away with just a little more effort. j ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: resolvconf problems
On Fri, 22 Aug 2008 13:17:42 +1000, Matt Joyce [EMAIL PROTECTED] wrote: On Fri, Aug 22, 2008 at 12:14 PM, abatrour [EMAIL PROTECTED] wrote: I've always edited the usb portion of my /etc/network/interfaces to this and its always worked. As you can see it writes the IP to the resolv.conf automatically every time at bootup. # Ethernet/RNDIS gadget (g_ether) # ... or on host side, usbnet and random hwaddr auto usb0 iface usb0 inet static address 192.168.0.202 netmask 255.255.255.0 network 192.168.0.0 gateway 192.168.0.1 up echo nameserver 208.67.222.222 /etc/resolv.conf up echo nameserver 208.67.220.220 /etc/resolv.conf #up echo nameserver 192.168.0.200 /etc/resolv.conf -- Just a comment: You're using a single redirect, which overwrites the file, so you're only ending up with one opendns.org dns server in resolv.conf. The second line should use to tell it to append. In support of local dns caching I've been digging through resolvconf and resolv.conf related scripts. One thing I noted is that /etc/ppp/ip-up.d/08setupdns simply overwrites the existing resolv.conf, rather than utilizing resolvconf, as does /etc/udhcpc.d/50default. For my purposes, it was simpler to circumvent resolvconf entirely, but if you want it to work it needs to be invoked... By default, it looks like only dhcp3/dhclient-enter-hooks.d/resolvconf is actually configured to use resolvconf, and ANY network device that comes online where resolvconf isn't used will break its intended behavior. (and wpa_supplicant, at least, is using udhcpc, NOT dhclient3) j Yes, that's true but is doesn't explain why resolvconf does not work as expected. It's been included in the build, and would appear to be the better solution, yet it does not appear to work. Matt ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
