Re: Community Updates/February 6, 2009 released
Hi, There was no reason to react so. Brenda just forgot to mention the work team. I think we all know that X.org is not done by Openmoko. ok, let me update you on that: In the last 2 months OM hired 2 developers to work full time on X.org (Juan + Jorge). Yes, it took a while to find these people. Unfortunately, X.org developers are not that easy to find and being a small company means to prioritize. In addition, OM handed out access to the documentation to a couple of people that were willing to sign the NDA. We are happy to see that they join the effort and about the progress of the whole team. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
meeting in Braunschweig
Hi, yesterday, we (Mickey, Daniel, Jan, Stefan, Ray and me) sat together in Braunschweig to discuss the next steps regarding the builds / images / feeds / 2.6.28 / etc. Here is the summary of the outcome: = latest / experimental package feed * This feed contains the latest version (autorev) of specific packages such as the framework, paroli, others? for developers. * Ray will decide what name is going to be used for this feed. = unstable images / package feed * All necessary build information come from OE upstream except for a few minor customization as repository URLs, additional packages, etc but no autorev. * Images is built only with a release of a new FSO milestone which will be tagged in the OE tree. Packages are built every day and offered via the feed. = testing images / packages feed * At some point prior to the release (e.g. 2 months) the testing branch forks from OE. It will contain Openmoko customizations and cherry picked fixes from upstream. * Until then the current testing builds will be suspended. = stable images / packages feed * Once the testing branch is bug free enough it will be declared stable. Maintenance fixes can go into this branch. = build location * Ray needs to find a workable compromise for all parties involved (building in Taipeh or in a data center). = build frontend * Outside parties want to know the status of the builds / versions / build errors. * Ray tries to get familiar with oestats / tinderbox. In the first step he will upload our build information to http://tinderbox.openembedded.net until he configured an oestats machine. = 2.6.28 * Framework already supports both kernels (.24 .28). * Next FSO milestone will come with support for both kernels. If .28 proves to be stable enough in the coming weeks .24 support may be removed immediately. = misc: * Remove OM bitbake (features went upstream according to Holger). * Ray will write a detailed announcement to explain how to get $your_package included in the OM repositories as OM is going to shutdown the (binary only) community repository. * Future releases will use a distro-update package to update the machines of the existing user base. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/30 ~ 12/06)
On Tuesday 09 December 2008 20:52:13 Gothnet wrote: OM is moving more focus to gta03 now, so my current resource for qtopia is fairly limited. I know it's important for OM to keep moving forward, but really, focusing on gta03? Already? It's been a few months since GTA02 went GA and we still don't really have a working system, focusing most effort on GTA03 now seems to be an abandonment of freerunner owners. I think there are some misunderstandings that need to be addressed: - Yes, our focus is shifting from Qtopia towards FSO / paroli / python. This happens gradually. - This has nothing todo with GTA0x - we are talking about software which will run across all devices. - We don't abandon the Freerunner. Furthermore it serves as our development platform as GTA03 does not come around any time soon. Its at an early stage of development (even internal developers don't have it). - We want to get the software into a much better shape to avoid the 02 experience. Sorry for the confusion, Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.x] Settings app not working
On Wednesday 19 November 2008 22:29:58 Ivar Mossin wrote: So... What would have been the preverred way of figuring which packages I would need to install? Is there a list somewhere on the net/wiki/anywhere else? Are there some meta-packages I could have installed instead, like 'opkg install phone-software' ? For this purpose we have meta packages (packages beginning with task-*). I believe for Qtopia on X11 it was: opkg install task-openmoko-qtopia-x11 But my conclusion seems to be that the settings app is working (although not scrolling) using a clean testing image. However, installing a stable image, then upgrading to testing by changing the opkg repository links, the settings application breaks. Even when doing it from a clean stable image. So I guess there is a bug that has to be addressed there to avoid the package conflict or whatever it is causing the breakage. Thanks for reporting this. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.x] Settings app not working
On Tuesday 18 November 2008 01:40:42 Ivar Mossin wrote: November 1st I upgraded from 2008.9 stable to 2008.x testing, using opkg update opkg upgrade. This broke the settings applications which no longer starts. I have just now updated and upgraded again to see if there would be a fix in the repository without any luck. May be the upgrade path is broken ? Did you try to install the latest testing image ? If that does not help we can reopen the bug ... Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Please add me to the planet
On Saturday, 20. September 2008 08:52:14 Rui Miguel Silva Seabra wrote: If you could please add my openmoko articles to the planet, I'd be pretty much grateful. http://blog.1407.org/tag/openmoko/feed Best would be you open a bug at http://admin-trac.openmoko.org/ Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing 20080901 first steps to 2008.09??
On Monday, 1. September 2008 18:22:56 David Samblas wrote: Inspite the it's really barebones, I have seen very interestings things by default, the raster ilume pack: qwerty on/off button the illume keyboard (oh Yes! :) ) illume configuration the backgound image is pretty zen and beatifull and screen dims smothly. These bugs are coming from OE upstream which is currently merged into the base image. Our distro team has a hard time fixing these. Openmoko does not want to force you into something - you should have the choice. Of course it's not functional at all because it has no apps but settings (that doesn't work for me), and I was unnable to ssh to it so I was no able to not further testing, but doesn't matter because is clear is a proof-of concept release. I will wait for the next test release (maybe tomorrow?, it's a really dayly?) It is a daily snapshot of the base / empty image. The fact that it is empy is not a bug but a feature. You should install your applications of choice, e.g. keyboard: illume/qtopia/dasher/$whatever_you_come_up_with, phone apps: GTK, Qtopia, FSO, $whatever Again, many bugs from OE upstream entered that image which we have to fix now. My question is , I can assume the good things mentioned avobe will be mantained in the oficial (semi-stable) 2008.09 release? This wont be the 2008.9 release because it is too buggy. The 2008.9 will focus on stabilizing 2008.8. Have you decide the date off that 2008.09 release? Our QA team gave us a list of bugs we have to fix prior to the release. We have to fix them first and then release. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mokomakefile
On Saturday, 30. August 2008 14:08:48 Rod Whitby wrote: I'm still waiting for Openmoko to decide which branch they are using, so I can advise people how to build Om2008.8 properly using MokoMakefile. The decision is made. Julian tried to explain it before but I can try it again: It used to be org.openmoko.asu.stable, but then someone from openmoko said they were going to concentrate on org.openmoko.dev instead. org.openmoko.asu.stable is the current stable branch on which we base our releases. We will continue to provide updates/fixes to make it work more reliably. This way of releasing is too static and too hard to tweak. Therefore we started a new way of releasing - the base / empty image style that is coming out of org.openmoko.dev. It wont have other aplications preinstalled other than settings and installer. Everyone can create his dream phone. Many things have to be merged and reorganized, so that it is work in progress. Once it proves to be stablized it will become our new stable. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mokomakefile
On Saturday, 30. August 2008 15:17:35 Rod Whitby wrote: OK, can you describe *exactly* how you built that released image and how you build those updates/fixes, so that others can replicate. 1) Git repo site 2) Git repo URL 3) Git repo branch 4) DISTRO setting (assume openmoko, but please confirm) 5) MACHINE setting (assume om-gta02, but please confirm) 6) whether moko-autorev and/or fso-autorev is included 7) The OS on which the image and updates are built 8) The set of host OS packages installed on the machine on which the image and updates are built. This should be answered by Julian or Graeme. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Feeds for testing packages
On Friday, 29. August 2008 13:31:57 Jean-Eric Cuendet wrote: Could someone explain me what's the diff between: http://buildhost.openmoko.org/daily-feed/all/ buildhost should be ignored as all official builds / packets are published on downloads. Our admin team is working on the shutdown of buildhost: http://admin-trac.openmoko.org/trac/ticket/1524 Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Repository and Images
On Wednesday, 27. August 2008 17:08:34 Al Johnson wrote: Sounds good so long as the packaging stops people accidentally breaking things just by installing a package. The problem installing 2 diallers is a recent example where it didn't work. Also how will it handle the situation where different frameworks use differently patched versions of the same app? Tangogps springs to mind as an example that seems to be slightly different on GTK, FSO and ASU. Obviously, you will be able to install 2 dialers if the dialers support that. If not I suggest to add necessary dependencies tp the packages. Don't consider this as something we completely designed and intend to push over you. Feel free to make suggestions. I see this approach as a chance to combine the different efforts on a single platform with the maximal user experience. Instead of this feature is working on image X but not on image Y which has feature Z running, etc. Is the mechanism for this in place, or still a work in progress? Are there any details available on how to use it? Get in touch with our distro team to include your project. You can accelerate the process by providing a working bb file. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Repository and Images
On Wednesday, 27. August 2008 22:27:37 Rod Whitby wrote: Will you be autobuilding from the OE git repository or the OM git repository? AFAIK it is based is a OM git repository that closely syncs with OE git. Julian and/or Graeme can give details about that. If the latter, will non-Openmoko staff have commit rights? If not, then we will still need autobuilders for the community distributions, since there is no automatic syncing from repositories with community commit rights to the Openmoko repository as far as I am aware. We want to let the community join and give commit rights to individuals. In the OpenWRT world they are able to give commit rights to single packages but they use SVN. Is that possible with git as well ? Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 update
On Tuesday, 26. August 2008 16:31:45 Jelle De Loecker wrote: Well, look at those filenames: 20080826-asu-stable-rootfs.jffs2 http://downloads.openmoko.org/releases/Om2008.8-update/20080826-asu-stable -rootfs.jffs2 It's a filename which actually makes sense! Anyhow, I installed the 20080808 image a few days ago and upgraded with Zecke's repository and my phone is running really smooth, I'm afraid to make any changes to it. I don't even dare to do an opkg upgrade! :) This is the official update for ASU (including Holgers fixes). An announcement and install instruction will follow soon. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 update
On Tuesday, 26. August 2008 17:34:40 Yorick Moko wrote: Seriously, I appreciate all your efforts, but some things I just can't grasp: Why would any sane man remove items that provide useful functionality (the wrench, full qwerty) without providing an alternative?? You guys know a lot of us want the full qwerty, and there are already very nice implementations (look at the raster-image) and you guys know that we will try to get it back; why not give us the choice?? The button to toggle from the original keyboard to the full qwerty one was perfect. Or just add an way to install it through the installer. Just like you know we want a terminal, and have added that to the installer. Seriously, we can't you make your homework and find out yourself that there _is_ a package to give you that button. Its called illume-config (not to hard to guess) and installable via the installer. Why not simply using that choice before ranting like mad ? Next time, you also can do a package yourself - we happily include it. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 update
On Tuesday, 26. August 2008 18:07:25 Yorick Moko wrote: Marek, installing that illume-config package was the first thing I did yesterday. It only gives the qwerty button in the upper left corner. I have not found a way to enable the spanner. It should do both (as the description indicates). Please open a bug in our trac if it does not work as expected. My apologies if I have offended you. I just want to understand why some good things were being left out at this stage. If you would give the reason to not use the keyboard like in the raster-image (or excluding the full-qwerty.kbd) at this point it would help me very much in understanding it. No offense taken. I simply would prefer a more reasonable feedback that we can process. General speaking, we don't want to exclude anything. To provide maximum flexibility and freedom we want to move everything to packages. The raster keyboard, the button, $whatever can be put into a package and shared with the world. There is no need to wait for anyone (including Openmoko) to do that for you. Just get your hands dirty and help increasing the choice. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is Neo1973 truly abandoned?
On Friday, 15. August 2008 02:03:43 John Locke wrote: How many GTA01s did you sell? Gotta be a few thousand. I'm sure we all bought them assuming *someday* we'd have a usable phone. Right now, I have a usable GPS, thanks to TangoGPS, other than the fact that the battery dies before I finish most of my hikes (making it useless as a GPS, too, other than for novelty value). Currently we are wokring on a major infrastructure change (debian style package management) which will enable us to port Om 2008.8 to GTA01. Once this shift to the new style has been completed we wont have the perfect GTA01 support yet but we are moving towards that direction. You can support that by helping us later on. We have enough GTA01 lovers within Openmoko itself, so that it wont be forgotten. :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ahah: and you released anyway ? - Re: [ Software Testing Report : 2008.08.07 ]
On Wednesday, 13. August 2008 18:02:35 Michele Renda wrote: People like you bring firms to have a close development process. Following our new trac culture: +1 Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Om 2008.8 Release
Hi, by the way, is uboot file necessary ? I think it would be nice to have everything in one place. :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Thursday, 31. July 2008 05:24:45 Josh Monson wrote: Or is Sean saying that this would be an option if it was in the form of a package, so if the package was built (by the community) then you would have the choice to toggle or not to toggle? I am assuming that functionality was removed so that it can be an installable option and not a default. Bingo ! :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
Hi, At the same time we heard comments from a key developer who indicated that the decision was made above him by unnamed individuals with whom the community has no obvious means of communication, and who apparently don't even listen to the reasonable technical arguments of key developers. Openmoko always avoided all kind of formal structures. Thus we don't have such a thing as key or core developer - a developer would be better. This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. May be it revealed that Openmoko itself is diverse as well. That some developers have different opinions than others. It was this incident with the keyboard that made several people believe option (2) was not available, and even after Sean's message, I still don't believe that we know the answer. So, I'll ask again: does Openmoko intend to allow direct code contributions by community members to core components of the ASU/FSO frameworks? If so, will such community members also have a voice in underlying design decisions that guide that/those framework(s)? if course you can - that is the whole point of Openmoko. The best way is to implement a solution, offer a package to install and let the people play with it. If your idea is convincing we will include it. Openmoko has to trust those members of the community, who prove themselves through actual contributions, to be worthy to give input on larger design issues as well. You got the point ! Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tuesday, 29. July 2008 19:19:10 Al Johnson wrote: Whether the term is 'key developer' or just 'a developer' is irrelevant. The issue is the total lack of communication over removal of a function many in the community, not to mention said developer, have good technical reasons to see as absolutely vital. Unfortunately, this tiny difference is important because it sounded like Even THE key developer (and god knows who else) objected and still you did it!. Diversity of opinion is fine and expected, but we needed to hear what the other opinions were! True, and you did hear it. I thought that was the whole point too, but your answer seems only to answer one of the two questions. You seem to be saying 'Of course you can submit code, and if we like it we'll use it' but saying nothing about whether the community has a voice in the decision. It would be helpful to know before embarking on implementation whether the idea conflicts with one or more of the unstated ideals by which inclusion may be judged. You should realize that we (Openmoko) are vastly outnumbered by the tasks on our ToDo list and the mails we have to process. For us it is very hard to grep out the genius and doable ideas - it is just too much ! But if you can provide a working prototype of your idea you can be sure that we seriously look at it. We simply install it, play with it and eventually get infected by it. In the end we are geeks as well and like to see cool stuff. :-) I think so, but I think the rest of the paragraph, particularly the preceding sentence, was at least as important. Since you snipped it I'm not sure you feel the same way. Do you mean that sentence: we are paid by openmoko to do what we are told to do by the design department and that is what we then do. If that's the state of things for paid developers, then community contributors have even less hope. Again, this is the statement from a single developer - I _definitely_ don't agree with that. This is simply not the way it is. Honestly, I have never seen a company that gives so much freedom to its employees. Sometimes I even have the feeling this is more a democracy instead of a business here. :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Tuesday, 29. July 2008 20:17:00 Chris Wright wrote: But you do have a design team, according to Rasterman. Of course we have. How do you think we are trying to get to a device that is ready for end user ? And this is just the beginning. We will work with more designers for the UI, the housing, etc to continue the direction towards the mass market. But that does not mean all that is perfect right from the beginning or that we don't listen to constructive criticism. Please help us making it better by _demonstrating_ a superior solution not by sending more emails. Out of curiosity, how many of these developers use an Openmoko phone as their primary phone? What do you mean with these developers ? Everybody certainly has a different opinion than others on something. Do these differences of opinion tend to fall on the same boundaries? I don't get what you trying to say here. Still, nobody has mentioned why the design team can't be contacted or identified. Sorry but this is just not true. I don't get why you follow this childish witch-hunt game. Strange, I read this as Openmoko has not been, but should in the future, trust those members I haven't been here long enough to determine which is the case. Maybe the company hasn't, either. Meant was: Openmoko pays much more attention to installable solutions and listens to hackers that provide those instead to people that complain all day long but don't get their hands dirty. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wednesday, 30. July 2008 04:57:27 Chris Wright wrote: Where I work, the design team is the same as the development team. May I ask where you work and what kind of consumer products you are creating ? Something as simple as a keyboard button -- well, users were complaining about its lack very quickly. If the design team were also users, then they would have insisted that the error be fixed. They _are_ users and kept complaining all the time why we have to push the damn button. The software should know that we want to type something. Yes, they are no engineers but I try to see that as a plus not a burden. Their perception is to have software that gets invisible while enabling the user to get the real job done and not the other way round. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: More info on on ticket #666 SIM Card problems.
On Wednesday, 30. July 2008 08:15:52 Adam Talbot wrote: There is a new bit of debug on ticket: http://docs.openmoko.org/trac/ticket/666 I am not sure if this is the right place to send this, but here is my out put. Please inform the devel or support list about your results. Also, it may be better if you attach the log file to the bug itself. That way we collect all the data in a central place. Thanks for digging into that, Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU - opkg upgrade - is it possible to exclude some packages?
On Wednesday, 30. July 2008 06:13:02 Torfinn Ingolfsen wrote: After an 'opkg update' today, I did a 'opkg -test upgrade'. And opkg still wants to install a Neo1973 kernel on my FreeRunner: Is there a way to tell 'opkg upgrade' to upgrade everything except the kernel? Please open a bug report for such issues (don't forget to check for duplicates first): https://docs.openmoko.org/ Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
On Wednesday, 30. July 2008 10:18:33 Al Johnson wrote: I agree with everything you say here. The keyboard should just appear when I want it and disappear when I don't. The absence of a manual override means that whenever it gets it wrong I can't correct it, the worst case being when I need to enter something but the keyboard doesn't appear. Conversely the presence of a manual override causes no problem even if it is never needed. The keyboard failing to appear is not a hypothetical scenario. Without manual intervention minimo was unusable because the keyboard didn't appear when the cursor was placed for URL entry. This is likely to be an issue with other apps that don't have a specific openmoko port, and we shouldn't have to create such a port just to use an otherwise capable app on openmoko. Other issues include the keyboard appearing when an edit field has focus although I don't want to edit it, keyboard appearing and disappearing frequently if a form contains mixed input types, or appearing over the top of the field to be edited. The field having focus although editing is not required is probably impossible to detect because the answer depends on the opinion of the user at the time. I understand your points and they all are valid. How do we address them ? That brings us back to Seans mail. Openmoko will provide the minimum set of applications and basic functionality that empowers ordinary users to use the phone. We will make sure that these applications work well with the environment we provide. This is an ongoing process we just started compared to many established phone systems. Feel invited to extend that basic system through packages that can be installed. If you install an application that hasn't been ported to the Openmoko platform and does not support the keyboard you also should install the manual keyboard button or you just install a package which deativates the automatic keyboard behaviour right away if you don't like it. We have to realize that the world is very diverse - we wont find a solution which suits for everybody in all the cases. So, we have to make it flexible. Again: This is a process and you can help us with that. Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Public build host (proposal)
Hi, since it seems to be extremely difficult to build software for the OpenMoko on my home machine, perhaps it would be usefull if someone (within OpenMoko?) would set up a globally reachable build host with an openembedded and toolchain environment on it. could you describe what kind of problems you experience ? The only way to improve the situation is by naming the issues at hand. :-) Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki editors
On Thursday, 17. July 2008 20:34:40 digger vermont wrote: - Mailing list fit into the Western style of communication not in the Eastern style. I'm curious, what would be the Eastern style? Eastern people try to avoid all public discussions for various reasons: - They don't want make other people loose their face. - They are educated not no say what they think. - They are afraid that they get fired (Openmoko one of the few exceptions here). - Often they have the feeling that their supervisor should make the decision and not them. So they wait in front of the problem, ignore it and hope it goes away. In contrast to that rumors and guessing is very popular here. :-) Marek PS: All that is a bit extreme but should you give a feeling. ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki editors
On Thursday, 17. July 2008 08:25:54 Torfinn Ingolfsen wrote: BTW, has anyone asked Brenda if she wants in on this? And have time for it? Happy to see that you bring that point up. I had a long and healthy discussion with her. The bottom line is: - She really appreciates your wish to help and gladly accepts it. - Mailing list fit into the Western style of communication not in the Eastern style. - Next to the cultural difference a flood of mails in English is a problem. A list would be less an issue if the list language would be Chinese or any other similar language as Japanese, Hongkongnese, etc (which is not realistic but should show the point). ;-) - Probably she will read the list but never post anything unless you directly address her (again cultural differences). My suggestion: Create your favorite communication channel. She probably will follow it but not become an active part in it. Once you have finishd your discussion send the result to her directly. We still try to help the Eastern people to understand and accept Western behaviour. That needs time. Meanwhile try to understand and support them. Greetings, Marek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
