**** BEGIN LOGGING AT Wed May 18 02:59:57 2011
May 18 03:21:43 <DocScrutinizer> (<GNUtoo> the kernel is upstreamed by meego people) orly? o.O Thought they just *use* upstream kernel and furiously refuse to push own things upstream?
May 18 05:27:52 <mrmoku> DocScrutinizer: they use the upstream kernel in the sense that patches are only allowed if they're either unaccaptable for mainline or are being actively pushed to mainline
May 18 05:27:56 <mrmoku> that's what I understood
May 18 05:28:06 <mrmoku> and moin
May 18 05:41:14 <JaMa|Off> mrmoku: moin
May 18 05:41:20 <JaMa> WARNING: the following files were installed but not shipped in any package:
May 18 05:41:24 <JaMa> WARNING:   /usr/lib/alsa-lib/fsoaudio_session.so
May 18 05:41:37 <JaMa> should I fix it or do you have patch for it already?
May 18 05:49:34 <JaMa> mrmoku: and should I sync 2.6.37 to normal feeds? some reports were positive and those reported issues like leds we can fix later
May 18 05:56:09 <mrmoku> JaMa: morphis has a patch for it
May 18 05:56:14 <mrmoku> (which I use locally)
May 18 05:56:29 <mrmoku> putting it in an extra package
May 18 05:56:48 <mrmoku> (2.6.37) yeah, push it
May 18 06:01:31 <JaMa> ah http://git.freesmartphone.org/?p=openembedded.git;a=commit;h=0d76535e589c7d36ad6d3d3491cfd6612010293d
May 18 06:03:16 <JaMa> it's missing only in shr-core, sorry for noise
May 18 06:03:18 <mrmoku> JaMa: and yes, probably it's time to get that patch in as we actively started to develop that thing and it does not do any harm anyway
May 18 06:03:22 <mrmoku> ahh ok
May 18 06:03:24 <mrmoku> :)
May 18 07:05:26 <CIA-30> freesmartphone.org: 03morphis 07cornucopia * rb8ab7a5795da 10/fsoaudiod/src/plugins/manager/ (Makefile.am controlinfo.vala deviceinfo.vala plugin.vala): fsoaudiod: manager: move two classes into their own code files
May 18 07:25:21 <CIA-30> SHR: 03Martin.Jansa 07shr-chroot * r7d4acc8383ee 10/ (644 files in 58 dirs): system upgrade
May 18 07:33:13 <CIA-30> freesmartphone.org: 03morphis 07specs * rfeedad3d03bb 10/ (3 files in 3 dirs): Add invalid stream type for org.freesmartphone.Audio.Stream enumeration
May 18 07:35:22 <CIA-30> freesmartphone.org: 03morphis 07gdbus * ra20d2a997643 10libfso-glib/configure.ac: Bump version to match newer fso-specs
May 18 07:40:08 <CIA-30> freesmartphone.org: 03morphis 07cornucopia * r8612317d94ee 10/fsoaudiod/src/ (lib/sessionhandler.vala plugins/manager/plugin.vala): fsoaudiod: manager: notify audio session policy when a stream connects/disconnects
May 18 07:45:42 <CIA-30> freesmartphone.org: 03morphis 07cornucopia * rc0a32dcc7acf 10/fsoaudiod/ (4 files in 3 dirs): fsoaudiod: introduce new sessionpolicy_default plugin
May 18 07:45:45 <morphis> heyho
May 18 07:45:46 <morphis> mrmoku: ping
May 18 07:46:00 <JaMa> hey morphis 
May 18 08:08:51 <morphis> JaMa: can you do me favour and try to open a new bug in fso trac?
May 18 08:12:16 <JaMa> ok trying
May 18 08:12:47 <JaMa> "test" is ok?
May 18 08:13:53 <JaMa> http://trac.freesmartphone.org/ticket/622
May 18 08:14:29 <JaMa> and resolved as invalid
May 18 08:14:48 <morphis> yes
May 18 08:14:49 <morphis> great
May 18 08:14:56 <morphis> then let's see how the spam filter works
May 18 08:15:35 <JaMa> I haven't seen any captcha or something
May 18 08:19:08 <CIA-30> SHR: 03Martin.Jansa 07shr-chroot * rf864d7ddd927 10/usr/ (3 files in 2 dirs): bitbake: remove sigdata.patch because it breaks build without sstate
May 18 08:19:27 <morphis> JaMa: captcha is now enabled
May 18 08:19:37 <morphis> I tested only the monitoring of the spam filter plguin
May 18 08:19:48 <morphis> so I marked your actions as ham
May 18 08:33:24 <morphis> mickeyl: ping
May 18 09:01:52 <morphis> yeah successfully build linux-palmpre kernel with oe-core/meta-oe
May 18 09:09:48 <JaMa> and meta-pre, right?
May 18 09:09:51 <morphis> JaMa: if you are interested meta-palmpre is found here: https://github.com/morphis/meta-palmpre
May 18 09:09:52 <morphis> yes
May 18 09:10:44 <morphis> JaMa: whats when some source package does not have a license file in it?
May 18 09:10:55 <morphis> what should I do then with LIC_FILES_CHKSUM?
May 18 09:14:01 <JaMa> morphis: if it's ready I can include it in shr-makefile for shr-core
May 18 09:14:12 <JaMa> morphis: and what is issue with LIC_FILES_CHKSUM?
May 18 09:14:25 <morphis> JaMa: I have a palmpre-audio-scripts recipe
May 18 09:14:37 <morphis> it contains audio configuration scripts for the palmpre
May 18 09:14:41 <morphis> they are copied from webOS
May 18 09:15:07 <morphis> as they only contain register:value pairs to configure audio it's not a problem to copy them
May 18 09:15:15 <morphis> but then they are authored by Palm
May 18 09:15:16 <JaMa> you can add ie LICENSE file in metadata repo
May 18 09:15:22 <JaMa> and add it by SRC_URI
May 18 09:15:23 <morphis> ah ok
May 18 09:15:26 <JaMa> or add it as patch
May 18 09:15:44 <JaMa> because if it's in SRC_URI then it ends in ${WORKDIR} not ${S}
May 18 09:15:56 <JaMa> I have used it few times in meta-shr
May 18 09:16:41 <morphis> ok
May 18 09:16:52 <morphis> (shr-makefile) that would be great
May 18 09:16:58 <morphis> but it will need sometime
May 18 09:17:14 <JaMa> ok let me know when it's ready (if I'm still here)
May 18 09:18:24 <morphis> ah right, you are going on holiday
May 18 09:19:07 <morphis> JaMa: I have another question
May 18 09:19:17 <morphis> JaMa: I need uboot in the meta-palmpre tree
May 18 09:19:28 <morphis> but I don't like the idea to double the whole recipe from oe-core
May 18 09:19:43 <morphis> as I need to set COMPATIBLE_MACHINE = "palmpre"
May 18 09:20:04 <morphis> in oe-core it is already set with COMPATIBLE_MACHINE = "(a|b)"
May 18 09:20:24 <morphis> I would like to create a bbappend file which adjust the COMPATIBLE_MACHINE for the palmpre
May 18 09:20:46 <morphis> but how should I do it? when I overwrite it then it's not be able to build machine a and b anymore
May 18 09:21:22 <morphis> or does something like COMPATIBLE_MACHINE = "(palmpre|$(COMPATIBLE_MACHINE))" work?
May 18 09:24:54 <JaMa> not sure if this works
May 18 09:25:14 <JaMa> stupid idea which probably works is to add COMPATIBLE_MACHINE_palmpre
May 18 09:25:27 <JaMa> and overwrite default only if you're building palmpre
May 18 09:26:04 <JaMa> but you can check with -e if your version works, then it's probably cleanr
May 18 09:26:52 <morphis> ok
May 18 09:26:55 <morphis> will try this
May 18 09:30:52 <morphis> JaMa: what's with PR bump in a bbappend?
May 18 09:32:47 <GNUtoo|htcdream> mrmoku: hi
May 18 09:33:18 <GNUtoo|htcdream> connmand prevents udhcpc from working on dream
May 18 09:33:29 <GNUtoo|htcdream> what should I do?
May 18 09:34:13 <GNUtoo|htcdream> also changing the DPI on dream result in great improvements
May 18 10:16:44 <morphis> JaMa: found the solution for the PR problem, PRINC = "1"
May 18 10:28:22 <morphis> JaMa: is that a new style in oe-core that bitbake -c clean x && bitbake x will not rebuild x and instead create it from sysroots?
May 18 10:31:40 <JaMa> morphis: yes it restores it from sstate
May 18 10:31:50 <JaMa> morphis: you can you -c cleanall to clean sstate
May 18 10:31:59 <morphis> ok, thats what I searched for
May 18 10:32:20 <morphis> confusing ...
May 18 10:32:31 <morphis> but a nice feature ...
May 18 10:32:36 <morphis> if you now
May 18 10:32:38 <morphis> it
May 18 10:32:40 <JaMa> morphis: and I'm not sure how to use PRINC if you have multiple bbappends
May 18 10:33:07 <JaMa> morphis: like not we have u-boot.bbappend also in meta-shr (which should be in meta-nokia later)
May 18 10:33:08 <morphis> JaMa: as far as I understand it a PRINC = "1" will set PR + 1
May 18 10:33:35 <morphis> so if you have multiple PRINC = "1" you will end with PR + 1 +1 +1
May 18 10:33:40 <JaMa> morphis: so if ew both set PRINC = "1" then adding meta-palmpre won't bump u-boot PR
May 18 10:33:54 <JaMa> morphis: ah it does?
May 18 10:34:13 <morphis> I never tried but thats how I understand the way it works
May 18 10:34:34 <morphis> mickey|office: good morning!
May 18 10:34:52 <JaMa> then ok.. I expected that it will be evaluated only once after parsing all .bb + .bbappneds
May 18 10:35:20 <morphis> otherwise I would say the name for it is wrong
May 18 10:35:25 <JaMa> or again we can limit it with machine override
May 18 10:35:32 <JaMa> like PRINC_palmpre
May 18 10:35:49 <JaMa> because otherwise I cannot decide to drop ie meta-palmpre layer layter
May 18 10:36:06 <JaMa> as it would cause PR going backwards for other machines
May 18 10:36:51 <morphis> jepp
May 18 10:36:56 <morphis> good idea
May 18 10:36:59 <JaMa> morphis: in other words I tend to add _machine override to everything in machine-bsp layer
May 18 10:37:08 <morphis> JaMa: I have now my u-boot_git.bbappend but it does not work
May 18 10:37:08 <morphis> http://pastie.org/1921035
May 18 10:37:25 <morphis> I get "ERROR: Nothing PROVIDES 'u-boot'" everytime I try to build u-boot
May 18 10:37:47 <morphis> JaMa: would be the right choice I thing
May 18 10:37:53 <JaMa> call bitbake-layers
May 18 10:38:34 <JaMa> and I'm trying to put .bbappend to same directory as upstream .bb is (and you have uboot instead of u-boot) 
May 18 10:39:00 <morphis> yes, thats what I am doing too
May 18 10:39:11 <morphis> and a COMPATIBLE_MACHINE_palmpre does not work
May 18 10:39:23 <morphis> base.bbclass is only evaluating COMPABTILE_MACHINE
May 18 10:39:29 <JaMa> ah :/
May 18 10:40:01 <JaMa> hmm meta-shr/recipes-bsp/u-boot/u-boot_git.bb also has COMPABTILE_MACHINE without override
May 18 10:40:16 <morphis> WARNING: No recipes available for:
May 18 10:40:16 <morphis>   /home/morphis/oe/buildroot-core/meta-palmpre/recipes-bsp/uboot/u-boot_git.bbappend
May 18 10:40:18 <morphis> hm
May 18 10:40:43 <morphis> but there is a openembedded-core/meta/recipes-bsp/uboot/u-boot_git.bb
May 18 10:41:43 <GNUtoo> JaMa, why do we have connman?
May 18 10:41:46 <GNUtoo> hi btw
May 18 10:41:49 <morphis> GNUtoo: heyho
May 18 10:41:52 <morphis> GNUtoo: in SHR?
May 18 10:42:03 <GNUtoo> yes
May 18 10:42:14 <morphis> as we have a fsogsmd plugin for it now
May 18 10:42:21 <GNUtoo> btw there was a signal in oe ml telling to migrate to oe-core
May 18 10:42:30 <GNUtoo> it breaks udhcpc -i wlan0
May 18 10:42:33 <GNUtoo> is it normal?
May 18 10:42:38 <morphis> hm, don't know
May 18 10:42:44 <GNUtoo> on htcdream
May 18 10:42:47 <morphis> GNUtoo: yes I saw the mail
May 18 10:42:50 <GNUtoo> I'll push a DPI change
May 18 10:42:56 <morphis> thats why I started a meta-palmpre
May 18 10:42:58 <GNUtoo> morphis, does SHR compile fine now?
May 18 10:43:38 <GNUtoo> with oe-core
May 18 10:43:43 <JaMa> morphis: try u-boot instead of uboot
May 18 10:43:47 <GNUtoo> because JaMa had dbus-codegen issues
May 18 10:44:01 <JaMa> GNUtoo: http://build.shr-project.org/shr-core/images/om-gta02/
May 18 10:44:28 <JaMa> GNUtoo: yes it compiles fine
May 18 10:44:40 <GNUtoo> what about runtime issues?
May 18 10:44:52 <JaMa> like what?
May 18 10:45:02 <GNUtoo> like telephony not working
May 18 10:45:21 <morphis> GNUtoo: I don't try to compile SHR with oe-core
May 18 10:45:23 <GNUtoo> is there any core functionality broken?
May 18 10:45:33 <morphis> GNUtoo: I am just working on a simple machine layer
May 18 10:45:39 <morphis> with poky as distro for now
May 18 10:45:46 <morphis> so only oe-core + meta-oe + meta-palmpre
May 18 10:45:48 <GNUtoo> morphis, ok , so you just want aurora
May 18 10:45:58 <morphis> yes
May 18 10:46:06 <GNUtoo> ok
May 18 10:46:23 <GNUtoo> if I get the palm pre, I would want SHR at first
May 18 10:46:37 <GNUtoo> so I guess I'll have to work on it?
May 18 10:46:42 <morphis> JaMa: you mean as folder name?
May 18 10:46:50 <morphis> GNUtoo: should be not so much work
May 18 10:46:58 <morphis> as the SHR bits are already in meta-shr
May 18 10:47:06 <GNUtoo> ok nice
May 18 10:47:14 <morphis> you just have to setup meta-shr + meta-palmpre + meta-oe + oe-core then
May 18 10:47:18 <GNUtoo> I want to integrate htcdream to shr-core
May 18 10:47:22 <GNUtoo> how do I do that
May 18 10:47:28 <morphis> do a meta-htc
May 18 10:47:39 <morphis> which only contains the machine relevant bits
May 18 10:47:40 <GNUtoo> can't we do a meta-phone?
May 18 10:47:53 <JaMa> morphis: yes folder name
May 18 10:47:57 <morphis> https://github.com/morphis/meta-palmpre
May 18 10:48:33 <morphis> JaMa: no, still "WARNING: No recipes available for:"
May 18 10:48:51 <morphis> GNUtoo: we can arrange all phone meta layers within one repository, yes
May 18 10:49:06 <morphis> but we should separate them as much as possible
May 18 10:49:21 <GNUtoo> ah ok
May 18 10:49:28 <morphis> so you have a meta-<machine-name> which only contains machine relevant bits
May 18 10:49:37 <GNUtoo> ok
May 18 10:49:41 <GNUtoo> so we could do that
May 18 10:49:42 <morphis> for example look at linux.inc in OE-classic
May 18 10:49:57 <GNUtoo> having a meta-phone with inside a meta-palmpre
May 18 10:50:01 <morphis> it's quite complex for a lot of machines
May 18 10:50:02 <GNUtoo> and a meta-htcdream
May 18 10:50:04 <morphis> yes
May 18 10:50:05 <JaMa> morphis: after testing allarch etc.. I can reorganize meta-shr repo to contain multiple meta-* like meta-oe does now
May 18 10:50:13 <GNUtoo> and a meta-nokia900
May 18 10:50:20 <GNUtoo> and a meta-om-gta02
May 18 10:51:21 <GNUtoo> JaMa, where are the meta for :
May 18 10:51:23 <GNUtoo> * om-gta02
May 18 10:51:28 <GNUtoo> * nokia900
May 18 10:53:00 <GNUtoo> ok
May 18 10:53:01 <GNUtoo> nice
May 18 10:53:23 <JaMa> in meta-shr now
May 18 10:53:27 <GNUtoo> ok
May 18 10:57:43 <DocScrutinizer> mrmoku: (unaccaptable for mainline) what's with OM's (or Nokia's) lis302dl.ko driver?
May 18 10:58:36 <JaMa> morphis, GNUtoo: http://paste.pocoo.org/show/391114/
May 18 10:58:38 <DocScrutinizer> and aiui the got no better concept for proximity sensor, or anything
May 18 10:59:03 <DocScrutinizer> oops maybe that's just sensorfw or even qtmob
May 18 10:59:32 <morphis> JaMa: meta-smartphone sounds good
May 18 11:00:24 <morphis> then I can do meta-smartphone/meta-aurora too
May 18 11:00:49 <DocScrutinizer> mrmoku: I'd hope for maemo-meego bastard harmattan meego HE kernel, which probably is rather sane
May 18 11:00:55 <JaMa> for now in meta-shr.git or do we have to rename it first in git repo?
May 18 11:00:56 <GNUtoo> ok
May 18 11:01:53 <GNUtoo> JaMa, where to put the DPI for meta-shr?
May 18 11:02:04 <JaMa> DPI?
May 18 11:02:13 <GNUtoo> display density
May 18 11:02:19 <morphis> JaMa: let's rename it
May 18 11:02:42 <JaMa> GNUtoo: for meta-shr? sorry I don't understand
May 18 11:03:01 <JaMa> morphis: how to rename it with gitosis?
May 18 11:03:02 <GNUtoo> JaMa, I've an xorg with bad DPI, I know how to fix it in normal oe
May 18 11:03:21 <GNUtoo> but with shr-core I've no idea on where to put the fix 
May 18 11:03:23 <GNUtoo> I'll look
May 18 11:03:27 <JaMa> GNUtoo: so you mean ie for htcdream in meta-shr?
May 18 11:03:49 <GNUtoo> yes
May 18 11:03:56 <GNUtoo> basically here's the patch:
May 18 11:03:58 <JaMa> then you do it in meta-htc with .bbappend
May 18 11:04:05 <GNUtoo> ah ok
May 18 11:04:09 <GNUtoo> I've to learn all that
May 18 11:04:20 <GNUtoo> what's .bbappend ?
May 18 11:05:11 <JaMa> GNUtoo: check this http://git.shr-project.org/git/?p=meta-shr.git;a=commit;h=493addd40618b12b6d0c65c3a70795e9344c9cb7
May 18 11:05:32 <GNUtoo> ahhh ok
May 18 11:05:44 <mickey|office> morning folks
May 18 11:07:57 <GNUtoo> hi
May 18 11:08:32 <GNUtoo> JaMa, btw are you sure for meta-htc's name
May 18 11:08:46 <GNUtoo> because we may support more than just the dream in the future
May 18 11:08:52 <GNUtoo> but maybe we can rename then
May 18 11:09:05 <GNUtoo> for instance palm pre 3
May 18 11:09:11 <GNUtoo> or hd2
May 18 11:09:14 <GNUtoo> or nexusone
May 18 11:09:17 <GNUtoo> or htc desire
May 18 11:09:28 <GNUtoo> maybe meta-msmqsd ?
May 18 11:09:34 <JaMa> that's why it's called meta-htc not meta-htcdream
May 18 11:09:50 <GNUtoo> ok
May 18 11:09:58 <JaMa> but I don't care how it's named
May 18 11:10:18 <GNUtoo> maybe meta-msm would be better
May 18 11:18:02 <DocScrutinizer> I don't give a Flying F* about DSK, but anyway hooray for USA where they put a sentence on 10 year old boys for kissing a classmate
May 18 11:21:16 <mrmoku> morphis: pong
May 18 11:21:42 <mrmoku> DocScrutinizer: (lis) no idea
May 18 11:22:03 <mrmoku> and yeah, let's hope for a sane kernel
May 18 11:22:11 <mrmoku> hi GNUtoo 
May 18 11:22:27 <DocScrutinizer> I hope you're not using this fsckdup lis3lv02.ko joystick driver 
May 18 11:23:04 <DocScrutinizer> like meego does
May 18 11:23:19 <mrmoku> accels are prolly not in the top ten of our agenda yet
May 18 11:23:26 <mrmoku> so no idea
May 18 11:23:31 <DocScrutinizer> while your own lis302dl.ko is magnitudes better
May 18 11:24:04 <DocScrutinizer> just asking about your general policy
May 18 11:24:30 <DocScrutinizer> meego kernel is kinda fsckdup in so many ways
May 18 11:26:12 <GNUtoo> mrmoku, hi, be back soon
May 18 11:26:26 <DocScrutinizer> I mean there's been a rationale behnd all those patches to 2.6.28 maemo kernel, and lots of those seems never made it upstream
May 18 11:26:45 <mrmoku> sure
May 18 11:27:24 <morphis> mrmoku: I did some first work for getting further with fsoaudiod
May 18 11:27:38 <mrmoku> yeah, great
May 18 11:27:41 <DocScrutinizer> so meego-arm is kinda dadlocked in their policy, and has abysmal power management
May 18 11:28:09 <morphis> mrmoku: we need now two components: streamcontrol_alsa and sessionpolicy_default
May 18 11:28:12 <DocScrutinizer> I'm questioning *your* policy regarding at very least N900 in particular
May 18 11:28:23 <lindi-> just curious, what's the newest kernel that people use on n900? (udev dropped support for anything older than 2.6.32 recently..)
May 18 11:29:02 <DocScrutinizer> define "people", define "use"
May 18 11:29:13 <morphis> mrmoku: you can do the streamcontrol_alsa thing while I am doing sessionpolicy_default
May 18 11:29:16 <lindi-> DocScrutinizer: :)
May 18 11:29:22 <morphis> btw. the fso bug tracker is now active again
May 18 11:29:43 <morphis> mickey|office: I enabled the spam filter plugin for our trac now
May 18 11:29:52 <morphis> mickey|office: but we need to train it first
May 18 11:30:57 <DocScrutinizer> mfff, mandatory login, registration secured by captcha
May 18 11:34:08 <DocScrutinizer> lindi-: see, the problem with maemo is: the kernel API is used in so many userland closed source stuff (charging, ALS, whatnot else...) that it's basically impossible to switch to a newer kernel without breaking whole userland stuff
May 18 11:35:46 <JaMa> morphis: check meta-smartphone repo :)
May 18 11:35:49 <DocScrutinizer> even loading a bq27200.ko module to get /sys nodes for reading out battery gauge will cause bme to go insane or even segfault
May 18 11:36:23 <JaMa> GNUtoo: you too..
May 18 11:37:06 <JaMa> morphis: feel free to populate meta-palmpre dir with your stuff
May 18 11:37:40 <JaMa> and fill in README and conf/layer.conf
May 18 11:38:08 * JaMa back to work
May 18 11:38:21 <morphis> JaMa: where is the meta-smartphone repository?
May 18 11:39:19 <GNUtoo> ok
May 18 11:40:21 <GNUtoo> where's meta-smartphone?
May 18 11:40:33 <GNUtoo> ah it was already asked
May 18 11:40:57 <morphis> :)
May 18 11:41:39 <JaMa> git+ssh://git@git.shr-project.org/meta-smartphone.git
May 18 11:41:42 <mrmoku> morphis: ok, will try to do something
May 18 11:42:14 <mrmoku> DocScrutinizer: problem is my load is already high theses days...
May 18 11:42:14 <GNUtoo> JaMa, it didn't appear in http://git.shr-project.org/git/
May 18 11:42:25 <mrmoku> but clearly we want the technical superior stuff
May 18 11:42:43 <GNUtoo> mrmoku, for the kernel? yes we'll see later
May 18 11:42:44 <mrmoku> it just needs someone to port the om driver to our n900 one
May 18 11:43:05 <JaMa> mrmoku: I don't remember *again* what's needed to publish repo in gitweb.. :/
May 18 11:43:19 <mrmoku> DocScrutinizer: so if you're only asking where we want to go in the end... yeah we don't want the joystick crap :P
May 18 11:43:25 <mrmoku> IMHO
May 18 11:43:45 <mrmoku> JaMa: let me see if I remember out of the box :P
May 18 11:43:51 <mrmoku> first add it to the gitosis.conf
May 18 11:43:55 <JaMa> done
May 18 11:43:57 <GNUtoo> hi tuxbrain 
May 18 11:44:04 <mrmoku> then you can do an explicit push to it
May 18 11:44:10 <JaMa> done :)
May 18 11:44:17 <morphis> there is a list of repos somewhere
May 18 11:44:17 <mrmoku> then you have to copy the hooks
May 18 11:44:26 <JaMa> mrmoku: on server?
May 18 11:44:27 <mrmoku> yup
May 18 11:44:28 <morphis> projects.list
May 18 11:44:29 <mrmoku> as git
May 18 11:44:44 <tuxbrain> hi I was trying to build shr-core but it fails 
May 18 11:44:47 <mrmoku> and yeah, there is projectlist too
May 18 11:44:56 <mrmoku> in home of git
May 18 11:45:44 <mrmoku> JaMa: the dameon-ok file should be there already... as I changed the config sometime back to default to it
May 18 11:46:15 <GNUtoo> tuxbrain, how does it fail, what device?
May 18 11:46:56 <JaMa> mrmoku: copies hooks/update and chmoded +x
May 18 11:47:06 <JaMa> copied
May 18 11:47:24 <JaMa> based on history of git user :)
May 18 11:47:37 <JaMa> so now I have to push to it again right?
May 18 11:47:44 <mrmoku> JaMa: don't forget to change the text in the hook :P
May 18 11:47:53 <mrmoku> it hast the project name hardcoded
May 18 11:47:55 <mrmoku> -t
May 18 11:48:22 <JaMa> mrmoku: where? I don't see it
May 18 11:48:36 <tuxbrain> you can see the fail here http://pastebin.com/0B9C4Z3Y
May 18 11:48:43 <JaMa> "$GIT_DIR/description" ah
May 18 11:48:51 <mrmoku> yeah, that one too :)
May 18 11:49:03 <mrmoku> in the update or post-update hook also
May 18 11:49:05 <DocScrutinizer> mrmoku: so you at very least have to make utterly clear what's going to be tackled which way. For example the lis3lv02 joystick driver has a completely different API than the rather sane maemo one and also than the really good OM one
May 18 11:49:08 <mrmoku> (the one doing the cia)
May 18 11:49:47 <tuxbrain> I was triying to build a "standard" build before start twicking for the BIP-6000 but it fails also building without any change on conf files 
May 18 11:49:49 <mrmoku> DocScrutinizer: and there starts my load problem... I don't have the time to dig into, compare and decide right now :/
May 18 11:50:06 <mrmoku> either somebody else has to do that or it has to wait :(
May 18 11:50:22 <DocScrutinizer> so exclude this driver from "upstream" kernel from very beginning, and have a readme: "we need to import OM driver here, please do NOT import the mainstream one, and esp do not base your app on the mainstream borked API!"
May 18 11:51:09 <mrmoku> btw. I think we have more the contrary problem... mokomaze is not working due to being for the correct API :)
May 18 11:51:49 <DocScrutinizer> that sounds like it's already too late for the readme suggested above
May 18 11:52:01 <mrmoku> JaMa: ahh, one thing I forgot
May 18 11:52:08 <mrmoku> JaMa: chmod 755 the repo dir
May 18 11:52:13 <mrmoku> it defaults to 750
May 18 11:52:18 <GNUtoo> tuxbrain, maybe try shr-lite-image ?
May 18 11:52:21 <mrmoku> and gitweb does not like that :P
May 18 11:53:13 <DocScrutinizer> you're running full speed closed eyes into another "we can't fix the borked API as it's already in use by apps" deadlock
May 18 11:53:32 <mrmoku> DocScrutinizer: nah, the problem is the other wy round, no? mokomaze is done for the om-lis api
May 18 11:53:38 <mrmoku> way even
May 18 11:53:43 <JaMa> http://git.shr-project.org/git/?p=meta-smartphone.git;a=summary
May 18 11:53:51 <JaMa> mrmoku: thanks
May 18 11:54:00 <DocScrutinizer> mrmoku: so you're fine for now
May 18 11:54:12 <JaMa> mrmoku: update has it hardcoded, but meta-shr had default update without refname, that's why it wasn't triggering cia :)
May 18 11:54:27 <mrmoku> JaMa: hehe,ok
May 18 11:54:46 <mrmoku> DocScrutinizer: where should we put such a README that people read it?
May 18 11:54:56 <DocScrutinizer> mrmoku: kick the lis3lv02.ko BS before somebody actually "fixes" mokomaze
May 18 11:55:04 <tuxbrain> GNUtoo: trying ...
May 18 11:55:06 <mrmoku> hehe :P
May 18 11:55:07 <mrmoku> ok
May 18 11:55:18 <DocScrutinizer> mrmoku: souretree, lis3lv02 ?
May 18 11:55:36 <mrmoku> DocScrutinizer: yeah, but nobody will read that :/
May 18 11:55:56 <DocScrutinizer> they will as soon as they consider to import the lis3lv02 BS
May 18 11:56:04 <CIA-30> SHR: 03Martin.Jansa 07meta-smartphone * r2d1c837ade94 10/meta-shr/classes/ (blacklist.bbclass recipe_sanity.bbclass testlab.bbclass): meta-shr: drop some classes
May 18 11:56:09 <mrmoku> not having the wrong module in the first place is maybe the best measurement
May 18 11:56:17 <mrmoku> GNUtoo: what's your thought on that one?
May 18 11:56:30 <DocScrutinizer> mrmoku: that's what I suggested :-D
May 18 11:56:53 <JaMa> mrmoku: repo dir had 755 already, and it's available on gitweb, only missing on main page with repo list
May 18 11:57:03 <DocScrutinizer> dunno if there's also a bord defne file somewhere
May 18 11:57:28 <DocScrutinizer> where you can comment out lis3lv02 and place a fat bold WARNING comment next to it
May 18 11:58:26 <tuxbrain> GNUtoo: well at least it starts building.. I will reconnect if another error ocurs meanwhile, I would like to why there is missing packages that makes unable to build the full one... 
May 18 11:59:14 <JaMa> mrmoku: ok fixed :)
May 18 11:59:31 <tuxbrain> uff the above sentence sound to surly, sorry I'm under some stress I not prettend to sound so trolling
May 18 12:00:51 <DocScrutinizer> tuxbrain: proper pidgin ;-)
May 18 12:01:40 <tuxbrain> DocScrutinizer: any way of fix it to make the build?
May 18 12:02:08 <DocScrutinizer> sorry, me do not know build
May 18 12:02:39 <tuxbrain> JaMa, mrmoku any one?
May 18 12:05:54 <DocScrutinizer> mrmoku: comment out lis3lv02 in that kernel builddef file (the one where you select module, yes, no for each subsyystem and property of kernel)
May 18 12:07:02 <DocScrutinizer> mrmoku: then replace content of lis3lv02.c in sourcetree by "#ERROR you must not use this module, read lis3lv02/README!
May 18 12:08:00 <DocScrutinizer> (fix syntax and naming errors where due)
May 18 12:08:12 <mrmoku> tuxbrain: sorry for shr-core building problems I'm not the correct one to ask
May 18 12:08:39 <GNUtoo> tuxbrain, there is a way
May 18 12:08:50 <GNUtoo> add the missing packages in oe-core
May 18 12:09:07 <GNUtoo> basically the error you saw was because some packages were missing
May 18 12:09:13 <DocScrutinizer> e.g that file doesn't read "builddef"
May 18 12:09:16 <tuxbrain> How to procced GNUtoo?
May 18 12:09:17 <GNUtoo> so to do that create a meta-games
May 18 12:09:24 <DocScrutinizer> more like defconfig
May 18 12:09:52 <tuxbrain> GNUtoo: any howto on how to do this?
May 18 12:09:55 <GNUtoo> tuxbrain, alternatively, wait until shr-image could be built
May 18 12:10:03 <GNUtoo> I don't even know how to do that
May 18 12:10:08 <GNUtoo> I know well oe
May 18 12:10:09 <tuxbrain> I can't wait :(
May 18 12:10:10 <GNUtoo> but not oe-core
May 18 12:10:12 <GNUtoo> why?
May 18 12:10:59 <GNUtoo> http://build.shr-project.org/shr-core/images/om-gta02/ has only lite-image
May 18 12:11:44 <morphis> tuxbrain: you have to wait, thats not something within an hour or so
May 18 12:11:51 <morphis> JaMa is already working on this for weeks
May 18 12:12:00 <GNUtoo> Missing or unbuildable dependency chain was: ['numptyphysics', 'virtual/libsdl']
May 18 12:12:02 <morphis> if you need a shr-image use classic oe
May 18 12:12:11 <GNUtoo> see here you have to add virtual/libsdl
May 18 12:12:25 <GNUtoo> and there are tons of stuff like that
May 18 12:13:18 <tuxbrain> I have contacted with one guy to do  a image with the las qt- pyqt libs to make able to run a costumer app on the BIP-6000 but for various circumstances the guy has do not nothing in two months, so I was searching a quick way to build an OE based distro with lastest packages aviableand SHR 
May 18 12:13:36 <CIA-30> SHR: 03morphis 07meta-smartphone * r969c0b706e72 10/ (9 files in 6 dirs): meta-palm: port over from old meta-palmpre and add layer configuration
May 18 12:13:47 <CIA-30> SHR: 03morphis 07meta-smartphone * r5568238aea32 10/meta-palm/ (6 files in 5 dirs): meta-palm: import recipes from old meta-palmpre repository
May 18 12:14:08 <GNUtoo> tuxbrain, ok, then use plain old oe
May 18 12:14:09 <morphis> tuxbrain: then use classic oe
May 18 12:14:22 <morphis> oe-core is not ready for things like that
May 18 12:14:23 <GNUtoo> the new one is incomplete
May 18 12:14:30 <mrmoku> hehe :)
May 18 12:14:45 <morphis> and classic oe is not dead
May 18 12:14:45 <tuxbrain> shr seems a good alternative but as you said I must roll back to old oe
May 18 12:14:56 <morphis> shr is even part of classic oe
May 18 12:14:57 <GNUtoo> tuxbrain, shr is in old oe
May 18 12:15:04 <tuxbrain> sorry shr-core
May 18 12:15:12 <morphis> there is currently not need to use shr-core
May 18 12:15:20 <morphis> s/not/no/
May 18 12:15:20 <apt> morphis meant: there is currently no need to use shr-core
May 18 12:15:38 <tuxbrain> I must leave se you later guys
May 18 12:15:50 <GNUtoo> tuxbrain, feel free to ping me btw
May 18 12:46:22 <morphis> JaMa: how do I tell bitbake to reparse all recipes?
May 18 12:53:54 <DocScrutinizer> drop it here as well ->ir detector hardware for gesture recognition: http://www.youtube.com/viralsilabs#p/u/0/QvrB8cufv80
May 18 12:54:46 <GNUtoo> DocScrutinizer, do you have any clue on how to add buffer size restrictions without .mmap in .asoundrc
May 18 12:54:55 <GNUtoo> no mmap means no dsnoop/dshare/dmix
May 18 12:55:08 <GNUtoo> maybe I should add mmap then
May 18 12:55:42 <DocScrutinizer> umm, the plugins will negotiate for themselves
May 18 12:56:02 <DocScrutinizer> i.e. you usually don't want to "touch" dmix directly
May 18 12:56:58 <DocScrutinizer> buffer size restrictions and similar stuff are done by a special call to some alsa function, prior to opening the device (though some can get changed after opening it)
May 18 12:58:07 <DocScrutinizer> that's the big shortcoming of alsa docs - they don't mention what the particular function's semantics are and when to use it and why
May 18 12:58:43 <GNUtoo> ok
May 18 12:58:49 <GNUtoo> I'll try to import mmap then
May 18 12:59:39 <DocScrutinizer> I'd think all the examples I mentioned (twinkle as well as on the alsa homesite) will give some pretty good hint on how to implement a proper alsa access
May 18 13:01:45 <GNUtoo> I was talking about something else
May 18 13:01:47 <GNUtoo> .asoundrc
May 18 13:02:02 <GNUtoo> and yes twinkle is great as example
May 18 13:02:12 <GNUtoo> and yes I should remove the dmix call
May 18 13:04:00 <DocScrutinizer> GNUtoo: please elaborate on your particular problem, so I can figure how to help
May 18 13:06:15 <GNUtoo> it's the htcdream
May 18 13:06:22 <GNUtoo> it needs fixed size for the buffer size
May 18 13:06:27 <GNUtoo> because of the hardware
May 18 13:06:55 <DocScrutinizer> man aplay, /--buffer-size=#
May 18 13:07:01 <GNUtoo> that works
May 18 13:07:08 <GNUtoo> but what if it's mplayer
May 18 13:07:10 <GNUtoo> or sdl
May 18 13:07:17 <GNUtoo> or gstreamer
May 18 13:07:30 <DocScrutinizer> aah, you're asking how to define a buffersize in asoundrc?
May 18 13:07:46 <GNUtoo> yes
May 18 13:07:52 <DocScrutinizer> wait a minute
May 18 13:08:00 <GNUtoo> without .mmap capabilities
May 18 13:08:07 <DocScrutinizer> yo
May 18 13:10:28 <DocScrutinizer> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html :: pcm_slave.NAME { ... ... buffer_time INT # Buffer time in us or "unchanged" string }
May 18 13:10:52 <GNUtoo> does it requires something special?
May 18 13:10:56 <GNUtoo> because I already tried
May 18 13:10:59 <GNUtoo> buffer_time
May 18 13:10:59 <DocScrutinizer> not afaik
May 18 13:11:02 <GNUtoo> period_time
May 18 13:11:06 <GNUtoo> buffer_size
May 18 13:11:09 <GNUtoo> and I failed
May 18 13:11:24 <GNUtoo> let me retry and paste
May 18 13:13:16 <GNUtoo> [AO_ALSA] alsa-lib: pcm.c:6891:(snd_pcm_slave_conf) Unknown field buffer_time
May 18 13:13:47 <GNUtoo> http://pastie.org/1921583
May 18 13:16:02 <DocScrutinizer> .oO(???) wtf
May 18 13:16:27 <DocScrutinizer> check pcm.c:6891
May 18 13:17:07 <GNUtoo> ok
May 18 13:17:51 <DocScrutinizer> also make sure you got no UTF8 issues with "_" char
May 18 13:18:06 <DocScrutinizer> (just wild handwaving)
May 18 13:18:43 <GNUtoo>                 SNDERR("Unknown field %s", id);
May 18 13:18:45 <GNUtoo> hmmm
May 18 13:18:57 <DocScrutinizer> sure, check the lines before :-)
May 18 13:19:06 <GNUtoo> that's what I'm doing
May 18 13:19:23 <DocScrutinizer> evidently you spotted the right line in right file
May 18 13:22:57 <DocScrutinizer> though I'm somewhat puzzled by line#6891
May 18 13:24:43 <CIA-30> SHR: 03morphis 07meta-smartphone * r852a1d1862fd 10/meta-palm/conf/machine/include/palmpre.inc: meta-palmpre: remove old MACHINE_KERNEL_PR from palmpre machine config
May 18 13:24:53 <CIA-30> SHR: 03morphis 07meta-smartphone * rfbdc20a6bd68 10/meta-palm/recipes-bsp/u-boot/u-boot_git.bbappend: meta-palm: add bbappend file for u-boot so it supports the palmpre machine
May 18 13:24:53 <CIA-30> SHR: 03morphis 07meta-smartphone * rbf18ce5a7786 10/meta-palm/recipes-bsp/x-load/x-load_git.bbappend: meta-palm: add bbappend file for x-load so it supports the palmpre machine
May 18 13:25:55 <DocScrutinizer> GNUtoo: the longest pcm.c files I can locate on my desktop are like 1100 lines
May 18 13:26:43 <GNUtoo|laptop> http://www.pastie.org/1921631
May 18 13:26:55 <DocScrutinizer> GNUtoo: could you toss a pointer (URL) to that code?
May 18 13:27:02 <GNUtoo|laptop> I just did
May 18 13:35:10 <DocScrutinizer> that's causing headache to me
May 18 13:36:35 <DocScrutinizer> esp lines 33 thru 42 of your paste
May 18 13:36:53 <GNUtoo> me too, I've a hard time to understand what it does
May 18 13:37:16 <GNUtoo> I know what va_args is
May 18 13:37:19 <GNUtoo> but still....
May 18 13:39:13 <DocScrutinizer> I don't even know va_args
May 18 13:39:31 <DocScrutinizer> but I'm musing about line 21
May 18 13:39:46 <GNUtoo> ok
May 18 13:39:48 <DocScrutinizer> maybe you should try a non-compound
May 18 13:39:58 <GNUtoo> you have present printf in C
May 18 13:40:03 <GNUtoo> well it uses va_args
May 18 13:40:14 <GNUtoo> it's for having a variable number of arguments
May 18 13:40:26 <DocScrutinizer> :nod:
May 18 13:41:28 <GNUtoo> maybe it's just mplayer that doesn't obey alsa?
May 18 13:41:40 <DocScrutinizer> anyway line 21 is searching for string "pcm_slave" and maybe it needs that for a proper working slave def
May 18 13:41:51 <GNUtoo> ok
May 18 13:42:07 <DocScrutinizer> don't use compound slave def
May 18 13:42:15 <GNUtoo> ?
May 18 13:42:21 <GNUtoo> compound?
May 18 13:42:51 <DocScrutinizer> try very first "example:" in http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
May 18 13:43:38 <DocScrutinizer> though just the second example suggests your asoundrc is correct
May 18 13:43:47 <GNUtoo> ok
May 18 13:44:13 <GNUtoo> it just doesn't want to take the buffer_time
May 18 13:45:21 <DocScrutinizer> btw buffer_time is in microseconds, is 50 really sane for that?
May 18 13:48:29 <DocScrutinizer> it's like 2 frames size for samplerates ~40k
May 18 13:49:10 <GNUtoo> it was a test
May 18 13:49:15 <GNUtoo> I didn't do the math yet
May 18 13:49:58 <GNUtoo|laptop> I'll try mmap
May 18 13:50:11 <DocScrutinizer> try 500000
May 18 13:50:58 <DocScrutinizer> it'd not be the first time the error msg isn't to the point
May 18 13:51:28 <DocScrutinizer> a buffer size of 2.3 frames is insane
May 18 13:51:40 <GNUtoo|laptop> in mmap I have:
May 18 13:51:42 <GNUtoo|laptop> alsa-init: got buffersize=9600
May 18 13:51:42 <GNUtoo|laptop> alsa-init: got period size 1200
May 18 13:51:52 <GNUtoo|laptop> that is inconsistent with .asoundrc:
May 18 13:52:25 <GNUtoo|laptop> http://www.pastie.org/1921727
May 18 13:52:30 <GNUtoo|laptop> I'll try to plug that
May 18 13:52:35 <DocScrutinizer> well, 8 periods of 1200 frames, that sounds good
May 18 13:53:21 <GNUtoo|laptop> but I want 2 periods
May 18 13:53:38 <GNUtoo|laptop> and the sound is hashed
May 18 13:53:42 <DocScrutinizer> yep, alsa can refuse to offer the exact period size /buffer size / sample rate you asked for, and pick the next supported value instead
May 18 13:53:58 <GNUtoo|laptop> so I should modify the kernel?
May 18 13:54:06 <DocScrutinizer> why?
May 18 13:54:16 <GNUtoo|laptop> aplay has the correct values tough
May 18 13:54:20 <GNUtoo|laptop> and aplay works fine
May 18 13:54:23 <GNUtoo|laptop> mplayer is hashed
May 18 13:54:25 <GNUtoo|laptop> that is to say
May 18 13:54:37 <GNUtoo|laptop> sound|blank|sound|blank|sound
May 18 13:54:42 <GNUtoo|laptop> very rapidely
May 18 13:55:30 <DocScrutinizer> hmm, I can't see why mpalayer would behave different when using the same device and hw-params that aplay used
May 18 13:55:56 <DocScrutinizer> except for CPU load issues maybe
May 18 13:57:13 <DocScrutinizer> maybe your audio card can't support any other buffer setup than that 8 periods a 1200 frames
May 18 13:57:16 <GNUtoo|laptop> the buffer values are not the same
May 18 13:57:35 <GNUtoo|laptop> it doesn't support more than 2 period at 2400 frames
May 18 13:57:40 <GNUtoo|laptop> that is 4800 fixed buffer
May 18 13:57:46 <GNUtoo|laptop> the driver is very bad
May 18 13:57:49 <DocScrutinizer> weird
May 18 13:58:02 <GNUtoo|laptop> it's not a normal sound card
May 18 13:58:12 <GNUtoo|laptop> it's a DSP that can play mp3, pcm etc...
May 18 13:58:53 <DocScrutinizer> anyway, check your debug-dump outputs to see what the plugins *actually* use
May 18 13:59:09 <GNUtoo|laptop> ?
May 18 13:59:13 <GNUtoo|laptop> apay -v you mean?
May 18 14:00:01 <DocScrutinizer> aiui the request with buffer X, period Y, rate Z propagates down the stack to hw:, then hw: replies with what it actually can do and that's what gets used to initialize the alsa device
May 18 14:00:11 <DocScrutinizer> yes, -v
May 18 14:01:19 <DocScrutinizer> (...what gets used) or is used by lowest plug plugin to convert accordingly, to match what app requested to what hw: can do
May 18 14:02:04 <DocScrutinizer> that's the magic how plug plugin works
May 18 14:02:09 <GNUtoo|laptop> aha playing a wav result in that:
May 18 14:02:11 <GNUtoo|laptop> alsa-init: got buffersize=4800
May 18 14:02:11 <GNUtoo|laptop> alsa-init: got period size 1200
May 18 14:02:14 <GNUtoo|laptop> from mplayer
May 18 14:02:21 <GNUtoo|laptop> the same wav result in that in aplay:
May 18 14:03:02 <GNUtoo|laptop> http://www.pastie.org/1921783
May 18 14:03:15 <GNUtoo|laptop> the playing wav was done without .asoundrc
May 18 14:05:24 <GNUtoo|laptop> playing big buck bunny with mplayer result in hashed sound. even at 70% CPU usage without the video( -vo null)
May 18 14:05:47 <GNUtoo|laptop> I came with a way to make it work using sdl long time ago
May 18 14:05:50 <GNUtoo|laptop> basically:
May 18 14:06:03 <GNUtoo|laptop> mplayer->sdl->alsa->sound_card
May 18 14:07:30 <DocScrutinizer> the mplayer output is basically worthless for me to get a grip on what's going on. Look at aplay -v paste to see how it's nicely converted by plug et al to buffer:2400 period:1200
May 18 14:08:33 <DocScrutinizer> NB how mplayer claims buffer:4800
May 18 14:09:42 <DocScrutinizer> which could be any kind of issue, from unit:frames vs unit:bytes to samplesize 2bytes (*channels)
May 18 14:10:06 <GNUtoo|laptop> I'll look
May 18 14:10:08 <GNUtoo|laptop> it's in libao
May 18 14:10:26 <DocScrutinizer> to stupid conversations like buffersize_bytes = buffersize_frames * 2
May 18 14:11:02 <DocScrutinizer> which is obviously incorrect for stereo stream
May 18 14:11:08 <DocScrutinizer> S16_LE
May 18 14:12:08 <DocScrutinizer> I don't even have any idea what alsa audio device mplayer is using
May 18 14:12:54 <DocScrutinizer> your aplay example obviously used "default"
May 18 14:13:30 <GNUtoo|laptop>           mp_msg(MSGT_AO,MSGL_V,"alsa-init: got buffersize=%i\n", ao_data.buffersize);
May 18 14:13:32 <DocScrutinizer> default might get redefined in ~/.asoundrc
May 18 14:13:35 <GNUtoo|laptop> I'll look
May 18 14:14:16 <DocScrutinizer> so the issue might even depend on user's $HOME
May 18 14:14:36 <GNUtoo|laptop>         ao_data.buffersize = bufsize * bytes_per_sample;
May 18 14:14:55 <GNUtoo|laptop> basically apart from
May 18 14:14:57 <GNUtoo|laptop> <GNUtoo|laptop> aha playing a wav result in that:
May 18 14:14:59 <GNUtoo|laptop> to
May 18 14:15:04 <GNUtoo|laptop> <GNUtoo|laptop> mplayer->sdl->alsa->sound_card
May 18 14:15:08 <DocScrutinizer> i.e. it works with user:A and the ~A/.asoundrc but not with B and ~B/.asoundrc
May 18 14:15:09 <GNUtoo|laptop> I was using the .asoundrc
May 18 14:15:21 <GNUtoo|laptop> .asoundrc is for easier testing
May 18 14:15:34 <GNUtoo|laptop> I won't use that in "production"
May 18 14:16:14 <GNUtoo|laptop> err = snd_pcm_hw_params_get_buffer_size(alsa_hwparams, &bufsize
May 18 14:16:23 <GNUtoo|laptop> so we have:
May 18 14:16:27 <GNUtoo|laptop> err = snd_pcm_hw_params_get_buffer_size(alsa_hwparams, &bufsize
May 18 14:16:33 <GNUtoo|laptop> ao_data.buffersize = bufsize * bytes_per_sample;
May 18 14:16:44 <DocScrutinizer> sorry I can't help any further. You say it works with aplay, so find out what mplayer is doing differently
May 18 14:16:47 <GNUtoo|laptop> and then it prints the ao_data.buffersize
May 18 14:16:56 <GNUtoo|laptop> ok
May 18 14:17:34 <DocScrutinizer> see? what they did
May 18 14:18:02 <DocScrutinizer> bytes_per_sample sounds odd, as a frame is sample * channels
May 18 14:18:28 <GNUtoo|laptop> ok
May 18 14:18:49 <DocScrutinizer> dunno what weird names and units they use in mplayer
May 18 14:18:55 <GNUtoo|laptop> so the problem lies in mplayer?
May 18 14:19:13 <DocScrutinizer> but if they got confused about the units of their vars, then nothing good will result
May 18 14:19:40 <GNUtoo|laptop> ok
May 18 14:20:56 <DocScrutinizer> ao_data.buffersize_bytes = bufsize_frames * bytes_per_sample * channels;
May 18 14:21:00 <DocScrutinizer> or
May 18 14:21:08 <DocScrutinizer> ao_data.buffersize_bytes = bufsize_frames * bytes_per_frame
May 18 14:23:17 * DocScrutinizer feels like analysing why mars explorer crashed, and finding the vessel sw used imperial while the rocket used metric
May 18 14:23:50 <GNUtoo|laptop>  * ALSA 0.9.x-1.x audio output driver
May 18 14:23:50 <GNUtoo|laptop>  *
May 18 14:23:50 <GNUtoo|laptop>  * Copyright (C) 2004 Alex Beregszaszi
May 18 14:23:50 <GNUtoo|laptop>  *
May 18 14:23:50 <GNUtoo|laptop>  * modified for real ALSA 0.9.0 support by Zsolt Barat <joy@streamminister.de>
May 18 14:23:52 <GNUtoo|laptop>  * additional AC-3 passthrough support by Andy Lo A Foe <andy@alsaplayer.org>
May 18 14:23:54 <GNUtoo|laptop>  * 08/22/2002 iec958-init rewritten and merged with common init, zsolt
May 18 14:23:56 <GNUtoo|laptop>  * 04/13/2004 merged with ao_alsa1.x, fixes provided by Jindrich Makovicka
May 18 14:23:58 <GNUtoo|laptop>  * 04/25/2004 printfs converted to mp_msg, Zsolt.
May 18 14:24:00 <GNUtoo|laptop>  *
May 18 14:24:02 <GNUtoo|laptop>  * This file is part of MPlayer.
May 18 14:24:14 <GNUtoo|laptop>  * it under the terms of the GNU General Public License as published by
May 18 14:24:16 <GNUtoo|laptop>  * the Free Software Foundation; either version 2 of the License, or
May 18 14:24:20 <GNUtoo|laptop>  * (at your option) any later version.
May 18 14:24:22 <GNUtoo|laptop>  *
May 18 14:24:24 <GNUtoo|laptop>  * MPlayer is distributed in the hope that it will be useful,
May 18 14:24:26 <GNUtoo|laptop>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
May 18 14:24:28 <GNUtoo|laptop>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
May 18 14:24:30 <GNUtoo|laptop>  * GNU General Public License for more details.
May 18 14:24:32 <GNUtoo|laptop>  *
May 18 14:24:34 <GNUtoo|laptop>  * You should have received a copy of the GNU General Public License along
May 18 14:24:35 <DocScrutinizer> please quit!
May 18 14:24:36 <GNUtoo|laptop>  * with MPlayer; if not, write to the Free Software Foundation, Inc.,
May 18 14:24:38 <GNUtoo|laptop>  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
May 18 14:24:40 <GNUtoo|laptop>  */
May 18 14:24:42 <GNUtoo|laptop> #include <errno.h>
May 18 14:24:44 <GNUtoo|laptop> #include <sys/time.h>
May 18 14:24:46 <GNUtoo|laptop> #include <stdlib.h>
May 18 14:25:16 <GNUtoo|laptop> is it ok now?
May 18 14:25:19 <DocScrutinizer> yep
May 18 14:25:22 <DocScrutinizer> :-S
May 18 14:25:24 <GNUtoo|laptop> sometimes paste is messed up on my computers
May 18 14:25:27 <GNUtoo|laptop> sorry
May 18 14:25:34 <GNUtoo|laptop> http://git.mplayer2.org/mplayer2/tree/libao2/ao_alsa.c
May 18 14:26:02 <DocScrutinizer> I don't feel like debugging/proofreading that right ATM
May 18 14:26:25 <GNUtoo|laptop> ok
May 18 14:27:32 <GNUtoo|laptop> strangely it works on every other device(mplayer)
May 18 14:27:54 <DocScrutinizer> if you feel like doing anything about it, add a int   snd_pcm_dump (snd_pcm_t *pcm, snd_output_t *out) line to it
May 18 14:28:18 <GNUtoo|laptop> ok
May 18 14:28:54 <DocScrutinizer> (the -v for mplayer)
May 18 14:29:58 <GNUtoo|laptop> strange gstreamer works fine
May 18 14:30:04 <DocScrutinizer> as soon as your output from aplay -v is identical to mplayer ('-v'), you got mplayer fixed
May 18 14:30:26 <DocScrutinizer> for the audio part at least
May 18 14:30:57 <DocScrutinizer> then you still need to make sure the internal handling of interrupt callbacks etc is correct
May 18 14:31:16 <DocScrutinizer> niceness of audiothread, etc
May 18 14:31:25 <GNUtoo|laptop> ok nice
May 18 14:31:50 <DocScrutinizer> gtg, RL calling
May 18 14:31:54 <DocScrutinizer> o/
May 18 14:57:31 <CIA-30> freesmartphone.org: 03mickey 07aurora * rf975a0f11671 10/aurora/aurora/extensions/agents.py: aurora: agents: catch DBus exception
May 18 15:15:23 <JaMa> morphis: remove cache
May 18 15:15:43 <JaMa> morphis: everything except bb_persist_data.sqlite3 file
May 18 15:16:00 <morphis> ok
May 18 15:16:20 <morphis> JaMa: "ERROR: Error parsing oe-core/meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb: Failure expanding variable CONFIG_SITE, expression was ${@siteinfo_get_files(d)}"
May 18 15:16:23 <morphis> you know this one?
May 18 15:16:48 <morphis> it means I need a conf/site.conf?
May 18 15:17:13 <JaMa> morphis: switched to meta-smartphone already?
May 18 15:17:17 <morphis> yes
May 18 15:17:21 <JaMa> morphis: it's only proof-of-layout
May 18 15:17:42 <JaMa> morphis: I can finish it tonight if time permits, but I've still running build from meta-shr
May 18 15:17:55 <JaMa> and yes conf/site.conf is mandatory iirc
May 18 15:18:08 <morphis> I am only using meta-palm and my own meta-aurora from meta-smartphone
May 18 15:19:13 <JaMa> conf/site.conf defines ie TOPDIR
May 18 15:19:23 <JaMa> unless you have it in local.conf or somewhere
May 18 15:20:27 <morphis> l
May 18 15:20:39 <CIA-30> SHR: 03morphis 07meta-smartphone * r526cda1458f7 10/meta-palm/conf/machine/include/palmpre.inc: meta-palm: comment MACHINE_EXTRA_RDEPENDS until mentioned recipes are available
May 18 15:24:45 <CIA-30> freesmartphone.org: 03mickey 07aurora * r79638131634b 10/aurora/aurora/ (4 files in 3 dirs): aurora: add FSOResource wrapper
May 18 15:27:05 <DocScrutinizer> fsoraw \o/
May 18 15:27:32 <JaMa> :)
May 18 15:28:10 <DocScrutinizer> one of my favourites (though I guess the above commit been only a kind reminiscence in wording ;-D )
May 18 15:29:27 * DocScrutinizer notices his best inventions/projects always been remarkably terse in metrics of code, and thinks that's one of their best properties
May 18 15:30:19 <JaMa> yeah, made my bash wrappers around SetPolicy look really long and stupid :)
May 18 15:34:45 <morphis> mickeyl: ping
May 18 15:36:42 <DocScrutinizer> btw, /me muses how FSO/SHR adapted OMAP zeroclock/never-suspend paradigm on N900
May 18 15:36:49 <morphis> hm TARGET_FPU        = "soft" for palmpre looks wrong
May 18 15:36:49 <mickeyl> pong
May 18 15:37:01 <morphis> mickeyl: we have now a http://trac.freesmartphone.org/admin/spamfilter/monitor
May 18 15:37:12 <mickeyl> ok
May 18 15:37:15 <morphis> there we order the actions the user did as spam and ham
May 18 15:37:23 <mickeyl> morphis: any idea why http://pastie.org/1922177 makes the system no longer find any resources?
May 18 15:37:25 <morphis> I even updated trac to 0.12
May 18 15:37:29 <mickeyl> cool
May 18 15:37:45 <morphis> it's not installed via debian ... but anyway
May 18 15:37:57 <mickeyl> ah, probably a type mismatch
May 18 15:38:20 <morphis> mickeyl: as idleStatus is maybe not initialized?
May 18 15:38:25 <DocScrutinizer> mickeyl: any general policy about that zeroclock stuff?
May 18 15:38:54 <mickeyl> morphis: no, it's freaking out in the javascript, idleStatus wasn't supposed to be a boolean, so it crashes when setting it to active
May 18 15:39:19 <DocScrutinizer> or are you just hoping for kernel to do all right for a standby power of <10mA, and you simply disbale suspend?
May 18 15:39:21 <mickeyl> DocScrutinizer: not really. i don't fancy linux suspend, so if possible on any arch, then i'd like to get away without it
May 18 15:39:38 <DocScrutinizer> ack
May 18 15:39:59 <DocScrutinizer> should work "fine" on OMAP/SmartReflex
May 18 15:40:32 <DocScrutinizer> as long as you got proper cpufreq governour magic
May 18 15:41:01 <DocScrutinizer> which aiui is a kernel domain thing anyway
May 18 15:41:06 <CIA-30> freesmartphone.org: 03mickey 07aurora * rbbf318cf3963 10/aurora/aurora/ (extensions/agents.py main.qml): aurora: agents: idleStatus is not a boolean, how to fix it with 'active'?
May 18 15:41:13 <mickeyl> yep
May 18 15:42:23 <DocScrutinizer> also ISI quite probably won't fly with s2ram
May 18 15:42:55 <mickeyl> not a wakeupsource?
May 18 15:43:03 <DocScrutinizer> never checked it
May 18 15:43:19 <DocScrutinizer> but latency might be way too high
May 18 15:43:36 <DocScrutinizer> and wakeups way too frequent
May 18 15:44:11 <DocScrutinizer> after all ISI seems wasn't designed with wake from suspend in mind
May 18 15:46:17 <DocScrutinizer> and qite probably you can't suspend OMAP SoC while keeping the fifo for ISI up and running
May 18 15:47:29 <DocScrutinizer> (if there's such a thing like fifo for ISI)
May 18 15:48:34 <DocScrutinizer> isn't here even a watchdog in cmt? watching ISI interface for "I'm alive" msgs from APE
May 18 15:49:33 <DocScrutinizer> or been that the other way round?
May 18 15:51:35 <mickeyl> i don't know. there is one watchdog - the one we can disable via R&D mode, but i don't know whether this has anything to do with the modem
May 18 15:52:01 <mickeyl> there is also _one_ challenge/response call in ISI
May 18 15:52:09 <mickeyl> but that seems to occur only on startup
May 18 15:52:19 <mickeyl> that's the one which costed us a couple of weeks
May 18 15:52:25 <mickeyl> on the way to network camping
May 18 15:52:26 <mickeyl> *sigh*
May 18 15:54:04 <mickeyl> morphis: hmm, you're already going the oe-core way?
May 18 15:54:14 <mickeyl> isn't that a bit too many frontiers to fight at?
May 18 15:56:11 <morphis> mickeyl: no, I just played a little bit
May 18 15:56:21 <morphis> with stuff I had laying around
May 18 15:57:09 <DocScrutinizer> hmmm, speedevil should know, he suspended maemo. If there's any keep-alive mechanism then the modem shouldn't survive. I'll ask him
May 18 15:57:24 <morphis> mickeyl: for aurora we will stay at the classic version of oe
May 18 16:00:48 <DocScrutinizer> ok, modem stays alive and wakes APE on every nonsense, as expected
May 18 16:01:23 <morphis> mickeyl: I added a milestone for the first version of aurora in trac
May 18 16:02:50 <DocScrutinizer> mickeyl: so *if* you'd want to use s2ram scheme, you probably need to figure how to switch off all those unsolicited msgs from modem
May 18 16:03:53 <DocScrutinizer> otherwise resume plus suspend would eat more power than a zeroclocked CPU with occasional wakeups for a few ms
May 18 16:05:11 <mickeyl> DocScrutinizer: ya, that's the same we have with the AT modems
May 18 16:05:17 <mickeyl> but I won't look at that
May 18 16:05:20 <mickeyl> i'm fine with zeroclocking 
May 18 16:05:33 <mickeyl> _if_ we manage to get decent standby time
May 18 16:05:39 <mickeyl> morphis: ok, gtood
May 18 16:06:10 <morphis> mickeyl: you already tried aurora on the device?
May 18 16:06:15 <mickeyl> no time :/
May 18 16:06:59 <DocScrutinizer> standby time is a matter of kernel drivers properly managing all "peripherals"
May 18 16:07:07 * mickeyl quite busy with baby and wedding (I'm best man) preparations these days
May 18 16:07:25 <DocScrutinizer> baby? o.O
May 18 16:07:34 <NuttyBunny> morphis: did you check k3dar's patches and my later patch? We managed to completely install shr from zero with make install-all :)
May 18 16:07:38 <mickeyl> baby preparations, not the baby yet...
May 18 16:07:40 <DocScrutinizer> or baby in spe?
May 18 16:07:41 <mickeyl> still waiting *phew*
May 18 16:07:58 <morphis> NuttyBunny: yeah, great work!
May 18 16:08:06 <morphis> NuttyBunny: no I had not time to look at them
May 18 16:08:09 <morphis> but will do that
May 18 16:08:23 <morphis> mickeyl: wedding?
May 18 16:08:55 <mickeyl> a very good friend of mine
May 18 16:09:11 <mickeyl> on 3rd of june
May 18 16:09:26 <mickeyl> which is pretty near the ETA of our baby
May 18 16:09:29 <mickeyl> so everything very hectic atm.
May 18 16:09:39 <mickeyl> if all fails, then i can't even make the wedding
May 18 16:09:44 <mickeyl> still i need to prepare 
May 18 16:09:50 <morphis> ah ok
May 18 16:10:07 <mickeyl> speech, foto presentation, games, songs, etc.
May 18 16:10:08 <mickeyl> *sigh*
May 18 16:10:23 * morphis thought mickeyl is going marry ....
May 18 16:10:31 <mickeyl> not again ;)
May 18 16:10:34 <morphis> hehe
May 18 16:10:42 <mickeyl> not soon at least 
May 18 16:10:43 <mickeyl> hehe
May 18 16:11:40 <morphis> :)
May 18 16:12:21 <morphis> mickeyl: aren't the setStrength/setOperator method in the cellular agent unnecessary?
May 18 16:12:51 <morphis> as from qml we should not set them
May 18 16:12:58 <morphis> so we should not expose them by the property
May 18 16:13:28 <morphis> only for internal use we need them
May 18 16:16:03 <morphis> so sports time
May 18 16:44:50 <GNUtoo|laptop> DocScrutinizer, what's the difference between dunping the sound params within the alsa library , or with the kernel(/proc/asound) ?
May 18 16:55:06 <GNUtoo|laptop> ah nice it dumped
May 18 17:51:37 <DocScrutinizer51> damn, Ranga Jogeshwar in DasErste\wissen vor Acht  used a Dash to explain GPS o.O
May 18 18:00:20 <DocScrutinizer51> hmm,  maybe not
May 18 18:07:48 <ynezz> hi, I'm trying to use the debug board v2 for the first time with another board, using J1 connector (standard 20-pin arm jtag interface)
May 18 18:07:57 <ynezz> but it kind seems not working
May 18 18:08:41 <ynezz> the question is, is here by any chance someone who did used it that way and can confirm, that it should work?
May 18 18:09:01 <morphis|sports> mickeyl: let's go to froscon!
May 18 18:09:22 <ynezz> I've populated the missing 10k resistors r50,r47,r51,r52 but it didn't helped
May 18 18:10:10 <ynezz> looks like I would need to find someone with the oscilloscope :p
May 18 18:11:41 <ynezz> it works fine with my neo, so I doubt it's somehow broken
May 18 18:12:46 <max_posedon> ynezz, anarsoul (he is online there sometimes) can confirm 
May 18 18:13:08 <max_posedon> he used my debug board to recovery his some HP* PDA
May 18 18:13:33 <ynezz> ah great, good to know, thanks
May 18 18:14:50 <DocScrutinizer51> max_posedon: HEY!! long time no see, I thought what's up with you several times lately :-)
May 18 18:15:43 <max_posedon> hi! All is fine)
May 18 18:16:05 <max_posedon> I just jumped in game dev ("with head")
May 18 18:16:41 <max_posedon> so, no time for playing with linux, also changed neo to n900 a month ago.
May 18 18:17:13 <DocScrutinizer51> wellcome to the club :-D
May 18 18:17:58 <max_posedon> thanks)
May 18 18:18:49 <DocScrutinizer51> writing on N900 just ATM
May 18 18:19:50 <max_posedon> hardware keyboard is a really nice feature, yes. 
May 18 18:20:05 <DocScrutinizer51> yup
May 18 18:29:10 <max_posedon> and I just(today) got kitchen in my flat!
May 18 18:30:27 <lindi-> max_posedon: is it in openstreetmap yet? ;)
May 18 18:32:09 <max_posedon> flat != house), and I got a flat a half a year ago, so it is
May 18 18:32:09 <max_posedon> http://www.openstreetmap.org/?lat=54.011731&lon=27.682009&zoom=18&layers=M
May 18 18:32:18 <max_posedon> 12
May 18 18:32:35 <lindi-> heh ok
May 18 18:51:16 <GarthPS> morphis|sports: still at sport ? :)
May 18 18:51:39 <GarthPS> how to cal a target without having this in terminal output? make[1]: quittant le répertoire « /home/sylvain/Bureau/SHR-FSO-PRE2 »
May 18 19:13:43 <morphis> GarthPS: no
May 18 19:14:00 <morphis> GarthPS: as far as I know you can't do that
May 18 19:14:15 <morphis> maybe make -s
May 18 19:15:06 <morphis> mickeyl: ping
May 18 19:15:08 <GarthPS> morphis: hmm can't we call a target without specifying the path
May 18 19:15:30 <GarthPS> ok I wiiil look at it
May 18 19:15:42 <morphis> you mean that make doesn't print the line you mentioned above?
May 18 19:18:04 <GarthPS> morphis: I have finished my new target "neuralyze-me"
May 18 19:18:50 <GarthPS> yes. it print it because it changes of repository but I thinj it is possible to make it not change
May 18 19:19:30 <morphis> GarthPS: yeah
May 18 19:19:39 <morphis> but I would suggest to give it another name
May 18 19:19:51 <morphis> revert-all
May 18 19:23:27 <GarthPS> morphis: ohhh its fun..
May 18 19:23:35 <morphis> :)
May 18 19:27:01 <GarthPS> morphis: I eatand I push it after (and look how to mut make)
May 18 19:29:54 <JaMa> morphis: I'm still building allarch patch, but do you have any comments to meta-smartphone? I can play with it during build if needed :)
May 18 19:34:10 <morphis> JaMa: currently not comments but I like the idea 
May 18 19:34:27 <morphis> and will help you when first milestone of aurora is done
May 18 19:34:57 <morphis> as there is so much to do
May 18 19:35:21 <morphis> but I am still happy as all the oe-core stuff looks like a fresh and clean environment
May 18 19:35:29 <morphis> which is more professional than before
May 18 19:35:38 <morphis> due to the work of the yocto project
May 18 19:36:03 <morphis> but there are even enough bugs/problems
May 18 19:36:17 <morphis> JaMa: I discovered one today
May 18 19:37:02 <morphis> JaMa: http://pastie.org/1923203
May 18 19:38:47 <JaMa> morphis: ah sorry I didn't know why you need bitbake to reparse that
May 18 19:39:10 <morphis> JaMa: otherwise it did not work with the bbappend
May 18 19:39:17 <JaMa> morphis: we discovered this with koen about month ago (you can find it in libusb.bbappend discusion
May 18 19:39:24 <morphis> ah ok
May 18 19:39:31 <morphis> so it is a known problem
May 18 19:39:47 <JaMa> morphis: because I replaced couple of "full" recipes in meta-oe with .bbappend where was only BBCLASSEXTEND
May 18 19:40:05 <JaMa> morphis: and everything worked for me and failed for koen (exactly the same metadata)
May 18 19:40:18 <JaMa> morphis: iirc touch original.bb works too
May 18 19:40:33 <JaMa> if you add original.bbappend to your layer
May 18 19:41:00 <morphis> hm
May 18 19:41:17 <morphis> but touching the original.bb would override the one from the layer below, right?
May 18 19:42:06 <JaMa> no, it should reparse original.bb and finally take into account .bbappend from layer
May 18 19:42:39 <JaMa> otherwise it's thinking that cached version of original.bb is still valid
May 18 19:43:04 <morphis> hm
May 18 19:43:32 <morphis> but that should be solved somehow so it detects on it's own there is a new bbappend
May 18 19:43:38 <JaMa> removing cache except that bb_persistence file also works
May 18 19:43:44 <morphis> as touching the original.bb is only a workaround
May 18 19:43:48 <JaMa> right
May 18 19:44:08 <morphis> so it's a bug within bitbake
May 18 19:44:10 <JaMa> I even thought that it was fixed in bitbake master later, but seems it was not
May 18 19:44:22 <JaMa> I'll search for that thread we had about it
May 18 19:45:07 <morphis> ok
May 18 19:45:19 <morphis> I was even on the way writing about this to oe-devel
May 18 19:45:33 <JaMa> morphis: without proper fix: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-April/001311.html
May 18 19:46:48 <morphis> hm
May 18 19:48:37 <JaMa> so does COMPATIBLE_MACHINE_palmpre work?
May 18 19:48:55 <morphis> yes
May 18 19:49:03 <JaMa> ah, good
May 18 19:49:07 <morphis> everything in meta-palm works
May 18 19:49:19 <morphis> so I could build linux-palmpre
May 18 19:50:54 <JaMa> allarch.bbclass also seems working now, so I think I'll do this as first thing in meta-smartphone :)
May 18 19:51:21 <morphis> whats allarch.bbclass?
May 18 19:52:06 <JaMa> http://bugzilla.yoctoproject.org/show_bug.cgi?id=1075
May 18 19:52:31 <JaMa> and here is fix for oe-core http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/allarch&id=0944f7393054a91ce1508ec1a98bd4c612ee90e4
May 18 19:53:26 <JaMa> I have it in oe-core-contrib/shr without PR bumps and now I would like to extend it for meta-oe/meta-shr recipes to check that everything keeps its checksum after switching om-gta02/nokia900 and back
May 18 19:53:50 <JaMa> that's why I was rebuilding from scratch today again..
May 18 19:57:34 <morphis> ah ok
May 18 19:57:36 <morphis> interesting
May 18 20:00:42 <morphis> playya: ping
May 18 20:26:18 <JaMa> morphis: meta-palm does not depend on layers: meta-oe, meta-efl, only meta-core, right?
May 18 20:26:32 <JaMa> morphis: I'm updating all layer.conf and README files in meta-smartphone now
May 18 20:28:49 <JaMa> morphis: I'll list you there as main Maintainer, is sending patches to shr-devel with [meta-palm] prefix fine for you?
May 18 20:30:58 <CIA-30> freesmartphone.org: 03morphis 07cornucopia * r6fd78f9a8f62 10/fsodeviced/src/plugins/palmpre_quirks/ambientlight.vala: 
May 18 20:30:58 <CIA-30> freesmartphone.org: fsodeviced: palmpre_quirks: remove unneeded debug log message from ambientlight handler
May 18 20:30:58 <CIA-30> freesmartphone.org: The event we can't detect here is only the sync event we're not interested in anyway.
May 18 20:35:20 <pespin> JaMa, hi, is ther esome good place which explains how SHR & OE will work with the new layers way? ie what to do if someone wants to port a device? I'd like to learn about it once I finish univ on june ;)
May 18 20:39:58 <JaMa> pespin: yocto docs are good
May 18 20:40:40 <pespin> ok, but which part are shr specific? only the layer shr-core or meta-shr or whatever it's called?
May 18 20:41:12 <pespin> or machine specific layers which as far as I see you are creating are distro specific too?
May 18 20:41:45 <pespin> btw, thanks for info (yocto) I'll look at it :)
May 18 20:42:31 <JaMa> no, they are nto distro specific
May 18 20:42:44 <JaMa> and ideally they should depend only on oe-core layer
May 18 20:43:51 <JaMa> pespin: shr-core is "version" of shr (like -unstable and -testing)
May 18 20:44:02 <JaMa> pespin: meta-shr is old repo with new style metadata
May 18 20:44:30 <JaMa> pespin: meta-smartphone is new repo where meta-shr is limited to shr recipes (and 3rdparty apps used there - for now)
May 18 20:45:43 <JaMa> pespin: and bsp layers are in meta-smartphone layers not because they are distro specific, but because I don't want to create 6 git repositories
May 18 20:47:31 <pespin> ok, I'll look at those git repos to get a better idea :)
May 18 20:48:35 <CIA-30> SHR: 03Martin.Jansa 07meta-smartphone * rcdb1788aac2f 10/ (13 files in 13 dirs): all layers: unify layer.conf files and add/improve README files
May 18 20:48:46 <CIA-30> SHR: 03Martin.Jansa 07meta-smartphone * rcfd94dfda6f6 10/meta-shr/README: meta-shr: improve README with building and contributing info
May 18 20:48:46 <CIA-30> SHR: 03Martin.Jansa 07meta-smartphone * rbc38a1685bb1 10/meta-shr/conf/layer.conf: meta-shr: update layer.conf like meta-angstrom did in 7dc05254f398dfaf46454eca0ed1ee3e6c4b67d5
May 18 21:06:27 <CIA-30> freesmartphone.org: 03morphis 07aurora * r1b5a8162b222 10/aurora/bin/aurora.in: aurora: quit application on SIGINT
May 18 21:06:28 <CIA-30> freesmartphone.org: 03morphis 07aurora * r0952622fbdc3 10/aurora/components/common/Dialpad.qml: aurora: text input field within the dialpad has the focus now automatically
May 18 21:10:59 <morphis> JaMa: do you see any problem with pushing a new distro to oe-classic? or should I ask on oe-devel before I do that?
May 18 21:15:11 <JaMa> I dont see any problem with it
May 18 21:15:21 <morphis> ok
May 18 21:15:29 <morphis> then I will push all the aurora stuff tomorrow
May 18 21:18:50 <morphis> so I am off now
May 18 21:18:51 <morphis> gn8
May 18 21:20:01 <JaMa> gn8
May 18 21:20:08 <CIA-30> SHR: 03Martin.Jansa 07shr-chroot * rc4c9c684406b 10/OE/.bashrc: bashrc: use cleanall for clean_toolchain_core
May 18 21:22:46 <CIA-30> SHR: 03Martin.Jansa 07shr-chroot * r2b02b9635e4c 10/ (13 files in 7 dirs): system upgrade
May 18 21:49:49 <JaMa> fscking typo!
May 18 22:13:14 <CIA-30> SHR: 03Martin.Jansa 07shr-makefile * r29fc97565de1 10/ (Makefile conf/shr-core/bblayers.conf): Makefile: switch from meta-shr repo to meta-smartphone
May 18 22:41:56 <CIA-30> SHR: 03Martin.Jansa 07meta-smartphone * rce1877a6d276 10/meta-openmoko/conf/ (6 files in 4 dirs): meta-openmoko: fix typo in directory name
May 18 22:42:06 <CIA-30> SHR: 03Martin.Jansa 07meta-smartphone * rc2c311c89385 10/meta-shr/conf/distro/shr.conf: SHR: use blacklist from meta-oe
**** ENDING LOGGING AT Thu May 19 02:59:58 2011