RE: price politics for hardware updates post-phase-1/2
Jan wrote: Somewhere I read that FIC will likely sell the phase 2 to phase 1 owners for something like $150 (instead of $300 - yes, I know that phase 2 will cost more likely around $450 instead of $300). Hi Jan, When FIC announced the Phase 1 phones, they told us that instead of paying full-price for the phase 1 and then getting a discount on phase 2 (and having to put a system in place for tracking who gets the discounts) they simply sold the Phase 1 phones at a discount. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Troubles with mailing list
Hi List, I did not receive any message from the list for two days now, except some messages dated to July. (lol) If anyone receives my message, please be that kind, and answer it. Leave the list out, or CC it, so I can be sure I will receive it. Thanks in advance! Daniel ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mailing list management
On Thu, Aug 16, 2007 at 12:19:55AM +0100, thus spake Giles Jones: It's only affecting GMail messages. It's mostly Gmail messages that are being affected, but not entirely. A recent non-Gmail message that was duplicated was sent by mokoNinja [EMAIL PROTECTED] on 8/16 with: Subject: Re: Fingerscroll, foofone and more from people.openmoko.org! Message-id: [EMAIL PROTECTED] There have been others in the past too; I've noticed them from starband.net, cnlohr.com, and axialys.net. If you want more details, see the messages I've sent to this list such as Duplicate message troubleshooting on 7/24. Plus that RFC you quoted says recommended 30 minute retry but GMail is retrying every 8 minutes. The RFC says: In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery. (Source: http://www.faqs.org/rfcs/rfc2821.html section 4.5.4.1) When I look at the messages I've seen duplicated from Gmail, the first retry is usually after 8-10 minutes but then it backs off to about 20-30 minutes for a message or two, then 1 hour or longer for the rest. Maybe they're trying a more sophisticated and variable strategy. Marco ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: compile problem: OOM when compiling
Andreas Jellinghaus wrote: When compiling busybox (from memory need to check) cc1 started eating 900M and soon my system was no longer useable. Busybox is a defconfig type buildsystem. Let me guess... it hangs during task do_configure, right? If so, the please launch a build and kill it shortly after it goes into the loop. Pastebin the resulting S/temp/log.do_configure. Does anyone see this problem too? my host os is ubuntu 7.04 (feisty) on x86_64. Our buildhost is x86_64, I have to use a custom uname (returning i686) and BUILD_ARCH = i686 in local.conf to make it build openmoko-devel-image. -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
WiFi vs. speaker
C'mon, guys, do you _really_ need that big hole right through the case? Why don't you keep the stereo speakers and put the WiFi in that wasted space instead It's not only a matter of stereo vs. mono, either -- you'll be halving the amount of sound output and perceived quality. From what everybody has been saying, the current speaker setup is great, but I think we'll all be underwhelmed if you go to a single speaker. If you don't want to completely re-engineer the case, just add a little hole on the seam for wires and add an insert module that will fill the hole and house the Wi-Fi. And please, please, please don't jump on the multi-touch bandwagon just because Apple thinks it's cool. Every review I've seen says that it's difficult to use and not at all what it's cracked up to be. On the other hand, the current resistive touch screen on the Neo1973 will be usable in the winter with heavy gloves on, and the iPhone is absolutely not. If you can keep the resistive screen and add multi-touch, fine, but please make it optional, not mandatory to learn in order to use the thing. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: List mail not being delivered
On 7/11/07, Marco Barreno [EMAIL PROTECTED] wrote: I haven't received any email from these mailing lists since around 10:00 CEST on July 10. The web archives, however, show several messages since that time. Could there be a problem with the list server? I checked my list subscriptions, which seem to all be correct (mail enabled, digest off, etc.). I also tried signing up two other email accounts I have at a different domains, to see if it was a problem with my ISP, but the subscription confirmation emails never arrived. Is anyone getting list mail delivered? Is there a known problem with the list server? (Please send replies directly to me in addition to the mailing lists, for obvious reasons!) Thanks, Marco Heres what i'm seeing: Gmail says I have new mail as of 4:35pm MDT today, August 20. This was your message. Even though on your message it appears you sent it back in JULY. What the?! Along the same lines, I have been, as far as my last post a few days ago (and to my knowledge), getting email and replies in what I thought was a timely fashion..Perhaps not.. Id have to go back and check. Any other gmail users seing this? Im rather curious to know what is going on here! :) Mike ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: 3G SIMs?
Marco Barreno wrote: I have a question about SIM cards. If I have a 3G phone with its 3G SIM, will I be able to put that SIM in the Neo? My carrier is ATT in the US. Hi Marco, There have been some problems with ATT SIMs, some working, some not. See the Wiki here: http://wiki.openmoko.org/wiki/Carriers/ATT T-Mobile seems to have a better track record so far: http://wiki.openmoko.org/wiki/Carriers/TMobile - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Zombie processes
Hi I just compiled openmoko platform and emulated in qemu successfully. After finished executing the processes like gtkterm, it is becoming zombie. Why did not it is reaped by the parent process(matchbox??)? Can someone look into that? -- Thanks, Ashok ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
How about a slim Openmoko
Hi, Was just wondering if there are any thoughts floating around for a slim openmoko case design. Moto Razr sold like hot cakes only because of the design IMO, even, when it was slimmer on the features. Openness with a sleek design and it may be a killer. Dev ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM Radio
Yup, all that is true. If there is a market for it, someone might be willing to create some kind of receiver add on. But I'd don't think an FM receiver would be a bad idea. While many of us here turn to cds or music files for music, its still useful for news and information. New media formats have more or less replaced their predessors in the US, but in traveling, its not that way yet in many countries. In Indonesia, its easier to buy a cassette than a CD sometimes. On 8/18/07, Harald Welte [EMAIL PROTECTED] wrote: On Thu, Aug 16, 2007 at 01:45:12PM +0530, Ashok Kumar wrote: Any plans of adding it in future? not really. It's still somewhat of a strange conception to me why peopel would be interested in listening to hours and hours of crappy commercials interrupted with one or two (mostly crappy, too) songs in between, if they have a choice to listen to their collection of .ogg (and patent-encumbered .mp3) files. Also, I currently don't know what effects this has on things like FCC approval. Furthermore, some countries have some kind of levy-based scheme for funding the public broadcasting companies. This means that they would have to pay extra money for a device that has FM radio capabilities. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ 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
MokoMakefile now builds OM-2007.2 (Was: Balancing simplicity with complexity)
Sean Moss-Pultz wrote: The introduction of OM-2007.2 goes hand in hand with merging the OpenMoko OpenEmbedded overlay into the upstream repository org.openembedded.dev. We are now based directly on the upstream metadata found in OpenEmbedded and synchronized with the most recent developments. The MokoMakefile (http://wiki.openmoko.org/wiki/MokoMakefile) has been updated to build OM-2007.2 images. If you're starting from scratch, just follow the instructions on that wiki page. Pay careful attention to the host software package requirements for the OpenEmbedded build system. If you're migrating from a previous version of the MokoMakefile, then just type: make update-makefile ; make setup update openmoko-devel-image and after a number of hours and lots of building you should have new OM-2007.2 images built. By changing the OPENMOKO_GENERATION variable at the top of the Makefile you can alternately (but not concurrently) build both OM-2007.1 and OM-2007.2 images. The ability to build OM-2007.1 images will be removed after a couple of weeks (you will still be able to get it from the MokoMakefile svn repository if you really need it). There was a 24 hour period up to earlier today where there was a bug in the MokoMakefile. If you experience the following problem: Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f) then type make clobber-patches and rebuild to fix it. -- Rod ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Balancing simplicity with complexity
This is fantastic to read! Thank you, Sean -- and Thomas, of course. I must say, today I have had an interesting revelation of sorts... One thing that gives me a bit of trouble with the open source community is my ridiculous pickiness, and my wish to have everything smooth and unique. (Not to mention extensible and powerful). It is quite problematic since nothing ever seems to be appealing to my overly exacting standards. Today has been very interesting for me, as I have come to appreciate the work done by other people a lot more. Particularly that my favourite dream features are not the only ultimate features; that those subtle features which already exist are just as awesome as the subtle features I want to see. Maybe I just happen to have been suddenly exposed entirely to the most competently designed projects (combined with general happy vibes that are moving through the air), but for some reason I am finally able to relax under an acceptance that other people are Really Good at this stuff, and I can now resume work on my own niche without a worry about how the rest of it fits together. The air feels lighter. Bye, -Dylan McCall On 8/20/07, Sean Moss-Pultz [EMAIL PROTECTED] wrote: Dear Community! A top ten complaint that we have received is directed at our user interface. Many people feel like the current interface doesn't address their exact needs. The organization is not intuitive; the colors are not pleasing; there is no simple way to navigate exactly where you want, exactly when you want. All Hardware has limits. All FOSS runs on hardware. Our current interface (OM-2007) was drawn almost in it's entirety before our designers had seen a working Neo. We had to live without an embedded stylus in the current version. And we had to learn to adapt to the lip on the touch screen preventing us from using interface elements on the edge of the display -- prime real estate regions. It was tough. We pressed on, faithful in our belief that our community would overcome this limitation and begin exploring our new found oceans. Personally, I feel that one of the most important areas for this project is the development and exploration of the mobile user interface. The human-machine interface is the intersection of art and technology. Great interfaces blend the visual with the technical. They balance simplicity with complexity. Often times, I feel, really great new interfaces are not immediately intuitive. They are not instantly natural. In fact, I would even argue this can be detrimental to improving interface design. If an interface is to be superior it must be different. Therefore it can't be intuitive, that is, familiar. A better metric, perhaps, is the learning time it takes until the interface feel's natural and intuitive. Now that we have freed phones, everyone can contribute to an improved baseline interface. This is our collective challenge. Can we create something truly different? Can we lead this incredibly important field? Recently, emails have been pouring in, questioning the community's ability to make our user interface into something insanely great. While some doubted, others stepped up. Thomas Wood, of our extended team (AKA: OpenedHand), sent an email, entitled, OpenMoko Design Suggestions proposing -- in detail -- a redesigned interface concept that was totally finger-based, optimized for GTK+ at 285ppi and, might I add, very cool looking. We went back to the drawing board with OpenedHand -- lead by their vast experience with GTK+, Matchbox, and mobile user interfaces -- and redesigned an incredibly promising new interface. Today I'm extremely excited to announce that everyone can find this, right now, in our subversion repository, under the name OM-2007.2. We have already converted the following applications to the new framework: * Dialer, * Contacts, * Today, * Calculator, * Feedreader You can find an official snapshot here: http://buildhost.openmoko.org/snapshots/2007.08/ The remaining applications and wiki specifications will be converted as we approach phase 2. We have new style guidelines here: http://wiki.openmoko.org/wiki/GUI_Style_Guidelines Here's a list of the major changes we've made with respect to this new interface: 1) We redesigned the user interface to better fit both the hardware capability of the Neo and its physical form factor. 2) Performance was improved by streamlining the visual appearance, still keeping it attractive, but at the same time lessening the resource impact. The current design allows for further future performance improvements. 3) We vastly simplified the UI design and optimized the available screen real estate and physical characteristics. This included the following: * Improved the interface clarity by taking into account the screen's ultra-high DPI. * Allowed functions to be accessible using less accurate finger methods with requiring the
Re: T-Mobile [EMAIL PROTECTED]
On 8/20/07, Richard Boehme [EMAIL PROTECTED] wrote: Hmm is there any way to use the t-Mobile at home service when in WiFi range if I don't care about disconnecting when I go out of WiFi range? The Asterix route seems very complex. Thanks. Richard At this point its hard to say, however I would be willing to bet against it. My understanding of reading about the UMA standard, is that the UMA box your carrier lets you connect to your broadband connection effectively becomes a GSM base station, except that it uses tcp/ip networking to reach your carrier rather than private networks. It talks to the network as if it were simply another cell site that you are going in/out of. Therefore, the signaling involved would somehow need to take this into account. This could prove to be either very hard, or if something else is needed, perhaps a coordinated GSM/UMA response, it may be impossible with the exact hardware that was chosen. I'm also not certain that tmobile would allow you to subscribe to the service without having one of their preapproved phones. In the coming months, this among many other questions is sure to be answered definitively. Regards, Mike ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't flash smaller root-fs through dfu-util?
Dr. H. Nikolaus Schaller [EMAIL PROTECTED] [2007-08-19 21:23:08]: After unsuccessfully flashing different root-filesystems, I finally found this note: If you upload rootfs image that is smaller that previous one it won't work - you need to attach to bootloader, erase NAND and then upload your rootfs first: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs This *should* help but I am trying to understand why dfu-util can't do that? And what do I do if I have no serial interface? Does this mean I can't ever again flash a (smaller) rootfs? http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=419#c7 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Test
On 8/19/07, Daniel Spies [EMAIL PROTECTED] wrote: Just another test, did not receive anything since Saturday... Hi; I think the list is somehow backlogged... Today i got messages that are entirely new to my gmail account, but were dated between July 10 and August 10. I think the 'duplicate messages' issue that gmail et al have been having, which Harald mentioned was because spamassain was crashing, has caused an enormous backlog of messages stuck in some queue somewhere. This is my half-educated half-speculative guess. Mike ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots? (was: Balancing simplicity with complexity)
Sean Moss-Pultz wrote: We went back to the drawing board with OpenedHand -- lead by their vast experience with GTK+, Matchbox, and mobile user interfaces -- and redesigned an incredibly promising new interface. Sounds great! Are there screenshots available anywhere? /Erland ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Forum? (Was Re: Neo Sound and USB Questions)
Hm, in other words: everybody should subscribe (listen) to all other lists to post questions in the correct sublist... This is IMHO a very strong argument for a Forum system where you have to register only once, but can change between topics easily - even if new ones come up. Just my 2 cents, Nikolaus Am 19.08.2007 um 06:30 schrieb Harald Welte: please, this is a _community_ list! IF youre interested in hardware issues, please post to neo1973- hardware. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Balancing simplicity with complexity
Hi all, Having tried 2007.2 it's a great improvement and moves the phone a long way into looking like a product. I have some usability improvement suggestions that I will propose at some point. Will the old 2007 be phased out? it's never going to get finished given most people will want to develop 2007.2 and beyond. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Really hard to keep the device usable
Wim Delvaux [EMAIL PROTECTED] wrote : the dialout caused the device to go black again and now I cannot get it on regardless what I do with the power button. I wonder how I can reset the device ? Have you tried removing the battery for 10 seconds, then replacing the battery and charging the phone for 4 hours? --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Forum? (Was Re: Neo Sound and USB Questions)
Please don't bring up the forum debate again. We have heared all the arguments. We will not have a forum as long as I have any role in this project. All FOSS projects that I've ever been involved in 10+ years FOSS development use mailinglists, very efficiently, even lots of them. That's our official take on this. Re-iterating this over and over again will just make everyone involed more upset, and everyone else annoyed by an even worse signal/noise ratio. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
openmoko API Documentation
Hi, I have installed the openmoko on my machine and now i want to develop some Gtk based sample applications. I saw the sample gtk based hello world in the openmoko.org but i am not able to find the api documentation (e,g like MokoApplication, MokoWindow etc). Can anybody have any idea about this ? From where can i get this documentation. Regards, Chetan - Unlimited freedom, unlimited storage. Get it now___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How about a slim Openmoko design?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dev Anand wrote: Moto Razr was slim and even slimmer on features but caught on because of the design. If one could have the openness of openmoko and make it a slim elegant design it will be a killer. What say? FIC/OpenMoko has said they will progress with different models in the future, so I guess this is something they'll consider. I agree with voicing your opinion, I would also like to see something like that - and if we let them know people are interested, it's more likely it'll come down the pipeline. Perhaps not as much processing and features, but more of a phone, less of a PDA (actually, less of a Smartphone too?). In any case, I guess that'll be something we won't see until well beyond 2007. :-) Kindest regards, Jørgen P. Tjernø. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFGyt6CUMzc1WGo4zgRAltTAJjFWk9CFkkmr6c7MztvuRqEVEpqAJ91t/yk pC8ygfnSubI2qVpPh94DUA== =OTUJ -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mailing list management
Dear Hank, On Tue, Aug 21, 2007 at 06:50:03AM -0400, hank williams wrote: While I agree with your argument that no header is the standard for FOSS, this is not the case for the reply to issue, which you did not address. As I said earlier, the Apache groups (perhaps the largest FOSS umbrella) for example, and many (most?) others do not have the default reply-to going to the individual. Part of the reason for this is that it is bad user interface for the default behavior to be one that is used perhaps 1% of the time. Most people generally want to reply to group. Your default should be the most commonly accessed option which is why your design decision on this matter is not only not standard, but is, I believe, the minority design, even in the FOSS community. I'm not opposed to changing the reply-to for community, if you want that. In fact, I have now changed it. For all other lists I'm a bit less inclined to do it, but would be willing to change if there were many supporters of such a change. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Balancing simplicity with complexity
IMO the new UI is absolutely awesome. You guys really have found a way to make the small screen and high resolution work well with just finger touches. In my playing around with all the latest snapshots for the last week or two I have yet to need a stylus, aside from making a few terminal commands and adding contacts, and I have hands like a gorilla. Congrats OpenMoko team, keep up the good work! Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Moss-Pultz Sent: Monday, August 20, 2007 9:08 AM To: community@lists.openmoko.org; [EMAIL PROTECTED] Subject: Balancing simplicity with complexity Dear Community! A top ten complaint that we have received is directed at our user interface. Many people feel like the current interface doesn't address their exact needs. The organization is not intuitive; the colors are not pleasing; there is no simple way to navigate exactly where you want, exactly when you want. All Hardware has limits. All FOSS runs on hardware. Our current interface (OM-2007) was drawn almost in it's entirety before our designers had seen a working Neo. We had to live without an embedded stylus in the current version. And we had to learn to adapt to the lip on the touch screen preventing us from using interface elements on the edge of the display -- prime real estate regions. It was tough. We pressed on, faithful in our belief that our community would overcome this limitation and begin exploring our new found oceans. Personally, I feel that one of the most important areas for this project is the development and exploration of the mobile user interface. The human-machine interface is the intersection of art and technology. Great interfaces blend the visual with the technical. They balance simplicity with complexity. Often times, I feel, really great new interfaces are not immediately intuitive. They are not instantly natural. In fact, I would even argue this can be detrimental to improving interface design. If an interface is to be superior it must be different. Therefore it can't be intuitive, that is, familiar. A better metric, perhaps, is the learning time it takes until the interface feel's natural and intuitive. Now that we have freed phones, everyone can contribute to an improved baseline interface. This is our collective challenge. Can we create something truly different? Can we lead this incredibly important field? Recently, emails have been pouring in, questioning the community's ability to make our user interface into something insanely great. While some doubted, others stepped up. Thomas Wood, of our extended team (AKA: OpenedHand), sent an email, entitled, OpenMoko Design Suggestions proposing -- in detail -- a redesigned interface concept that was totally finger-based, optimized for GTK+ at 285ppi and, might I add, very cool looking. We went back to the drawing board with OpenedHand -- lead by their vast experience with GTK+, Matchbox, and mobile user interfaces -- and redesigned an incredibly promising new interface. Today I'm extremely excited to announce that everyone can find this, right now, in our subversion repository, under the name OM-2007.2. We have already converted the following applications to the new framework: * Dialer, * Contacts, * Today, * Calculator, * Feedreader You can find an official snapshot here: http://buildhost.openmoko.org/snapshots/2007.08/ The remaining applications and wiki specifications will be converted as we approach phase 2. We have new style guidelines here: http://wiki.openmoko.org/wiki/GUI_Style_Guidelines Here's a list of the major changes we've made with respect to this new interface: 1) We redesigned the user interface to better fit both the hardware capability of the Neo and its physical form factor. 2) Performance was improved by streamlining the visual appearance, still keeping it attractive, but at the same time lessening the resource impact. The current design allows for further future performance improvements. 3) We vastly simplified the UI design and optimized the available screen real estate and physical characteristics. This included the following: * Improved the interface clarity by taking into account the screen's ultra-high DPI. * Allowed functions to be accessible using less accurate finger methods with requiring the stylus. * Placed common functions on easy access prominent buttons and increased the button target areas. * Reduced the number of objects on screen at once by splitting applications into tabs and redesigned the application layout. * Added more natural interaction methods, such as finger scrolling. * Removed some unnecessary elements such as the footer. Improved usage and accessibility of existing ones. 3) Application management and navigation is now improved by with a completely rewritten today app and by using the Neo's hardware keys. 4) This is now an interface that uses the
Re: Bug 256, gsmd sudden death and making phone calls
I'm seeing this, as well. gsmd dies after 5 minutes. From the log: -- Mon Aug 20 01:04:06 2007 1 atcmd.c:210:ml_parse() buf=`%CSQ: 1 '(8) Mon Aug 20 01:04:06 2007 1 atcmd.c:372:ml_parse() Appending buf to mlbuf Mon Aug 20 01:09:06 2007 1 gsmd.c:124:alive_interval_tmr_cb() interval expired, starting next alive inquiry Mon Aug 20 01:09:06 2007 1 atcmd.c:545:atcmd_submit() submitting command `AT' Mon Aug 20 01:09:36 2007 1 gsmd.c:79:alive_tmr_cb() gsmd_alive timer expired Mon Aug 20 01:09:36 2007 8 gsmd.c:82:alive_tmr_cb() modem dead! gsmd - (C) 2006-2007 by OpenMoko, Inc. and contributors This program is FREE SOFTWARE under the terms of GNU GPL [EMAIL PROTECTED]:~$ ps | grep gsm [EMAIL PROTECTED]:~$ -- On 8/17/07, Shawn Rutledge [EMAIL PROTECTED] wrote: I can also reproduce bug 705, and I found the log in /tmp/gsm.log so I posted it on bugzilla. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Aditya (http://aditya.sublucid.com/) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: FM Radio
2007/8/19, Harald Welte [EMAIL PROTECTED]: On Thu, Aug 16, 2007 at 01:45:12PM +0530, Ashok Kumar wrote: not really. It's still somewhat of a strange conception to me why peopel would be interested in listening to hours and hours of crappy commercials interrupted with one or two (mostly crappy, too) songs in between, if they have a choice to listen to their collection of .ogg (and patent-encumbered .mp3) files. Also, I currently don't know what effects this has on things like FCC approval. Furthermore, some countries have some kind of levy-based scheme for funding the public broadcasting companies. This means that they would have to pay extra money for a device that has FM radio capabilities. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ I'm not in agreemen with how you say about the FM... So no radio for Neo? not even in future versions? I am one that think that it's a FM radio is essential in a modern device, like the camera. This is not a good news for me... :( ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Forum? (Was Re: Neo Sound and USB Questions)
Am 21.08.2007 um 12:46 schrieb Harald Welte: On Tue, Aug 21, 2007 at 11:19:57AM +0200, Dr. H. Nikolaus Schaller wrote: Harald, please calm down. I know from your blog how upset you are from setting up the new office location, networks and servers during Taifun time. in fact that was the most fun part. But just one question to answer for yourself: do you want to have community involvement or not? I am from the community ;) And not in my 10+ years of FOSS community It didn't look like that... development have I seen any project that had problems with properly using mailinglists. By deciding not to have a forum, you will loose some participants. And those who remain will have no problems. So, this argument is not a proof... Forums are for people who don't understand the technology of properly dealing with e-mails. Of what use is something that's only available Well, I don't know how old you are but I did send my first e-mails approx. 1984 and wrote my first UNIX programs at that time. Nevertheless I would prefer a forum. It is so easy to wipe away needs and requests from others by saying they simply don't understand properly how to use it :-) What would you do if you go into a shop where you want to buy a red t- shirt and the sales agent says that red is out and t-shirts are not good at all and that all those who want to buy a t-shirt simply don't understand why polo shirts are so much better? online? Of no use at all. Try keeping a local copy of a forum on your I have never had a problem with not being online all the time. laptop. Why should openmoko be any different? For which purpose should I keep ***all*** these mails archived? We will most likely have a forum for _end users_ at a time where we want to address end users. But not for developers, sorry. That might be an unwise decision - but you are the decision taker :-) Now as your network appears to work again, please focus on solving kernel, uboot, etc. issues that we as the dumb users can't solve ourselves. I am for example still fighting the issue with short and long rootfs flashing and NAND erasing, that leaves an inoperable OpenMoko device If you consider yourself a dumb user, then you probably are not the kind of developer crowd that we are addressing at this moment :( Looks a little like Freedom and Openness has limits? Look - I have a device now for 2 weeks. I have 20 years experience in software development and a certain goal to achieve with the OpenMoko. So, how should I know everything the core team knows that works on the device for now 10 months? Compared to you, I am of course a dumb user who has to learn a lot of aspects of the OpenMoko system. Especially the flashing process. But that is IMHO no argument to criticise my requests and needs. But I do not want to open a new fundamentalistic discussion. Nikolaus ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Is GTA2 UMA/GAN capable
Will the GTA2 be UMA/GAN capable? If not, does anyone know if FIC has any plans for a UMA/GAN capable OpenMoko phone? Thanks. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Forum? (Was Re: Neo Sound and USB Questions)
Am 21.08.2007 um 10:39 schrieb Harald Welte: Please don't bring up the forum debate again. We have heared all the arguments. We will not have a forum as long as I have any role in this project. All FOSS projects that I've ever been involved in 10+ years FOSS development use mailinglists, very efficiently, even lots of them. That's our official take on this. Re-iterating this over and over again will just make everyone involed more upset, and everyone else annoyed by an even worse signal/noise ratio. Harald, please calm down. I know from your blog how upset you are from setting up the new office location, networks and servers during Taifun time. But just one question to answer for yourself: do you want to have community involvement or not? Now as your network appears to work again, please focus on solving kernel, uboot, etc. issues that we as the dumb users can't solve ourselves. I am for example still fighting the issue with short and long rootfs flashing and NAND erasing, that leaves an inoperable OpenMoko device (Bug # 719). Maybe, it is not a software issue at all but just a documentation on what to do differently? I simply got stuck with my knowledge. Best regards, Nikolaus ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mailing list management
Harald, While I agree with your argument that no header is the standard for FOSS, this is not the case for the reply to issue, which you did not address. As I said earlier, the Apache groups (perhaps the largest FOSS umbrella) for example, and many (most?) others do not have the default reply-to going to the individual. Part of the reason for this is that it is bad user interface for the default behavior to be one that is used perhaps 1% of the time. Most people generally want to reply to group. Your default should be the most commonly accessed option which is why your design decision on this matter is not only not standard, but is, I believe, the minority design, even in the FOSS community. Regards, Hank On 8/19/07, Harald Welte [EMAIL PROTECTED] wrote: Hi! For the various reasons cited in the many mails on this subject, there is a general concensus in the FOSS community and among maybe the hacking community in general _not_ to add subject prefixes. Filtering can be done on List-ID header (or with other commonly-used list software on Mailing-List or even the Sender-header) The vast majority of all FOSS-related mailing lists that I've ever seen follow this policy. We see no reason why we should deviate from that. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ 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: Can't flash smaller root-fs through dfu-util?
Dr. H. Nikolaus Schaller wrote: After unsuccessfully flashing different root-filesystems, I finally found this note: If you upload rootfs image that is smaller that previous one it won't work - you need to attach to bootloader, erase NAND and then upload your rootfs first: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs This *should* help but I am trying to understand why dfu-util can't do that? And what do I do if I have no serial interface? Does this mean I can't ever again flash a (smaller) rootfs? I have no info on the first question, but about the serial interface. The commands above actually run over USB. Simply boot the Neo into uBoot (hold the Aux button while powering on) and select the option to use the console over USB (Move selection using Aux, invoke the selection by pressing power). Then plug in the USB cable and run the cu command. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How about a slim Openmoko design?
On 8/18/07, Dev Anand [EMAIL PROTECTED] wrote: Moto Razr was slim and even slimmer on features but caught on because of the design. If one could have the openness of openmoko and make it a slim elegant design it will be a killer. What say? I like the idea of going slim for future devices, the problem is, it makes it really hard for the hardware hackers to go in and change anything, and still have it fit in the package. Future devices that are targeted at the mass market would probably be ok though -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPL projects from Nokia
On 21 Aug 2007, at 18:50, Giles Jones wrote: Hi all, Anyone taken a look at these projects? thought there may be things of use here. http://opensource.nokia.com/projects/index.html Just thought, will be Symbian based stuff, doh. I guess some of the bluetooth protocol stuff might port over. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't flash smaller root-fs through dfu-util?
Am 21.08.2007 um 17:13 schrieb andy selby: If you upload rootfs image that is smaller that previous one it won't work - you need to attach to bootloader, erase NAND and then upload your rootfs first: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs This *should* help but I am trying to understand why dfu-util can't do that? And what do I do if I have no serial interface? Does this mean I can't ever again flash a (smaller) rootfs? Just type screen /dev/ttyACM0 into any pc while the device is in u-boot mode attached by a usb But not on a Mac... cable, that will give you the GTA01Bv3 prompt ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM Radio
Harald Welte [EMAIL PROTECTED] writes: Any plans of adding it in future? not really. It's still somewhat of a strange conception to me why peopel would be interested in listening to hours and hours of crappy commercials interrupted with one or two (mostly crappy, too) songs in between, if they have a choice to listen to their collection of .ogg (and patent-encumbered .mp3) files. For myself, I use the FM radio on my MP3 player to listen to news and public affairs programming while exercising in the gym. The anger I feel when I hear about what's been happening in the last 24 hours usually distracts me far better than music does. Furthermore, some countries have some kind of levy-based scheme for funding the public broadcasting companies. This means that they would have to pay extra money for a device that has FM radio capabilities. Some companies that sell MP3 players get around this by turning off FM capability when the device is shipped to such a country. Ugly, but I imagine it works for them. Perry ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPL projects from Nokia
Hi all, Anyone taken a look at these projects? thought there may be things of use here. http://opensource.nokia.com/projects/index.html ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't flash smaller root-fs through dfu-util?
Am 21.08.2007 um 19:23 schrieb John Seghers: Dr. H. Nikolaus Schaller wrote: After unsuccessfully flashing different root-filesystems, I finally found this note: If you upload rootfs image that is smaller that previous one it won't work - you need to attach to bootloader, erase NAND and then upload your rootfs first: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs This *should* help but I am trying to understand why dfu-util can't do that? And what do I do if I have no serial interface? Does this mean I can't ever again flash a (smaller) rootfs? I have no info on the first question, but about the serial interface. The commands above actually run over USB. Simply boot the Neo into uBoot (hold the Aux button while powering on) and select the option to use the console over USB (Move selection using Aux, invoke the selection by pressing power). Then plug in the USB cable and run the cu command. Many thanks for your suggestions, but MacOS X has no cu command :-( And, I want to automate this all with dfu-util. BTW: the bug tracker (bugs #419, #719, #726) says it has been solved by a newer version of uboot - but to my experience it is not completely solved even by an uboot compiled 19th August. It looks like that contrary to the warnings on http:// wiki.openmoko.org/wiki/Flashing_openmoko it is NOT optional. We all should flash a newer uboot first. Nikolaus ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: USB host
On Tue, Aug 21, 2007 at 10:48:19AM -0500, William Voorhees wrote: For GTA02 we will most likely supply power to the USB in host mode! Awesome, is this news or did I just find out? It is intentionally leaked but not yet finally confirmed and officially announced and confirmed information. Being able to do that is one of the few sources of joy that I still have ;) -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Balancing simplicity with complexity
mostly to rod... how soon until mokomakefile is updated? On 8/20/07, Sean Moss-Pultz [EMAIL PROTECTED] wrote: Dear Community! A top ten complaint that we have received is directed at our user interface. Many people feel like the current interface doesn't address their exact needs. The organization is not intuitive; the colors are not pleasing; there is no simple way to navigate exactly where you want, exactly when you want. All Hardware has limits. All FOSS runs on hardware. Our current interface (OM-2007) was drawn almost in it's entirety before our designers had seen a working Neo. We had to live without an embedded stylus in the current version. And we had to learn to adapt to the lip on the touch screen preventing us from using interface elements on the edge of the display -- prime real estate regions. It was tough. We pressed on, faithful in our belief that our community would overcome this limitation and begin exploring our new found oceans. Personally, I feel that one of the most important areas for this project is the development and exploration of the mobile user interface. The human-machine interface is the intersection of art and technology. Great interfaces blend the visual with the technical. They balance simplicity with complexity. Often times, I feel, really great new interfaces are not immediately intuitive. They are not instantly natural. In fact, I would even argue this can be detrimental to improving interface design. If an interface is to be superior it must be different. Therefore it can't be intuitive, that is, familiar. A better metric, perhaps, is the learning time it takes until the interface feel's natural and intuitive. Now that we have freed phones, everyone can contribute to an improved baseline interface. This is our collective challenge. Can we create something truly different? Can we lead this incredibly important field? Recently, emails have been pouring in, questioning the community's ability to make our user interface into something insanely great. While some doubted, others stepped up. Thomas Wood, of our extended team (AKA: OpenedHand), sent an email, entitled, OpenMoko Design Suggestions proposing -- in detail -- a redesigned interface concept that was totally finger-based, optimized for GTK+ at 285ppi and, might I add, very cool looking. We went back to the drawing board with OpenedHand -- lead by their vast experience with GTK+, Matchbox, and mobile user interfaces -- and redesigned an incredibly promising new interface. Today I'm extremely excited to announce that everyone can find this, right now, in our subversion repository, under the name OM-2007.2. We have already converted the following applications to the new framework: * Dialer, * Contacts, * Today, * Calculator, * Feedreader You can find an official snapshot here: http://buildhost.openmoko.org/snapshots/2007.08/ The remaining applications and wiki specifications will be converted as we approach phase 2. We have new style guidelines here: http://wiki.openmoko.org/wiki/GUI_Style_Guidelines Here's a list of the major changes we've made with respect to this new interface: 1) We redesigned the user interface to better fit both the hardware capability of the Neo and its physical form factor. 2) Performance was improved by streamlining the visual appearance, still keeping it attractive, but at the same time lessening the resource impact. The current design allows for further future performance improvements. 3) We vastly simplified the UI design and optimized the available screen real estate and physical characteristics. This included the following: * Improved the interface clarity by taking into account the screen's ultra-high DPI. * Allowed functions to be accessible using less accurate finger methods with requiring the stylus. * Placed common functions on easy access prominent buttons and increased the button target areas. * Reduced the number of objects on screen at once by splitting applications into tabs and redesigned the application layout. * Added more natural interaction methods, such as finger scrolling. * Removed some unnecessary elements such as the footer. Improved usage and accessibility of existing ones. 3) Application management and navigation is now improved by with a completely rewritten today app and by using the Neo's hardware keys. 4) This is now an interface that uses the strengths of our toolkit so that we can keep the extra framework and developer learning curve to a minimum. Please keep in mind that this new interface is still, very much, a work in progress. This is the earliest possible stage than we can release something with enough of a framework for you all to start exploring. It's a huge advancement in balancing simplicity with it's digital antagonist -- complexity. Also, thanks to Jon Phillips help, we've finally
Re: FM Radio
Personally, I would find a FM radio on a phone to be a welcome addition. I use the radio to not only to listen to music, but also the listen to the news and other broadcasted information. I must admit that stations on the FM band are definitely more incline to be your stereotypical Top40 radio stations. I guess there is always the option of mokocasting (aka podcasting) On 8/19/07, Harald Welte [EMAIL PROTECTED] wrote: On Thu, Aug 16, 2007 at 01:45:12PM +0530, Ashok Kumar wrote: Any plans of adding it in future? not really. It's still somewhat of a strange conception to me why peopel would be interested in listening to hours and hours of crappy commercials interrupted with one or two (mostly crappy, too) songs in between, if they have a choice to listen to their collection of .ogg (and patent-encumbered .mp3) files. Also, I currently don't know what effects this has on things like FCC approval. Furthermore, some countries have some kind of levy-based scheme for funding the public broadcasting companies. This means that they would have to pay extra money for a device that has FM radio capabilities. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ 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
Bricked Neo
I ran a nand erase when I was a bit tired and have killed my phone. Anyone in Sydney with a debug board that I can use to resurrect it? Alternately, does anyone know if is it possible to buy the debug board separately to the Neo? Cheers, Mark C. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't flash smaller root-fs through dfu-util?
If you upload rootfs image that is smaller that previous one it won't work - you need to attach to bootloader, erase NAND and then upload your rootfs first: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs This *should* help but I am trying to understand why dfu-util can't do that? And what do I do if I have no serial interface? Does this mean I can't ever again flash a (smaller) rootfs? Just type screen /dev/ttyACM0 into any pc while the device is in u-boot mode attached by a usb cable, that will give you the GTA01Bv3 prompt ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 status updates please
Sean Moss-Pultz schrieb: On 07/31/2007 Sven Neuhaus wrote: Hello Openmoko folks, please keep us in the loop regarding the GTA02 development. How is it progressing? Do you have pictures of the inside of the prototypes already? Is it still on track for the October release date? The last update on GTA02 was more than a month ago. I'll ping mokoninja. Gives him a day or so... Any news on that, or have I just missed the mail? -- Sebastian Latza ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: avoid auto power-off in u-boot mode
On 8/22/07, Javi Roman [EMAIL PROTECTED] wrote: The entry http://wiki.openmoko.org/wiki/Flashing_openmoko#Preparing_the_device_for_DFU_mode warns us about some devices turns off after a period of inactivity while on the u-boot menu. I am not really sure if this issue is hardware related, because the same behavior happens when we use QEMU to go into u-boot: If you log into u-boot by means of telnet localhost 1200, the system power-off passed a few seconds, therefore is difficult to work under these conditions. Is it possible to avoid this nuisance? Regards, -Javi Answer my own question: Setting the environment variable boot_menu_timeout = number_of_seconds solves the problem. GTA01Bv4 # setenv boot_menu_timeout 1 -Javi ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: compile problem: OOM when compiling
Dnia poniedziałek, 20 sierpnia 2007, Michael 'Mickey' Lauer napisał: Andreas Jellinghaus wrote: When compiling busybox (from memory need to check) cc1 started eating 900M and soon my system was no longer useable. Busybox is a defconfig type buildsystem. Let me guess... it hangs during task do_configure, right? No - it is not that rather. We did setup busybox build to get smallest possible binaries and this make compiler to eat lot of memory. Does anyone see this problem too? my host os is ubuntu 7.04 (feisty) on x86_64. Our buildhost is x86_64, I have to use a custom uname (returning i686) and BUILD_ARCH = i686 in local.conf to make it build openmoko-devel-image. Mickeyl - you are cheater when it comes to 64bit. From my experience only Python has problems if build machine is 64bit and build for 32bit. -- JID: hrw-jabber.org OpenEmbedded developer/consultant Real programmers don't document. If it was hard to write, it should be hard to understand. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Troubles with mailing list
The message is received. It arrived in a batch of about 15 other emails too all at the same time (6:29 est) Simon On 8/20/07, Daniel Spies [EMAIL PROTECTED] wrote: Hi List, I did not receive any message from the list for two days now, except some messages dated to July. (lol) If anyone receives my message, please be that kind, and answer it. Leave the list out, or CC it, so I can be sure I will receive it. Thanks in advance! Daniel ___ 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: Test
The very same thing for me! Everything is very (!) slow and buggy... Is this some mailman bug, or is there something else broken? I tried to subscribe with another e-mail address. This did not work, too... Well, someone could try this one more time, just try to get a confirmation mail, I guess you´ll wait for ages... Daniel Original-Nachricht Datum: Mon, 20 Aug 2007 23:18:06 -0600 Von: Mike Hodson [EMAIL PROTECTED] An: Daniel Spies [EMAIL PROTECTED], community@lists.openmoko.org Betreff: Re: Test On 8/19/07, Daniel Spies [EMAIL PROTECTED] wrote: Just another test, did not receive anything since Saturday... Hi; I think the list is somehow backlogged... Today i got messages that are entirely new to my gmail account, but were dated between July 10 and August 10. I think the 'duplicate messages' issue that gmail et al have been having, which Harald mentioned was because spamassain was crashing, has caused an enormous backlog of messages stuck in some queue somewhere. This is my half-educated half-speculative guess. Mike ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WiFi vs. speaker
Mark Haury [EMAIL PROTECTED] wrote : C'mon, guys, do you _really_ need that big hole right through the case? Why don't you keep the stereo speakers and put the WiFi in that wasted space instead The GSM antenna is next to the hole, not the best place for a wifi module. I do agree with the comment about stereo, it is one feature a lot of phones lack and there's a few that have stereo which makes ringtone playback clearer. If you're clever you can make ringtones where the bass is in the left and the rest of the signal in the right. Should be clearer with some music. You won't see any case changes as it has been stated previously that changing the tooling would be too expensive (this is a new project and it needs to grow gradually). My comments on the Neo1973 hardware are below, I like this phone and want it to succeed, but at the same time being critical makes something better. If you aren't critical about a product before it gets to the press then you probably care more about money than success. I don't really want to start off flamewars or have some of these design decisions explained to me as I don't think many of them can be explained (other than carelessness or for form factor reasons). Please just take the points on board when designing future hardware. Likes: It's light for its size. I like the rubberised surface, hard wearing. VGA screen is superb. No creaks or rattles. Open source :) Generous accessories for the price. Seemingly decent headphones. Dislikes: Back cover design is terrible and will easily break, especially given how tricky it is to remove. Port layout seemingly done at random, poor layout. USB/power connector better at bottom of device. Battery removal could be easier. Memory card under the SIM card (why? there's seemingly loads of space). 2.5mm audio jack (use 3.5mm like Nokia N95 to get mp3 marketshare) Power button location (location towards top is better, mine's also a bit sticky/spongey). Aux button looks like IR port (does it have any use outside of the bootloader?) GSM speed Battery it at top of the phone unlike pretty much every other phone. GSM antenna is at bottom of phone, should be at top of phone. No dedicated volume up or down (important during a call when the screen backlight has switched off). Fiddly SIM card holder. Earpiece hole, the ear piece foam is visible? (looks like black fluff). --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko Flasher
OpenMoko Flasher 1.3 (for MacOS X) is now available: http:// www.dsitri.de/wiki.php?page=OpenMoko%20Flasher Am 21.08.2007 um 09:35 schrieb Dr. H. Nikolaus Schaller: Ah, I see. I will add a feature that one can change the list of repositories in the Preferences... In the meantime, you can download a file through Safari and then use the Add button to make the file known to OpenMoko Flasher. Best regards, Nikolaus Am 21.08.2007 um 05:21 schrieb Neal Horman: Um, the directory structure of the build host has changed, and there is no configuration for changing the url and there is no source to recompile. Please can you help fix the tool ? Thanks Neal ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko API Documentation
The classes you mention belong to OM-2007.1 which won't receive any more development. OM-2007.2 so far only features one class on top of Gtk+, the MokoFingerScroll. It's derived from GtkScrolledWindow and should be drop-in substitute. Full doxygen-based API documents -- also for the classes that are forthcoming -- are on our todo. -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Balancing simplicity with complexity
Giles Jones wrote: Having tried 2007.2 it's a great improvement and moves the phone a long way into looking like a product. Thanks, we still see a long way before us, but we're moving! :) I have some usability improvement suggestions that I will propose at some point. Excellent. Please do that via bugzilla. Will the old 2007 be phased out? it's never going to get finished given most people will want to develop 2007.2 and beyond. There won't be any more development on 2007.1. We will though, have to port some of the remaining classes and applications to get a more rich OpenMoko library API. -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: FM Radio
I'm currently using a Motorola E6 as I wait for NEO to be more ready for the early adopter / power user. While I haven't had it a long time, I will say that the FM Radio is a pretty commonly used thing for me in a cell phone .. and I encourage the group to consider it if it doesn't have huge overhead / openness issues. - While travelling .. it gives an outlet for picking up traffic / news .. etc that otherwise you might not have access to. - At the gym / workout facility there's often times several TV's with low range FM modulators piping the audio to different channels. This has been huge for use with the E6 .. and I think the same will be true with Neo. It's a pretty small thing when I picked out the phone .. I got the phone for the quad band, expandability and modabillity .. the FM was a throw in that I find myself using almost everyday .. for small periods of time .. but almost every day. Regarrds, DS On Thu, Aug 16, 2007 at 01:45:12PM +0530, Ashok Kumar wrote: not really. It's still somewhat of a strange conception to me why peopel would be interested in listening to hours and hours of crappy commercials interrupted with one or two (mostly crappy, too) songs in between, if they have a choice to listen to their collection of .ogg (and patent-encumbered .mp3) files. Also, I currently don't know what effects this has on things like FCC approval. Furthermore, some countries have some kind of levy-based scheme for funding the public broadcasting companies. This means that they would have to pay extra money for a device that has FM radio capabilities. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ I'm not in agreemen with how you say about the FM... So no radio for Neo? not even in future versions? I am one that think that it's a FM radio is essential in a modern device, like the camera. This is not a good news for me... :( ___ 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: Can't flash smaller root-fs through dfu-util?
On 8/21/07, Dr. H. Nikolaus Schaller [EMAIL PROTECTED] wrote: Am 21.08.2007 um 19:23 schrieb John Seghers: Dr. H. Nikolaus Schaller wrote: After unsuccessfully flashing different root-filesystems, I finally found this note: If you upload rootfs image that is smaller that previous one it won't work - you need to attach to bootloader, erase NAND and then upload your rootfs first: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs This *should* help but I am trying to understand why dfu-util can't do that? And what do I do if I have no serial interface? Does this mean I can't ever again flash a (smaller) rootfs? I have no info on the first question, but about the serial interface. The commands above actually run over USB. Simply boot the Neo into uBoot (hold the Aux button while powering on) and select the option to use the console over USB (Move selection using Aux, invoke the selection by pressing power). Then plug in the USB cable and run the cu command. Many thanks for your suggestions, but MacOS X has no cu command :-( And, I want to automate this all with dfu-util. BTW: the bug tracker (bugs #419, #719, #726) says it has been solved by a newer version of uboot - but to my experience it is not completely solved even by an uboot compiled 19th August. It looks like that contrary to the warnings on http:// wiki.openmoko.org/wiki/Flashing_openmoko it is NOT optional. We all should flash a newer uboot first. Nikolaus The problem is that many of us don't have a debug board, and it's a bit scary to flash a new uboot which could brick the device. It would be nice if some uboot builds were blessed so that we know we can safely flash those without bricking the neo. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: compile problem: OOM when compiling
Marcin Juszkiewicz wrote: Does anyone see this problem too? my host os is ubuntu 7.04 (feisty) on x86_64. Our buildhost is x86_64, I have to use a custom uname (returning i686) and BUILD_ARCH = i686 in local.conf to make it build openmoko-devel-image. Mickeyl - you are cheater when it comes to 64bit. From my experience only Python has problems if build machine is 64bit and build for 32bit. You are saying openmoko-devel-image from scratch runs through on your 64bit machine? :M: ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How about a slim Openmoko design?
Open Source = Choice, Freedom, Alive Slim Design = EDCability ( and currently lack of features) Open Source + Slim Design = Choice, Freedom, Alive and EDC The problem with my current phone's software is that I am stuck with what I bought. I cannot use applications other than what was shipped with it. Even if I like an application I know sooner or later I may have to give it up, as, there have been hardly any updates in over an year. The development on its applications is dead. Even when I love hacking and am not faint hearted in trying out broken stuff and making it work. The thing about open source - it does not die like this - just adapts and evolves. So, I will always have some version of what I like. this is apart from the choice in apps. and freedom. And this keeps on growing and growing. The thing about a slim small phone is that it never gets left behind on that unfortunate day when you may need it the most. Almost becomes an inseparable part of your attire. Even on that hot sunny outdoor trek. Am saving and looking forward to the Phase 2 release of Openmoko and Its great to hear that there may be other cool designs later in the road map. Thanks guys. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Balancing simplicity with complexity
Jeff Andros wrote: mostly to rod... how soon until mokomakefile is updated? It was updated and put into alpha testing a couple of days before Sean's announcement, and went live about 6 hours before the announcement (on Mickey's Go signal). However, my announcement of the MokoMakefile update then took another 24 hours at least to get through the openmoko mailing list logjam. -- Rod ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM Radio
Are there no companies that make USB FM receivers? Seems like that would be an easy fix, right? I got a Sansa e140 as a prize a little while ago. It has an FM receiver. I was thinking of breaking the thing open and trying to steal the receiver to put in my Neo. Think that's workable? -Steven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Forum? (Was Re: Neo Sound and USB Questions)
Harald Welte wrote: On Tue, Aug 21, 2007 at 11:19:57AM +0200, Dr. H. Nikolaus Schaller wrote: Harald, please calm down. I know from your blog how upset you are from setting up the new office location, networks and servers during Taifun time. in fact that was the most fun part. But just one question to answer for yourself: do you want to have community involvement or not? I am from the community ;) And not in my 10+ years of FOSS community development have I seen any project that had problems with properly using mailinglists. Forums are for people who don't understand the technology of properly dealing with e-mails. Of what use is something that's only available online? Of no use at all. Try keeping a local copy of a forum on your laptop. Why should openmoko be any different? We will most likely have a forum for _end users_ at a time where we want to address end users. But not for developers, sorry. Now as your network appears to work again, please focus on solving kernel, uboot, etc. issues that we as the dumb users can't solve ourselves. I am for example still fighting the issue with short and long rootfs flashing and NAND erasing, that leaves an inoperable OpenMoko device If you consider yourself a dumb user, then you probably are not the kind of developer crowd that we are addressing at this moment :( ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots? (was: Balancing simplicity with complexity)
On 8/21/07, Erland Lewin [EMAIL PROTECTED] wrote: Sounds great! Are there screenshots available anywhere? /Erland Better, see videos on this blog: http://chrislord.net/blog/fancy-scrolling-widgets-pt2.enlighten ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Forum? (Was Re: Neo Sound and USB Questions)
Sorry. I had uncontrollable spasms in my mouse finger. Or whatever. This mail was not intentionally sent. Sorry I just wanted to agree with harald. But not whith sending a blanc email. :) Forums suck for many reasons. (No filter, no archiving, no offline use, ...) No FOSS project of any importance needed a forum for anything. If someone likes forums so much. Write a mailinglist-2-frum proxy. Or make a pimped up verison of the list arcives for browser use. (This is a part where all/most mailinglists really stink at the moment) Tilman Baumann wrote: Harald Welte wrote: On Tue, Aug 21, 2007 at 11:19:57AM +0200, Dr. H. Nikolaus Schaller wrote: Harald, please calm down. I know from your blog how upset you are from setting up the new office location, networks and servers during Taifun time. in fact that was the most fun part. But just one question to answer for yourself: do you want to have community involvement or not? I am from the community ;) And not in my 10+ years of FOSS community development have I seen any project that had problems with properly using mailinglists. Forums are for people who don't understand the technology of properly dealing with e-mails. Of what use is something that's only available online? Of no use at all. Try keeping a local copy of a forum on your laptop. Why should openmoko be any different? We will most likely have a forum for _end users_ at a time where we want to address end users. But not for developers, sorry. Now as your network appears to work again, please focus on solving kernel, uboot, etc. issues that we as the dumb users can't solve ourselves. I am for example still fighting the issue with short and long rootfs flashing and NAND erasing, that leaves an inoperable OpenMoko device If you consider yourself a dumb user, then you probably are not the kind of developer crowd that we are addressing at this moment :( ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bricked Neo
On Wed, 2007-08-22 at 01:43 +, an unknown sender wrote: I ran a nand erase when I was a bit tired and have killed my phone. As long as you didn't erase uboot you should still be able to re-flash the phone without a debug board. Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Lipstick on a fetus
Hi Ken, I hope once you've tested 2007.2 you will find there have been many improvements in the Dialer. We have re-written large parts of it in an effort to make it simpler and more stable. There are still teething problems lower down the stack (gsmd for example), but significant progress is being made. One of the aims of 2007.2 was to simplify our approach so we could concentrate on getting the core features working well (such as making and receiving calls). Please help us by testing the snapshots and filing bugs on bugzilla.openmoko.org. Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bricked Neo
Thomas Wood wrote: On Wed, 2007-08-22 at 01:43 +, an unknown sender wrote: I ran a nand erase when I was a bit tired and have killed my phone. As long as you didn't erase uboot you should still be able to re-flash the phone without a debug board. Regards, Thomas I literally did nand erase, and I think that kills everything. The phone won't start, no matter what I try. That could just be a power problem, though. I'm very willing to be corrected :-D In case I'm right, I've just ordered myself a wiggler to see if can flash the uboot back on as per this wiki page http://wiki.openmoko.org/wiki/Sjf2410-linux Cheers, Mark C. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Screenshots
http://scap.linuxtogo.org/index.php?page=1 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots? (was: Balancing simplicity with complexity)
Great UI! But after watching the layout, I have one concern: Compare with the incoming-call layout: http://wiki.openmoko.org/images/f/f0/Dialer-incoming-arrows.png and the in-call layout: http://wiki.openmoko.org/images/f/f7/Dialer-talking-arrows.png The place of the accept-call button in former is the same with hang-up button in the latter. There may be the probabily that: if the system responds slowly for some reason, user press accpet-call and in-call state doesn't popup immediately, then he may press the button again but at this moment in-call state popup, so he actually pressed the hang-up button instead. 2007/8/22, Joe Friedrichsen [EMAIL PROTECTED]: On 8/21/07, Erland Lewin [EMAIL PROTECTED] wrote: Sean Moss-Pultz wrote: We went back to the drawing board with OpenedHand -- lead by their vast experience with GTK+, Matchbox, and mobile user interfaces -- and redesigned an incredibly promising new interface. Sounds great! Are there screenshots available anywhere? Yes, on the wiki. http://wiki.openmoko.org/wiki/Dialer/2007.2 for example... Joe ___ 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: Screenshots
Amy Stephen [EMAIL PROTECTED] wrote : But, IMO, the color scheme is wrong! I know lots of amazing technical hurdles are being cleared and political ones, as well. But, that color scheme is going to hold this thing back. It should be snazzy and bright and colorful and full of ENERGY! Not orange and black like Halloween. The added gray does not help, either! Orange and black will get the spooky kids interested in buying one though :) But if it's all being done in a skinnable way it will be possible to change the colour scheme and appearance. The orangeness does remind me of old CRT monitors. I'd much sooner see some blue, it's easier on the eye (and that's a scientific fact, eyes are less sensitive to blue). --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
Absolutely true! It should be skinnable. But, before that happens - these images are what are hitting the press. Would certainly love to see OpenMoko present a very sharp, bright image as others are observing, wondering if an open source community can really go toe-to-toe with the iPhone. I recognize in relative terms of importance, this is *not* critical. All the best, Amy :) On 8/22/07, Giles Jones [EMAIL PROTECTED] wrote: Amy Stephen [EMAIL PROTECTED] wrote : But, IMO, the color scheme is wrong! I know lots of amazing technical hurdles are being cleared and political ones, as well. But, that color scheme is going to hold this thing back. It should be snazzy and bright and colorful and full of ENERGY! Not orange and black like Halloween. The added gray does not help, either! Orange and black will get the spooky kids interested in buying one though :) But if it's all being done in a skinnable way it will be possible to change the colour scheme and appearance. The orangeness does remind me of old CRT monitors. I'd much sooner see some blue, it's easier on the eye (and that's a scientific fact, eyes are less sensitive to blue). --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- [EMAIL PROTECTED] http://OpenSourceCommunity.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
Amy Stephen wrote: But, IMO, the color scheme is wrong! I know lots of amazing technical hurdles are being cleared and political ones, as well. But, that color scheme is going to hold this thing back. It should be snazzy and bright and colorful and full of ENERGY! Not orange and black like Halloween. The added gray does not help, either! I like the new schme very much. Dark interfaces aren't generally bad. My Desktop is black and gray. Or just have a look at the LG Chocklate, it is mainly black and red. The best looking phone ui ever i would say. :) (iPhone excluded) But i'm sure this will be no real concern in the future, since theming is of course mandantory. Regards Tilman ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
- Original Message - From: Amy Stephen Absolutely true! It should be skinnable. But, before that happens - these images are what are hitting the press. Would certainly love to see OpenMoko present a very sharp, bright image as others are observing, wondering if an open source community can really go toe-to-toe with the iPhone. I recognize in relative terms of importance, this is *not* critical. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
Sorry for the empty post. Heres the intended content. - Original Message - From: Amy Stephen Absolutely true! It should be skinnable. But, before that happens - these images are what are hitting the press. Would certainly love to see OpenMoko present a very sharp, bright image as others are observing, wondering if an open source community can really go toe-to-toe with the iPhone. I recognize in relative terms of importance, this is *not* critical. I have to agree with amy. Interface is not that jazzy yet. It looks really old-school. I've yet to hold moko in my hands so I can not comment on how it feels, but it does look a bit old in the videos. It's sort of funny the way it seems to go: first you are really exited about something (like I was about the first ui's), and then it starts to look old. Even before I get it in my hands. I guess that this is due to the fact that the implementation has not been up to speed with the photoshop drafts. And now that they are getting closer to the point when ui would be important, there is a release of images that do not contain that much of anything new. BTW: its hard to be exited about kinetic scrolling when others have already done it so well. It's a 'cool' feature, must-have, in order not to pale in comparison. I guess that there should be something extra on the ui. It's pretty plain as it is. Maybe there could be animations or some other stuff that'd make the phone come to life? Maybe for the menus and toolbars or something like in compiz? -- Kalle.___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
On 8/22/07, Jeremy G [EMAIL PROTECTED] wrote: I think at this point, the orange/black is just such a default OpenMoko look that getting rid of it would cause a few aneurysms; I also think that the color scheme is already so associated with the OS that springing something new would bring about a bit of confusion in the press and among casual followers. OK, Jeremy - that is an excellent point. I withdraw my incredibly unimportant points! Brand recognition certainly trumps this. Back to listening in to this fabulous and important discussion...keep up the great work! Amy :) -- [EMAIL PROTECTED] http://OpenSourceCommunity.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
On Wed, 2007-08-22 at 19:49 +0300, Kalle Kärkkäinen wrote: [...] I guess that there should be something extra on the ui. It's pretty plain as it is. Maybe there could be animations or some other stuff that'd make the phone come to life? Maybe for the menus and toolbars or something like in compiz? Firstly, You have to build a project that works withing the technical limitations of your hardware. Sure, the original mockups (2007.1) looked impressive, but there was no way they were going to be implemented nicely with our hardware and resources. Secondly, it's only natural that after a while something that was once new and jazzy will become old and plain. The most exciting thing about this project is not that it will have a fancy user interface or some amazing killer feature. The most exciting thing about this project is that the whole phone and platform is based on the principles of Free Software. Besides, what's the point of adding animations or other stuff if the most important features don't work in the first place? We're building a smartphone from scratch here, so let's get our priorities right! Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is GTA2 UMA/GAN capable
On Tue, Aug 21, 2007 at 08:51:24AM -0400, Richard Boehme wrote: Will the GTA2 be UMA/GAN capable? no. If not, does anyone know if FIC has any plans for a UMA/GAN capable OpenMoko phone? yes, we would love to have one. But I don't think there is any way how we could do it in the forseeable future. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Buying Openmoko GTA02 from Europe
Hi, It seems that a big problem we have here in Europe to get Openmoko devices is that the shiping costs are quite high: around 80-100USD !! I've opened a website that will sell GTA02 devices when they are available, to other Europe countries. I'll buy quantities of devices from FIC and resell them from here, in Switzerland, middle of Europe. If you are interested in buying one, please drop me a mail through the website at : http://www.jesc.ch/openmoko This is a *pre-order* only. You are not liable if you change your mind! It's just to know the approximate number of devices that I'll need to order from FIC. Payment will be possible through Paypal or direct postal payment in Switzerland. Shiping costs will be around 20-25EUR for countries in Europe. Best regards. -jec -- Don't assume, ask! JeSC - Software et Consulting Jean-Eric Cuendet Ingénieur HES en télécommunications 1168 Villars-sous-Yens Web : http://jesc.ch Tel : +41 21 800 3343 Mobile: +41 76 222 3343 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM Radio
On 8/22/07, Steven ** [EMAIL PROTECTED] wrote: I was thinking of breaking the thing open and trying to steal the receiver to put in my Neo. Think that's workable? http://lists.openmoko.org/mailman/listinfo/community uh... probably not... I haven't seen the device, but there probably isn't a nice discrete module to pull out... production devices like that tend to be highly integrated to save space, and, from the pictures I've seen in a quick google search, I'd guess most of the chips are BGA packaged... it's a pain in the *arse* to work with unless you've got hot air -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
I just want to say that I can't stand the ubuntu colors. Please don't suggest using ugly brown colors for a phone. At the moment I like the dark version of the phone but the orange one could use a little change. Dylan McCall wrote: Have to kind of agree with Amy about the colour scheme. I am not much of an art person, but I am pondering a theme that rhymes with Ubuntu's Human theme, with a more natural, (human) look to the applications. I am one of what seems a few who has always liked the idea behind that theme :b What I have pondered out (in way too many different mediums) is a bit lighter than that Human theme, but I think it is helpful to have applications behave more like people than just machines. I am not talking about avatars that are pictures of smiling people! For example, people make suggestions and know what they are doing, while machines just do things, assuming the user knows everything. For a friendly interface, I think the human behaviour can be really beneficial and unique, as opposed to the appliance behaviour of most systems. The theme is the first place to start! The other thing I consider a bit problematic with the black and orange is that it is difficult (nay, impossible!) to get a more extreme colour for particularly important buttons and messages. For example, with a lighter background, Red would be a lot prominent. Bye, -Dylan McCall On 8/22/07, *Amy Stephen* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks so much for sharing these pictures. I include one, and a link, on OpenSourceCommunity.org I watch this project very closely. It has great potential to keep choice available to people - even just for selecting a services provider. But, IMO, the color scheme is wrong! I know lots of amazing technical hurdles are being cleared and political ones, as well. But, that color scheme is going to hold this thing back. It should be snazzy and bright and colorful and full of ENERGY! Not orange and black like Halloween. The added gray does not help, either! All the best to you all as you work together on this extremely important effort! Amy :) On 8/22/07, * Franco Austin* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://scap.linuxtogo.org/index.php?page=1 ___ OpenMoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://OpenSourceCommunity.org ___ OpenMoko community mailing list community@lists.openmoko.org mailto: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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How about a slim Openmoko design?
I think less PDA is the wrong direction to go with this product. Future versions ought to be more iPhone-like in form factor (as slim as they can make it, and frameless or at least nearly, with a high ratio of screen real estate to overall size). As for hardware hacking, I doubt that most of us are going to be really changing out chips or soldering the board anyway... we just need schematics (for understanding) and easy access to JTAG. That can still be accomplished with a compact design. A lot of people say they want a plain old telephone without so many features, but it doesn't seem very interesting to me, and I'm not sure if they really want that either... or this idea just comes out of a frustration with current UI's. Such a phone could also be an open-source project, but it would tend to be completely different. E.g. there is no point in using Linux for that, when a simpler microcontroller with simpler all-in-one firmware would suffice. (And you would get incredible battery life with that approach, too.) I think a different company ought to try that, but there is no point in having the OpenMoko resources being spread thinner by trying to do both. For applications like web browsing and email and GPS navigation, you need as much screen real estate, resolution, memory and processing power as you can get. But the content itself is way more important than the eye candy. It's still good to simplify the UI as much as possible, but not by removing features. I don't actually talk to people that much; probably more of my minutes are used by GPRS than voice (or at least it will be that way, when I can get a phone on which browsing becomes more worthwhile than it has been on my A1200). So I'm one class of users. Then there are the professionals that do need to talk to a lot of people, and therefore contact management features are very important; but they also could make use of all the PDA and Internet features. The third class would be people who just use a phone for talking, some of them need it to be rugged, and they don't care about the other features (construction workers, plumbers and other service people, and people who are put off by ever having to learn anything new). A smart phone of any kind is not for them, and there is hardly any point in trying to adapt it to satisfy them, IMO. They are also not likely to care if it's open-source or not (because they don't need any applications - just a dialer and a contact list). On 8/21/07, Jørgen P. Tjernø [EMAIL PROTECTED] wrote: Perhaps not as much processing and features, but more of a phone, less of a PDA (actually, less of a Smartphone too?). In any case, I guess that'll be something we won't see until well beyond 2007. :-) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screenshots
On 22 Aug 2007, at 19:38, Xamindar wrote: I just want to say that I can't stand the ubuntu colors. Please don't suggest using ugly brown colors for a phone. At the moment I like the dark version of the phone but the orange one could use a little change. People will never agree on colours, icons etc. People like to be individual or to be able to customise. Effort should be put into making theme support painless, then everyone can be happy. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can't flash smaller root-fs through dfu-util?
Dr. H. Nikolaus Schaller wrote: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs Many thanks for your suggestions, but MacOS X has no cu command :-( You can use minicom from the Darwin Ports collection. I've added a section on the Wiki: http://wiki.openmoko.org/wiki/MacOS_X#USB_Serial ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How about a slim Openmoko design?
Shawn Rutledge wrote: A lot of people say they want a plain old telephone without so many features, but it doesn't seem very interesting to me, and I'm not sure if they really want that either I've used various cell phones since 1996 and now seeing that it's nearly impossible to buy a phone *without* a camera, mp3 player, push-to-talk, etc.. A little over a year ago, when it was time to replace a dead Samsung phone, I was BEGGING for just a simple clamshell style phone that was JUST a cell phone. I didn't need a smartphone at the time, I didn't want another lousy 1MP camera, and I'd already invested in a nice non-iPod MP3 player, so all I needed was just a cell phone. I truly believe there's still a market for that. As far as my own attitude changing: I was given a Treo 700w from work this spring, which was my first real experience with a smartphone (with an actual browser, bluetooth, etc.). And now that I've quit that job to work from home, I've had to give it back, and seriously miss having a browser. So I've decided that when the Neo1973 comes out for mass consumption, I'm all over it, because I don't really need a camera or mp3 player built into a phone. The GPS module is likely going to be quite overused in my case. And yes, I'll likely overuse the contacts portion as well, as being able to sync my address books and calendar have become quite important to me. Just my $0.02. -id ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buying Openmoko GTA02 from Europe
Jean-Eric Cuendet (ML) wrote: Hi, It seems that a big problem we have here in Europe to get Openmoko devices is that the shiping costs are quite high: around 80-100USD !! I've opened a website that will sell GTA02 devices when they are available, to other Europe countries. I'll buy quantities of devices from FIC and resell them from here, in Switzerland, middle of Europe. I am interested, but I am concerned about VAT and import duty issues, as Switzerland is outside the European Union. I would feel much happier ordering from an importer inside the EU, as that way the importer would be responsible for sorting out and paying any import duties and taxes. The price I pay would include VAT at the prevailing rate in the importer's country. (So it would be better to ship from Belgium where it is low, rather than France where it is high). Unfortunately I don't get any of those advantages if buy from a retailer ouside the EU. I may save a small amount on shipping, but I would still have the headache of paying those taxes myself, and the posibily of paying a lot more than I expect if the customs officers misclassify the Neo 1973, or disagree with me on it's value. Payment will be possible through Paypal or direct postal payment in Switzerland. Shiping costs will be around 20-25EUR for countries in Europe. I *HATE* paypal, so in any case, if you can find another way of receiving payments that would be good. Regards -- David Pottage ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mailing list management
On Tue, 2007-08-21 at 19:31 +0800, Harald Welte wrote: Dear Hank, On Tue, Aug 21, 2007 at 06:50:03AM -0400, hank williams wrote: While I agree with your argument that no header is the standard for FOSS, this is not the case for the reply to issue, which you did not address. As I said earlier, the Apache groups (perhaps the largest FOSS umbrella) for example, and many (most?) others do not have the default reply-to going to the individual. Part of the reason for this is that it is bad user interface for the default behavior to be one that is used perhaps 1% of the time. Most people generally want to reply to group. Your default should be the most commonly accessed option which is why your design decision on this matter is not only not standard, but is, I believe, the minority design, even in the FOSS community. I'm not opposed to changing the reply-to for community, if you want that. In fact, I have now changed it. For all other lists I'm a bit less inclined to do it, but would be willing to change if there were many supporters of such a change. Hello, how do i now answer only to the poster ? (only using one button/shortcut press) as before i could use: ctrl+l = reply to list ctrl+r = reply to poster and now both reply to the list... and no! i _dont_ want to start a flamewar! just wanted to ask if someone knows how to reply only the poster with one click in evolution (or another linux email client, so i could change) mfg. andre ps. on a side note, when i do reply all it also sends only to list. i newer did/do this, but was just wondering is it normal or just my client ? (as with my logic it should answer to the real sender and the list, no?) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: mailing list management
Mike Hodson wrote: Why not reply to all? Because im rather sure I don't want to reply to the author twice Well, I want you to reply to me twice, reason being that one copy goes into my openmoko folder and the other goes into my inbox. This way, I know this is not just another boring email in the list, but an email regarding a thread I'm interested in. Now, you might conceivably say that while that logic applies to me, it does not apply to you. To that I answer: log on to the mailman interface and turn on no duplicates. You get what you want (one email) and I get what I want (two emails), provided EVERYBODY PRESSES REPLY TO ALL. My $0.02 Mike Shachar ___ 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: mailing list management
On Tue, Aug 21, 2007 at 07:31:54PM +0800, thus spake Harald Welte: Dear Hank, On Tue, Aug 21, 2007 at 06:50:03AM -0400, hank williams wrote: While I agree with your argument that no header is the standard for FOSS, this is not the case for the reply to issue, which you did not address. As I said earlier, the Apache groups (perhaps the largest FOSS umbrella) for example, and many (most?) others do not have the default reply-to going to the individual. Part of the reason for this is that it is bad user interface for the default behavior to be one that is used perhaps 1% of the time. Most people generally want to reply to group. Your default should be the most commonly accessed option which is why your design decision on this matter is not only not standard, but is, I believe, the minority design, even in the FOSS community. I'm not opposed to changing the reply-to for community, if you want that. In fact, I have now changed it. *sigh* Now this is another list I have to be very careful on to be sure I don't send something to the list that I intended to go only to one person. I disagree with Hank that default behavior is the issue here. It's not a matter of the default for one action; there are two separate actions to take, either reply to the sender or reply to the list. These have two separate buttons/keys in any mail program. You choose which one to use based on the behavior you want. Neither one should be easier or more difficult than the other. In Gmail, I press 'r' when I want to reply to the sender and 'a' when I want to reply to all/list; in mutt I press 'r' to reply to sender and 'L' to reply to list. Now 'a' or 'L' still gets me the list behavior but 'r' is broken. In fact, in Gmail, there's now no way to reply to the sender other than copying and pasting the email address into the To: field. (I consider this a bug in Gmail, but still, it'll be an issue for a lot of people on this list.) Some mailers have special features for lists. Some mailers automatically use Reply-To and some ask you. But every mailer has a Reply to All feature that will reply to the list. Why break the normal behavior of Reply in most mail programs in order to duplicate a feature that all mail programs already have? *sigh* Marco ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Neo Debug Board Schematics or Pinouts
Are these signals TTL level or are they already RS-232? If they are TTL, is there any reason I could not use the BrainStem from Acroname (http://www.acroname.com/robotics/parts/S13-SERIAL-INT-CONN.html) to overcome this? (That device only uses TXD, RXD, and of course power and ground). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joachim Steiger Sent: Saturday, August 18, 2007 2:43 PM To: community@lists.openmoko.org; [EMAIL PROTECTED] Subject: Re: Neo Debug Board Schematics or Pinouts wee.kiampeng wrote: Hi folks, I will like to to have a peek at the Neo debug board's schematics or pinouts. I need to access the uarts as well as the jtag. Does anyone have any idea? we already are in the process of releasing the neo debug board schematics since we believe that it would be useful not only for the moko, but for a lot of different usecases for the embedded hacker community. please give us some more time do do this properly. if you need to access the serial of the ftdi via the 2.54mm spacing port ( J10 ) the pinout is as follows: 1 TXD 2 RXD 3 RTS 4 CTS 5 DSR 6 DTR 7 DCD 8 RI 9 GND 10 VCC (3.3V) remember, this is the port B of the ftdi2232D so the mapping is BDBUS0-BDBUS7 pin 1 to pin 8 to get a serial from your linux kernel do this: modprobe ftdi_sio vendor=0x1457 product=0x5118 then you get 2 serial of which one will vanish as soon as you start openocd to use portA as jtag J1 on the debug board is JTAG in regular arm 20pin out kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mailing list management
On Wednesday 22 August 2007 21:19, Andre Schmidt wrote: On Tue, 2007-08-21 at 19:31 +0800, Harald Welte wrote: I'm not opposed to changing the reply-to for community, if you want that. In fact, I have now changed it. For all other lists I'm a bit less inclined to do it, but would be willing to change if there were many supporters of such a change. Hello, how do i now answer only to the poster ? (only using one button/shortcut press) as before i could use: ctrl+l = reply to list ctrl+r = reply to poster and now both reply to the list... KMail seems to understand this properly, this email provides me several options: R: Reply (goes to list) A: Reply to All (goes to list and to you) Shift-A: Reply to author (goes to you) L: Reply to list (goes to the list again) Using L and Shift-A on a proper mailing list message will give you the same result in KMail regardless of the configuration of the mailinglist... AVee ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
tinylogin: file can not be created! error on do_rootfs
I'm trying to build OpenMoko using mokomakefile on Ubuntu 7.04 (Feisty Fawn), and it's dying with the following error: NOTE: Running task 3401 of 3403 (ID: 4, /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) NOTE: package openmoko-devel-image-1.0: started NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: started ERROR: function do_rootfs failed ERROR: log data follows (/home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849) | + rm -rf /home/myk/Projects/moko/build/tmp/rootfs | + '[' 0 '!=' 1 ']' | + mkdir -p /home/myk/Projects/moko/build/tmp/rootfs/dev | + for devtable in /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | + makedevs -r /home/myk/Projects/moko/build/tmp/rootfs -D /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | makedevs: /home/myk/Projects/moko/build/tmp/rootfs/bin/tinylogin: file can not be created! NOTE: Task failed: /home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849 NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed ERROR: TaskFailed event exception, aborting NOTE: package openmoko-devel-image-1.0: failed ERROR: Build of /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb do_rootfs failed ERROR: Task 4 (/home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) failed NOTE: Tasks Summary: Attempted 3400 tasks of which 0 didn't need to be rerun and 1 failed. ERROR: '/home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb' failed make: *** [openmoko-devel-image] Error 1 Does anyone know what the problem might be and how to resolve it? -myk ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tinylogin: file can not be created! error on do_rootfs
Sounds like bug #740 http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=740 -Rob On 8/22/07, Myk Melez [EMAIL PROTECTED] wrote: I'm trying to build OpenMoko using mokomakefile on Ubuntu 7.04 (Feisty Fawn), and it's dying with the following error: NOTE: Running task 3401 of 3403 (ID: 4, /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) NOTE: package openmoko-devel-image-1.0: started NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: started ERROR: function do_rootfs failed ERROR: log data follows (/home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849) | + rm -rf /home/myk/Projects/moko/build/tmp/rootfs | + '[' 0 '!=' 1 ']' | + mkdir -p /home/myk/Projects/moko/build/tmp/rootfs/dev | + for devtable in /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | + makedevs -r /home/myk/Projects/moko/build/tmp/rootfs -D /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | makedevs: /home/myk/Projects/moko/build/tmp/rootfs/bin/tinylogin: file can not be created! NOTE: Task failed: /home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849 NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed ERROR: TaskFailed event exception, aborting NOTE: package openmoko-devel-image-1.0: failed ERROR: Build of /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb do_rootfs failed ERROR: Task 4 (/home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) failed NOTE: Tasks Summary: Attempted 3400 tasks of which 0 didn't need to be rerun and 1 failed. ERROR: '/home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb' failed make: *** [openmoko-devel-image] Error 1 Does anyone know what the problem might be and how to resolve it? -myk ___ 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: FM Radio
2007/8/22, Jeremy G [EMAIL PROTECTED]: Plus, most of the good radio (for example NPR here in the US) is released in some sort of downloadable format anyway, so anymore I don't see much use for a FM receiver. To listen for streaming radio I MUST pay for the download, and the price of data isn't cheap... so, the FM module is the only way, for me, to listen radio. And I see very much use of it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo Debug Board Schematics or Pinouts
Heilpern, Mark wrote: Are these signals TTL level or are they already RS-232? If they are TTL, is there any reason I could not use the BrainStem from Acroname (http://www.acroname.com/robotics/parts/S13-SERIAL-INT-CONN.html) to overcome this? (That device only uses TXD, RXD, and of course power and ground). it is 3.3V cmos logic so NO RS-232 levels. you could use that board you linked to connect to the serial console of a moko, i think. at least in theory because you still need to build an adapter for the fpc. and supply it with 3.3V (the specs of the brainstem say it can be used with 3.3V) you just need to keep in mind that the serial is getting switched on and off by GSM_EN and some latches on the debug board. kind regards -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tinylogin: file can not be created! error on do_rootfs
Not to hi-jack your thread, but to rather put together build error threads, I'm having this build problem. Whilst making 2007.2 | make[1]: Entering directory `/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-src-4.3.0/src/tools/uic3' | g++ -fno-exceptions -Wl,-rpath,/home/mintee/moko/build/tmp/staging/i686-linux/qt4/lib -Wl,-rpath,/home/mintee/moko/build/tmp/staging/i686-linux/qt4/lib -o ../../../bin/uic3 .obj/release-static/customwidgetsinfo.o .obj/release-static/databaseinfo.o .obj/release-static/driver.o .obj/release-static/treewalker.o .obj/release-static/ui4.o .obj/release-static/uic.o .obj/release-static/validator.o .obj/release-static/cppextractimages.o .obj/release-static/cppwritedeclaration.o .obj/release-static/cppwriteicondata.o .obj/release-static/cppwriteicondeclaration.o .obj/release-static/cppwriteiconinitialization.o .obj/release-static/cppwriteincludes.o .obj/release-static/cppwriteinitialization.o .obj/release-static/main.o .obj/release-static/ui3reader.o .obj/release-static/parser.o .obj/release-static/domtool.o .obj/release-static/object.o .obj/release-static/subclassing.o .obj/release-static/form.o .obj/release-static/converter.o .obj/release-static/widgetinfo.o .obj/release-static/embed.o .obj/release-static/qt3to4.o .obj/release-static/deps.o -L/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-src-4.3.0/lib -lQt3Support -L/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-src-4.3.0/lib -lQtSql -pthread -L/home/mintee/moko/build/tmp/staging/i686-linux/lib -pthread -pthread -pthread -pthread -pthread -pthread -pthread -L/usr/X11R6/lib -pthread -pthread -pthread -pthread -lQtNetwork -pthread -pthread -pthread -pthread -pthread -pthread -lQtXml -pthread -pthread -lQtGui -pthread -pthread -lXext -lX11 -lQtCore -lz -lm -pthread -lgthread-2.0 -lglib-2.0 -lrt -ldl -lpthread | /usr/bin/ld: cannot find -lXext | collect2: ld returned 1 exit status | make[1]: *** [../../../bin/uic3] Error 1 | make[1]: Leaving directory `/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-src-4.3.0/src/tools/uic3' | FATAL: oe_runmake failed NOTE: Task failed: /home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/temp/log.do_compile.12505 NOTE: package uicmoc4-native-4.3.0-r2: task do_compile: failed ERROR: TaskFailed event exception, aborting NOTE: package uicmoc4-native-4.3.0: failed ERROR: Build of /home/mintee/moko/openembedded/packages/uicmoc/uicmoc4-native_4.3.0.bb do_compile failed ERROR: Task 2696 (/home/mintee/moko/openembedded/packages/uicmoc/uicmoc4-native_4.3.0.bb, do_compile) failed NOTE: Tasks Summary: Attempted 1394 tasks of which 1384 didn't need to be rerun and 1 failed. ERROR: '/home/mintee/moko/openembedded/packages/uicmoc/uicmoc4-native_4.3.0.bb' failed make: *** [openmoko-devel-image] Error 1 On Wed, 2007-08-22 at 14:11 -0700, Myk Melez wrote: I'm trying to build OpenMoko using mokomakefile on Ubuntu 7.04 (Feisty Fawn), and it's dying with the following error: NOTE: Running task 3401 of 3403 (ID: 4, /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) NOTE: package openmoko-devel-image-1.0: started NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: started ERROR: function do_rootfs failed ERROR: log data follows (/home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849) | + rm -rf /home/myk/Projects/moko/build/tmp/rootfs | + '[' 0 '!=' 1 ']' | + mkdir -p /home/myk/Projects/moko/build/tmp/rootfs/dev | + for devtable in /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | + makedevs -r /home/myk/Projects/moko/build/tmp/rootfs -D /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | makedevs: /home/myk/Projects/moko/build/tmp/rootfs/bin/tinylogin: file can not be created! NOTE: Task failed: /home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849 NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed ERROR: TaskFailed event exception, aborting NOTE: package openmoko-devel-image-1.0: failed ERROR: Build of /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb do_rootfs failed ERROR: Task 4 (/home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) failed NOTE: Tasks Summary: Attempted 3400 tasks of which 0 didn't need to be rerun and 1 failed. ERROR: '/home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb' failed make: *** [openmoko-devel-image] Error 1 Does anyone know what the problem might be and how to resolve it? -myk ___ OpenMoko community mailing list
Re: RM Radio
not really. It's still somewhat of a strange conception to me why peopel would be interested in listening to hours and hours of crappy commercials interrupted with one or two (mostly crappy, too) songs in between, if they have a choice to listen to their collection of .ogg (and patent-encumbered .mp3) files. Plus, most of the good radio (for example NPR here in the US) is released in some sort of downloadable format anyway, so anymore I don't see much use for a FM receiver. Local non-syndicated radio is awesome. I have some very good stations in my area. The news is more relevant to my area than NPR, but NPR is great for news around he world, and the people operating the stations are people I see around my community. If radio is done right, it is by no means outdated. I personally like listening to my local stations because it exposes me to new music, half of which is local and the commercials really aren't that bad when they are from local businesses. That is my 2 cents, I would love to see a FM receiver. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM Radio
On 22 Aug 2007, at 22:37, D. Vicario wrote: To listen for streaming radio I MUST pay for the download, and the price of data isn't cheap... so, the FM module is the only way, for me, to listen radio. And I see very much use of it. FM is only worth doing if you can also use the FM circuitry for TMC to get realtime traffic information. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How about a slim Openmoko design?
I think by Slim Design = EDCability ( and currently lack of features) I may have *mistakenly* suggested that I would be happy with a compromise on features. No, quite on the contrary what I wanted to suggest was to have all the features in as small dense elegant package as possible. But, definitely not at the cost of removing features. Lack of features is what makes a phone boring after some time. Since the hardware is also open, I don't think it will be long before someone may actually come up with some interesting case designs. Looking forward On 8/23/07, Shawn Rutledge [EMAIL PROTECTED] wrote: I think less PDA is the wrong direction to go with this product. Future versions ought to be more iPhone-like in form factor (as slim as they can make it, and frameless or at least nearly, with a high ratio of screen real estate to overall size). As for hardware hacking, I doubt that most of us are going to be really changing out chips or soldering the board anyway... we just need schematics (for understanding) and easy access to JTAG. That can still be accomplished with a compact design. A lot of people say they want a plain old telephone without so many features, but it doesn't seem very interesting to me, and I'm not sure if they really want that either... or this idea just comes out of a frustration with current UI's. Such a phone could also be an open-source project, but it would tend to be completely different. E.g. there is no point in using Linux for that, when a simpler microcontroller with simpler all-in-one firmware would suffice. (And you would get incredible battery life with that approach, too.) I think a different company ought to try that, but there is no point in having the OpenMoko resources being spread thinner by trying to do both. For applications like web browsing and email and GPS navigation, you need as much screen real estate, resolution, memory and processing power as you can get. But the content itself is way more important than the eye candy. It's still good to simplify the UI as much as possible, but not by removing features. I don't actually talk to people that much; probably more of my minutes are used by GPRS than voice (or at least it will be that way, when I can get a phone on which browsing becomes more worthwhile than it has been on my A1200). So I'm one class of users. Then there are the professionals that do need to talk to a lot of people, and therefore contact management features are very important; but they also could make use of all the PDA and Internet features. The third class would be people who just use a phone for talking, some of them need it to be rugged, and they don't care about the other features (construction workers, plumbers and other service people, and people who are put off by ever having to learn anything new). A smart phone of any kind is not for them, and there is hardly any point in trying to adapt it to satisfy them, IMO. They are also not likely to care if it's open-source or not (because they don't need any applications - just a dialer and a contact list). On 8/21/07, Jørgen P. Tjernø [EMAIL PROTECTED] wrote: Perhaps not as much processing and features, but more of a phone, less of a PDA (actually, less of a Smartphone too?). In any case, I guess that'll be something we won't see until well beyond 2007. :-) ___ 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
T-Mobile, MyFav and OpenMoko
Hello, Do you know if MyFav, from T-mobile will work with OpenMoko ?? I am not sure because if you check the phone list on Tmobile web site, not all of them can handle it. What is the hardware/software needed to have MyFav working ? MyFav is a plan of T-Mobile, where you have 5 predifine number, that are unlimited in addition of some minutes plan Regards fey ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko API Documentation
Hi Michel Thanks for this information. Regards, Chetan Nanda - Bollywood, fun, friendship, sports and more. You name it, we have it.___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM Radio
On 8/22/07, Ian Stirling [EMAIL PROTECTED] wrote: NXP has a FM radio in a 2*3mm package that sits on the I2C bus and has 8 or so external components, to give you a complete FM radio. Some $3 IIRC for the device in quantity. (neglecting the fact that it can complicate EMI) Do you have a part number by any chance? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: T-Mobile, MyFav and OpenMoko
On 8/22/07, feydreva [EMAIL PROTECTED] wrote: Hello, Do you know if MyFav, from T-mobile will work with OpenMoko ?? I am not sure because if you check the phone list on Tmobile web site, not all of them can handle it. What is the hardware/software needed to have MyFav working ? This should still work, but you will require a plan that comes originally with a my faves phone to actually set up those numbers. The phone you buy (or get free as part of a contract) has special software inside that allows you to edit these 'faves' but i am under the impression that as soon as you switch your simcard from your tmobile branded phone to your Moko, the numbers you have listed will continue to be free. Please someone correct me if im wrong; I still haven't ported my number from Sprint yet :) Mike ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tinylogin: file can not be created! error on do_rootfs
Install the host package which provides the libXext library. The error message is pretty clear about that. -- Rod -Original Message- From: Jimmy McMillan [EMAIL PROTECTED] Date: Thursday, Aug 23, 2007 1:27 pm Subject: Re: tinylogin: file can not be created! error on do_rootfs Not to hi-jack your thread, but to rather put together build error threads, I'm having this build problem. Whilst making 2007.2 | make[1]: Entering directory `/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-src-4.3.0/src/tools/uic3' | g++ -fno-exceptions -Wl,-rpath,/home/mintee/moko/build/tmp/staging/i686-linux/qt4/lib -Wl,-rpath,/home/mintee/moko/build/tmp/staging/i686-linux/qt4/lib -o ../../../bin/uic3 .obj/release-static/customwidgetsinfo.o .obj/release-static/databaseinfo.o .obj/release-static/driver.o .obj/release-static/treewalker.o .obj/release-static/ui4.o .obj/release-static/uic.o .obj/release-static/validator.o .obj/release-static/cppextractimages.o .obj/release-static/cppwritedeclaration.o .obj/release-static/cppwriteicondata.o .obj/release-static/cppwriteicondeclaration.o .obj/release-static/cppwriteiconinitialization.o .obj/release-static/cppwriteincludes.o .obj/release-static/cppwriteinitialization.o .obj/release-static/main.o .obj/release-static/ui3reader.o .obj/release-static/parser.o .obj/release-static/domtool.o .obj/release-static/object.o .obj/release-static/subclassing.o .obj/release-static/form.o .obj/release-static/converter.o .obj/release-static/widgetinfo.o .obj/release-static/embed.o .obj/release-static/qt3to4.o .obj/release-static/deps.o -L/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-s rc-4.3.0/lib -lQt3Support -L/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-src-4.3.0/lib -lQtSql -pthread -L/home/mintee/moko/build/tmp/staging/i686-linux/lib -pthread -pthread -pthread -pthread -pthread -pthread -pthread -L/usr/X11R6/lib -pthread -pthread -pthread -pthread -lQtNetwork -pthread -pthread -pthread -pthread -pthread -pthread -lQtXml -pthread -pthread -lQtGui -pthread -pthread -lXext -lX11 -lQtCore -lz -lm -pthread -lgthread-2.0 -lglib-2.0 -lrt -ldl -lpthread | /usr/bin/ld: cannot find -lXext | collect2: ld returned 1 exit status | make[1]: *** [../../../bin/uic3] Error 1 | make[1]: Leaving directory `/home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/qt-x11-opensource-src-4.3.0/src/tools/uic3' | FATAL: oe_runmake failed NOTE: Task failed: /home/mintee/moko/build/tmp/work/i686-linux/uicmoc4-native-4.3.0-r2/temp/log.do_compile.12505 NOTE: package uicmoc4-native-4.3.0-r2: task do_compile: failed ERROR: TaskFailed event exception, aborting NOTE: package uicmoc4-native-4.3.0: failed ERROR: Build of /home/mintee/moko/openembedded/packages/uicmoc/uicmoc4-native_4.3.0.bb do_compile failed ERROR: Task 2696 (/home/mintee/moko/openembedded/packages/uicmoc/uicmoc4-native_4.3.0.bb, do_compile) failed NOTE: Tasks Summary: Attempted 1394 tasks of which 1384 didn't need to be rerun and 1 failed. ERROR: '/home/mintee/moko/openembedded/packages/uicmoc/uicmoc4-native_4.3.0.bb' failed make: *** [openmoko-devel-image] Error 1 On Wed, 2007-08-22 at 14:11 -0700, Myk Melez wrote: I'm trying to build OpenMoko using mokomakefile on Ubuntu 7.04 (Feisty Fawn), and it's dying with the following error: NOTE: Running task 3401 of 3403 (ID: 4, /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) NOTE: package openmoko-devel-image-1.0: started NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: started ERROR: function do_rootfs failed ERROR: log data follows (/home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849) | + rm -rf /home/myk/Projects/moko/build/tmp/rootfs | + '[' 0 '!=' 1 ']' | + mkdir -p /home/myk/Projects/moko/build/tmp/rootfs/dev | + for devtable in /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | + makedevs -r /home/myk/Projects/moko/build/tmp/rootfs -D /home/myk/Projects/moko/openembedded/files/device_table-minimal.txt | makedevs: /home/myk/Projects/moko/build/tmp/rootfs/bin/tinylogin: file can not be created! NOTE: Task failed: /home/myk/Projects/moko/build/tmp/work/fic-gta01-angstrom-linux-gnueabi/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.4849 NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed ERROR: TaskFailed event exception, aborting NOTE: package openmoko-devel-image-1.0: failed ERROR: Build of /home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb do_rootfs failed ERROR: Task 4 (/home/myk/Projects/moko/openembedded/packages/images/openmoko-devel-image.bb, do_rootfs) failed NOTE: Tasks Summary: Attempted 3400 tasks of which 0 didn't need to be rerun and 1 failed. ERROR:
Re: tinylogin: file can not be created! error on do_rootfs
Dnia środa, 22 sierpnia 2007, Myk Melez napisał: Does anyone know what the problem might be and how to resolve it? mtn pull;mtn update in OE metadata directory. -- JID: hrw-jabber.org OpenEmbedded developer/consultant Could you please speak more slowly? I'm a masochist and I want to prolong the agony of this conversation. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
