**** BEGIN LOGGING AT Tue Nov 29 02:59:57 2011
Nov 29 06:46:18 <mrmoku> zub: yeah... pespin forced me to bleeding edge valac :)
Nov 29 06:46:26 <mrmoku> moin
Nov 29 07:40:39 <snkt> I m configuring D-Link WA125 USB wireless adaptor for ARM...... I had compiled a kernel with ralink support .... but still WA125 adapter is not detecting.... can anyone me help....
Nov 29 07:44:25 <JaMa> moin
Nov 29 07:59:33 <CIA-69> SHR: 03Martin.Jansa 07shr-chroot * rc7d1de073c60 10/ (1128 files in 41 dirs): system upgrade
Nov 29 08:26:40 <zub> mrmoku: and I assume you rebuilt libeflvala... then I find it strange you have not bumped into a compilation error
Nov 29 08:26:54 <zub> I saw it, eventually it showed up for pespin too
Nov 29 08:27:23 <zub> anyway fix is in the git repo, and it continues to work with old vala
Nov 29 08:28:28 <mrmoku> zub: hmm... actually... I did not rebuild libeflvala with valac from git
Nov 29 08:28:34 <mrmoku> installed it after etalk build failed
Nov 29 08:28:38 <mrmoku> and just rebuilt etalk
Nov 29 08:28:42 <zub> ok :)
Nov 29 08:28:46 <zub> that explains it
Nov 29 08:28:49 <mrmoku> :)
Nov 29 08:28:55 <zub> one mystery less, that's only good
Nov 29 08:31:14 <zub> mrmoku: would you know... do vala applications typically offer a way to set custom VALAFLAGS?
Nov 29 08:31:39 <zub> IIRC I had to go through some extra hoops to make my autohell-built app allow for VALAFLAGS from the env.
Nov 29 08:32:47 <mrmoku> zub: hmm... I'm neither vala nor autohell expert... NFC :/
Nov 29 08:33:03 <zub> ok, I bring it up with the vala gods then
Nov 29 08:33:37 <zub> I have the feeling I saw it discussed somewhere, with the point being "who'd want that"... but if you have libs in non-std places (somewhere in $HOME), you might need it for vapidir's
Nov 29 08:33:42 <mrmoku> yeah... send them a prayer :)
Nov 29 08:33:46 <zub> :)
Nov 29 09:35:12 <mrmoku> radekp: you know fsodeviced can serve as firmware loader?
Nov 29 10:02:24 <radekp> mrmoku: hi, nice
Nov 29 10:49:27 <GNUtoo> hi mrmoku 
Nov 29 11:00:22 <GNUtoo> mickeyl, hi
Nov 29 11:00:37 <GNUtoo> mickeyl, how can you see which AT commands fsogsmd send/receive from fsogsmd
Nov 29 11:05:59 <mrmoku> hi GNUtoo 
Nov 29 11:06:30 <GNUtoo> hi
Nov 29 11:06:57 <GNUtoo> are AT commands only displayed in the modem plugins(not in the lowlevel plugins) ?
Nov 29 11:11:37 <GNUtoo>         var bread = transport.writeAndRead( "AT\r\n", 4, buf, 512, 0 );
Nov 29 11:11:49 <GNUtoo> I want to see that stuff in fsogsmd
Nov 29 11:11:51 <GNUtoo> how do I do that?
Nov 29 11:13:59 <mrmoku> hmm
Nov 29 11:14:26 <mrmoku> GNUtoo: doesn't transport log to libgsm log?
Nov 29 11:14:38 <GNUtoo> normally yes but I don't see a thing
Nov 29 11:14:40 <GNUtoo> and I've DEBUG
Nov 29 11:15:49 <GNUtoo> http://www.pastie.org/2938077
Nov 29 11:16:07 <mrmoku> #if DEBUG debug( @"writeAndRead: writing $((string)wdata) ($wlength)" );
Nov 29 11:16:10 <mrmoku> #endif 
Nov 29 11:16:17 <mrmoku> so you should see that somewhere...
Nov 29 11:16:18 <mrmoku> ahh
Nov 29 11:16:23 <GNUtoo> DEBUG is not set
Nov 29 11:16:25 <mrmoku> GNUtoo: debug goes to stdout I think
Nov 29 11:16:30 <GNUtoo> no
Nov 29 11:16:35 <GNUtoo> DEBUG is like #ifdef
Nov 29 11:16:36 <mrmoku> ahh, you have loglevel debug
Nov 29 11:16:40 <GNUtoo> it's a compile time thing
Nov 29 11:16:43 <GNUtoo> --enable-debug
Nov 29 11:16:47 <mrmoku> I know
Nov 29 11:16:53 <mrmoku> 12:11 < GNUtoo> and I've DEBUG
Nov 29 11:16:55 <GNUtoo> which we don't enable
Nov 29 11:16:58 <GNUtoo> ahhh
Nov 29 11:16:59 <mrmoku> I thought you have it enabled
Nov 29 11:17:03 <GNUtoo> I meant debug in config file
Nov 29 11:17:24 <GNUtoo> http://www.pastie.org/2938077
Nov 29 11:17:59 <mrmoku> there is no logger in writeAndRead
Nov 29 11:18:06 <mrmoku> just with #define DEBUG
Nov 29 11:18:12 <GNUtoo> ok
Nov 29 11:18:36 <mrmoku> did you try with the even newer vala morphis added yesterday?
Nov 29 11:19:42 <GNUtoo> I'll try
Nov 29 11:20:25 <mrmoku> ok, I really hope that will fix it
Nov 29 11:20:36 <GNUtoo> I made a test
Nov 29 11:20:44 <GNUtoo> I installed an old libfsotransport
Nov 29 11:20:46 <GNUtoo> and it works
Nov 29 11:20:54 <GNUtoo> so or vala broke fsotransport
Nov 29 11:20:59 <mrmoku> ok
Nov 29 11:21:02 <GNUtoo> or...morphis broke it
Nov 29 11:21:56 <mrmoku> libfsotransport: commandqueue: respect the case that we can have more than two commands pending
Nov 29 11:22:00 <mrmoku> hmm... that one is from 20th
Nov 29 11:22:38 <GNUtoo> ok
Nov 29 11:23:27 <mrmoku> actually that one looks fishy
Nov 29 11:24:30 <GNUtoo> let me try with reverting that
Nov 29 11:24:30 <mrmoku> hmm... or not
Nov 29 11:25:36 <mrmoku> ok
Nov 29 11:25:39 * mrmoku lunch  meanwhile
Nov 29 11:26:47 <GNUtoo> it's not that patch
Nov 29 11:34:17 <GNUtoo> seem not to be vala
Nov 29 11:34:37 <GNUtoo> (I compiled old version with newer valac)
Nov 29 11:35:52 <GNUtoo> strange 
Nov 29 11:45:10 <GNUtoo> strange I don't understand
Nov 29 11:46:20 <GNUtoo> I try work/armv4t-oe-linux-gnueabi/libfsotransport-1_0.9.6+gitr2+ead0c62443b1d1372c618bba5ce3aafa849f3f87-r6.2
Nov 29 11:46:27 <GNUtoo> I scp the libfsotransport 
Nov 29 11:46:29 <GNUtoo> then it work
Nov 29 11:47:00 <GNUtoo> then I try work/armv4t-oe-linux-gnueabi/libfsotransport-1_0.9.6+gitr42+3d9c42ca3cff4929c278805bf099ca3471301629-r6.2
Nov 29 11:47:05 <GNUtoo> I scp the libfsotransport
Nov 29 11:47:07 <GNUtoo> and it fails
Nov 29 11:47:14 <GNUtoo> so until here it's ok
Nov 29 11:47:18 <GNUtoo> then I try work/armv4t-oe-linux-gnueabi/libfsotransport-1_0.9.6+gitr42+3d9c42ca3cff4929c278805bf099ca3471301629-r6.2
Nov 29 11:47:31 <GNUtoo> I git checkout ead0c62443b1d1372c618bba5ce3aafa849f3f87 inside it
Nov 29 11:47:38 <GNUtoo> and recompile
Nov 29 11:47:42 <GNUtoo> and still fails
Nov 29 11:50:04 <GNUtoo> something is bad in my procedure I guess
Nov 29 11:52:05 <GNUtoo> work/armv4t-oe-linux-gnueabi/libfsotransport-1_0.9.6+gitr2+ead0c62443b1d1372c618bba5ce3aafa849f3f87-r6.2 at HEAD fails tough
Nov 29 11:55:17 <GNUtoo> maybe configure options
Nov 29 11:55:37 <GNUtoo> or maybe it didn't recompile well
Nov 29 11:55:41 <GNUtoo> now it should have
Nov 29 11:55:43 <GNUtoo> retrying
Nov 29 11:56:44 <GNUtoo> still the same
Nov 29 11:56:50 <GNUtoo> I'll compare the configure options
Nov 29 11:59:39 <GNUtoo> the options seem the same
Nov 29 11:59:42 <GNUtoo> strange strange
Nov 29 12:00:33 <GNUtoo> JaMa, hi, since the devshell works another way, is there a way to build not in oe?
Nov 29 12:00:52 <JaMa> sorry I don't understand
Nov 29 12:01:25 <GNUtoo> the devshell is not the same than in oe.dev anymore
Nov 29 12:01:43 <GNUtoo> I want to source it and to build libfsotransport....outside from oe
Nov 29 12:01:48 <GNUtoo> that is to say not with bitbake
Nov 29 12:01:58 <GNUtoo> not following the recipe
Nov 29 12:02:49 <JaMa> you can build toolchain and source it afaik
Nov 29 12:03:06 <JaMa> but I'm usually sourcing run.do_compile.* scripts to get env setup right
Nov 29 12:03:20 <GNUtoo> ok
Nov 29 12:12:26 <GNUtoo> JaMa, it doesn't work for building out of tree stuff
Nov 29 12:13:02 <GNUtoo> it seem to cd into the in-tree stuff before do_foo
Nov 29 12:13:25 <JaMa> but you can move cwd somewhere else and still keep your env
Nov 29 12:13:55 <JaMa> sorry I never used devshell so I probably dont understand your use-case
Nov 29 12:14:37 <GNUtoo> ok
Nov 29 12:14:45 <GNUtoo> the use case was to build something out of tree
Nov 29 12:25:24 <mrmoku> zub: hmm... there is no e.vapi.... so building e modules with vala is not (yet) possible, right?
Nov 29 12:30:56 <zub> mrmoku: what are e modules? (now it's NFC from my side)
Nov 29 12:31:11 <zub> but probably the answer is no
Nov 29 12:31:32 <mrmoku> :)
Nov 29 12:31:45 <mrmoku> zub: something you can load as module in e17
Nov 29 12:31:49 <GNUtoo> enlightenment modules like elfe, keyboard etc...
Nov 29 12:32:06 <zub> too bad pespin doesn't keep his client connected, I sometimes feel like leaving him a message, but can't, at least not via IRC :-/
Nov 29 12:32:19 <mrmoku> yeah, indeed
Nov 29 12:32:36 <GNUtoo> zub, mail?
Nov 29 12:32:45 <zub> na klar
Nov 29 12:33:08 <zub> but when on IRC, it would be more convenient
Nov 29 12:33:22 <zub> anyway, mrmoku, if you remined me and/or pespin in the evening
Nov 29 12:33:28 <zub> we might have a look at it
Nov 29 12:33:34 <zub> as it sounds interesting
Nov 29 12:33:58 <zub> modules = shared libs?
Nov 29 12:35:47 <mrmoku> zub: kind of
Nov 29 12:35:59 <mrmoku> let me see if I find some documentation
Nov 29 12:37:36 <GNUtoo> mrmoku, newer vala doesn't fix it
Nov 29 12:37:42 <mrmoku> zub: http://trac.enlightenment.org/e/wiki/Gadgets
Nov 29 12:37:45 <mrmoku> GNUtoo: damn :/
Nov 29 12:37:53 <GNUtoo> mrmoku, did you see what I wrote?
Nov 29 12:38:00 <mrmoku> yeah
Nov 29 12:38:07 <GNUtoo> my setup is kind of problematic
Nov 29 12:38:21 <mrmoku> what vala version do you have in OE now?
Nov 29 12:38:24 <zub> GNUtoo: what issues you're fighting?
Nov 29 12:38:35 <GNUtoo> mrmoku, I think the newest one
Nov 29 12:38:52 <GNUtoo> zub, many issues, but my priority right now is to get telephony working again
Nov 29 12:38:57 <GNUtoo> libfsotransport is broken
Nov 29 12:39:00 <GNUtoo> on om-gta02
Nov 29 12:39:33 <zub> ah, I thought some vala compilation/build issues
Nov 29 12:39:40 <GNUtoo> zub, possible
Nov 29 12:39:47 <GNUtoo> not build tough
Nov 29 12:39:51 <GNUtoo> but runtime
Nov 29 12:40:08 <GNUtoo> also ffalarms is broken at compile time
Nov 29 12:40:12 <zub> I'm running bleeding edge vala + efl, all built and installed in $HOME, so I got some exprience :)
Nov 29 12:40:15 <GNUtoo> and at runtime too since too long
Nov 29 12:40:19 <mrmoku> GNUtoo: 0.14.0.6 right?
Nov 29 12:40:20 <zub> (but on PC)
Nov 29 12:40:29 <GNUtoo> mrmoku, how do I find out?
Nov 29 12:40:38 <mrmoku> GNUtoo: look in tmp/work?
Nov 29 12:41:06 * mrmoku wonders if it is broken for gta04 too
Nov 29 12:41:59 <GNUtoo> Vala 0.14.0.6-68e8
Nov 29 12:44:05 <mrmoku> ok
Nov 29 12:44:29 * mrmoku boots his gta04 to see if transport works there
Nov 29 12:47:22 * GNUtoo will try to build ead0c62443b1d1372c618bba5ce3aafa849f3f87 within oe
Nov 29 12:48:18 <mrmoku> even worse
Nov 29 12:48:19 <mrmoku> root@om-gta04:~# fsogsmd
Nov 29 12:48:20 <mrmoku> Segmentation fault
Nov 29 12:48:37 <GNUtoo> ouch
Nov 29 12:48:49 <GNUtoo> any log before that?
Nov 29 12:49:19 <GNUtoo> everything worked fine for a while then there were too many update at the same time
Nov 29 12:49:27 <mrmoku> 2000-01-01T00:04:00.578582Z [ERROR] DBusServiceResource <GSM>: Could not register GSM with ousaged: Error calling StartServiceByName for org.freesmartphone.ousaged: GDBus.Error:o
Nov 29 12:49:28 <GNUtoo> and everything broke
Nov 29 12:49:31 <mrmoku> rg.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/libexec/dbus-daemon-launch-helper received signal 11; trying to enable the resource unconditionally
Nov 29 12:49:44 <mrmoku> root@om-gta04:~# fsousaged 
Nov 29 12:49:44 <mrmoku> Segmentation fault
Nov 29 12:49:47 <mrmoku> gah
Nov 29 12:50:07 <GNUtoo> ok
Nov 29 12:50:14 <GNUtoo> mrmoku, you extracted on microsd right?
Nov 29 12:50:19 <mrmoku> yup
Nov 29 12:50:34 <mrmoku> root@om-gta04:~# ls -l /usr/libexec/dbus-daemon-launch-helper 
Nov 29 12:50:35 <mrmoku> -rwsr-xr--    1 root     messageb    185056 Nov 22  2011 /usr/libexec/dbus-daemon-launch-helper
Nov 29 12:50:38 <GNUtoo> how did you extract
Nov 29 12:50:51 <GNUtoo> because tar xvjpf is wrong
Nov 29 12:51:01 <mrmoku> hmm... my install script does that
Nov 29 12:51:02 <mrmoku> moment
Nov 29 12:51:29 <mrmoku> TAROPT=-xzf
Nov 29 12:51:42 <GNUtoo> you should use --numeric-owner 
Nov 29 12:51:48 <mrmoku> tar -C /mnt/neo $TAROPT '$IMG'
Nov 29 12:51:48 <GNUtoo> you are not using it
Nov 29 12:52:09 <mrmoku> ok, will add that in the script and retry
Nov 29 12:52:19 <GNUtoo> add --numeric-owner to the command
Nov 29 12:52:33 <JaMa> and you need normal tar :)
Nov 29 12:54:07 <mrmoku> that for sure :P
Nov 29 12:54:21 <mrmoku> 0022 mok@ladyt[pts/2]:~/shr-chroot-> tar --version
Nov 29 12:54:22 <mrmoku> tar (GNU tar) 1.26
Nov 29 12:55:05 <mrmoku> JaMa, GNUtoo: I have problems with CMDLINE on gta04...
Nov 29 12:55:14 <mrmoku> It does not use what u-boot is passing
Nov 29 12:55:31 <GNUtoo> printenv?
Nov 29 12:55:33 <mrmoku> and in my defconfig forcing the compiled in CMDLINE is off
Nov 29 12:55:47 <mrmoku> moment
Nov 29 12:55:52 <JaMa> mrmoku: is it still off after linux.inc mangling?
Nov 29 12:56:06 <GNUtoo> maybe it's vala then
Nov 29 12:56:18 <JaMa> newer kernels changed CONFIG_ options wrt CMDLINE so maybe linux.inc needs some tweaks too
Nov 29 12:56:19 <mrmoku> JaMa: that would be my question
Nov 29 12:56:23 <GNUtoo> because:
Nov 29 12:56:24 <GNUtoo> opkg install libfsotransport0_0.9.6+gitr43+ead0c62443b1d1372c618bba5ce3aafa849f3f87-r6.2_armv4t.ipk
Nov 29 12:56:27 <GNUtoo> didn't fix it
Nov 29 12:56:29 <GNUtoo> I'll eat
Nov 29 12:56:40 <mrmoku> GNUtoo: maybe it needs rebuilding more stuff
Nov 29 12:56:45 <mrmoku> not only libfsotransport
Nov 29 12:56:49 <GNUtoo> possible
Nov 29 12:56:51 <GNUtoo> bbl
Nov 29 12:56:54 <mrmoku> cu
Nov 29 12:57:12 <mrmoku> JaMa: newer vala is in jansa/tests already?
Nov 29 12:58:09 <mrmoku> yeah, it is
Nov 29 12:59:27 <mrmoku> gah
Nov 29 12:59:34 * mrmoku should be more carefull with make update ;)
Nov 29 12:59:56 <JaMa> got efl?
Nov 29 13:00:08 <mrmoku> no... lost my kernel changes :_P
Nov 29 13:00:13 <JaMa> ah
Nov 29 13:00:40 <mrmoku> nothing dramatic... just the srcrev and a scp of the defconfig
Nov 29 13:02:11 <JaMa> btw there is new libnl-3, do we want that?
Nov 29 13:02:26 <JaMa> it's incompatible with libnl-2
Nov 29 13:02:39 <JaMa> so I'll add P_V for it for now
Nov 29 13:10:40 <mrmoku> JaMa: hehe, yeah saw that... libnl fun :(
Nov 29 13:12:45 <GNUtoo> mrmoku, altough replacing just libfsotransport with older version built long time ago worked
Nov 29 13:13:22 <mrmoku> GNUtoo: yeah, read that... it's a strange thing
Nov 29 13:14:00 <GNUtoo> what should I do now?
Nov 29 13:14:03 <GNUtoo> revert vala?
Nov 29 13:18:52 <GNUtoo> the last compiled before r42 is:
Nov 29 13:18:53 <GNUtoo> libfsotransport-1_0.9.6+gitr38+22b0f0b0951660081742124cf3f566a4351347be-r6.2
Nov 29 13:19:00 <GNUtoo> and scping the lib make it work
Nov 29 13:19:12 <GNUtoo> so it's between the two that something changes
Nov 29 13:19:14 <GNUtoo> *changed
Nov 29 13:21:22 <mrmoku> dunno
Nov 29 13:22:23 <mrmoku> I will try with a fresh gta04 image when it sinished
Nov 29 13:22:31 <mrmoku> finished even
Nov 29 13:23:10 <GNUtoo> ok
Nov 29 13:23:41 <GNUtoo> mrmoku, abuot numeric-owner basically your desktop/laptop has /etc/groups
Nov 29 13:23:47 <GNUtoo> so it uses the values inside that
Nov 29 13:23:52 <GNUtoo> which doesn't match SHR values
Nov 29 13:23:56 <GNUtoo> so it create issues
Nov 29 13:24:14 <GNUtoo> so for instance messagebus will be an unknown number on target
Nov 29 13:25:44 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * rfc5922f472c9 10/meta-shr/conf/distro/include/preferred-shr-versions.inc: meta-shr: add P_V for libnl-2
Nov 29 13:28:46 <CIA-69> SHR: 03mok 07meta-smartphone * r2c51c01ed44a 10/meta-openmoko/recipes-kernel/linux/ (linux-gta04/defconfig linux-gta04_git.bb): linux-gta04_git.bb: switch to the merge tree of Neil Brown
Nov 29 13:28:56 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * rc7901c905f9e 10/meta-shr/ (12 files in 12 dirs): meta-shr: enable pam DISTRO_FEATURE and add PRINC for recipes which are influenced by this
Nov 29 13:28:57 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * r39c52a2b9cc5 10/meta-fso/recipes-devtools/vala/vala_0.14.0.6-68e8.bb: vala: add gtk+ to depends
Nov 29 13:30:22 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * rfadb69e26609 10/meta-shr/recipes-connectivity/avahi/ (avahi-ui_0.6.30.bbappend avahi_0.6.30.bbappend): avahi: drop sysvinit-pidof from RDEPENDS
Nov 29 13:31:26 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * rfb5ad8acff08 10/meta-nokia/conf/machine/nokia900.conf: nokia900: don't replace /sbin/init link with actuall file
Nov 29 13:31:42 <mrmoku> CONFIG_CMDLINE_FORCE=y
Nov 29 13:31:44 <mrmoku> damn
Nov 29 13:31:52 <mrmoku> JaMa: indeed something is turning that on :/
Nov 29 13:32:16 <mrmoku> ohh... no
Nov 29 13:32:42 <mrmoku> it's in my defconfig :P
Nov 29 13:32:44 <mrmoku> gah
Nov 29 13:35:09 <mrmoku> JaMa: KERNEL_ENABLE_CGROUPS goes into shr.conf?
Nov 29 13:35:40 <JaMa> ?
Nov 29 13:36:10 <mrmoku> linux.inc enforces cgroups to be on in kernel config
Nov 29 13:36:13 <mrmoku> when  that var is set
Nov 29 13:36:21 <mrmoku> which is what we want for systemd, no?
Nov 29 13:36:55 <mrmoku> on the other hand we might have older kernels without cgroups... hmm
Nov 29 13:36:56 <JaMa> ah, right shr.conf 
Nov 29 13:38:27 <mrmoku> that's only the half story though
Nov 29 13:38:49 <mrmoku> systemd wants autofs, ipv6 and bridge built in too
Nov 29 13:39:18 <mrmoku> maybe we just wait where systemd is going regarding oe-core ;)
Nov 29 13:40:23 <JaMa> it could take longer then next weekend I fear :/
Nov 29 13:41:08 <JaMa> my goal is to merge jansa/test before FSOSHRCON, but...
Nov 29 13:41:35 <JaMa> fscking daywork.. ahh better :)
Nov 29 13:42:22 <Ainulindale> For FSOSHRCON
Nov 29 13:42:30 <Ainulindale> You should wire some money to Paul
Nov 29 13:42:36 <Ainulindale> So this time he won't have to take the bus from Moscow
Nov 29 13:42:46 <Ainulindale> And spend two days utterly wasted by the trip
Nov 29 13:43:10 <Ainulindale> As for me one thing I will surely miss is the beers mrmoku gave me last time :-(
Nov 29 13:43:39 * mrmoku promisses a crate of good bavarian beer to Ainulindale if he comes ;)
Nov 29 13:44:37 <Ainulindale> I won'et be able to 
Nov 29 13:44:40 <Ainulindale> That's sure
Nov 29 13:44:43 <Ainulindale> I started a new job remember?
Nov 29 13:45:03 <Ainulindale> And anyways I wasn't implicated in the project the last few years :-)
Nov 29 13:45:37 <mrmoku> few is exagerated... and a 'comeback' is always possible :)
Nov 29 13:45:55 <mrmoku> JaMa: eina-native fails
Nov 29 13:46:06 <Ainulindale> Well mrmoku you know what drove me away
Nov 29 13:46:15 <GNUtoo> bugs?
Nov 29 13:46:17 <Ainulindale> You know that this probably hasn't changed since then
Nov 29 13:46:23 <JaMa> mrmoku: how?
Nov 29 13:47:02 <GNUtoo> Ainulindale, what drove you away?
Nov 29 13:47:03 <mrmoku> | cp: cannot stat `/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/share/aclocal/vala.m4': No such file or directory
Nov 29 13:47:03 <Ainulindale> Lack of QA, OE changes too fast with no concern for true stability, people who grew on my nerves and such
Nov 29 13:47:09 <Ainulindale> In the end it wasn't interesting anymore
Nov 29 13:47:13 <GNUtoo> ok
Nov 29 13:47:23 <mrmoku> Ainulindale: got worse even :-P
Nov 29 13:47:32 <mrmoku> (without you spanking now and then)
Nov 29 13:47:48 <GNUtoo> indeed but oe-core now officialy cares about stability
Nov 29 13:47:49 <Ainulindale> GNUtoo: I think that at that time I was maybe one of the couple of actual users on a day to day basis
Nov 29 13:48:02 <Ainulindale> I'm not sure many people can say so
Nov 29 13:48:13 <mrmoku> JaMa: it built in parallel with vala-native... probably that's the problem
Nov 29 13:48:17 <GNUtoo> I am currently using the freerunner daily too
Nov 29 13:48:25 <Ainulindale> GNUtoo: And I was back then
Nov 29 13:48:25 <mrmoku> configure hitting the moment where vala-native already was removed and not yet back
Nov 29 13:48:33 <Ainulindale> More than two years ago I think now
Nov 29 13:49:11 <Ainulindale> And it was working as long as I didn't include the changes commited by overexcited developers
Nov 29 13:49:24 <GNUtoo> lol
Nov 29 13:49:41 <Ainulindale> I spent a lot of time arched upon the enter key for the revert commit (aka nuclear blast) action
Nov 29 13:49:50 <GNUtoo> now someone bumped vala and telephony broke....along with efl bump and lots of other bump....
Nov 29 13:49:53 <Ainulindale> But in the end I wasn't too keen on being a jackass
Nov 29 13:50:00 <Ainulindale> GNUtoo: That's the problem
Nov 29 13:50:05 <Ainulindale> This has to be done in a sandbox
Nov 29 13:50:07 <Ainulindale> Not for everyone
Nov 29 13:50:14 <Ainulindale> As long as it's done that way
Nov 29 13:50:20 <Ainulindale> Either in OE or SHR
Nov 29 13:50:24 <Ainulindale> As long as there are autorevs
Nov 29 13:50:32 <Ainulindale> It won't work properly and that's logical
Nov 29 13:50:34 <GNUtoo> Ainulindale, maybe we need you at FSOSHRCON for advises on how to handle stuff
Nov 29 13:50:36 <Ainulindale> Bleeding edge is for power users
Nov 29 13:50:41 <Ainulindale> GNUtoo: I did that last time
Nov 29 13:50:47 <Ainulindale> I did that LOADS of time
Nov 29 13:51:03 <Ainulindale> I spent so much time on that I actually wasn't able to do other things
Nov 29 13:51:11 <Ainulindale> Cleaning after people, fixing regressions
Nov 29 13:51:24 <GNUtoo> I spent too much time fixing bugs too
Nov 29 13:51:33 <Ainulindale> I'm not talking about bugs
Nov 29 13:51:35 <GNUtoo> that's what I do most of the time now
Nov 29 13:51:39 <Ainulindale> I'm talking about regressions
Nov 29 13:51:42 <GNUtoo> ok
Nov 29 13:51:44 <Ainulindale> Bugs are logical
Nov 29 13:51:47 <Ainulindale> Regressions aren't
Nov 29 13:52:02 <Ainulindale> Bugs mean no appropriate tests or not enough tests
Nov 29 13:52:02 <GNUtoo> so s/bugs/regressions/
Nov 29 13:52:11 <Ainulindale> Regressions mean no care from the developer
Nov 29 13:52:13 <GNUtoo> we have no tests at all
Nov 29 13:52:18 <Ainulindale> Yeah I know
Nov 29 13:52:23 <Ainulindale> I launched an initiative for that
Nov 29 13:52:30 <Ainulindale> There was no follow-up sadly :-)
Nov 29 13:52:39 <Ainulindale> You need (again) QA procedures
Nov 29 13:52:41 <Ainulindale> Unit testing
Nov 29 13:52:48 <GNUtoo> I tried to make someone work on that and it failled too
Nov 29 13:52:48 <Ainulindale> And sandboxes
Nov 29 13:52:55 <Ainulindale> That's because it's annoying
Nov 29 13:53:04 <Ainulindale> So either do it yourself or find a motivated enough person
Nov 29 13:53:23 <Ainulindale> I was neither of these categories
Nov 29 13:53:30 <Ainulindale> (motivated or willing to do it myself)
Nov 29 13:53:41 <Ainulindale> And couldn't find someone 
Nov 29 13:53:45 <GNUtoo> ok
Nov 29 13:53:46 <Ainulindale> So I let it go :-)
Nov 29 13:53:58 <Ainulindale> Plus I was disgusted for a time by open source
Nov 29 13:54:05 <Ainulindale> Due to a certain company I should never have joined
Nov 29 13:54:13 <GNUtoo> ah?
Nov 29 13:54:22 <GNUtoo> bearstech?
Nov 29 13:54:54 <Ainulindale> Yep
Nov 29 13:55:02 <Ainulindale> I was trying not to name them though :-)
Nov 29 13:55:03 <GNUtoo> what did they do wrong?
Nov 29 13:55:53 <GNUtoo> mrmoku, I'll go and come back late this night
Nov 29 13:55:55 <Ainulindale> I'm sure that cdevel isn't the place to talk about that
Nov 29 13:56:02 <mrmoku> GNUtoo: ok
Nov 29 13:56:13 <GNUtoo> mrmoku, so if you have time to try to fix....
Nov 29 13:56:21 <mrmoku> I will try
Nov 29 13:56:39 <GNUtoo> thanks  a lot
Nov 29 13:56:52 <Ainulindale> GNUtoo: but more seriously if there's no QA I can't see the point, software won't be stable enough anytime soon :-)
Nov 29 13:57:07 <Ainulindale> fso does QA
Nov 29 13:57:12 <Ainulindale> why not OE/SHR ?
Nov 29 13:57:33 <mrmoku> JaMa: after manually building vala-native first eina-native built fine too
Nov 29 13:57:38 <Ainulindale> Plus unit testing isn't so difficult
Nov 29 13:57:49 <Ainulindale> Maybe you should write templates for unit tests and apply them as a pre-commit action
Nov 29 13:58:09 <JaMa> mrmoku: weird eina-native is using vala?
Nov 29 13:58:43 <Ainulindale> (plus vala sucks)
Nov 29 13:59:02 <JaMa> heh :)
Nov 29 13:59:32 <Ainulindale> The worst is: I'm not joking
Nov 29 13:59:46 <mrmoku> JaMa: seems to need vala.m4
Nov 29 14:00:40 <JaMa> mrmoku: ah, it's probably race in handling m4
Nov 29 14:00:50 <JaMa> I've seen it with different combinations already :/
Nov 29 14:00:50 <mrmoku> yup
Nov 29 14:01:04 <mrmoku> has seen it in one moment and then it went away
Nov 29 14:01:26 <JaMa> only OE thinks eina wants vala.m4
Nov 29 14:03:27 <mrmoku> JaMa: what do we do with elsa? 
Nov 29 14:05:13 <JaMa> I've arrived too late yesterday to test it.. I hope today.. but first I need to get keysyms read by systemd so I can setup networking and launch elsa..
Nov 29 14:08:48 <mrmoku> JaMa: just launching it does not work for  me
Nov 29 14:09:04 <mrmoku> well... will retry with what I'm building right now
Nov 29 15:25:49 <karl677> some interesting n900 scripts. http://meego.gitorious.org/meego-device-adaptation/n900_nokia-n900-configs/trees/78a20b45ffaf51afe07ea04f0f47ebc6fcd81143
Nov 29 15:26:37 <karl677> does shr use the same, or is it not compareable?
Nov 29 15:28:45 <mrmoku> karl677: some of those we have integrated
Nov 29 15:28:55 <mrmoku> on a fast look it is the cmt-gpio thing
Nov 29 15:28:57 <mrmoku> and the keymap
Nov 29 15:29:35 <karl677> the alsa part is nogood?
Nov 29 15:31:47 <mrmoku> karl677: alsa is a complex story
Nov 29 15:31:54 <mrmoku> first meego is using pulseaudio
Nov 29 15:31:56 <mrmoku> we don't
Nov 29 15:32:09 <mrmoku> and then our alsa for n900 is still WIP
Nov 29 15:32:14 <mrmoku> needs some love :/
Nov 29 15:32:38 <karl677> i see. 
Nov 29 15:32:49 <mrmoku> but the alsamixer-set* ones might get usefull someday
Nov 29 15:37:03 * jonwil wonders how fso-on-N900 will get around the closed source undocumented nokia pulseaudio blobs
Nov 29 15:37:17 <angelox|laptop> good afternoon people
Nov 29 15:38:55 <mrmoku> jonwil: what pulseaudio blobs should we be interested in?
Nov 29 15:39:52 <jonwil> whatever these are
Nov 29 15:39:54 <jonwil> https://build.pub.meego.com/package/files?package=pulseaudio-modules-nokia&project=CE%3AAdaptation%3AN9xx-common
Nov 29 15:40:06 <jonwil> Thats the nokia-closed pulseaudio blobs MeeGo are using
Nov 29 15:40:10 <jonwil> No clue what they are doing
Nov 29 15:40:19 <jonwil> but they must be doing something important
Nov 29 15:40:50 <mrmoku> sure? :P
Nov 29 15:40:58 <mrmoku> probably DocScrutinizer51 would know a bit more
Nov 29 15:41:45 <DocScrutinizer> hmß
Nov 29 15:41:47 <DocScrutinizer> ?
Nov 29 15:42:11 <mrmoku> DocScrutinizer: pulseaudio blobs for n900
Nov 29 15:42:28 <mrmoku> one thing was the volume limiting
Nov 29 15:42:31 <DocScrutinizer> I thought we avoid PA like devil the holy ground
Nov 29 15:42:35 <mrmoku> sure
Nov 29 15:42:40 <mrmoku> no fear :P
Nov 29 15:43:01 <jonwil> isnt speaker protection part of those blobs?
Nov 29 15:43:01 <mrmoku> just jonwil was wondering how we would implement whatever those blobs do in shr
Nov 29 15:43:02 <DocScrutinizer> XPROT?
Nov 29 15:43:41 <DocScrutinizer> XPROT is meant to get implemented by setting aic34 hw equalizer to some sane settings
Nov 29 15:44:10 <DocScrutinizer> cmtspeech got implemented in a native way here
Nov 29 15:44:50 <DocScrutinizer> policy-enforcer crap is not needed as we got a completely different concept that doesn't use PA
Nov 29 15:46:26 <jonwil> I just wish there was more info on the different things those binary blobs DO
Nov 29 15:46:41 <DocScrutinizer> indeed
Nov 29 15:48:45 <karl677> since I am a bit paranoid, I'd say remote access to microphone. without any proof or better knowledge oof course.
Nov 29 15:51:23 <mrmoku> :)
Nov 29 15:52:19 <mrmoku> maybe we should add a page to our wiki: 'What our users talk right now' ... some kind of lifestream ;)
Nov 29 15:52:56 <karl677> :)
Nov 29 16:08:44 <karl677> DocScrutinizer, aic34? like this one http://www.ti.com/litv/pdf/slas538a ? http://natisbad.org/N900/n900-commented-hardware-specs.html says it is TWL4030. or is this more or less the same thing?
Nov 29 16:19:46 <karl677> seems like alsa driver are avaible. what am I missing to understand?
Nov 29 16:25:18 <DocScrutinizer> karl677: N900 codec isn't twl4030
Nov 29 16:25:35 <DocScrutinizer> it's a 32AIC34 or sth like that
Nov 29 16:26:48 <karl677> yes, just saw it in source. tlv320aic3x and TPA6130A2
Nov 29 16:28:20 <DocScrutinizer> karl677: this codec has a digital parametric equalizer that can implement a proper hw-based XPROT-alike protection of speakers
Nov 29 16:29:02 <DocScrutinizer> basically remove too much too strong and low-freq signal components with a highpass filter
Nov 29 16:32:26 <karl677> ok, the equalizer is "too brutal" thats basically the todo for shr/fso, right?
Nov 29 16:35:08 <DocScrutinizer> sorry?
Nov 29 16:35:45 <DocScrutinizer> aah maybe I was a bit fuzzy
Nov 29 16:37:41 <DocScrutinizer> XPROT PA plugin implements some speaker protection, we assume it does some dynamics compression/limiting and also filters out low frequencies that the small speakers can't cope with. On tlv320aic34 there's an unised digital filter that can be put to purpose to do similar highpass filtering like XPROT does
Nov 29 16:37:52 <DocScrutinizer> unused*
Nov 29 16:40:38 <karl677> do you have a link to xprot? I'd try can compare it to TI's dokumentation.
Nov 29 16:42:58 <karl677> oh, or is xprot that pulse audio binary?
Nov 29 16:45:27 <DocScrutinizer> yes
Nov 29 16:45:43 <DocScrutinizer> XPROT PA plugin
Nov 29 16:45:52 <DocScrutinizer> (C) Nokia, closed
Nov 29 16:49:28 <karl677> I see. doesn't seem much of a problem, since dokumenation from TI is avaible. So basically I have to write a xprot alternative for alsa. has someone made a picture of the speaker/ micro in n900? ist there a ohm value painted on?
Nov 29 17:31:43 <karl677> yes, I'll take a closer look on alsa source. seems kind of incomplete.
Nov 29 17:48:54 <karl677> interesting. give me two weeks guys. I think, I can handle that.
Nov 29 18:07:45 <mrmoku> nice
Nov 29 18:21:08 <GNUtoo> hi mrmoku
Nov 29 19:05:59 <GNUtoo> ping mrmoku 
Nov 29 19:19:40 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r97289f918129 10/tools/mdbus2/ (configure.ac src/Makefile.am src/main.vala): 
Nov 29 19:19:40 <CIA-69> freesmartphone.org: mdbus: port to GDBus and GVariant
Nov 29 19:19:40 <CIA-69> freesmartphone.org: This requires vala master after 2011-02-07 19:38:36 (GMT)
Nov 29 19:19:40 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * rdd7d671c1485 10/tools/mdbus2/src/main.vala: mdbus2: Add support for calling methods without introspection and parameters
Nov 29 19:19:41 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r0ab47b48d254 10/tools/mdbus2/src/main.vala: mdbus2: Fix completion for interface methods
Nov 29 19:19:41 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r0cce459ed5e2 10/tools/mdbus2/src/main.vala: mdbus2: don't return immediately if we have methods for completion
Nov 29 19:19:42 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r9f25915d04d9 10/tools/mdbus2/src/main.vala: mdbus2: add support to set properties
Nov 29 19:19:42 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r50df8a7dfe82 10/tools/mdbus2/src/main.vala: mdbus2: Fix out signature for method calls
Nov 29 19:19:43 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r7e92da67ac8e 10/tools/mdbus2/configure.ac: mdbus2: update required glib version
Nov 29 19:19:43 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * rf6048472b94e 10/tools/mdbus2/src/main.vala: mdbus2: Add support for property getters
Nov 29 19:19:47 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r49ccd945d3c6 10/tools/mdbus2/src/main.vala: mdbus2: return if wrong number of arguments is specified for properties
Nov 29 19:19:47 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * rb2710372e99a 10/tools/mdbus2/src/main.vala: mdbus2: return if Variant.parse fails to parse user input
Nov 29 19:19:47 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r246309818037 10/tools/mdbus2/src/main.vala: mdbus2: Only remove signals for tab completion
Nov 29 19:19:47 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r97bcbc6846cc 10/tools/mdbus2/src/main.vala: mdbus2: Fix indentation of interface descriptions
Nov 29 19:19:48 <CIA-69> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r163d1fb84c68 10/tools/mdbus2/src/main.vala: mdbus2: Show some nice arrows pointing on the parsing errors position
Nov 29 19:19:51 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r645dfc7f5a58 10/tools/mdbus2/src/Makefile.am: 
Nov 29 19:19:53 <CIA-69> freesmartphone.org: mdbus2: enable debug build options
Nov 29 19:19:53 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:19:54 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * rdcad7cbd0cf3 10/tools/mdbus2/src/main.vala: 
Nov 29 19:19:54 <CIA-69> freesmartphone.org: mdbus2: some cleanups and enhancements to get it working probably
Nov 29 19:19:55 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:19:55 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * rfc7445a9fd10 10/tools/mdbus2/configure.ac: 
Nov 29 19:19:56 <CIA-69> freesmartphone.org: mdbus2: prepare for release of version 2.1.0
Nov 29 19:19:56 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:19:57 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r2dc5d8bb37d8 10/tools/mdbus2/NEWS: 
Nov 29 19:19:57 <CIA-69> freesmartphone.org: mdbus2: update NEWS for release of 2.1.0
Nov 29 19:20:03 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:20:03 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r9f8ac310904e 10/tools/mdbus2/ (AUTHORS src/main.vala): 
Nov 29 19:20:03 <CIA-69> freesmartphone.org: mdbus2: update mentioned authors
Nov 29 19:20:03 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:20:04 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * rbb6292136ca4 10/tools/mdbus2/README: 
Nov 29 19:20:04 <CIA-69> freesmartphone.org: mdbus2: update README
Nov 29 19:20:05 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:20:05 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r900c0ffb861e 10/fsodeviced/src/lib/ (Makefile.am dispatcher.vala): 
Nov 29 19:20:06 <CIA-69> freesmartphone.org: fsodeviced: lib: remove unused and empty dispatcher class
Nov 29 19:20:06 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:20:24 <morphis> sorry for the noise ...
Nov 29 19:20:25 <morphis> heyho
Nov 29 19:20:26 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r9efa6cb59fed 10/fsodeviced/ (7 files in 4 dirs): 
Nov 29 19:20:26 <CIA-69> freesmartphone.org: fsodeviced: merge proximity_palmpre plugin into palmpre_quirks plugin
Nov 29 19:20:26 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:20:26 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r746c61d14b47 10/fsodeviced/ (8 files in 5 dirs): 
Nov 29 19:20:27 <CIA-69> freesmartphone.org: fsodeviced: rework gta04_powercontrol plugin into a gta04_quirks plugin
Nov 29 19:20:27 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:20:28 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * rb9f046789a24 10/fsodeviced/AUTHORS: 
Nov 29 19:20:28 <CIA-69> freesmartphone.org: fsodeviced: add myself as author
Nov 29 19:20:29 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:21:26 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r44a6ccb140ba 10/fsodeviced/ (4 files in 4 dirs): 
Nov 29 19:21:26 <CIA-69> freesmartphone.org: fsodeviced: move 3rdparty folder into the src directory where it should be
Nov 29 19:21:26 <CIA-69> (14 lines omitted)
Nov 29 19:21:30 <CIA-69> SHR: 03morphis 07meta-smartphone * rf3bd874dc042 10/meta-fso/recipes-freesmartphone/freesmartphone/fsodeviced_git.bb: meta-fso: fsodeviced: drop proximity-palmpre packages as it is now part of palmpre-quirks plugin
Nov 29 19:21:40 <CIA-69> SHR: 03morphis 07meta-smartphone * ra8228db08c7e 10/meta-fso/recipes-freesmartphone/freesmartphone/cornucopia.inc: cornucopia: bump SRCREV
Nov 29 19:24:08 <GNUtoo-desktop> morphis, hi
Nov 29 19:24:24 <GNUtoo-desktop> was it you that bumped vala?
Nov 29 19:25:09 <morphis> GNUtoo-desktop: yes
Nov 29 19:25:11 <morphis> why?
Nov 29 19:25:45 <GNUtoo-desktop> I suspect that it's the cause of libfsotransport breakage that broke my freerunner telephony during 3 days
Nov 29 19:25:56 <GNUtoo-desktop> and it's still broken
Nov 29 19:26:07 <GNUtoo-desktop> only that I scp-ed an old libfsotransport
Nov 29 19:26:08 <morphis> can you give me some details?
Nov 29 19:26:22 <GNUtoo> I've not enough details yet
Nov 29 19:26:41 <GNUtoo> if I use the newer libfsotransport it fails to open the modem
Nov 29 19:26:41 <morphis> ok but what does you tell that it is broken?
Nov 29 19:26:45 <morphis> ok
Nov 29 19:26:48 <GNUtoo> let me finish
Nov 29 19:26:52 <GNUtoo> if I use the newer libfsotransport it fails to open the modem
Nov 29 19:26:54 <morphis> aye
Nov 29 19:27:05 <GNUtoo> I suspect that it doesn't see a response to what it sends
Nov 29 19:27:13 <GNUtoo> then I revert to an older rev:
Nov 29 19:27:18 <GNUtoo> it still fails the same way
Nov 29 19:27:20 <GNUtoo> but....
Nov 29 19:27:29 <GNUtoo> if I take the same exact older rev built before it works
Nov 29 19:27:34 <GNUtoo> so maybe it's vala?
Nov 29 19:27:38 <morphis> maybe
Nov 29 19:27:40 <GNUtoo> or could it be something else?
Nov 29 19:27:51 <morphis> it's hard to say
Nov 29 19:28:30 <GNUtoo> anyway having the phone broken during a period that long is unacceptable, I use that phone daily
Nov 29 19:28:50 <GNUtoo> here:
Nov 29 19:28:51 <GNUtoo> http://wiki.freesmartphone.org/index.php/FSOSHRCON_2011
Nov 29 19:29:00 <GNUtoo> I've added a Topic part
Nov 29 19:29:15 <GNUtoo> that should be discussed in december
Nov 29 19:29:33 <GNUtoo> I guess that if that can't be addressed in the long term I'll finish by quiting
Nov 29 19:29:44 <morphis> very good point
Nov 29 19:29:49 <GNUtoo> s/I'll finish by/I'll end up by/
Nov 29 19:29:49 <apt> GNUtoo meant: I guess that if that can't be addressed in the long term I'll end up by quiting
Nov 29 19:29:55 <GNUtoo> s/by//
Nov 29 19:29:55 <apt> GNUtoo meant: I guess that if that can't be addressed in the long term I'll finish  quiting
Nov 29 19:29:59 <GNUtoo> bad apt
Nov 29 19:30:12 <morphis> quality and stable versions are something we missed for a long time
Nov 29 19:30:28 <GNUtoo> yes so we must think about how to achieve it
Nov 29 19:30:37 <morphis> but please add it to the agenda http://wiki.freesmartphone.org/index.php/FSOSHRCON_2011_AGENDA
Nov 29 19:30:48 <GNUtoo> it seem that Ainulindale has some idea baout htat
Nov 29 19:30:49 <morphis> GNUtoo: yes, I already started to take some notes on that
Nov 29 19:30:59 <morphis> really?
Nov 29 19:31:18 <morphis> GNUtoo: you tried libfsotransport locally with serial-forward?
Nov 29 19:31:40 <GNUtoo> no, the problem is that the lowlevel_openmoko fails
Nov 29 19:31:54 <morphis> lowlevel_openmoko?
Nov 29 19:32:24 <morphis> hm
Nov 29 19:32:26 <GNUtoo> yes fsogsmd has lowlevel plugins
Nov 29 19:32:30 <morphis> I know
Nov 29 19:32:39 <GNUtoo> that exact plugin does something like:
Nov 29 19:32:42 <GNUtoo> send AT
Nov 29 19:32:45 <GNUtoo> wait for a response
Nov 29 19:32:45 <morphis> I was somethine like "lowlevel_openmoko really?"
Nov 29 19:32:50 <morphis> yes I see
Nov 29 19:33:06 <GNUtoo> just to check that the link works
Nov 29 19:33:11 <GNUtoo> and of course it fails
Nov 29 19:33:17 <morphis> ok, can you open a bug report in FSO trac?
Nov 29 19:33:37 <GNUtoo> and it's libfsotransport that transports that
Nov 29 19:33:40 <GNUtoo> ok
Nov 29 19:33:41 <morphis> I will start to build the relevant parts here for the om-gta02 to fix that bug
Nov 29 19:33:43 <morphis> yeah
Nov 29 19:33:56 <morphis> but there are several things involved
Nov 29 19:34:09 <morphis> we really need some automatic test application
Nov 29 19:34:11 <GNUtoo> replacing libfsotransport breaks or repairs it
Nov 29 19:34:14 <GNUtoo> indeed
Nov 29 19:34:20 <morphis> more than everything else
Nov 29 19:34:37 <GNUtoo> we cannot expect to have users anymore with the current state
Nov 29 19:34:55 <GNUtoo> and the same for new developers
Nov 29 19:35:07 <GNUtoo> so if we fails with QA, all devs will leave at some point
Nov 29 19:35:15 <GNUtoo> some sooner, some later
Nov 29 19:35:30 <morphis> yes
Nov 29 19:35:38 <GNUtoo> sorry
Nov 29 19:35:42 <morphis> but there are several levels of QA, on SHR and FSO side
Nov 29 19:35:48 <GNUtoo> ctrl+w on xchat instead of browser
Nov 29 19:35:51 <GNUtoo> ok
Nov 29 19:35:52 <morphis> I can and will keep only about QA on FSO side
Nov 29 19:35:55 <morphis> :)
Nov 29 19:35:58 <GNUtoo> we also depend on instable stuff
Nov 29 19:36:00 <GNUtoo> which is bad
Nov 29 19:36:15 <GNUtoo> to name a few: vala, enlightenment etc...
Nov 29 19:36:44 <morphis> some other good point, yes
Nov 29 19:36:47 <morphis> and OE too
Nov 29 19:36:56 <GNUtoo> oe I'm not sure
Nov 29 19:37:06 <GNUtoo> because maybe oe-core will become better
Nov 29 19:37:09 <GNUtoo> not sure
Nov 29 19:37:34 <GNUtoo> but in the past and in the early part of the transition to oe-core it was very unstable
Nov 29 19:40:03 <morphis> yes
Nov 29 19:40:07 <morphis> it is better now
Nov 29 19:40:19 <morphis> but we have still many aspects and in development phase
Nov 29 19:40:22 <morphis> nothing is stable
Nov 29 19:40:25 <GNUtoo> ok
Nov 29 19:40:32 <morphis> same is for community things on FSO side
Nov 29 19:40:38 <GNUtoo> ok
Nov 29 19:40:38 <morphis> wiki/trac/git concept is broken
Nov 29 19:41:02 <GNUtoo> I've added the topic in the agenda
Nov 29 19:41:05 <GNUtoo> now the bugreport
Nov 29 19:41:06 <morphis> I am currently thinking about giving FSO a new homepage as consists of a single trac site
Nov 29 19:41:09 <morphis> ok
Nov 29 19:41:38 <GNUtoo> we need a logo btw
Nov 29 19:41:46 <GNUtoo> I suspect that the logo is not very legal
Nov 29 19:42:08 <GNUtoo> ( the one on http://www.freesmartphone.org/ )
Nov 29 19:43:53 <morphis> hm
Nov 29 19:44:02 <morphis> a logo is another good point
Nov 29 19:44:19 <morphis> my problem currently is that I don't have much time to be online in IRC for example
Nov 29 19:44:25 <GNUtoo> ok
Nov 29 19:44:36 <morphis> it's getting better next year starting april
Nov 29 19:44:38 <GNUtoo> even a bad logo with F S O letters would do
Nov 29 19:44:52 <GNUtoo> maybe we could include a phone in the O tough
Nov 29 19:45:03 <GNUtoo> personally I'll start working very soon
Nov 29 19:45:12 <morphis> really?
Nov 29 19:45:12 <GNUtoo> but that's good since it'll give me more time
Nov 29 19:45:13 <morphis> where?
Nov 29 19:45:21 <GNUtoo> since I'll drop 1 course
Nov 29 19:45:27 <GNUtoo> and start working part time
Nov 29 19:45:43 <GNUtoo> same as before but in italy
Nov 29 19:45:59 <GNUtoo> (work trough the internet)
Nov 29 19:47:10 <morphis> ah ok
Nov 29 19:48:18 <morphis> I am away for some minutes
Nov 29 19:48:23 <GNUtoo> ok
Nov 29 19:48:26 <GNUtoo> I'll do the bugreport
Nov 29 19:49:52 <GNUtoo> btw it's not just me that has telephony broken
Nov 29 19:49:58 <GNUtoo> it's on the shr official feeds too
Nov 29 19:50:09 <GNUtoo> for instance mrmoku saw the same thing
Nov 29 19:52:08 <CIA-69> freesmartphone.org: 03morphis 07cornucopia * r76799b0459ad 10/fsogsmd/src/3rdparty/conversions.h: 
Nov 29 19:52:09 <CIA-69> freesmartphone.org: fsogsmd: 3rdparty: add missing prototypes
Nov 29 19:52:09 <CIA-69> freesmartphone.org: This is based on a patch from Colin Watson <cjwatson@ubuntu.com> attached to FSO bug
Nov 29 19:52:09 <CIA-69> freesmartphone.org: report #656. It's also tracked in debian bug report system as #648447. Both bugs are fixed
Nov 29 19:52:09 <CIA-69> freesmartphone.org: with this commit.
Nov 29 19:52:09 <CIA-69> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Nov 29 19:59:22 <karl927> DocScrutinizer: is the needed highpass filter for n900 for only for output? speaker or headphones or both?
Nov 29 20:02:18 <lindi-> speaking of filters, gnuradio seems fun
Nov 29 20:06:14 <DocScrutinizer> karl927: speakers only
Nov 29 20:06:25 <karl927> LOP_A, LOM_A (right, left) I asume.
Nov 29 20:13:38 <karl927> there is a -3db highpass filter in aic34, could be enabled in alsa. might already be in source.
Nov 29 20:14:45 <GNUtoo-desktop> lindi-, you have an USRP?
Nov 29 20:15:00 <lindi-> GNUtoo-desktop: at work yes
Nov 29 20:15:12 <lindi-> possibly more than one soon
Nov 29 20:15:33 <GNUtoo-desktop> wow
Nov 29 20:15:37 <GNUtoo-desktop> where do you work?
Nov 29 20:16:21 <lindi-> GNUtoo-desktop: www.metsahovi.fi
Nov 29 20:17:04 * GNUtoo-desktop worked this summer for a company to get the money to buy an USRP to do developement work for osmocombb but that failed since I cannot get GSM test license in italy
Nov 29 20:17:40 <GNUtoo-desktop> wow
Nov 29 20:18:02 * GNUtoo-desktop is still looking for the perfect job
Nov 29 20:18:11 <lindi-> GNUtoo-desktop: can't you somehow connect the phone to the USRP directly without using antennas?
Nov 29 20:18:48 <GNUtoo-desktop> lindi-, maybe with very low power emmisions ....
Nov 29 20:18:56 <GNUtoo-desktop> altough it wouldn't be that legal either
Nov 29 20:19:15 <lindi-> GNUtoo-desktop: hmm, if you don't transmit anything but use shielded wire then it should be?
Nov 29 20:19:23 <GNUtoo-desktop> ok
Nov 29 20:19:25 <GNUtoo-desktop> possible
Nov 29 20:20:08 <lindi-> GNUtoo-desktop:  doesn't openmoko even have a connector for that?
Nov 29 20:20:10 <GNUtoo-desktop> what model of the USRP do you have access to?
Nov 29 20:20:13 <GNUtoo-desktop> yes it does
Nov 29 20:20:15 <lindi-> GNUtoo-desktop:  N210
Nov 29 20:20:19 <GNUtoo-desktop> ok nice
Nov 29 20:20:26 <GNUtoo-desktop> so the best one
Nov 29 20:20:32 <GNUtoo-desktop> how is it?
Nov 29 20:20:53 <GNUtoo-desktop> I really wonder, if I buy the one that costs less money, will it still work?
Nov 29 20:20:57 <GNUtoo-desktop> I need GPS tough
Nov 29 20:21:00 <GNUtoo-desktop> *GPS clock
Nov 29 20:21:08 <lindi-> GNUtoo-desktop: I've only looked at it since last week. my first impression is that there are a lot of moving pieces in software radio that can be misconfigured :)
Nov 29 20:21:17 <GNUtoo-desktop> ok
Nov 29 20:21:23 <lindi-> GNUtoo-desktop: I dumped some photos and notes to   http://www.metsahovi.fi/howto/usrp/
Nov 29 20:21:24 <GNUtoo-desktop> btw do you know the E series?
Nov 29 20:22:26 <lindi-> GNUtoo-desktop: not really, I'm not that much of a hardware person. just trying to make the software work for the RF people
Nov 29 20:22:39 <lindi-> GNUtoo-desktop: I think we need to have uhd in debian
Nov 29 20:23:11 <GNUtoo-desktop> ok
Nov 29 20:23:40 <GNUtoo-desktop> Is UHD in ubuntu(and so trisquel) ?
Nov 29 20:23:47 <lindi-> GNUtoo-desktop: nope
Nov 29 20:23:50 <GNUtoo-desktop> ouch
Nov 29 20:23:54 <GNUtoo-desktop> that's bad
Nov 29 20:24:24 <lindi-> GNUtoo-desktop: well ubuntu inherits gnuradio directly from debian too afaik
Nov 29 20:24:33 <GNUtoo-desktop> ok
Nov 29 20:24:33 <lindi-> GNUtoo-desktop: so when we add uhd to debian it'll be in ubuntu
Nov 29 20:24:49 <GNUtoo-desktop> and then in trisquel one version after it goes into ubuntu
Nov 29 20:25:02 <lindi-> GNUtoo-desktop: you can always backport
Nov 29 20:25:07 <GNUtoo-desktop> ok
Nov 29 20:25:42 <lindi-> anyways, the whole uhd + gnuradio combination seems to be quite actively developed, it took a while to understand what's going on
Nov 29 20:25:44 <GNUtoo-desktop> btw what can't you do with the newer USB version?
Nov 29 20:25:57 <lindi-> GNUtoo-desktop: well USB is limited to 480 Mbps
Nov 29 20:25:58 <GNUtoo-desktop> that you can do with the more powerfull E210
Nov 29 20:26:09 <GNUtoo-desktop> yes but pratically speaking:
Nov 29 20:26:16 <GNUtoo-desktop> for instance you can't do wifi
Nov 29 20:26:24 <GNUtoo-desktop> or you can't talk to the ISS
Nov 29 20:26:30 <GNUtoo-desktop> or you can't use openBTS
Nov 29 20:26:49 <lindi-> GNUtoo-desktop: we are mostly going to use this to monitor certain bands for radio interference
Nov 29 20:26:57 <GNUtoo-desktop> ok
Nov 29 20:27:02 <lindi-> GNUtoo-desktop: so we want maximum bandwidth to be able to scan them as fast as possible
Nov 29 20:27:10 <GNUtoo-desktop> ok
Nov 29 20:27:36 <lindi-> last summer we spent weeks trying to find a problem. it turned out to be a new LED light bulb
Nov 29 20:27:37 <GNUtoo-desktop> like fft on large bands?
Nov 29 20:27:46 <GNUtoo-desktop> lol
Nov 29 20:27:53 <GNUtoo-desktop> interesting job...
Nov 29 20:28:15 <lindi-> GNUtoo-desktop: yeah it seems LED lights are sometimes problematic
Nov 29 20:28:44 <GNUtoo-desktop> I meant that you do cool stuff + don't have anything to do with non-free software
Nov 29 20:28:45 <lindi-> GNUtoo-desktop: maybe you heard that in Finland (is it the whole EU?) you can't sell normal light bulbs anymore :)
Nov 29 20:28:58 <GNUtoo-desktop> ah right
Nov 29 20:29:09 <lindi-> GNUtoo-desktop: well the fpga firmware used in N210 still can't be compiled with any free compiler
Nov 29 20:29:20 <lindi-> GNUtoo-desktop: so we have source code to the firmware but no compiler
Nov 29 20:29:27 <GNUtoo-desktop> but are the new light bulbs safe? or do they explode because they come from some factory in china?
Nov 29 20:29:39 <GNUtoo-desktop> ok
Nov 29 20:29:57 <GNUtoo-desktop> or create fires
Nov 29 20:30:03 <lindi-> GNUtoo-desktop: I don't they are unsafe, LEDs are usually cool
Nov 29 20:30:14 <GNUtoo-desktop> ok
Nov 29 20:30:31 <GNUtoo-desktop> yes leds are cool
Nov 29 20:31:09 <lindi-> "Some jurisdictions, such as the European Union, are in the process of phasing out the use of incandescent light bulbs in favor of more energy-efficient lighting." -- http://en.wikipedia.org/wiki/Incandescent_light_bulb#Measures_to_ban_its_use
Nov 29 20:32:03 <GNUtoo-desktop> so we have replacement that works at least as good as the old light bulbs?
Nov 29 20:32:29 <GNUtoo-desktop> I was told the contrary but the person telling me that is not that aware of technology
Nov 29 20:32:30 <lindi-> GNUtoo-desktop: well LEDs?
Nov 29 20:32:37 <GNUtoo-desktop> like white-leds
Nov 29 20:32:53 <GNUtoo-desktop> how efficent are they btw? 99% light?
Nov 29 20:33:04 <lindi-> GNUtoo-desktop:   http://en.wikipedia.org/wiki/Phase-out_of_incandescent_light_bulbs seems to have some info
Nov 29 20:33:23 <lindi-> GNUtoo-desktop: and again, I'm not a hardware person :)
Nov 29 20:33:35 <GNUtoo-desktop> ok
Nov 29 20:33:48 <lindi-> GNUtoo-desktop: I just deal with the fallout caused by somebody replacing some light bulbs without verifying that they don't cause RF interference
Nov 29 20:34:02 <GNUtoo-desktop> ok
Nov 29 20:35:21 <morphis> so I am back
Nov 29 20:35:26 <morphis> GNUtoo: you opened the bug?
Nov 29 20:35:30 <GNUtoo-desktop> not yet
Nov 29 20:35:33 <GNUtoo-desktop> I was compiling
Nov 29 20:35:37 <GNUtoo-desktop> to install the new version
Nov 29 20:35:45 <GNUtoo-desktop> to bugreport with the lastest source
Nov 29 20:37:09 <morphis> ah ok
Nov 29 20:37:11 <morphis> thats great
Nov 29 20:38:06 <morphis> I am at 2339 of 4126 packges build for om-gta02
Nov 29 20:38:13 <morphis> so expect testing me this tomorrow
Nov 29 20:39:06 <GNUtoo-desktop> ok
Nov 29 20:42:10 <GNUtoo-desktop> morphis, one more thing:
Nov 29 20:42:22 <GNUtoo-desktop> did you push your devshell?
Nov 29 20:53:24 <morphis> GNUtoo-desktop: no, I didn't had time for this
Nov 29 20:54:33 <morphis> GNUtoo-desktop: wait a moment
Nov 29 20:55:16 <karl927> DocScrutinizer: if the codec filters before reaching class-d amp it should be fine, shouldn't it?
Nov 29 20:55:57 <DocScrutinizer> yup
Nov 29 20:57:27 <morphis> GNUtoo: I have one problem with devshell.bb
Nov 29 20:57:35 <morphis> GNUtoo: in OE-classic it claims to be GPL
Nov 29 20:57:49 <morphis> but thats wrong
Nov 29 20:58:16 <morphis> the recipe can't be GPL as OE is MIT and devshell uses code OE generates
Nov 29 20:58:54 <karl927> Well, I found the register, in alsa handling it. i know the neccassary value. but I am not that good at C yet. there is a const offset in that part of alsa, doesn't seem right.
Nov 29 21:01:50 <GNUtoo> GPL and MIT are compatible
Nov 29 21:02:18 <GNUtoo> so it can be GPL
Nov 29 21:03:00 <karl927> the important lines are 222-223 and 244 ( http://git.freesmartphone.org/?p=linux-2.6.git;a=blob;f=sound/soc/codecs/tlv320aic3x.c;h=789453d44ec5d212d2974d8c1db28dc95b81b52f;hb=refs/heads/nokia900/n9xx-v3.0-wip-rx51-camera )
Nov 29 21:04:05 <GNUtoo> karl927, we use 2.6.37 currently
Nov 29 21:04:20 <GNUtoo> because the 3.0 lacks the modem
Nov 29 21:05:11 <karl927> ok, didn't look into 2.6.37. is this part of alsa missing there?
Nov 29 21:06:48 <GNUtoo> no idea
Nov 29 21:06:54 <karl927> the register is on page 57 ( http://www.ti.com/litv/pdf/slas538a )
Nov 29 21:07:19 <karl927> d7-d4
Nov 29 21:10:07 <GNUtoo> morphis, btw did you write to mark brown?
Nov 29 21:10:20 <karl927> line 116-123 describes line 244 in kernel source http://www.mjmwired.net/kernel/Documentation/sound/alsa/soc/codec.txt
Nov 29 21:10:20 <GNUtoo> I don't want to do it because I broke the speakers
Nov 29 21:14:16 <GNUtoo> it's there
Nov 29 21:14:20 <GNUtoo> in alsamixer there is:
Nov 29 21:14:29 <GNUtoo> ADC HPF Cut-off
Nov 29 21:14:31 <GNUtoo> values are:
Nov 29 21:14:37 <GNUtoo> Disabled
Nov 29 21:14:48 <GNUtoo> 0.0045xFs
Nov 29 21:15:02 <GNUtoo> 0.0125xFs
Nov 29 21:15:12 <GNUtoo> 0.0025xFs
Nov 29 21:15:20 <GNUtoo> oops
Nov 29 21:15:28 <GNUtoo> I meant
Nov 29 21:15:30 <GNUtoo> Disabled
Nov 29 21:15:41 <GNUtoo> 0.0045xFs
Nov 29 21:15:51 <GNUtoo> 0.0125xFs
Nov 29 21:16:15 <GNUtoo> 0.025xFs
Nov 29 21:16:30 <GNUtoo> nschle85, hi
Nov 29 21:16:38 <nschle85> hi
Nov 29 21:16:48 <GNUtoo> karl927, will have an or has an n900
Nov 29 21:17:06 <GNUtoo> he is willing to do device adaptation
Nov 29 21:17:09 <GNUtoo> morphis_, hi
Nov 29 21:17:16 <GNUtoo> morphis_, :
Nov 29 21:17:28 <GNUtoo> GPL and MIT *are* compatible
Nov 29 21:17:54 <GNUtoo> morphis_, did you write to mark brown yet, I cannot do it myself, it would look like a complain
Nov 29 21:18:02 <GNUtoo> (since I broke the speaker)
Nov 29 21:20:00 <karl927> no n900 yet, waiting for delivery service. I think, friday or monday.
Nov 29 21:20:47 <GNUtoo> karl927,  about the register, what value should it be set to?
Nov 29 21:21:02 <GNUtoo> karl927, could you do a patch for the states files?
Nov 29 21:22:54 <karl927> I think, 0.025xFs should be the safest one.
Nov 29 21:23:10 <GNUtoo> ok
Nov 29 21:23:20 <GNUtoo> then you should send a patch that fixes the state files for that
Nov 29 21:23:35 <karl927> about patch, not yet. haven't read about patching.
Nov 29 21:23:55 <karl927> where are the state files?
Nov 29 21:24:13 <GNUtoo> basically on the device(which you don't have yet) they are here:
Nov 29 21:25:05 <GNUtoo> /etc/freesmartphone/conf/NokiaRX-51board/alsa-default
Nov 29 21:25:13 <GNUtoo> and on the source repositories:
Nov 29 21:27:05 <GNUtoo> fsodeviced/conf/nokia_n900 in git://git.freesmartphone.org/cornucopia.git
Nov 29 21:27:22 <GNUtoo> ( http://git.freesmartphone.org/?p=cornucopia.git;a=summary  for viewing online )
Nov 29 21:28:34 <DocScrutinizer> karl927: 0,025 * Fsampling will result in sth like, hmm, mickeymouse. At least when using usual samplefreq of 48k
Nov 29 21:28:53 <DocScrutinizer> or 44.1k
Nov 29 21:30:42 <karl927> DocScrutinizer, right filters everything below 1200hz.
Nov 29 21:31:07 <DocScrutinizer> you probably don't want to do this
Nov 29 21:33:20 <karl927> what is the lowest output 8000hz? than 0.0125xFs should be ok.
Nov 29 21:34:56 <DocScrutinizer> sorry?
Nov 29 21:35:27 <JaMa> mrmoku: ping
Nov 29 21:35:38 <DocScrutinizer> the lowest output? phone bandwidth usually attributed as 400..4000Hz
Nov 29 21:36:31 <DocScrutinizer> with lower cutoff freq >400Hz not even speech is transferable via that channel
Nov 29 21:37:17 <DocScrutinizer> so you probably wnat to use sth like -3dBm@300Hz for speaker protection
Nov 29 21:38:23 <GNUtoo> basically Line+Line DAC + TPA6130A2 are the *missing* control to make headphone works
Nov 29 21:38:59 <DocScrutinizer>  ~0.0045 * 48000
Nov 29 21:39:00 <apt> 216
Nov 29 21:39:33 <karl927> 400..4000hz? speech output shouldn't be lower than 8khz (speaker). 
Nov 29 21:39:46 <DocScrutinizer> err wut?
Nov 29 21:40:31 <DocScrutinizer> speech of whom? a mouse?
Nov 29 21:41:33 <DocScrutinizer> I suspect a translation problem here
Nov 29 21:43:12 <DocScrutinizer> http://en.wikipedia.org/wiki/Audio_frequency
Nov 29 21:43:21 <karl927> yes. I know what you mean. in case of 48000 * 0.0045 is the best quality, but in case of 8000 x 0.0045 the filter doesn't protect the speaker anymore, I think.
Nov 29 21:45:17 <nschle85> hello, i have a git problem., after http://git.shr-project.org/git/?p=meta-smartphone.git;a=blobdiff;f=meta-fso/recipes-freesmartphone/freesmartphone/cornucopia.inc;h=2953730f8e2b2b2ca52fb3f54a3ca6633ec6d018;hp=3c278eda069cb048d3871ea384c46f48ab7da69c;hb=a8228db08c7e7c18b9fdb2ce773cd517127f046c;hpb=fb5ad8acff087aac044c9640ac91e3098dfca781
Nov 29 21:45:39 <nschle85> i get fatal: reference is not a tree: fa4be12a6171b445b70f87652441e935e7d34b23
Nov 29 21:46:33 <DocScrutinizer> karl927: that's what the other settings are for, though you usually don't use a sampling frequency of 8000samples/s for audio output, it sounds crappy even for speech
Nov 29 21:48:16 <JaMa> nschle85: your checkout in downloads is broken somehow
Nov 29 21:48:18 <DocScrutinizer> and quite usually the interface from SoC via mixer to amp is always running either on 44.1k or 48k
Nov 29 21:48:24 <JaMa> nschle85: try to git pull in it or remove it completely
Nov 29 21:48:34 <nschle85> ok
Nov 29 21:49:24 <DocScrutinizer> if you use lower sampling rate media files then ALSA will upsample to meet that standard sampling rate of 44.1k
Nov 29 21:50:13 <karl927> DocScrutinizer: then 0.0045 should be good. wasn't sure about that upsampling part.
Nov 29 21:50:31 <DocScrutinizer> well, obviously you have to make sure about that
Nov 29 21:51:22 <DocScrutinizer> aplay -vv will show you what are the sampling freq used. The one at very bottom is the one used on hw audio DAC, so the relevant one for your filter setting
Nov 29 21:53:52 <zub> mrmoku: getting e (e-wm?) is a pain, it requires a bunch of other deps
Nov 29 21:54:23 <GNUtoo> mrmoku, ping
Nov 29 21:54:30 <GNUtoo> morphis__, ping
Nov 29 21:54:42 <zub> and libefreet doesn't build for me on debian testing, I had to hack the build... some libtool nastyness once again
Nov 29 21:54:53 <GNUtoo> who broke backlight?
Nov 29 21:57:15 <GNUtoo> help please
Nov 29 21:57:38 <GNUtoo> if that continues like that I'll quit *before* the FSOSHRCON
Nov 29 21:59:55 <GNUtoo> please HELP!
Nov 29 22:01:17 <lindi-> GNUtoo: is it a kernel problem?
Nov 29 22:01:23 <GNUtoo> no idea
Nov 29 22:01:28 <GNUtoo> it worked just before the update
Nov 29 22:01:33 <lindi-> GNUtoo: the update?
Nov 29 22:01:37 <GNUtoo> opkg update
Nov 29 22:01:40 <GNUtoo> opkg upgrade
Nov 29 22:01:44 <lindi-> GNUtoo: I don't use SHR but I know about kernel
Nov 29 22:01:48 <GNUtoo> ok
Nov 29 22:01:53 <lindi-> GNUtoo: I might be able to help if you could first figure out which bit causes the problem
Nov 29 22:01:54 <GNUtoo> I guess it's userspace
Nov 29 22:02:16 <lindi-> GNUtoo: should be easy to verify, just restore userland from backup and keep the kernel as it is?
Nov 29 22:02:26 <GNUtoo> lindi-, kernel was not updated I guess
Nov 29 22:02:29 <GNUtoo> let me verify
Nov 29 22:02:39 <GNUtoo> Linux om-gta02 2.6.39.4 #1 Sat Nov 19 16:22:13 CET 2011 armv4tl GNU/Linux
Nov 29 22:02:51 <GNUtoo> I just built the image
Nov 29 22:02:59 <GNUtoo> so clearly not updated
Nov 29 22:04:35 <GNUtoo> the problem is the following:
Nov 29 22:04:48 <GNUtoo> * I  need a phone that gives me enough freedom
Nov 29 22:04:59 <GNUtoo> * QTmoko has no good music player
Nov 29 22:05:05 <GNUtoo> * SHR is too bugy
Nov 29 22:05:30 <GNUtoo> * debian has only desktop-friendly environments as far as I know
Nov 29 22:05:33 <GNUtoo> so I'm screwed
Nov 29 22:06:21 <GNUtoo> I'm really really nervous right now
Nov 29 22:06:47 <GNUtoo> I've a solution tough:
Nov 29 22:06:52 <GNUtoo> replicant on gta04
Nov 29 22:06:55 <GNUtoo> that would be usable
Nov 29 22:07:42 <GNUtoo> if a decision in favor of stability is not taken I'll port replicant on the gta04
Nov 29 22:07:47 <GNUtoo> and use that as a phone
Nov 29 22:08:31 <GNUtoo> lindi-, how's debian?
Nov 29 22:08:45 <GNUtoo> because debian is kind of different for every install
Nov 29 22:08:59 <lindi-> GNUtoo: debian is what you make it be :)
Nov 29 22:09:01 <GNUtoo> so what's the most finger friendly desktop environment on debian
Nov 29 22:10:31 <lindi-> GNUtoo: possibly E17 but I don't use it
Nov 29 22:10:36 <GNUtoo> ok
Nov 29 22:10:47 <GNUtoo> what's the minimal size of microsd for installing debian?
Nov 29 22:10:53 <GNUtoo> is 2G ok?
Nov 29 22:11:02 <GNUtoo> or 512M?
Nov 29 22:11:07 <GNUtoo> or 1G?
Nov 29 22:11:10 <lindi-> GNUtoo: have you used debian before?
Nov 29 22:11:14 <GNUtoo> no
Nov 29 22:11:20 <GNUtoo> not really used
Nov 29 22:11:22 <GNUtoo> tried yes
Nov 29 22:11:34 <karl927> wouldn't go lower than 2G.
Nov 29 22:11:36 <lindi-> you might want to learn it first on some non-embedded hw
Nov 29 22:12:19 <GNUtoo> lindi-, I use a deb based system on all my computers (trisquel)
Nov 29 22:12:40 <lindi-> GNUtoo: so what's the minimal size of trisquel installation?
Nov 29 22:12:48 <GNUtoo> no idea
Nov 29 22:12:56 <GNUtoo> maybe 2G
Nov 29 22:13:17 <lindi-> that kind of question really does not make much sense since it depends on what software you want there
Nov 29 22:13:33 <GNUtoo> indeed that's why I asked, for the tipical freerunner usage
Nov 29 22:13:38 <lindi-> I use 4 GB currently
Nov 29 22:13:40 <GNUtoo> ok
Nov 29 22:13:46 <GNUtoo> because debian has manuals etc....
Nov 29 22:14:01 <karl927> http://wiki.debian.org/DebianOnFreeRunner
Nov 29 22:14:02 <GNUtoo> the problem would be to find a good music player I guess
Nov 29 22:14:17 <lindi-> GNUtoo: you need to define "good" somehow now :)
Nov 29 22:14:29 <GNUtoo> finger friendly
Nov 29 22:14:31 <GNUtoo> like intone
Nov 29 22:14:37 <lindi-> GNUtoo: well intone is in debian
Nov 29 22:14:42 <GNUtoo> wow
Nov 29 22:14:49 <lindi-> I think I told you this already :/
Nov 29 22:15:02 <GNUtoo> no, I really don't remember
Nov 29 22:15:17 <GNUtoo> you told me you used a desktop like xmms2/mpd client
Nov 29 22:15:40 <lindi-> yep I use mpd + ario
Nov 29 22:15:45 <GNUtoo> yes that
Nov 29 22:15:53 <lindi-> what I use does not restrict what you can use :)
Nov 29 22:16:15 <GNUtoo> ok
Nov 29 22:16:32 <lindi-> I prefer stability currently. I would like to have finger friendly stuff but they seem to be changing all the time
Nov 29 22:17:55 <nschle85> GNUtoo: i think PaulFertser_: also uses debian on his phone(s)
Nov 29 22:19:04 <GNUtoo> ok
Nov 29 22:20:05 <nschle85> GNUtoo: but on youtube a tutorial exists how to install debian in a chroot environment over maemo (N900)
Nov 29 22:20:36 <GNUtoo> ok, but I prefer native and freerunner
Nov 29 22:21:07 <nschle85> GNUtoo: http://wiki.maemo.org/Easy_Debian
Nov 29 22:21:18 <karl927> there seems to be some native work on n900, too http://elektranox.org/n900/todo.html
Nov 29 22:21:19 <zub> with debootstrap, geting debian in a chroot anywhere is quite easy
Nov 29 22:21:31 <GNUtoo> I know
Nov 29 22:21:46 <GNUtoo> but the n900 is not ready for beeing my phone tomorrow morning
Nov 29 22:22:21 * DocScrutinizer pets his N900
Nov 29 22:22:59 * DocScrutinizer idly waits for impact of CSSU-Testing1.1
Nov 29 22:24:30 <GNUtoo> hmmm
Nov 29 22:24:42 <GNUtoo> my 32G is in fat32 and doesn't work well with the bootloader
Nov 29 22:24:51 <GNUtoo> and all the music is in the microsd
Nov 29 22:24:56 <GNUtoo> *in taht 
Nov 29 22:25:07 <GNUtoo> and there is no NAND debian install
Nov 29 22:25:30 <GNUtoo> s/the bootloader/the 2.6.39 kernel
Nov 29 22:29:49 <karl927> would a linux partition on card help? you could resize fat32, maybe.
Nov 29 22:29:58 <GNUtoo> that's too long to do
Nov 29 22:30:08 <GNUtoo> I need the phone for tomorrow 
Nov 29 22:30:12 <GNUtoo> and I need to go to bed
Nov 29 22:30:54 <nschle85> GNUtoo: good night
Nov 29 22:30:55 <karl927> is there no older, more stable image to flash?
Nov 29 22:31:12 <lindi-> GNUtoo: sometimes you  need to pay more to get free software (in this case another SD)
Nov 29 22:31:46 <GNUtoo> lindi-, that's not a problem, it's just that it's 11:28 here
Nov 29 22:32:11 <GNUtoo> how long is the debian install?
Nov 29 22:32:47 <lindi-> GNUtoo: I installed in 2009 or so
Nov 29 22:33:05 <lindi-> GNUtoo: unstable changes every day, hard to predict. 2 hours?
Nov 29 22:33:25 <lindi-> surely it is cheaper to buy a new SD card than to spend 10 hours to learn a new distribution
Nov 29 22:33:29 <karl927> http://wiki.openmoko.org/wiki/Debian says 90 min
Nov 29 22:33:56 <GNUtoo> that's way too long
Nov 29 22:34:11 <GNUtoo> I'm screwed then
Nov 29 22:34:23 <GNUtoo> because I don't know how to call contacts in QTMOKO
Nov 29 22:34:26 <GNUtoo> SHR fails to work
Nov 29 22:34:37 <GNUtoo> identifying an old good revision would take time
Nov 29 22:34:46 <lindi-> you are not really being productive here :/
Nov 29 22:34:56 <GNUtoo> ?
Nov 29 22:35:42 <lindi-> GNUtoo: it'd be helpful to at least refer to bug report
Nov 29 22:35:59 <lindi-> "SHR fails to work" is not very useful since I don't know what version of SHR or how it fails
Nov 29 22:36:02 <GNUtoo> I've a bugreport
Nov 29 22:36:05 <lindi-> especially since I don't use SHR
Nov 29 22:36:35 <GNUtoo> but I really need to go to bed
Nov 29 22:36:37 <GNUtoo> I'm sorry
Nov 29 22:36:41 <lindi-> ok then it might be a good idea to always link to it when you mention it, maybe somebody will recognize it
Nov 29 22:36:46 <karl927> were the problems with august unstable http://build.shr-project.org/shr-unstable/images/om-gta02/
Nov 29 22:36:46 <lindi-> ok
Nov 29 22:36:58 <GNUtoo> I've failed at making it appera correctly tough
Nov 29 22:37:09 <GNUtoo> http://trac.freesmartphone.org/ticket/657
Nov 29 22:37:16 <GNUtoo> I forgott to use {{{ }}}
Nov 29 22:37:54 <lindi-> yeah completely unreadable
Nov 29 22:37:59 <GNUtoo> indeed
Nov 29 22:38:06 <GNUtoo> and I don't find how to edit it
Nov 29 22:38:34 <lindi-> I don't think trac.freesmartphone.org lets you do that
Nov 29 22:38:40 <GNUtoo> ok
Nov 29 22:38:43 <lindi-> one of the few advantages of bugs.debian.org I guess :))
Nov 29 22:39:06 <GNUtoo> ah? weren't debian bugreports made trough mail?
Nov 29 22:39:21 <lindi-> GNUtoo: yep but you can manipulate them over email
Nov 29 22:39:28 <GNUtoo> ok
Nov 29 22:39:28 <lindi-> GNUtoo: to fix a typo in the original report for example
Nov 29 22:39:39 <lindi-> anyways, your issue reminds me why I still use frameworkd e6c36e917cc75809f60fa587b68bbf6be0c5bf58 from more than a year ago
Nov 29 22:39:45 <lindi-> as listed in http://wiki.openmoko.org/wiki/User:Lindi
Nov 29 22:39:50 <GNUtoo> ok
Nov 29 22:40:43 <DocScrutinizer> GNUtoo: probably better redo the whole ticket, rather than hoping for editing it
Nov 29 22:40:56 <GNUtoo> ok
Nov 29 22:41:18 <DocScrutinizer> aiui deleting a ticket is somewhat feasible
Nov 29 22:41:28 <DocScrutinizer> or voiding it
Nov 29 22:41:35 <DocScrutinizer> for the admin
Nov 29 22:41:50 <GNUtoo> ok I deleted it (invalid)
Nov 29 22:41:59 <DocScrutinizer> good enough
Nov 29 22:42:06 <lindi-> that'll delete the list of subscribers though
Nov 29 22:43:03 <DocScrutinizer> who wants to subscribe to a garbled ticked?
Nov 29 22:44:44 <lindi-> I considered that :)
Nov 29 22:51:06 <GNUtoo> http://trac.freesmartphone.org/ticket/658
Nov 29 22:51:08 <GNUtoo> morphis_, hi
Nov 29 22:51:28 <GNUtoo> morphis_, did you saw what I said about GPL+MIT and about mark brown?
Nov 29 23:42:34 <antrik> lindi-: LED bulbs are not really cool. they are somewhat more efficient than incadescent bulbs, but the bulk of energy is still transferred to heat. in fact cooling is one of the major challenges for high-power LED lights AFAIK...
Nov 30 00:12:16 <DocScrutinizer> antrik: yes, some LED bulbs are filled with water or oil to improve cooling
Nov 30 00:13:19 <DocScrutinizer> anyway all modern traffic lights are equipped with LED. So it seems it's slowly getting usual
Nov 30 00:13:33 <DocScrutinizer> and those traffic lights are pretty good I'd say
Nov 30 00:18:05 <antrik> indeed, for traffic lights (or any application where you actually want monochromatic light), LEDs are vastly superior
Nov 30 00:18:49 <antrik> for room lighting, they are actually rather crappy. you want a full spectrum for that, and AFAIK LEDs are even worse than fluorescent lights
Nov 30 00:45:50 <DocScrutinizer> yes, terrible. A *huge* narrow blue-violet spike, backed up with a yellowish-orange fluorescent component
Nov 30 00:46:51 <DocScrutinizer> no real green components at all
Nov 30 00:47:09 <DocScrutinizer> ideal for plants - well maybe
Nov 30 00:49:59 <DocScrutinizer> basically white LEDs all are blue LEDs in fact, with some pimping by special fluorescent stuff creating the other colors from the blue light
Nov 30 00:58:37 <antrik> there are RGB leds too AFAIK... but that doesn't make it much better -- still just a few spikes instead of a proper spectrum :-(
Nov 30 01:03:44 <DocScrutinizer> RGB very unusual for white LEDs. You can get some sort of white out of a usual RGB LED, and there are lamps using discrete R + G + B LED arrays
**** ENDING LOGGING AT Wed Nov 30 02:59:57 2011