**** BEGIN LOGGING AT Mon Sep 28 02:59:57 2009 Sep 28 06:07:01 raster: ping Sep 28 06:07:27 raster: after the switch to xorg we are having a problem with the power button Sep 28 06:07:56 raster: it does work after configuring it via the illume settings - but only until next reboot Sep 28 06:08:26 raster: then it does not work anymore until you go to illume keybindings settings and do some bogus change Sep 28 06:08:30 raster: any idea? Sep 28 06:09:33 mrmoku: rm -r ~/.e Sep 28 06:09:35 ;) Sep 28 06:09:43 PaulFertser: nah :P Sep 28 06:09:55 PaulFertser: on every boot? ;) Sep 28 06:10:09 mrmoku: have you tried it at least once? ;) Sep 28 06:10:31 PaulFertser: well... of course... and I'm not talking about updates... I'm talking about our fresh xorg image Sep 28 06:10:53 so there should be no need to do it (at least no difference in the result as .e will be recreated the same way) Sep 28 06:11:12 PaulFertser: and Weiss has the same thing Sep 28 06:11:27 funny Sep 28 06:12:05 PaulFertser: less funny if you try to offer people some image to use :P Sep 28 06:13:23 mrmoku: not sure. the default config was hooked to a specific keycode Sep 28 06:13:38 e will see its a keycode not a keysym and try bind the keycode directly Sep 28 06:13:56 i guess if that keycode is invalid at the time of binding... or if tis invalid when e starts it will fail Sep 28 06:14:18 e doesnt give errors on bindings failing as its going to be a problem for universal configs on multiple systems - too many erros on start Sep 28 06:14:22 raster: hmm... how could it happen to be invalid? Sep 28 06:14:28 try restart e Sep 28 06:14:38 does it work then Sep 28 06:14:40 dont change config Sep 28 06:14:42 just restart e Sep 28 06:15:03 (killall - HUP will do) Sep 28 06:16:19 raster: ok, I have XF86Phone and XF86PowerOff configured in keybindings Sep 28 06:16:36 the phone one works and the poweroff not Sep 28 06:16:47 before it was Execute (for kdrive) Sep 28 06:17:42 the XF86PowerOff is what e tells me when I click on Add Key in the keybindings config Sep 28 06:18:49 is poweroff set up by xmodmap Sep 28 06:18:56 ? Sep 28 06:19:01 ie thats a keysym (key symbol) Sep 28 06:19:10 hmm, it is what e autodetects Sep 28 06:19:22 it could be that u run xmodmap or some modification of the keymnap that makes that valid AFTEr e starts Sep 28 06:19:26 sure Sep 28 06:19:31 what it detects WHEN u configure the binding Sep 28 06:19:36 at that time that symbol is valid Sep 28 06:19:42 thus why - i asked, if u restart e Sep 28 06:19:46 root@om-gta02 ~ $ xmodmap -pk | grep -i poweroff Sep 28 06:19:49 tells me nothing Sep 28 06:20:07 with -pm neither Sep 28 06:20:13 (eg reboot then it doesnt work - just killall -HUP enlightenment, then try) Sep 28 06:20:19 ahh ok Sep 28 06:20:44 e gets the keysym from the keycode Sep 28 06:20:48 when u bind it Sep 28 06:20:54 and if a keysym exists - uses that Sep 28 06:21:01 otherwise it gets a keycode and bindsa that Sep 28 06:21:03 no, still not working Sep 28 06:21:07 it asks xlib for this info Sep 28 06:21:19 and now the phone one is not working too Sep 28 06:21:25 what does e's settings say? Sep 28 06:21:36 has somethign else grabbed them? Sep 28 06:21:40 xev will tell u Sep 28 06:21:49 either nothgn grabbed them and when u press them u get key presses Sep 28 06:21:56 and u'll see what presses they are Sep 28 06:21:58 KeyPress event, serial 27, synthetic NO, window 0x1000001, root 0x47, subw 0x0, time 4283363530, (220,158), root:(220,212), state 0x0, keycode 124 (keysym 0x1008ff2a, XF86PowerOff), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Sep 28 06:22:21 or u'll see focuse out events, docus in and keymap notify events Sep 28 06:22:28 meaning somethign grabbed the key and is getting it Sep 28 06:22:56 after the KeyPress there is just a KeyRelease and a LeaveNotify event Sep 28 06:22:59 nothing focus Sep 28 06:23:22 ok nothnig has grabbed it Sep 28 06:24:58 raster: if I now go to the keybindings... just do some bogus change to be able to click ok... the key works Sep 28 06:25:19 and I don't get a KeyPress event anymore... get some KeymapNotify instead Sep 28 06:25:22 ??? Sep 28 06:25:26 that doesnt make any sense Sep 28 06:25:37 keybindings are grabbed at the same time - on init Sep 28 06:25:49 same call that re-grabs them on config change (well ungrabs then grabs again) Sep 28 06:26:07 if that stopped working on start - all my current keybindings would work Sep 28 06:26:10 and they do work Sep 28 06:26:15 every single one Sep 28 06:26:34 xorg vs kdrive doesnt make a difference - its still x client and x server Sep 28 06:26:43 they keycode/keysym used may change Sep 28 06:26:55 don't know if it's related... it is handled via evdev now Sep 28 06:27:31 raster: could it be that e is not correctly recompiled against the new x stuff? Sep 28 06:27:45 the code calls Sep 28 06:27:49 e_managers_keys_ungrab() Sep 28 06:27:52 hmm... probably not... we did a rebuild from scratch Sep 28 06:27:55 and then e_managers_keys_grab() Sep 28 06:28:01 when config is applied (changed) Sep 28 06:28:27 that calls e_bindings_key_ungrab() and and e_bindings_key_grab() for each root window you have Sep 28 06:28:31 (respectively) Sep 28 06:29:00 and so on Sep 28 06:29:15 e_managers_keys_grab(); Sep 28 06:29:26 is also called from e's main() in the init code Sep 28 06:29:51 near the end actually of the init phase Sep 28 06:30:02 its the same call Sep 28 06:30:13 goign thru the same data structs and same config callign the same grab calls Sep 28 06:30:35 all i can imagine is - those grabs are failing on start for some reason (or restart - same init code in the end) Sep 28 06:31:38 raster: if the key is working... doing a killall -HUP enlightenment... and the key does not work anymore Sep 28 06:31:43 so yes init and restart is the same thing Sep 28 06:32:02 ahh... no wait Sep 28 06:32:06 it *is* still working Sep 28 06:32:24 aha! Sep 28 06:32:45 so my first theory. when e starts - when your x session starts, that keysym doesnt exist. Sep 28 06:32:52 it is made to exist some time later after e has started Sep 28 06:33:08 (possibly by some xmodmap call during the x session init) Sep 28 06:37:11 raster: ok, thanks so far... will try to find... after some daywork :( Sep 28 06:37:49 raster: ahh one thing... would using Keycode-xxx solve it? Sep 28 06:41:30 yes - if u know the keycode Sep 28 06:41:37 keycodes are device dependant Sep 28 06:41:41 eg they change from keyboard to keyboard Sep 28 06:41:48 keysyms are meant to be "portable" Sep 28 06:42:06 ie ways of naming a key in a known portable way regardless of the hardware-level "keycode" you get Sep 28 06:42:15 thus e prefers keysyms if it can find them Sep 28 06:42:57 ok Sep 28 06:43:01 stylesheetsw now do work Sep 28 06:43:04 i didnt copy all the files Sep 28 06:43:05 now done Sep 28 06:43:35 some are broken Sep 28 06:47:10 efreet as it uses images Sep 28 06:47:12 not img Sep 28 06:47:18 should fix that Sep 28 06:47:32 oops Sep 28 08:51:55 morning Sep 28 08:52:24 can someone tell me what's the source of the problem here? Sep 28 08:52:24 blindcoder@fortuna:/tmp$ git fetch git://gitorious.org/webkit-efl/webkit-efl.git master Sep 28 08:52:28 fatal: Not a git repository Sep 28 08:52:48 It's the error I get when running bitbake -iparse Sep 28 08:53:51 blindcoder: git fetch works only in git repositories Sep 28 08:54:05 blindcoder: you probably want git clone Sep 28 08:54:45 PaulFertser: git fetch is run by bitbake Sep 28 08:55:23 NOTE: bb.fetch.FetchError:Fetch command export git fetch git://gitorious.org/webkit-efl/webkit-efl.git master failed with signal 128, output: Sep 28 08:55:29 fatal: Not a git repository Sep 28 08:55:46 that's the output from bitbake -i parse Sep 28 08:56:55 after that bitbake terminates Sep 28 08:59:01 blindcoder: i guess that it means bitbake thinks that it's already created a repository with git pull or git init before. Sep 28 08:59:19 PaulFertser: where would that be? any idea? Sep 28 09:01:39 blindcoder: there's some switch to bitbake to trace its execution Sep 28 09:37:50 PaulFertser: download/git/gitorious.org*webkit* Sep 28 09:42:29 blindcoder: so go there and manually clone first Sep 28 09:42:47 blindcoder: or find an appropriate "bitbake -c" option to do that. Sep 28 10:01:50 blindcoder: or just 'rm -rf download/git/gitorious.*' Sep 28 10:01:55 and retry then Sep 28 10:07:28 mrmoku, got a screenie of gtk-theme-neo? Sep 28 10:07:40 TAsn: no Sep 28 10:07:50 okie, thanks. Sep 28 10:08:06 what for :P Sep 28 10:08:17 just saw there's a new gtk theme Sep 28 10:08:22 and wanted to see how it looks like Sep 28 10:08:23 :) Sep 28 10:09:38 TAsn: install and try it then... and post a screenie for me to see it ;) Sep 28 10:09:51 nah ;) Sep 28 10:09:54 I learned my lesson Sep 28 10:09:58 when it works Sep 28 10:10:00 don't touch it Sep 28 10:10:03 :) Sep 28 10:10:26 :) Sep 28 10:10:33 and actually it works quite well atm. Sep 28 10:10:42 mrmoku, anyhow, what about testing/fixing builds? Sep 28 10:10:47 what seems to be the issue? Sep 28 10:11:14 TAsn: issue is that we switched to xorg... and might not want that for testing yet Sep 28 10:11:40 finally! Sep 28 10:11:41 so either we have to somehow make testing build without it... or add a branch for testing Sep 28 10:11:47 I was waiting for that switch for a long time :) Sep 28 10:12:06 mrmoku, are you using xorg atm? Sep 28 10:12:08 TAsn: thank JaMa and Heinervdm for that Sep 28 10:12:12 TAsn: yep using it Sep 28 10:12:29 how can I switch? Sep 28 10:12:36 (shit, I promised I won't though it if it works) Sep 28 10:12:53 where do your feed configs point to? Sep 28 10:13:27 src/gz shr-armv4 http://build.shr-project.org/shr-unstable/ipk//armv4 Sep 28 10:13:32 src/gz shr-armv4t http://build.shr-project.org/shr-unstable/ipk//armv4t Sep 28 10:13:32 src/gz shr-om-gta02 http://build.shr-project.org/shr-unstable/ipk//om-gta02 Sep 28 10:13:32 src/gz shr-all http://build.shr-project.org/shr-unstable/ipk//all Sep 28 10:13:34 if they point to tests/mrmoku you can just opkg -force-reinstall install task-x11-server Sep 28 10:13:49 ahh... ok. Just wait till I sync the feed this afternoon then :P Sep 28 10:14:08 mrmoku, cool enough ;) Sep 28 10:14:11 * mrmoku has to run and pickup son from the kindergarten now Sep 28 10:14:14 bbl Sep 28 10:14:18 enjoy. Sep 28 13:00:25 TAsn: ping Sep 28 13:01:17 mrmoku, pong. Sep 28 13:01:28 TAsn: once again I'm having problems with your evas patches ;) Sep 28 13:02:14 mew Sep 28 13:02:24 :) Sep 28 13:02:27 mrmoku, hehe thought so. Sep 28 13:02:46 fyi. elementary docs are now live on line updated daily Sep 28 13:02:48 http://docs.enlightenment.org/auto/elementary/ Sep 28 13:03:01 raster: ohh, good thing :D Sep 28 13:03:20 well u can alkwasy do Sep 28 13:03:20 mrmoku, I should really fix the bugs and just send it to raster so he'll commit them upstream ;) Sep 28 13:03:20 I just don't have a lot of free time, but bah, I should do it already. Sep 28 13:03:20 mrmoku, what seems to be the problem? Sep 28 13:03:24 "make doc" in the src tree Sep 28 13:03:38 raster, cool :) Sep 28 13:03:38 TAsn: they don't apply :P Sep 28 13:03:40 TAsn: any time. if there arent bugs :) Sep 28 13:03:46 *cough* finally *cough* Sep 28 13:03:47 :) Sep 28 13:04:01 hehehehe Sep 28 13:04:22 mrmoku, I figured that myself Sep 28 13:05:23 TAsn: failing for src/modules/engines/cairo_x11/evas_engine.c Sep 28 13:05:48 and src/lib/engines/common/evas_intl_utils.c Sep 28 13:05:55 I meant are there many conflicts? Sep 28 13:05:55 or just a couple of minor ones? Sep 28 13:05:55 * TAsn is checking out evas Sep 28 13:05:56 and src/lib/engines/common/evas_font_main.c Sep 28 13:06:02 and src/lib/canvas/evas_object_textblock.c Sep 28 13:06:12 and src/modules/engines/cairo_x11/evas_engine.c Sep 28 13:06:14 really? intl_utils? that's odd Sep 28 13:06:21 sec, I'll try to fix the patches here. Sep 28 13:06:27 TAsn: thanks :) Sep 28 13:06:47 mrmoku, so it fails everywhere :) Sep 28 13:06:56 almost ;) Sep 28 13:07:57 evas_private.h Evas.h and src/lib/engines/common/evas_font_draw.c succeed with offset Sep 28 13:10:15 mrmoku, yeah, well I'll just generate a new patch Sep 28 13:10:42 TAsn: dos1 will be very gratefull... because then I will bump the EFL :) Sep 28 13:10:44 raster, I'll send you a patch with minor changes soon Sep 28 13:10:53 :) Sep 28 13:11:16 no bugs, I promise Sep 28 13:11:17 :) Sep 28 13:11:22 hahahahaa Sep 28 13:11:28 famous last words! Sep 28 13:11:29 :) Sep 28 13:11:29 :) Sep 28 13:11:36 I'll just change the files I created Sep 28 13:11:42 i.e intl_utils and such Sep 28 13:12:16 someone evil changed the indentation in the file :| Sep 28 13:12:21 sec. Sep 28 13:13:16 no wait, that's not it. Sep 28 13:24:56 mrmoku: (rm -f *gitorious*) that's what I did, and it worked fine, thanks :) Sep 28 13:25:08 blindcoder: good :) Sep 28 13:32:56 mrmoku, ok, looks like I'm done, sec a bit of testing first. Sep 28 13:33:18 testing sounds like a good idea :P Sep 28 13:34:14 I don't have a lot of time though, so I'll only be able to do mild testing. Sep 28 13:34:20 raster, ping. Sep 28 13:34:33 mild testing has to suffice then Sep 28 13:34:54 * mrmoku wants a fresh xorg unstable image with newest EFL today :) Sep 28 13:35:03 :) Sep 28 13:35:16 mrmoku: not only you ;) Sep 28 13:35:29 soltys: I know :) Sep 28 13:35:36 ;) Sep 28 13:36:20 having build faulre on libXxf86dga for a couple of days - is there a fix? - error makes it seem like Sep 28 13:36:33 something is missing - maybe version problems. Sep 28 13:37:26 BillK_: you have to manually build something first... moment Sep 28 13:37:45 actually, mrmoku I'll send you a patch that compiles Sep 28 13:37:49 and will test later :) Sep 28 13:38:05 BillK_: xf86dgaproto Sep 28 13:38:06 how does that sound? Sep 28 13:38:40 TAsn: well... as long as it applies and compiles I'm happy... for raster that won't be enough though :P Sep 28 13:38:52 tkx, bitbake that first I presume ... Sep 28 13:38:53 so gimme your patch :) Sep 28 13:39:17 BillK_: yep... strange thing is that it is a depend of it... so it should automatically build it... but it doesn't :( Sep 28 13:39:54 mrmoku, I know, I just sent him a pm. Sep 28 13:40:03 weepee it applies. Sep 28 13:40:09 mrmoku: tkx, much appreciated. Sep 28 13:40:10 and compiles Sep 28 13:40:19 BillK_: np Sep 28 13:41:34 TAsn: because your short of time you can just send me your patch via mail... otherwise I would require you to go with a nice OE patch via patchwork ;) Sep 28 13:42:01 :) Sep 28 13:42:06 mrmoku, thanks. Sep 28 13:42:25 TAsn: thanks for adjusting your patch fast Sep 28 13:43:41 thanks for willing to accept a source patch and not an OE patch :) Sep 28 13:43:57 and for not spanking me for being too lazy to fix the issues and send thet patches upstream ;) Sep 28 13:44:10 :P Sep 28 13:44:22 will leave the spanking to others this time :) Sep 28 14:16:37 xorg-xserver RC3 is out? Sep 28 14:16:53 there appeared a new tag for this in git Sep 28 14:21:18 dos1: today I will make you happy :) Sep 28 14:22:11 Heinervdm: as we're on AUTOREV and I will build a new unstable image today... we might be the first distro including it :P Sep 28 14:22:44 mrmoku: we moved to autorev? Sep 28 14:22:49 Heinervdm: btw... are you into X keysymbol names? Sep 28 14:22:52 mrmoku: hmm? :) Sep 28 14:22:52 Heinervdm: we are not? Sep 28 14:23:05 dos1: going to bump EFL today Sep 28 14:23:10 yaaaaaay!!! Sep 28 14:23:11 :D Sep 28 14:23:20 mrmoku: but well, i'll have more work then Sep 28 14:23:25 as i have to update niebiee theme ;) Sep 28 14:23:29 yup ;) Sep 28 14:23:39 and it has to build first on my laptop Sep 28 14:24:04 mrmoku: i think we build xserver-xorg_1.6.99.902.bb and that's from a tar.gz Sep 28 14:24:17 ahh... ok :( Sep 28 14:25:04 Heinervdm: if you have time I will happily apply a patch updating that then Sep 28 14:25:08 we had AUTOREV just after switching to xorg Sep 28 14:25:20 but then we switched back to releaser Sep 28 14:25:26 as far as i noticed from patches ;) Sep 28 14:26:05 where is preferred version for shr defined now? -xorg.inc is gone... Sep 28 14:26:33 -live.inc... Sep 28 14:27:05 SRCREV_pn-xserver-xorg = "${AUTOREV}" Sep 28 14:27:12 is in shr-autorev-unstable.inc Sep 28 14:27:23 and that includes also the -live.inc Sep 28 14:27:33 PREFERRED_VERSION_xserver-xorg ?= "1.6.99.902" in -live Sep 28 14:27:37 so not git Sep 28 14:29:19 mrmoku, still here? Sep 28 14:29:25 yup Sep 28 14:29:41 I want to bug you :) Sep 28 14:29:47 try ;) Sep 28 14:30:00 mrmoku, I split the patch to two parts Sep 28 14:30:05 one I'm sending to raster Sep 28 14:30:15 and he'll commit sometime soon (hopefully) Sep 28 14:30:49 Will try to compile RC3 now Sep 28 14:31:10 TAsn: just splitted or modified too? Sep 28 14:33:02 and the second is the additional patching needed for full rtl support Sep 28 14:33:02 so next bump we'll be able to drop just one patch and everything will hopefully go smooth. Sep 28 14:33:46 TAsn: ok, mail me Sep 28 14:36:22 mrmoku, split Sep 28 14:36:36 sec, I'm testing it a bit Sep 28 14:37:01 just to make sure it's split correctly Sep 28 14:58:05 mrmoku, man, my computer is slow :) Sep 28 14:58:09 taking ages to compile... :| Sep 28 14:58:34 that's why I I said I wouldn't test it in the first place, but whatever... :) Sep 28 14:58:47 I'm already half way through. Sep 28 14:58:49 kinda Sep 28 14:58:55 hehe... we should find somebody to sponsor us some i7 ;) Sep 28 14:58:56 mostly. Sep 28 14:58:56 :)\ Sep 28 14:58:56 :) Sep 28 14:59:11 aye! Sep 28 14:59:47 A desperate developer is looking for a decent CPU. Sep 28 15:00:01 :) Sep 28 15:00:08 mrmoku: sponsoring is a general demand :-/ Sep 28 15:00:42 yup... and sponsors seem to be hiding :P Sep 28 15:02:27 hmm, sometimes I think it's me hiding from sponsors... but no. Probably there simply is no sponsoring for a hw-sw communicatinf systems engineer Sep 28 15:04:09 atm I got P4 on my desktop Sep 28 15:04:09 and a P3 on my laptop Sep 28 15:04:09 :| Sep 28 15:04:09 I really gotta get myself a couple of additional cores Sep 28 15:04:09 :| Sep 28 15:04:11 * TAsn is going back to his school work. Sep 28 15:04:13 brb when it's done compiling. Sep 28 15:05:54 yay, I got a sponsor. Sep 28 15:06:03 TAsn-Redbull: lol. Sep 28 15:06:05 :) Sep 28 15:07:34 TAsn-Redbull: stop moaning as long as you don't have to build on a P-II-233 with 128MB of RAM. *that's* really getting a PITA Sep 28 15:09:13 well, it's been a nice reference platform for Neo performance, back when I got no real OM hw Sep 28 15:10:35 I'm building on a Sep 28 15:10:46 P3 600mhz 128ram (or maybe 256?) atm Sep 28 15:10:57 so it also sucks Sep 28 15:11:09 they weren't paying enough :| Sep 28 15:12:07 hadware is cheap, guys! Sep 28 15:12:15 TAsn: aah, and I thought it was because of the part in contract that request you drinking that stuff all the time ;-) Sep 28 15:12:20 money is rare though :( Sep 28 15:12:22 * mwester builds on a quad-core with 8GB of RAM. :D Sep 28 15:12:51 mwester: \o/ :-DD Sep 28 15:13:07 mrmoku: rc3 built Sep 28 15:13:23 any of you happen to know if the arm cross compiling stuff in recent fedora releases can be used to compile apps for the fr? Sep 28 15:13:26 Yeah. Unfortunately, the way OE and bitbake work, that usually means I have three cores idle and 7GB of ram unused... Sep 28 15:13:38 mwester: would you mind getting tim-rikers apt on this chan? Sep 28 15:14:10 I don't know how -- if I did, I wouldn't have spent the effort to get bzzbot running. Sep 28 15:14:29 If someone knows how to do that, I can kill off that stupid troublesome bot i have running :D Sep 28 15:14:32 that's why I ask. I actually know how Sep 28 15:14:38 Oh - please do! Sep 28 15:15:14 bye-bye bzzbot! Sep 28 15:15:18 ok, so I'll manage to get apt, and you may replace "~" with "!" for bzzbot Sep 28 15:15:18 Hi mrmoku, insane yet? ;-) Sep 28 15:15:41 always been insane... but not in sane yet ;) Sep 28 15:15:47 ;-) Sep 28 15:15:54 mwester: there's been sad feelings about losing bzzbot completely Sep 28 15:16:08 mwester: dunno why ;-P Sep 28 15:16:15 mrmoku: patch in patchwork :) Sep 28 15:16:23 Heinervdm: thanks very much :) Sep 28 15:16:44 :( I'm travelling a lot for work -- to a company that has high security. So I can't login in very often to check if bzzbot is actually working... I think it has been down more often that up lately. Sep 28 15:17:19 mwester: so you're ok with me kicking bzzbot when I get apt here? Sep 28 15:17:29 Yep. Sep 28 15:17:38 fine :-) Sep 28 15:18:22 Schorhr: though... I have good news. scanimage is part of sane-backends Sep 28 15:18:27 mwester: I'd appreciate if you'd change the ~ then, and give me notice to re-enable bzzbot after you changed that Sep 28 15:18:46 mwester: *after* the apt invite Sep 28 15:18:50 # sane-backends - includes: backends (scanner drivers), command-line-frontend (scanimage), network scanning daemon (saned) and SANE-API documentation. Sep 28 15:19:38 edje needs lua now :P Sep 28 15:21:55 Heinervdm: your patch has --disable-xephyr thice Sep 28 15:21:59 s/thice/twice/ Sep 28 15:22:24 dos1: then it was in the RC2 recipe too :) Sep 28 15:22:40 ;) Sep 28 15:23:03 good thing... to make it explicitely clear we don't want xephyr ;) Sep 28 15:23:11 dos1: so it's JaMa's fault ;) Sep 28 15:24:46 mrmoku: So it does work allready? Sep 28 15:25:02 I know it's sick, but...: http://scap.linuxtogo.org/files/448f5f9cfad119bba40586bac626dc21.png Sep 28 15:25:05 Schorhr: the backends build yes Sep 28 15:25:08 dwm on SHR :) Sep 28 15:25:43 blindcoder: hmm... how to install that? I might want that to fix the resizing of our apps :) Sep 28 15:26:07 DocScrutinizer-8, (drinking redbull) like I'd agree to that, we had mutual understanding that I only drink it for photo-shoots, and I'm allowed to spit it between scenes. Sep 28 15:26:10 So whats missing/what's in the frontend? Sep 28 15:26:32 mwester, not all of us live in the us :| Sep 28 15:26:38 here hw is not *that* cheap :) Sep 28 15:26:48 TAsn: that's just enough of contact to toxic waste :-P Sep 28 15:27:04 mrmoku: want an .ipk? Sep 28 15:27:06 well, unfortunately that's what pays the bills :| Sep 28 15:27:11 mrmoku: or better, a recipe? Sep 28 15:27:22 blindcoder: recipe would be fine, yes :) Sep 28 15:27:27 correction: used to pay, as I said, I ditched them :) Sep 28 15:27:28 *wink* Sep 28 15:28:02 mrmoku: http://pallas.crash-override.net/~blindcoder/dwm.tar.bz2 Sep 28 15:28:07 Schorhr: frontends has: sane-frontends - includes: graphical frontends (scanning applications) xscanimage and xcam, command-line-frontend scanadf. You don't need this package if you use one of the more advanced graphical frontends like XSane Sep 28 15:28:20 mrmoku: details (license, homepage, etc) are wrong, but it works fine Sep 28 15:28:23 TAsn, you need a beer company as a sponsor, perhaps then you won't have to spit! Sep 28 15:28:27 blindcoder: ok, thanks Sep 28 15:29:00 mwester, beer companies are hard to get as sponsors in this field, because here it's illegal to drink and code. Sep 28 15:29:06 mrmoku: after that, just create an executable ~/.Xsession with "exec /usr/bin/dwm" in it to start Sep 28 15:29:24 TAsn: that's too bad. :( How about a coffee company, then? Sep 28 15:29:26 blindcoder: what about keyboard? Sep 28 15:29:34 mrmoku: So I can scan using scanimage, and write myself a few scripts (for example "scan150dpi" or similar) and skip the frontend Sep 28 15:29:44 Schorhr: yep Sep 28 15:29:58 Schorhr: still have to build it on the buildhost and sync it to the feed though Sep 28 15:30:03 Schorhr: and you need to reflash ;) Sep 28 15:30:09 mrmoku: That's awesome. Sep 28 15:30:15 mrmoku: how upgrade went? Sep 28 15:30:15 mrmoku: I use literki Sep 28 15:30:18 mrmoku: Okey nlo rush: ) Sep 28 15:30:46 *no rush Sep 28 15:31:52 dos1: upgrade went fine Sep 28 15:32:07 dos1: it did not install xorg though Sep 28 15:32:18 dos1: for that I bumped task-x11 PR ;) Sep 28 15:32:24 dos1: so next time it will Sep 28 15:32:29 ;) Sep 28 15:32:42 mrmoku: but it worked? did you synced feed? Sep 28 15:32:56 dos1: not yet... first new EFL :P Sep 28 15:33:00 and a new image Sep 28 15:33:14 and we need to fix the power button Sep 28 15:34:16 what's wrong with power button? Sep 28 15:34:42 with xorg it is no longer Execute Sep 28 15:34:50 it is XF86PowerDown Sep 28 15:34:58 (and XF86Phone for Aux) Sep 28 15:35:09 but that symbol somehow is not known to e on startup Sep 28 15:35:39 it is later, because that is what the keybinding config tells you when pressing it Sep 28 15:36:07 mrmoku: did you ask raster? ;) Sep 28 15:36:25 yep Sep 28 15:36:27 mrmoku: is there some binary value that we can use? Sep 28 15:36:34 was talking with him about that this morning Sep 28 15:36:42 Heinervdm: we could use the keycode Sep 28 15:36:51 that is not portable to other hw though Sep 28 15:37:25 I would prefer to find out why it is not yet known on startup Sep 28 15:37:41 err... XF86PowerOff is its name Sep 28 15:40:55 Heinervdm: maybe recompiling e against the new xorg headers will do the trick Sep 28 15:41:21 not sure abou that though... because dos1 did a rebuild from scratch on the buildhost Sep 28 15:44:32 but why is it found after editing the config? if the symbol is there it should work and the symbol shouldn't apear after editing the config Sep 28 15:48:52 ffs Sep 28 15:48:55 stupid power out. Sep 28 15:48:55 :| Sep 28 15:49:18 at least I got sick and moved to compiling on my desktop instead of my laptop Sep 28 15:49:28 Heinervdm: I think e requeries the symbols in the config Sep 28 15:51:17 Heinervdm: btw, thanks for the efforts you put towards the Xorg move :) Sep 28 15:51:25 I've been waiting for this for a couple of months now :) Sep 28 15:51:31 mrmoku: btw, did you sync? Sep 28 15:51:34 can I get xorg? :) Sep 28 15:51:47 nah... still solving some problems Sep 28 15:51:51 okie. Sep 28 15:51:57 TAsn: that was JaMa's effort ;) Sep 28 15:52:20 Heinervdm: I heard it was a combined effort. Sep 28 15:52:44 TAsn: ok :) Sep 28 15:52:53 :) Sep 28 15:52:56 anyhow, thanks. Sep 28 15:53:13 I'm anxious to test it. Sep 28 15:53:13 :) Sep 28 15:57:35 TAsn: we should not forget to thank Weiss and larsc :D Sep 28 16:01:51 http://build.shr-project.org/tests/mrmoku/feed/armv4t/ffalarms_0.2.4+svnr54-r0_armv4t.ipk where does this pkg comes from? is it still my faulty recipe? Sep 28 16:02:22 Heinervdm: probably... dunno Sep 28 16:02:55 mrmoku: in recipes/ffalarms is just a recipe for 0.2.2... Sep 28 16:03:32 i should fix the recipe and send it... Sep 28 16:03:39 Heinervdm: hmm, no I have 0.2.3 in there Sep 28 16:04:11 uuhh... local uncomitted change ;) Sep 28 16:04:29 mrmoku: ah then it's my recipe Sep 28 16:04:39 Heinervdm: as I don't have the time to check that it is building... yes patch please :D Sep 28 16:06:22 ah now i know what's the problem :) it depends on openmoko-alsa-scenarios and i don't know how to replace this depencie for shr Sep 28 16:06:51 Heinervdm: alsa-scenarii-shr Sep 28 16:07:06 Heinervdm: and only for openmoko devices, as for others it's unbuildable Sep 28 16:07:13 dos1: yes, but how to write the DEPENDS line Sep 28 16:08:49 Weiss, larsc: thanks a lot for Xorg :) Sep 28 16:11:01 :) Sep 28 16:11:08 Sorry, absent for now. Keep me posted :-) Sep 28 16:11:09 anything non-KMS is really just larsc Sep 28 16:11:21 KMS? Sep 28 16:11:57 mrmoku: everyone here are too modest :| Sep 28 16:14:12 TAsn: it's already possible to build KMS based SHR ;) Sep 28 16:14:30 dos1: wth is KMS? :) Sep 28 16:14:33 thanks to JaMa Sep 28 16:14:37 TAsn: Kernel Mode-Setting Sep 28 16:14:46 i c. Sep 28 16:15:08 linux supports KMS for some Intel cards, some ATI cards and... Glamo ;D Sep 28 16:15:32 cool :) Sep 28 16:15:38 finally something good about glamo Sep 28 16:15:39 :) Sep 28 16:16:24 sorry for being such an ignorant, though what does it mean for us? (I know what mode-setting is) though I have no idea what are it's main advantages. Sep 28 16:17:05 ask Weiss ;) Sep 28 16:17:26 Weiss: ^ Sep 28 16:19:03 TAsn: but for me it just seems to having everything done *right* about glamo Sep 28 16:19:23 including possible (but limited) 3d acceleration Sep 28 16:19:41 Heinervdm: PREFERRED_PROVIDER_openmoko-alsa-scenarios = "alsa-scenarii-shr" Sep 28 16:19:43 really? Sep 28 16:19:46 is what we have in shr.conf Sep 28 16:19:59 didn't know it has this kind of effect Sep 28 16:20:15 ah, then that RDEPENDS is ok Sep 28 16:20:23 should be yeah Sep 28 16:20:58 then i just need a small patch for it Sep 28 16:21:10 dos1: btw... raster pointed out the new autogenerated elementary docs Sep 28 16:21:11 PREFERRED_PROVIDER_openmoko-alsa-scenarios = "alsa-scenarii-shr" Sep 28 16:21:13 ouch Sep 28 16:21:17 http://docs.enlightenment.org/auto/elementary/index.html Sep 28 16:21:20 :) Sep 28 16:23:28 mrmoku: anyhow, concerning the patches Sep 28 16:23:35 I still haven't managed to test them Sep 28 16:23:42 as it didn't finish building yet Sep 28 16:23:48 though please use the split version Sep 28 16:23:51 and apply Sep 28 16:23:54 non-intrusive Sep 28 16:23:55 first Sep 28 16:23:57 :) Sep 28 16:24:12 okie? Sep 28 16:24:16 TAsn: I pushed the single one for now... we can split it afterwards Sep 28 16:24:31 okie :( Sep 28 16:24:53 TAsn: as I didn't get splitted patches from you... I had no choice :P Sep 28 16:25:00 oh Sep 28 16:25:05 * TAsn spanks tasn. Sep 28 16:25:21 I'll send them as soon as I'll finish testing then. Sep 28 16:25:39 TAsn: ok :) Sep 28 16:26:57 raster: is lua stricly needed for edje or can we disable it with --disable-lua? Sep 28 16:29:00 mrmoku: it will replace embryo in the future. But currently it is not needed unless some apps dont use it already Sep 28 16:29:11 khiraly1: ok, thanks Sep 28 16:29:25 * mrmoku off for dinner Sep 28 16:29:29 bbiab Sep 28 17:10:12 is an opkg file for tangogps 0.9.7 available anywhere? Sep 28 17:33:12 TAsn: pushing control of the chip into the kernel means that userspace can't mess things up - e.g. current non-KMS xf86-video-glamo has to tweak some registers to bring the LCD up at the right time (otherwise WSoD happens), but (as lindi- found), if you put a breakpoint in Xorg at the right point, the device locks up solid Sep 28 17:34:03 TAsn: but for me it was mostly because it's necessary to avoid some nastinesses in making DRI work. DRI gives us a unified framework to use for acceleration functions, so that the X server and (say) mplayer or Mesa can cooperate. currently, they both fight for control of the chip and all hell breaks loose Sep 28 17:34:35 dos1: what was the solution to the misc-vapi problem? Sep 28 17:34:45 mrmoku: bitbake -c clean vala Sep 28 17:34:58 net_tux: it's in shr tests repo Sep 28 17:35:05 hmm... I did oeclean vala Sep 28 17:35:24 mrmoku: try to clean vala-native too Sep 28 17:35:30 but that does not unstage files... Sep 28 17:35:51 no, vala-native no Sep 28 17:35:52 t Sep 28 17:36:33 i had to clean vala-native to get misc-vapi compile Sep 28 17:41:01 Weiss: I see. Thanks a lot :) Sep 28 17:46:32 dos1: cleaning only vala did not suffice... following Heinervdm now Sep 28 17:58:57 dos1: ping Sep 28 17:59:42 TAsn: poooong Sep 28 17:59:48 I wonder, how hard do you assume fixing ophonekitd to resolve from opimd will be? it's only running a query, nothing more. Sep 28 17:59:52 I think we should do it Sep 28 18:00:01 because this is the only thing that doesn't compliment opimd-utils Sep 28 18:00:26 TAsn: it shouldn't be hard Sep 28 18:00:38 TAsn: but i don't have any clue about using opimd from C Sep 28 18:00:45 TAsn: mrmoku did libframeworkd-phonegui-efl2 Sep 28 18:00:46 ;) Sep 28 18:00:48 mrmoku: ping :D Sep 28 18:01:12 dos1: I wasn't suggesting you should do it Sep 28 18:01:16 I was talking about myself :) Sep 28 18:01:23 but you made a good point, mrmoku ! Sep 28 18:02:01 oh Sep 28 18:02:02 ;D Sep 28 18:02:34 Heinervdm: even after cleaning vala-native it does not build :( Sep 28 18:03:12 mrmoku: does contact resolving via opimd work? Sep 28 18:03:20 mrmoku: JaMa had to apply a patch yesterday, he patched the Makefile.am Sep 28 18:03:28 TAsn: what is opimd? :P Sep 28 18:03:43 Heinervdm: ok, thanks Sep 28 18:04:34 mrmoku: sth with the tests, that the test doesn't compile in the root dir Sep 28 18:04:42 :) Sep 28 18:04:45 Heinervdm: yeah... it is testalsamixer failing Sep 28 18:05:10 mrmoku: look at the backlog :) Sep 28 18:06:09 Hello... Does anyone know of an application that tests the accelerometers? Sep 28 18:07:43 mrmoku: well... does it work with contact resolving via opimd? or does it segfault? Sep 28 18:08:53 TAsn: hmm... what do you mean? how could I tell if it segfaults when you implement that? probability is high ;) Sep 28 18:09:18 ;D Sep 28 18:09:19 mrmoku: http://logs.nslu2-linux.org/livelogs/openmoko-cdevel/openmoko-cdevel.20090926.txt 16:52 Sep 28 18:09:34 Heinervdm: yeah... found it in my bip log :) Sep 28 18:09:48 mrmoku: oh, I see, it's not there yet... :| Sep 28 18:09:49 bah. Sep 28 18:09:59 well I guess I'll just implement it myself. Sep 28 18:10:04 mrmoku: what about libfso-glib Sep 28 18:10:05 TAsn: it is using the contact cache thingie... Sep 28 18:10:05 does it work? Sep 28 18:10:08 *sync) Sep 28 18:10:16 (sync api) Sep 28 18:10:29 mrmoku: ophonekitd, I know, I want to drop it, as it's useless. Sep 28 18:10:32 dos1: btw Sep 28 18:10:34 did not look at it for some time now... it should even work async now Sep 28 18:10:37 getting phonelog is really slow here Sep 28 18:10:39 any reason why? Sep 28 18:10:46 mrmoku: I want sync. Sep 28 18:10:47 :) Sep 28 18:10:57 bahh... but not in ophonekitd ;) Sep 28 18:10:58 no actually I want async Sep 28 18:11:01 ahh :) Sep 28 18:11:04 :) Sep 28 18:11:25 DocScrutinizer: you around? I don't see you on the cs access list. Sep 28 18:11:56 TimRiker: yup, here Sep 28 18:12:28 this shr manual thingie is really cool :) Sep 28 18:12:30 useful and nice. Sep 28 18:12:39 apt: save Sep 28 18:12:39 saved user and chan files Sep 28 18:12:46 apt: lart DocScrutinizer Sep 28 18:12:46 * apt brandishes Excalibur! "With this sword, I vanquish thee, DocScrutinizer!" and lops off DocScrutinizer's head Sep 28 18:13:13 ~botsnack Sep 28 18:13:13 DocScrutinizer: :) Sep 28 18:13:14 logs will show up in less than 24 hours. Sep 28 18:13:18 ~logs Sep 28 18:13:19 All conversations are logged to http://ibot.rikers.org/channel, where "channel" is replaced by the URL-encoded channel name, such as %23freenode for #freenode. Lines starting with spaces are not logged. Sep 28 18:13:21 TimRiker: Thanks Sep 28 18:13:28 :-) Sep 28 18:14:11 did you resolve the addressing char issue with the other bot? it is adjustable for apt per channel, though I think it is set to ~ everywhere at present. (100+ channels) Sep 28 18:14:37 seems bzzbot vanished Sep 28 18:14:43 k Sep 28 18:15:22 you're all set then. :) Sep 28 18:15:25 "~" is fine for us Sep 28 18:15:38 TimRiker: yep. Many thanks Sep 28 18:15:42 np Sep 28 18:15:54 glad you got the op issues sorted out too. :) Sep 28 18:16:10 TimRiker: me too :-D Sep 28 18:18:15 mwester: you could activate bzzbot (with "!" I'd suggest) now. There were requests if we could keep bzzbot concurrently to apt Sep 28 18:18:34 test Sep 28 18:18:38 !ping Sep 28 18:18:38 s/est/ost/ Sep 28 18:18:38 dos1 meant: tost Sep 28 18:20:15 ~logs Sep 28 18:20:16 All conversations are logged to http://ibot.rikers.org/channel, where "channel" is replaced by the URL-encoded channel name, such as %23freenode for #freenode. Lines starting with spaces are not logged. Sep 28 18:20:56 ~fr-audio Sep 28 18:20:57 from memory, fr-audio is http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem and http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem Sep 28 18:21:04 ~audio Sep 28 18:21:05 i heard audio is usually a codec issue. start with trying to set 'disallow=all' and 'allow=alaw' in sip.conf or the channel's config file if not using sip Sep 28 18:21:31 k, cya Sep 28 18:21:55 ~seen bzzbot Sep 28 18:21:59 bzzbot was last seen on IRC in channel #nslu2-linux, 70d 15h 28m 10s ago, saying: 'eno meant: &d sounds like a good package to be included in optware'. Sep 28 18:25:11 TAsn, re: sponsorship, I'm willing to give 1000 nis for the good cause of a computer for you. On KSP it can buy you a E5300 dual core 1GB mem and 250GB disk Sep 28 18:26:24 * dos1 would like more sponsorship of palm pre to hack FSO on it :P Sep 28 18:26:47 * DocScrutinizer would like the same for N900 Sep 28 18:27:02 baruch: hehe, thanks :) Sep 28 18:27:11 I'm sure everyone would, I would too, but I don Sep 28 18:27:19 I don't have infinite money supply Sep 28 18:27:25 baruch: same here :( Sep 28 18:27:36 DocScrutinizer, I'll research how to do that with bzzbot, but it won't be soon -- I'll be locked in a customer's network soon for the rest of the week. Sep 28 18:27:55 mwester: np Sep 28 18:28:11 mwester: many thanks anyway Sep 28 18:28:37 TAsn-baruch, I'm serious, send me private email and we can coordinate Sep 28 18:29:13 It's not much but it sounds like it's much better than your current setup Sep 28 18:29:38 baruch: nah, it's ok, I can manage with this current setup in the meanwhile Sep 28 18:29:49 I'm just a crybaby :) Sep 28 18:29:54 baruch: nah, it's ok, I can manage with this current setup in the meanwhile [20:26] == baruch [n=baruche@bzq-82-81-167-28.red.bezeqint.net] has left #openmoko-cdevel ["Leaving"] [20:27] I'm just a crybaby :) Sep 28 18:30:00 though thanks a lot for the offer. Sep 28 18:30:08 np Sep 28 18:34:54 i found my sponsor! Sep 28 18:35:01 NOOO Sep 28 18:35:03 i hope you'll like it Sep 28 18:35:05 ;> Sep 28 18:35:07 dos-Microsoft: you are evil. Sep 28 18:35:35 dos-Microsoft: we should create "team tuborg" Sep 28 18:35:42 we'll get money, beer Sep 28 18:35:53 and maybe publicity :) Sep 28 18:35:58 we'll be extreme devs Sep 28 18:36:26 yuck. Sep 28 18:36:35 ~lart dos-Windows7 Sep 28 18:36:35 * apt blasts dos-Windows7 to oblivion with a kamehameha wave Sep 28 18:36:39 by brother actually uses this crap Sep 28 18:36:48 soon after he installed it Sep 28 18:36:57 he asked me to install ubuntu Sep 28 18:37:13 wow, i haven't heard lart in about 2 or 3 years now :) Sep 28 18:37:18 i'm looking forward for future Sep 28 18:37:22 ;) Sep 28 18:38:11 hmm... i think they don't like linux developers... ;x Sep 28 18:38:52 ~lart github Sep 28 18:38:52 * apt keeps mailing github free America Online CDs until he drowns Sep 28 18:39:44 baruch: hi Sep 28 18:39:49 nooo... that makes it even slower :P Sep 28 18:40:02 onen|openBmap, hi Sep 28 18:41:02 baruch: sorry for late answer Sep 28 18:41:08 TAsn: I'll join team tuborh immediately ;-) Sep 28 18:41:13 onen|openBmap, I'm already advancing on my code, I got most of the server backend written, now hooking it to http proper Sep 28 18:41:16 Tuborg Sep 28 18:41:18 baruch: I finish my response... Sep 28 18:41:27 DocScrutinizer: cool! Sep 28 18:41:31 onen|openBmap, no problem, I also happen to reply late at times Sep 28 18:41:31 should get it right with my sponsor :-P Sep 28 18:41:33 we only need tuborg and we are good to go Sep 28 18:41:34 :) Sep 28 18:42:06 baruch: may I ask why the different existing projects are not good enough? It looks a bit to me as if you rewrite everything, aren't you? Sep 28 18:42:22 onen|openBmap, yes I do rewrite Sep 28 18:42:43 baruch: why??? Sep 28 18:43:01 I explained in my email, none of the existing projects have a a proper api to work seamlessly for the user Sep 28 18:43:02 hmm... github does not answer... which means I can't build... which means I will continue the vala-learning-quest now :P Sep 28 18:43:26 I need a way to sync the gsm cell positioning information for the user Sep 28 18:43:43 all the existing projects provide is a way to get a full dump, that's way too much Sep 28 18:43:54 baruch: yes I got that. my question is why do you rewrite everything? there are already different projects which have all the infrastrucutre. why not improving it? why rewrite everything from scratch? Sep 28 18:43:59 onen|openBmap: heh, that sounds all very interesting to me :-) Sep 28 18:44:03 I need an api to say, I'm on mcc/mnc give me any updates Sep 28 18:44:23 onen|openBmap, none of them seem really open or inviting Sep 28 18:44:40 baruch: ??? did you ask??? Sep 28 18:45:08 * DocScrutinizer wonders what's state of FSO olocationd Sep 28 18:45:13 no, I didnt say they are not open, I said they done seem open (and inviting) Sep 28 18:46:28 baruch: what do you expect from us? we have contact information, we answer to people when they contact us. And I, for one, have written multiple times that I was welcoming help Sep 28 18:46:56 I can't easily find on openbmap a pointer to a git/svn/whatever repository with the source Sep 28 18:47:48 baruch: everything should be under the sourceforge project. The wiki page on openmoko about the client states pointers to my git repository under SF Sep 28 18:47:55 I'm looking now and I can't find my way around to see where is the server source Sep 28 18:47:59 * DocScrutinizer pokes TAsn to hand over a Tuborg Sep 28 18:48:23 baruch: I am very surprised of your comments... I do give all the pointers (at least I try, maybe not good enough ;-) ) Sep 28 18:48:35 * TAsn happily accepts the tuborg, and chugs the bottle dry. Sep 28 18:48:41 I don't look at the openmoko wiki , I look at your website Sep 28 18:48:48 that's where I expect to see the info Sep 28 18:49:15 baruch: agreed, it needs some love. Sep 28 18:49:45 that's part of the not inviting, If I can't find info easily without contacting anyone I'm fairly likely to go on my way Sep 28 18:50:14 baruch: when I click on "download" it opens a SF page, with all the packages (client, and AFAIK the server code) Sep 28 18:50:30 I can't understand from that page what is the server Sep 28 18:50:48 the git repo only has the logger source, where is the server source repo? Sep 28 18:51:04 * DocScrutinizer wanders off for dinner etc Sep 28 18:51:19 hi, is there someone from shr here: if I install a package from abi version 3 into shr version "02fe96061411de095776edd314d9ae551e1b2f22" will it render my system unusable? Sep 28 18:51:24 baruch: I understand. But I find you a little bit too hard on us ;-) it is always hard to keep up with all the aspects of a project, especially when you want to make it move forward Sep 28 18:51:30 abi means openembedded abi Sep 28 18:52:09 baruch: there is no repo to my knowledge. Nick, not I, is taking care of the server. you should get in touch with him if this is what you are looking for Sep 28 18:52:09 onen|openBmap, I simply explain why I went the route of writing my own server side as well Sep 28 18:52:37 Not having *easy* access to your server code doesn't make it easy to join Sep 28 18:52:58 baruch: yes I understand your point of view. But I disagree with you about this approach though. Sep 28 18:53:22 All it takes is a single place where all code is kept in VCS, a single page to point to the various dev resources (mailing list, forum, irc, git, whatever) Sep 28 18:53:31 Make the page ugly, but make it so it is easy to join Sep 28 18:53:47 baruch: for the server, contact Nick. for the client, (which is my part) I have put the git public, I have added the pointers to the wiki (IIRC) Sep 28 18:53:51 onen|openBmap, I'm not perfect, I can be wrong, no disagreement there Sep 28 18:54:27 baruch: :-D no problem, as long as we discuss, I have no problem with disagreements. let's work them out :-) Sep 28 18:55:59 baruch: that is exactly the reason why I would prefer to work together, thus we could have more time for wiki/site/documentation maintenance :-) Sep 28 18:59:29 raster: sent you the patches we talked about. (non intrusive ones) just tested them and they don't seem to cause any damage. Sep 28 19:02:26 onen|openBmap, your contact page is not inviting as well, see: http://realtimeblog.free.fr/contact.php Sep 28 19:03:00 Next thing you'll ask me to run AES256 in my head and verify it with DSA1024 Sep 28 19:03:48 baruch: :-) I know, this is a little bit hair fetched. Nick did not want to put form code for contacts because he did not want to take the security risk Sep 28 19:03:55 raster: at least I hope so, I tested for the bugs you talked about last time we spoke about it, and tested for general bugs as well. I haven't really made any changes, so it's not surprising nothing broke. Just added stuff and changed names/comments/type declerations. Sep 28 19:04:20 I put my email in the open, get lots of spam and most of it is thrown by my mail server automatically Sep 28 19:04:21 baruch: so I hesitated between email address in an image, or this approach for preventing spam Sep 28 19:04:41 it's not fun but it makes contact easy Sep 28 19:04:47 image is better Sep 28 19:04:57 baruch: proable better yes Sep 28 19:05:08 s/proable/probably/ Sep 28 19:05:08 onen|openBmap meant: baruch: probably better yes Sep 28 19:05:56 baruch: I agree mostly with you by saying that the doc etc. are scarce, and need serious improvements Sep 28 19:06:11 baruch: but we tried to put the minimum at least Sep 28 19:06:45 baruch: ok, response sent on the ML. Sep 28 19:06:55 fired off email to contact address, I didn't see a specific reference to nick Sep 28 19:07:17 baruch: sorry, what do you mean? Sep 28 19:07:53 baruch: ok got it Sep 28 19:08:27 baruch: good, Nick should look at this address. Thus you should get answer from him. If not ping me, so that I ping him ;-) Sep 28 19:10:15 Regarding your email reply, email is too slow when there are so many points Sep 28 19:11:00 I don't care if the logging service has a manual mode, controllable by a gui, that's fine. I do want to have the option for it to "just work(tm)" Sep 28 19:11:19 I want my phone to just work, and not need to do anything special for it Sep 28 19:11:38 The gsm location service is a service and it should require no user intervention Sep 28 19:12:00 heyho Sep 28 19:12:17 When I install it, I want it to know what network I'm in, download the relevant data, sync this data with updates when it has a network and show me the location whenever it can (and is asked for) Sep 28 19:12:45 All of this without any intervention from me Sep 28 19:12:50 morphis: hallo, palm pre is coming ;-) Sep 28 19:13:08 Also, it should be able to collect information when the gps is on and upload it, also with no intervention Sep 28 19:13:33 for users who want privacy, let them disable the auto upload and/or auto collection Sep 28 19:14:02 or users without flat contracts due to expensiveness :P Sep 28 19:14:02 But these users are not interesting for me at this stage, they will hardly help to improve the location service Sep 28 19:14:15 I'm not saying upload in real time, Sep 28 19:14:17 onen|openBmap: jepp I know and the challenge is open! Sep 28 19:14:30 I actually only want upload when usb is connected or wifi or pan Sep 28 19:14:44 ok :) Sep 28 19:15:00 onen|openBmap: http://www.freesmartphone.org/index.php/Palm_Pre_Challenge Sep 28 19:15:02 baruch: if email exchange sounds to slow for discussing many points, waht do you propose? irc here? (I like ML because it lets the traces of why decisions are taken) Sep 28 19:15:11 GPRS is not cheap for me either, so I ignore it :-) Sep 28 19:15:29 onen|openBmap, I prefer irc for that, yes Sep 28 19:16:00 baruch: I understand what you are looking for, you told me in the emails. and I think we agree that our demands are compatible. simply make it configuraable Sep 28 19:16:00 irc is logged as well, extracts can be taken as necessary as well Sep 28 19:16:34 That's the most important point for me, the rest are more details Sep 28 19:17:12 like which side filters interesting cell attributes, I dont care, it can be a random oracle in the middle Sep 28 19:17:45 I do care somewhat about implementation language, python eats too much memory and is too slow to start Sep 28 19:17:58 baruch: I understood that IRC are logged but only for limited time. am I mistaken? this channel for example gets logged forever? Sep 28 19:18:07 Vala is great and it works just as well on other platforms though no idea about android Sep 28 19:18:18 onen|openBmap, there are logs since 2006 Sep 28 19:18:36 Though I was surprised by that as well Sep 28 19:18:38 :-) Sep 28 19:19:53 baruch: let's discuss the technical point about the oracle: I disagree ;-) Sep 28 19:21:21 What is the size of the current full (calculated position) database? Sep 28 19:21:33 I said I dont care much about the oracle option, discard it then Sep 28 19:21:49 baruch: about the server aspects, I am not the right person to toalk to, let's discuss this with Nick Sep 28 19:22:06 baruch: about the client, do you like the dbus proposition I made? Sep 28 19:22:34 you mentioned dbus several times, can you summarize here? Sep 28 19:23:55 baruch: I am not sure it contains all the data, but I think: 22 MB Sep 28 19:24:00 baruch: sqlite Sep 28 19:25:31 dos1, you didn't answer me! phonelog: do you know why it takes a lot of time to retrieve calls? though you know where the bottle neck is? mind telling me where I can find the queries at? Sep 28 19:25:54 dos1, please pm me all of those as I'm off. Sep 28 19:25:57 ciao. Sep 28 19:26:01 TAsn: hmm Sep 28 19:26:05 TAsn: maybe sorting Sep 28 19:26:06 ? Sep 28 19:26:14 it isn't optimised at all in opimd :P Sep 28 19:26:17 and it can take some time Sep 28 19:26:19 baruch: dbus service: the logging engine is written let's say in vala. it can be used as library OR run as a service on the device. then the it can be driven by IPC calls, and thus easily by a gui (written in whatever) to pilot it if wanted Sep 28 19:26:34 syslog? ;) Sep 28 19:26:41 dos1, hm... I don't think that's it. Sep 28 19:26:49 since I limit my read to 50 Sep 28 19:26:55 maybe you first sort and then limit? Sep 28 19:26:59 oh right you probably do Sep 28 19:27:03 TAsn: still Sep 28 19:27:05 as it's the correct behavior Sep 28 19:27:12 so it may be sorting Sep 28 19:27:13 yeah. Sep 28 19:27:21 yup Sep 28 19:27:24 :| Sep 28 19:27:39 and there's no way to change the internal design to sqlite? Sep 28 19:27:46 takes too much time? Sep 28 19:27:51 *work Sep 28 19:27:52 onen|openBmap, I wouldn't bother with the library part, not until there is a real need for this, ofcourse, internally the code need not be a spaghetti so it should be easy to extract the code when needed Sep 28 19:28:06 ciao. Sep 28 19:28:33 My take is to createa server daemon that runs at boot and stays there, it provides gypsy dbus interface to get location and possibly a dbus interface to control it Sep 28 19:28:58 I'd say by default it logs gps/gsm data but doesn't turn on the gps itself Sep 28 19:29:24 It can be told not to log automatically and will have a method to log manually on request Sep 28 19:29:40 It can have interface to a logger gui if the user wants to see what happens behind the scenes Sep 28 19:29:50 that should cover it I think Sep 28 19:31:22 baruch: well that is precisely what I wrote in my email and above. good to see we agree :-) Sep 28 19:31:29 mrmoku: vala 0.7.7 includes all our patches "for upstream" :p it has been released yesterday Sep 28 19:31:43 ptitjes: yay :) Sep 28 19:31:43 mrmoku: also I just releases libgee 0.5.0 Sep 28 19:31:48 baruch: a logging engine which is versatile enough to let people use it as they wish Sep 28 19:31:55 s/releases/released/ Sep 28 19:31:55 ptitjes meant: mrmoku: also I just released libgee 0.5.0 Sep 28 19:31:57 ptitjes: hey, wassup? Sep 28 19:32:13 onen|openBmap: hello! Sep 28 19:32:16 onen|openBmap, I would only bother writing the automatic part for now because that's what I really care about Sep 28 19:32:29 but I do not object to the manual part as well Sep 28 19:32:43 baruch: that's the whole point of working together on the same code. we bring what matters to us Sep 28 19:33:03 ptitjes: with old autostuff I hope? :P Sep 28 19:33:11 sure :) Sep 28 19:33:30 you said you have a working service already, care to share it? Sep 28 19:33:54 * onen|openBmap is amazed to find someone who wants to collaborate with him :-O Sep 28 19:34:00 mrmoku: I wait for you to give me the green light to move to am1.11 Sep 28 19:34:07 :) Sep 28 19:34:35 ptitjes: already started this quest Sep 28 19:34:40 mrmoku: question about testing candidate - I'm trying to install omnewrotate, and I get unsatisfied dependancy on libframeworkd-glib0 -- any ideas? Sep 28 19:34:50 baruch: it is *very* basic, and pretty crapy. As proposed in my previous email, if you want to see it soon, I'll spend more time on it, to put it under git Sep 28 19:35:19 baruch: asap Sep 28 19:35:20 wjbaird: hmmm... libframeworkd-glib0 is for sure installed Sep 28 19:35:23 onen|openBmap, regarding experimenting with algorithms, I think that I'd like to collect information from users on how different algorithms behave for them, to get a good sense of the algorithm behaviour that requires multiple active algorithms feeding back information Sep 28 19:35:34 wjbaird: did you change the feed config? Sep 28 19:35:46 onen|openBmap, just put it in git and share, it doesnt have to be perfect Sep 28 19:35:48 mrmoku: great Sep 28 19:35:50 wjbaird: I guess it is pointing to the official testing position Sep 28 19:35:52 mrmoku: yeah, my feeds point to http://build.shr-project.org/tests/mrmoku/testing/feed Sep 28 19:35:58 wjbaird: ahh, ok Sep 28 19:36:03 that's fine then Sep 28 19:36:04 baruch: we had this idea too. then we realized that we the raw data, you basically have the data to test your algorithms Sep 28 19:36:29 mrmoku: shr currently uses fsodeviced or odeviced? Sep 28 19:36:29 mrmoku: could be a version issue: The complete message is: * libframeworkd-glib0 (>= 0.0.1+gitr680276e4cddabeb1edd088ddd421f363dd106a50) * Sep 28 19:36:40 To do proper testing you need to feed the algorithm some of the data and reserve some for testing Sep 28 19:36:44 morphis: still odeviced Sep 28 19:37:00 mrmoku: but you are planing to switch in the near future? Sep 28 19:37:10 wjbaird: omnewrotate from our repo or opkg.org? Sep 28 19:37:20 morphis: needed for palm pre? :P Sep 28 19:37:22 mrmoku: from the repo Sep 28 19:37:36 mrmoko: list_installed gives me: libframeworkd-glib0 - 0.0.1+gitr98+680276e4cddabeb1edd088ddd421f363dd106a50-r1 Sep 28 19:37:57 ahh ouch Sep 28 19:37:57 mrmoku: it is not showstopper for the palm pre but I have to decide for which I implement the device handling Sep 28 19:37:59 baruch: I see your point. it might make sense Sep 28 19:38:10 s/it is not/it is not a/ Sep 28 19:38:11 morphis meant: mrmoku: it is not a showstopper for the palm pre but I have to decide for which I implement the device handling Sep 28 19:38:16 mrmoko: just force the install? Sep 28 19:38:17 dos1: what state is fsodeviced in for you? Sep 28 19:38:25 wjbaird: yep just force it Sep 28 19:38:38 it is the same version of the lib... just one has the git... prefix Sep 28 19:38:39 ~botsnack Sep 28 19:38:40 mrmoku: and I would really like to do it for fsodeviced Sep 28 19:38:41 DocScrutinizer: aw, gee Sep 28 19:38:50 mrmoku: k. should I open an issue on trak? Sep 28 19:38:52 ~good bot :-) Sep 28 19:38:52 thanks, DocScrutinizer Sep 28 19:38:58 mrmoku: now i switched back to odeviced Sep 28 19:39:05 but i have some other problems Sep 28 19:39:18 wjbaird: no, will be automatically resolved by rebuilding... and other than that we can't do anything Sep 28 19:39:28 wjbaird: thanks for reporting though Sep 28 19:39:40 mrmoku: ok... that's the only glitch I've seen on the testing candidate so far... Sep 28 19:39:48 good :) Sep 28 19:40:01 mrmoku: how are plans to promote this as the official shr-t? Sep 28 19:40:23 wjbaird: nothing decided yet... but so far comments are positive Sep 28 19:40:30 I have a question about vala. android allows compiling c code. thus I was wondering if it is possible to compile libraries of vala (glib?) and generated c code to compile it under android (I think navit does the glib part?) Sep 28 19:40:41 wjbaird: our problem is that right now we can't build anything for testing due to the switch to xorg Sep 28 19:41:05 I would like to have that solved first... publishing testing without being able to update and build fixes for it feels bad Sep 28 19:41:17 mrmoku: not clear how that's a problem... don't you build testing off a different branch? Sep 28 19:41:20 dos1: when will we switch? Sep 28 19:41:24 onen|openBmap: what do you mean with "android allows to compile c code", the vm dalvik? Sep 28 19:41:27 wjbaird: no Sep 28 19:41:43 wjbaird: we build different revisions of packages... but out of the same branch Sep 28 19:41:51 at least now... we might change that now :P Sep 28 19:42:06 morphis: they have tools to compile your code to run it (I think) on dalvik yes. but you compile c code. I guess it runs in some kind of safe area Sep 28 19:42:07 mrmoku: that seems... surprising to me... Sep 28 19:42:15 wjbaird: why? Sep 28 19:42:17 onen|openBmap: ah ok Sep 28 19:42:22 mrmoku: well, we can't include it just now Sep 28 19:42:29 as it needs some manual tweaking Sep 28 19:42:38 but i'll bug mickey_away for remaining issues when he'll return Sep 28 19:42:42 onen|openBmap, vala compiles to c Sep 28 19:42:45 dos1: ok Sep 28 19:42:56 mrmoku: probably that I'm not familiar enough with git... All my experience has been cvs or svn --- and in those the right choice would be a separate branch, and then merge stuff over periodically when you know it's stable enough... Sep 28 19:42:59 the vala compiler emits c code to be further compiled Sep 28 19:43:23 you will also need several libraries like glib since it uses the glib object model Sep 28 19:43:31 morphis: not sure how this works. http://developer.android.com/sdk/ndk/1.5_r1/index.html Sep 28 19:43:35 mrmoku: btw - using --force-depends still gives me the same error message. o_O? is there a difference force option I need to use? Sep 28 19:43:40 http://developer.android.com/sdk/ndk/1.5_r1/index.html Sep 28 19:43:43 uups Sep 28 19:44:05 baruch: I know, this is what I have written above Sep 28 19:44:56 wjbaird: hmm... with one - though... -force-depends Sep 28 19:45:14 baruch: thus the idea as you want to use vala: maybe it would be possible to compile the core of our common engine to run under android Sep 28 19:45:17 seems like the ndk is a way to compile code with a local interface Sep 28 19:45:22 a JNI of sorts Sep 28 19:45:41 baruch: IIRC you can creatge libs, and call them from java. nothing more Sep 28 19:45:58 that's what it seems to do indeed Sep 28 19:46:17 morphis: from where will the palm pre images be build? org.oe.dev or shr/import? Sep 28 19:46:17 You can always retarget vala from c to dalvik Sep 28 19:46:19 :-) Sep 28 19:46:39 baruch: he he :-) Sep 28 19:46:52 mrmoku: currently there is no real plan for building images for the palm pre Sep 28 19:47:21 * mrmoku wonders if he should start to integrate support for it in the Makefile Sep 28 19:47:29 mrmoku: shr currently builds from shr/import? Sep 28 19:47:37 morphis: yep Sep 28 19:47:50 mrmoku: then I think we will even build from shr/import Sep 28 19:48:01 baruch: I am again thinking about communication. ML is easier for me and others because asynchronous. and threads are easier to follow. irc is fine to talk. but I would propose to use ML to write summaries of our discussion here. what do you think? Sep 28 19:48:10 mrmoku: good point, currently the machine files for the palm pre are only in org.oe.dev Sep 28 19:48:20 morphis: ok, we can enable fsodeviced just for the palm then I think Sep 28 19:48:21 onen|openBmap, sure, a summary on a ML is great Sep 28 19:48:26 morphis: I can cherry-pick them ;) Sep 28 19:48:30 baruch: great Sep 28 19:48:33 mrmoku: shr/import is merged from time to time with org.oe.dev? Sep 28 19:48:41 mrmoku: would be great Sep 28 19:49:01 mrmoku: (fsodeviced) that would fantastic :) Sep 28 19:49:03 morphis: well... stefan is working on merging the stuff into org.oe.dev Sep 28 19:49:23 mrmoku: ah ok, so you will build in the near future from org.oe.dev? Sep 28 19:49:28 morphis: when he (or better we all involved) have finished that merging we will base a new branch on org.oe.dev and keep it close to it Sep 28 19:49:38 morphis: rule will be... UPSTREAM FIRST :P Sep 28 19:49:55 mrmoku: hehehe :) Sep 28 19:50:12 baruch: let's see, I try to bring quickly my location code under git, for you to peak at it. 2. point: discuss with nick about the server part. Is it ok? Sep 28 19:50:42 mrmoku: do you can rate when the merge will be finished? Sep 28 19:51:07 mrmoku: or it depends much on how many time the involved people has? Sep 28 19:51:15 morphis: hmmm... stefan would be in a better position to answer that question Sep 28 19:51:37 mrmoku: ok, will ask him when he is available Sep 28 19:52:27 baruch: I would like to know what are the parts you are mostly interested (client/server/location service)? Sep 28 19:52:43 onen|openBmap, yes its ok Sep 28 19:52:56 I care about the whole system just working Sep 28 19:53:18 If I need to hack the cisco routers in the middle to work, I'll do it Sep 28 19:53:19 baruch: he he. so to have sth working we only need my location service then :P Sep 28 19:53:52 baruch: I was thinking, what part of the chain should be improved first... or what would you like to improve first? Sep 28 19:54:18 baruch: for example, my logger is manual, and in python. but it works well. so maybe this is not the highest priority Sep 28 19:54:19 I want a good enough client which can sync/auto-dl from the server Sep 28 19:54:32 baruch: I can let it run 4-5 hours before battery is depleted Sep 28 19:54:47 If there is a way to download calculated data from the server than the next priority is the client Sep 28 19:55:15 my moko cant live after one hour of working Sep 28 19:55:20 Anyone know if there is an NTP client for OM? Sep 28 19:55:31 baruch: I think we use same word for different thing. for me the client is only the logger. the server... that's ok. then the location service. Sep 28 19:55:31 though most of the time I peek the screen so that takes lots of power Sep 28 19:55:40 Alpha6: otimed, ntpdate :P Sep 28 19:55:52 baruch: thus I don'tunderstand what sync you want to do for the client...? Sep 28 19:55:54 the client is both logger and location service Sep 28 19:56:02 I couldn't find ntpdate Sep 28 19:56:23 we need the sync for the location service obviously, the logger doesnt care about it Sep 28 19:56:28 Alpha6: under shr, or debian? Sep 28 19:56:46 shr Sep 28 19:57:24 baruch: let's use the terms: logger, server, location service. agreed? Sep 28 19:57:48 baruch: and I see logger and location service as two separate things Sep 28 19:58:21 baruch: because you might want to have the location service on your netbook, with 3g key, but you don't have a gps Sep 28 19:58:24 ok Sep 28 19:59:03 <[Rui]__> hi Sep 28 19:59:13 [Rui]: hello Sep 28 19:59:56 baruch: if your phone last that little, I fear a switch to vala won't improve much Sep 28 20:00:17 baruch: I use native apps on my windows mobile phone, and it lasts 4-5 hours maximum too Sep 28 20:01:16 I think my battery is mostly dead, it behaves rather strangely Sep 28 20:01:38 baruch: please think about priorities about the three aspects. we can keep talking about it next days Sep 28 20:01:42 The vala change is not for battery life anyway, it is for general usability Sep 28 20:01:55 baruch: for me the priority is clearly the location service Sep 28 20:02:22 baruch: then we have the complete chain Sep 28 20:02:34 Since the location service is the missing part for now, it should be completed yes Sep 28 20:03:18 baruch: since my code is very small. I guess we could switch to vala. Even if I think this makes things more complicated for possible contributors Sep 28 20:05:03 I'm willing to hand hold any possible contributor to get him working with vala, it's really simple Sep 28 20:05:22 baruch: I have to think about this. for now my location service is very small and does nothing when not called. so not much to save here. but I find python fast to develop Sep 28 20:05:24 onen|openBmap: probability for contributions from will rise with vala ;) Sep 28 20:05:33 s/from/from me/ Sep 28 20:05:33 mrmoku meant: onen|openBmap: probability for contributions from me will rise with vala ;) Sep 28 20:05:56 mrmoku: baruch: ok if this brings mrmoku in, then I have not arguments left Sep 28 20:06:21 mrmoku: actually the '--force-depends' worked, I just didn't look closely enough - I got the same message, but it was flagged as a warning not an error... thanks... Sep 28 20:06:26 cant argue with editing on the device, but the other benefits outweigh it for me Sep 28 20:06:33 wjbaird: ahh ok :) Sep 28 20:07:28 baruch: you mean less memory, faster (thus less power angry too). yes I know Sep 28 20:07:44 baruch: vala is more "green IT" than python ;-) Sep 28 20:08:31 onen|openBmap: btw... is it normal that the server takes *that* long to digest log files? Sep 28 20:09:02 baruch: what I imagine is: put my python location under git. then either release it to bring the service to the people right now, and start vala implementation. or directly vala Sep 28 20:09:34 I don't mind either way Sep 28 20:09:48 I only want to hack on the vala code to get it working Sep 28 20:10:06 and then make the logger vala as well (and working in the background) Sep 28 20:10:12 mrmoku: well as usual I am not the server guy :-( I can ask. I will come back to you with some technical explanaitions Sep 28 20:10:38 onen|openBmap: well... has no importance... use your energy for more important things :) Sep 28 20:11:08 onen|openBmap: it's just that I'm eagerly waiting to pass the 6000 ;) Sep 28 20:11:28 baruch: you will need a SF account to write to our git :-) Sep 28 20:11:39 have one already, baruch Sep 28 20:11:51 mrmoku: pfff, you will never catch me!!! >:-) Sep 28 20:12:07 baruch: good, then it will be formality to add you. Sep 28 20:12:12 onen|openBmap: I know... but I want to manifest my 4th position ;) Sep 28 20:12:26 baruch: should I add you so that you have a git repository? Sep 28 20:13:05 it all depends on how you want to do this, if you want me to commit directly than yes, I should be added Sep 28 20:13:33 baruch: I am wondering: if you are willing to work on location service, I might then spend my time on the logger (patches are pending), plus multiple ideas... Sep 28 20:13:51 baruch: but I don't want to give you the feeling that I let you work on what I did not want to... Sep 28 20:13:58 no problem for me Sep 28 20:14:30 If you put your python code up, I can do the rest myself Sep 28 20:14:43 baruch: well I don't feel hacker enough to review your code as patches ;-) simpler to commit it right away :-) Sep 28 20:14:47 though it's always more fun to work together Sep 28 20:15:40 baruch: indeed. I expect to learn more with working together too (and you will help me with vala ;-) ). and I am wondering if it makes sense for me to keep going on python logger, if vala is coming Sep 28 20:16:13 baruch: well probably not for tomorrow anyway, thus may be good to keep maintaining it for a while Sep 28 20:16:25 It depends on how long it will take to make the location service and for me to turn to the logger :-) Sep 28 20:16:45 I can give you the code I have for the logger in vala, it collects the data but doesn't write or upload it Sep 28 20:16:53 it has no gui, it is intended as a background service Sep 28 20:17:13 you can delve into it if you want and make it a complete system with dbus interface for gui and the gui itself Sep 28 20:17:37 baruch: yes, please send it to me. I will have a look. I should be able to understand the purpose of vala code without knowing it precisely Sep 28 20:18:04 baruch: I would propose to reimplement parts as vala, and keep the python parts. Sep 28 20:18:17 baruch: that is what the fso people did Sep 28 20:18:35 that would be too much of a bother I think, the gui can stay python but mixing python and native is too much to bother for me Sep 28 20:19:13 baruch: we can talk about this later. Sep 28 20:19:17 sure Sep 28 20:19:30 baruch: I am very much happy to find someone willing to collaborate Sep 28 20:19:43 baruch: and I hope things will keep going so :-) Sep 28 20:20:05 baruch: I put the location code under git asap Sep 28 20:20:20 onen|openBmap: so let me suggest a few nice algos eventually ;-P Sep 28 20:20:21 I hope so too, I worked in the past on cell locator but collaborators there disappeared and I lost the free time I had Sep 28 20:21:07 DocScrutinizer, what algos do you have in mind? Sep 28 20:21:27 DocScrutinizer: he he, I know your algorithms already, I will say they are from me >:-) Sep 28 20:21:54 baruch: why did you lose the time? if it was opensource you could still keep going, isn't it? Sep 28 20:21:55 baruch: matching actual network fingerprint against map Sep 28 20:22:17 DocScrutinizer: ah, there he is again :-P Sep 28 20:22:40 onen|openBmap: what? the fingerprint? :-D Sep 28 20:22:46 onen|openBmap, switched job after startup company folded, needed more time for work and didnt sacrifice family time Sep 28 20:23:10 also family included two growing kids, at the time they killed all of my free time since their sleep patterns weren't that good Sep 28 20:23:17 their sleep patterns improved lately Sep 28 20:23:29 DocScrutinizer: baruch: indeed a very interesting approach. we wanted to focus on other things (log more raw infos for competiting algorightms, location service, etc.), thus this is low on our priority list though. Sep 28 20:23:31 DocScrutinizer, not sure I follow you Sep 28 20:24:02 That sounds like it's useful for a "mark my position" service Sep 28 20:24:13 and then act on that location, not for a generic gsm location service Sep 28 20:24:39 baruch: DocScrutinizer: guys I have to go Sep 28 20:24:54 errrm, maybe I have no slightest idea about what's the actual topic Sep 28 20:25:03 onen|openBmap: cya Sep 28 20:25:11 baruch: we keep in touch. at least, for my parts (logger + location), I hope we can makes collaboration works :-) Sep 28 20:25:18 onen|openBmap, bye, let me know when your code is up and when I'm in sf project Sep 28 20:26:03 baruch: by the way, you should use openBmap logger :P Sep 28 20:26:10 see you Sep 28 20:26:16 baruch: http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002434.html Sep 28 20:26:34 baruch: http://lists.openmoko.org/pipermail/openmoko-kernel/2008-June/002987.html Sep 28 20:26:34 onen|openBmap, I will, from now Sep 28 20:28:26 DocScrutinizer, that's using the tav value which is only available during a call AFAIK Sep 28 20:28:32 baruch: probably I have no idea what's a "generic gsm location service". My suggestions are about finding your current position not via GPS but via GSM Sep 28 20:28:56 baruch: we talked about that topic really extensively Sep 28 20:28:58 raster: ping Sep 28 20:29:13 baruch: nad no, it's not strictly during call nly Sep 28 20:29:31 The first message details what I'm thinking about but it depends on the correct location of the gsm cell Sep 28 20:29:38 that's not easy to find Sep 28 20:29:50 TA should be set for each transmission from ME to BTS Sep 28 20:30:01 the logger onen is working on generates raw measurements from which you can try to find the cell position but it wont be accurate enough Sep 28 20:30:08 I did that in my former project cell locator Sep 28 20:31:01 baruch: we could continue that talk tomorrow (preferrably when onen is here as well). Have to run now, sorry Sep 28 20:31:14 I know of several cell locations and no sane optimization algorithm found them properly from the logging info Sep 28 20:31:21 ok, bye Sep 28 20:33:45 baruch: (from the door..) you're right. That's the main problem of onens approach. And that's the reason (well one of) why I talk about fingerprints. You won't get any better info from GSM. Even TA might be wrong in some locations Sep 28 20:33:52 * DocScrutinizer away Sep 28 20:33:59 * mrmoku too :P Sep 28 20:34:01 gnight all Sep 28 20:34:06 night Sep 28 20:38:29 anyone know where opimd-notes keeps it's notes? I thought I moved my entire home dir over from shr-u to shr-t, but I don't see the notes I created before... Sep 28 21:17:25 wjbaird: Is it in /etc/freesmartphone/opim/ ? Sep 28 21:21:00 <[Rui]__> I see things are still a bit unstable at shr-dev-land :) Sep 28 21:26:55 TeLLuS: I'm trying to check... but I was also downloading some TangoGPS tiles - and my load average has shot up to about 12, and the phone is basically unusable... Sep 28 21:28:42 <_phil> did somebody suceed in booting om-2.6.31? Sep 28 21:31:14 TeLLuS: yup - looks like it's in sqlite-notes.db in /etc/freesmartphone/opim. Seems a bit questionable to be putting that kinda info into /etc to me... Sep 28 22:56:09 pros/cons for this navit configuration: http://scap.linuxtogo.org/files/8a5696050bc8f713dedef532303f1df7.png Sep 28 23:00:08 playya_: I don't like many OSD elements on my Navit map, it uses too much CPU IMO Sep 28 23:01:27 ok. what should be removed? Sep 28 23:02:14 i think i could at least remove the speed Sep 28 23:03:45 I only have the basic + and - for zooming, nothing else Sep 28 23:04:25 i want to keep the navigation stuff with next point and street Sep 28 23:04:56 playya_: also take a look at http://trac.navit-project.org/ticket/447 Sep 28 23:06:52 do you know if it's already accepted? Sep 28 23:07:19 sure it is. It's in the "we're waiting for your patch" state ;-) Sep 28 23:19:15 g'night Sep 28 23:30:51 Hi all. Trying to build OpenMoko on Ubuntu 9.04 for a HTC Raphael (MSM 7201A based) phone...however, having trouble being able to do bitbake openmoko-image...something always fails. Sep 28 23:32:38 there's no openmoko image Sep 28 23:32:48 it'obsolete Sep 28 23:33:16 try import/shr branch with you machint config Sep 28 23:34:26 Well, that would be a good reason :-) Sep 28 23:34:44 I will say I'm very new to OpenEmbedded... Sep 28 23:35:29 so I set machine to "htcraphael" and currently distro is set to openmoko in my local.conf, what should I replace that with? Sep 28 23:36:10 you have to switch to a different branch first Sep 28 23:36:49 maybe you can use shr-makefile to setup the basic system and change stuff for htcraphael Sep 28 23:37:08 I've got my own kernel, just trying to get a userland image Sep 28 23:39:12 whats the git flag to switch branches? git branch ??? origin/shr/import .. Sep 28 23:40:18 git checkout Sep 28 23:40:37 but use the makefile. it sets up everything for you Sep 28 23:41:53 and then you change your machine and some other fixes Sep 28 23:41:55 do you have a link that will get me going? I hate asking stupid questions... Sep 28 23:42:45 http://git.shr-project.org/git/?p=shr-makefile.git;a=summary Sep 28 23:42:46 and I do appreciate the help. Sep 28 23:44:14 ok, cool. Where should that be in the $OEBASE tree? Sep 28 23:44:55 no Sep 28 23:45:06 just clone it somewhere else Sep 28 23:45:18 then cd into the dir Sep 28 23:45:22 make setup Sep 28 23:45:27 get a coffee :) Sep 28 23:46:11 hah Sep 28 23:46:28 eek, is it going to re-clone the OE repo? Sep 28 23:46:33 yes Sep 28 23:46:40 I already got that Sep 28 23:46:47 hehe Sep 28 23:47:14 whatever, if it makes my life easier, and more importantly, actually works, it's time well spent :-) Sep 28 23:47:16 volume flat? Sep 28 23:49:26 What do you mean? Sep 28 23:50:25 actually, that was a lot faster then expected. Sep 28 23:50:51 make setup ready? Sep 28 23:50:56 yeah Sep 28 23:51:12 cs shr-unstable Sep 28 23:51:18 s/cs/cd/ Sep 28 23:51:18 playya_ meant: cd shr-unstable Sep 28 23:51:27 ah, good old apt :-0 Sep 28 23:51:28 :-) Sep 28 23:51:59 change the machine in conf/auto.conf Sep 28 23:53:12 ok. htcraphael is also in your git's machine dir, so I'll give it a whirl...just make seems to kick it off Sep 28 23:53:29 good luck Sep 28 23:53:52 afaik shr doesn't have a framework conf for it Sep 28 23:54:01 but that should be hard Sep 28 23:54:49 hmm..yeah, doesn't seem to recognize it, but it's in openembedded/conf/machine Sep 28 23:55:08 you set it in auto.conf? Sep 28 23:55:24 yeah, it didn't like it. Sep 28 23:57:15 1 second Sep 28 23:57:52 waut Sep 28 23:57:53 wait Sep 28 23:58:11 lol typo. Sep 28 23:58:12 Sorry. Sep 28 23:58:45 Kensan: pong! Sep 29 00:01:21 Lots of 404s Sep 29 00:01:31 but alternate sources seem to have the files Sep 29 00:17:38 raster! I can't see any issues with my complete patch, but that was the same case last time and you said you found some :| Sep 29 00:18:42 raster, mind if I'll send you another patch (which should be applied on top of the one I sent you today) and you'll tell give me a test case? Sep 29 00:27:36 oh ummm sure! Sep 29 00:27:47 i have only woken up recently... havent even gotten to it yet Sep 29 00:29:01 cool, thanks :) Sep 29 00:29:10 * TAsn is sending raster the second patch as well. Sep 29 00:32:40 raster, sent. ;) Sep 29 00:33:05 playya_: No go "Missing or unbuildable dependency chain was: ['openmoko-alsa-scenarios']" Sep 29 00:33:32 mrmoku|away, please build newest E for SHR I wanna see how it goes :) Sep 29 00:33:43 mrmoku|away, everything looks fine here... Sep 29 00:39:38 :] Sep 29 00:43:55 raster, I'm expecting either a bug report or a commit :) Sep 29 00:46:46 Does the current git tree build? Sep 29 00:49:35 TAsn: :) **** ENDING LOGGING AT Tue Sep 29 02:59:58 2009