**** BEGIN LOGGING AT Mon Jan 02 02:59:56 2012 Jan 02 07:55:36 rah: yes, we don't have gta01 and nobody to test it :/ Jan 02 08:31:10 mrmoku: I was thinking about that one big libefl tree and from OE POV there is big disadvantage, that we need e.g. edje-native for edje_cc and then we'll have to build whole libefl-native maybe with lots of native deps if the options don't allow to build only specific parts of libefl tree Jan 02 08:45:31 JaMa: ohh... yes, indeed Jan 02 08:45:36 that is bad Jan 02 08:45:55 maybe something we should take up with e-devels Jan 02 08:46:01 TAsn: ^ Jan 02 08:48:41 anyone against merging 015/016 to public feed today? Jan 02 08:49:14 015 reports are good, but there weren't images, so 016 will be just image build and then rsync of all to public feed Jan 02 08:51:12 and I'll create http://www.shr-project.org/trac/wiki/StagingTestsMerged and move there all already merged staging feeds, to deal with size of StagingTests page Jan 02 08:51:14 I did not test anything yet since I was away... but good reports are good reports :-) Jan 02 09:02:18 ah it's not just image build, there was cornucopia bump too, so I'll keep 016 with images for more testers for some time too Jan 02 09:11:21 JaMa: ok, will test gta02 today Jan 02 09:14:35 mrmoku: please wait for 016 image then :) Jan 02 09:14:43 NOTE: Running task 4657 of 6862 Jan 02 09:15:22 I'll test n900 Jan 02 09:23:42 good Jan 02 10:14:09 heyho Jan 02 10:19:26 morning from the new office Jan 02 10:25:37 mickey_office: moin mickey_office ... you moved? Jan 02 10:34:06 mrmoku: image in 016 ready for you, but don't tell anyone it's not closed yet :) Jan 02 10:37:09 JaMa: hehe, ok :P Jan 02 10:40:53 mrmoku: yeah, the GbR moved into a new place, much more room, also a new employee Jan 02 10:44:11 mickey_office: congrats :) Jan 02 10:45:00 we're considering an employee too... just no freaking idea how to find a good one ... Jan 02 10:45:48 just reject the wrong one until you find the good one ? Jan 02 10:46:05 or just offer temporary work until you grasp how to get a good one ? Jan 02 10:46:36 mrmoku: considering an employee where ? Jan 02 10:49:19 phh: munich Jan 02 10:49:56 misc: yeah, something like that :/ Jan 02 10:51:50 mrmoku: IIRC, joel spolsky had some good articles on this Jan 02 10:52:08 * mrmoku googles Jan 02 10:52:57 hi mickey_office Jan 02 10:52:59 or mickeyl ? Jan 02 10:53:37 mrmoku: http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html Jan 02 10:54:49 mrmoku: I would also sugest to do some test interview first, with friends, so you know what to do ( I did this , on the other side of the table, I answered to job offer that I was not interested to in order to practice ) Jan 02 10:54:51 misc: thx, lots of nice articles there :) Jan 02 10:55:13 does someone knows how to pass a vapidir in fso? Jan 02 10:55:57 btw the cmtspeech handler still contains many bugs and need to be cleaned more Jan 02 11:00:45 ah you can pass VALAC= to ./configure Jan 02 11:02:48 GNUtoo: --vapidir ? Jan 02 11:12:28 morning GNUtoo Jan 02 11:12:38 GNUtoo: --vapidir Jan 02 11:13:07 yes but I didn't know how to pass it to autotools Jan 02 11:13:12 mrmoku: have you seen my e-mail in coredevs? Jan 02 11:13:21 who is going to FOSDEM? Jan 02 11:13:33 now I did it with VALAC="$(which valac) --vapidir ..." Jan 02 11:24:59 JaMa: yeah... maybe pespin has some... or slyon Jan 02 11:25:16 JaMa: coredevs? Jan 02 11:25:31 morphis: there is a shr-core ml Jan 02 11:25:47 very secret SHR ML, it took me couple of minutes to even find it's address Jan 02 11:26:00 because there is no traffic at all :) Jan 02 11:26:08 indeed :/ Jan 02 11:26:20 and 3/4 of the members are inactive anyway Jan 02 11:26:59 btw there is automake-1.11.2 upgrade on oe-core ML, some recipes need extra patches (already done for oe-core) Jan 02 11:27:40 now I'm wondering if I should allow automake upgrade in shr-chroot too, or mask it for a while at least until we finish 1.11.2 transition in rest of OE recipes Jan 02 11:27:58 without rebuild from scratch I cannot test this properly Jan 02 11:28:00 mrmoku: interesting Jan 02 11:28:12 hmm... maybe masking for a while would be good Jan 02 11:28:51 mrmoku: ok, done Jan 02 11:34:22 JaMa: you remember our problems with qt-components in OE? Jan 02 11:36:32 no Jan 02 11:36:47 JaMa: when I had included the recipe for qt-components in meta-aurora Jan 02 11:37:03 we had several issues with getting the files correctly installed and packaged Jan 02 11:37:05 was it those sed calls moving back and forth? Jan 02 11:37:51 yes Jan 02 11:38:07 I am currently playing with it again Jan 02 11:38:21 I reverted my commit which removed the recipe Jan 02 11:38:30 and you told me you got it working fine with some little changes Jan 02 11:38:36 do you still have them somewhere? Jan 02 11:39:41 let me check after lunch Jan 02 11:40:09 ok Jan 02 11:40:45 iirc I've send you only e-mail about fix for linking wrt DSO Jan 02 11:41:28 just adding -lX11 or something like that, not playing with sed calls in .inc again Jan 02 11:41:50 ok first part of fowarder is coded more cleanly Jan 02 11:41:59 I'll test it now Jan 02 11:42:02 morphis, hi Jan 02 11:42:20 JaMa: ah I found the mails Jan 02 11:42:22 GNUtoo: heyho Jan 02 11:42:28 morphis, 2 things: Jan 02 11:43:06 1) in palm pre mplayer can freeze the phone even within a chroot with the standard pre kernel in the standard OS(I already said it but I don't remember if you were there) Jan 02 11:43:16 2) I got precomm working with bootie Jan 02 11:43:47 GNUtoo: yes, it's a problem with kernel; there some patches flying around somewhere but they didn't helped to fix the problem Jan 02 11:43:57 ok Jan 02 11:44:02 GNUtoo: try searching for 2.6.24 + arm + neon problems Jan 02 11:44:05 something like that Jan 02 11:44:16 I'll look later, it doesn't even boot right now Jan 02 11:44:19 about precomm: great, what did you do? Jan 02 11:44:27 it doesn't boot? Jan 02 11:44:47 I tried sniffing the USB understood it etc... but the thing what that I had to comment that line(rather simple): Jan 02 11:45:33 - dev->state=STATE_LIMBO; Jan 02 11:45:56 SHR: 03Martin.Jansa 07shr-chroot * r6c2c31249f8f 10/ (1483 files in 71 dirs): system upgrade Jan 02 11:46:23 it echo the caracter twice tough Jan 02 11:46:27 instead of just once Jan 02 11:46:29 but it works Jan 02 11:46:34 GNUtoo: and that still works for the normal mode? Jan 02 11:46:39 if you type something it send one time only Jan 02 11:46:44 yes I guess so Jan 02 11:49:23 GNUtoo: ok, do you asked at webos-internals for commit access for the repository? Jan 02 11:49:30 or should we import it at fso.git? Jan 02 11:49:35 within utilities? Jan 02 11:49:49 they will move to github Jan 02 11:49:55 and I'll send a merge request Jan 02 11:50:01 *more precomm to github Jan 02 11:50:22 yo morphis Jan 02 11:53:08 mickey_: heyho Jan 02 11:53:22 mickey_: you wanted to discuss something with me about fsoeventsd right? Jan 02 11:53:30 GNUtoo: ah o Jan 02 11:53:32 k Jan 02 11:53:56 GNUtoo: but I hope they will release the novacom thing as opensource Jan 02 11:55:38 JaMa: hmm... alarms seems to segfault when adding one Jan 02 11:55:49 yes me too but it'll take soo long that I had to do something about it Jan 02 11:56:00 that is to say or we support the pre and work on it Jan 02 11:56:08 and fix that booting issue Jan 02 11:56:11 or we drop it Jan 02 11:56:39 but if we choose to work on it and that I want to participate I needed precom Jan 02 11:57:43 * mrmoku lunch Jan 02 11:58:28 mickey_, should I push early and often? Jan 02 11:58:35 or should I push when done? Jan 02 11:59:52 morphis: fsoeventsd yeah, i didn't have a chance to think about that yet though. i rather wanted to ask wrt. vala master, it solved things differently in posix.vapi, so we need to apply a patch when the next stable release has been made Jan 02 11:59:55 GNUtoo: early and often is fine Jan 02 12:00:17 ok I'll clean the identation then Jan 02 12:00:23 and push Jan 02 12:00:26 mickey_: yes, I already managed that things are fixed with 0.14.2 Jan 02 12:00:53 and I have some local patches for that Jan 02 12:00:58 mickey_, btw I've "included" the ring buffer Jan 02 12:00:58 I will push when 0.14.2 is out Jan 02 12:01:05 it will need to move out Jan 02 12:01:18 to be somewhere common between cmt and that gta04 plugin Jan 02 12:01:41 mickey_: look here: http://git.freesmartphone.org/?p=cornucopia.git;a=shortlog;h=refs/heads/vala-0.14.2-support Jan 02 12:01:54 I have to leave for some time Jan 02 12:02:03 will be back in about 1-2 hours Jan 02 12:04:14 k Jan 02 12:10:27 can we really not do anything about spam in shr-trac? Jan 02 12:12:33 I think I'll push in a branch as-is Jan 02 12:33:01 I sent a patch to shr-devel but it's 170KB and it's waiting for moderator approval Jan 02 12:33:05 * rah glances at Ainulindale Jan 02 12:33:30 should I wait or send a pull request for a remote git repo instead? Jan 02 12:35:28 rah: I don't have access anymore to that Jan 02 12:35:35 I said so a year ago Jan 02 12:35:43 Sadly :-) Jan 02 12:35:44 oh dear Jan 02 12:35:58 mailman software thinks you're the administrator Jan 02 12:36:42 Shr-devel list run by ainulindale at gmail.com Jan 02 12:36:42 Shr-devel administrative interface (requires authorization) Jan 02 12:37:16 Well I asked twice to change that as I don't have the password anymore Jan 02 12:37:19 It never was Jan 02 12:37:24 I see Jan 02 12:37:27 that's bad Jan 02 12:37:36 who runs shr-project.org? Jan 02 12:38:52 now it's mrmoku Jan 02 12:39:52 mrmoku: sort it out! Jan 02 12:39:55 * rah slaps mrmoku Jan 02 12:40:09 There. My work is done. Jan 02 12:47:22 mrmoku: ffalarms it self or fsotdld? Jan 02 12:48:37 JaMa: have to look into it Jan 02 12:48:44 somehow it behaves strange in general Jan 02 12:48:47 very laggish Jan 02 12:49:00 rah: I have access to DNS... but not the ML Jan 02 12:49:25 mrmoku: who runs the web server/mail server? Jan 02 12:49:41 Ainulindale: you at least remember where it is running? Jan 02 12:49:55 nope Jan 02 12:51:30 rah: pull request is fine for me Jan 02 12:51:44 hmm... what is the best ML manager? Jan 02 12:52:20 mrmoku: IMHO, mailman, which is what is running shr-devel at the moment Jan 02 12:52:30 ok Jan 02 12:52:31 JaMa: ok Jan 02 13:01:47 oh Jan 02 13:02:25 I have created a project called "meta-smartphone" on gitorious, presuming it would be qualified by my user but apparently it's a global name Jan 02 13:02:41 so I've stolen meta-smartphone on gitorious, sorry :-) Jan 02 13:03:19 you can just copy it from ~jama/meta-smartphone Jan 02 13:03:35 it will be faster and I would see you on my meta-smartphone page Jan 02 13:03:52 https://gitorious.org/shr/meta-smartphone Jan 02 13:03:56 or this ^ :) Jan 02 13:04:22 wait a minute before "Clone" I'll update it to latest first Jan 02 13:04:45 hmm Jan 02 13:04:48 hi, I've the following problem: Jan 02 13:04:54 it's saying I can create it within the shr project Jan 02 13:04:56 I see that in my logs: Jan 02 13:05:03 lots of ringbuffer.read Jan 02 13:05:17 RingBuffer.read: ring_head=0, ring_tail=0, count=320, avail=0 Jan 02 13:05:17 RingBuffer.read: ring_head=0, ring_tail=0, count=320, avail=0 Jan 02 13:05:28 then It wait an eternity Jan 02 13:05:40 and there are ringbuffer.write: Jan 02 13:05:57 RingBuffer.write: ring_head=0, ring_tail=0, count=320, free=960 Jan 02 13:06:00 rah: ? Jan 02 13:06:10 RingBuffer.write: ring_head=320, ring_tail=0, count=320, free=640 Jan 02 13:06:17 but then it wait again an eternity Jan 02 13:06:29 so I added yield; Jan 02 13:06:33 right after that: Jan 02 13:06:46 JaMa: nevermind Jan 02 13:06:55 JaMa: it says "Create a clone of meta-smartphone in shr" Jan 02 13:07:13 in playback/record thread, right before the closing } for while Jan 02 13:07:22 but it still does the same Jan 02 13:07:23 JaMa: I was reading that as "deposit the clone in shr" rather than "clone the project that is currently in shr" Jan 02 13:07:25 mickey_, ^^^ Jan 02 13:07:41 rah: updated and btw your pull request should be against shr branch (not master) Jan 02 13:07:48 rah: ah I see Jan 02 13:08:15 JaMa: yes, I'm using the shr branch :-) Jan 02 13:09:26 rah: I don't see any permissions setting on "project", no idea maybe you can create repo under /shr prefix too Jan 02 13:09:44 freesmartphone.org: 03GNUtoo 07gnutoo/gta04-fsoaudiod-forwarder * re73023def62e 10cornucopia/fsoaudiod/src/plugins/gsmvoice_alsa_forwarder/plugin.vala: Jan 02 13:09:44 freesmartphone.org: fsoaudiod: improve gsmvoice_alsa_forwarder errors logging Jan 02 13:09:44 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jan 02 13:10:26 JaMa: I've cloned it now, and it's done it under ~rah Jan 02 13:10:29 git://gitorious.org/~rah/shr/rah-meta-smartphone.git Jan 02 13:10:29 note that it's in a branch Jan 02 13:12:55 (and I've deleted the meta-smartphone project :-) Jan 02 13:16:06 ahhh maybe I need async Jan 02 13:17:27 I'm lost in threads + async + yield Jan 02 13:19:02 * mrmoku will update his server and test-install mailman to see if that is something which he could get installed into his companies server ... Jan 02 13:20:00 mrmoku: but we would still need someone with access to get history :/ Jan 02 13:20:24 hmm... Jan 02 13:20:32 that will be challenging :P Jan 02 13:21:51 n900 reflashed with 016 image, let's see icons again :) Jan 02 13:21:59 ahh Jan 02 13:22:00 bamse.bearstech.com Jan 02 13:22:18 JaMa: I still got no icons on reboot Jan 02 13:22:26 with 016 on gta02 Jan 02 13:23:11 for me it worked again with 014 on n900 :/ Jan 02 13:24:48 heh, fun :/ Jan 02 13:35:41 mrmoku, do you know vala well? Jan 02 13:35:46 like threading? Jan 02 13:37:21 GNUtoo: nah, not well Jan 02 13:37:26 ok Jan 02 13:37:32 who could know? Jan 02 13:37:37 morphis, is always busy.... Jan 02 13:37:44 JaMa: I will ask lukhas if he can reset me the password Jan 02 13:38:09 that would be the easiest thing to do :) Jan 02 13:39:47 010-015 merged to public feed Jan 02 13:41:24 I asked in #vala Jan 02 13:41:28 in gimpnet Jan 02 13:44:58 dos1: now with new image names merged to public feed too we really need that download page fixed **** BEGIN LOGGING AT Mon Jan 02 13:47:34 2012 Jan 02 13:47:51 thanks Jan 02 13:51:53 GNUtoo: whats up with vala and threading? Jan 02 14:15:30 JaMa: I've sent a "merge request" on gitorious btw Jan 02 14:19:09 morphis, I tried threads such as: Jan 02 14:19:14 while (var > 0) Jan 02 14:19:21 /run writei and buffer stuff Jan 02 14:19:32 and same for readi Jan 02 14:19:38 rah: you have gta01, right? Jan 02 14:19:47 JaMa: yes Jan 02 14:20:06 the threads run for too long so the other thread doesn't get a chance to run early enough Jan 02 14:20:09 rah: are you interested to become maintainer of it for SHR? Jan 02 14:20:20 so I converted to async and yield Jan 02 14:20:22 like that: Jan 02 14:20:29 rah: ie update it's kernel to 2.6.39 or even better 3.2? Jan 02 14:20:31 while ( var > 0) Jan 02 14:20:36 //do stuff Jan 02 14:20:41 yield; Jan 02 14:20:43 } Jan 02 14:20:58 rah: problem with 2.6.37 is that after adding it to OE-classic I got no confirmation that it even boots Jan 02 14:21:04 but then the function run only once Jan 02 14:21:11 JaMa: well, it would appear that I've become the GTA01 maintainer by accident :-) Jan 02 14:21:20 morphis, do you have an idea? Jan 02 14:21:43 rah: that's why I didn't take 2.6.37 to shr-core and on FSOSHRCON we mostly said that gta01 is unsupported now Jan 02 14:22:13 btw I got no response in #vala Jan 02 14:22:13 JaMa: I haven't tried the image yet but I thought I would send the patch just so that one can get to the point of having an image to be tested Jan 02 14:22:32 I believe I did try the shr-unstable image though Jan 02 14:22:35 and had it boot Jan 02 14:22:42 I definitely remember trying shr-testing Jan 02 14:23:12 rah: ok, I'll merge it as soon as you confirm it boots :) Jan 02 14:23:16 ok Jan 02 14:23:39 I'll try it later, have ironing and stuff to do now :-) Jan 02 14:23:42 rah: and for next build I'll include it on buildhost Jan 02 14:23:51 cool Jan 02 14:24:35 and there is 3.2 branch on shr/linux for gta02 Jan 02 14:25:02 so if you can try to port missing bits for gta01 too, then you can skip upgrade to 2.6.39 Jan 02 14:25:11 aye Jan 02 14:25:40 kernel patches will come later I think, I just want to get a working image at the moment Jan 02 14:29:21 rah: I'll merge it without PR bumps in 2.6.39 Jan 02 14:29:41 mrmoku: there? Jan 02 14:29:50 as it doesn't change the output for gta02 and nobody built gta01 if it doesn't work for gta01 :) Jan 02 14:36:15 morphis, ping? Jan 02 14:36:49 else, mrmoku do you know how async work? Jan 02 14:38:43 GNUtoo: pong Jan 02 14:38:48 GNUtoo: let me read the lines Jan 02 14:38:53 was at launch Jan 02 14:38:55 ok thanks a lot!!!! Jan 02 14:39:53 GNUtoo: you need to call the async method back you yield in Jan 02 14:40:03 GNUtoo: like my_async_func.callback(); Jan 02 14:40:10 otherwise it never returns Jan 02 14:40:57 ? Jan 02 14:41:16 you mean like a lambda thing? Jan 02 14:42:29 GNUtoo: when you have async function Jan 02 14:42:39 it needs some point where it should return Jan 02 14:42:55 if you do yield; who tells the method that it should proceed again? Jan 02 14:42:56 yes doesn't yield make it return right after it? Jan 02 14:43:04 after what? Jan 02 14:43:08 like: Jan 02 14:43:14 /some code Jan 02 14:43:18 yield; Jan 02 14:43:22 //some other code Jan 02 14:43:39 after yield it doesn't return to "some other code"? Jan 02 14:43:55 it returns to "some other code" Jan 02 14:44:06 but someone must tell the async method that it should continue Jan 02 14:44:22 ahhh ok Jan 02 14:44:30 how shold I do that Jan 02 14:44:32 *should Jan 02 14:44:35 ? Jan 02 14:44:48 when you yield you want to defer some work Jan 02 14:44:58 then you need to decide somewhere else to continue again Jan 02 14:44:58 yes that's the point Jan 02 14:45:10 if you have that point you need to call async_method.callback() Jan 02 14:46:10 ok Jan 02 14:47:17 thanks a lot I'll read more about yield Jan 02 14:47:25 *async Jan 02 14:53:11 JaMa, rah: still need to aprove the message? Jan 02 14:57:43 hmmm Jan 02 14:58:08 what's the point of using buffers if I use yield Jan 02 14:58:19 it's not asyncronous (not in the vala sense) Jan 02 14:59:21 hmm Jan 02 14:59:38 when you have two threads... one writing to the buffer and one reading from it there should be no need for yield Jan 02 14:59:44 indeed Jan 02 14:59:49 anyway... got to reboot my server Jan 02 14:59:52 hopefully brb Jan 02 15:21:52 mrmoku, welcome back Jan 02 15:22:02 here's my problem: Jan 02 15:22:16 in the logs I see: Jan 02 15:22:21 many RingBuffer.read Jan 02 15:22:25 then many RingBuffer.write Jan 02 15:22:30 both are way too long Jan 02 15:22:34 mrmoku: his patch now arrived on ML and I have it in my branch too so someone already aproved it (you?) Jan 02 15:22:38 that's whith threads Jan 02 15:22:49 JaMa: yeah, got access now Jan 02 15:22:50 that's why I had the bad idea of using yield Jan 02 15:22:58 the gta04 has only one CPU.... Jan 02 15:23:06 GNUtoo: in what way too long? Jan 02 15:23:14 let me show you the logs Jan 02 15:23:17 ok Jan 02 15:23:25 mrmoku: nah, probably best to reject that email Jan 02 15:23:27 mrmoku: and ffalarms also segfaults on n900, I'll open ticket for that if you don't have it already (to use it in stagingTests report) Jan 02 15:23:33 mrmoku: thanks Jan 02 15:24:11 JaMa: did not do that yet... wanted to look closer first Jan 02 15:24:28 rah: thx for forcing us to have access to our mls again :) Jan 02 15:25:13 mrmoku: heh, np :-) Jan 02 15:25:41 mrmoku: #1624 and assigned to you :) Jan 02 15:25:58 hehe ok Jan 02 15:30:40 mrmoku, http://gnutoo.homelinux.org/downloads/people/mrmoku/logs.tar.bz2 Jan 02 15:33:48 what I ear is one microsecond and then nothing Jan 02 15:35:46 hmm Jan 02 15:35:54 GNUtoo: all pushed in that branch to take a look? Jan 02 15:36:01 yes Jan 02 15:37:28 also when I start calling the threads start.... Jan 02 15:37:39 but when I stop calling it continues Jan 02 15:37:47 for a quite long time Jan 02 15:37:49 and then stop Jan 02 15:41:58 can we block the read thread until there is something available in the buffer? Jan 02 15:42:44 hmm Jan 02 15:51:03 GNUtoo: why is it trying to read long before call status is active? Jan 02 15:51:13 ? Jan 02 15:51:29 ahh Jan 02 15:51:30 outgoing Jan 02 15:51:32 right now I'm making a waiter in the ringbuffer + threads Jan 02 15:52:03 I'll remove outgoing Jan 02 15:52:13 *hsould I remove outgoing Jan 02 15:52:30 well, no, you will want to hear it ringing Jan 02 15:55:48 definitely Jan 02 15:55:59 the other-party-connected-ringing tone is important Jan 02 15:56:16 ok Jan 02 15:57:21 indeed Jan 02 15:58:55 GNUtoo: why do we copy the buffer instead of using the ring directly? Jan 02 15:59:15 let me look Jan 02 15:59:48 I tought it was cleaner Jan 02 15:59:54 for instance if you implement some locks Jan 02 16:00:02 like for not overwriting etc... Jan 02 16:00:17 you don't block for long with copy Jan 02 16:00:52 hmm Jan 02 16:00:59 isn't overwriting what we want in this case? Jan 02 16:01:23 and no locking? Jan 02 16:01:43 really??? Jan 02 16:02:03 I mean we don't want to do ring buffer underrun and overrun Jan 02 16:02:05 rah: fwiw updated version of your patch is now in http://git.shr-project.org/git/?p=meta-smartphone.git;a=shortlog;h=refs/heads/meta-openmoko-wip Jan 02 16:02:38 rah: I've also moved COMPATIBLE_MACHINE from linux-openmoko_* to linux_* Jan 02 16:03:53 JaMa: I fixed the qt-components recipe now Jan 02 16:04:11 because else we read silence or old data Jan 02 16:04:14 JaMa: what do you think were does fit in best meta-aurora/meta-shr or meta-oe? Jan 02 16:04:57 morphis: does it depend on something which is not yet in oe-core? Jan 02 16:05:39 only on qt-components-graphics Jan 02 16:06:20 morphis: I would say add it to meta-aurora now and then send patch adding it to oe-core Jan 02 16:06:29 JaMa: ok Jan 02 16:07:34 GNUtoo: do we have alsaloop available to play with? Jan 02 16:07:42 alsaloop? Jan 02 16:07:44 what's that? Jan 02 16:08:06 we have arecord + aplay Jan 02 16:10:01 it's one of the alsa-utils Jan 02 16:10:11 looks like the thing we're trying to do :) Jan 02 16:10:19 might be worth a look into the source of it Jan 02 16:10:23 * mrmoku doing that right now Jan 02 16:18:33 GNUtoo: I wonder if I can test that on my laptop Jan 02 16:19:01 opkg install alsa-utils-alsaloop Jan 02 16:19:28 ahh Jan 02 16:19:35 no I can't... missing the call states :P Jan 02 16:19:42 ok Jan 02 16:20:18 but I could make a small executable out of the plugin Jan 02 16:20:32 and try to loop from my usb headset mic to the laptop internal speakers Jan 02 16:20:50 ok Jan 02 16:26:56 JaMa: hm I don't think I will submit the qt-components recipe to oe-core as it is very meego specific Jan 02 16:27:01 but usable without meego Jan 02 16:27:24 so I will maybe create a meta-meego which includes it + needed support recipes Jan 02 16:29:28 might be worth to just use it :-P Jan 02 16:30:02 mrmoku, are you sure of that: Jan 02 16:30:24 mrmoku: ^ Jan 02 16:30:24 free = (ring_size + ring_tail - ring_head) % ring_size; Jan 02 16:31:00 free = (ring_size + ring_tail - ring_head) % ring_size Jan 02 16:31:24 = (ring_size -( ring_head - ring_tail ) ) % ring_siz Jan 02 16:32:19