[om2008-testing] illume-config-illume + illume-theme-illume + illume
Hey all, Been out of the loop for a few weeks and decided to see if testing was working again. After updating I had the icons issue and used the combination of: illume-config-illume + illume-theme-illume + illume Which seems to be working except that when prompted to enter my pin I get the SEGV error popup. It seems to coincide with the keyboard popping up but that may be coincidence. At one point I saw this on the console: enlightenment: malloc(): memory corruption I don't have the entire message but it's probably unimportant. Everything else seems fine, it's just when prompted for my pin. Any ideas? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: uboot version? wiki not accurate
On Thursday 23 October 2008 22:13:02 Helmut Tessarek wrote: Hey, how many files with gta02v5 and u-boot in the name do you see? One. How many files do you see with 'latest' in the name? Is it possible to answer my questions or is the only thing you know how to be sarcastic? But I guess you just don't know it either: What is gta02v5_and_up-lowlevel.bin? Is there a stable version of uboot, or are there only daily builds available? Sarcasm and stating the obvious aside, there used to be an identical file to gta02v5_and_up-u-boot.bin that had 'latest' in the name, I assume to avoid people asking which one is the latest. It seems it no longer exists or possibly exists somewhere else. All that said, everything is pretty fluid at the moment and I've found that as long as you know you have a compatible u-boot image, checking the creation/modification date is more accurate than assuming somebody is maintaining the 'latest' file. Seeing as the 'lowlevel' image doesn't even contain the word 'u-boot', it's really outside the scope of obtaining a relevant u-boot image. Hope that helps. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New home for the New FDOM
On Friday 24 October 2008 07:33:04 David Samblas wrote: Quoting Matt Luzum [EMAIL PROTECTED]: Also, the tarball unpacks everything into var/tmp/root/. If I move everything from there into the root directory of the SD partition it boots, although I can't start contacts or the dialer. That could be something I did wrong, though. I don't think so. This was happening to me on testing and was due to a missing ld.so.cache. I had to uncomment ldconfig form the startup scripts to prevent this from occurring. I'm not sure what the correct fix really is, as I'm not sure as to the intended layout of the filesystem. No surely something I did wrong any body sees what's wrong in this sentece to make a tarball of a neo rootfs? #ssh [EMAIL PROTECTED] tar -cp /var/tmp/root -C /var/tmp/root|gzip - Fat_and_Dirty_OM.200808-updates.20080909.rootfs.tar.gz I'd say it's fine but you can abbreviate a bit by using 'tar cpzf' which will incorporate gzip. I think tar will preserve permissions automatically aswell, it's only when extracting I believe. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone interested in mentoring?
On Wednesday 22 October 2008 18:05:50 Minh Ha Duong wrote: Dear wanabee mentored, Mentoring might be the wrong term as it implies some obligation from the person assisting. If you were contributing code then I'm sure someone might consider it. Project managers already trust _you_ explicitely to go forward and commit the changes you think are good: anybody can edit wiki pages, open tickets and float patches around. But you don't trust yourself. Good judgement comes with experience, and you say you don't have much. So you want someone to review your changes before you commit them. Start with small fixes that are very obvious to you and you can explain well. If you are unsure, just post your opinion or your changes to the mailing lists. If you are even less confident, use your own blog (just don't expect anybody else to see it if it is not advertised on the planet !). Did you find a local user group in your area ? Ever since mankind discovered fermentation (thousands of years ago), sharing beer has been the #1 way to join a social group. Being polite and nice is mostly optional in the open source world.The currency is actual contributions. So you do something first, and someone will look it over. Minh I'm not sure if my quote was relevant, except that maybe I was too nice? The original email seemed to imply they required training rather than mentoring. They did not even mention possible code submission or areas of interest. Not to say your suggestions aren't very good ones mind you :) To the original sender, there's a saying; The only stupid question is the one not asked. You'll find in the open source world that that is definitely not the consensus ;) ... but don't be perturbed. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone interested in mentoring?
On Wednesday 22 October 2008 23:37:58 Minh Ha Duong wrote: Sarton said: I'm not sure if my quote was relevant, except that maybe I was too nice? Re-reading my mail, quoting you was not the best way to establish context for my reply, I should have cut and paste the question. Sorry about that. But I have no real regrets on reproducing your paragraph because I fully subscribe to it and could not have said it better. Ah, I see. I failed to identify you were elaborating on what I said, or at least mapping out a clear path for participation and possibly mentoring. In the context of elaboration/clarification it makes perfect sense, it just wasn't obvious to me ... and quite possibly only me :) But as I said, all good suggestions and worth stating. There's no 'generic participation entry point' for open source and I'm sure some people wouldn't be aware of all possible avenues, sometimes due to the obvious factor. Even I could use some of that advice ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 102, Issue 16
On Wednesday 22 October 2008 07:07:14 Matthew Lane wrote: No, I have not tried the 512mb card (it's at home and I'm at college). I'm not sure how to do what you're talking about arne, but you're suggesting that I can install a base system and put Debian on that? Can you point me in the correct direction? Also, my 8gb uSDHC card works That's debatable :) ... I have tried various cards and have installed debian successfully and unsuccessfully based on the card I use. I now only use 2GB cards and below as they don't seem to suffer from the issues 4GB seems to present. IMO try a smaller card before you consider alternative install methods, otherwise you might end up like me, with debian installed but randomness occurring. Also don't believe everything the FR reports, use a bit of trial and error, especially with uSD cards. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone interested in mentoring?
On Wednesday 22 October 2008 07:00:19 Jason Cawood wrote: I've owned my freerunner since july and have tinkered with it a lot trying out everything you guys throw out there. But I honestly don't know much about what I am doing... I'm to the point where I'd love to actually submit helpful bug reports and be able to SSH into my freerunner which I can't figure out how to put all the steps together for it to work for me. I guess I know enough to get me in trouble, but I also know enough to undo what I did to get out of trouble also. What I am asking is for someone to be willing to help me understand what I'm doing so that I can become helpful instead of dangerous. In the end, I would like to produce a better how-to less technical than what is available now to help others get started who are lost in technical data and instructions. Gday :) Don't be scared to ask questions on the list. If you are truly stuck with using a particular facility, ask away! ... If you are worried that the questions will clutter an otherwise, well, _cluttered list_ then I'm sure people will be willing to communicate in a limited fashion off-list. Myself included. Mentoring might be the wrong term as it implies some obligation from the person assisting. If you were contributing code then I'm sure someone might consider it. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.8 - testing] - no desktop icons any more.
On Wednesday 22 October 2008 03:33:04 Benedikt Schindler wrote: hi, is someone on the testing tree of the 2008.8 distro, and solved the icon problem yet? i upgraded to the latest testing 2008.8 packages. I know that there is a problem with the splash screen at boot up, that isn't solved yet. so i disabled the boot screen (btw: that saves 10 seconds boot time) But now i don't have any desktop icons. also the clock-, battery- and signal-panel is at one place now. i restored the old ~/.e directory but that didn't changed anything. Testing broke for me so I switched to fso-testing, which now seems to be almost as good as om2008 testing, when it actually worked ;) The facilities are no where near as comprehensive but I'm not fussed at this stage. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] man pages??? killing events/0
On Tuesday 21 October 2008 23:27:33 Matthias Apitz wrote: El día Tuesday, October 21, 2008 a las 12:51:22PM +1100, Sarton O'Brien escribió: ... You were asking for documentation for _technically_ a 3rd party program included on an embedded system. It makes sense to consult the website of the software or (heaven forbid) search for the man page. Last resort would be to install/extract the software on a system where you can read the documentation, which seems to be your preferred option. ... What I have exactly to checkout from SVN or GIT (?) to get access to the sources of Qtopia's 'qpe' demon which is part of Om2008.9; I've checked our Wiki but I got lost in all the diffrent places given there; This I don't know and would be better addressed as another subject as it really doesn't relate to your original question about generic linux interface and 3rd party application documentation ... you'll be more likely to get the attention you require. You may also have more milage on a developer list rather than a discussion list as it pertains to core development of the om2008 infrastructure. Qtopia in itself is a bit of a mystery, mainly due to it's current lineage. There are quite a few knowledgable people on here who can help you though, I just doubt they will be reading emails about man pages. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
On Tuesday 21 October 2008 18:47:58 DJDAS wrote: Sarton O'Brien ha scritto: Speaking of formatting ... I imagine there's a reply in there somewhere :P On Tuesday 21 October 2008 01:31:21 DJDAS wrote: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head /head .. /body /html Sorry :P Sent in HTML. I simply suggested a man indent ;) Bye! Hehe, I know, I was just ribbin ya ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
On Wednesday 22 October 2008 05:44:08 Joel Newkirk wrote: On Tue, 21 Oct 2008 16:29:30 +0100, Alastair Johnson [EMAIL PROTECTED] wrote: Joel Newkirk wrote: OK, I posted the updated package to htp://newkirk.us/om/testing/netfix-j2.tar.gz - using 'route' instead of 'ip' now to set up default routes. So the only external dependency should be for resolvconf on SHR and Raster (and I'm guessing FSO). Please test and post results or problems to this thread. Sounds good. I'll give it a try when I get the chance. It sounds like it should combine well with dnsmasq or similar. I've been using djbdns dnscache. You just need the cache startup to also invoke echo 'nameserver 127.0.0.1' | resolvconf -a lo and it always uses local cache first, drops to next priority if cache is broken or stopped. You can also stuff a custom script in /etc/resolvconf/update.d that will be able to take the prioritized nameservers and update your cache to use them as upstream caches. (I've an example script for dnscache, but it expects it to be running under the full daemontools+tcpserver setup whereas I run it as a simple standalone service) http://newkirk.us/om/dnscache_2.1.5_armv4t.ipk ;) Still yet to try, my apologies. om2008 testing died on me recently so I'm giving a few days until I chroot in and update again. I have nothing but respect for djb's tools, it hadn't twigged when you first mentioned dnscache, as it's been ... a while :) ... I'd say you've made the appropriate selection :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 102, Issue 16
On Wednesday 22 October 2008 12:44:27 Matthew Lane wrote: Sarton O'Brien wrote: On Wednesday 22 October 2008 07:07:14 Matthew Lane wrote: No, I have not tried the 512mb card (it's at home and I'm at college). I'm not sure how to do what you're talking about arne, but you're suggesting that I can install a base system and put Debian on that? Can you point me in the correct direction? Also, my 8gb uSDHC card works That's debatable :) ... I have tried various cards and have installed debian successfully and unsuccessfully based on the card I use. I now only use 2GB cards and below as they don't seem to suffer from the issues 4GB seems to present. IMO try a smaller card before you consider alternative install methods, otherwise you might end up like me, with debian installed but randomness occurring. Also don't believe everything the FR reports, use a bit of trial and error, especially with uSD cards. Sarton Sounds good, thanks. Do you have a suggestion on a 2GB card? I found a cheap (~$4) Kingston card on NewEgg, do you think that'll be fine? (http://www.newegg.com/Product/Product.aspx?Item=N82E16820134665) Well I run debian on a 2GB Apacer and om2008 on a 2GB Kingston. Both work fine. I can't gaurantee it will work but your chances are a lot higher :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] man pages??? killing events/0
On Monday 20 October 2008 18:57:21 Matthias Apitz wrote: El día Monday, October 20, 2008 a las 06:45:26PM +1100, Alex Osborne escribió: Well of course it's going to be different on FreeBSD -- different kernel -- but the location of the CPU time in /proc is going to be the same as any other system running the Linux kernel (well at least any that's not completely ancient anyway). So the simplest option, as I was suggesting is just to consult the proc manpage on any random Linux PC and if you don't have a Linux box handy then Google it, as people have put most of the man pages online. for example where is the man page of 'dropbear'? http://www.google.com/search?q=dropbear+manpage First result: http://downloads.openwrt.org/people/nico/man/man8/dropbear.8.html ;-) I thing Linux/UNIX goes the wrong way if we depend on Google to lookup man pages; Errr ... I've seen plenty of windows programs that don't come with documentation or relatively useless documention. Can't say the help facility is all that helpful either. You were asking for documentation for _technically_ a 3rd party program included on an embedded system. It makes sense to consult the website of the software or (heaven forbid) search for the man page. Last resort would be to install/extract the software on a system where you can read the documentation, which seems to be your preferred option. I don't think the suggestion was google is our documentation but merely that, if you bothered to search, you wouldn't have to bother us to search for you. Seriously though, if you must have the absolute exact same version for some reason and don't have a Linux box, just grab the source tarball: wget http://downloads.openmoko.org/sources/dropbear-0.51.tar.bz2 tar -jxvf dropbear-0.51.tar.bz2 cd dropbear-0.51 man ./dropbear.8 Now we're getting closer; thanks for the hint; maybe it would be a good idea if we have *all* man pages installed at http://downloads.openmoko.org/ or even as a fetch-able tar ball; in KDE you can just put 'man:ssh' into the KDE's browser Konqueror and you get what you want; Fair enough, but it's like expecting microsoft to host all the documentation for all the apps that you could _possibly_ install on their OS. As nice as that might be, it's not exactly realistic. Nearly any decent linux distro project has htmlised their man pages and from experience, reinventing the wheel can only ever have 'so much' benefit. The definitive place for any documentation will always be the source. Anything else could quite possibly be outdated. Possibly automated links to the official software source files/homepages would be more appropriate. The kernel itself is a different matter but once again, plenty of wheels are out there. Usually manpages aren't installed on embedded systems in the interests of saving space. Of course and I was not expecting the man pages installed on the FR. So searching the wiki and searching google are not akin? There seems to be a location dependency going on with your logic, I would have thought search relevance was what was important here and how quickly you can obtain the information you require. Seriously, this is the situation with embedded systems and I doubt any project can warrant the time for maintaining a man digest vs development. It's really not as much of an issue as you make it appear. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
Speaking of formatting ... I imagine there's a reply in there somewhere :P On Tuesday 21 October 2008 01:31:21 DJDAS wrote: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head /head body bgcolor=#ff text=#00 Rui Miguel Silva Seabra ha scritto: blockquote id=mid_20081020130945_GB9125_roque_1407_org cite=mid:[EMAIL PROTECTED] type=cite pre wrap=On Mon, Oct 20, 2008 at 01:33:20PM +0200, Fabian Henze wrote: /pre blockquote id=StationeryCiteGenerated_1 type=cite pre wrap=On 20.10.2008 at 12:00:36, Rui Miguel Silva Seabra wrote: /pre blockquote id=StationeryCiteGenerated_2 type=cite pre wrap=On Mon, Oct 20, 2008 at 01:37:33AM +0200, Fabian Henze wrote: /pre blockquote id=StationeryCiteGenerated_3 type=cite pre wrap=As it seems popular these days to publish a custom version of the rotate program, I am also going to do it. /pre /blockquote pre wrap=heh, you could've just sent a patch :) /pre /blockquote pre wrap=Then I would have to write in your style, which I am not used to :p /pre /blockquote pre wrap=! It would be easier than fixing the indent in order to join the patch and have you as a co-author :) I'm not prickly about any style, that's just my default and it's manually done. If someone can cookup indent recipes for converting between one and another I'd gladly use it to facilitate integration :)/pre /blockquote man indent? ;)br br /body /html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[om2008.x] qcop service send Launcher execute\(QString\) dialer crash
Sorry but I deleted the previous thread that this was related to. The problem for me seems to be a missing ld.so.cache. libqtsvg also claimed to be up-to-date regardless of a later version being available. Whoever it was saying they had a similar problem, try running ldconfig. If you want to upgrade libqtsvg you will have to -force-depends remove the existing one and then simply opkg install qtopia-phone-x11-libqtsvg. Now, back to root of the problem, seeing as ld.so.cache resides in volatile, is it suppose to be generated on boot or should there be another copy somewhere else? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [om2008] stable vs testing vs unstable
On Tuesday 14 October 2008 20:41:51 Benedikt Schindler wrote: i think there is a problem with the build server, or a patch that went into unstable killed the compiler. There doesn't even exist the Packages.gz files ... and i am sure they exists a few days ago. so unstable ist just as it says ... unstable it is also unstable in the fact of it's existens ;) In that context, even stable is unstable ;) btw: i couldn't install http://downloads.openmoko.org/repository/testing/om-gta02/distro-feed-confi gs_1.0-r0.02_om-gta02.opk there is a md5 checksum error. Are there valid sig files now? Besides, I don't install the feeds package, it almost never aligns with what is actually available. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Accelsense.org (accelerometer-based gestures)
On Wednesday 15 October 2008 06:06:40 Paul V. Borza wrote: Hi everyone, A couple of people asked me whether I will or won't continue my project on accelerometer-based gestures. My answer was always yes, and to make that clear, I've bought accelsense.com, and accelsense.org. The code has moved from http://code.google.com/p/accelges/ into a GIT repository located at http://repo.accelsense.org. I'm now in the first year of masters, and I've managed to get two of my courses into the accelerometer-based gestures (i.e. to implement this as homework). From now on, my professors require me to use SOMs (i.e. self-organizing maps, a type of neural networks), instead of hidden Markov models. A couple of you guys asked whether the efficiency and speed can be improved using HMMs. Again, the answer is yes, just that I don't have time to work on the HMM implementation anymore. Just wanted to let you know that from now on, I'll focus exclusively on working with the Neo, rather than the Wii to test the gestures; and make them smooth and natural. Nokia is using SOMs for gesture recognition in mobile phones, so we should be on the technology wave as I can tell (still, I'm just one guy). What I'll focus on in the 0.2 release: * use some code from the rotate application that is flying around. * keep the current Dbus system for interaction. * 10% of CPU (it's now using 20%), and yes it's doable. * no GUI, but change the text console UI to be something like 'top', and not just printf hundreds of xyz data. * reintegrate with matlab-compatible diagrams. * will still be in C99 and under LGPL. * math formulas that are used in code will have a link to http://wiki.accelsense.org/wiki/page and the formula will be written in LaTex. * some of you gave me advices on how to improve the organization of the project, will also do that. * some dependencies aren't checked, there are too many you say, will be removed. * integration with the freesmartphone.org Dbus FSO communication system (I've seen that it grew since I last checked it). * implementation of self-organizing maps. Bottom line: I'll be trying turn it in a mature project ;) You can do interesting things with SOMs, like Nokia was doing: detecting when the user climbs down, up or walks, just using an accelerometer. An impressive effort and a great example to us all :) Well done! Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] Using Freerunner as a digital audio player
On Wednesday 15 October 2008 05:42:32 Clemens Kirchgatterer wrote: Xavier Cremaschi [EMAIL PROTECTED] wrote: I just want a single view named Folders (which would be a file explorer) instead of the existing Albums, Artists, Genre. I totally understand that a tag-based player could be interesting for some people, but I *know* where my files are in my collection. FULL ACK! i allways find it strange if i can't make a playlist by simply selecting a directory from the filebrowser view. I found the media player in FSO completely usable and included a filebrowser. I think volume control was lacking but all in all it ran very nicely, until I updated and it didn't run at all. Out of all, this one showed the most promise to me, albeit a little ugly ... but that's a gtk thing ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Example of community manager job role (Was: FBReader now working on the FreeRunner)
On Monday 13 October 2008 07:48:10 Rod Whitby wrote: Seriously dude, this is meant to help improve the openmoko community, not flame about it. Don't stress, I think he was only one to have interpreted it that way. Anyone following the recent discussions properly would have understood your intention. Hopefully you've triggered somebody to think Ah yeah, good idea! :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Tuesday 14 October 2008 02:58:13 Joel Newkirk wrote: On Mon, 13 Oct 2008 17:48:50 +0200, David Samblas [EMAIL PROTECTED] wrote: El lun, 13-10-2008 a las 00:42 -0400, Joel Newkirk escribió: Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. j I'm not a kernel hacker only a user, but as I undertand It would be better to invert that behaviour, better to primary boot from NAND and then secondary boot on uSD, a normal user must boot his phone even without any uSD. Normal boot to nand, and if you want to boot from anything else do something else. It's a pitty than NOR uboot doesn't allow to boot from uSD by default, but this fault does't have to change the logical behaviour NAND is attached to the phone and is less likely blow up the hole S.O. sa mistake by a normal user putting some music in his uSD card trough a 2.0 Card reader :) seekeng for some free space If there's NO uSD, or the uSD doesn't contain a folder named 'boot' on the first partition, with a file named 'uImage.bin', then Qi will boot from NAND. It's just if you WANT a dual-boot environment that currently Qi doesn't let you do that simply. As Andy noted in his response to that post, however, he plans for Qi to support user selection of boot, it just doesn't do it at this time. Until it offers the ability to select, then the present behavior (check for kernel on uSD, else use NAND) makes more sense that always going to NAND and only NAND. I'm guessing with the current scenario, invoking a generic boot from nor means you lose any benefits of an updated u-boot/qi in nand? As in you may see power management regressions and the like? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FDOM] dialer crash
On Saturday 11 October 2008 01:46:12 julien cubizolles wrote: As of yesterday's updates from testing, the dialer won't start with an Enlightenment message : qcop service send Launcher execute\(QString\) dialer Any ideas ? Yes: # qcop service send Launcher execute\(QString\) dialer qcop: error while loading shared libraries: libQtSvg.so.4: cannot open shared object file: No such file or directory I'm about to try downgrading the version libqtdvg but am a bit busy and need to locate the opk. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Repositories missing after update to testing feed.
On Friday 10 October 2008 18:54:11 abatrour wrote: Hey guys I need help. After I upgraded from stock 2008.9 to the latest testing feed and rebooted I noticed most of my *feed.conf files are gone. All I have left are: arch.conf fic-gta02-feed.conf Multiverse-feed.conf Has anyone else encountered this problem? Yes. I have stopped using the distro-feeds package due to the inconsistencies between the files produced and the actual available repos. My suggestion would be to configure them manually. I keep three directories within /etc/opkg to store confs from the three repos I switch between. Admittedly this isn't that useful but it means I have a backup of all the required confs when I need them. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.x] GPRS Instructions on the Wiki
On Wednesday 15 October 2008 00:54:45 Arigead wrote: Configuring libdbus-glib-1-2 Collected errors: * Package libgobject-2.0-0 wants to install file /usr/lib/libgobject-2.0.so.0 But that file is already provided by package * libglib-2.0-0 Maybe the above is not a problem but if you've any advice I'll be very happy to get it opkg -force-depends remove libglib-2.0-0 opkg install libgobject-2.0-0 And if it doesn't pull libglib back in: opkg install libglib-2.0-0 From memory, after the first two commands, it should sort itself out. As long as you put back what gets removed, all should be well. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Wednesday 15 October 2008 15:36:40 Joel Newkirk wrote: [...snip] Interesting - I've been approaching it from the other end, trying to alter base configuration instead of adding a 'network manager'-like layer wrapping it all. When I look at the default behavior of the various interfaces, and various means of bringing them up/down, I see differing approaches where some use /etc/resolv.conf, some use resolvconf (the binary), some do their own thing, but none of them really cooperating. I feel if they're all brought in tune (all handling route and DNS additions/removals centrally, instead of each handling route DNS replacements as though they're king) that everything else becomes much simpler. Same thought. The main reason for our approach was due to the varying systems we maintain. More often than not they are *BSD, well for me anyway. This approach should function regardless of the underlying system, so long as it uses, say, udhcpc. I've been working on resolv.conf plus default routes lately, though most of the time I've been under Raster+FSO. (so frameworkd doing setup for GPRS, and requires it's own fixes to do what I want instead of within /etc/ppp) I've reached the conclusion that it will require changes to udhcpcd config (which currently does a blind replacement of /etc/resolv.conf) and ppp/ip-up.d/08setupdns (which currently creates /var/run/ppp/resolv.conf, then forces a symlink to it from /var/run/resolv.conf). /etc/resolv.conf is a symlink to /var/run/resolv.conf, and if udhcpcd works with it at /var/run/resolv.conf, (which might be better done via resolvconf bin instead, which works with /var/run/resolv.conf itself) then breaking that link is trivial, and the default behaviors would affect only that file, NOT /etc/resolv.conf which could be under new management, or a static 127.0.0.1 if dns caching is installed. And changing udhcpcd and ppp config is needed to address default route headaches as well. Yep, which is why we thought making the required changes as an afterthought or delayed event at least, would mitigate the effect of any existing networking changes being made by the OS facilities. I really like the idea of a cache. I also like /etc/resolv.conf being a symlink. In our possible approach, a config file specifying primary and secondary resolv.conf files, with a 127.0.0.1 + opendns override for the primary and the secondary containing whatever was last pushed to /etc/resolv.conf would address static and dynamic dns assignment. Metric per interface would be a config file option aswell. I currently have my Freerunner /almost/ working as I want, which is as follows: Local DNS cache with default upstream caches of opendns.org for unchanging simplicity (any static DNS would behave identically at this point in my setup), use Wifi if it's up for default route (metric 20), usbnet if wifi is down but usbnet is up (metric 30), and demand-dialed GPRS if usbnet is unavailable (metric 40). As I've got it, it should handle DNS changes properly, (subsystems are altering /var/run/resolv.conf) but that's untested since I'm running local caching. Once that's working fully automatically (getting close) I will check non-cached DNS and probably rewrite it to utilize resolvconf bin, then write the support script to tell dnscache to use dhcp-provided DNS servers as upstream caches, and finally look at VPN and a few more exotic possibilities. (I've got two USB ethernet adapters on a hub here that I've tested as a packet-sniffing bridge on the Freerunner, for example ;) Nice ... and now I can grasp why you might be utilising multiple routing tables :) I can definitely see your work filling the gap that currently exists, as much as I don't like the look of resolvconf, I'm all for something that works and this fits within the existing framework. I figured the rule for priority should be VPN first, followed by wifi, then any USB networking device (if in host mode) or usbnet to host (if in gadget mode), and finally (if desired) GPRS. For myself, I have the old T-Mobile unlimited (really, so far) internet3 'VPN' service, so my only concern with GPRS is avoiding its slowness when something faster is available - I realize other people who use GPRS may want to be more in control of it than I. (I've made a desktop icon to enable/disable it, which currently starts up the interface and leaves it in demand-dial waitstate, I'll eventually test it in direct up/down control) Well I guess metric is a personal matter :) ... and I guess that if the VPN is being added as a default route then the possibility of wanting it to be used is highly likely. If it's a dedicated route then metric is moot. OK, so mine should have gone VPN - Wired - Wireless - GPRS. Assuming usb can outperform wireless that is. My goal is to achieve everything without requiring a network manager of any significance. After that I'd like to have a widget in the top
[om2008] stable vs testing vs unstable
Hmmm ... I just noticed that stable (Om200.8) has surpassed testing in versioning. I now backup all my opk files per repo for easy switching but shouldn't testing at least be equal to or greater than stable? And what's the deal with unstable ... it doen't even look like a repo? For anyone else out there who is on testing and can't read their messages ... switch to stable and it will update :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: console command history
On Tuesday 14 October 2008 12:17:06 Joel Newkirk wrote: On Mon, 13 Oct 2008 23:21:18 +0200, Fox Mulder [EMAIL PROTECTED] wrote: If you use bash on OM than do it the same way how it is done in a normal linux pc. You must export HISTFILESIZE=1000 to set the number of lines saved to 1000. Just put this command in an adequate file to be executed at start like profile or bashrc. Ciao, Rainer Indeed, but how then do I tell it to use bash instead of ash for Terminal and ssh? vi /etc/passwd? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Default OM settings, no lan messed up
On Tuesday 14 October 2008 06:14:35 Joel Newkirk wrote: PS: ipcalc is a handy tool... $ ipcalc -b 192.168.1.20/29 Address: 192.168.1.20 Netmask: 255.255.255.248 = 29 Wildcard: 0.0.0.7 = Network: 192.168.1.16/29 HostMin: 192.168.1.17 HostMax: 192.168.1.22 Broadcast: 192.168.1.23 Hosts/Net: 6 Class C, Private Internet But you'll lose those awfully useful on-demand binary skillz :) Seriously though, nice tool. Would have been really handy when I was bothering with cisco, if only to give to the people looking over my shoulder ;). I swear they sit around trying to figure out how to confuse people as much as possible. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: console command history
On Tuesday 14 October 2008 13:21:21 Joel Newkirk wrote: vi /etc/passwd? Sarton (Ok, I'll go sit in the corner for five minutes wearing the stupid hat... I already knew that from desktop/server context but for some reason my brain just didn't make the connection...) Thanks. Hehe, don't stress :) I grew up on BSD (94/95) which has always been pretty baron so for a good long while before most of the automation existed, I did everything by hand and then continued doing it even when I didn't have to :S chsh was the first thing I checked for though :) Everything is so abstract now it's easy to forget the bottom layer. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Default OM settings, no lan messed up
On Tuesday 14 October 2008 13:38:45 Joel Newkirk wrote: On Tue, 14 Oct 2008 12:57:07 +1100, Sarton O'Brien [EMAIL PROTECTED] wrote: On Tuesday 14 October 2008 06:14:35 Joel Newkirk wrote: PS: ipcalc is a handy tool... $ ipcalc -b 192.168.1.20/29 Address: 192.168.1.20 Netmask: 255.255.255.248 = 29 Wildcard: 0.0.0.7 = Network: 192.168.1.16/29 HostMin: 192.168.1.17 HostMax: 192.168.1.22 Broadcast: 192.168.1.23 Hosts/Net: 6 Class C, Private Internet But you'll lose those awfully useful on-demand binary skillz :) Seriously though, nice tool. Would have been really handy when I was bothering with cisco, if only to give to the people looking over my shoulder ;). I swear they sit around trying to figure out how to confuse people as much as possible. Sarton sort of like riding a bicycle... My first computer I programmed via a hex keypad, 1802 machine code (no assembler, no mnemonics, just hex opcodes), so at the start of things I became (painfully) familiar with hex-dec-bin relationships, masks, and binary arithmetic. (I still see things like 'a*8' while my brain thinks 'a3') I agree, though I haven't ridden that bicycle for a very long time. Although I've done some programming using hex on the z80s, I was always very fluent at deriving binary logic and determining boolean expressions by briefly looking at a diagram. So shuffling binary around in my head was never an issue, but the base 10 conversion was. Hex - binary was always easier but most likely due to the typically quad/octal nature of computing. For the people over your shoulder you should omit the '-b' flag, which tells it to skip the bitwise output... ;) $ ipcalc 192.168.1.20/29 Address: 192.168.1.20 1100.10101000.0001.00010 100 Netmask: 255.255.255.248 = 29 ...1 000 Wildcard: 0.0.0.7 ...0 111 = Network: 192.168.1.16/29 1100.10101000.0001.00010 000 HostMin: 192.168.1.17 1100.10101000.0001.00010 001 HostMax: 192.168.1.22 1100.10101000.0001.00010 110 Broadcast: 192.168.1.23 1100.10101000.0001.00010 111 Hosts/Net: 6 Class C, Private Internet Yep, this program would have saved me a lot of time ;) Seems most people who don't understand binary all the way down to their souls can't even see the dotted quads, their eyes and brains get stuck on the 'big' block of binary. You mean octal yeah? For those interested in achieving understanding of netmasks it can be helpful to generate a few of these for familiar networks and look at the binary portion... The meaning of a /29 netmask for example is pretty clear above. I second that. Anyone who doesn't completely understand what they are doing when they alter routes, IPs and netmasks should make sure to investigate further. Worst case you might light up an area of your brain that hasn't seen activity in a while :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9] Wifi very unreliable
On Friday 10 October 2008 03:05:07 Michael Shiloh wrote: All things wifi, including known issues and a link to Tom's article, are here: http://wiki.openmoko.org/wiki/Neo_FreeRunner_Wifi Yep, but my point was that Tom's article covers way more than wifi and therefore could be indexed under multiple troubleshooting categories, along with other external sources. Currently you would have to access each applicable wiki area and add the link, then do the same when the link changes. Rather than than say 'this person did this here', why not say 'see the wifi section in troubleshooting' and have a small write up for each link? There's no problem with linking haphazardly, it just eliminates a single point of maintenance. This is just my view, no need to reply with any links, unless it to a troubleshooting index ;) ... I may even compile one up myself for personal use as I only use the wiki for troubleshooting and I tend to do more reading and searching than anything else. Something like this would be easy to create on the fly. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian size and uSD
On Thursday 02 October 2008 07:43:42 Atilla Filiz wrote: A consistency check with fdisk yielded that the size of the partition and the size of the filesystem do not match, and advised me to run e2fsck. e2fsck said there are no problems. I ran fdisk and e2fsck on FR-debian. gparted on my py sees the partition as 2GB. darn it. Although the process you chose is a good exercise for block copying/boundary resizing and the like ... you could have avoided the problems and had the system running within half an hour using tar :) TBH, it takes me about 15 mins :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WIFI Connector Application
On Friday 26 September 2008 19:18:43 Matthias Apitz wrote: I've typed in the key in the FR again and again but it always said after some time 'ERROR Unable to join network' Yeah, it looks like there is quite a bit of separation between all the different facilities. The 'Settings-Wifi' GUI sort of works. If you select a network and enter a key (I've only tried WPA-PSK-TKIP), switch to a terminal, wait for the wireless indicator to appear and then issue 'udhcpc eth0', it all works. The error has always appeared for me but the facility has still worked. Better yet, the latest testing update seems to allow the wireless indicator to disappear when you select wireless off. This is with no wpa_supplicant.conf. Manually launching wpa_supplicant is trivial for debugging, just bump up the verbosity and omit the '-B'. I get the impression that a lot of the facilities haven't yet been configured to utilise any one particular network management scheme ... heard of resolvconf? ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian size and uSD
On Wednesday 01 October 2008 08:26:05 Atilla Filiz wrote: After I installed Debian on my stock uSD, i realized that Debian is _BIG_. There are tons of libraries installed. I think a lighter Debian is possible, any ideas? Another thing is I bought a 2G uSD and I want to move my debian system to that card. If I manually partition it (8MB fat and rest ext2) and just copy contents of 512M, would it work? Or maybe i can copy an image using dd and then somehow resize the partition. Anyone tried migrating from one SD to another? You could use copy but tar tends to be a better alternative. Just tar up your rootfs and then extract to your new card. Under most *nix variants you need to extract using the 'p' parameter to preserve file permissions. Also make sure you are not mounted with the option 'nodev'. With a new u-boot it's also possible to consolidate the kernel and rootfs into one partition to ease kernel upgrades. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dead battery
On Wednesday 01 October 2008 05:52:38 Vince M. Clark wrote: I've tried that, as well as the wall charger. The battery is totally dead and my fr will not boot, regardless of how long I leave it plugged in. 6 - 8 hours on the wall charger is not unusual for my dead battery to start to function. How long have you left it? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dead battery
On Wednesday 01 October 2008 09:31:22 Vince M. Clark wrote: Not that long on the wall charger. I'll leave it overnight and see what happens. I have left in on the USB charger for a few hours with no luck. The 'leave it overnight' scenario is the best one I encounter for a dead battery ;) ... I think you'll be right. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dead battery
On Wednesday 01 October 2008 09:37:22 Shawn prjktdtnt Thompson wrote: Vince M. Clark wrote: Thanks Shawn. I have tried NOR boot (holding aux button while pressing power button, then releasing aux button.) I cannot even get that far. I'm going to leave it plugged into the wall charger overnight and see what happens. In the meantime i ordered an after market Nokia battery charger. They are cheap but it looks like it may take a week or so to get it. Vince, When my battery died I plugged my phone into the OpenMoko supplied charger, started it using NOR boot, leaving it at the boot menu until it timed out (repeat that twice) then I was about to select boot from the NOR menu and after a few extra seconds the phone booted. When trying to get into NOR do you already have it plugged into your charger? That is how I was able to finally get mine to boot, you only need the actual OpenMoko charger until it starts up then you can use whatever USB charger you prefer. Just plug into wall-socket and phone, start NOR twice, viola. Not to be a killjoy but I think there may be varied levels of 'dead'. I've had a similar situation but it's not always he case. When you can't get anything to happen, the only solution is to plug it in and go to bed (assuming you have no other options at hand). Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dead battery
On Wednesday 01 October 2008 09:45:08 Shawn prjktdtnt Thompson wrote: Odd. Sadly that is the only way I was able to get mine going again, would be nice to see a patch that corrects the issue somehow so that people don't have to use workarounds in the future. -Shawn I don't think it is as complicated as that. I think it's merely the amount of charge the FR is able to negotiate when powered off. Depending on the level of 'dead' determines how long you need to trickle charge it before anything useful occurs. I'd say battery maintenance and usage patterns may contribute also. From what I have seen on this list, I don't think this situation will change in a hurry, if ever. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dead battery
On Wednesday 01 October 2008 09:56:00 Shawn prjktdtnt Thompson wrote: What I had meant is that I hope they find away to allow 1000mA charging while powered off so that you don't have to let it tricle charge for the entire night to power it on at only partial power. Of all the phones I've owned none of them had this problem and it's probably the most annoying problem I can think of with the OpenMoko. Lucikly for me I'm the type to plug in my phone daily so it isn't a problem but I could see it becoming one in the future when more and more people start using the OpenMoko products Yes, I understand. I got the impression it was a design flaw and not something that could be addressed, that's all. I could be completely wrong though. Maybe the phone can go into some kind of holding pattern when close to flat or something, to mitigate the effect. If it's something a u-boot update can fix then that would awesome ... but I'm not holding my breath. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9] Wifi very unreliable
On Tuesday 30 September 2008 19:06:28 Matthias Apitz wrote: this works very unreliable; in (let's say) 8 of 10 cases it can't associate to the AP, even not after fresh re-boots and independently if the AP at my home works with WEP or in my office with WPA; what can I do? is someone willing to look into the debug output of the wpa_supplicant? or do I need somehow an update in the kernel drivers? I've installed as well lint-wifi; this does not even see the AP next door and to which I'm now after 2-3 tries connected too; strange, isn't it? there must be something broken in kernel land, I think; I use testing and have varied success with wifi. I don't bother with trying to identify what going on by what's being reported. It has been stated on here that the issues with the driver are great enough that statistics may be skewed. What I have witnessed is that sometimes it appears the wireless hardware is next to useless ... but then under a different update or on another day it functions flawlessly even in a problematic area of the house. When I was running stable with no real updates coming down, I couldn't even be bothered with wireless. At the moment, I am having issues. Selecting wireless 'on' results in nothing being displayed. I have to push all my scripts back across so I haven't tested manually yet. So in summary, I don't think it's worth attempting to figure this out as an end user as yet. I believe it's driver/kernel related. The hardware itself is quite new so it doesn't really surprise me. I'd wait for a statement as _everybody_ has this problem. I can't imagine the devs are sitting there with freerunners and working wireless ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dead battery
On Wednesday 01 October 2008 10:20:59 Shawn prjktdtnt Thompson wrote: Yes, I understand. I got the impression it was a design flaw and not something that could be addressed, that's all. I could be completely wrong though. Maybe the phone can go into some kind of holding pattern when close to flat or something, to mitigate the effect. If it's something a u-boot update can fix then that would awesome ... but I'm not holding my breath. Sarton That is how I understood it too but that is something that if they're unable to address on 1973/FreeRunner they need to address before GTA03, IMO Of course ... unless there's an 'intentional commercial suicide' department within openmoko ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[om2008-testing] qpe cpu usage when dialer open
96% cpu usage just to have the dialer open. Awesome! :) Updated a couple of hours ago. Anyone aware of this? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is anyone from openmoko working on Bug #1841 (wsod)
On Friday 26 September 2008 16:41:49 Petr Vanek wrote: I use testing too but no luck :( , tried opkg upgrade right now and just copied kernel version from wsod freerunner by ssh: kernel-image-2.6.24 - 3:2.6.24+gitr109+a1e97c611253511ffc2d8c45e3e6d6894fa03fa3-r2 - is there any special procedure you follow? boot up with usb in/out? suspend with usb in/out? ok ... there may be a few things ... I don't know what base system you installed but I used to use the raster image. An opkg upgrade via testing worked but I had major issues. Extracting a fresh asu build and updating had no such issues. When I start using testing, I overwrite all configurations with the developer versions, to make sure I'm starting with the intended functionality. Then on top of that, I make sure to use the latest u-boot provided via the daily testing images. Everything works pretty good. I've yet to get any of the games working though (specifically kobodeluxe, numpty physics and duke3d). I haven't really attempted to look into it much so I can't say why these aren't working. Oh, I've noticed after the latest update, the wireless indicator actually goes away when you select wireless 'off' ... awesome ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9] What, no updates?...
On Friday 26 September 2008 00:50:14 [EMAIL PROTECTED] wrote: Hi. It's been a long time since the last real update of packages for the 2008.x feeds. Everyday I do opkg update and opkg upgrade and all that comes down is the angstrom version file. Since there are still a lot of bugs to solve, I find this strange... What's happening?... why aren't there any updates? Is OM working on something else entirely, or taking a vacation? :) I get the impression updates are staged fairly well for stable. I use testing (and it runs fantatsic at the moment, can use as a daily phone) and updates are pushed pretty much every day. I guess it comes down to your avenue of participation :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 22:06:29 Joel Newkirk wrote: On Thu, 25 Sep 2008 18:45:32 +1000, [EMAIL PROTECTED] wrote: Joel Newkirk wrote: So for example, usb0 coming up stuffs 192.168.0.201 in as nameserver, but does it by executing resolvconf. Then eth0 comes up and tells resolvconf its nameserver(s) - resolvconf decides which to use, likely eth0 will be set a higher priority than usb0. Later eth0 goes down. Now resolvconf automatically restores the nameserver settings from usb0. (presuming it is still up) If usb0 went down already, but ppp0 over gprs came up in the meantime, nameservers for ppp0 go live. OK, so this resolvconf thing is inherited from debian and has been implented obviously without much thought to general functionality. I say this in the context of normal (non-debian) services functioning as expected when not massaged by resolvconf. I understand the intention, don't get me wrong, and it is indeed a nice idea. But when all people want to do is gain connectivity with their chosen method, this resolvconf facility seems to be more of a hinderence and is unlike a lot of linux distros. Shouldn't this, at least currently, be optional? If something as fundamental as _core_ network services are going to be overlayed with something like this, it should really be working first, rather thaan people editing files left and right without understanding why. This is just what I think, take it as you will. In the end I am the master of my device ;) I've actually just done a bit of research before posting and it _appears_ this was implemented with good intention, just without the required software support. It seems to be very much of debian origins and a little bit of overkill for managing the facilities on the freerunner, but that's just my opinion. If I was currently using usb0, eth0 and a tun/tap interface simultaneously, that all flapped or had dynamic dns requirments (sounds more like a router) it would make sense to me. I imagine the end goal is to consolidate gprs and wifi dns but currently no resolvconf is going to teach people how to get that going. When om2008 is mature and these kind of connections can be made easily, without much knowledge, this utility would be a godsend ... as it stands you currently need basic linux knowledge to understand why things don't work and then you need to know how to manipulate resolvconf. Maybe it's my BSD upbringing, thanks for the clarification however. :) Sarton IMHO the simplest effective solution should always head the list. In this instance I think that is to run dnscache or a similar service on the Freerunner itself, pointing somewhere like opendns.com's servers. (ok, maybe not simplest, though the local cache has various benefits. Pointing resolv.conf at opendns.com or wherever is simplest, assuming no network connection actually requires use of it's own DNS - corporate intranet wifi might, to reach 'private' records for example) If needed, newly-connected network connections that come equipped with new DNS servers (IE, wifi with DHCP) can insert/remove their DNS servers from the list used by dnscache, while resolv.conf permanently points at 127.0.0.1. This is what I've had running for a few weeks, but I hadn't yet attempted to get ifup/ifdown manipulating /etc/dnscache/root/servers/@. (which will essentially require a resolvconf-like manager ;) That all makes sense. Typically I've seen dnsmasq fulfill this function. My point was merely that the current solution is added complexity to a rather neat base filesystem. If this was a package I wouldn't have the same gripe. Using dnsmasq, pointing at localhost, including opendns and using helper scripts to insert and remove dns servers sounds less complex and less confusing, with the added benefit of caching and less modification to the base system. It also means not having to incorporate something that doesn't appear to have had the modifications needed _to_ incorporate it. I don't like the requirement that all the software modifying network settings needs to be resolvconf aware. If we had a generic central solution people could use whatever they want and not incur breakage ... Worst case, something like a resolv.conf pipe to a daemon that updates resolv.conf.auto for dnsmasq would be better. Something central! Looking at the way resolvconf works, it almost seems like we should be patching libc :S ...so we have a generic interface. Anyway ... I can feel fork coming on :P Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 21:50:51 Matthias Apitz wrote: How is that exactly supposed to work for the usb0 interface? this always has the static IP 192.168.0.202 (coded in /etc/network/interfaces); I've setup in my FreeBSD laptop a DHCP server to offer the IP addr of DNS with this config This is the problem. Nothing useful is in place to facilitate the added bloat (no offense intended). My current argument is that if something is being done, for something as necessary as networking, is should be either simple ... or working. Complex and non-functioning seems to be the alternative :S Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 21:22:54 [EMAIL PROTECTED] wrote: If resolvconf isn't doing what it should, then it is our responsibility as users to file enough bugs with enough pertinent info until it is corrected. If this were a package I'd agree. Sometime it's up to the users to show some concern. I don't think I want resolvconf working. Despite not being optimised for embedded, it's requirements seem to outweigh it's benefit in my view. To me it seems someone decided to not reinvent the wheel, which is fair enough in most cases. The freerunner currently has square wheels, so I don't see why a custom solution couldn't be developed. There's plenty of time after all, before we actually need a seemless facility like this. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 21:22:54 [EMAIL PROTECTED] wrote: I don't care which kind of connection management system is inside openmoko, as long as it works and is flexible to accommodate any networking scenario we may come up with (which pretty much narrows it down to resolvconf IMHO). You use debian don't you :P I hadn't even heard of resolvconf until I had no nameservers available :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is anyone from openmoko working on Bug #1841 (wsod)
On Friday 26 September 2008 09:53:56 Glen Ogilvie wrote: Hi, Is anyone from openmoko working on Bug #1841 (wsod)? This bug has been around for quite a long time and is critical and affecting many users. Can anyone actually suspend and resume reliability? Without being able to suspend and resume, using the gta02 as a phone is not really possible for myself anyway. I am more than happy to assist in any way I can, but I am not a kernel hacker, so can't make code changes at this level to fix it. I use testing and have had no problems for the last 3 weeks, maybe more. Actually there was one update which I think broke it, but testing updates daily so was fixed the next day. I don't recommend testing ... well ... because it's testing. But I can honestly say I've had a great experience. I don't modify the base system, I just wrap around it :) ... and testing has nearly always worked as a daily phone for me, without tweaks. It may be just a touch soft but nothing like qtopia ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.X] Flashing the kernel live
On Friday 26 September 2008 10:17:45 Kelvie Wong wrote: On Thursday, September 25, 2008 03:20:15 [EMAIL PROTECTED] wrote: I've not tried cat before but have used mtd-utils. Sorry, that's what I meant before. It's available at least in the testing repo but I've not tested on the freerunner. There seems to minor limitations on what some of the system tools are capable of, which is pretty typical of embedded systems. Maybe the packaged tools will help. I have mtd-utils-1.0.0_git-r8 installed on the FR: [EMAIL PROTECTED] ~] $ nandwrite /dev/mtd3 uImage.bin Input file is not page aligned Data was only partially written due to error : Success It took a split second, so I doubt its definition of Success coincides with my own... Ah ... looks like you may need to strip a header or something. We really need input from someone who generates the images. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FDOM] Booting from SD, unable to open an initial console
On Wednesday 24 September 2008 08:51:53 Neil Jerram wrote: Hi there, trying to boot from FDOM on my SD card... So I downloaded the latest rootfs.tar.gz and uImage.bin from http://compartida.net/openmoko/FDOM/, unpacked the rootfs.tar.gz into /media/mmcblk0p2, and copied the uImage.bin to /media/card. I was previously running Debian on the SD card, so I think my bootloader should already be correctly configured to boot this. But the boot comes to a halt with: VFS: Mounted root (ext2 filesystem). Freeing init memory: 128K Warning: unable to open an initial console. Kernel panic - not syncing: Attempted to kill init! Assuming the content of the archive is ok and you extracted preserving permissions (tar option 'p') , the only time I've seen a kernel load and the rootfs fail is with a dodgy SD card or one not properly supported. Is this the same SD card you were running debian from? I'd test by extracting an asu release set and see how you fair. Good luck. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.09] resolv.conf
On Thursday 25 September 2008 10:32:00 Joel Newkirk wrote: On Thu, 25 Sep 2008 02:01:24 +0300, Flyin_bbb8 [EMAIL PROTECTED] wrote: In 2008.8 resolvconf didn't populate it with the nameserver supplied by dhcp when the wifi interface was brought up. I don't know if this is still the case in 2008.9. hmm actually it always filled it in for me from DHCP when connectin to wifi using ifdown eth0 ifup eth0 both in 2008.8 and in 2008.9 Both correct, actually, as it DOES fill it in from DHCP (if used) connecting wifi with 'ifup eth0', but IIRC resolvconf isn't used to do it, it just overwrites resolv.conf. The idea behind resolvconf (the bin) is that IT manages changes to the resolv.conf file, doing things like removing eth0-related DNS nameservers when eth0 goes down, going back to usb0-related nameservers automatically. ifup should feed DNS info to resolvconf and let it manage. Right now, I think DNS and default route changes when interfaces change up/down need some attention from the 'just-works' dept. I still don't quite understand this confusion. udhcpc modifies /var/run/resolv.conf, as do I when needed. Any continually changing value/file should reside in volatile, in my opinion. /etc/resolv.conf has, for as long as I've been playing, symlinked to /var/run/resolv.conf. Except for the backend stuff not agreeing on this location, I have no issues, so long as udhcpc is used and an 'ip r d default' is issued prior to invocation. If the plan is that these values will be written to the filesystem, I'd say I'll be modifying mine to the contrary. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.X] Flashing the kernel live
On Wednesday 24 September 2008 19:05:45 Kelvie Wong wrote: I was just wondering, is there a way to flash the kernel live (i.e. with the software still running)? Is the boot partition (it's on the NAND Flash somewhere) something I can just mount and override a file? Or do I have to use dd? Or is there some trickery I can do with dfu-util? opkg upgrade manages this so I'd say you could ... using a tool like mtd or such, I really don't how, just that it does :) You obviously still have to reboot. I read somewhere that there should be the ability in linux down the track to actually do a 'live update' without a reboot. That'd be interesting and useful on a slow booting device :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.9 GPS
On Tuesday 23 September 2008 14:19:45 Chia-I Wu wrote: On Mon, Sep 22, 2008 at 09:25:39PM +0200, Alex Oberhauser wrote: What program do you use? If I have tried only with the location program I haven't received a fix. With the testprogram openmoko-gps-ui (I'm not sure with the name) and tangogps it works. When there is clear sky and a free sight after 1:30 or 2 minutes. When you start then location after you have received a fix with one of the two programs mentionend it finds your location. The Searching for your location message and Unable to locate a fix alert is merely informative. After they disappear, Locations (actually, diversity-daemon) continues listening to /dev/ttySAC1 silently and waiting for a fix. Could you help verify it? If it causes confusions, it should be changed. I agree, the message is confusing and gives the wrong impression. Something like 'Your position is not available at this time' would be more appropriate or maybe some kind of progress/status indicator to denote that it is attempting to retrieve information. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: df-util required minimum kernel version
On Tuesday 23 September 2008 14:03:27 Matthias Apitz wrote: El día Tuesday, September 23, 2008 a las 11:12:05AM +1000, Sarton O'Brien escribió: On Monday 22 September 2008 17:14:45 Matthias Apitz wrote: I'm not sure, is it a 32bit binary? My system is: yes, the above 'albatros' runs a normal SLES: [EMAIL PROTECTED]:~ cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (i586) VERSION = 9 I saw you were running i386, I actually meant the dfu-util binary but from you have presented it appears the kernel version is indeed a problem. I hadn't realised. anyway; I'll put a Knoppix 5.1.1 on an USB key to use this as alternative boot in my laptop (which runs FreeBSD, would be nice to port later dfu-util to FreeBSD :-)) I agree ... well ... let's just say *BSD :) ... I'm on the NetBSD side of the fence. Virtualbox should run on FreeBSD and I've heard their Xen implementation has matured quite a bit, using hvm should allow this to function if your laptop supports it. Xen's acpi functionality tends to be lacking though. Anyway, just a thought :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Nokia BL-5C replacement battery
On Tuesday 23 September 2008 15:34:51 Joel Newkirk wrote: On Tue, 23 Sep 2008 05:04:02 +0200, Joerg Reisenweber [EMAIL PROTECTED] wrote: If you bought a Nokia BL-5C for a spare battery, you might want to check this site: http://batteryreplacement.nokia.com/batteryreplacement/en/ cheers jOERG Wow. After reading this I went to check the BL-5c from my old Nokia 6600, and couldn't find it. I also have a BL-6c and a new BL-5c clone I ordered online a couple months ago. That last one was on the desktop charger, and was almost twice as thick in the middle as it should be... extremely pillow-shaped. Needless to say I relocated it to the middle of the concrete garage floor away from anything flammable. (6-ft radius :) Thanks for the heads up. Apparently whoever made this clone battery, it has the same or a similar flaw to the genuine Nokia ones made by Matsushita in 2006. (always assuming it's not just someone selling off the portion of the 46 million made which never reached consumers, which actually seems pretty believable) But the timing is just remarkable. Hehe, cool. Have you got some protective clothing and a 6.5 foot stick to poke it with? :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.9 GPS
On Tuesday 23 September 2008 03:33:59 Matthew Lane wrote: I can't get my GPS to get a fix, even outside. I'm using the latest 2008.9 distro from the wiki (as of 9/18/08). My Locations app shows a map, attempts to get a fix, and always tells me I can't get a fix in sunny weather! Is anyone else having this issue, or does anyone know of a solution? Running om2008-testing booting from single partion uSD (kernel on same partition, loading from /boot/uImage.bin symlink), I have no direct problems. Performance is a bit meh and it's glitchy. For locations to work I need to have turned on GPS and let it sit. This can take a while. If I use tangogps it picks up quicker and then switching to locations it identifies my position. Tangogps seems to require a bit of task switching to update the screen, you'll notice this when the map moves but none of the buttons function. This seems to be a graphical problem. The accuracy of the GPS seems to be ok. Tangogps reports the speed of my car almost to the kilometer :) ... which I didn't expect. Good luck! Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: df-util required minimum kernel version
On Monday 22 September 2008 17:14:45 Matthias Apitz wrote: [EMAIL PROTECTED]:~ uname -a Linux albatros 2.6.5-7.97-smp #1 SMP Fri Jul 2 14:21:59 UTC 2004 i686 i686 i386 GNU/Linux [EMAIL PROTECTED]:~ ./dfu-util -V FATAL: kernel too old Segmentation fault i.e. what is the minimum required kernel version for df-util? thx I'm not sure, is it a 32bit binary? My system is: # uname -a Linux trunks 2.6.26-ARCH #1 SMP PREEMPT Tue Sep 9 09:56:28 UTC 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ AuthenticAMD GNU/Linux And I have no issues. I am a bit bleeding edge though. It seems strange that you are running 2.6 and you get that error. # file dfu-util dfu-util: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.8, not stripped # ./dfu-util -V dfu-util - (C) 2007 by OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY dfu-util version 0.1+svn4160 Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[om.2008-testing] booting from single uSD partition
Hey all, Just a quick question, I have a uSD card with one ext2 partition where uboot sources the kernel via a /boot/uImage.bin symlink. So long as I: rm /etc/default/flashkernelopkg updateopkg upgrade All seems to be fine. Does anyone know of any problems with this scenario? I think any problems I'm seeing are more to do with testing but thought I'd see if anyone else is aware of something that might creep up on me. Maybe a wiki update is in order if there are no foreseeable problems. Thanks, Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wlan Issues after inactivity
On Monday 22 September 2008 23:36:41 vale wrote: Hello, i want to ask if there are other users having the same issues? Yes, wireless is flakey. Generally if I lose signal, then I need to reboot to reassociate. If i do an ifup eth0, then i start some updates or installs (apt-get install or opkg install ...) everything works fine. if some time passes by and after some minutes i install another thing or do wget something, then the downloads doesn't start. ping to the sites is still working. if i do an ifdown eth0 and ifup eth0, i can download again, experiencing after some minutes the same issue. In some cases, you're doing better than some of us. At least you can reconnect without a reboot :) is there a possible solution to this problem ? I don't think so, I've tried most of everything with varied success/failures. I think we're waiting for it to be fixed. Apparently some people need to do iwconfig eth0 power off to even get an association. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Should I update u-boot?
On Tuesday 16 September 2008 14:42:01 Vinc Duran wrote: I have a big favor to ask. Could someone direct me exactly to a correct version of u-boot that can charge a Freerunner with a dead battery? An exact URL with a file name would mean a lot to me. :-) Every u-boot I've tried has been able to charge a dead battery. It just takes like 6 hours before you can turn it on :) ... this is due to the hardware needing to be primed before allowing for proper charging. I don't know if this will ever change, software/firmware-wise. I only run testing ... everything ... so I'd only point you to daily for u- boot. If you want to test ... run it flat then try and charge over night. Keep a battery handy if you can ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mockup or what else?
On Tuesday 16 September 2008 14:06:32 Marco Trevisan (Treviño) wrote: However there's another question to Openmoko: another important developer left openmoko; unfortunately he's not the first of the list. Why this happens so often? In every message I've read about, it's always stated that there's no so much openness as it should be. This won't to be a flame, but we all know how people like Rasterman are important for the project. I can't really understand how we can throw those opportunities away... Rasterman already stated on this list that his efforts will be directed towards fso and we all know that fso will be merged with om2008 right? :) I installed milestone 3 the other day and was pleased to see illume, with the wrench :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] Copying the iPhone, or what not to do in phone UI design
On Wednesday 17 September 2008 01:33:23 Nishit Dave wrote: http://www.thebestpageintheuniverse.net/c.cgi?u=iphone Hah, nice :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO/ASU not registering on the Australian Vodafone GSM network
On Tuesday 16 September 2008 19:22:59 Dale Maggee wrote: I'm on the Aussie Vodafone network, using an old sim card I've had for *many* years (it's red and labelled sim^2 [i.e sim squared]), and FSO3 works fine for me, although sometimes it takes a little while to prompt for my PIN. as for ASU I can't be sure - the last time I tested it it registered, but again took a while, but It only lasted maybe 2 reboots before it got reverted back to 2007.2 again. I own a gta02v5. I'm on Vodafone too, newer card, Vodafone logo with 'if found call' blah blah. Never had a problem. I triboot qtopia (updated against testing), om2008 (updated against testing) and FSO milestone 3 (not sure where to update - tried testing :) and all do what I'd expect. I have a pin set. Sorry, not much I can offer. One thought comes to mind though, out of all the providers I've had, Vodafone seems to have the lowest signal strength. I used to think it was my ipaq but it is the same with the FR. Maybe 2007 is driving it harder? That's about all I can think of. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO/ASU not registering on the Australian Vodafone GSM network
On Wednesday 17 September 2008 12:48:05 W.Kenworthy wrote: On Wed, 2008-09-17 at 12:37 +1000, Sarton O'Brien wrote: On Tuesday 16 September 2008 19:22:59 Dale Maggee wrote: I'm on the Aussie Vodafone network, using an old sim card I've had for *many* years (it's red and labelled sim^2 [i.e sim squared]), and FSO3 works fine for me, although sometimes it takes a little while to prompt for my PIN. as for ASU I can't be sure - the last time I tested it it registered, but again took a while, but It only lasted maybe 2 reboots before it got reverted back to 2007.2 again. I own a gta02v5. I'm on Vodafone too, newer card, Vodafone logo with 'if found call' blah blah. Never had a problem. I triboot qtopia (updated against testing), om2008 (updated against testing) and FSO milestone 3 (not sure where to update - tried testing :) and all do what I'd expect. I have a pin set. Sorry, not much I can offer. One thought comes to mind though, out of all the providers I've had, Vodafone seems to have the lowest signal strength. I used to think it was my ipaq but it is the same with the FR. Maybe 2007 is driving it harder? That's about all I can think of. I set a pin but it only asked for it once(still no connection), and never again. I deleted 2007.2 so cant test it with that anymore, howver everything works as expected on my Treo. Hmmm, hence why I suggest the antenna power output/sensitivity. I'm sure you've thought of this ... but have you tried another sim? Have a friend on telstra, a coworker on optus? Even if the sim is fine it will help eliminate carrier signal strength. Oh and as we are all supposedly enforcing mailling list rules now, please don't top post. Well done on the subject btw ;) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO/ASU not registering on the Australian Vodafone GSM network
On Wednesday 17 September 2008 13:00:31 W.Kenworthy wrote: On Wed, 2008-09-17 at 12:37 +1000, Sarton O'Brien wrote: On Tuesday 16 September 2008 19:22:59 Dale Maggee wrote: I'm on the Aussie Vodafone network, using an old sim card I've had for *many* years (it's red and labelled sim^2 [i.e sim squared]), and FSO3 works fine for me, although sometimes it takes a little while to prompt for my PIN. as for ASU I can't be sure - the last time I tested it it registered, but again took a while, but It only lasted maybe 2 reboots before it got reverted back to 2007.2 again. I own a gta02v5. I'm on Vodafone too, newer card, Vodafone logo with 'if found call' blah blah. Never had a problem. I triboot qtopia (updated against testing), om2008 (updated against testing) and FSO milestone 3 (not sure where to update - tried testing :) and all do what I'd expect. I have a pin set. Sorry, not much I can offer. One thought comes to mind though, out of all the providers I've had, Vodafone seems to have the lowest signal strength. I used to think it was my ipaq but it is the same with the FR. Maybe 2007 is driving it harder? That's about all I can think of. Query - is there anything you do to get the pin dialog up? Have the dialler onscreen? - or just let it boot and it comes up automaticly? It coincides with starting X. Usually a /etc/init.d/xserver-nodm restart is enough (or qpe restart?). I'm not sure if it will reprompt if the pin has already been entered successfully however. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO/ASU not registering on the Australian Vodafone GSM network
On Wednesday 17 September 2008 13:56:26 W.Kenworthy wrote: As I stated initially, the sim works fine on 2007.2 - its only on FSO/FDOM/2008.8 where I am having the problem. I have tried another, few month old vodafone sim with the same results as my many years old one (under FDOM) You seemed to have missed my point completely, unless you can be sure that everything other than 2007 is driving the hardware exactly the same. I'd still recommend a provider other than vodafone for testing. Please dont bottom post unless willing to trim the mail - I waste such a lot of time scrolling its really frustrating - to the point I often never read bottom posters. It's not about your convenience as it is to be able to see the final email in an archive and derive the entire conversation. If you mean 'trim irrelevant information' than I will agree with you. Trying to enforce your own conventions to merely make a point won't fly. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Should I update u-boot?
On Tuesday 16 September 2008 08:56:20 Glen Ogilvie wrote: Hi, I am just wondering if the is any reason to update the u-boot on my freerunner from the factory default? I have not been able to find anything on the Wiki that says if this is actually would make any difference, so not sure if I should. u-boot is effectively your bios and therefore fwiu facilitates power management and the like. Certain features will benefit like suspend and booting from ext3. Seeing as you have your nor u-boot, it doesn't hurt to try out a newer one in nand, you can always revert. Hope that helps. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fast dfu-util for Mac?
On Tuesday 16 September 2008 06:27:59 Linus Gasser wrote: Hello all, another question: if I boot the jffs from FDOM (97MB), it takes nearly 15 minutes on my Mac with the dfu-util from http://www.dsitri.de/wiki.php?page=Openmoko%20Flasher I heard somebody complain about the same issue on Windows. Is there another solution than to install Linux on my Mac? Anybody? No, the windows issue was more like 1 hour :S That's a pretty typical time for flashing the rootfs. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fast dfu-util for Mac?
On Tuesday 16 September 2008 11:51:10 nickd wrote: Sarton look into running Linux inside VirtualBox. I believe it gives you direct access to all USB devices. Will cut 1hr down to a few minutes. Thanks Nick, I'm a big fan of virtualbox. I actually run archlinux and my flash time is ~10mins. My main point was that even on linux the time is still ~10 mins, where the original poster seemed to think that was a long time to wait on OSX. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Trolltech Qtopia (not X11) on 2008.8 base rootfs
On Thursday 11 September 2008 22:02:52 Cédric Berger wrote: there is already a qtopia update archive with qtopia stack files only. it comes with a little script to replace these files (/opt/Nokia/Qtopia/) (just beware if you have qtopia X11 apps installed, this script might delete them) I meant this snapshot http://www.qtopia.net/modules/mydownloads/visit.php?lid=82 Ok, I guess I can strip what I need from the update. Thanks :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Questions regarding shell/startup scripts
On Thursday 11 September 2008 08:48:24 SCarlson wrote: Hey guys -- Does anyone's resolv.conf get stomped on every time the machine is rebooted? I have been adding my nameservers by hand.. Just wondering if there is a good reason for this? Embedded systems typically have resolv.conf in volatile memory, due to the value changing regularly, with /etc/resolv.conf symlinked. udhcpc will use /var/run/resolv.conf. Unless you script something up to modify /var/run/resolv.conf, you may encounter problems when /etc/resolv.conf is not symlinked. I currently only use my own scripts to invoke wpa/udhcpc, nothing special and all works fine with no modifications. At this point I don't see any benefit in modifying startup scripts unless the changes are also made upstream and won't break when someone actually cleans up dns resolving amongst apps and services. Why static entries are being made in flash and why some apps aren't aware of a 'typical' scheme is a bit beyond me. It's not hard to manually overwrite /var/run/resolv.conf by hand or scripted and you have the added benefit of not modifying the base system. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Trolltech Qtopia (not X11) on 2008.8 base rootfs
On Tuesday 09 September 2008 02:27:05 Cédric Berger wrote: I would like to be able to install Trolltech's Qtopia on top of a fresh distro such as the latest testing 2008.8 base distro. This works really well. I'm booting from sd with om2008 testing, switching both applications via scripts from terminal. This now leaves me with the flash for installing debian. Lorn, what would be involved with upgrading only the qtopia component? Besides extracting from the jffs image (which requires I knock up a linux kernel, which I haven't had to do for years on archlinux - fantastic generic kernel ... any hints on doing this under *BSD? I'll look into it ...). Is there a possibility you will be releasing a rootfs archive? That'd rock. Thanks, Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem with usb cable: device descriptor read/64, error -110
On Thursday 04 September 2008 04:56:48 sledgeas wrote: Yhaw! It was enough today just to flash this: http://downloads.openmoko.org/releases/Om2008.8-update/Om2008.8-gta02-20080 903.uImage.bin and cdc_ether immediately gave out usb0 (before to even get the usb `new full speed USB device using uhci_h' line, I had to suspend and then wake up. Ah good. So, it was the kernel's problem (and for some reason the 20080826 did not work (bad image) on my FR DateCode: 20080725). Case close, into the new explorations! ;) and thanks for everyone's care, I'd hoped your image was corrupt ... for you sake :) Well done. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: specific absorption rate
On Tuesday 02 September 2008 15:51:00 Robin Paulson wrote: i was looking through planet earlier, when i saw this blogpost, which i'm sure others of you have read: http://blogs.thehumanjourney.net/finds/entry/20080901 i gather it's a report on the effects of emitted radiation when the freerunner is used near to a person's body. is there anyone here who understands these things. would it be possible to explain what this means, in a more condensed terms and understandable way? i'm not looking for 'The Idiot's Guide to Mobile Phone Radiation', or anything like that, but something a bit simpler to understand. I'm sure there are others here who would be interested to here this too I don't know the specifics now but I looked into it years ago. The end result was that any mobile with an internal antenna is more damaging to human cells than one with an external antenna. The theory being that the transmission is taking place further away from your body. The only use I can see for the findings is to compare existing antenna models to pick the lowest value. From memory the motorola startac, like 7 years after it's release, was still the lowest. Ericsson tended to have the higher values with nokia falling somewhere in between. The way I see it is, there is a required/acceptable amount of power required to reach the nearest tower. Anything lower would be unacceptable and the findings then fall on the antenna design. Currently nearly all phones omit an antenna and therefore increase the SAR (and decrease the signal quality). I admit, I've never understood why an antenna like the startac's han't been included in newer phones. It did retract after all. The alternative these days is to use a headset/ear piece (and probably leave the phone near other important parts of you body!). The overall effect is that nearly all current mobile phones have a similar SAR, as far as I can tell anyway (give or take, usually based on the design of the internal antenna). It's been a while so thing may have changed ... Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: specific absorption rate
On Tuesday 02 September 2008 17:56:26 Robin Paulson wrote: 2008/9/2 Sarton O'Brien [EMAIL PROTECTED]: The way I see it is, there is a required/acceptable amount of power required to reach the nearest tower. Anything lower would be unacceptable and the findings then fall on the antenna design. is the relationship as simple as: increase the antenna size, decrease the radiation? From what I understand, the SAR is determined under normal operation. If less of the transmission is occurring close to your body, then the SAR decreases. So I guess ... the answer is probably yes. could an external antenna help increase battery life also? If you were able to decrease the sensitivity then I'd say that's a possibility. is this something we can choose ourselves, or are there particular requirements we should be aware of? That I have no idea about and would depend on what I said above. Currently nearly all phones omit an antenna and therefore increase the SAR (and decrease the signal quality). I admit, I've never understood why an antenna like the startac's han't been included in newer phones. It did retract the public values compactness over safety? Since when has the human race as a whole been smart? We learn quickly compared to other species but way too slow for our own good. after all. The alternative these days is to use a headset/ear piece (and probably leave the phone near other important parts of you body!). someone suggested this was a bad idea, cos you're plugging the antenna straight into the side of your head, actually making things worse That assumes the ear piece is the antenna. Not always the case. In the case of the FR, I don't know if this is the case or not. The overall effect is that nearly all current mobile phones have a similar SAR, as far as I can tell anyway (give or take, usually based on the design of the internal antenna). It's been a while so thing may have changed ... To be honest, I gave up caring. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR won't boot without going into uboot menu first
On Wednesday 03 September 2008 05:13:17 Thorben Krueger wrote: My FreeRunner won't boot unless I hold down the AUX button while powering up and select boot manually from the menu. This problem started to appear when I had piped junk into all mtdblock devices on my FR. (I had misinterpreted one of the wiki pages about images (the instructions were intended for the host machine, not the FR itself)) So booting from NOR works but booting from NAND doesn't. Sounds like a uboot problem to me ... but I am guessing. Maybe try an older uboot image. What happens if you boot directly to NAND? If you don't know how, it is in the wiki somewhere. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem with usb cable: device descriptor read/64, error -110
On Wednesday 03 September 2008 01:35:50 sledgeas wrote: Hello, I am getting same error. I got my FR last week. I reflashed om2007 with 2008.8 using: Om2008.8-gta02-20080831.rootfs.jffs2 gta02v5_and_up-u-boot.bin testing-om-gta02-20080831.uImage.bin You're using a testing kernel. You can't ever expect the test kernel and stable userland to match. They _may_ match but it's up to you to find out the hard way :) Try flashing the correct kernel/uImage. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem with usb cable: device descriptor read/64, error -110
On Wednesday 03 September 2008 02:49:58 sledgeas wrote: I am having the same problem as Kevin once had, now. I have immed reflashed my FR's om2007 with 2008 and kernel: tried these: from openmoko2008 update site: Om2008.8-gta02-20080826.uImage.bin - this one says bad kernel image these combinations work, (but the usb error is still there, error -110): Om2008.8-gta02-20080831.rootfs.jffs2 testing-om-gta02-20080831.uImage.bin testing-om-gta02-20080902.uImage.bin gta02v5_and_up-u-boot.bin (Aug 26th) OK, so it looks like you've tried a few combinations. It's still really hard to tell if you have used the right combination though and where the images actually came from. You should be using images from here: http://downloads.openmoko.org/releases/Om2008.8-update/ And from nowhere else (at least until you have something working). If using those images doesn't work then it's sounding like some kinda hardware fault. Good luck! Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Preventing opkg upgrade from flashing the kernel partition
On Wednesday 03 September 2008 04:06:16 Mikael Berthe wrote: I'm afraid that upgrading the kernel on one of the SD card systems could flash the NAND kernel (and then the kernel wouldn't match the OM2007.2 modules). Of course there would be a few ways to recover from this situation, but if I can make sure it will not happen it's all the better... You could always give it a go and let us know :) I'd be interested. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM2008.8, sound not working after resume from suspend
On Tuesday 02 September 2008 17:03:30 Nishit Dave wrote: What I am after is a way to lock the screen with the aux button first, and allow it to blank automatically after 5,10,30 or 60 seconds. It should not light up without pressing the aux button again - in this way, you can keep it in your pocket without resorting to suspend and losing sound after resume. OK. Except for the requirement of not lighting up until unlocked, that is exactly how mine operates. I store mine in an old leather ipaq cover that sits flush and doesn't knock the screen when moving so I don't have the issue of it lighting from random taps. I can go a whole day without a charge (woohoo). Without knocking something up yourself, I doubt anything will facilitate what you are after as suspend is suppose to cover this scenario and I'd say that's where the focus currently is, unless someone core decides a permanently blanked screen while locked is useful. I don't know if there is a way to do this after recent updates, so I'll un-mothball the moko and try, and post my experience again. You'll have to manually hook something into the aux button to keep the screen blanked even when tapped as the feature will likely only have merit on an individual basis once suspend works. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problem with usb cable: device descriptor read/64, error -110
On Wednesday 03 September 2008 10:32:17 sledgeas wrote: Please, refer to this http://n2.nabble.com/Can-bad-NAND-blocks-cause-USB%27s-%22device-descriptor -read-64%2C-error--110%22---tp835094p835094.html for more full info. A guy in #openmoko suggested my flash blocks might be bad and fs not really dealing with them ok. - could this be causign the usb problem (or even 20080826 kernel's wrong image error for some reason) ? Well the next thing I was going to say was, I can imagine only a few scenarios: - Bad flash procedure - Bad image - Bad hardware If you are doing everything by the book and your images aren't corrupt, it does sound like your flash is fubar. You haven't showed any commands or output during your flashing procedures so it is still really hard to tell. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 update: Wrench doesn't appear even with illume-configinstalled
On Monday 01 September 2008 23:47:18 Carsten Haitzler wrote: someone else just did it and it works. (From: yves mahe [EMAIL PROTECTED] - Subject: Re: illume-config-illume on 2008.8-updates) There are two packages, illume-config and illume-config-illume in testing, from what I understand. The first one only enables the qwerty button. This problem doesn't occur using your image however :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Duped Messages (was Re: Please split this list!)
On Monday 01 September 2008 23:23:21 Joel Newkirk wrote: Rui Miguel Silva Seabra wrote: Since we're talking about the mailing lists, I still receive (randomly), three repeated mails, two repeated mails, etc... This mail from Vasco... I received it three times already! :) Rui On Mon, Sep 01, 2008 at 12:24:03PM +0100, [EMAIL PROTECTED] wrote: If you examine the email headers you can see that the 'received' header documenting where the mail server handling the list (sita.openmoko.org running exim 4.63) received the message from the sender's mailserver (IE, their ISP's mailserver) differs from one copy to the next - this means that either the sending server is failing to recognize that the message has been delivered and resends, possibly the receiving server is failing to send the acknowledgement of receipt at the end of the SMTP transaction (at least in a timely fashion), so the sending server automatically retries. Received: from relay1.ptmail.sapo.pt ([212.55.154.21] helo=sapo.pt) by sita.openmoko.org with smtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1Ka7yh-0002Ow-Ha for community@lists.openmoko.org; Mon, 01 Sep 2008 13:55:37 +0200 Received: from relay1.ptmail.sapo.pt ([212.55.154.21] helo=sapo.pt) by sita.openmoko.org with smtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1Ka7fK-0005dL-Pf for community@lists.openmoko.org; Mon, 01 Sep 2008 13:55:37 +0200 Received: from relay1.ptmail.sapo.pt ([212.55.154.21] helo=sapo.pt) by sita.openmoko.org with smtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1Ka7ZO-0003bU-8Q for community@lists.openmoko.org; Mon, 01 Sep 2008 13:55:21 +0200 Notice that the message ID differs between the three copies. This tells us that this is the point (when sapo.pt mailserver delivers to sita.openmoko.org mailserver) where the failure occurs. If it were the mailinglist server sending dupes, this header would be identical among all copies. Also, it doesn't depend on sending mailserver software, I've noted it happening with qmail as sender, exim, gmail.com, and others. (even mail.openmoko.org sometimes, such as Andy Green's reply to the '3G modem' thread) Based on past experience as admin of a cluster of mailservers that sometimes exceeded 1 million incoming SMTP connections per day, I suspect that either spam filtering or some testing for ML (IE, 'is this sender permitted to post?') takes place AFTER receiving the message but BEFORE telling the sending server that message was received, and is periodically taking longer than the sending server's SMTP timeout, so the sender gives up on the connection and tries again - meanwhile the exim server handling the ML eventually accepts the message. My suspicion is that the load on the (virtual?) server hosting the ML is getting to a level where processing messages sometimes takes longer than some sending servers are willing to wait. Properly, in such a situation, the sending server is supposed to resend, and the receiving server is supposed to discard the message it failed to fully receive before the connection was broken. Unfortunately my mailserver experience is with surgemail, qmail, sendmail, and some exchange (ick), but I've never worked with Exim, so I can't suggest anything specific to check in the server config. (When I've seen this caused by receiving mailserver it was most often qmail, and was caused by improperly configured/limited spawning that exceeded available RAM instead of deferring excess inbound connections - once dipping into swap, all bets are off regarding timely responses) Sounds like a decent theory. I've experienced abnormalities when pre- processing facilities (greylisting/virus scanning/spam filtering) are configured incorrectly or terminate abruptly or incorrectly. I imagine just looking at the logs around the time of duplication would give a fair indication as to where the issue is. Otherwise system load sounds reasonable, swap in anything time critical is not ideal. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Please split this list!
On Monday 01 September 2008 21:06:57 Thorben Krueger wrote: Please consider splitting this mailinglist into sublists, i.e. each handling its own distribution... All the best, Thorben PS: Yes I know how to handle filtering on the client side. My 2 cents. Qtopia contains FSO related components and vice versa. om2008 contains Qtopia components. Qtopia runs on a modified om2008. FSO will be merged into om2008. Now ... where was this split to be? In the end it looks like Qtopia/FSO/om2008 will be combined, or more to the point, unneeded separately. I can possibly see a need for a debian based mailling list. I think the community just needs to calm down a bit and focus. More importantly, be patient, as this will all pass when the people who are in this for the right reasons, stick around. People do need to be more specific with their details but that is partially a side effect of this new product being introduced in the state it is in. Some people have less than an idea of what's going. Anyone serious about making this list usable needs to take a firmer stance on what they reply to and how. Be firm, not mean ... and I'm sure it will all work out :) ... requiring at least the distro in the subject would be a good start. I admit the list is feeling more like general discussion rather than community discussion. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtopia update
Hi Lorn, On Tuesday 02 September 2008 10:30:14 Lorn Potter wrote: I have updated qtopia at qtopia.net Fixes include sms messages not retrieved after resume. Qtopia getting confused between two calls. Make default call volume down and mic up (only in flash update). Added echo fix. Enjoy! I think Qtopia is great but admittedly removed it after less than a day due to there being now browser available. I would really like to use Qtopia, can you suggest a method of obtaining a functional browser for Qtopia? If this is a trolltech obscurity thing then so be it, I'll happily stick with what I'm using but thought I'd ask first. Thanks :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing 20080901 first steps to 2008.09??
What ... only 5 duplicates? pfft :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtopia update
On Tuesday 02 September 2008 11:07:04 Lorn Potter wrote: Sarton O'Brien wrote: I would really like to use Qtopia, can you suggest a method of obtaining a functional browser for Qtopia? wait for 4.4 Awesome, thanks. If this is a trolltech obscurity thing then so be it, I'll happily stick with what I'm using but thought I'd ask first. No, it's a Nokia obscurity thing. Heh, that was what i was going to type first :) Thanks for the info. Greatly appreciated. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM2008.8, sound not working after resume from suspend
On Monday 01 September 2008 16:59:26 Nishit Dave wrote: On Mon, Sep 1, 2008 at 11:58 AM, [EMAIL PROTECTED] wrote: Nishit Dave wrote: Now here's the bottom line: OM should either resolve the suspend-resume-sound issue, or give us a way in which the screen can be both blanked and locked. The current design 'feature' that a screen-locked phone cannot be blanked is really, well, unfortunate. Install illume-config-illume from testing or instll rasters image and update to asu stable. Both options will mean you can access the power configuration and enable screen blanking and disable suspend. The suspend option will look to be enabled in settings but this is wrong. It's actually the screen blanking time. I've only tested the raster image. I know, I already have the spanner and power settings. What is needed is a way to blank and lock without suspending. Will illume-config-illume enable it? Errr ... isn't that what I said? I have suspend disabled and blanking set to 60 seconds. My FR never suspends and it blanks after 60 secs. This is the case when locked or not. If you indeed have the facilities I do, then you just aren't configuring it correctly. Or am I missing something? Is this not what you were after? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Duped Messages (OffTopic but important to lists.openmoko.org operations)
On Tuesday 02 September 2008 13:02:59 Joel Newkirk wrote: After that final period (a period by itself on a line ends an SMTP message transfer) it sits there thinking for 12-15 seconds in silence, then responds - slightly more delay that I'm used to in such tests, but not unusual, (particularly if filtering is performed at that stage, which would allow unacceptable emails to be rejected instead of having to bounce - better for spam control that way) and one test it took only 7.5 seconds. Then there was the test (same procedure, same entries, second test) where after the period-enter I waited 4 minutes with no '250 OK' response. Lacking that response code, the sending mailserver eventually presumes the communication to have failed, and queues the message for redelivery attempt. I finally killed my telnet session, and sure enough the message The results of your email commands came back to me from Mailman. ***HOWEVER: RFC-2821 specifies the timeout period while awaiting '250 OK' response is 10 minutes, so strictly speaking this is a misconfiguration or bug in the SENDING mailserver, NOT Exim 4.63 on sita.openmoko.org.*** Hmmm, those are erratic results. Unfortunately without knowing their setup, it could merely be one drone or two drones causing the problem as I have sent an email with no duplicates before. It could also be the load balancing itself . Who knows. Maybe there is no load balancing ... Hopefully you've discussed this enough for someone to look :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WIFI on FR
On Friday 29 August 2008 15:29:52 Sarton O'Brien wrote: It's likely to be the nameserver issue most people experience. For some reason the nameserver obtained via udhcpc is not written to the symlinked location of resolv.conf (/var/run/resolv.conf). The raster image works brilliantly and this doesn't seem to be a problem fyi. For anyone testing images, I've been through nearly all and the raster image updated using the official om2008 repos works very nicely. Good work rasterman! Greatly appreciated (sorry if I got any spelling wrong), Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WIFI on FR
On Friday 29 August 2008 17:01:36 Jean-Eric Cuendet wrote: The raster image works brilliantly and this doesn't seem to be a problem fyi. Is it Om2008.8 update from 25 august? Or is there some other image? Where? Download the raster image for gta02 here: http://download.enlightenment.org/misc/ It's a modified om2008 ... there's quite a bit of updating (opkg updateopkg upgrade) but the end result seems to work quite well and it's inline with the current stable development repos so ... yay :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 update
On Friday 29 August 2008 02:12:32 Michael Zanetti wrote: Hi Wifi browsing seems to work ok, though it appears to not support wpa yet. Works fine here. I just copied my Laptops wpa_supplicant.conf over and added the wpa-conf line to /etc/network/interfaces. ifup eth0 got me connected to my wpa encrypted network. I meant via the interface (hence 'browsing' rather than 'scanning'). Utilising wpa_supplicant and wireless tools works fine, as I'd expect form linux :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can you help the Openmoko booth at Software Freedom Day in Singapore on Sat. Sept. 20?
I'm no list maintainer but you probably shouldn't be replying to an existing thread. I know hitting reply is easier but it clutters the archives. Just so you know ... Sarton On Tuesday 26 August 2008 16:46:28 Chelsea Wei wrote: Openmoko is pleased to be invited for an open source day event on Software Freedom Day in Singapore. We will love to have some openmoko presence in Singapore; nevertheless, we are small understaffed team, so we will love if some of you could commit to helping us. Software Freedom Day in Singapore will be held at Singapore Management University Campus (School of information Systems) on Saturday September 20 from 10AM to 5PM. [http://www.softwarefreedomday.sg/] We will need approximately two volunteers for this event. For return, we will give away ONE debug board for each volunteer. If any of you is interested in helping us out, please let me know asap so I will be able to arrange for this event. Any help is extremely appreciated.. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WIFI on FR
On Friday 29 August 2008 15:01:21 Jean-Eric Cuendet wrote: Hi, I'm unable to make the wifi working on my FR Could someone explain how to do it? I have an open access point, with DHCP. My laptop connects and works well with it. I go to Settings, then choose WIFI, then click on it : it passes to ON Then, after some seconds, I see my WIFI ESSID. I click on it (is that what should do) and nothing happens... Are you obtaining a dhcp lease from your router? It's likely to be the nameserver issue most people experience. For some reason the nameserver obtained via udhcpc is not written to the symlinked location of resolv.conf (/var/run/resolv.conf). It's probably a good idea to ssh/terminal in and check iwconfig/ifconfig, make sure you have an IP and then modify the network scripts to add your nameserver to /var/run/resolv.conf Somebody on here suggested adding the nameserver to a location on flash, so it may be that the symlink for /etc/resolv.conf is overwritten by the networking scripts in which case the file will either be /etc/resolv.conf or /etc/networking/eth0 ... or something like that. This is off the top of my head. Stay tuned for a more comprehensive reply ... from someone else :) Ahh there it is ... a wiki link ... of course :) ... but I'll send this redundant information just in case ... this thread will be archived anyway and there may be information lacking on the wiki. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Getting rid of echo for callers.
On Friday 29 August 2008 15:20:53 Jean-Eric Cuendet wrote: This settings removes the echo for the other person completely, at least for my hardware. I didn't hear any buzz either on my final testcalls, could be luck. How did you change these settings? With alsamixer? Is there a GUI to change sound propertiers? (kmix like) Alsamixer is available. And just another question: what is gsmhandset.state file? It is the file that stores the state of the levels so you don't have to rejig every reboot :) You could definitely spend a bit more time on the wiki. Most of the basic questions are answered there. Just a suggestion. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problems booting
On Tuesday 26 August 2008 05:48:59 Gunnar AAstrand Grimnes wrote: After several weeks of waiting I've finally got my OpenMoko - it came with 2007.02 which I've opkg update'd. However, now it seems to have some trouble booting :( Most times I turn on it will simply freeze on the first flash-screen, booting into the nand or nord menus works, but they will both freeze after Starting kernel... removing power-supply+battery to turn off and trying again will usually make it boot after about 5 attempts. This happens regardless of the battery level. I've had a cursory glance over the mailinglist archives and of course googled, but not found anything. Is this a known problem? Or do I have some weird hardware error? I second what the others have said but to address your actual problem ... opkg updates the userland binaries and kernel modules, I'd say the most likely reason you're having problems is due to not updating your kernel. An updated uboot is still worthwhile however and _may_ also be part of the problem. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sold out ahh
On Monday 25 August 2008 17:00:00 Christoph Pulster wrote: Unfortunately that means people who live in a place that does not have a distributor - like Brazil - are SOL for like, forever, Some countries have rigid customs importing anything with GSM or GPS inside. That's the only problem. Most distributors ship worldwide. I think Openmoko community should be a worldwide one without exception. This is where I see my small part supporting the project: as distributor I ship to ANY country on earth. I'm in Australia and ordered mine from France with no dramas, though, I think customs stole my lanyard :( Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: stupid guy! thinks it's a train wreck!
On Monday 25 August 2008 17:36:31 Jelle De Loecker wrote: Stroller schreef: On 24 Aug 2008, at 20:00, Fredrik Wendt wrote: ... I tried to argue with this dude at http://www.vimeo.com/1366042 but pretty soon found out that it was all in vain ... Fuck! There are some retards in that thread. Stroller. That's the video Neowin featured on their frontpage after the release of the freerunner, isn't it? If you want to read more of those retarded comments you should visit it. I, however, stopped bothering. They're just trolls, what else can you say? I agree. I compare openmoko to the likes of openwrt the ability to do what you want with what you own. People like that have to warrant the money they spend on their iphone by railing on something they don't understand. When you and I are still hacking our mokos in 5 years time, and enjoying ourselves, that guy will be comparing linux gaming to his playstaion 5. Some people just haven't quite grasped when free = freedom. Just quietly grin with me. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
