Rod Whitby (MokoMakefile author) moves on to start WebOS Internals
http://www.rwhitby.net/blog/webos-internals/palm-pre-lands-in-australia.html It is with some sadness that I must say goodbye to the OpenMoko community, and move on to new things. My dream of an OpenMoko phone with a hardware keyboard to replace my aging Treo 650 was never realised, and you all know the rest of the story on the software side of things. I've now started a new community (webos-internals.org) which does open source Linux-based development for the Palm Pre. My hope is that freesmartphone.org may one day be the bridge between the OpenMoko community I am now leaving, and the WebOS Internals community which has recently started. I wish everyone continuing down the OpenMoko path the best of success in the future. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzz on GTA02v5 with latest SHR-Testing, do I need buzz fix ?
Denis Johnson wrote: Currently running SHR Testing from around 22 April, on my GTA02V5 in Australia. While on a mobile to mobile call, the other party complained about buzzing. 1. Could someone please confirm that this is the hardware caused buzzing problem and not related to the distro or alsa state settings. 2. Are there any users in Australia with same batch (original group purchase via Perth/Brisbane) which also have the issue and have managed to get it corrected or have access to someone that can do the fix in Aus ? I have about 8 sets of buzz fix parts from OpenMoko, and have previously (on the oz-moko list) said I'd send those parts to anyone who can fix devices in Australia. I haven't heard from anyone yet. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Autobuilder
Angus Ainslie wrote: The Openmoko autobuilder is back online. It is generating images for gta01 and gta02 devices. ... For those interested in improving or commenting on the build scripts used to generate the unstable and experimental images they can be found here: http://downloads.openmoko.org/build/ Thanks Angus - this is a huge leap forward for Openmoko with regards to autobuilder configuration transparency and management. Well done! I'll update MokoMakefile to match your build description. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FSO Milestone5 feeds fixed (Was: Milestone V blkid installation prob)
Rod Whitby wrote: qhaz wrote: Hi, does anyone else get this error message when udate/upgrade on milestone 5 installation? Upgrading busybox on root from 1.13.2-r5 to 1.13.2-r9... Downloading http://downloads.freesmartphone.org/fso-milestone5/feeds//armv4t/busybox_1.13.2-r9_armv4t.ipk Collected errors: * Package busybox wants to install file /sbin/blkid But that file is already provided by package * e2fsprogs-blkid There is a problem with the milestone5 feed. It is being regenerated (will take some time). Best not to opkg upgrade in the meantime. The feeds have now been fixed. The only package upgrade you should see now is angstrom-version, until fixes start being back-ported to the fso/milestone5 branch for other packages. Unfortunately, if you have opkg upgraded against the broken milestone5 feeds before now, you will probably need to reflash the image to get to a stable state. The autobuilder is now building the feeds correctly, and any commits to the fso/milestone5 branch will appear in the feeds automatically. There are 7696 unique packages in the feeds for FSO milestone5. You can always check the progress of the autobuilder at: http://tinderbox.openembedded.net/builders/milesto...@freesmartphone.org/ The following packages from task-openmoko-feed are currently unbuildable: free42-vga, gnash, evince, devmem2, font-adobe-utopia-type1, font-bh-ttf, font-bh-type1, font-bitstream-type1, font-ibm-type1, font-misc-ethiopic, font-misc-meltho, font-xfree86-type1, ewl, ruby-native and libgnomeprintui. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Milestone V blkid installation prob
qhaz wrote: Hi, does anyone else get this error message when udate/upgrade on milestone 5 installation? Upgrading busybox on root from 1.13.2-r5 to 1.13.2-r9... Downloading http://downloads.freesmartphone.org/fso-milestone5/feeds//armv4t/busybox_1.13.2-r9_armv4t.ipk Collected errors: * Package busybox wants to install file /sbin/blkid But that file is already provided by package * e2fsprogs-blkid There is a problem with the milestone5 feed. It is being regenerated (will take some time). Best not to opkg upgrade in the meantime. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freesmartphone.org down? DNS?
Pablo Ruiz Múzquiz wrote: Thanks! though downloads.freesmartphone.org redirects to www.f...org and a beautiful 404 appears :-( downloads.freesmartphone.org is on a different server (140.211.169.169). -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
I have owned the android-internals.org and android-linux.org domains since last year, waiting for this day, and the former has a wiki already set up and available to be used for porting information (dunno whether Openmoko would or would not want Android porting info on wiki.openmoko.org ...). -- Rod -Original Message- From: Jim Morris [EMAIL PROTECTED] Date: Wednesday, Oct 22, 2008 6:43 am Subject: Re: Android open sourced To: List for Openmoko community discussion community@lists.openmoko.orgReply-To: [EMAIL PROTECTED], List for Openmoko community discussioncommunity@lists.openmoko.org Cédric Berger wrote: Here we are http://google-opensource.blogspot.com/2008/10/android-open-source-cell-phone.html time to port to Neo ! Maybe we should setup a Neo branch on Androids GIT, and start to collaborate on the port? Anyone else interested? -- Jim Morris, http://blog.wolfman.com ___ 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: [FSO] makefile - openembedded git repository not working
Previdi Roberto wrote: hello, it's some days (4-5) that i am not able to update the fso tree. OE moved from a trial git server to a production git server, and the git repository location changed as a result. I forgot to update the FSO makefile to match. when i give make update i get this errors: [EMAIL PROTECTED] ~/openmoko/fso2 $ make update ( cd common ; git pull ) Already up-to-date. ( cd bitbake ; svn up ) At revision 1108. ( cd openembedded ; git pull ) fatal: The remote end hung up unexpectedly make: *** [update-openembedded] Error 1 even if i remove the openembedded folder (move it somewhere) it doesn't work. what should i do? should i change the repository? and how? 1) make update-common 2) Remove the openembedded folder (not your build folder) 3) make setup-openembedded That should fix it for you. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing http://www.opkg.org
Robin Paulson wrote: 2008/10/12 Tobias Kündig [EMAIL PROTECTED]: It's a simple database of available *.ipk-Packages. great stuff, found some interesting things there already would you be interested in turning it into a true repository? with an entry for the .conf file for opkg? It really is a sad commentary on the state of official Openmoko repositories that this question is even asked. The state of affairs *should* be that you just get the application name from opkg.org, and then type opkg install name on whatever distribution you are running (or select the application name from the GUI installer application on the device) and it installs flawlessly from the official feeds for that distribution. Have we all given up on that scenario (which is commonplace in other community projects) and must resort to even more third-party repositories which do nothing more than mirror bits and pieces of all the existing disparate repositories? Please, let's make this the best site for *finding* new applications and deciding which ones to install, but hook it into the existing repositories and improve them instead of creating yet more repositories to confuse people, become out of date, and cause upgrade nightmares when they are not consistent with the base images ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Example of community manager job role Was: Re: FBReader now working on the FreeRunner
Stroller wrote: On 12 Oct 2008, at 20:55, Rod Whitby wrote: If Openmoko had a community manager, that person would contact Michael directly and: 1) Invite Michael to get commit privs and commit this patch himself directly to the OM repo. This may include teaching about how it all works. Is it possible to give Michael commit privs for only this package, though? One surely wouldn't want to give them to a community member on the basis of a single GUI app and later find he has b0rked the whole kernel tree. In four years of running a project with a very low commit barrier, I've never had a single problem. And configuration management systems are designed to be able to remove an errant version, so even in the remote case that it does happen it's trivial to detect (since lots of people watch each and every commit) and fix. If you give people guidance on what they should and should not modify, then you will find that they follow those guidelines. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing http://www.opkg.org
Stroller wrote: On 13 Oct 2008, at 08:13, Rod Whitby wrote: ... The state of affairs *should* be that you just get the application name from opkg.org, and then type opkg install name on whatever distribution you are running (or select the application name from the GUI installer application on the device) and it installs flawlessly from the official feeds for that distribution. That requires exiting the web-browser using the CLI. Aren't people asking for immediate installation through the GUI of the browser? OK, add ... or click on the link to run the normal GUI application installer which already points to the official repositories to the above. The point is not how convenient it is, since you can easily fix that in one place. The point is how disparate and fragmented the community resources become if you don't continuously fight against entropy. Diversity driven by well-informed intention is good. Fragmentation caused by barriers or simply entropy is not. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing http://www.opkg.org
Tobias Kündig wrote: I'm proud to announce my newest project: http://www.opkg.org It's a simple database of available *.ipk-Packages. I don't want to rain on your parade, cause it's a great service you've set up, but the problem is that .ipk (and now .opk) is used for *many* more different embedded devices than the Openmoko phones. So your domain name may be just a bit too general :-) But hey, you got the domain first, so you get to choose how to use it. So, can I add .ipks for the nslu2 or the wrt54g or the zaurus or the Treo 650 to your database? -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Wolfgang Spraul wrote: Rod, It seems that access was granted sometime between then and now oh great, I'm happy to hear that. Maybe we don't talk about it enough publicly: We have an 'admin trac' issue tracker, that _EVERYBODY_ can use to send requests to the Openmoko admins. This is a public resource, same as pretty much everything else in the Openmoko project: http://admin-trac.openmoko.org/trac Ah, now I see what happened. I did raise a ticket in the admin-trac, and since we use Trac a lot at my work and in the nslu2-linux project, I expected it to send me email on ticket state changes. It didn't, so I assumed nothing had happened (my incorrect assumption). BTW, I can show you guys how to set up Trac so that you can issue all the developers an SSL client certificate (which you can use in a lot of places instead of username and password) and it automatically logs them into trac using their email address so they automatically get emails when the tickets change state ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2/3: What people want Openmoko to do?
Wolfgang Spraul wrote: Openmoko — how many are subscribed to your email lists? announce: 11187 community: 2240 devel: 1218 I'm surprised that the community and devel numbers are so low considering it is almost 2 years since launch (for a data point, the nslu2-linux project grew to 9000 members on the community list in two years after project start, peaked to 12000 after 3 years and still has 1 after four years). One needs to wonder why the respectable announce list numbers haven't been converted into respectable community and devel list numbers ... Surely you've sold many more than 5000 devices (supposedly mainly to developers) - how come all those people are not on the mailing lists? It would be very interesting to see the graph of mailing list member numbers over time and whether it has just not grown very much since the launch or whether it grew significantly and has shrunk since. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FBReader now working on the FreeRunner
If Openmoko had a community manager, that person would contact Michael directly and: 1) Invite Michael to get commit privs and commit this patch himself directly to the OM repo. This may include teaching about how it all works. or 2) Grab the patch, add it to the repo themselves (if Michael is not keen to become a full developer) and 3) Make sure the autobuilders for all the different distributions build this package and put it in the official feeds. 4) Add the entry to opk.org Then all Openmoko users would benefit from Michael's work, and hopefully Michael would accept the offer of commit access (and access to do everything else above for himself) and be able to port many more applications for Openmoko without needing the intervention of the community manager in the future. -- Rod -Original Message- From: Michael Sheldon [EMAIL PROTECTED] Date: Monday, Oct 13, 2008 5:55 am Subject: FBReader now working on the FreeRunner To: List for Openmoko community discussion community@lists.openmoko.orgReply-To: List for Openmoko community discussion community@lists.openmoko.org Hi all, Ive just spent the day hacking on FBReader to make it work correctly under OpenMoko (OM2008.*). Until now its been pretty much unusable due to the GPE version of FBReader expecting you to be using a device that has some physical buttons which then get bound to vital functions like turning the page. The changes Ive made are as follows: * Add scroll forward/backward buttons to the toolbar * Add fullscreen mode button to the toolbar (doesnt have an icon at the moment, its the third button from the right) * Change fullscreen mode so that it doesnt hide the toolbar (otherwise theres no way to get back from fullscreen mode) * Switch to using the much prettier blue tango icons * Make the line separation larger so the text doesnt overlap * Reduce the font size * Change the default colours to match openmokos colour scheme better (and so its a little easier on the eyes) And most importantly * Make it so that tapping the sides of the screen turns the books pages (left = backwards, right = forwards) Heres a screenshot of what it used to look like: http://blog.mikeasoft.com/wp-content/uploads/2008/10/fbreader-orig.png And what it looks like with my patches: http://blog.mikeasoft.com/wp-content/uploads/2008/10/fbreader-openmoko.png To install it simply run: opkg install http://mikeasoft.com/~mike/openmoko/enca_1.9-r3_armv4t.ipk http://mikeasoft.com/~mike/openmoko/fbreader_0.8.2a-r6+elleopatches_om-gta02.ipk (all on one line) For those interested the patch can also be downloaded from http://mikeasoft.com/~mike/openmoko/fbreader-openmoko.patch. Bonus points for anyone who knows what book Im testing it with in the screenshots (without googling) ;). Cheers, Mike. ___ 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
Example of community manager job role (Was: FBReader now working on the FreeRunner)
Kosa, I can't understand how you took my mail to be a flame? (Apologies for not changing the title - I've rectified that now). What I was trying to do was to point out with a real example what Steve was asking for - what would a community manager do to bring one more very effective developer into the fold - e.g. working inside the openmoko framework in a way that incrementally builds on existing openmoko developer resources rather than needing to have packages that are patched versions of packages in the existing openmoko source base but due to not having commit privs end up being totally disconnected from that source base, autobuilder and official feeds. If the below 4 steps were done for every external developer who announces a new tool, then we wouldn't need to have the discussion about how opkg.org links to external feeds and ensures the security of downloads, since everything would be coming from the official feeds and built with the trusted openmoko autobuilder. And we'd have many more application developers feeling empowered to port applications have their work known and used by the maximum number of people. Seriously dude, this is meant to help improve the openmoko community, not flame about it. -- Rod Kosa wrote: Easy dude, there is a discussion taking place about that right know on this very list, and this kind of comments don't help at all. Be aware of the last thing we need is one more flame. You made some incredible points about why should we have a community manager and what things he or she might be doing, but then again, this does not help at all. BTW, if you change the topic of the thread, you change the subject as well. No need to be the CM to say that. ;-) Cheers! Kosa - Un mundo mejor es posible - Rod Whitby escribió: If Openmoko had a community manager, that person would contact Michael directly and: 1) Invite Michael to get commit privs and commit this patch himself directly to the OM repo. This may include teaching about how it all works. or 2) Grab the patch, add it to the repo themselves (if Michael is not keen to become a full developer) and 3) Make sure the autobuilders for all the different distributions build this package and put it in the official feeds. 4) Add the entry to opk.org Then all Openmoko users would benefit from Michael's work, and hopefully Michael would accept the offer of commit access (and access to do everything else above for himself) and be able to port many more applications for Openmoko without needing the intervention of the community manager in the future. -- Rod -Original Message- From: Michael Sheldon [EMAIL PROTECTED] Date: Monday, Oct 13, 2008 5:55 am Subject: FBReader now working on the FreeRunner To: List for Openmoko community discussion community@lists.openmoko.orgReply-To: List for Openmoko community discussion community@lists.openmoko.org Hi all, I’ve just spent the day hacking on FBReader to make it work correctly under OpenMoko (OM2008.*). Until now it’s been pretty much unusable due to the GPE version of FBReader expecting you to be using a device that has some physical buttons which then get bound to vital functions like turning the page. The changes I’ve made are as follows: * Add scroll forward/backward buttons to the toolbar * Add fullscreen mode button to the toolbar (doesn’t have an icon at the moment, it’s the third button from the right) * Change fullscreen mode so that it doesn’t hide the toolbar (otherwise there’s no way to get back from fullscreen mode) * Switch to using the much prettier blue tango icons * Make the line separation larger so the text doesn’t overlap * Reduce the font size * Change the default colours to match openmoko’s colour scheme better (and so it’s a little easier on the eyes) And most importantly… * Make it so that tapping the sides of the screen turns the book’s pages (left = backwards, right = forwards) Here’s a screenshot of what it used to look like: http://blog.mikeasoft.com/wp-content/uploads/2008/10/fbreader-orig.png And what it looks like with my patches: http://blog.mikeasoft.com/wp-content/uploads/2008/10/fbreader-openmoko.png To install it simply run: opkg install http://mikeasoft.com/~mike/openmoko/enca_1.9-r3_armv4t.ipk http://mikeasoft.com/~mike/openmoko/fbreader_0.8.2a-r6+elleopatches_om-gta02.ipk (all on one line) For those interested the patch can also be downloaded from http://mikeasoft.com/~mike/openmoko/fbreader-openmoko.patch. Bonus points for anyone who knows what book I’m testing it with in the screenshots (without googling) ;). Cheers, Mike. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Rod Whitby wrote: (Wolfgang told the Openmoko admins to give me svn and git access on the 22 Sept, and nothing has happened yet). I want to make a public retraction and apology on this point. It seems that access was granted sometime between then and now, but either I wasn't informed of that or the notification got lost in transit. My apologies to Wolfgang and the Openmoko admins. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Risto H. Kurppa wrote: I also want to remind that community is not limited to the developers. It should also include all users that can be used to create marketing events and material, generate new ideas and test software and report bugs. I like to think of the distinction between users and developers as a mindset difference rather than a difference in skills or ability. A user just wants to use the device, gets angry when things don't work as advertised, and expects support from the company that sold them the device. There's nothing wrong with that, by the way. A developer sees something that is not working properly as an opportunity to step in and try and fix it. If given the environment and accessibility to do so, they will often go as far as fixing it themselves and contributing the fix directly into the source base. Note that I make no distinction between code, doco, bug reports, marketing material, fonts, UI elements, wiki pages, etc when talking about developers. Anyone who has the mindset of this is broken, how can I fix it? is a developer. Anyone who has the mindset of this is broken, I expect it to be fixed by someone else right now! is a user. The community will have both (and often a single person will be one or the other depending on what type of day they are having in real life), but you really do need areas in the community (like a developers mailing list) where the user mindset is simply not acceptable. To do this without disrepecting your users, you also need areas where the user mindset is fully accepted and responded to with excellent support. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Risto H. Kurppa wrote: On Sat, Oct 11, 2008 at 3:35 PM, Duv [EMAIL PROTECTED] wrote: My only concern here is that there seems to be a separation between the developer and the user... that in the community both seem to have there little corner. Maybe I am reading that wrong, but if I am not... I am not too sure that it's something that I would agree with, if only because the current make-up of OpenMoko, Developer and user are one in the same. I agree: There's no reason to make a separation between developers and users. They do have a bit different needs but no matter what, they're all needed. A community manager should take care of all members of the community, from beginners to kernel developers. Help the beginners to get involved and allow and enable developers to work as efficiently as possible. I'm sorry, but I don't believe one single community manager can cross the divide between the developer and user mindsets that I spoke about in my reply to your earlier post. It's *really* difficult to spend your day answering end-user FAQs and support issues, and then turn around and enthuse and excite your developers. One person will burn out very quickly trying to do both. Note that both needs (support of users and embracing of developers) do need to be met for a well functioning community. But I don't believe a single person can do the job of meeting both those needs. We found in the nslu2-linux community that if you encourage the more experienced users to start thinking of themselves as mentors for the new users, and if you give the developers permission to not have to answer end-user FAQs (since the more experienced users are expected to be doing that), then the two mailing lists (users and developers) have a much higher satisfaction rating. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Lorn Potter wrote: Rod Whitby wrote: I'm sorry, but I don't believe one single community manager can cross the divide between the developer and user mindsets that I spoke about in my reply to your earlier post. I disagree. I have been doing exactly that for the last 5 years. Trying to anyway. I believe a community manager can only be _one_ person. OK, for a single distribution (note that Openmoko currently has 5 different Openmoko distributions, not including Qtopia and Debian), I agree with you. But for the current state of Openmoko, I still believe it's too much for one person. To have a user mindset, you simply need to use what you're trying to evangelize everyday. You see the difficulties of actually using something. Fully agree. The trouble we have today is that there are so many half-finished, half-working distributions (and everyone is swapping between them constantly trying to find something that works) that nobody is getting any benefit from a synergy like that. Qtopia and Debian are the exceptions, because they are mature distributions with existing communities to which a new device is being added. The group of 5 (2007.X, 2008.X, FDOM, FSO, SHR) are the distributions I'm mainly referring to. To work with the user community in this fashion, you need to care about and understand the flaws the software may have (in terms of bugs and usability) and the reasoning the developers may have done a particular thing. Only a developer can do this part, and only a developer can work with the developer community. Fully agree with this too. However, Openmoko currently has about five or six distinct developer communities and about the same number of distinct user communities as well. There is absolutely no way one person can cover all that. So for each distribution (e.g. Qtopia, Debian, ...) I fully agree that having a single community manager that covers both users and developers is the ideal situation. Unfortunately, the current situation with Openmoko is so far off the track (IMHO), that it will need multiple managers just to get it back on track. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Joel Newkirk wrote: On Sun, 12 Oct 2008 07:35:12 +1030, Rod Whitby [EMAIL PROTECTED] wrote: Anyone who has the mindset of this is broken, how can I fix it? is a developer. Anyone who has the mindset of this is broken, I expect it to be fixed by someone else right now! is a user. The community will have both (and often a single person will be one or the other depending on what type of day they are having in real life), but you really do need areas in the community (like a developers mailing list) where the user mindset is simply not acceptable. To do this without disrepecting your users, you also need areas where the user mindset is fully accepted and responded to with excellent support. There's also a distinctly grey area that might be exemplified by 'application developer' - someone who develops software for the platform, but expects the underlying infrastructure to be stable and complete, and instability or incompleteness to be resolved 'upstream' at OM, or by whomever has produced the distribution of their choice. Effectively they are of the 'user mindset' with regard to the core system (both kernelspace and core functionality in userspace), but of the 'developer mindset' with regard to everything sitting on top of it. (general userspace) Very good point. Just like kernel developers are users when thinking about the hardware ... WRT your final point, we already have the 'Support' mailinglist - my impression is that the intent of that list (not necessarily the actual usage though) is as a place for the 'user' to go when seeking answers and fixes, rather than seeking to involve themselves in the actual quest for those answers and fixes. Indeed, the trouble is there is a third list community which muddies the waters between devel and support, and the five word descriptions on lists.openmoko.org don't give people enough guidance on which list to use for what. Nor is there a community manager who is consistently and politely but firmly requiring people to use the correct lists ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
What should a community manager do?
official feeds. i) Never fork wholesale from upstream. If you need to make a branch, then talk to upstream and try to make the branch in *their* repo. If you need to fork, then fork the absolute minimum set of things possible. The current state of org.openembedded.dev in OE vs org.openmoko.dev in OM is a complete waste of time and effort that has not gained anybody anything. j) Mantain an autobuilder, and manage it proactively. Whenever you see someone mention a package on the mailing lists, make sure that someone adds that package to the autobuilder so that it's part of the official feeds. Have mechanisms where developers can commit source code for a new package and cause the autobuilder to build and release that package on the official feeds without any employee intervention. Treat third-party feeds and packages listed on third-party websites as indications that the development community manager has failed in their job. I say all this based on the experience of running the nslu2-linux.org project for the last four years, and building a community of over 100 developers and over 10 thousand users all working in common repositories producing packages and images for four different distributions (targeted to four different use cases) using the same top-level build system and ending up in common official feeds on a single official download site. See the following documents for more details: http://www.nslu2-linux.org/presentation.pdf http://www.batbox.org/IsThataLampInYourPocket.pdf -- Rod Whitby (No, I'm not looking for the job) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: why?
Detructor wrote: and FSO and SHR doesn't have images, yet. (FSO not before spring 2009) and nobody knows when the SHR will come with an image. FSO has released three milestone images, and also has daily build images available at downloads.freesmartphone.org - they may not be the complete stable finished images that you are looking for, but they are bootable functional images nonetheless. SHR has corresponding images available at shr.bearstech.com ... -- Rod (who manages the autobuilders which build those images) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building FSO Wiki page
Previdi Roberto wrote: On Sun, Oct 5, 2008 at 12:27 AM, Rod Whitby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 2) if i issue a make update openembedded complains that it don't know where to update from... the Makefile was updated to match this. Did you run make update-makefile and try again? i tried but the makefile just doesn't have the update-makefile target.. Apologies for that - the FSO makefile updates itself automatically as part of the normal make update target. So if you'd done that you should have got the new makefile. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building FSO Wiki page
Fredrik Wendt wrote: Is this why http://downloads.freesmartphone.org/fso-testing/images/ doesn't produce daily builds any more? (guess it's not) No, that's due to OE having a flag day TMPDIR ABI change requiring everything to be rebuilt from scratch on the autobuilder. I froze the feeds while this is happening so people don't get a half-baked result. As soon as building is successful again, I will unfreeze them. At the moment, fso-testing-image and fso-unstable-image pass but fso-testing-packages and fso-unstable-packages fail on liburi-perl. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] FSO repositories
rhn wrote: The testing repo seems to be down at the moment. Does anyone know why? OpenEmbedded had a TMPDIR ABI increment, which meant that everything needs to be rebuilt. I've temporarily put the old build results back so people can continue using those while the rebuild is happening. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building FSO Wiki page
Previdi Roberto wrote: anyway, using the automatic procedure (the makefile) i have some problems: 1) the build stops at the ttf-liberation-0.2-r2 package, install phase, and the install log is empty This was fixed a couple of days ago. Did you run make update and try again? 2) if i issue a make update openembedded complains that it don't know where to update from... The trial OE Git repository layout was changed a couple of days ago, and the Makefile was updated to match this. Did you run make update-makefile and try again? 3) which other branches are present? how do i list them? i mean: i have managed to build the fso-testing-image branch, modifying the bb files that depended on the ttf-liberation package. by doing this i must remove the terminal bb recipe, and so it's difficult to use it actually. so i tried to build fso-stable-image, but it stops the compilation on the same package (ttf-liberation, same version) and with the identical sympthoms (empty log file). is there actually any difference between fso-testing and fso-stable? This problem will go away once you do the two things above. 4) last but not least, the fso image i have created (fso-testing, removing the ttf-liberation package) is not able to connect to the gsm network, and write No service over the band meter icon. Is this expected? It's not a systematic problem, since many people are able to connect using that image. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Where are actions configured for buttons in FSO?
digger vermont wrote: Are there nightly/daily's of frameworkd somewhere? There's a lot of good stuff being done I'd like try out. Or is the way to best way to take advantage of the new methods still using NFS or similar? If fso-image and task-openmoko-feed actually built properly in OE, then you would find daily's for all FSO stuff in http://downloads.freesmartphone.org/fso-unstable/feeds/ Unfortunately, http://tinderbox.openembedded.net/builds/36365/ shows that evas-native is breaking the unstable build at the moment with the error shown in http://tinderbox.openembedded.net/public/logs/1248197.txt -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unable to read from Sandisk 8Gb SD
Andy Green wrote: It used to be that our kernel packages followed our stable kernel git daily. But the hash on that one tells it is stuck at Aug 23 patchlevel... Yet another reason why the openmoko autobuilder configuration should be documented and published somewhere. As an example, the person in charge of the openmoko autobuilder should publish the same information as can be found on http://downloads.freesmartphone.org and make the web server show the *actual* conf files used, like in http://downloads.freesmartphone.org/fso-testing/conf/ ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unable to read from Sandisk 8Gb SD
Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: | It used to be that our kernel packages followed our stable kernel git daily. | | But the hash on that one tells it is stuck at Aug 23 patchlevel... | | Yet another reason why the openmoko autobuilder configuration should be | documented and published somewhere. | | As an example, the person in charge of the openmoko autobuilder should | publish the same information as can be found on | http://downloads.freesmartphone.org and make the web server show the | *actual* conf files used, like in | http://downloads.freesmartphone.org/fso-testing/conf/ ... Yes, they (whoever they are) have packages from 16th September, it doesn't look like we broke the build since everywhere is different aged package. The fso-testing distro builds the version of the linux-openmoko kernel denotes as latest stable by the conf/distro/include/sane-srcrevs.inc file, which currently in OE git (not OM git) on the org.openembedded.dev branch says: SRCREV_pn-linux-openmoko ?= ca19d156400f817960efe0d14680324b2ea34171 In OM git, that same file (in the org.openmoko.dev branch) says: SRCREV_pn-linux-openmoko ?= a1e97c611253511ffc2d8c45e3e6d6894fa03fa3 which surprise surprise matches the ipk in http://downloads.openmoko.org/repository/testing/om-gta02/ I have no idea what determines which version is built for the feeds at http://downloads.openmoko.org/repository/unstable/om-gta02/ since there is no published build configuration on downloads.openmoko.org anywhere to be found. It's up the the person in charge of testing the linux-openmoko bitbake recipe to determine what the latest stable version in the feeds should be by updating that sane-srcrevs.inc file (after booting an image using that kernel of course). -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unable to read from Sandisk 8Gb SD
That may be, but despite that I need a daily package for kernel I can point people to. Actually blocking current stable kernel from users by not packaging it, which seems to be the case, is completely backwards. That may be the case, and you defintely should be able to point experienced alpha testers to such isolated packages for testing, but you don't want inexperienced Joe Random User permanently setting their opkg feeds to a such a directory, so you don't really want it as part of the official feeds ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unable to read from Sandisk 8Gb SD
Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | That may be, but despite that I need a daily package for kernel I | can point people to. Actually blocking current stable kernel from | users by not packaging it, which seems to be the case, is | completely backwards. | | That may be the case, and you defintely should be able to point | experienced alpha testers to such isolated packages for testing, but | you don't want inexperienced Joe Random User permanently setting | their opkg feeds to a such a directory, so you don't really want it | as part of the official feeds ... -- Rod Uh... yes in fact I do want it as part of an official feed. I expect you want it as part of the unstable feed, not the testing feed. I can fully agree with that. People who use the unstable feed are the people who know they are testing the integration and distro consistency. Someone has taken time to make a stable / testing / and even unstable branches of stuff, and you think it is right that our stable kernel git HEAD is so radioactive it doesn't even belong in testing or unstable? No, it definitely belongs in unstable, but never in testing automatically. Someone has to make a conscious decision (and commitment to the community that it should work) to edit sane-srcrevs.inc to make something new appear in testing. This is certainly something we need, the only question is where to put it so people who want to update to it can routinely get it. Unstable feed is the appropriate place for kernel stable branch head. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: inotify-tools on openmoko
Joel Newkirk wrote: On Wed, 24 Sep 2008 15:44:34 +0100, Al Johnson [EMAIL PROTECTED] wrote: On Wednesday 24 September 2008, jitendersingh wrote: hi, Do openmoko has support for inotify-tools. (more information on inotify tools on http://inotify-tools.sourceforge.net/) if not, how can I port inotify-tools to openmoko. OpenEmbedded has inotify-tools 3.12 so there is a fair chance it will build and run on openmoko. Under mokomakefile it would be: make build-package-inotify-tools If not, I successfully built 3.13 (untested though, my Freerunner's not here ATM) with just a slight alteration to the configure script - circumventing the inotify test that's not possible when cross-compiling anyway. (seems kinda shortsighted to actually check if you're cross-compiling but then fail instead of warn and attempt) Both 2.1 and 3.12 build for FSO (so should build for other openmoko distros too), but 2.1 is specified in the openmoko pinned versions file. If someone can verify that the 3.12 version from OpenEmbedded actually does something sensible on an openmoko phone, then I can change the pinning to 3.12 and add it to task-openmoko-feed.bb and it will automatically appear in the fso feeds. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neopwn
Angus Ainslie wrote: On Mon, Sep 22, 2008 at 6:51 PM, Rod Whitby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Didier Raboud wrote: Russell Hay wrote: I'm assuming they're not intending to release the full code? Certainly cant see any mentions of license or downloads on their site. Formally, they only have to release the source code to their buyers... ... and then that buyer can release it publicly for everyone else under the terms of the GPL. Who's going to volunteer to buy one? [In reality, I'm expecting they will make the source code available at the same time they start shipping their first units. A security testing system without source code available for security review would not fly with most people ...] So far they've either redirected or ignored my requests for their custom kernel changes. They also claim all of the source code for the security apps can be downloaded from their software page. Did you purchase a device from them? The GPL does not require source code availability to just anyone who wants it - the distributor only needs to provide it to those people to whom they distribute the binary. I agree that a good open source citizen should provide the source publicly as soon as it is available (i.e. even before the binary is distributed), but the GPL simply doesn't require that so you can't demand that. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO toolchain?
Nicola Mfb wrote: You may use the Makefile at http://shr.bearstech.com/ , this will setup the entire openembedded environment to build toolchain and fso images/applications. Note that the canonical place for the FSO Makefile is now at downloads.freesmartphone.org - shr.bearstech.com is for SHR work only. (The FSO and SHR Makefiles are currently identical, but may not remain so in the future, so please use the correct one). -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neopwn
Didier Raboud wrote: Russell Hay wrote: I'm assuming they're not intending to release the full code? Certainly cant see any mentions of license or downloads on their site. Formally, they only have to release the source code to their buyers... ... and then that buyer can release it publicly for everyone else under the terms of the GPL. Who's going to volunteer to buy one? [In reality, I'm expecting they will make the source code available at the same time they start shipping their first units. A security testing system without source code available for security review would not fly with most people ...] One thing they don't specify is whether the hardware is 850MHz (USA) or 900MHz (rest of world). -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Porting MokoMakefile, odd errors
Lally Singh wrote: I'm getting an openmoko build environment set up on OpenSolaris (which, btw, is great). A build error is difficult for me to interpret. I was hoping for some help. I've included the full output below. At this point, you have left the realm of MokoMakefile, and entered deep into OpenEmbedded and Bitbake. Though you might be lucky and find someone on the openmoko lists who has ported OpenEmbedded to OpenSolaris, I expect you will have better fortune on the openembedded-devel mailing list. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 default dialer crash on # or *
Marco Trevisan (Treviño) wrote: Holger Freyther wrote: On Thursday 18 September 2008 19:05:51 Marco Trevisan (Treviño) wrote: Ok, I was right... The latest upgrade to phonevendor plugin in git blocked it [1] Grab this [2] and put it in /opt/Qtopia/plugins/phonevendors. Restart the phone (reloading qpe wasn't enough to me) and it should work. [1] 563d5f4c781efe1a11680c6a055b409034b528ab [2] http://downloads.tuxfamily.org/3v1deb/openmoko/qtopia-ussd-support-phone-ve ndor.tar.gz Source? Patch? GPL? You're right. Completely. I generally never release binaries without diffs, but the patch I've with me is so bad and I'm so busy with my personal tasks that I had no time to upload anything in the last days. With GPL stuff, I always find it's best to upload the source code *first*. License compliance is not something that you can wave off with a oh, I didn't have time to do that this week. Either you had time to comply with the license, or you shouldn't have distributed the binary. The GPL applies to hobbyists just as much as it applies to big corporations. The hobbyists often cry loud when big corporations delay the release of source code - please don't give those same corporations ammunition to say well, the community doesn't release source immediately, so why should we. Either upload the source, or remove the binary. It's as simple as that. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What packages have cu and socat?
Erin Yueh wrote: Hi, i use OE to build package and i upload socat package here. You may try it on. http://cs1.cs.nyu.edu/~wcy203/socat_1.3.2.1-r1_armv4t.opk Since you work at Openmoko, why didn't you just add socat to the task-openmoko-feed bitbake recipe, and then re-run the openmoko autobuilder to update the feed? Why would someone with an @openmoko.com address be putting pre-built packages anywhere other than in the official openmoko feeds? -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fso bug/oddity
Tilman Baumann wrote: And for the wakeup stuff. Well besides at there is not much of a stable interface i guess, besides some acpi and nvram cruft. I guess a dbus interface suits well for that. But needs to be more abstract (register timer for callback/signal, remove timer). :) But somehow i can't get the at command out of my head... I would hope that framework services like registering a wakeup would not require the overhead of starting a shell to run an 'at' command :-) -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO/ASU not registering on the Australian Vodafone GSM network
W.Kenworthy wrote: I am having a problem registering anything ASU/FSO based with the Australian Vodafone GSM network. Its not the SIM card but ASU/FSO as 2007.2 works fine. I also believe that other Aussies are having the same problem. Just as a data point, my GTA01 running FSO registers fine with Vodafone AU. (Of course, that doesn't mean yours will, but it does mean that it's possible) -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Build process fails at gsm0710muxd
Michael 'Mickey' Lauer wrote: /home/micha/openmoko/openembedded/packages/freesmartphone/gsm0710muxd_svn.b b, do_fetch) That looks like a very old recipe, we switched to git since months. I think what's happening here is that task-openmoko-feeds has not been built lately on the Oenmoko servers, and holds some out of date entries in it in the openmoko git repo. Someone at OM needs to make sure that task-openmoko-feeds builds for org.openmoko.asu.stable and org.openmoko.dev ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: update-alternatives question
Charles-Henri Gros wrote: Joel Newkirk wrote: Quick question, hopefully someone can instantly see my error: I've built the full iproute2 toolset, and am working on an ipk/opk for ip and tc. The default om2008 at least, has /bin/ip linked to /bin/busybox. So that should be changed. For inspiration, I looked at the postinst script for grep, since it must perform the same changes. (point at full bin instead of busybox in postinst, restore in prerm) So I took the update-alternatives line from grep's postinst and simply replaced 'grep' with 'ip' everywhere. [EMAIL PROTECTED]:~# update-alternatives --install /usr/bin/ip ip ip.ip 100 update-alternatives: Error: cannot register alternative ip to /usr/bin/ip since it is already registered to /bin/ip Isn't this the point of update-alternatives - to allow multiple possible binaries, and 'register' the one with highest priority? What have I done wrong? And why is the path component grep.grep (or in my case ip.ip)?? grep.grep is the binary that contains what the grep package installs. You should probably install your ip as ip.ip, or use /usr/bin/ip (if that's where you install it) So the command would look like (I think): update-alternatives --install /bin/ip ip /usr/bin/ip 100 I would not recommend that command. For update-alternatives to work, all the packages which install that binary have to agree on the final path of the binary. You can't have one package wanting to install it in /bin and the other wanting to install it in /usr/bin. So first you need to modify all the packages so they install into the same directory. Then you go and put the update-alternatives stuff in, and you make each package install the binary in /path/binary-name.package-name (e.g. /bin/ip.ip and /bin/ip.busybox). Then you get update-alternatives to symlink one of those to the final binary filename in the postinst. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MonoMakefile: how to build navit-svn instead of navit-0.0.4 ?
Nicola Mfb wrote: On Sat, Sep 13, 2008 at 4:47 AM, Rod Whitby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: You should report the confusion to the bitbake developers, not to the openmoko community. https://lists.berlios.de/mailman/listinfo/bitbake-dev Come on Rod! this was only a gentle way to say i have some doubts about the opinion of a such guru as you :) Let's try to help Harald instead! The two things are separate. Suspected bugs in the documentation for bitbake should be reported to the bitbake developers. Help for Harald continues on this list ... I finally got bitbake to compile navit_cvs editing openembedded/packages/navit/navit_cvs.bb http://navit_cvs.bb and commenting the line DEFAULT_PREFERENCE = -1 as it seems a way to block a bb recipie ala gentoo package.mask. Yes, any bitbake recipe that has not had sufficient testing is usually added with DEFAULT_PREFERENCE = -1 so that it doesn't break existing builds. Once it has had sufficient testing, it's fixed CVS revision should be added to sane-srcrevs.inc or sane-srcdates.inc Howewer note that in the file openembedded/conf/distro/include preferred-om-2008-versions.inc you have PREFERRED_VERSION_navit ?= 0.0.3, this will be ignored if in your git tree there is no navit 0.0.3 recipie (as in my case) and cvs version will be automatically selected. Yep, that means that whoever updated the navit recipe version in OE (which could easily be someone who doesn't use and knows nothing about Openmoko) didn't modify that file. That's quite common, since OpenEmbedded supports hundreds of different devices, of which the Openmoko phones are just one. If in your tree there is a 0.0.3 recipie, you cannot put in local.conf PREFERRED_VERSION_navit ?= cvs, as this will be not recognized so 0.0.3 will be selected. I do not know if there is a special string to indicate to use cvs/svn string, for this you should really ask to bb developers. I don't know the answer to that either. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Package python-etk-git allready has patches applied to source
Didier Ptitjes wrote: python-etk already has the two openembedded patches applied in python-etk git. This makes build failing during patch. Yes, this is the problem that Openmoko due to their decision to let versions float with regard to packages like this. It means that breakage like this happens all the time and stays broken until someone notices it. Patches should be removed. There is a notation to identify that patches should only be applied up to a maximum revision, however since git has no ordering of revisions I doubt that will help. Should I raise a bug in the openmoko or openembedded bugtracker ? Openmoko, since you're building an org.openmoko.* branch. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki outdated ? was Re: Problems building ASU image
Didier Ptitjes wrote: OK I found the problem finaly. The Wiki states what follows for the local.conf : MACHINE = x86 DISTRO = openmoko BUILD_ARCH = i686 INHERIT += devshell TARGET_FPU = but the INHERIT += rm_work is mandatory else the bitbake doesn't work at all as you can see in the errors of my previous message. rm_work should have no effect on whether bitbake can find configuration files. Are you sure it wasn't some other change you made? Someone else had the same problem as you when they moved the build directory and did not do a make clobber between moving the directory and starting a new build ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki outdated ? was Re: Problems building ASU image
Didier Ptitjes wrote: It seems that the Wiki is outdated. Yes, wiki's are always outdated. :-( For example, the Wiki says you have to make openmoko-devel-image or openmoko-qtopia-x11-image. But the MokoMakefile version I downloaded has no such target but you have to set OM_IMAGE_NAME := openmoko-asu-image in the Makefile and make image. Please update the wiki to match reality. I'm wondering if anyone has done a fresh build restarting from scratch with the MokoMakefile as I can't explain my problems. Yes. Make sure you always make clobber if you move the build directory. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Opkg: how to protect configuration files?
Previdi Roberto wrote: When i make an update/upgrade opkg carefully protect my configuration files inside /etc, but he always destroy my changes in /opt/Qtopia/etc, causing qpe to search for documents in all the /usr (which i transferred on the memory card). Is there a way to tell to opkg to protect other directories than /etc ? The packager of whatever package includes that file needs to set CONFFILES to include that file. Then opkg will ask you whether you want to overwrite the file, or keep your old one, or drop you into a shell to do a manual merge. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MonoMakefile: how to build navit-svn instead of navit-0.0.4 ?
Harald Koenig wrote: On Sep 12, Nicola Mfb wrote: In my oe tree i have navit_cvs and not navit_svn, and can you start a build for navit_cvs (I'd guess for you it's make build-package-navit-cvs then?) Everything after the '_' in the bitbake recipe name is part of the version number, and should not be used as part of a make command. You need to tell bitbake using PREFERRED_VERSION which version you want to build. See the bitbake manual for more details. http://bitbake.berlios.de/manual/, Example 4.7 -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki outdated ? was Re: Problems building ASU image
Didier Ptitjes wrote: I just noticed that this behavior only occurs when building for the x86 machine. I say this if this can help to identify the problem. Do you mean x86 as a host, or x86 as a target. x86 as a target is not supported, and x86 as a host is what everyone uses, so you can assume that that works. BTW the makefile process is great. I used Gentoo daily so I like it. I would suggest to add a x/n numbering for packages selected to be build, as does emerge. MokoMakefile just sets up an environment and then calls bitbake. Numbering of packages selected to be built is the domain of bitbake. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MonoMakefile: how to build navit-svn instead of navit-0.0.4 ?
Nicola Mfb wrote: On Sat, Sep 13, 2008 at 2:37 AM, Rod Whitby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: [...] Everything after the '_' in the bitbake recipe name is part of the version number, and should not be used as part of a make command. You need to tell bitbake using PREFERRED_VERSION which version you want to build. See the bitbake manual for more details. http://bitbake.berlios.de/manual/, Example 4.7 In 4.2 there are examples where version number is used, i tested it and it runs, so this is quite confusing. You should report the confusion to the bitbake developers, not to the openmoko community. https://lists.berlios.de/mailman/listinfo/bitbake-dev -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPKG building and repository
Jean-Eric Cuendet wrote: First packages are built! The Feed is here: http://alf.pticoli.net/openmoko/ Do you have the source code and build instructions available alongside these packages, or are you expecting people to blindly trust that these binaries are not infected with malware? What are the quality processes that you employ to make sure that nothing untoward gets into your feed? Also, if you are going to have GPL programs in this feed, where are the sources going to be published? Note that adding packages to OE, and then just adding the package name to task-openmoko-feed.bb, will enable those packages to be available from a number of official and unofficial feeds, and also automatically comply with GPL licenses. -- Rod Whitby -- Maintainer of the fso-testing and fso-unstable feeds ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building FSO Wiki page
John Whitmore wrote: Thanks to all who replied and to Hedora who went and edited the wiki page. No doubt more questions may follow from me in the fullness of time, but for the moment I'm building. I'm hoping that I can ultimately help out here. If asking questions of Wiki pages highlights areas for improvement maybe it'll save future people asking the same questions. Indeed. http://wiki.openmoko.org/wiki/Building_FSO is now a great wiki page. [I made some small adjustments as well] Thanks to all involved. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building FSO Wiki page
Michael 'Mickey' Lauer wrote: Am Saturday 06 September 2008 00:48:00 schrieb Rod Whitby: Michael 'Mickey' Lauer wrote: For building a .dev branch, in your local.conf file, you should have at least the following three entries. Example for the Angstrom distribution and the Openmoko gta01 machine: BBFILES = /stuff/org.openembedded.dev/packages/*/*.bb DISTRO = angstrom-2008.1 MACHINE = om-gta01 I thought DISTRO was openmoko for FSO builds? Yes, but this was a quote from the wiki page. Therein lies the problem with that wiki page (http://wiki.openmoko.org/wiki/Building_FSO). It's meant to tell you how to build FSO, but instead it starts talking about Angstrom half way through (after the first half of the page duplicates other existing OpenEmbedded pages). No wonder people are confused about how to build things ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: http://shr.bearstech.com/Makefile - 403 forbidden
Russell Sears wrote: Can someone fix the file permissions? Bearstech is in the middle of doubling the disk space available for the FSO feeds, so the site is down at the moment. I don't have an ETA for when it will be up again, but they should only need to copy about 50GB from one partition to another and change /etc/fstab ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: http://shr.bearstech.com/Makefile - 403 forbidden
Russell Sears wrote: Can someone fix the file permissions? In the meantime, you can use the following workaround: git clone git://git.freesmartphone.org/fso-makefile common ln -s common/Makefile Makefile -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Building FSO Wiki page
Michael 'Mickey' Lauer wrote: For building a .dev branch, in your local.conf file, you should have at least the following three entries. Example for the Angstrom distribution and the Openmoko gta01 machine: BBFILES = /stuff/org.openembedded.dev/packages/*/*.bb DISTRO = angstrom-2008.1 MACHINE = om-gta01 I thought DISTRO was openmoko for FSO builds? The easiest way to build FSO is: wget http://shr.bearstech.com/Makefile make fso-testing-image -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Time and Timezone issues...
Marco Trevisan (Treviño) wrote: better not set TZ but do once (once after every update/upgrade?!): cp /usr/share/zoneinfo/Europe/Rome /etc/localtime Even better to make that a symlink, then if your city ever changes it's daylight savings rule, then you will automatically get the update. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stable Distro Recommendation for Business trip
Craig B. Allen wrote: In my non-exhaustive testing of FSO, I have found that daily builds generally have significant issues, so unless you are installing a FSO milestone release, then I would not recommend FSO. Are you using the testing feed or the unstable feed? Unstable is guaranteed to regularly break. Testing should break rarely. Milestones should not break. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mofi on FR
Shawn Thompson wrote: Is there an opkg package for emacs? I've just added emacs (and tichy, pidgin, epdfview, microcom and midori) to task-openmoko-feed, so any properly-set-up feed for Openmoko (such as shr.bearstech.com) should have it after the next autobuild run. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian on the FreeRunner -- now official
Joachim Breitner wrote: At the moment, emdebian does not support python, because python seems to be hard to cross-compile Hmm - OpenEmbedded has no problems cross-compiling python ... Perhaps it's a bit of NIH rather than hardness ;-) -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
Stroller wrote: On 30 Aug 2008, at 05:34, Rod Whitby wrote: Please don't assume that everyone has unlimited data plans. Please don't assume probably won't prevent developers from doing so. Nothing can prevent open source developers from taking any world view they please. That's their right. That's why I'm educating them with the message that unlimited data plans are not available in all parts of the world. Whether developers listen to or do anything with that information is completely up to them. If it's educated just one of them who happens to have only lived in a country that has unlimited data plans, then it has been worth writing. It would probably be better to educate readers about WHY we shouldn't assume data transfer via GPRS to be massively cheap affordable. Where are you? Australia. Are unlimited data plans completely unavailable there? Or just expensive? Completely unavailable. How much does data transfer cost there? (comparison of data cost relative to calls?) 1c per Kb. Calls are about 30c/min. Why is this? A teleco monopoly? No, there are three major telco's - it's just that none of them offer unlimited data plans. Why is the situation unlikely to change in the foreseeable? There are no market forces that will make it change, as Australia is a large country with a relatively sparse population (2.6 people per square kilometer). It is not as common in many parts of the world as it is in your part of the world. Great, so enlighten me. Saying please don't assume that everyone has unlimited data plans just makes me think, oooh, look! here's someone as cantankerous as I. If you want me to REMEMBER you when developing my hypothetical ultimate mail client then tell me something memorable about data plans in your country. Things are very different in different parts of the world. For instance, in the USA it used to be the case (and may still be) that the recipient had to pay for incoming mobile calls and SMSs. Such weird pricing (where you can be sent poor by someone harrassing you with calls or SMS messages) has never been seen in Australia. I expect the IMAP client on my openmoko phone to be able to download all my email for offline reading, deleting, and replying on the bus with *no* internet connectivity, and then sync all those changes seamlessly to the server as soon as I get the next internet connection. I expect that, too. Certainly under my data plan this would be essential for foreign holidays. It's good that our needs are identical then. Ability to do stuff when connected, and ability to do stuff when not connected as well. As opposed to an assumption that someone is always connected. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mokomakefile
Michael Kluge wrote: At the risk ob beeing called a parrot I want to ask the same question again: Is anyone able to build a 2008.08 image with Mokomakefile? This is the third time I am asking this. I really noone interested in this? Did I miss anything and do we now build images a different way? 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. It used to be org.openmoko.asu.stable, but then someone from openmoko said they were going to concentrate on org.openmoko.dev instead. I wish they would create a document like http://shr.bearstech.com/README so that *everyone* would know how they build their images and can replicate them outside of Openmoko. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mokomakefile
Marek Lindner wrote: 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. OK, can you describe *exactly* how you built that released image and how you build those updates/fixes, so that others can replicate. The level of detail found in http://shr.bearstech.com/README is appropriate: 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. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Repository and Images
Julian Chu wrote: On Wed, Aug 27, 2008 at 11:57:37PM +0930, Rod Whitby wrote: Will you be autobuilding from the OE git repository or the OM git repository? 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 auto-build from OM git tree. And we still trying to make it close to OE git tree. It's that delay (which is often a number of days) which means that we still needs auto-builders (especially for FSO and SHR) which build directly from the OE git tree. Since Openmoko now has it's own stable branches (org.openmoko.asu.stable), I don't see the reason for having a separate org.openmoko.dev branch separate from org.openembedded.dev - in an ideal world you would be always in sync with the org.openembedded.dev branch without any delay caused by manual syncing by Graeme. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ePDFviewer and reflowing text
Nishit Dave wrote: On Sat, Aug 30, 2008 at 2:43 AM, Risto H. Kurppa [EMAIL PROTECTED] wrote: On Fri, Aug 29, 2008 at 7:39 PM, Nishit Dave [EMAIL PROTECTED] wrote: I have installed ePDFviewer from http://www.ginguppin.de/node/21 after loading all missing dependencies from the feed at http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/ (and it was a long list!) Could you please post the list here for others? Sure, here it is, with the paths: ... Then: [EMAIL PROTECTED]:your/temp/directory/location# opkg install epdfview_0.1.6-r3_armv4t.ipk FYI, epdfview 0.1.6 should be available in the fso/shr feeds within an hour or so. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
Stroller wrote: I thought the standard now was unlimited data plans. ... You have my sympathies if you're not on an unlimited data plan, Ole, but I would see unlimited data use as the long-term expectation of OpenMoko projects. Please don't assume that everyone has unlimited data plans. It is not as common in many parts of the world as it is in your part of the world. I expect the IMAP client on my openmoko phone to be able to download all my email for offline reading, deleting, and replying on the bus with *no* internet connectivity, and then sync all those changes seamlessly to the server as soon as I get the next internet connection. My Treo650 does that today. Assuming an always-on connection (as opposed to just taking advantage of one when it is available) is a backwards step. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Repository and Images
On Wednesday 27 August 2008, Marek Lindner wrote: We also encourage $your_project to be built by our auto builder and become installable on the base image. This should give you the time to focus on improving your project instead of building and distributing it. The unstable package feed will always contain your latest code, testing the version you think is ready for use. Will you be autobuilding from the OE git repository or the OM git repository? 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. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO testing on Neo 1973
Ernst Skribbler wrote: Rod wrote: This means you haven't got the gpschannel_add_udpchannel_and_filechannel.patch from Trac 49 applied. Any idea when the patches that fix GPS will be available in the testing images? Thanks. Yes, when the frameworkd developers have a stable new version ready for testing :-) They are currently in the middle of a set of disruptive changes. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tester please?
Timo Juhani Lindfors wrote: Joel Newkirk [EMAIL PROTECTED] writes: http://newkirk.us/om/dnscache_2.1.5_armv4t.ipk and let me know of any Hmm, how do I build this from source? Indeed - I'd be happy to test bitbake recipes for these ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing and Unstable feeds for the FSO distribution are now available
Kevin Fenzi wrote: I installed the unstable image, and tried to use either the unstable or testing feeds here, and I get: a bunch of: Assuming locally installed package is up to date. then a bunch of: * Packages were found, but none compatible with the architectures configured Can't seem to install or update anything. ;( Please post the contents of your /etc/opkg/*.conf files. I know that both sets of feeds work, cause people have reported success with both in the IRC channel (and I personally use the fso-testing feed exclusively). -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO testing on Neo 1973 - opkg update doesn't work
Torfinn Ingolfsen wrote: Downloading http://my-distribution.org/remote-feed/... You might want to change that to the actual location of the feeds ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Which distribution to start with? - Noob question alert
Daniel Selinger wrote: Or should i still consider using the 2007 or SHR release to begin with the phone, despite the fact that they are mainly based on the old gtk apps which will likely be abondoned in the future, aren't they? There is no SHR release yet - do you perhaps mean ASU/Om2008.8 ? -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navit patch for faster map dragging
Yohann (YC) Coppel wrote: So, I can view the maps, calculate the directions, but It does not read gps data. I am using FSO, and apparently there is no gpsd in the repositories. gpsd is installed in the GTA01 fso-testing image at shr.bearstech.com, and navit is also in the fso-testing feeds. I have been able to run it, and get it to display the GPS co-ords, on a GTA01 device. I can comment on GTA02 support, since my pre-production GTA02 is broken, and I'm hoping that OM will send me a replacement 900MHz version sometime ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO testing on Neo 1973
Torfinn Ingolfsen wrote: On Thu, Aug 21, 2008 at 10:01 AM, Torfinn Ingolfsen [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 2:12 AM, Rod Whitby [EMAIL PROTECTED] wrote: The connection between gllin and TangoGPS is not there on the fso-testing image (since we're waiting for some major frameworkd changes to stabilise before Mickey bumps the srcrev). If you apply the patches in FSO trac tickets 49 and 50, then it works. I'll try that. Thanks. I must have done something wrong, because neither tangoGPS nor zhone displays any GPS data, even if gpsd spews data out. I applied the pat in 49, edited /etc/fraeworkd.conf as described in one comment, and applied the patch in 50. Then I restarted the phone and verified that gllin and gpsd was started, and that gpsd was outputting data. Any hints on where to look? So just to confirm your setup ... 1/ You installed the gta01 fso-testing image from shr.bearstech.com 2/ You installed gllin 3/ You applied the patches from trac 49 and 50 4/ You edit /etc/frameworkd.conf as detailed in trac 49 5/ You rebooted after all this 6/ cat /tmp/nmeaNP gives output, including FIX lines 7/ dbus-monitor --system does not show any GPS-related signals If all the above is true, then kill frameworkd and run it on the command line - send the output of that. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Testing and Unstable feeds for the FSO distribution are now available
I have created an unofficial auto-builder for the FSO distribution at http://shr.bearstech.com (hosting of the server is provided by Bearstech - I have no relationship with Bearstech other than managing the auto-builder that runs on the server they have provided for this purpose). The server currently contains continuous builds of the fso-testing and fso-unstable distributions for the OpenMoko GTA01 (Neo 1973) and GTA02 (Neo FreeRunner). In the future it will also contain continuous builds of the shr-testing and shr-unstable distributions. The fso-testing and fso-unstable distributions are built from the org.openembedded.dev branch of the git://git.openembedded.net/org.openembedded.dev.git repository. Both are built with DISTRO set to 'openmoko' and MACHINE set to sequentially to 'om-gta01' and 'om-gta02'. The fso-testing distribution builds the versions of packages specified in the preferred-om-2008-versions.inc file and the sane-srcrevs.inc file. A key feature of the fso-testing distribution is that the package versions do not change unless by direct action of developers to update those files. The intention is that this results in a recent set of packages that have undergone some rudimentary testing by the developers. The fso-unstable distribution allows a certain set of packages (defined in the moko-autorev.inc and fso-autorev.inc files) to 'float', and therefore is more likely to have the absolute latest version of any package, but also more likely to include versions of packages that do not not work and sometimes do not even build. The set of packages built is determined by contents of the task-openmoko-feed recipe in the OpenEmbedded repository. Build results are reported continuously to the oestats server at http://tinderbox.openembedded.net/builders/shr.bearstech.com/ All source tarballs used can be found in the sources directory on the server. Note that images that are rebuilt multiples times on the same day are overwritten. The server operates in the CEST timezone. To replicate the configuration of this server, you should use a Debian Lenny host operating system, with the host package configuration as specified in the sources.list and dpkg-list.txt files in the server-config directory. Then copy the Makefile and 'common' directory to your build area. Read the Makefile for further documentation and instructions. -- Rod Whitby -- MokoMakefile and FsoMakefile author ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO testing on Neo 1973
Torfinn Ingolfsen wrote: FYI, I just installed FSO testing (latest snapshot) on my Neo 1973. Looks - I like it! screen locker - I like it! And many things work also - nice! I don't have a SIM card in my 1973 (it's in the FreeRunner) so I can't test phone functions. GPS - I have installed gllin and I get data from it (tested with 'cat //tmp/nmeaNP'). Should zhone and / or tangoGPS work on this image? The connection between gllin and TangoGPS is not there on the fso-testing image (since we're waiting for some major frameworkd changes to stabilise before Mickey bumps the srcrev). If you apply the patches in FSO trac tickets 49 and 50, then it works. BTW, Orrery (a great star chart app) works nicely on it too! http://downloads.openmoko.org/repository/Multiverse/orrery_1.1_arm_2008.8.ipk -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing and Unstable feeds for the FSO distribution are now available
Kevin Fenzi (by way of Kevin Fenzi [EMAIL PROTECTED]) wrote: Just read your announcement about the testing and unnstable FSO feeds. Awesome work. ;) A few quick questions tho: 1. How can we request/test new packages be added to the task-openmoko-feed ? (In particular I would love to see FBRreader, irssi, twinkle and a few others. ;) Also, is there an easy way to list whats in that feed now? Anyone with commit access to the OpenEmbedded repository can add to the feed by modifying the task-openmoko-feed.bb file. You can see it's contents at: http://git.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/tasks/task-openmoko-feed.bb;h=207d48d9048d811a403732e56c0ba743be892adb;hb=HEAD 2. The Packages* files seem to all be 0 length there... ie, look in: http://shr.bearstech.com/fso-unstable/ipk/ Packages* files at the top level are not used. Look in the subdirectories. 3. Are the feed files in each of the branches setup to point to those repos for updates? Ie, if I install the unstable image, will updates pull from unstable? At the moment, no. Mickey would need to modify the standard image feeds config to do that. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openvpn?
OpenVPN is also in the fso-testing and fso-unstable autobuild repositories at shr.bearstech.com, along with every other package listed in the OE task-openmoko-feed recipe ... -- Rod Michele Renda wrote: If you want an easy way, you can try with Debian. OpenVPN is in repository! Michele Renda Nick Van Fossen wrote: I'm trying to compile openvpn for my FreeRunner, which is running 2008.8, but so far I haven't been successful. Has anyone else tried to do this yet? If so I'd appreciate any info on how you were able to. -Nick _ Talk to your Yahoo! Friends via Windows Live Messenger. Find out how. http://www.windowslive.com/explore/messenger?ocid=TXT_TAGLM_WL_messenger_yahoo_082008 ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Try to install MokoMake on openSuSE 11 fails
Lothar Behrens wrote: The difference is that I am using openSuSE 11 instead of 10.3. Which (of the many, redundant, mostly out of date, non-executable) instructions did you use? Your subject says MokoMake (which I assume means MokoMakefile) but you talk below about manually installing bitbake (which the MokoMakefile does for you automatically). One package was not installable via Yast (help2man) = Downloaded orginal source tgz and built it. Ok Installing BitBake was also not possible via Yast. Downloaded the package from BerlinOS. Try http://wiki.openmoko.org/wiki/MokoMakefile -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navit patch for faster map dragging
diff --git a/packages/navit/navit_0.0.4.bb b/packages/navit/navit_0.0.4.bb
index 104495f..edd4519 100644
--- a/packages/navit/navit_0.0.4.bb
+++ b/packages/navit/navit_0.0.4.bb
@@ -4,4 +4,7 @@ PR = r0
SRC_URI = ${SOURCEFORGE_MIRROR}/navit/navit-${PV}.tar.gz
+DEFAULT_PREFERENCE = -1
+
SRC_URI_append += file://navit.xml-so.patch;patch=1
+SRC_URI_append += file://font_scaling_patch.diff;patch=1
You should never set DEFAULT_PREFERENCE to -1 on an already working
recipe, just because you added a better svn recipe.
In addition to this, since you modified the recipe, you should have
changed PR = r0 to PR = r1.
It is a common occurrence for there to be multiple working versions of a
recipe in OE.
Use PREFERRED_VERSION and sane-srcrevs.inc to select between alternative
working versions and prefer one for a specific distribution.
-- Rod
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: which updates for Om 2008.8 ?
Julian Chu wrote: I am the leader of building stuff. We did a release in 2008.8 then provide a stable feed. Buidhost is a building machine that build many things with AUTOREV. That means everything comes from buildhost is *Unstable* We provide buildhost for the reason that we hopes we can provide latest packages for someone who like fresh. Right now it confused many people, we know that and are going to shut down the http interface. Many people concern about 2008.8 repository. Let me explain what we are going to do. *) Provide three repositories 1) unstable 2) testing 3) stable Thanks for clearing up this problem. BTW, Bearstech have graciously donated a server instance for building FSO images, and have accepted my offer to maintain an autobuilder which builds stable, testing and unstable feeds for the FSO distro. The stable feed builds pinned at the latest milestone commit. The testing feed builds from sane-srcrevs. The unstable feed builds from moko-autorev and fso-autorev. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MokoMakeFile
Alasal wrote: Is the MokoMakeFile still under development? It is, but it's difficult at the moment to get things to build correctly. Is there any chance for flashing Om2008.8 on the qemu emulator? You can do this now by setting the branch correctly. See the MokoMakefile wiki page for details of how to build asu.testing -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU and sound - broken - how to fix it?
Torfinn Ingolfsen wrote: On Wed, Aug 13, 2008 at 5:46 PM, Benedikt Schindler [EMAIL PROTECTED] wrote: did you update your ASU with the buildhost ? that will destroy the Yes, I did. AFAIK, this is the only way to update ASU with daily updates, unless one wants to reinstall everything every day (ie. flash a new image with dfu-util). There are no ASU updates on buildhost. You have installed packages built from a branch which is not ASU, and this is likely to be the cause of your no sound problem. I'll do another 'opkg update opkg upgrade' this evening and see if things have improved. If you're still pointing at buildhost (instead of pointing at zecke's temporary asu testing feed), then it won't help. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: spanner/wrench in daily builds (ASU) from buildhost.openmoko.org
Yorick Moko wrote: Is there a way to get the spanner/wrench back on openmoko-openmoko-qtopia-x11-image-glibc-ipk--20080813-om-gta02.rootfs ? You'd be better off actually using the asu image, and then updating it using zecke's correct feeds instead of using that image you've listed above which is not related to asu. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is Neo1973 truly abandoned?
Holger Freyther wrote: PS: E.g. mickeyl is testing FSO on GTA01 as well, so it remains supported.. I'm currently working on getting gllin to talk to ogpsd in the fso framework, so I can run TangoGPS on a GTA01 alongside Zhone and NumptyPhysics :-) -- Rod (who's only working OM phone is a GTA01) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: opkg upgrade - kernel not updated corectly - Om2008.8
Benedikt Schindler wrote: it's me again with an update problem of the kernel. i like kernels and i like to update them in a wrong way :) so here are my steps so far. Device: Freerunner rootfs: Om2008.8 kernel: Om2008.8 i installed the Om2008.8 and did a opkg update opkg upgrade. i deleted the neo-feeds. i added this feeds to opkg: http://buildhost.openmoko.org/daily-feed/om-gta02/ http://buildhost.openmoko.org/daily-feed/armv4t/ http://buildhost.openmoko.org/daily-feed/all/ Those feeds are not updates to Om2008.08 If you use them, you are guaranteed to have versioning problems. Let me repeat it again: Buildhost does *not* build ASU/Om2008.08 packages. I'm hoping that Openmoko build leader will announce a change to this policy, but at the moment you cannot get Om2008.08 updates from buildhost. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which updates for Om 2008.8 ?
Harald Koenig wrote: in Om 2008.8 all feeds in /etc/opkg/ go to http://downloads.openmoko.org/repository/Om2008.8/ Correct. That is the Om2008.08 feed. is it ok to use http://buildhost.openmoko.org/daily/freerunner/200808/MMDD/ as update feed for Om 2008.8 ? Absolutely not. Buildhost does *not* build ASU/Om2008.08 packages. We're still waiting for the Openmoko build team lead to make a decision to fix this. Building and making public packages that do not match with your latest stable binary image simply doesn't make sense. if not, is there a recommended update feed for Om 2008.8 ? http://downloads.openmoko.org/repository/Om2008.8/ There is *no* other feed location for Om2008.08 at the moment, and Openmoko are *not* doing public daily builds of Om2008.08 ... -- Rod (not associated with Openmoko, but with strong opinions on feeds) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which updates for Om 2008.8 ?
Olivier Berger wrote: Rod Whitby [EMAIL PROTECTED] writes: if not, is there a recommended update feed for Om 2008.8 ? http://downloads.openmoko.org/repository/Om2008.8/ There is *no* other feed location for Om2008.08 at the moment, and Openmoko are *not* doing public daily builds of Om2008.08 ... -- Rod (not associated with Openmoko, but with strong opinions on feeds) May I suggest to add that into : http://wiki.openmoko.org/wiki/Om_2008.8#Updates if you feel confident on your opinions ? The text that is there (There should be some official updates for 2008.8 setup soon, but in the meantime, you'll have to wait.) is correct. I've added a warning about buildhost. I expect that Openmoko will start populating the official Om2008.08 feed with updates as soon as those updates make their way through QA. [Although one might ask why the updates need to go through QA when it is now clear that the release itself happened against the advice of QA ...] -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which updates for Om 2008.8 ?
steve wrote: Rod, Our QA includes community feedback. If we release early particular elements in the community will slam us. We expect that. If we hold back releases, other elements of the community will slam us. So we expect to be slammed no matter what we do. Fun job ehh? Armour plating is required. Steve, I have no problem with Openmoko having the sole right and responsibility to determine the time and frequency of updates to the community. That is as it should be. If a community member was more frequently updated packages than what is provided by Openmoko, then they can easily build them themselves. What I do have a problem with is the current situation where buildhost builds a daily feed of updates WHICH ARE INCOMPATIBLE with the latest Openmoko Om2008.08 released image and which cause major confusion amongst your customer base. http://docs.openmoko.org/trac/ticket/1809 Please fix that ticket. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.9 - Was Re: Third request: what *is* the warranty on the Freerunner?
Feydreva wrote: Does Mokomakefile can build a 2008.8 more recent than the one release on August 08 of 2008 ? I setup the Makefile for OM_GIT_BRANCH := org.openmoko.asu.testing and run make openmoko-qtopia-x11-image Will I have the fake asu, like the one on the daily buildhost ? or will I have a 2008.8/ASU ? That should build the correct image from the correct branch to get you ASU updates. The only other variable is whether the Openmoko staff who built the ASU image used moko-autorev.inc or not. I truely hope they did not and instead relied on the pinned sane-srcrevs.inc file. I would really like to see a precise definition of how Openmoko staff build the images for release ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which updates for Om 2008.8 ?
Holger Freyther wrote: On Wednesday 13 August 2008 23:39:06 Rod Whitby wrote: What I do have a problem with is the current situation where buildhost builds a daily feed of updates WHICH ARE INCOMPATIBLE with the latest Openmoko Om2008.08 released image and which cause major confusion amongst your customer base. http://docs.openmoko.org/trac/ticket/1809 Please fix that ticket. You are right, this ticket needs to be fixed and it is on the way. One part of the fix would be to remove the daily feed just now. Seriously, now that you have graciously provided a temporary correct daily feed of Om2008.08, I would strongly recommend removing the incorrect one. First, do no harm. The invisible part is the consolidation of the build infrastructure. So currently we have buildhost.om.org (probably hosted in germany) and a server in the Taipei office (office). Latency from asia to europe is big and interactive ssh sessions can be funny... the same applies the other way around.. and some more reasons, so we have to decide which server to shutdown...and how to please the related engineers. I'm confident they will sort it out. Understood. Thanks for letting us know that a decision has been made and it's now just a matter of implementation. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU 2008.08 image
simarillion wrote: I'm a little bit confused. On the devel List I read that the real ASU image has a black Wallpaper. But where can I download it? I downloaded this one http://buildhost.openmoko.org/daily/freerunner/200808/20080807/openmoko-openmoko-qtopia-x11-image-glibc-ipk--20080807-om-gta02.rootfs.jffs2 but it has the wallpaper of the FSO image and the nice qwerty button at the top left. Which image is this, SHR ? FYI, that image is not ASU/2008.08, since buildhost builds from the org.openmoko.dev branch, not the org.openmoko.asu.* branches. It's not SHR either. It's a qtopia-x11 image based on the latest builds of the branch that brought you the current openmoko release (the one that comes on your phone). In my opinion, it should be removed, since it causes so much confusion. Hopefully, the point will be moot in less than 2 days. So whilst it might give an idea of what ASU might look like, it will certainly have lots of bugs and features (e.g. the FSO theme) which definitely are not in the image you get when you build from the correct branch. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: cpu-speed limitations
Alex Kavanagh wrote: Jay Vaughan wrote, On 05/08/08 16:32: It would be a terrible shame if, after all the 'more important work' gets done, Glamo gets ignored because 'now its time to build new hardware'. I think it'd be rotten, in fact. I'd agree with that, if that happens - but that hasn't happened yet. You're imagining the worst possible outcome here? Perhaps I'm too naive. Although I can imagine a scenario where the OM team would move quickly onto the GTA03 once the GTA02 is 'good enough', the community can keep the pressure up to 'do' something with the glamo chip when the other issues on the GTA02 have been solved. Hmm - there's a current issue regarding the GTA01 GPS gllin driver and kernel /sys filesystem paths, so the response of Openmoko to that previous generation issue is probably a good indicator of the sort of attention that GTA02 Glamo will get once GTA03 is released. I'm hoping that the response is a positive one from Openmoko. Publishing the schematics will be a great first step, but there is still the previous generation support for the proprietary NDA stuff that needs to be factored into Openmoko's staffing plans (since the community can't do it). -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: buildhost.openmoko.org issues.
On Friday 01 August 2008, Lech Karol Pawłaszek wrote: I wonder if there is something going on with buildhost.openmoko.org. I am unable to update packages list nor install new packages via opkg for two days now. I am unable to wget http://buildhost.openmoko.org/daily-feed/all/Packages.gz as well. It says 403 Forbidden. On [EMAIL PROTECTED] someone said that the server layout is being changed. Is that true? Is there any temporary workaround? Someone on IRC said that all the daily builds have been deleted as payback for all the badmouthing of Openmoko staff over the last week ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Lack of 3G a killer for Australia
Ben wrote: Unfortunately the FreeRunner will not function well as a phone in Australia due to the lack of 3G. Rubbish. Both GTA01 and GTA02 work perfectly in Australia without 3G. Coverage of GSM in Australia *far* outreaches 3G coverage. The Australian Telcos don't appear to be spending anymore money on pre 3G networks and they may even be pulling some of it out as service is declining badly. Complete FUD. Please provide evidence. -- Rod ___ 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 Wed, Jul 30, 2008 at 7:59 AM, Charles-Henri Gros [EMAIL PROTECTED] wrote: Is there a way to tell 'opkg upgrade' to upgrade everything except the kernel? If you were using ipkg, you could say: $ ipkg flag hold package-name Dunno whether opkg has that functionality yet. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Sean: Please authorise the release of GTA01 schematics
Sean, Now that the FreeRunner is selling like hotcakes, and your hardware and software teams must focus on it to ensure that it succeeds in the market, and the GTA01 Neo1973 is no longer in production or being sold by Openmoko or its distributors, surely it's the perfect time to release the GTA01 hardware schematics? This would send a clear message to the community and the whole mobile ecosystem that Openmoko is a company that doesn't leave it's customers in the lurch when it brings out a replacement product like closed ecosystem companies do, but that Openmoko is a company that wants it's customers to continue to impact the material world with *all* of it's products - past, present and future - for many years into the future. Allow the amateurs to continue to have the distinct advantage over the professionals even years after the professionals have moved onto the next piece of hardware. Imagine a world where new uses for 10 year old Openmoko hardware are still being found, because the schematics for previous generation products are always released when Openmoko ceases to produce or sell that product. Imagine how much wider the impact of Openmoko can be if older products are not thrown in the bin due to lack of information availabe to repair them, but are instead repaired by people in the community or amateur ecosystem and then put back into service to continue to spread the word about the clear advantage that open source has over the closed ecosystem. Sean, please release the hardware schematics and pcb layout and component placements for the GTA01. Let the GTA01 run free and continue to impact the material world. Respectfully, -- Rod Whitby ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to find the board revision?
Ken Restivo wrote: I'm thinking about flashing the Uboot to get working APM capability. The instructions on the Flashing_openmoko WIKI page say that it is very important to only flash the uboot image that matches the hardware revision of the phone (obviously), but it doesn't say *how* to find out what board revision you have. I'd be glad to add that to the page with the instructions on how to flash, if someone could tell me where to find the revision. I remember stumbling across it somewhere (probably in /proc), but I've since forgotten. cat /proc/cpuinfo -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No WLAN AP functionality
Crane, Matthew wrote: But if you can plug a usb wifi stick which the kernel does support AP mode you could then use the internal wifi as the uplink. I'm finding it difficult to source a cheap usb wifi stick that Linux supports in AP mode. Do you have an example of one that you know works in this way, and has Linux drivers available for armel (which immediately cuts out any madwifi drivers due to eabi) ? -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
