SHR: Where I am on getting 2007.2 M stuff running on FSO
I know really only shr folks care about this, but I thought some of you who know something about FSO and/or 2007.2 could point out stupidity if you see it :-) I installed an FSO MS 1 image on my gta01, and made sure that it runs properly. I created a directory called 2007.2 that holds the rootfs from a 2007.2 install. Then: cp 2007.2/etc/matchbox/session to it cp 2007.2/usr/bin/matchbox-session to it comment out phonekit mv /usr/bin/x-window-manager /usr/bin/x-window-manager.fso ln -s /usr/bin/matchbox-session /usr/bin/x-window-manager opkg install openmoko-common2 openmoko-contacts2 openmoko-dialer2 openmoko-icon-theme-standard2 openmoko-mediaplayer2 openmoko-messages2 openmoko-panel-battery openmoko-panel-bt openmoko-panel-clock openmoko-panel-gps openmoko-panel-gsm openmoko-panel-memory openmoko-panel-usb openmoko-session2 openmoko-tasks2 openmoko-terminal2 openmoko-today2 opkg install matchbox-panel-2 neod /etc/init.d/gsmd stop rm /etc/rc*/*gsmd* /etc/init.d/x* stop /usr/bin/matchbox-session The last failure I got was ** (openmoko-today:1401): WARNING **: Failed to get dbus connection: dbus-launch failed to autolaunch D-Bus session: Autolaunch requested, but X11 support not compiled in. Cannot continue. There's a recent post on openmoko-devel about how to fix that. It's just a matter of getting the dbus env variable set properly. The other missing thing is getting Julien's phonekit adapter running on FSO, and you may need to either fix openmoko-panel-gsm or remove it from the matchbox/session config (I would try the latter first). Gotta go spend family time now, I recommend coordinating in #openmoko-cdevel if you find time to work on this stuff. Later! Bobby -- If it doesn't make you smile, you're doing something wrong.
SHR: 2007.2 desktop on FSO (sort of)
Well, it's not much, but it's progress. I realized shortly after I sent the last email that the dbus problem was only because I started X from the ssh session, not from the device console. So I set my gta01 back up as described in the last email rebooted. I get the standard 2007.2 openmoko-today2 home screen, with a lot of error messages in x.log that it can't talk to gsmd (expected) and with no theme applied (not expected, I thought I just needed to install the theme). Once we root out the few direct gsmd calls from the OM apps and debug Julien Marc's phonekit adapter, and do a little clean-up, I think we'll be ready to put out our first alpha release of SHR. Regarding direct gsmd calls, one of the shr guys said it looked as if the only calls were in openmoko-gsm-panel and opemoko-dialer2, but I'm getting messages about missing gsmd from openmoko-today2 as well). Bobby -- If it doesn't make you smile, you're doing something wrong.
Fwd: GSM Modem emulator
Has anyone built a gsm emulator, for example for testing in qemu? Below is Federico's proposal; I'm just trying to see if someone has a baseline for him to start from or a finished product... I just subscribed to the list, so I don't have the previous message but it is related to this. Would it be helpful if I hacked up a GSM modem emulator in Python? It should be quite easy (famous last words :) and it would just use master/slave pseudo ttys, and implement a tiny set of AT commands. Cheers Federico/ Bobby
SHR hosting on Freeculture.org?
Asheesh, is it possible that we can host the various SHR things that don't have a place on OM servers on freeculture.org, maybe all under whatever.shr.freeculture.org? E.g. git.shr.freeculture.org? Ainulindale pointed out (rightly, I think) that we should try to make the host naming consistent, and you have the nicest name to put it under, and you appear to have lots of stuff already configured on your servers :-) Thanks! -- If it doesn't make you smile, you're doing something wrong.
Re: Reading SIM card contacts (was [Fwd: about openmoko input method])
From: xiangfu [EMAIL PROTECTED] there are another two question: 1. where is the code of read SIM card contacts. i want it can read Chinese. there is some different between English and Chinese store in SIM card. I wrote a python script to do this; you can get it at http://wiki.openmoko.org/wiki/Import_Sim_Contacts It doesn't specifically handle internationlization. I don't know if libgsmdtool will stream internationalized characters, or even if python streams i18n characters correctly by default. It would at least be a starting place. The script inserts the contacts using the 2007.2 dbus interface; you would need to change it to target another database. If you do have to change it, I would love to have the code updates :-) I need to get this into projects.openmoko.org... The code is availble under GPL v2.0, although I still need to get that into the code itself. There was also some code written by a Chinese fellow that is (I think) integrated into the 2007.2 contacts application. It did handle i18n. It should just be an option in the 2007.2 contacts application... Bobby -- If it doesn't make you smile, you're doing something wrong.
SHR: All dialer SMS traffic goes through dbus?
Hi, I'm starting work on the phonekit-to-ophoned adapter for the Stable Hybrid Release, and I'm wondering if someone can tell me offhand if all traffic to the gsm from the 2007.2 application suite goes through the org.openmoko.PhoneKit dbus interface? Or are there a few outlying features (e.g. maybe the Contact app feature that reads entries from the SIM card) that access the gsm in another way? Thanks! Bobby -- If it doesn't make you smile, you're doing something wrong.
SHR First steps
I'm just going to give my impressions here as if they're facts - everyone feel free to correct me where I'm wrong :-) 1) The FSO is the build with the most stable calls and suspend/resume. Those seem to be the real sticky bits of the suite (as well as some of the most important for day-to-day use), so I think our first target for SHR should be simply to reproduce a stable (and repeatable) build of the FSO, but in an environment in which we can apply our future changes. 2) To that end, I know Asheesh has created a git repository. I think mwester is probably the one best suited to tell us what repositories we should be pulling from to generate our build products, and how to get there. If he can either outline for us what to do, or, better yet, just get access to Asheesh's repository and do it, I think that's how we should get started. 3) Once we can reproduce an FSO build, I think we need to figure out how we're going to launch programs. IMO it should be one of the existing launchers - probably the one the ASU uses, but I'm open to suggestions since I have yet to run ASU at all :-) If it turns into a morass to bring in the ASU launcher, and if another full-featured launcher is easier to port, I think that's the way to go. 4) I think the 2007.2 suite of phone PIM applications are the most ready for day to day use right now, so I propose that we change those apps to use ophoned as the backbone instead of phonekit/gsmd. I *think* they almost exclusively use the PhoneKit dbus interface to access the gsm now, so I intend to write an adapter from PhoneKit to ophoned and modify the dependencies so those apps that access the phone depend on our new adapter. At this point I think we have a baseline that will let us have a phone that works and will last 1 day+ using suspend, and let us pull in lots of individual applications that don't conflict with the things we already have in the image. There is IMO one biggish thing missing... 5) We need to figure out our keyboard solution. I'm not sure how the existing keyboards work... is raster's keyboard in the ASU ready to go, and can we bring it in without needing a bunch of conflicting dependencies? 6) Now we have the full basic suite, and we just try all the different packages we can find and see if we need to write some adapter for popular ones, and maybe produce a list of tested apps as well as those that have been shown to have some problem. We're still feeling this stuff out, so if I've gone way off track, or missed the obvious (either obvious problems or obvious solutions), please chime in. I would love it if this could eventually just turn into a part of the ASU, with people replacing the old 2007.2 apps (without breaking them!) with alternatives that work better or look nicer as a part of the ASU. Our goal is *not* to create another competing release (although I know that's essentially what we're doing right now). Our goal is to take the goodness of the future and the goodness of the past and patch together something that gives us both until the future can catch up on all counts with the past :-) Thanks for any feedback! Bobby -- If it doesn't make you smile, you're doing something wrong.
Re: [PATCH] Adding password protection to U-boot: salted version
From: Francesco Albanese [EMAIL PROTECTED] Hello, I have cleaned my code and I updated my patch with a new feature for salting the password. - The salt is generated collecting a timestamp for every valid keystroke supplied during password prompting: then, the least significant byte of each timestamp is XORed providing eventually a 24bits seed for SHA256 function. The first 24bits of the generated context are used as the salt. - Even though I cannot claim that function is Bruce Schneier proof, the level of complexity added should provide a certain degree of security against rainbow tables (256bits secure hash, salt derived from quite random events like keystrokes, XOR is a statistical balanced function ...). This patch has been tested on GTA01BV04. It is stil unclear if it could work on FR (the twin bootloaders shall share the same ENV VARs). Comments are always welcome, Francesco Albanese Francesco, I highly recommend looking at http://eternallyconfuzzled.com/tuts/algorithms/jsw_tut_hashing.aspx for an analysis of various hashing algorithms. If you have a few sources of randomness and you hash them together with a good algorithm, that should be all you need. To me, the Jenkins algorithm is the clear winner. The page I linked complains that it is significantly more difficult to implement, but it is still quite easy to implement since they give you a C implementation already :-) Computational complexity of an algorithm like that is utterly negligible on a processor of even a few KHz, much less 200 MHz+. Bobby -- If it doesn't make you smile, you're doing something wrong.
Re: GSoC Accelerometer-based Gestures Update
Alexey Feldgendler [EMAIL PROTECTED] wrote: On Wed, 04 Jun 2008 08:51:54 +0200, Paul-Valentin Borza [EMAIL PROTECTED] wrote: The classifier is based on multivariate gaussian mixtures. I've written the discriminant functions and just finished writing the estimation/training functions (yes, this classifier also needs to be trained). The classifier is great because it can adapt/learn new values on the fly while in use. So, when this classifier classifies enough frames as gestures/motion, it passes these frames to the recognizer that has a unigram grammar of hidden Markov models. One thing that worries me is whether continuous recognition is something feasible within Freerunner's battery life and CPU time constraints. Even if the gesture recognizer manages to put the device to sleep when there is no signal and wake up on motion, there will still be a lot of idle processing to do while the user is walking. I would think that you just wouldn't have it wake on motion... clicking Aux before starting gesture recognition (if the neo is asleep) seems a reasonable prerequisite. By the way, it would be great if you guys would have ideas for gestures. Although creating a new gesture will be trivial, it would be good for me to know how many I have to create. The demo app will enable auto-answer when picked up from the table, auto-hang-up and snooze the alarm when hit. Any more ideas? Is the recognizer able to factor out rotation of the coordinate system? In other words, will it recognize the same gesture if the phone is turned compared to the orientatin used in training, e.g. if the snooze gesture is done from another side? Some gesture ideas: snip a bunch of great ideas Paul, you might also consider: * holding the moko out angling the front of it up repeatedly turns up volume * angling front down repeatedly turns down volume * a set of 5 or 10 standard, easily distinguishable gestures that the user can map to favorite programs This is an exciting project; it's great to hear that you've made so much progress already! Bobby -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com -- If it doesn't make you smile, you're doing something wrong.
Re: Automatic pop up kbd
Subject: Re: Automatic pop up kbd On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED] babbled: On Friday 16 May 2008 08:53, Tick wrote: Hi Zecke, We are going to make the kbd show and hide automatically. snip Thanks. Tick Please can you make it possible to switch this off and / or force the keyboard to hide. There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. design decision was made to remove manual control even though it has been there from the beginning. no can do. -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] Could we get someone to forward the logic of this design decision? Not giving the user a way to turn something off that occupies 30% of the screen seems like, dare I say, a bad design decision. -- If it doesn't make you smile, you're doing something wrong.
Re: Request for stable, automated build process
On Fri, May 2, 2008 at 12:02 AM, Joachim Steiger [EMAIL PROTECTED] wrote: Bobby Martin wrote: On Thu, May 1, 2008 at 11:50 AM, Thomas Wood [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Well, there is buildhost.openmoko.org http://buildhost.openmoko.org which builds images nightly. I've been asking for the toolchain to be fixed and updated and I believe Julian has this on his TODO list. Regards, Thomas Thanks for pointing that out. Does it apply a label to builds that succeed? Is there documentation of what this hypothetical label might be, and also documentation of the build process that buildhost.openmoko.org http://buildhost.openmoko.org uses? (Hrm, reading over that, it looks like I'm trying to be sarcastic with the thanks. I'm definitely not! The thanks, and the questions, are real, not rhetorical.) i do not really get what you mean by labels. when buildhost successfully finished a build there is a new image. else, there is not. if it cannot compile all dependencies then it logically cannot package it. i think i know what you really want in the end. a full CI representation of what buildhost does build and what not. i have found http://bitten.edgewall.org/ recently and since we are currently in the process of moving to trac it is very interesting for me. whats missing is the glue between that and the openembedded build system. and to make it really usefull at all we would need unit tests for all 'packages', not only a 'built something' 'did report exit=!0' yes i want that. but let us finish work on getting trac first please ;) if you know your way around trac, python and OE i am happy about everyone who can help me there. What I mean by a label (sometimes called a tag) is that your build process uses your revision control systems' commands to apply a label to all files before the build process starts. In svn, you use the svn copy command to tag files, like so: svn copy file:///tmp/repos/test/trunk file:///tmp/repos/test/tags/building -m tag tree (see http://svnbook.red-bean.com/en/1.1/re07.html) Unfortunately, I think OM uses three different repositories (svn, git, mtn) so you would issue at least three different commands to apply the label. Then when you're done with the build, you would relabel it with a build-successful tag, e.g.: svn copy file:///tmp/repos/test/tags/building file:///tmp/repos/test/tags/build-success-2008-05-02-13-47 -m tag tree (If the build happened at 13:47 on 2008/05/02) Then you run your tests and relabel with test-success-2008-05-02-13-47 if those pass. When the build is done, you delete the building tag so you can re-use it for the next build. You probably also want to tag those same files with build-success-latest and test-success-latest. That way people can pull that label from the repository and know what to expect. You can also look at the labels and see when good builds happened and when things broke. A good CI system will also email some set list of people when the build is bad with the files that changed since the last good build (this set ideally including the list of people who checked those files in) so the build tends to get fixed quickly. Being able to retrieve the build products from good builds is obviously very important, but it's not necessarily very helpful for people doing development work. For them, being able to get the very latest code from the project they're working on, and the latest good code from all projects it depends on, is typically what they want. I have used trac a bit, but probably not enough to be helpful without studying up on it. I wasn't aware it provided much Continuous Integration support. I will do some research on it. Thanks! Bobby -- If it doesn't make you smile, you're doing something wrong.
Re: Request for stable, automated build process
On Thu, May 1, 2008 at 11:54 AM, Bobby Martin [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 11:50 AM, Thomas Wood [EMAIL PROTECTED] wrote: Well, there is buildhost.openmoko.org which builds images nightly. I've been asking for the toolchain to be fixed and updated and I believe Julian has this on his TODO list. Regards, Thomas Thanks for pointing that out. Does it apply a label to builds that succeed? Is there documentation of what this hypothetical label might be, and also documentation of the build process that buildhost.openmoko.org uses? (Hrm, reading over that, it looks like I'm trying to be sarcastic with the thanks. I'm definitely not! The thanks, and the questions, are real, not rhetorical.) I should point out that if I knew the right way to run a build (I think there are three possible ways) and could actually get a build to go through at least once in a while, I would volunteer a server and the effort to set up continuous integration. My time is pretty restricted, so it might take me a fairly long time to get it all done, but I am willing to do the work if I can get answers to the basic questions. Bobby -- If it doesn't make you smile, you're doing something wrong.
Request for stable, automated build process
I really think OM is shortchanging themselves with the current build process. As far as I can tell: * there is no way to run a build that has a high probability of working all the way through * there is no way to identify the latest code that builds together * there is no automated build process, nor even a stable script one can follow to do a complete build from source on one's local machine * it looks to me as if the code lives in at least three different kinds of repositories: svn, GIT, and mtn * I'm sure that there is a way to identify the code that went into a particular snapshot found on the web, but I don't know what it is * there is no way to identify which tasks definitely have someone reliable working on them, which are open issues need attention they're not getting, and which have some casual developer looking at them I have done several very minor programs for my neo, which I would have much preferred to integrate into the real build process. However, when I've tried the Mokomakefile process, it will run for hours and then die in some obscure way. I spent a few hours over the course of several days debugging that process on my Ubuntu machine at home, before I realized there were version issues with the assembler that I didn't see any way to work around. I have a debian installation that I run some web services on, and a build there went farther, but finally failed as well. I see consistent complaints from people who do have known good build environments that the build is broken for days at a time. I just don't have the energy to spend a dozen hours debugging a process that will enable me to spend a few dozen hours doing development. I would think that many other potential contributors fall in the same boat. I think that a few procedures could dramatically increase the development community's involvement in OM, resulting in faster bugfixes, more features added sooner, and greater visibility into the project status: *Automated build process* The build process should be a no brainer. The process should document the operating systems versions supported, and the tools versions needed. If I run on one of those OSes, I should be able to download one script and kick it off, and come back a day later and have a full build of the latest code that compiles. I can then update the configuration to get the latest code in specific areas if I want to. To ensure that *anyone* who is a competent developer can run the build script, ideally there would be a chroot filesystem tarball to fall back on or a VM image for when you don't have the appropriate OS version available, or otherwise have conflicts between the OM build process and other things you may need on your system. There should also be a test harness for developers to easily insert tests for their code, and for which every bug (except those that require hardware to test) must have a test inserted for the bug to be considered fixed. The test harness should likewise be runnable trivially, with one simple command (e.g. 'make test') *Continuous integration* (CI) Someone needs to set up a server that on a periodic basis (one or more times per day) pulls the latest build process script, labels the code with something like CI_CANDIDATE, configures the build script for that label and runs it. If that process fails at any point, some set of interested parties should receive an email (ideally, also the people who checked in changes since the last working build would be emailed). If the process succeeds, then the code labeled CI_CANDIDATE would be relabeled something like GOOD_BUILD_2008_04_23 and the CI_CANDIDATE label removed. Further, the test harness should be run, and if it passes a label like TESTS_PASS_2008_04_23 should be added. *Task tracking* Maybe this is supposed to happen in bugzilla now, but it seems to me that we need the kind of bug tracking I was discussing above - a full list of tasks, priority (something as simple as High, Medium, Low would work fine), and a way to see if it is *really* being worked or not. Having a project manager who is an OM employee for every task would be helpful, since we could then expect to get an answer if we email a query about the status. *Documentation* If the above were implemented, that documentation could be as simple as telling people: * the script location and how to configure what labels are used for each subsystem * the location to download the VM or chroot tarball if necessary * the meaning of the continuous integration labels, and which ones to look for * perhaps the place to look for CI build statuses (most recent successful build, etc) * the location of the task tracker and the important fields (status, priority, assignee(s), project manager) Some or possibly even all of this may exist, but if so I couldn't find the documentation. In particular, CI and a test harness make a HUGE difference in the likelihood of success of a project,
Slow dialer
Does anyone know why the dialer takes multiple seconds to come up? Is it just rendering the themed gtk widgets that is the slow-down? I know I could build an ugly dialer that occupied almost no memory and just kicked off libgsmd-tool when you try to dial a number... My point is, shouldn't the dialer be a part of the home application, always running, and with the UI coming up in a fraction of a second after you click the dialer button? Bobby aka wurp/wurp2
Re: Usability Review of OpenMoko GTK+ Applications
This is pretty straightforward, but I think it's worth mentioning: - The dialer app should start up virtually instantaneously. It would be nice if the media player did too, but it's essential for the dialer. - I should be able to add numbers from my call history as contacts. - I should be able to select any text, and there should be a title bar icon (or some other always-available functionality) to paste. - There should probably be a power button menu option to restart X. (Ideally, we could edit the power button and aux button menus trivially) I do think you should go with either Kevin Dean's idea of configurable data on the address book details page, or, more trivially, a remarks/notes section. I may want to remind myself when I called the person last, or a food allergy or lunch preference they have, etc.
Re: Phonebook on SIM card
Agh, now you tell me :-) I just finished the first version of mine. It is intended to be a simple importer, one way, from the SIM card to the address book. Really, it seemed that it would be a faster way to get my 60+ address entries into my neo than typing them in by hand, and that's the niche it's written for. I wrote it in python - it just builds a command list that it passes in to libgsmd-tool -m atcmd, then it parses the results to get the list of SIM entries. It has some minimal smarts to put multiple phone numbers under one name into one address book entry, then it builds a vcard and sends it to EDS over dbus. I spent more time playing with dbus, trying to find the interface to send contacts to the address book and the format for the function parameters, than I did writing the program. This is really just to tide me over, and I thought some other people could make use of it. It might end up in pyneo, if those guys are interested. But I don't really think it would even be a helpful reference for people putting real SIM synchronization functionality in openmoko-contacts. I doubt that my utility will support unicode at all :-( It really just depends on python's unicode support, address book's unicode support, and libgsmd-tool properly formatting unicode output. I posted my current version of the script on the wiki at http://wiki.openmoko.org/wiki/Import_Sim_Contacts , but honestly it sounds as if what you have is better in every way except that my script is on the wiki so people can use it now :-) Bobby On Thu, Feb 28, 2008 at 10:59 PM, Chia-I Wu [EMAIL PROTECTED] wrote: Hi Bobby, (moving the discussion to openmoko-devel) On Thu, Feb 28, 2008 at 01:15:08PM -0600, Bobby Martin wrote: I will also soon have an interim solution for importing contacts from the SIM into the address book for you to put up there, too :-) I spent some time on phonebook importing last weekend (for fun :-). Currently, I am able to read the phonebook entries from the SIM and insert them into EDS. Unicode entries are also supported, but the support is a little bit ugly. I plan to work on a cleaner way for unicode support over this weekend. My biggest problem right now is that openmoko-contacts is not aware of the phonebook on SIM card. This means, deletion or renaming from openmoko-contacts do not propagate back to the SIM. This can cause confusion to the users. Do you have any idea how to deal with it? I also noticed this problem from the gsmd side: http://lists.openmoko.org/pipermail/gsmd-devel/2008-February/000478.html Phonebook import is a must for me. It is really great to see you also work on it. -- Regards, olv
