**** BEGIN LOGGING AT Sat Sep 13 02:59:56 2008 Sep 13 04:09:03 *sighs* Sep 13 04:27:58 hi all. I'm trying to build a custom kernel for openmoko. I already have a patch but I can't find out the convention for applying this patch. I need to use the kernel version 2.6.24.3 plus a patch file. Do I need a git repository setup on the build system? Sep 13 06:25:14 frameworkd died during a call and now the vibrator just won't stop; it's driving me nuts;) Sep 13 06:25:26 what exactly makes it pulsate? Sep 13 06:26:06 /sys/class/leds/neo1973\:vibrator/brightness pulsates between 0 and 255 Sep 13 06:26:12 its just 'on' then Sep 13 06:26:31 echo'ing 0 into it, doesn't help Sep 13 06:26:37 it has a small weight which is mounted noncentric on a small dc motor Sep 13 06:26:50 check the 'spaces' behind the 0 Sep 13 06:27:28 right, but some process is setting it to 0 and then 255 in an eternal loop Sep 13 06:27:43 that shouldnt be Sep 13 06:27:56 not if no frameworkd is running (fso) Sep 13 06:28:05 right, but it does;) Sep 13 06:28:17 ps -e|grep -i fram Sep 13 06:28:24 returns nothing, so it's not running Sep 13 06:28:46 this is on a debian, btw Sep 13 06:29:55 any other processes? paste 'ps axu' output on somethinkg like http://paste.lisp.org/ Sep 13 06:30:17 i did never use the debian, so i'm not sure what theyre doing there Sep 13 06:30:55 http://www.esben-stien.name/proc Sep 13 06:32:00 weird.. and when you echo 0 into the sysfs its zero afterwards on readback? Sep 13 06:32:47 yes, when I read it, it's 0 when not vibrating and 255 when vibrating, so echo'ing 0 into, just kills one pulse Sep 13 06:33:01 s/into,/into it,/ Sep 13 06:36:48 damn, I don't get it Sep 13 06:39:05 does the chip have an internal pulse state, maybe? Sep 13 06:40:58 I just have to turn the device off, cause I'm going insane;) Sep 13 06:41:21 I'm seconds before chopping it up with an axe Sep 13 06:52:06 b0ef nope.. you control a pwm in kernelcode with the value Sep 13 06:52:25 the pin is just driving a transistor which gives power to the motor 'or not' Sep 13 09:02:15 is the tool chain mentioned in openmoko.org/wiki/toolchain suitable for all distros? gtk and qt alike? Sep 13 09:07:31 AndreasD, I always get the CallStatus CALL_STATUS_HELD instead of CALL_STATUS_RELEASED when a call is released. Is that issue known? Sep 13 09:19:58 hi Sep 13 09:19:59 Hi, FSO compilation stuck at "populate_staging" for "python-pyrex-native" (ImportError: No module named math) .. any solution ? Sep 13 09:26:58 i'm trying to follow fso initialisation scripts. i'm running an fso image inside the simulator (which works pretty well). i see tha zhone is loaded, but before zhone, there is "Home" with some apps "dialer", "zhone"... Sep 13 09:27:29 I don't see anything in /etc/X11/Xsession.d, except for zhone Sep 13 09:31:37 ... I think it is the x-window-manager (enlightment) Sep 13 09:32:04 w_erase: I had problems with python two days ago, I updated yestersday, and everything worked fine... Sep 13 09:33:37 ok Sep 13 09:34:22 is the tool chain mentioned in openmoko.org/wiki/toolchain suitable for all distros? gtk and qt alike? Sep 13 09:45:56 quickdev: Not really it might be worth looking into Sep 13 09:46:27 quickdev: Which version of frameworkd are you using? Sep 13 09:48:11 AndreasD, 0.8.2+gitr2+02c8fbe7588cf7ef62764b37f58925eaf007dc8d-r0 Sep 13 09:48:19 frameworkd is the cause? Sep 13 09:49:48 quickdev: might be, from what I can see lfg seems to follow the specs Sep 13 09:52:27 quickdev: Could you try and take a look at the outout of frameworkd? Sep 13 09:52:41 I'll try in a few minutes, yes Sep 13 09:53:15 hi all. I'm trying to build a custom kernel for openmoko. I already have a patch but I can't find out the convention for applying this patch. I need to use the kernel version 2.6.24.3 plus a patch file. Do I need a git repository setup on the build system? Sep 13 09:53:38 quickdev: great, have to go, I'll be back in 15-20 min. Sep 13 09:54:13 ok, till then ;) Sep 13 10:20:44 hi Sep 13 10:21:01 is there a way to make fso go to sleep after some time ? Sep 13 10:21:36 peter-b, know it on the head with a baseball bat, duh... Sep 13 10:21:37 ;0 Sep 13 10:22:03 hmmm.... Sep 13 10:22:40 whats the difference between rootfs.jffs2 and rootfs.jffs2.summary ?? Sep 13 10:23:20 summary should boot a bit faster iirc Sep 13 10:24:11 but its a lot bigger. Does it have more stuff preinstalled or something? Sep 13 10:24:42 quickdev: I'm back, have you looked at the output of frameworkd? Sep 13 10:25:13 AndreasD, just having a little compile issue - will be ready in few minutes.. Sep 13 10:25:52 face_ iirc it just contains a summry so your files can be found faster in the flash Sep 13 11:13:18 Hi Sep 13 11:13:32 python-etk-git package problem : Sep 13 11:13:44 Patch scrolled_view-drag.patch does not apply Sep 13 11:14:40 log : http://pastebin.com/m3742d12e Sep 13 11:15:19 Do not even what could I do to continue building my image as I'm a total newbie Sep 13 11:15:57 can I reject the current package building (like emerge --resume --skipfirst) ? Sep 13 11:16:33 ideas ? Sep 13 11:20:12 wow it seems everybody sleeps this soon ;) Sep 13 11:34:08 hi mickeyl Sep 13 11:34:33 are you working on FSO/python-pyrex at the moment ? Sep 13 11:40:23 is there a way to tell bitbake to skip currently building package ? Sep 13 11:40:44 mickeyl: ping - what shall we do about the feeds? I'm rebuilding from scratch on nslu2-linux.org in case that helps Sep 13 11:47:23 ptitjes, what distribution are you building ? Sep 13 11:48:38 rwhitby: no idea, honestly. open for all suggestions Sep 13 11:48:44 w_erase: no, why? Sep 13 11:50:56 w_erase: openmoko-asu-image from org.openmoko.asu.stable git branch Sep 13 11:51:25 Task 2242 (/home/olivier/moko/fso-testing/openembedded/packages/python/python-pyrex-native_0.9.8.4.bb, do_populate_staging) Sep 13 11:52:07 am i wrong in thinking this is the stable 2008.8 ? Sep 13 11:52:35 mickeyl, failed : ImportError: No module named math Sep 13 11:53:12 org.oe.dev? Sep 13 11:54:56 mickeyl, yes Sep 13 11:55:07 strange, never seen that Sep 13 11:55:16 can you import python on your native host? Sep 13 11:55:19 err Sep 13 11:55:20 import math Sep 13 11:59:35 yes I can import math in python CLI. Sep 13 11:59:55 ok, then try with the one in staging/x86-64/usr/bin Sep 13 12:00:44 mickeyl: the only thing I could think of would be to re-release an image which is built on the same machine as the feeds, or otherwise to point the feeds to use the bitbake from OM (but I think there might be recipe changes needed too) Sep 13 12:01:52 yeah Sep 13 12:01:58 first one sounds better to me Sep 13 12:02:00 olivier@royale:~$ ~/moko/fso-testing/tmp/staging/i686-linux/usr/bin/python Sep 13 12:02:00 Python 2.5.1 (r251:54863, Sep 12 2008, 18:39:24) Sep 13 12:02:00 [GCC 4.3.1] on linux2 Sep 13 12:02:00 Type "help", "copyright", "credits" or "license" for more information. Sep 13 12:02:00 >>> import math Sep 13 12:02:01 Traceback (most recent call last): Sep 13 12:02:02 File "", line 1, in Sep 13 12:02:04 ImportError: No module named math Sep 13 12:02:07 >>> Sep 13 12:02:11 w_erase: uh, that's sick Sep 13 12:03:29 looks like it miscompiles your python-native Sep 13 12:03:36 send me the logs from that Sep 13 12:03:49 (in work/x86-64/python-native/tmp/do*.log) Sep 13 12:05:01 mickeyl, I'll try without -j4 parallel build Sep 13 12:05:16 k, not that it should make a difference, but worth a try Sep 13 12:06:39 w_erase: what git repo and branch should I set in Makefile to get the 2008.8 ? Sep 13 12:06:57 is that : OM_GIT_SITE := git.openmoko.org Sep 13 12:06:57 OM_GIT_REPO := git/openmoko.git Sep 13 12:06:57 OM_GIT_BRANCH := org.openmoko.asu.stable Sep 13 12:06:57 OM_IMAGE_NAME := openmoko-asu-image Sep 13 12:07:04 ? Sep 13 12:07:28 "Om 2008.8 is the successor to Om 2007.2 and had ASU as a codename" Sep 13 12:07:49 so I guess you're right Sep 13 12:08:16 understood that but why is there packages not building if this is stable ? Sep 13 12:08:45 i'm affraid I set a wrong branch as many people build it before without errors ?? Sep 13 12:10:06 ptitjes: not everyone has an identical build environment. it's meant to be repeatable but often isn't/ Sep 13 12:10:40 however, I just built that same branch and image, and that build is up to task 4280 of 4343 Sep 13 12:11:29 so maybe my patch tool is not a good one ? I run on Gentoo Sep 13 12:11:45 of course, you're building on x86_64, and 64bit is always the troublesome one. I'd recommend sticking to a 32bit machine for building if you want to have the highest chance of success. others will tell you that 64bit works perfectly Sep 13 12:11:58 ah gentoo. just give up now Sep 13 12:12:30 moko@didier ~ $ patch --version Sep 13 12:12:31 patch 2.5.9 Sep 13 12:12:31 Copyright (C) 1988 Larry Wall Sep 13 12:12:31 Copyright (C) 2003 Free Software Foundation, Inc. Sep 13 12:12:31 This program comes with NO WARRANTY, to the extent permitted by law. Sep 13 12:12:32 You may redistribute copies of this program Sep 13 12:12:33 under the terms of the GNU General Public License. Sep 13 12:12:35 For more information about these matters, see the file named COPYING. Sep 13 12:12:37 written by Larry Wall and Paul Eggert Sep 13 12:12:38 since no two gentoo installations are alike, that means that no-one has ever tested the build on the exact same configuration that you are using, hence whether it works or not is just up to luck. Sep 13 12:12:39 moko@didier ~ $ uname -a Sep 13 12:12:41 Linux didier 2.6.24-gentoo-r8 #1 SMP PREEMPT Thu Jun 19 10:14:05 CEST 2008 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux Sep 13 12:13:00 get a distribution where everyone in the world is running exactly the same binaries, and you might have a chance of a repeatable build Sep 13 12:13:22 but the toolchain is build by bitbake so this should be the same Sep 13 12:13:42 "should be" is the operative phrase. Sep 13 12:13:55 obviously, it isn't since openmoko-asu-image builds fine for me here. Sep 13 12:14:20 so either I'm on my own or either I don't develop for om ?? Sep 13 12:14:20 (and builds fine for the people at openmoko too) Sep 13 12:14:45 that is sad Sep 13 12:14:49 or you use a distribution which has well defined binaries, that don't change from installation to installation Sep 13 12:15:10 that's the price you pay for running Gentoo Sep 13 12:15:27 not to start a distro fame war, but I tried lots of distro and gentoo is still the most stable i found running on my computer Sep 13 12:15:43 sure, but stability has nothing to do with repeatability of builds Sep 13 12:15:55 because computers are not the same from insallations to installations Sep 13 12:16:37 I'm not here to tell you which is a better distribution, I'm simply telling you that since you run Gentoo, I am unable to replicate your installation, and hence cannot reproduce your error. Sep 13 12:17:06 NOTE: package openmoko-asu-image-1.0: completed Sep 13 12:17:30 Ubuntu 8.04, on a 32bit x86. Sep 13 12:18:34 I can pastebin the output of 'dpkg -l', and you'd be able to reproduce that exactly if you had a 32bit xen instance running on your 64bit machine Sep 13 12:18:54 and then the build would most likely complete without any errors. Sep 13 12:19:14 but I have no 64bit machine ??? Sep 13 12:19:56 ah, sorry, that was w_erase Sep 13 12:20:30 ok, so it's not 64bit related then, just gentoo-related probably. Sep 13 12:21:06 I can't even think patch works differently in gentoo than in ubuntu... Sep 13 12:22:05 ok, you tell me why it's not working then? Sep 13 12:24:05 mickey|sports, compilation continues when -j4 is disabled ... strange Sep 13 12:24:29 w_erase: another one of those "it should work ..." ;-) Sep 13 12:25:03 rwhitby, :-) Sep 13 12:25:23 * rwhitby wonders why "make qemu" is grabbing an image for buildhost.automated.it ... Sep 13 12:25:33 s/for/from/ Sep 13 12:27:19 rwitby: please could you give me your exact version of patch ? Sep 13 12:28:25 sure, it's the version that everyone running ubuntu 8.04.1 across the whole world is using - patch 2.5.9 Sep 13 12:28:25 , and by the way, every single instance of it is the same binary, so it's guaranteed to run identically ... Sep 13 12:36:10 where could I browse the git online ? Sep 13 12:36:23 I can only find browse svn Sep 13 12:36:32 git.openmoko.org Sep 13 12:37:13 hnn.. on my topic. Does openmoko have a git repo for linux-2.6.24.3 Sep 13 12:37:24 oups sorry Sep 13 12:37:46 hil__: same answer Sep 13 12:38:12 :O Sep 13 12:38:15 * hil__ looks again Sep 13 12:38:20 http://git.openmoko.org/?p=kernel.git;a=shortlog;h=stable Sep 13 12:38:37 there's also the andy branch for bleeding edge Sep 13 12:40:05 sorry but i'm new to this git thing and not very good at reading the repos. can you help me a little bit more. I see this are revisions but nowhere does it say 2.6.24 Sep 13 12:40:21 i found a git link for 2.6 (stable) but i need .24.3 specifically Sep 13 12:41:48 that repo is 2.6.24 Sep 13 12:41:51 look in the Makefil Sep 13 12:41:55 e Sep 13 12:42:08 yes. but what about extrarevision .3 Sep 13 12:42:49 dunno. why do you need something other than what openmoko builds? Sep 13 12:43:21 i have a patch (linux-ima) and that requires 2.6.24.3 Sep 13 12:43:38 it's a very early prototype, so I don't think it will work with another version Sep 13 12:43:57 there's not likely to be much different between 2.6.24 and 2.6.24.3 ... Sep 13 12:44:14 especially no api changes Sep 13 12:44:58 actually, it changes some key places like initialization, places the bootloader calls etc. but i guess i should give it a try Sep 13 12:45:13 tell me just one more thing :) Sep 13 12:45:45 the .3 is only allowed to be bugfixes on 2.6.24, so I really doubt it's different in the areas that patch touches Sep 13 12:45:50 can I just put the patch in the kernel .bb file in SRC_URI += "patchfile" to have mokomakefile build the kernel after applying the patch Sep 13 12:46:01 that should do it Sep 13 12:46:02 hnn... alright Sep 13 12:46:08 ok then. thanks Sep 13 12:46:22 what does the ima patch do? Sep 13 12:46:22 oh and a special thanks for the Mokomakefile. it's a life saver Sep 13 12:46:51 you're welcome - if you really want to thank me, clean up the wiki page for me ;-) Sep 13 12:47:09 ermm... it's "Integrity Measurement Architecture" ... remote attestation (which, btw, has been rejected by the linux community since it uses LSM hooks which are already taken by SELinux) Sep 13 12:47:21 :O the wiki page looks fine. I used it to get the whole thing going Sep 13 12:47:34 it's a little difficult at first, but then it gets ok. Sep 13 12:48:00 so ima is like a remote secure boot? Sep 13 12:48:31 yeah. it's different from secure boot because it doesn't stop the boot process if integrity fails Sep 13 12:48:44 it's just there to report the integrity to the challenger sometime in the future Sep 13 12:49:00 ok, I found http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html :-) Sep 13 12:49:00 (of course, this is all just research at the moment and is very crude) Sep 13 12:49:05 exactly Sep 13 12:49:19 Sailer et al. are the guys working actively on this (and many related issues) Sep 13 12:49:26 are you involved in the research? Sep 13 12:49:33 er.. not on ima directly Sep 13 12:49:44 we're working on a high level framework for making this thing feasible. Sep 13 12:50:01 http://portal.acm.org/citation.cfm?id=1377836.1377864&coll=Portal&dl=ACM&type=series&idx=SERIES10694&part=series&WantType=Proceedings&title=SACMAT&CFID=15151515&CFTOKEN=6184618 Sep 13 12:50:08 in case you want to know ... :) Sep 13 12:50:18 it's Model-based Behavioral Attestation Sep 13 12:50:45 IMA simply measures the hashes of executables. our framework measures the runtime/dynamic behavior of the app and reports that Sep 13 12:50:58 (well... it doesn't actually do anything since we haven't implemented it yet :) Sep 13 12:51:11 interesting, thanks. Sep 13 12:52:00 no, thank _you_ for the help :) openmoko is our target prototype and your makefile was great help Sep 13 12:52:03 see you around Sep 13 12:52:03 I greped the bitbake thing but can't find the do_patch hooks (I don't know python so maybe it is binary compiled ?) I would like add verbosity to the path call... Sep 13 12:53:14 does someone know where it is ? Sep 13 13:01:21 ok! found "openembedded/classes/patch.bbclass" but don't understand anything :( (whish I never add to worry about python things...) Sep 13 13:17:38 maybe another idiot question: it seems that when I modify the patch.bbclass it says : Sep 13 13:18:05 NOTE: Out of date cache found, rebuilding Sep 13 13:18:13 does it take my changes in account ? Sep 13 13:19:25 also is there a way to update the cache manually for just the file I changed ? Sep 13 14:38:27 b hey folks, anyone knows how to make qemu work with gta2 ? Sep 13 15:01:01 mickey|sports, hi, not sure if its a bug, but i think frameworkd is registering too many bus names..all of them expose the same objects.. Wouldn't just org.freesmartphone.frameworkd do? Sep 13 15:32:17 I have tried to get sample2 to compile, following http://wiki.openmoko.org/wiki/Toolchain Sep 13 15:33:21 problem is that the latest toolchain has some hardcoded paths, /home/build/internal-daily/.... which do not exist on my box Sep 13 15:34:04 I go back a version and it is missing some basic dependencis ... libmokoui2 ? Sep 13 15:35:06 am I missing something obvious? Sep 13 15:36:00 zion, afaik, libmokoui2 is long deprecated Sep 13 15:36:55 well, outside of the current toolchain, you have to go back to 2007 Sep 13 15:38:07 looking at the config.log of sample2 it seems that pango was hardcoded to /home/build/internal-daily-build/neo1973/staging/x86_64-linux/usr Sep 13 15:40:53 I could be misunderstanding that, but make is failing on not finding libpangoft2 in that dir Sep 13 16:20:39 I have problems with initramfs-image Sep 13 16:21:22 ptitjes: what kind of? Sep 13 16:21:46 during do_rootfs there is a script that does : Sep 13 16:21:49 opkgarchs='all any noarch i486 x86 x86' Sep 13 16:22:40 I can't find where this script is and this genertes multiple src declarations which in turn makes errors like Sep 13 16:22:42 ERROR: duplicate src declaration. Skipping: Sep 13 16:22:43 | src oe-x86 file:/home/moko/build/tmp/deploy/glibc/opk/x86 Sep 13 16:23:09 ok no idea then Sep 13 16:23:21 i have experience in initramfs-tools but not openembedded Sep 13 16:23:38 I tried to grep everywhere in openmoko tree and openembedded tree but not found Sep 13 16:24:04 ptitjes: it might rm -fr it after build Sep 13 16:24:37 lindi-: sorry ?? Sep 13 16:25:06 ok understood but this makes fail the build Sep 13 16:26:22 mickeyl: Question regarding frameworkd: I need to implement a callback that can be scheduled by an event. Specifically, an unsolicited message handler needs to be able to request a callback to be executed in "n" seconds from now. Does anything exist in the framework right now that can do such a thing? Sep 13 16:26:28 side question: what are the advantages of bitbake over portage ? Sep 13 16:27:15 mwester: which kind of event are you thinking of? Sep 13 16:27:27 well Sep 13 16:27:28 anyways Sep 13 16:27:44 i could do that in the framework, but Sep 13 16:27:54 wouldn't it be better to use standard linux technologies for that? Sep 13 16:27:59 like, any mainloop will do Sep 13 16:28:18 every mainloop abstraction has timeout_add Sep 13 16:28:28 and since you're using dbus async, you need to have a mainloop anyways Sep 13 16:30:59 :) Another of my "Horrible Awful Ugly" hacks -- when CSQ reports "99,99" I want the handler to post the problem to a callback scheduled to run in 3 seconds -- that callback will be cancelled when and unsol. CSQ arrives with a valid signal quality. This will filter out the erroneous loss-of-signal events as the Calypso switches cells. (the same technique, but more complicated will filter out the other unso. messages such as loss of regis Sep 13 16:30:59 tration) Sep 13 16:31:50 *nod* Sep 13 16:31:56 i thought about that in ogsmd Sep 13 16:31:58 I have a prototype that is rather effectively working; it "papers over" the 1024 problem. Sep 13 16:32:18 but i don't want to add too many quirk-workarounds for sucky modems Sep 13 16:32:41 :) I agree. I wasn't even considering submitting such a horrible hack for inclusion. Sep 13 16:32:53 anyone knows how the build/tmp/work/x86-angstrom-linux/initramfs-image-1.0-r0/temp/log.do_rootfs.XXXXX are generated please ? Sep 13 16:32:54 It's just to make my phones somewhat usable, is all. Sep 13 16:33:05 (oops, be right back...) Sep 13 16:38:51 mickey, evening, not sure if its a bug, but i think frameworkd is registering too many bus names..all of them expose the same objects.. Wouldn't just org.freesmartphone.frameworkd do? or is it a known thingy? Sep 13 16:39:32 that's by design. every subsystem should be able to have its own bus name and this is an artefact of them being in the same linux process Sep 13 16:39:35 mickeyl: hey, have you thought about how you'd like FSO to handle wifi? I was thinking about working on it, but didn't know if you were thinking of a wpa_supplicant wrapper or full NetworkManager. Sep 13 16:39:47 and, if a wpa_supplicant wrapper, whether it needs its own dbus interface. Sep 13 16:39:56 cjb: tough question Sep 13 16:40:06 it depends on how good connman is Sep 13 16:40:18 i try to stay away from implementing anything network unless i need to Sep 13 16:40:30 yeah, me too; I prefer NM for that reason Sep 13 16:40:40 so hopefully only a very small dbus interface for some highlevel queries Sep 13 16:40:42 there are so many edge cases around authentication and stuff Sep 13 16:40:46 delegating the hard work to connman Sep 13 16:40:49 and/or wpa Sep 13 16:41:02 mickeyl, oh, ok....but why is org.fso.ogsmd exposing objects which is part of org.fso.odeviced? Sep 13 16:41:13 Sup3rkiddo: that's a bug in dbus Sep 13 16:41:15 ok. shall I try building connman? know if there's an OE package already? Sep 13 16:41:30 Sup3rkiddo: busnames are per process Sep 13 16:41:42 Sup3rkiddo: so once you register more than one, objects appear multiple Sep 13 16:41:52 perhaps a bus in python bindnigs of dbus Sep 13 16:41:53 dunno Sep 13 16:43:31 mickeyl, oh!, ok, by the way..i have started working on the C/vala implementation for the heck of it....created a branch in git.. Sep 13 16:43:53 ah, cool, but why a branch? Sep 13 16:44:02 why not just another repository? Sep 13 16:45:08 mickeyl, i was thinking of re-using the openmoko-gsoc2008 repos itself, as there is some common code...CPP (Copy Paste Protocol) would be easy that way :P Sep 13 16:47:18 well, ok i confess... i wanted to test the branching capabilities of git :/ Sep 13 16:48:33 hahah Sep 13 16:48:34 ok Sep 13 16:48:36 it's your call of course Sep 13 16:48:47 but a seperate repository would make it easier for me to contribute ;) Sep 13 16:49:24 mickeyl, yeah, you are write...git branch for later then...i will let you know once i have something worth pushing.. Sep 13 16:49:29 s/write/right Sep 13 16:49:42 ok, cool. just let me know and i'll create a new repo when you're ready Sep 13 16:49:53 mickeyl, yep..thanks a lot.. Sep 13 16:50:33 np Sep 13 16:51:19 mickeyl, i have created a presentation on FSO, have sent the link to the smartphones-list for comments.. Sep 13 16:51:30 *nod* already commented Sep 13 16:55:30 mickeyl, lol, the talk is on October 3rd :D Sep 13 16:56:59 ah, good Sep 13 16:57:05 where? Sep 13 16:59:49 mickeyl, IIT Madras. its only a small sub-conference, only 4 talks..But the there is a hackfest, a lot of people are interested in Openmoko here...so I will try my best to get people for a bug-jam on frameworkd then Sep 13 17:00:20 good plan! Sep 13 17:01:42 * mwester is lost in a maze of twisty little objects in frameworkd, all different. Sep 13 17:02:40 yeah, docs needed Sep 13 17:02:46 at least interfaces docs are there Sep 13 17:02:49 Ok, looks like modem.py has a timed callback -- is that a good example that I need to implement somewhere else to do a callback of this sort (Oh for the simplicity of the kernel!) Sep 13 17:03:10 if you have glib then yes Sep 13 17:04:15 planning to spend some weeks on docs and tests when i'm in .tw Sep 13 17:04:22 Hmmm.... I think it's getting too complicated. Maybe I can just launch another thread from the unsolicited message callback, and have it do the work. Assuming the framework is thread-safe... Sep 13 17:04:23 although that's always booooooooooooring Sep 13 17:04:33 (Docs are always boooring!) Sep 13 17:04:53 Which is why developers continue to look for a language that is truely "self-documenting" :D Sep 13 17:04:55 that's why i can't get our students to do it Sep 13 17:05:04 and need to do it on my own *sigh* Sep 13 17:05:28 That's also why tech writers are highly sought-after. Sep 13 17:07:34 mickeyl: If I sleep for a few seconds inside an unsolicitied-message handler, before making a decision on what to do with the message, does that stall all processing of GSM data, just the processing of unsolicited messages, or is each message handler invoked as a separate thread (and runs asyncronously)? Sep 13 17:08:14 neither :) Sep 13 17:08:32 if you sleep by using the mainloop, it's ok Sep 13 17:08:33 * mwester has demonstrated his lack of understanding of the code ;) Sep 13 17:08:43 unsol is called async from the mainloop Sep 13 17:09:00 so if you sleep by using mainloop, event processing continues Sep 13 17:09:11 but it's not threaded Sep 13 17:09:15 that'd be too heavy Sep 13 17:10:58 Ok, here's an example: Unsol. CREG is encountered; it calls into a method that queries the registration status of the modem, and broadcasts that via dbus -- the registration query involves sending AT command and reading them, and therefore has a sleep built in -- so one can assume that processing that original CREG will defer all other Unsol. message processing until the dbus message is sent? Sep 13 17:13:15 if you are really sleeping, then yes Sep 13 17:13:19 but you don't need to Sep 13 17:13:28 i'm using additional queries alright Sep 13 17:13:37 you just need to play with the mainloop Sep 13 17:13:39 then everything will be ok Sep 13 17:13:50 additional queries will get pushed into the AT queue Sep 13 17:13:54 then lateron processed Sep 13 17:14:05 and once the result comes, your original unsol callback will be called Sep 13 17:14:17 have a look into mediator.py Sep 13 17:14:50 Ok - I'll dig into that. Sep 13 17:15:19 But let me just post the specifics, and ask how you would approach the problem, if I may? Sep 13 17:15:33 The specific challenge is this: When we get a "de-register" message from the modem, we want to ignore it IFF we get a "register" message to the same carrier in about 2.5 seconds. Sep 13 17:15:44 This is easy if we get a follow-on message. Sep 13 17:15:54 aah Sep 13 17:15:57 that's what you want Sep 13 17:16:01 ok Sep 13 17:16:09 i'd patch unsolicited.py Sep 13 17:16:20 But I need a timed event scheduled for 3 seconds in the future, in case the deregister was legitimate -- it will be the only message we got to tell us that we entered a tunnel, for example. Sep 13 17:16:29 then you do Sep 13 17:16:43 gobject.timeout_add_seconds( deregister_timeout ) Sep 13 17:16:58 and continue as usual Sep 13 17:17:06 ah, actually Sep 13 17:17:10 you need to save the timeout watch Sep 13 17:17:25 self.deregister_timeout = gobject.timeout_add_seconds( 3, self.cb_deregisterTimeout ) Sep 13 17:17:36 if you see the register, you remove it w/ Sep 13 17:17:45 gobject.remove_source( self.deregister_timeout ) Sep 13 17:17:52 clear so far? Sep 13 17:18:13 :) Ah, excellent. I'll dig up the docs for the details, but the structure is what I hoped for. Sep 13 17:19:04 you know though that this will just cover up the symptom Sep 13 17:19:06 not the cause :) Sep 13 17:19:30 I might add that into the ti calypso specific code... Sep 13 17:19:34 Yes, a grotesque hack. but the hack without the timeout handling is working fine for me right now -- I can send/rcv SMS, calls, etc. with FSO MS3. Sep 13 17:19:58 I can add that the problem may be related to the calypso bouncing between cell sites. Sep 13 17:20:11 yeah Sep 13 17:20:22 luckily we have some news here Sep 13 17:20:45 my operator contact could finally reproduce that Sep 13 17:20:45 this contact has lab equipment Sep 13 17:20:49 (since they're a huge operator) Sep 13 17:20:57 and they're going to measure some things for us Sep 13 17:21:01 lets see Sep 13 17:21:23 I'm happy that work is continuing on this! Sep 13 17:21:33 well Sep 13 17:21:33 (but I would have thought that this would be driven out of .tw) Sep 13 17:21:35 not Openmoko work Sep 13 17:21:37 but still Sep 13 17:21:40 Ah. I see. Sep 13 17:21:41 my personal friends Sep 13 17:21:58 i'm afraid Om has given up on that, but don't quote me Sep 13 17:22:40 they have no gsm experts atm. Sep 13 17:22:57 (lowlevel gsm, that is) Sep 13 17:23:09 * mickeyl would consider being a highlevel GSM expert now Sep 13 17:23:11 ;) Sep 13 17:23:24 Well, I'll continue to gather data. I'm really interested to see if the timing details of this change or are consistent across the country here (Deregister events occur withing 20 - 30 seconds _always_, and are followed by a re-register within 2 - 2.8 seconds _always_) Sep 13 17:24:06 The interesting part is that I get reregistered to three different cells -- and all of them are very very close in signal strength. Sep 13 17:25:19 The consistent timing is the part that I think might make the "papering over" of the problem something that might be usable, as the risk of missing legitimate events could be made lower. Sep 13 17:27:36 yeah Sep 13 17:27:46 what's really interesting to me is that it's 100% only a problem in idle mode Sep 13 17:27:52 once a call is setup or a gprs connection, you're safe Sep 13 17:28:47 i can use gprs for >= 4 hours without any disconnect Sep 13 17:28:55 which is good! Sep 13 18:06:12 i would like to run a newer version of u-boot from memory first Sep 13 18:06:29 i have a freerunner, and have a working debian on the SD card Sep 13 18:06:50 I can fatload the image into memory, but don't know where to start it. Sep 13 18:06:54 Can anyone help? Sep 13 18:15:36 Hey Sep 13 18:16:21 AndreasD, you talked with Ainulindale ? Sep 13 18:20:47 trying to run the mokomakefile and it is failing with applying a patch to python-etk Sep 13 18:40:23 quickdev: nope, he still hasn't answered my mail :-( I think its about 10 days since I last talked to him Sep 13 18:40:45 he's having fun in the carribean ;) Sep 13 18:43:15 quickdev: any progress with the callStatus problem? did you check the frameworkd output? Sep 13 18:44:12 not yet, sorry. atm I'm using the HELD status for testing. but I'll figure it out at the beginning of the week Sep 13 18:46:25 okay, great! :-) Sep 13 18:48:25 thanks for your support btw. Sep 13 18:49:39 np and btw. thanks for the work you do :-) Sep 13 19:30:59 AndreasD: which mail ? Sep 13 19:38:38 Hello Ainulindale, the title is "Regarding patches for libframeworkd-glib", I sent it to your gmail Sep 13 19:42:45 Ainulindale: can you find it? or should I resend it? Sep 13 19:48:30 I'm ill so I'll check tomorrow, could you please ask me again then ? Sep 13 19:51:23 Ainulindale: oh, I'm sorry to hear that, yes sure! Hope you'll get well soon Sep 13 19:59:21 have a good evening, I'm off Sep 13 20:31:31 mickey|sofa: you alive? Sep 13 21:31:39 I am trying to understand the mokomakefile Sep 13 21:32:02 doesn't it just grab all the code thats needed and build it? so why would glibc not be available for pth ? Sep 13 21:45:10 zion: MokoMakefile is just a 'driver' to make OpenEmbedded do the work, so if you don't understand then look up help for that instead perhaps.. Sep 13 21:45:13 you have a build error? Sep 13 22:29:29 mickey|sofa: Thanks for your pointers on the timeout stuff; it's saved me hours of re-implementing something that turned out to be remarkably simple in the end. :) Sep 13 22:37:06 * rwhitby thinks mwester is becoming a low level GSM expert ... Sep 13 22:37:24 in addition to being the community kernel expert ... Sep 13 22:39:15 :) No, I'm just filling the role of the "pit mechanic" -- ugly hacks and patches to just "make it work". :D Sep 14 01:12:30 Weiss: right now I am just trying any and every possible method to get something/anything to work.... I tried toolchain page, didm't work... been poking at the MokoMakefil all day... Sep 14 01:12:39 build error: pth_mctx.c:476:2: error: #error "Unsupported Linux (g)libc version and/or platform" Sep 14 01:13:02 Hello all -- I'd like to apply the XGlamo patch which fixes X-Coordinate on rotation. I've downloaded a snapshot of the git tree. And am trying to run om-conf on the tree. I am getting some errors, but should be able to work through this. Sep 14 01:13:14 trying to rebuild glibc now ... see if that will fix it Sep 14 01:13:45 Am I going down the right path? Once I compile this, do I make a IPK and replace the xserver-kdrive-glamo package on my phone? (OM2008.8-update) Sep 14 01:15:19 scarlson: wish I could, no idea since I am still trying to get MokoMakefil to work Sep 14 01:15:32 s/could/could help/ Sep 14 01:15:57 zion: You should post a bit more context than just one line Sep 14 01:16:05 (pastebin, of course) Sep 14 01:17:26 http://pastebin.com/d20e33bb0 Sep 14 01:21:45 any ideas? Sep 14 01:21:46 What image are you building, and on what type of host? Sep 14 01:22:13 make image Sep 14 01:22:34 amd64 Sep 14 01:22:36 gentoo Sep 14 01:22:49 gentoo? 64-bit host? Sep 14 01:22:56 yes Sep 14 01:23:20 You're into uncharted territory Sep 14 01:23:36 really? its just linux right? Sep 14 01:23:47 wait... is 64 bit the uncharted part? Sep 14 01:24:17 Isn't gentoo the one where you compile it yoursefl, instead of installing standard binaries? And 64-bit has also been problematic, although I think some have gotten it to work. Sep 14 01:24:58 emerge package-name vs apt-get install package-name Sep 14 01:25:10 and emerge builds it from source... so its not that manual Sep 14 01:25:11 Gentoo is uncharted, 64-bit is a path that's been charted but is like a swamp -- the path seems to shift under your feet, and what worked last week may not work tomorrow... Sep 14 01:25:43 so a 32bit chroot then? Sep 14 01:26:03 really don't want to toast yet another day on a dead end Sep 14 01:26:32 manual or not, it's not as repeatable as it needs to be. I'd recommend you go with ubuntu, debian, fedora running 32-bit to build it, and then you can compare with your gentoo 64-bit and see where things start to go wrong. Sep 14 01:28:29 let me ask this instead; my real goal is to write an app, run+debug it on workstation. the mokomakefile is the best path for that? Sep 14 01:29:34 If your app has many dependencies that are not part of the standard toolchain, then yes. If it's dependencies are met by the standard toolchain, then download that and use it insted. (much simpler) Sep 14 01:30:37 my problems with the toolchain were a hardcoded path of /home/build/internal-daily/... for lib look ups Sep 14 01:30:55 I had no idea how fix that, except to rebuild the toolchain from source Sep 14 01:32:05 so looks like a vmware of ubuntu Sep 14 01:32:38 Er, why not just untar it into that location? Sep 14 01:33:10 I found a package 1.2.0-r24 replaced it with the one that came with OM2008.8update 09-13-2008 and .. well xrandr doesn't like me anymore. Sep 14 01:33:10 cause the location is 15dirs deep, and docs state to put in /usr/local/openmoko Sep 14 01:33:39 What is the most efficient way to apply this PATCH that I have, so I can move on with the Application that I am developing.. any suggestiosns? Sep 14 01:33:53 that and it looks for libs there... so rebuildimg all the libs and installed with a destdir ofr that seems... well a huge bug Sep 14 01:33:55 The toolchain should be in /usr/local/openmoko indeed. How did you determine the library issue? Sep 14 01:34:14 trying to use the sample2 Sep 14 01:34:39 running make there tries looking for libs im that dir Sep 14 01:34:59 Ok. Well, there's nothing there that some command-line args and/or sym links can't fix -- but even if you don't want to do that, the external toolchain should be fixed. Sep 14 01:35:08 Did you report this on the mailing list? Sep 14 01:35:26 not yet Sep 14 01:35:56 kind of flailing about blind here... getting that grossly inept feeling Sep 14 01:36:11 Ok. So you can either go with a binary distro that's been proven to work with the Om builds, and use the full build environment, or Sep 14 01:36:27 you can work on the toolchain approach and see if that can work for you. Sep 14 01:36:46 Either way will be some effort it seems. Sep 14 01:37:24 will just do the ubuntu route Sep 14 01:39:37 Ok. Go for 32 bit, and avoid anything that's really really new (like in the last couple months or so) as you don't want to be trailblazing. I don't use ubuntu so I have no idea what you want to run. I know Fedora 9 works find. Sep 14 01:40:20 Inquisitive Iguana? Jumping Jackal? :D Sep 14 01:50:32 http://lists.openmoko.org/nabble.html#nabble-td677542 Sep 14 01:50:40 This is the patch that I'm referring to. Sep 14 01:51:04 I'm sorry if this seem rudimentary, but I'm very new with this project/cross-compiling and the toolchain in general.. Sep 14 02:17:28 zion: for the python-etk this is a bug from upstream Sep 14 02:17:53 it seems that the maintainer already has applied the patches Sep 14 02:19:33 see : community mailing list Sep 14 02:20:29 I post a patch that just exclude the two patches from the bb file Sep 14 02:21:00 -SRC_URI = "git://staff.get-e.org/users/cmarcelo/python-etk.git;protocol=git \ - file://scrolled_view-drag.patch;patch=1 \ - file://scrolled_view-drag-extra.patch;patch=1 " +SRC_URI = "git://staff.get-e.org/users/cmarcelo/python-etk.git;protocol=git " Sep 14 02:21:20 from penembedded/packages/python/python-etk_git.bb Sep 14 02:46:48 configure: error: cannot check for file existence when cross compiling Sep 14 02:48:21 I am having a heck of a time tracking this.. that error comes from OM-CONF .. there is no configure.in file.. so i decided to comment out the lines that caused this error in aclocal.m4 but someone else generates this file.. Sep 14 02:49:19 and I can't grep my way to the culprit. **** ENDING LOGGING AT Sun Sep 14 02:59:56 2008