**** BEGIN LOGGING AT Fri Apr 13 02:59:58 2012 Apr 13 04:19:26 btw in maemo.org there's election for a new term of council, and discussions about future and direction of maemo community. The funny and related part: everybody states things like "we of course will welcome and hope for other communities to join. Like Openmoko..." Apr 13 04:40:35 * pabs3 giggles Apr 13 05:25:35 SHR: 03Martin.Jansa 07shr-chroot * r54d4a90035c4 10/ (410 files in 27 dirs): system upgrade Apr 13 07:25:48 SHR: 03Martin.Jansa 07meta-smartphone * ref3928bba29e 10/meta-shr/recipes-shr/3rdparty/chroneo_svn.bb: chroneo: add stopwatch app Apr 13 07:25:58 SHR: 03Martin.Jansa 07meta-smartphone * r5188b60a7fb5 10/meta-shr/recipes-shr/3rdparty/podboy_svn.bb: podboy: bump SRCREV Apr 13 07:31:05 SHR: 03Martin.Jansa 07shr-chroot * re3a26b3a532a 10/ (388 files in 36 dirs): python upgrade Apr 13 07:39:55 DocScrutinizer: heh :-P Apr 13 08:00:11 Good day all , internet connection is ok on fr , how to solve this problem http://www.pastie.org/3773901 ? Apr 13 08:05:16 alabd: seems like the apt metadata downloaded from ftp2.de.debian.org is corrupted somehow Apr 13 08:06:10 try another mirror Apr 13 08:07:10 pabs3: thanks , what's other mirror and should change it in installler.sh source? Apr 13 08:08:10 alabd: yep, change it to any of the mirrors on http://www.debian.org/mirror/list Apr 13 08:11:29 tbh, that should not happen, the mirror looks fine from here Apr 13 08:14:22 pabs3: wget: bad address 'ftp2.au.debian.org' Apr 13 08:14:22 .. Apr 13 08:14:51 not sure where you got that from, ftp2.au.debian.org never existed Apr 13 08:15:45 yes changed ut to ftp.au Apr 13 08:16:29 pabs3: but prev mirror was ok and package has been downloaded before ... Apr 13 08:16:32 ftp.au.debian.org should work but ftp2.au.debian.org will not work Apr 13 08:17:13 I guess there is something weird on your network then, maybe a proxy is breaking the files? Apr 13 08:17:21 anyway I need to go, good luck Apr 13 08:21:26 pabs3: ah so bad , http://www.pastie.org/3773901 , internet connection with debian.org is ok , but problem remain Apr 13 09:17:44 SHR: 03shr-devel 07buildhistory * r1afbab15fc27 10/packages/armv4t-oe-linux-gnueabi/podboy/ (5 files in 5 dirs): packages: Build 201204131107 of shr 20120413 for machine om-gta02 on opmbuild Apr 13 09:19:22 SHR: 03Martin.Jansa 07meta-smartphone * ra6ad952b21ba 10/meta-shr/recipes-shr/tasks/task-shr-feed.bb: task-shr-feed: add chroneo Apr 13 09:25:00 SHR: 03shr-devel 07buildhistory * r5290b346cc8c 10/packages/armv7a-vfp-neon-oe-linux-gnueabi/podboy/ (5 files in 5 dirs): packages: Build 201204131118 of shr 20120413 for machine nokia900 on opmbuild Apr 13 09:32:16 SHR: 03shr-devel 07buildhistory * rf3a59c1b4e07 10/packages/ (9 files in 9 dirs): packages: Build 201204131125 of shr 20120413 for machine om-gta04 on opmbuild Apr 13 09:39:11 SHR: 03shr-devel 07buildhistory * rdf46f97d6c47 10/packages/palmpre-oe-linux-gnueabi/task-shr-feed/ (4 files in 4 dirs): packages: Build 201204131132 of shr 20120413 for machine palmpre on opmbuild Apr 13 09:46:00 SHR: 03shr-devel 07buildhistory * r9094142e7103 10/packages/palmpre2-oe-linux-gnueabi/task-shr-feed/ (4 files in 4 dirs): packages: Build 201204131139 of shr 20120413 for machine palmpre2 on opmbuild Apr 13 09:53:34 SHR: 03shr-devel 07buildhistory * r189228a17424 10/images/crespo/eglibc/chroot-image/ (build-id image-info.txt installed-package-sizes.txt): images: Build 201204131146 of shr 20120413 for machine crespo on opmbuild Apr 13 10:04:04 SHR: 03shr-devel 07buildhistory * rbf13e3c7ae8a 10/packages/ (13 files in 13 dirs): packages: Build 201204131157 of shr 20120413 for machine om-gta02 on opmbuild Apr 13 10:18:48 hey Apr 13 11:21:59 heyho Apr 13 11:41:11 hi morphis Apr 13 11:41:25 slyon: heyho Apr 13 11:41:28 slyon: you got my mail? Apr 13 11:41:46 morphis, yes Apr 13 11:42:09 i thought about that one as well: modem_access = combined:[/dev/ttyHS3:115200,/dev/ttyHS5:115200]:-1 Apr 13 11:42:31 but we'd need to add the transport type to the "array", don't we? Apr 13 11:43:11 hm Apr 13 11:43:12 as the combined transport does not need to be of serial transports only, right? Apr 13 11:43:15 you're right Apr 13 11:43:34 combined:[serial:/dev/ttyHS3:115200,...]:-1 ? Apr 13 11:43:42 right Apr 13 11:44:00 as in this case the CombinedTransport can evaluate the part [...] on it's own Apr 13 11:44:26 or: [serial,serial]:[/dev/ttyHS3,/dev/...]:[int,int] Apr 13 11:44:28 and no other component has to be updated to support this Apr 13 11:44:34 hmm Apr 13 11:45:09 as the CombinedTransport gets the [...] thing as portname Apr 13 11:45:14 yes Apr 13 11:45:23 evaluates it and then configures its transports Apr 13 11:45:44 this would probably be the best way Apr 13 11:45:57 if we're using [serial,serial]:... we're not exposing that we want to use the combined transport Apr 13 11:46:20 yes.. scratch that one Apr 13 11:47:10 i think the combined:[serial:/dev/ttyHS3:115200,...]:-1 solution would be pretty straight forward Apr 13 11:47:16 yes Apr 13 11:47:48 you will implement this? Apr 13 11:48:43 yes. I've some time today Apr 13 11:49:21 great Apr 13 11:49:37 so we can resolve this issue Apr 13 11:49:57 I don't have a good overview about the current GTA04 status in FSO Apr 13 11:50:22 but I know some people talked about call status polling needed to get known about the fact that a call has ended Apr 13 11:50:43 is this solved with this solution or do we still need the polling for something else? Apr 13 11:51:13 this should be fixed with the combined transport Apr 13 11:52:32 all in all the GTA04 is pretty good supported by FSO already. A big missing thing is a sane audio routing/forwarding within fsoaudiod Apr 13 11:52:39 but afaik mrmoku is working on this Apr 13 11:53:11 another thing which didn't work for me was receiving SMS during suspend. we'd need to check if the resume reason was an incoming SMS Apr 13 11:54:18 ok Apr 13 11:54:32 whats with PDP sessions? Apr 13 11:54:41 morphis, shall I implement the [serial:/dev/ttyHS3:115200,...] parsing in the combined.vala file and thus change the CombinedTransport constructor, or shall I implement it in case "combined": (in transport.vala) Apr 13 11:55:33 hmm... mickeyl and mrmoku worked on PDP at the FSOSHRCON. I never tested it. you should ask mrmoku about this Apr 13 11:55:59 ok Apr 13 11:56:20 maybe we can make the parsing of the triple part of a common method Apr 13 11:57:21 but implement it for now as part of combined.vala Apr 13 11:57:36 ok Apr 13 12:06:52 freesmartphone.org: 03morphis 07cornucopia * r495cf37c1957 10/fsodatad/configure.ac: fsodatad: restructure autoconf/automake configuration to be ready for a release Apr 13 12:06:52 freesmartphone.org: 03morphis 07cornucopia * r5e395e3b6d89 10/fsoaudiod/configure.ac: fsoaudiod: restructure autoconf/automake configuration to be ready for a release Apr 13 12:06:53 freesmartphone.org: 03morphis 07cornucopia * r09f7ea43bbc4 10/ (16 files in 16 dirs): Update autotools bootstrap script for all components Apr 13 12:06:53 freesmartphone.org: 03morphis 07cornucopia * r201e202c2b51 10/fsoaudiod/src/alsa_hooks/session/alsa-wrapper.c: fsoaudiod: alsa_hooks: add missing alsa-wrapper source file Apr 13 12:06:54 freesmartphone.org: 03morphis 07cornucopia * r551f7ac429a7 10/fsoaudiod/ (13 files in 13 dirs): fsoaudiod: refactor automake infrastructure to use common vala automake bits Apr 13 12:06:55 freesmartphone.org: 03morphis 07cornucopia * ra7a19ae6f4b9 10/fsodatad/src/ (bin/Makefile.am lib/Makefile.am plugins/world/Makefile.am): fsodatad: refactor automake infrastructure to use common vala automake bits Apr 13 12:07:22 slyon: for the fsoaudiod alsa routing we need to add support in the SHR applications Apr 13 12:07:26 to get the routing etc. done Apr 13 12:08:38 morphis, i already did a call with fsoaudiod on the gta04. it worked with gnutoo's alsa_forwarder but it used 100% CPU. dunno how it works excactly Apr 13 12:09:19 ok Apr 13 12:09:35 isn't there another solution from radekp which doesn't use 100% CPU? Apr 13 12:13:12 there is ;-) Apr 13 12:13:50 it can also do echo cancellation - without it it's unusable Apr 13 12:13:56 :) Apr 13 12:14:06 radekp: but it doesn't take 100% of the CPU? Apr 13 12:43:08 morphis: no Apr 13 12:44:15 morphis: 10% cpu Apr 13 12:49:40 hi Apr 13 12:52:03 gnutoo: heyho Apr 13 12:52:20 radekp: how we have to use the your routing program? Apr 13 12:54:07 hi gnutoo Apr 13 12:55:51 * mrmoku was distracted by eggly formed chocolate pieces the last days but will start to look into the audio router tonight Apr 13 12:56:14 morphis: i am just running it as separate process Apr 13 12:56:45 morphis: to use radek routing program do that: Apr 13 12:56:48 and it takes constantly 10% of the CPU? Apr 13 12:56:50 opkg remove fsoaudiod-config Apr 13 12:56:52 and run it Apr 13 12:56:55 morphis: yes Apr 13 12:57:05 hm Apr 13 12:57:07 morphis: i guess that 10% is the echo cancellation Apr 13 12:57:18 morphis: otherwise IIRC it was ~1% Apr 13 12:57:39 can we limit the echo cancellation only to the timeframe where there is really something to process Apr 13 12:57:45 like in a phonecall? Apr 13 12:58:05 morphis: imo running it as separate process makes quite sence, since you can set priority and send signal to stop it Apr 13 12:58:16 ok Apr 13 12:58:37 so we can start it when a call receives and close it when call is over? Apr 13 12:59:01 morphis: yes exactly Apr 13 12:59:18 morphis: you can start it even before the call starts - the program can handle it Apr 13 13:00:18 morphis: btw with newer GTA04A04 you wont need it at all once the HW route kernel patches are included Apr 13 13:01:19 morphis: so i spend a quite a lot of time on project that will be actually used just by like by 10 users - but nevermind... Apr 13 13:01:49 so we just start it when an outgoing call get's initiated or an incoming call is ringing and we would be done... hmm Apr 13 13:02:27 and that 10 users is a good argument to maybe *not* invest the time to do it properly inside FSO but live with that 'hack' instead Apr 13 13:02:34 gnutoo: what do you think? Apr 13 13:11:50 btw the program on SIGTERM closes alsa streams - dont forget to send it (e.g. dont kill it just with SIGKILL) Apr 13 13:12:28 radekp: thats something nice too know as I have a A$ Apr 13 13:12:34 s/A$/A4/ Apr 13 13:12:35 morphis meant: radekp: thats something nice too know as I have a A4 Apr 13 13:13:03 mrmobil: yes with the hack to control the program from radekp from fsoaudiod Apr 13 13:13:21 which starts/stops the router according to the call status Apr 13 13:13:30 s/mrmobil/mrmoku/ Apr 13 13:13:41 morphis: yeah, I will look into it tonight... package it... and make the fsoaudiod plugin start/stop it Apr 13 13:13:53 both are fine :-) (mrmoku + mrmobil) Apr 13 13:14:17 :) Apr 13 13:14:48 bb in some minutes Apr 13 13:15:02 mrmoku: what do I think about what? Apr 13 13:15:31 mrmoku: that would be fine Apr 13 13:15:45 gnutoo: about just using radeks router as external process and start/stop it via the plugin in fsoaudiod Apr 13 13:16:04 gnutoo: as radekp correctly stated... it's just for GTA04 A3... that's not many users Apr 13 13:16:36 radekp: what about the kernel routing patches? are they available somewhere? Apr 13 13:17:30 radekp: ah found them on the gta04-owner ML Apr 13 13:19:35 morphis, the combined transport is finished, tested and working :) Apr 13 13:19:48 slyon: yeah! Apr 13 13:19:52 already pushed? Apr 13 13:19:54 i had to change the inner seperator from : to ; though Apr 13 13:19:58 yes just pushed Apr 13 13:20:02 ok, I am fine with that Apr 13 13:20:08 so I can merge it? Apr 13 13:20:14 (after a short review) Apr 13 13:20:24 yes. i tested it on my gta04 and it's working Apr 13 13:20:32 ok Apr 13 13:20:43 btw. someone knows about mickeyl? Apr 13 13:20:59 parsing is a little ugly. but it will be refactored anyway, right? Apr 13 13:21:09 (2 times the nearly same code) Apr 13 13:21:47 i guess mickeyl is still busy with his family life. he was here few days ago though Apr 13 13:21:51 yes Apr 13 13:22:05 you tested with parallel use of the data access? Apr 13 13:22:51 slyon: ah ok, so he is not dead :) Apr 13 13:22:52 great Apr 13 13:22:59 as I wrote him several mails and he never answered Apr 13 13:23:02 yes. (i didn't comment data_access) but i didn't connect to / use the umts network Apr 13 13:23:08 ok Apr 13 13:23:08 morphis: yeah, he is busy with some work projects + family... though work projects might finish soon :-) Apr 13 13:23:12 slyon: I see one problem Apr 13 13:23:20 * mrmoku bbl Apr 13 13:23:23 mrmoku: good to hear :) Apr 13 13:24:48 slyon: I see one problem with your code Apr 13 13:24:54 morphis, which problem? Apr 13 13:25:14 slyon: you parse the transport lines and after you parsed one successfully you create it's transport Apr 13 13:25:34 shouldn't we create the transport only when we parsed both transport lines successfully? Apr 13 13:26:16 mrmoku: hmmmm Apr 13 13:26:32 mrmoku: you need to make it work with dmix or default Apr 13 13:26:41 if you use radek forwarder Apr 13 13:26:43 morphis, yes. that would keep us in a consistend state Apr 13 13:26:52 I failed to do that Apr 13 13:27:12 else there is still alsaloop but it uses too much CPU when the modem is not ready Apr 13 13:27:21 so it needs to be profiles and fixed Apr 13 13:30:15 so I am off Apr 13 13:30:17 cya Apr 13 13:40:43 mrmobil, look the backlog Apr 13 13:41:10 I responded.... Apr 13 13:42:33 so we have 2 ways.... Apr 13 13:42:59 or we fix radek's rwarder or we fix alsaloop Apr 13 13:44:58 gnutoo: hi, dont forget that alsaloop without echo cancellation is useless Apr 13 13:45:14 ok but we can do that from the modem right? Apr 13 13:45:19 gnutoo: but it should not be that hard to add echo cancellation there Apr 13 13:45:53 gnutoo: if you do SW sound routing you need SW echo cancellation Apr 13 13:46:11 ah ok Apr 13 13:46:11 gnutoo: at least i havent found way how to cancel echo by the modem Apr 13 13:46:23 DocScrutinizer51: made me think otherwise.... Apr 13 13:48:05 i know it does not make logic, but that's how it behave... Apr 13 13:48:15 ok Apr 13 13:48:46 radekp: DocScrutinizer51 knows well alsa....he has many pointers for us Apr 13 13:50:04 for instance many things are hardcoded in your forwarder Apr 13 13:50:18 it has no threading.... Apr 13 13:50:19 etc.... Apr 13 13:50:52 gnutoo: well feel free to improve it :) Apr 13 13:50:58 ok Apr 13 13:51:03 I tried but I failed Apr 13 13:51:07 gnutoo: btw why threading at all? Apr 13 13:51:30 your forwarder works with which wirtei/readi? Apr 13 13:51:34 the blocking one? Apr 13 13:51:39 yup Apr 13 13:51:42 ok Apr 13 13:52:16 but it blocks only when reading from the first device Apr 13 13:52:32 ah ok, that's why it work for your use case then Apr 13 13:52:54 when it gets further remaining alsa buffers are filled/emptie so the reads/writes dont block Apr 13 13:53:14 ok Apr 13 13:53:32 that's how i understand it, i may be wrong :) Apr 13 13:53:40 ask DocScrutinizer51 Apr 13 13:54:27 * radekp is now compiling OpenSSL for windows CE 4.1 ;-) Apr 13 13:54:40 i need to do some payed work too Apr 13 13:54:49 note that our "default" is very different Apr 13 13:54:52 it's not hw:0 Apr 13 13:55:20 it's a dmix like thing Apr 13 13:55:39 and it's S32_LE Apr 13 13:55:43 and it's stereo Apr 13 13:56:08 so I changed the parameters and it -EPIPE(buffer overflow and underfolow) Apr 13 13:56:09 isnt this the reason for high cpu? if alsa has to remix it? Apr 13 13:56:35 high cpu is only in alsaloop Apr 13 13:57:04 no, dmix doesn't hog CPU Apr 13 13:57:22 your code spinning unthrottled loops does, though Apr 13 13:58:09 DocScrutinizer: hi, "your code" means the alsaloop code or mine routing program? Apr 13 13:58:28 the one gnutoo pointed me at Apr 13 13:58:28 your routing program Apr 13 13:58:39 the 100ms loop Apr 13 13:58:41 ahh oki Apr 13 13:58:44 s/loop/wait Apr 13 13:59:02 you could for instance read and block until it is ok Apr 13 13:59:11 *block-read Apr 13 13:59:12 and you can't handle two streams in one loop Apr 13 13:59:46 as the streams can and will get outa sync Apr 13 14:00:32 hmm but for some reason it work perfectly ;-) Apr 13 14:00:42 erm works Apr 13 14:01:16 if it blocks on only one call/stream (either read() or write()) then the other one will eventually xrun Apr 13 14:01:34 if it blocks on neither, you got a CPU hog Apr 13 14:01:37 it works for your setup Apr 13 14:01:42 not for mine for instance Apr 13 14:02:12 DocScrutinizer: i think it always blocks here: route_stream_read(&r0) Apr 13 14:03:09 then route_stream_read(&r1); will not block - since the r1 (umts sound rec) already has data Apr 13 14:03:39 well, iirc gnutoo said he got a extremely high number for function calls when profiling the binary, and that makes me think it doesn't block at all Apr 13 14:04:22 DocScrutinizer: well you can put printf there - i am quite sure i did it and it did block properly Apr 13 14:04:23 anyway, the statement "you can't service two unsynced audiostreams in one loop" is fundamental Apr 13 14:04:52 DocScrutinizer51: the profiling was done on alsaloop Apr 13 14:04:59 I tried 2 things Apr 13 14:05:01 DocScrutinizer: of course it's called many times, since it's done 30x per second Apr 13 14:05:03 profiling alsaloop Apr 13 14:05:08 and fixing radek's forwarder Apr 13 14:05:12 both failed for me Apr 13 14:05:41 DocScrutinizer: but if you have larger buffers you will have unwanted delay Apr 13 14:05:46 gnutoo: it would've helped you explaned the fact that you're talking about different things Apr 13 14:06:05 radekp: did I say sth about larger buffers? Apr 13 14:06:11 DocScrutinizer: i aggree on the "two unsynced audiostreams in one loop" Apr 13 14:06:21 ok Apr 13 14:06:31 DocScrutinizer: sorry - i wanted to explain why there are many calls Apr 13 14:06:51 who said that radek's program consume too much CPU? Apr 13 14:07:03 gnutoo's numbers were in the millions for 70s iirc Apr 13 14:07:35 DocScrutinizer: i wanted to implement some syncing later, but it appeared that it works even without it - i have no idea why it works though Apr 13 14:07:54 my numbers were on alsaloop Apr 13 14:07:58 it works when your streams are perfect Apr 13 14:08:10 gnutoo: it would've helped you explaned the fact that you're talking about different things Apr 13 14:08:11 which can use 100% cpu Apr 13 14:08:29 DocScrutinizer: maybe the clocks of UMTS and internal sound card are enough precise so that you wont notice problem Apr 13 14:08:40 maybe Apr 13 14:08:43 *)profiling was done on alsaloop Apr 13 14:08:46 until you get dropouts Apr 13 14:09:02 not an unusual thing with inbound GSM Apr 13 14:09:07 DocScrutinizer: maybe you get after some time xrun and they got synced again? Apr 13 14:09:17 yes Apr 13 14:09:25 that's what will happen Apr 13 14:09:40 the more they are outa sync the more xruns Apr 13 14:09:44 i am printing xruns on the screen btw ;-) Apr 13 14:09:57 *)trying to fix radek's program was also attempted by me and I failed....here I tried removing the manual stuff and changing the parameters(buffer size etc...) Apr 13 14:10:03 and a glitch in instream induces glitch in outstream Apr 13 14:11:24 gnutoo: maybe if you give me your asound.conf i can try to make the program working with it Apr 13 14:11:50 I don't have it right now but I'll do Apr 13 14:12:01 for mic->GSM stream you need to block on the timing msgs from modem, i.e. on writei() or nearby. Not on readi() Apr 13 14:12:02 it's in fsoaudiod/conf/alsa.conf or something like taht Apr 13 14:12:12 DocScrutinizer: well but for short calls it does not happen, i just did 90s long call and no xruns Apr 13 14:12:25 maybe mrmoku could pastebin it? Apr 13 14:13:45 for gsm->earpiece you want to block on readi() Apr 13 14:14:18 implement two threads, each with a loop with one read() and one write(), for one stream Apr 13 14:15:21 DocScrutinizer: oki, i see Apr 13 14:16:23 * radekp has to go home now... Apr 13 14:16:27 ok Apr 13 14:17:04 i'll be back probably on sunday, got football match tomorrow ;-) Apr 13 14:17:25 while !abort {read_mic_nonblock(); wait_for_timing_msg(); write_to_GSM_nonblock()}; & while !abort {read_GSM_block(); write_to_earpiece_nonblock()} Apr 13 14:19:12 DocScrutinizer: i am writing it down, but no idea when i will get to it... Apr 13 14:19:36 DocScrutinizer: thanks for explaining Apr 13 14:19:41 yw Apr 13 14:19:55 ok,maybe mrmoku and me should try to incrementally improve the fowarder? Apr 13 14:25:54 gnutoo, i just finished the FSO combined transport, which can be used on the gta04 to avoid CLCC polling during calls Apr 13 14:26:09 morphis will review it and do a second test. then it will get merged Apr 13 14:26:29 so with this code finished calls are detected Apr 13 14:26:59 as we're listening on /dev/ttyHS5, where the "NO CARRIER" URC is send Apr 13 14:28:14 slyon: ok wow nice Apr 13 14:30:23 SHR: 03shr-devel 07buildhistory * re944de6e85dd 10/packages/ (880 files in 880 dirs): packages: Build 201204131519 of shr 20120413 for machine om-gta02 on opmbuild Apr 13 14:31:49 ok Apr 13 14:32:21 slyon: we're sure that the NO CARRIER is for the call ended? Apr 13 14:33:14 mrmoku: did you start trying radek's forwarder Apr 13 14:35:46 gnutoo, yes. thats how it's defined in the spec and how it works on the gta02 Apr 13 14:36:06 ok Apr 13 14:39:35 bbl bye Apr 13 15:08:43 Good day all , have flashed cpucake on Nand before , all system.img userdata.img and kernel.img should be replaced ? Apr 13 15:08:57 android cpucake* Apr 13 15:19:52 alabd, probably try asking in #android-on-freerunner Apr 13 15:36:12 heyho Apr 13 15:37:43 slyon|away: tried before Apr 13 15:37:49 morphis: heya Apr 13 15:39:06 SHR: 03shr-devel 07buildhistory * r2c262f249316 10/packages/ (877 files in 877 dirs): packages: Build 201204131637 of shr 20120413 for machine nokia900 on opmbuild Apr 13 15:59:23 freesmartphone.org: 03morphis 07cornucopia * r82a199baac1e 10/ (4 files in 2 dirs): Merge branch 'fsotransport/combined-transport' Apr 13 16:01:02 slyon|away: your branch is merged to master now Apr 13 16:17:58 SHR: 03Martin.Jansa 07meta-smartphone * rc32608c68597 10/meta-shr/recipes-shr/shr/libphone-ui-shr_git.bb: libphone-ui-shr: bump PR for libelementary soname change Apr 13 16:17:59 SHR: 03Martin.Jansa 07meta-smartphone * rdaf66386ef24 10/meta-shr/recipes-shr/3rdparty/intone_git.bb: intone: bump PR for libelementary soname change Apr 13 16:17:59 SHR: 03Martin.Jansa 07meta-smartphone * r1a454d2b6df3 10/meta-shr/recipes-shr/shr/shr-e-gadgets_git.bb: shr-e-gadgets: bump PR for libelementary soname change Apr 13 16:17:59 SHR: 03Martin.Jansa 07meta-smartphone * r0b5383c6798a 10/meta-shr/recipes-shr/3rdparty/emtooth2_svn.bb: emtooth2: bump SRCREV for naviframe switch Apr 13 16:17:59 SHR: 03Martin.Jansa 07meta-smartphone * rdf86b7297190 10/meta-shr/recipes-shr/3rdparty/ffalarms_git.bb: ffalarms: bump SRCREV for naviframe switch Apr 13 16:53:34 SHR: 03shr-devel 07buildhistory * r072ab4e90ef1 10/packages/om_gta04-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201204131745 of shr 20120413 for machine om-gta04 on opmbuild Apr 13 17:18:51 mrmoku, ping Apr 13 17:23:10 GNUtoo-desktop: pong Apr 13 17:24:14 GNUtoo-desktop: I'm writing a recipe for the forwarder now Apr 13 17:24:26 and I wonder if that belongs to the openmoko or to the fso layer... Apr 13 17:24:57 somehow it is openmoko... but will be needed by fsoaudiod Apr 13 17:24:59 hmm Apr 13 17:26:15 ok Apr 13 17:26:50 altough we might want to fix the forwarder before writing a recipe Apr 13 17:26:59 beause right now it doesn't work with dmix Apr 13 17:27:01 I need the recipe to fix it Apr 13 17:27:05 and that is a uhge issue Apr 13 17:27:06 ok Apr 13 17:27:10 I have no idea about using devshell Apr 13 17:27:21 mrmoku, there is a morphis devshell Apr 13 17:27:31 in morphis's meta-staging Apr 13 17:27:41 it's the same as the good old devshell Apr 13 17:27:50 hmm Apr 13 17:28:06 I wonder what is easier... integrate that layer or write a recipe for it :-) Apr 13 17:28:49 (which we need anyway if it turns out to work) Apr 13 17:30:12 on the other hand that devshell thing might turn out handy in other occasions as well... Apr 13 17:30:29 GNUtoo-desktop: short instruction on how to use it? Apr 13 17:31:27 bitbake devshell Apr 13 17:31:45 source ~/path/to/deploy/add-on/gta04* Apr 13 17:31:48 oe_runmake Apr 13 17:33:48 GNUtoo-desktop: well firwt I have to clone meta-staging from somewhere Apr 13 17:34:05 s/firwt/first/ Apr 13 17:34:05 mrmoku meant: GNUtoo-desktop: well first I have to clone meta-staging from somewhere Apr 13 17:35:12 mrmoku, yes in morphis's repos in github Apr 13 17:36:22 ok Apr 13 17:41:21 ok... building devshell Apr 13 17:43:27 mrmoku, you can bitbake -b it if you want Apr 13 17:43:29 that would be faster Apr 13 17:43:39 if you already have the toolchain built Apr 13 17:43:53 hmm... I updated everything... so I guess it's better to build dependencies too Apr 13 17:44:05 it's building complete toolchain Apr 13 17:44:18 ok Apr 13 17:45:29 mrmoku: does devshell work again ? as i Know it was broken fo a long time Apr 13 17:49:46 nschle85, yes but you must import morphis's meta-staging for that Apr 13 17:50:06 nschle85: morphis has a meta-staging layer with a working devshell Apr 13 17:50:21 https://github.com/morphis/meta-staging Apr 13 17:50:39 mrmoku: GNUtoo-desktop: why is it not merged upstream ? Apr 13 17:54:16 mrmoku: GNUtoo-desktop: is the order in bblayers.conf important ? devshell does currently exists in oe-core too but does not work i think Apr 13 17:54:47 nschle85, because morphis didn't do it, I asked him many times tough Apr 13 17:55:16 it's not that it doesn't work in oe-core it's that it's implemented differently Apr 13 17:55:22 and seem to do something different Apr 13 17:56:45 GNUtoo-desktop: but why is the morphis one used instead of oe-core one ? how does bitbake decide that ? Apr 13 18:00:02 I guess by looking into meta-staging/conf/bblayer.conf Apr 13 18:00:06 mrmoku: at the moment the PIN dialog does not appear on image 045 and my self build image for N900 do you have the same problem ? Apr 13 18:00:09 there are priorities defined there Apr 13 18:00:47 ah ok, so the order in bblayers.conf is not important, true ? Apr 13 18:02:38 no idea Apr 13 18:02:42 I guess not Apr 13 18:02:48 but ask JaMa Apr 13 18:06:08 SHR: 03shr-devel 07buildhistory * r37d8d55c1d3f 10/packages/palmpre-oe-linux-gnueabi/shr-version/ (latest shr-version/latest): packages: Build 201204131859 of shr 20120413 for machine palmpre on opmbuild Apr 13 18:11:01 GNUtoo-desktop: I know you reminded me many times to get the devshell thing upstream but I didn't had the time to do this Apr 13 18:11:20 yes I know Apr 13 18:20:00 btw. slyon|away and I resolved the problem that we don't get any call-end event on the GTA04 today Apr 13 18:20:22 it will be in the SHR images with the next SRCREV bump of FSO Apr 13 18:20:29 i know its the wrong channel but anybody of you a mysql expert ? I destroyed my installation by an update and mysql wont start now Apr 13 18:24:31 morphis, didn't slyon-away solved it too in a branch? Apr 13 18:24:43 GNUtoo-desktop: I talked about that branch Apr 13 18:24:47 it's now merged to master Apr 13 18:24:47 ok Apr 13 18:24:50 nice Apr 13 18:25:15 :) Apr 13 18:25:26 it's better than the polling solution Apr 13 18:27:04 yes I know Apr 13 18:27:10 I talked with slyon Apr 13 18:27:19 I know his solution Apr 13 18:27:38 basically NO CARRIER get emmited in another serial port Apr 13 18:27:41 better than what the ofono guys did :) Apr 13 18:27:47 lol wow Apr 13 18:27:53 :D Apr 13 18:30:05 so now the remaining things are: Apr 13 18:30:12 * AT+VTS=n Apr 13 18:30:15 * a forwarder Apr 13 18:30:17 ---- Apr 13 18:30:42 * more usable apps such as a good browser(important tough) Apr 13 18:33:30 GNUtoo-desktop: yes Apr 13 18:33:38 GNUtoo-desktop: I already started with the AT+VTS one Apr 13 18:33:41 wow Apr 13 18:34:13 it needs some fundamental changes in the FSO stack Apr 13 18:34:22 mrmoku, did you succeed at building radek's forwarder Apr 13 18:34:25 yes I saw that Apr 13 18:34:33 that's why I failed.... Apr 13 18:34:41 but can you please describe in detail in the bug report what you did to reproduce this issue? Apr 13 18:34:54 I ran SHR image Apr 13 18:35:12 and I called 4242(an operator number) Apr 13 18:35:21 I pressed a button(9 for instance) Apr 13 18:35:28 and it kept repeating AT+VTS=9 Apr 13 18:35:32 ok Apr 13 18:35:39 should I narrow the test case Apr 13 18:35:40 will add that to the bug report Apr 13 18:35:44 with only fso? Apr 13 18:36:00