**** BEGIN LOGGING AT Tue Dec 14 02:59:57 2010
Dec 14 05:54:14 <DocScrutinizer> mrmoku: the speaker filter thingie is called xprot
Dec 14 06:43:20 <mrmoku> DocScrutinizer: like this: http://alsa.opensrc.org/index.php/Low-pass_filter_for_subwoofer_channel_(HOWTO) ?
Dec 14 06:43:56 <mrmoku> can't find now xprot there hmm
Dec 14 06:47:33 <mrmoku> DocScrutinizer: ahh, under maemo and pa its called xprot?
Dec 14 06:47:44 <DocScrutinizer> yep
Dec 14 06:47:59 <mrmoku> 		x-maemo.xprot.parameters.left = hex:8c09c7004277ce8fc77f4404bc7bfa85014964a1615368e28751efa8df7fb68db6280040922de722ee8acd6b1f8bae6bff7f0020f6288f04598264002d80f00000001b89be6fc2012a040efd0000000000000000
Dec 14 06:48:03 <mrmoku> 		x-maemo.xprot.parameters.right = hex:8c09c7004277ce8fc77f4404bc7bfa85014964a1615368e28751efa8df7fb68db6280040922de722ee8acd6b1f8bae6bff7f0020f6288f04598264002d80f00000001b89be6fc2012a040efd0000000000000000
Dec 14 06:48:08 <mrmoku> ok
Dec 14 06:48:16 <DocScrutinizer> OMFG what's that?
Dec 14 06:53:24 <mrmoku> DocScrutinizer: pactl_list output 
Dec 14 06:53:45 <DocScrutinizer> *cough* pactl
Dec 14 06:53:48 <DocScrutinizer> ok
Dec 14 06:54:08 <mrmoku> what is xprot doing with temperature?
Dec 14 06:54:21 <DocScrutinizer> hehe good question
Dec 14 06:54:44 <DocScrutinizer> why?
Dec 14 06:55:45 <DocScrutinizer> I know bme has a socket or sth open to PA
Dec 14 06:56:19 <mrmoku> because it has a temperature = true parameter too... and googling I found something about ambient temperature from bme
Dec 14 06:57:00 <DocScrutinizer> I *guess* it will reduce volume when device gets too hot
Dec 14 06:59:33 <mrmoku> ahh, ok
Dec 14 07:00:08 <DocScrutinizer> what is pactl_list? you mean `pactl list` ?
Dec 14 07:00:15 <mrmoku> yep
Dec 14 07:04:29 <DocScrutinizer> yesterday I learnt to enjoy the true root causes of my hate for PA 
Dec 14 07:05:02 <mrmoku> googling braught me nice discussions with you involved from 15.6.2010
Dec 14 07:05:27 <DocScrutinizer> [http://0pointer.de/blog/projects/pulse.html]
Dec 14 07:05:29 <DocScrutinizer> Posted by Paul Davis at Tue Apr 8 22:36:03 2008
Dec 14 07:05:30 <DocScrutinizer>  Congratulations on redesigning the internals of CoreAudio :) Apple has at 
Dec 14 07:05:50 <DocScrutinizer> (discussions) where? #maemo?
Dec 14 07:06:09 <DocScrutinizer> Posted by Lennart at Tue Apr 8 23:01:23 2008
Dec 14 07:06:41 <DocScrutinizer> me: "" seems nothing has changed since 2008. It's exactly the problem twinkle has when using alsa device pulse (i.e. libalsa-Pulse) NB even the original author of the PA software recommends to stay away from PA when you got high demands regarding real time and short latency. Twinkle is doing exactly that, trying to get best latency out of ALSA. PA can not do this, according to above blog post. (also note the subtext where lennard 
Dec 14 07:06:42 <DocScrutinizer> admits he never thought about that and hasn't done any decent testing) /j
Dec 14 07:07:15 <mrmoku> DocScrutinizer: #meego-arm
Dec 14 07:07:28 <DocScrutinizer> aah, equally futile
Dec 14 07:09:19 <DocScrutinizer> polyp audio - priceless
Dec 14 07:09:59 <DocScrutinizer> NB they hope to keep binary and API compatibility, *mostly* X-P
Dec 14 07:11:16 <DocScrutinizer> I dunno what to say, except OUUUUUCH
Dec 14 07:11:35 <mrmoku> DocScrutinizer: even more interesting that nokia was going for pa to achieve low latency, no?
Dec 14 07:11:42 <DocScrutinizer> yes
Dec 14 07:14:27 <DocScrutinizer> the best part was somewhere in PolypAudio wiki, where they recommend to have avahi installed and running on all machines of your LAN, so Polyp can do some weird shit
Dec 14 07:14:44 <mrmoku> :)
Dec 14 07:15:06 <mrmoku> there are some things I like about pa though
Dec 14 07:15:29 <mrmoku> like being able to mute single applications via a nice gui
Dec 14 07:15:44 <DocScrutinizer> Up til then I was indecisive about what I hate more, avahi or Polyp. Now I know they are siamese twins for that aspect
Dec 14 07:15:46 <mrmoku> (something that my wife is using to mute the flash plugin for example)
Dec 14 07:16:40 <antrik> DocScrutinizer: I wonder whether it's a coincidence that they were both created by the same guy?... :-)
Dec 14 07:17:09 <mrmoku> probably with some alsa tweaking all of that is possible without pa too
Dec 14 07:17:10 <DocScrutinizer> mrmoku: if you're going to nuke PoA off your machines, I'm willing to post you a config that can mute single apps with mere ALSA
Dec 14 07:17:47 <mrmoku> DocScrutinizer: well... PA is giving me serious troubles too... so I would yes prefer to live without it :-)
Dec 14 07:18:00 <mrmoku> like every now and than it goes boom when I plugin my USB headset
Dec 14 07:18:10 <mrmoku> or just does ignore it
Dec 14 07:18:16 <mrmoku> nevertheless alsamixer is showing it just fine
Dec 14 07:18:26 <mrmoku> so yes... please post :-)
Dec 14 07:18:42 <DocScrutinizer> pretty simple, mompls
Dec 14 07:18:46 <mrmoku> ok
Dec 14 07:19:12 <DocScrutinizer> http://tech.groups.yahoo.com/group/twinklephone/message/1731
Dec 14 07:20:15 <mrmoku> ok, thanks
Dec 14 07:20:49 <mrmoku> btw. talking about twinkle... unchanged situation? still stalled development?
Dec 14 07:21:19 <DocScrutinizer> yep
Dec 14 07:21:56 <DocScrutinizer> though it seems some underground group moved on to sourceforge to do a forge
Dec 14 07:22:12 <mrmoku> ah
Dec 14 07:22:16 <DocScrutinizer> never ever heard about that project
Dec 14 07:22:23 <DocScrutinizer> again
Dec 14 07:22:53 <DocScrutinizer> so maybe they renamed it and have great progress with porting it to kde4/qt4
Dec 14 07:24:24 <DocScrutinizer> there's another flock of trolls that think twinkle MUST learn PolypAudio, as libalsa-Pulse doesn't support the more sophisticated snd_alsa_* calls twinkle uses
Dec 14 07:24:59 <DocScrutinizer> that's where my last msgs from yesterday took up, in above forum
Dec 14 07:25:09 <mrmoku> ok
Dec 14 07:28:12 <DocScrutinizer> for flash you'll have the problem it is using alsa:default for audio output, so you might want to wrap flashplayer or browser with a wrapper that is replacing the standard .asoundrc by a special file that has a default!.pcm definition with a slave `softvol flashvolume`
Dec 14 07:29:29 <DocScrutinizer> or you patch the flash binary to replace the string "default" by something different, and include a definition for that alsa defice to your .asoundrc
Dec 14 07:30:32 <DocScrutinizer> most problems of ALSA aren't exactly ALSA but the gashead developers that got no clue how to use ALSA
Dec 14 07:30:40 <DocScrutinizer> same shit e.g with skype
Dec 14 07:31:19 <DocScrutinizer> exactly same shit, that's where I left skype betatester group, calling them names.
Dec 14 07:32:48 <mrmoku> ok :)
Dec 14 07:33:16 <mrmoku> patching binary is out of question... before doing that I would remove it ;)
Dec 14 07:33:50 <DocScrutinizer> ehrlich, da muss der programmierer doch in der baumschule gelernt haben, um so nen string hart ins programm zu codieren
Dec 14 07:36:26 <playya> or it's intentional that nobody can change it
Dec 14 07:36:30 <DocScrutinizer> oh, now I recall: you defne default!.pcm as using a slave of $ALSADEVICE with a fallback to some sane standard when the env is undefined. So you can simply set that by `ALSADEVICE=flashvolume flashplayer` for starting e.g. flash
Dec 14 07:38:16 <DocScrutinizer> then in all usual mixer apps there will show up a softvol slider named according to that device, after you first time invoked it
Dec 14 07:39:58 <DocScrutinizer> this a only slightly more complex than the .asoundrc generated by http://tech.groups.yahoo.com/group/twinklephone/message/1731 - ping me if you really want to test it and can't figure how to set up ALSA for that
Dec 14 07:43:29 <DocScrutinizer> playya: what's the use of not allowing to change the audio output device name?
Dec 14 07:44:19 <playya> USB soundcard :)
Dec 14 07:44:23 <DocScrutinizer> I fail to see any rationale behind that being intentional
Dec 14 08:10:19 <DocScrutinizer> tbh it's mere ignoranze and sloth
Dec 14 08:11:13 <DocScrutinizer> you can redirect pcm.!default to whatever you like anyway, in ~/.asoundrc
Dec 14 08:11:28 <morphis> mickey|bbiab: ping
Dec 14 08:11:30 <DocScrutinizer> so hardcoding is just sloth, nothing else
Dec 14 08:12:45 <DocScrutinizer> plus for an app with different classes of audio-out, like skype (headset, ringer), it's absolutely braindamegd idiocy to have the same hardcoded device for both
Dec 14 08:14:30 <DocScrutinizer> well, the fact that twinkle has a dedicated audio device setting for ringer is initiated by me pushing michel de boer to implement that. So it seems knowledge about proper audio design at any level isn't very common
Dec 14 08:18:36 <DocScrutinizer> also twinkle's ability to accept arbitrary string values in audio device setup, rather than having an option to select from a dropdown list, is my concept. Otherwise such a hack like softvol wouldn't be possible at all
Dec 14 08:19:18 <DocScrutinizer> WTH??
Dec 14 08:19:38 <DocScrutinizer> freenode is split-happy today?
Dec 14 09:19:34 <mickey|office> morphis: pong
Dec 14 09:19:53 <mickey|office> ah, nevermind, ping might have been from yesterday
Dec 14 09:19:53 <morphis> mickey|office: as you may know we have now working wifi on the pre
Dec 14 09:20:05 <morphis> PuffTheMagic builds the libertas module out of compat-wireless-old
Dec 14 09:20:10 <morphis> and have modifed it a lot
Dec 14 09:20:30 <morphis> I am now thinking about how to handle this in our case for porting FSO/SHR
Dec 14 09:20:57 <morphis> is it ok we add anoter repository compat-wireless-2.6-old.git to our repository list and mange the code there?
Dec 14 09:21:32 <morphis> as we have to modify the code too but in another way than PuffTheMagic
Dec 14 09:21:47 <morphis> he tries to use it as drop-in-replacement for sd8xxx in webos
Dec 14 09:22:52 <morphis> as next step I would then create a recipe for OE in recipes/palmpre named palmpre-libertas-sdio_git.bb
Dec 14 09:22:52 <mickey|office> i wouldn't call it compat-wireless-2.6-old, but yes, why not
Dec 14 09:23:04 <morphis> ok
Dec 14 09:23:16 <morphis> then we can maybe name it linux-2.6-extra-modules.git
Dec 14 09:23:16 <mickey|office> tell me the name and i'll create the repo
Dec 14 09:23:25 <mickey|office> hmm
Dec 14 09:23:30 <morphis> and add different subdirectories for different platforms
Dec 14 09:23:35 <mickey|office> ok, right
Dec 14 09:23:57 <morphis> but I don't think we will have so lot out of kernel tree modules for other platforms
Dec 14 09:24:22 <morphis> compat-wireless-2.6-old.git should be better
Dec 14 09:24:38 <morphis> as it is a clone of the original compat-wireless-2.6.old.git repository
Dec 14 09:24:57 <mickey|office> hmm, ok. i don't like the name, but it's your call
Dec 14 09:25:09 <mickey|office> will set it up in a minute
Dec 14 09:25:23 <morphis> ok thank
Dec 14 09:25:31 <morphis> its the name of the original repository
Dec 14 09:28:45 <mickey|office> created
Dec 14 09:49:47 <GNUtoo|laptop> hi mickey|office 
Dec 14 09:54:04 <GNUtoo|laptop> hi mrmoku 
Dec 14 10:00:48 * mrmoku` turned on the tv and switched to 'camera dei deputati' ;)
Dec 14 10:00:51 <mrmoku`> hi GNUtoo|laptop 
Dec 14 10:01:40 <GNUtoo> ah right...I forgott about that
Dec 14 10:01:52 <mrmoku> toca Di Pietro
Dec 14 10:02:32 <GNUtoo> is there forbidden to -18 in camera dei deputati because of berlusoni escorts?
Dec 14 10:03:07 <mrmoku> hehe
Dec 14 10:03:38 <GNUtoo> if it did there would be an issue...for the escorts that are -18
Dec 14 10:03:49 <GNUtoo> so maybe not
Dec 14 10:04:10 <mrmoku> and then... he probably does not want to share them ;)
Dec 14 10:08:54 <GNUtoo> btw audio scenario don't work anymore
Dec 14 10:11:57 <CIA-107> SHR: 03mail 07libphone-ui-shr * r9e298fe240d9 10/ (3 files in 2 dirs): message-list-view: theme, use filters instead of states
Dec 14 10:12:24 <mrmoku> GNUtoo: you mean switching?
Dec 14 10:14:17 <GNUtoo> yes
Dec 14 10:16:33 <daniele_athome> morning guys
Dec 14 10:16:42 <daniele_athome> i see you're about to release a new shr-testing image
Dec 14 10:16:59 <daniele_athome> it seems that anyone don't care about the huge problems of fsogsmd
Dec 14 10:17:13 <daniele_athome> and other problems around suspend
Dec 14 10:18:02 <daniele_athome> *anyone cares
Dec 14 10:20:37 <GNUtoo|laptop> http://pastebin.com/kxSnEu6y
Dec 14 10:20:37 <mrmoku> GNUtoo: yeah, and if you check dmesg it is full of i2c bus timeouts, right?
Dec 14 10:20:52 <GNUtoo|laptop> dmesg is fine
Dec 14 10:21:02 <mrmoku> hmm
Dec 14 10:21:08 <GNUtoo|laptop> apart that:
Dec 14 10:21:10 <GNUtoo|laptop> [   94.862274] WARNING: at kernel/time/timekeeping.c:98 getnstimeofday+0x2c/0xf8()
Dec 14 10:22:23 <GNUtoo|laptop> and it worked just before my last opkg update;opkg upgrade
Dec 14 10:23:08 <mrmoku> did you reboot in between?
Dec 14 10:23:15 <mrmoku> (after upgrade)
Dec 14 10:23:17 <GNUtoo|laptop> yes
Dec 14 10:23:20 <mrmoku> ok
Dec 14 10:23:28 <GNUtoo|laptop> I upgraded yesterday
Dec 14 10:23:34 <GNUtoo|laptop> yesterday night
Dec 14 10:23:45 <GNUtoo|laptop> and before going to sleep I powered down the nokia900
Dec 14 10:24:12 * mrmoku forgot to power down and is now waiting for nolo to charge it enough to be able to boot :/
Dec 14 10:24:36 <GNUtoo|laptop> should I push my fsogsmd config?
Dec 14 10:24:49 <mrmoku> sure
Dec 14 10:24:59 * mrmoku wants to get rid of pin input too :)
Dec 14 10:25:17 <GNUtoo|laptop> ok nice thanks a lot
Dec 14 10:27:16 <Heinervdm-Work> daniele_athome: wich problems?
Dec 14 10:27:31 <daniele_athome> Heinervdm-Work, the biggest one is the suspend problem with gsm
Dec 14 10:27:41 <daniele_athome> actually 2 problems afaik
Dec 14 10:27:51 <daniele_athome> first is: try to call as soon as the FR resumes
Dec 14 10:27:54 <daniele_athome> very soon
Dec 14 10:28:03 <daniele_athome> it will hang fsogsmd
Dec 14 10:28:22 <daniele_athome> second is after some suspend cycles fsogsmd simply crashes
Dec 14 10:28:28 <daniele_athome> or hangs
Dec 14 10:30:13 <Heinervdm-Work> i haven
Dec 14 10:30:29 <Heinervdm-Work> 't seen these problems till now
Dec 14 10:30:45 <Heinervdm-Work> would be nice if someone creates a ticket for those
Dec 14 10:35:44 <daniele_athome> Heinervdm-Work, isn't there any already?
Dec 14 10:35:48 <daniele_athome> on freesmartphone
Dec 14 10:37:12 <GNUtoo|laptop> ping mickey|bbiab 
Dec 14 10:37:16 <GNUtoo|laptop> ping mickey|office 
Dec 14 10:37:26 <GNUtoo|laptop> what should I do for the libisi Makefile?
Dec 14 10:37:41 <daniele_athome> someone once answered to my ping with a ping command output lol
Dec 14 10:38:03 <mrmoku> no route to host?
Dec 14 10:40:33 <CIA-107> freesmartphone.org: 03GNUtoo 07cornucopia * r5280a4d26c0b 10/fsogsmd/conf/nokia_n900/fsogsmd.conf: (log message trimmed)
Dec 14 10:40:33 <CIA-107> freesmartphone.org: fsogsmd: nokia900: fsogsmd.conf: change from dummy modem to isi modem(and use n900 lowlevel plugin)
Dec 14 10:40:33 <CIA-107> freesmartphone.org: Before the configuration for the nokia n900 used the dummy modem,
Dec 14 10:40:33 <CIA-107> freesmartphone.org:  but it had several issues, such as not beeing able to close
Dec 14 10:40:34 <CIA-107> freesmartphone.org:  the SHR pin dialog(despite typing the correct pin)
Dec 14 10:40:34 <CIA-107> freesmartphone.org: Also, the nokia900 lowlevel plugin is used in this configuration
Dec 14 10:40:35 <CIA-107> freesmartphone.org:  file and is expected to work,the isi modem plugin is just a stub
Dec 14 10:41:01 <mrmoku> GNUtoo|laptop: thanks :)
Dec 14 10:42:39 <JaMa|Zzz> mrmoku: does latest fsodeviced build for you with OE on gta?
Dec 14 10:43:02 <mrmoku> JaMa|Zzz: gta I don't know... for n900 yes
Dec 14 10:43:08 <JaMa|Zzz> mrmoku: n900 works but i2c-dev.h is not installed by i2c-tools (only as i2c-dev-user.h)
Dec 14 10:43:19 <mrmoku> ahh
Dec 14 10:43:30 * JaMa|Zzz -> lunch
Dec 14 10:51:01 <daniele_athome> mrmoku, lol
Dec 14 11:06:49 <PaulFertser> mickey|office: btw, it feels like setting the timeout to 5 seconds is reasonable, at least i couldn't hit those suspend/resume bugs for about a week.
Dec 14 11:07:40 <daniele_athome> hi PaulFertser is that timeout related to the issues i was talking about?
Dec 14 11:08:34 <PaulFertser> daniele_athome: not sure, for me it is at command timeout which in turn always lead to fsogsmd closing resource etc and telephony not working until after fsogsmd restart.
Dec 14 11:08:47 <daniele_athome> PaulFertser, it might be that
Dec 14 11:09:01 <PaulFertser> daniele_athome: i've some tickets related to that.
Dec 14 11:09:07 <daniele_athome> mmm
Dec 14 11:09:30 <PaulFertser> daniele_athome: but i see those for months, so that's nothing new.
Dec 14 11:09:40 <daniele_athome> yeah that's my concern
Dec 14 11:09:53 <daniele_athome> releasing a new shr-t image with those bugs
Dec 14 11:24:34 <mickey|office> PaulFertser: ok, sounds good. i will do that then with only a handful commands overriding to 60 or so
Dec 14 11:25:09 <PaulFertser> mickey|office: without even looking at my logs? TBH i haven't grepped them for timeouts yet.
Dec 14 11:25:12 <lindi-> gena4x: PaulFertser: just a quick poll: have you used systemtap, ksplice, oprofile or perf? ;)
Dec 14 11:25:29 <PaulFertser> lindi-: neither of those :(
Dec 14 11:25:31 <gena4x> lindi-: oprofile only
Dec 14 11:25:52 <gena4x> lindi-: and on freerunner too :)
Dec 14 11:26:07 <PaulFertser> The poll proved to be really quick indeed :)
Dec 14 11:29:12 <lindi-> yes, and with wrong answers :(
Dec 14 11:29:52 <gena4x> lindi-: what answer should be right from your point of view?
Dec 14 11:31:29 <gena4x> since i tried oprofile in 2008, it covers all my profiling needs, see no reason to use other tools
Dec 14 11:31:58 <JaMa|Zzz> mickey|office: i2c-tools was needed in fsodeviced only for i2c-dev.h? http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=48e6a063370a38a35f31a28efd8f6ce6ebf00840
Dec 14 11:33:50 <JaMa|Wrk> mrmoku, mickey|office: rebuilding linux-libc-headers gives you i2c-dev.h again
Dec 14 11:34:40 <lindi-> gena4x: that you are a guru in all those projects and have been holding the critical patches that fix my issues :)
Dec 14 11:37:40 <gena4x> lindi-: sounds like real guru is you using all four projects deeply, to the point that you've found issues in all four :)
Dec 14 11:40:28 <JaMa|Wrk> mickey|office: and the version from linux-libc-headers will later fail with conftest.c:(.text+0x6): undefined reference to `i2c_smbus_read_byte_data'
Dec 14 11:40:31 <JaMa|Wrk> configure:12504: error: Could not find i2c functions in linux/i2c-dev.h...please install i2c-tools
Dec 14 11:55:14 <mrmoku> mickey|office: headphone jack *is* broken... it always reports disconnected... regardless if you plug in or out
Dec 14 11:55:19 <mrmoku> [ 5217.250579] headphone (GPIO 177) is now connected
Dec 14 11:55:19 <mrmoku> [ 5271.522277] headphone (GPIO 177) is now disconnected
Dec 14 11:55:24 <mrmoku> is what dmesg says
Dec 14 11:55:30 <mrmoku> 1970.01.01 02:26:43.942504 [libphone-ui]        MESSAGE: Headset disconnected
Dec 14 11:55:34 <mrmoku> 1970.01.01 02:27:38.215881 [libphone-ui]        MESSAGE: Headset disconnected
Dec 14 11:55:37 <mrmoku> is what libphoneui gets
Dec 14 11:57:29 <mrmoku> hmm
Dec 14 11:57:30 <mrmoku> 1970-01-01T01:26:43.938110Z [DEBUG] GpioInputDevice </sys/devices/platform/gpio-switch/headphone>: read 10 bytes: connected
Dec 14 12:00:49 <mickey|office> what does mdbus2 -sl say?
Dec 14 12:02:46 <GNUtoo|laptop> hi mickey|office , quick question, you said something aobut libisi Makefile
Dec 14 12:02:51 <GNUtoo|laptop> what should I do?
Dec 14 12:03:48 <mickey|office> GNUtoo|laptop: moving this to autotools is a bit more involved, i don't know exactly what happens here with the stub & binding generator
Dec 14 12:04:09 <GNUtoo|laptop> ah ok
Dec 14 12:04:15 <GNUtoo|laptop> we keep the Makefile then
Dec 14 12:04:24 <GNUtoo|laptop> but I had an issue with GNU_HASH
Dec 14 12:04:30 <GNUtoo|laptop> I did $(LDFLAGS)
Dec 14 12:04:30 <mickey|office> yeah, until someone is motivated enough to autotoolize it
Dec 14 12:04:44 <GNUtoo|laptop> after the $(CC) under the linker args
Dec 14 12:04:53 <mrmoku> [SIGNAL] org.freesmartphone.Device.Input.Event  /org/freesmartphone/Device/Input  :1.3
Dec 14 12:04:55 <GNUtoo|laptop> but it doesn't work the expected way
Dec 14 12:04:56 <mrmoku> ("HEADSET","released",0)
Dec 14 12:04:58 <mrmoku> twice
Dec 14 12:05:02 <GNUtoo|laptop> only exporting LDFLAGS works
Dec 14 12:05:13 <GNUtoo|laptop> passing LDFLAGS to the Makefile doesn't
Dec 14 12:05:19 <GNUtoo|laptop> maybe I should do something like:
Dec 14 12:05:30 <GNUtoo|laptop> LDFLAGS += $(LDFLAGS) ?
Dec 14 12:05:34 <GNUtoo|laptop> in the Makefile?
Dec 14 12:10:46 * mrmoku will continue digging into it after lunch
Dec 14 12:11:38 <GNUtoo|laptop> mickey|office, autotoolizing is not the priority since I'd better code on modem 
Dec 14 12:12:31 <mickey|office> yo
Dec 14 12:12:40 <mickey|office> mrmoku: ok, i'll take a look when i'm home
Dec 14 12:13:37 <GNUtoo|laptop> so what should I do for the LDFLAGS?
Dec 14 12:14:07 <GNUtoo|laptop> I'll try once more
Dec 14 12:16:27 <GNUtoo|laptop> ah it works now
Dec 14 12:16:30 <GNUtoo|laptop> I made an error
Dec 14 12:16:40 <GNUtoo|laptop> basically it was doing that
Dec 14 12:17:06 <GNUtoo|laptop> EXTRA_OEMAKE="test 'LDFLAGS=${LDFLAGS}'"
Dec 14 12:17:21 <GNUtoo|laptop> swaping test and LDFLAGS work
Dec 14 12:17:33 <GNUtoo|laptop> other question
Dec 14 12:17:42 <GNUtoo|laptop> some Makefile based program inherit autotools
Dec 14 12:17:46 <GNUtoo|laptop> what's the best
Dec 14 12:17:50 <GNUtoo|laptop> an empty do_configure
Dec 14 12:17:55 <GNUtoo|laptop> or to inherit autotools
Dec 14 12:18:01 <GNUtoo|laptop> maybe I should ask in #oe
Dec 14 12:18:06 <GNUtoo|laptop> intstead of bothering you
Dec 14 12:21:02 <GNUtoo|laptop> I asked in #oe
Dec 14 12:23:11 <mrmoku> mickey|office: will try to beat you ;)
Dec 14 12:28:47 <mickey|office> excellent :)
Dec 14 12:39:01 <playya> mrmoku, are there any hints in the fsodeviced logs?
Dec 14 12:41:59 <CIA-107> freesmartphone.org: 03sre 07libisi * r71272e544cc9 10/ (config.mk test/Makefile): [Makefile] install tests
Dec 14 12:43:12 <playya> sth like: 2010-06-16T07:57:28.684906Z [WARN]  KernelAggregateInputDevice </dev/input>: Received release event before pressed event!?
Dec 14 12:44:40 <GNUtoo|laptop> playya, I pasted the logs before, let me find it
Dec 14 12:44:55 <GNUtoo|laptop> http://pastebin.com/kxSnEu6y
Dec 14 12:45:37 <playya> looks like the same problem
Dec 14 12:47:36 <mrmoku> playya: yup
Dec 14 12:48:06 <mrmoku> playya: though it should not have KEY_RELEASED in the first place
Dec 14 12:48:21 <mrmoku> var event = Linux.Input.Event() { type = Linux.Input.EV_SW, code = (uint16)this.code, value = eventValue }; 
Dec 14 12:48:37 <mrmoku> with int32 eventValue = ( str.strip() == this.onValue ) ? 1 : 0; 
Dec 14 12:49:06 <mrmoku> I verified via logger that str and this.onValue are indeed identical (connected)
Dec 14 12:49:58 <playya> evtest might be useful
Dec 14 12:50:00 <mrmoku> duuuhhh
Dec 14 12:50:03 <mrmoku> hmm
Dec 14 12:50:04 <mrmoku> no
Dec 14 12:50:31 <mrmoku> internal const int KEY_PRESS = 1; 
Dec 14 12:50:47 <mrmoku> playya: dmesg is telling the correct thing
Dec 14 12:50:58 <mrmoku> [ 7943.092376] headphone (GPIO 177) is now connected
Dec 14 12:51:26 <mrmoku> configured as word to compare is 'connected'
Dec 14 12:51:29 <mrmoku> which is what it gets
Dec 14 12:51:41 <mrmoku> so eventValue should be KEY_PRESS
Dec 14 12:52:38 <playya> ah. it's n900 gpio module?
Dec 14 12:53:56 <mrmoku> yup
Dec 14 13:02:34 <playya> plugin.vala:241.9-241.23: error: The name `backlight_power' does not exist in the context of `Backlight.OmapPanel.set_backlight_power'
Dec 14 13:02:34 <playya> |         backlight_power( power ); // DBUS SIGNAL
Dec 14 13:02:34 <playya> make[4]: Leaving directory `/home/playya/pre/tmp/work/armv7a-oe-linux-gnueabi/fsodeviced-2_0.9.4+gitr7+5280a4d26c0b7a10d9e4323c1b0ee55a6ca9cc52-r2.15/git/fsodeviced/src/plugins/backlight_omappanel'
Dec 14 13:03:19 <playya> any ideas?
Dec 14 13:04:04 <GNUtoo|laptop> playya, git pull
Dec 14 13:04:07 <GNUtoo|laptop> in openembedded
Dec 14 13:04:15 <playya> Ok.
Dec 14 13:04:16 <GNUtoo|laptop> if it still doesn't work, rebuild fso-specs
Dec 14 13:04:30 <playya> but i need to pull from org.oe.dev=
Dec 14 13:04:39 <GNUtoo|laptop> yes
Dec 14 13:04:42 <GNUtoo|laptop> what are you on?
Dec 14 13:05:13 <playya> on a pre branch from git.fso
Dec 14 13:05:45 <GNUtoo|laptop> ah ok
Dec 14 13:05:53 <GNUtoo|laptop> maybe cherry-pick mrmoku's oe patches then
Dec 14 13:06:09 <GNUtoo|laptop> you should consider migrating the pre patches in openembedded
Dec 14 13:06:17 <GNUtoo|laptop> if they are some left in your pre branch
Dec 14 13:06:26 <GNUtoo|laptop> else you should consider using openembedded.dev
Dec 14 13:06:49 <GNUtoo|laptop> if the pre branch is only an old/stabilized version of openembedded
Dec 14 13:09:23 <playya> i think the branch should be necessary anymore and we should be able to merge the rest into org.oe.dev
Dec 14 13:09:44 <playya> do you know if there's a working kexec for n900?
Dec 14 13:10:54 <JaMa|Wrk> recipes/kexec-tools/kexec-tools-klibc_2.0.2.bb
Dec 14 13:21:16 <mrmoku> playya: it's just SRCREV bump to HEAD for fso-specs and PR bump for libfso-glib
Dec 14 13:22:17 <JaMa|Wrk> hmm poky has newer glib-2.0 than OE glib-2.0_2.27.3.bb, maybe the have resolved dbus dependency somehow
Dec 14 13:28:46 <mrmoku> daniele_athome: bad italian politicians :/
Dec 14 13:29:19 <daniele_athome> mrmoku, yeah i see... :(
Dec 14 13:29:29 <daniele_athome> it's unbelievable
Dec 14 13:29:52 <mrmoku> yup
Dec 14 13:32:53 <daniele_athome> mrmoku, 314-311
Dec 14 13:32:55 <daniele_athome> my god :S
Dec 14 13:56:55 <mrmoku> daniele_athome: 2 did not vote
Dec 14 13:57:02 <daniele_athome> i see
Dec 14 13:57:16 * mrmoku was watching 'Camera dei deputati' channel ;)
Dec 14 13:57:37 <mrmoku> would all be quite funny... despite the fact my wife is italian :/
Dec 14 14:27:47 <GNUtoo|laptop> how do you pass LDFLAGS to valac ?
Dec 14 14:43:58 <mrmoku> GNUtoo|laptop: autotools or not?
Dec 14 14:44:16 <GNUtoo|laptop> no
Dec 14 14:44:19 <GNUtoo|laptop> plain Makefile
Dec 14 14:44:21 <GNUtoo|laptop> in #vala
Dec 14 14:44:25 <GNUtoo|laptop> I was told to use -C
Dec 14 14:44:26 <GNUtoo|laptop> or -c
Dec 14 14:44:45 <mrmoku> valac -c compiles vala to c
Dec 14 14:44:57 <GNUtoo|laptop> indeed
Dec 14 14:45:00 <mrmoku> though I think it should just respect LDFLAGS env regardless
Dec 14 14:45:13 <GNUtoo|laptop> <juergbi> GNUtoo|laptop: no, you nrrf to use valac -C or valac -c and then call cc/ld manually if you want more control
Dec 14 14:45:13 <GNUtoo|laptop> <juergbi> s/nrrf/need/
Dec 14 14:45:25 <mrmoku> ahh, ok
Dec 14 14:49:48 <GNUtoo|laptop> I'll do as he said
Dec 14 14:49:53 <GNUtoo|laptop> if there is no better way
Dec 14 14:54:27 <CIA-107> SHR: 03mail 07libphone-ui * rcb5cdecb7b05 10/src/phoneui-utils.c: phoneui-utils: use the "New" parameter instead of MessageRead in _add_opimd_message
Dec 14 14:54:37 <CIA-107> SHR: 03mail 07libphone-ui * rcff929aea989 10/src/ (phoneui-utils-messages.c phoneui-utils-messages.h): phoneui-utils-message: added the set_sent, set_new functions
Dec 14 14:54:38 <CIA-107> SHR: 03mail 07libphone-ui * r4483d590500c 10/.gitignore: Added .gitignore file
Dec 14 14:54:39 <CIA-107> SHR: 03mail 07libphone-ui * r674bfc35595f 10/src/ (6 files): Added phoneui_utils_{calls,messages,contacs}_get_full() functions
Dec 14 14:54:40 <CIA-107> SHR: 03mail 07libphone-ui * r7f00c8293f35 10/src/phoneui-utils.c: phoneui-utils: set a message as sent only if it really did.
Dec 14 14:55:37 <playya> mrmoku, GNUtoo|laptop what's the problem?
Dec 14 14:55:48 <GNUtoo|laptop> playya, that :
Dec 14 14:55:54 <playya> need to convert a vala project to autotools?
Dec 14 14:56:06 <GNUtoo|laptop> No GNU_HASH in the elf binary
Dec 14 14:56:14 <GNUtoo|laptop> playya, yes that would be great
Dec 14 14:56:20 <GNUtoo|laptop> but I was fixing the Makefile instead
Dec 14 14:56:26 <GNUtoo|laptop> (which is not obtimal)
Dec 14 14:56:47 <playya> whcih project?
Dec 14 14:56:53 <GNUtoo|laptop> libisi
Dec 14 14:56:59 <GNUtoo|laptop> in fso repo
Dec 14 15:09:00 <playya> GNUtoo|laptop, maybe later in the autofoo branch
Dec 14 15:10:19 <GNUtoo|laptop> ?
Dec 14 15:13:01 <CIA-107> SHR: 03mail 07libphone-ui * rd304a78e0e5e 10/src/phoneui-utils.c: phoneui-utils: added warning message errors, plus missing free
Dec 14 15:15:51 <playya> GNUtoo|laptop, does libisi already have a version?
Dec 14 15:15:59 <mrmoku> playya: I found the input issue
Dec 14 15:16:06 <GNUtoo|laptop> 0.0.0
Dec 14 15:16:09 <mrmoku> what is the correct vala way if I have
Dec 14 15:16:11 <mrmoku> void* data, ssize_t length 
Dec 14 15:16:16 <GNUtoo|laptop> so no
Dec 14 15:16:17 <mrmoku> and want a string of length size?
Dec 14 15:16:44 <playya> in later versions uint8[] shoulb be the best
Dec 14 15:16:57 <playya> the you can use string.data
Dec 14 15:17:08 <mrmoku> ?
Dec 14 15:17:26 <mrmoku> right now it's doing string str = (string)data;
Dec 14 15:17:32 <mrmoku> but data contains some more crap
Dec 14 15:17:55 <mrmoku> so I need to truncate it to length
Dec 14 15:18:30 <playya> you want to slice it?
Dec 14 15:19:07 <mrmoku> well I want just the first length bytes of it
Dec 14 15:19:14 <mrmoku> when thats slicing... fine :)
Dec 14 15:19:51 <mrmoku> str.slice(length) ?
Dec 14 15:20:14 <playya> str.slice(0,length)
Dec 14 15:20:21 <mrmoku> good, thanks :)
Dec 14 15:24:13 <playya> mrmoku, could you show me the concrete source? maybe there's a problem with the void* > string cast
Dec 14 15:25:01 <mrmoku> playya: moment
Dec 14 15:25:46 <playya> GNUtoo|laptop, should i use fso-userland as the contact mail or elektranox's mail?
Dec 14 15:25:49 <mrmoku> playya: http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=fsodeviced/src/plugins/gpio_input/plugin.vala;h=c71d5edb80a478cde6461c996777bff9933c90ca;hb=5280a4d26c0b7a10d9e4323c1b0ee55a6ca9cc52#l78
Dec 14 15:28:09 <playya> ah. that's a piece of code i want to change in libfso
Dec 14 15:28:22 <playya> void* is always ugly in vala
Dec 14 15:28:41 <mrmoku> ok, but for now I will just slice and strip it
Dec 14 15:28:44 <playya> uint8[] might be a better solution
Dec 14 15:29:24 <playya> i think you need to memcpy it, because vala tries to strdup the data
Dec 14 15:29:56 <playya> mybe you should use an unowned string to avoid copying and the slice it
Dec 14 15:30:16 <GNUtoo|laptop> playya, fso-userland
Dec 14 15:30:29 <mrmoku> hmm
Dec 14 15:35:39 <mrmoku> does not work anyway :/
Dec 14 15:37:00 <playya> har* make_string (void* data, gint length) {
Dec 14 15:37:00 <playya>         char* result = NULL;
Dec 14 15:37:00 <playya>         char* s;
Dec 14 15:37:00 <playya>         s = g_strdup ((const char*) data);
Dec 14 15:37:00 <playya>         result = string_slice (s, (glong) 0, (glong) length);
Dec 14 15:37:06 <playya> that's my testcase
Dec 14 15:37:27 <playya> and i think you see the problem
Dec 14 15:38:49 <playya> mrmoku, this one should work:
Dec 14 15:38:52 <playya> string make_string(void* data, int length) {
Dec 14 15:38:52 <playya>     unowned string s = (string) data;
Dec 14 15:38:52 <playya>     return s.slice(0, length);
Dec 14 15:38:52 <playya> }
Dec 14 15:40:25 <mrmoku> playya: hmm... ok, where to put make_string?
Dec 14 15:43:34 <mrmoku> playya: alternatively.. is there something like strncmp that would work in that case?
Dec 14 15:44:30 <mrmoku> string.strncmp(length-1, this.onValue, (string)data) ?
Dec 14 15:45:18 <playya> it's in posix.vapi
Dec 14 15:46:11 <playya> I don't know if it's used somewhere else
Dec 14 15:46:13 <mrmoku> posix.strncmp(this.onValue, (string)data, length-1) 
Dec 14 15:46:25 * mrmoku tries
Dec 14 15:46:46 <playya> but i think we should convert the void* stuff to uint8[]
Dec 14 15:47:01 <playya> mickey|bbiab, ^
Dec 14 15:58:51 <playya> mrmoku, better solution:
Dec 14 15:58:54 <playya>     unowned string s = (string) data;
Dec 14 15:58:54 <playya>     return s.ndup(length);
Dec 14 15:59:41 <CIA-107> SHR: 03mail 07libphone-ui-shr * r196982059b7e 10/src/view/message-list-view.c: message-list-view: first basic support to draft view/editing
Dec 14 15:59:47 <mrmoku> int32 eventValue = ( Posix.strncmp(this.onValue, (string)data, length - 1 ) == 0 ) ? 1 : 0;
Dec 14 15:59:53 <GNUtoo|laptop> playya, do you have commit access to fso?
Dec 14 16:00:02 <playya> yep
Dec 14 16:00:12 <mrmoku> that's the only thing I need data for
Dec 14 16:00:34 <playya> ah. you only need to compare
Dec 14 16:00:42 <mrmoku> yup
Dec 14 16:01:55 <GNUtoo|laptop> playya, then you've automatically commit access to libisi in fso repo
Dec 14 16:02:38 <playya> ok
Dec 14 16:02:49 <GarthPS> Hello guys!
Dec 14 16:03:49 <GNUtoo|laptop> hi
Dec 14 16:04:09 <playya> mrmoku, this.onValue.ascii_ncasecmp(data, length -1)
Dec 14 16:04:16 <playya> hi GarthPS 
Dec 14 16:04:43 <GarthPS> tell me , is it possible with OE and bitbake to make a "gcc somecode.c -o test"  to have a armv4t binary to test it directly ?
Dec 14 16:05:07 <GarthPS> s/make/do
Dec 14 16:05:59 <GNUtoo|laptop> what's the autofoo branch?
Dec 14 16:06:07 <GNUtoo|laptop> I do not see any changes
Dec 14 16:06:19 <playya> GNUtoo|laptop, not yet. working on it ;)
Dec 14 16:06:33 <GNUtoo|laptop> ah ok thanks a lot!!!!!
Dec 14 16:06:50 <GNUtoo|laptop> what should I work on in the meantime?
Dec 14 16:09:34 <GarthPS> nobody ?
Dec 14 16:09:55 <GNUtoo|laptop> GarthPS, looking
Dec 14 16:10:18 <GNUtoo|laptop> GarthPS, look at hello world if you want to make a recipe
Dec 14 16:10:28 <GNUtoo|laptop> GarthPS, else bitbake devshell
Dec 14 16:10:37 <GNUtoo|laptop> and source the defshell which is here for me:
Dec 14 16:10:50 <GarthPS> GNUtoo|laptop: I do not want oto make a recipe.it is the point. is it possible ?
Dec 14 16:10:56 <GNUtoo|laptop> ~/embedded/oe/oetmps/nokia900/deploy/addons/arm-oe-linux-gnueabi-shr-nokia900-devshell
Dec 14 16:11:06 <GNUtoo|laptop> yes of course
Dec 14 16:11:16 <GNUtoo|laptop> use the devshell then
Dec 14 16:11:42 <GarthPS> GNUtoo|laptop: how does it work ?
Dec 14 16:12:18 <GNUtoo|laptop> it's a script
Dec 14 16:12:20 <GNUtoo|laptop> that you source
Dec 14 16:12:28 <GNUtoo|laptop> then you have everything in the path
Dec 14 16:12:33 <GNUtoo|laptop> including arm-oe-gcc
Dec 14 16:12:43 <GNUtoo|laptop> or even oe_runmake
Dec 14 16:12:54 <GNUtoo|laptop> LDFLAGS etc...are exported
Dec 14 16:12:56 <GNUtoo|laptop> etc...
Dec 14 16:13:06 <GNUtoo|laptop> basically the only lacking stuff is inherit
Dec 14 16:13:24 <GarthPS> GNUtoo|laptop: ok understood. but for where do i access it ?
Dec 14 16:13:34 <GNUtoo|laptop> as I said
Dec 14 16:13:37 <GNUtoo|laptop> bitbake devshell
Dec 14 16:13:40 <GNUtoo|laptop> will create it
Dec 14 16:13:45 <GNUtoo|laptop> then you source it like that
Dec 14 16:13:54 <GarthPS> GNUtoo|laptop: yop but i did not find yet . i will serch deeper
Dec 14 16:14:03 <GarthPS> ah ok
Dec 14 16:14:10 <GNUtoo|laptop> source YOUR_TMPDIR/nokia900/deploy/addons/arm-oe-linux-gnueabi-shr-nokia900-devshell
Dec 14 16:14:16 <GNUtoo|laptop> oops 
Dec 14 16:14:17 <GNUtoo|laptop> rather
Dec 14 16:14:24 <GNUtoo|laptop> source YOUR_TMPDIR/deploy/addons/arm-oe-linux-gnueabi-shr-nokia900-devshell
Dec 14 16:14:29 <mickey|office> do we have accelerometers?
Dec 14 16:14:34 <mickey|office> are they working?
Dec 14 16:14:35 <GNUtoo|laptop> yes but sysfs only
Dec 14 16:14:36 <GNUtoo|laptop> yes
Dec 14 16:14:51 <mickey|office> how do you interact with them?
Dec 14 16:14:53 <GNUtoo|laptop> but it's the same chip than the freerunner/bug device
Dec 14 16:14:56 <GNUtoo|laptop> cat the node
Dec 14 16:15:04 <GNUtoo|laptop> let me boot the nokia900
Dec 14 16:15:23 <GNUtoo|laptop> mickey|office, maybe I convert to a kernel driver?
Dec 14 16:15:54 <mrmoku> playya: | plugin.vala:81.59-81.62: error: Argument 1: Cannot convert from `void*' to `string'
Dec 14 16:15:57 <mickey|office> i happen to like the way we use the lis
Dec 14 16:16:02 <mrmoku> have to cast...
Dec 14 16:16:03 <mickey|office> configuration via sysfs
Dec 14 16:16:10 <mickey|office> data via input system
Dec 14 16:16:16 <mickey|office> makes much sense to me
Dec 14 16:16:29 <playya> mrmoku, ok. if it helps :(
Dec 14 16:16:30 <GNUtoo|laptop> indeed
Dec 14 16:16:33 <GNUtoo|laptop> should I doit?
Dec 14 16:16:57 <mrmoku> playya: the Posix.strncmp was working too btw. :)
Dec 14 16:17:01 <GNUtoo|laptop> or should it wait
Dec 14 16:17:30 <playya> mrmoku, ok
Dec 14 16:18:03 <mickey|office> GNUtoo|laptop: that'd be pretty cool
Dec 14 16:18:10 <mickey|office> perhaps we could even reuse the FSO's plugin then
Dec 14 16:18:11 <playya> GNUtoo|laptop, i you want to get familiar with vala you can rewrite libisi in vala to get a more gio-like API
Dec 14 16:18:31 <GNUtoo|laptop> uhhh
Dec 14 16:18:35 <GNUtoo|laptop> I can't do everything
Dec 14 16:18:42 <GNUtoo|laptop> and I've often headeaches
Dec 14 16:18:50 <GNUtoo|laptop> and am often tired too
Dec 14 16:19:56 <GNUtoo|laptop> btw: http://wiki.maemo.org/N900_accelerometer
Dec 14 16:21:26 <GNUtoo|laptop> the strange thing is that:
Dec 14 16:21:31 <GNUtoo|laptop> cat enable => off
Dec 14 16:21:33 <GNUtoo|laptop> cat coord
Dec 14 16:21:34 <GNUtoo|laptop> cat coord
Dec 14 16:21:36 <GNUtoo|laptop> etc...
Dec 14 16:21:41 <GNUtoo|laptop> it seem to work while off
Dec 14 16:23:23 <GarthPS> GNUtoo|laptop: what does "source" do ? (sorry if it seems stupid for you... :) ) can you explain just a bit plz ?  thx
Dec 14 16:23:33 <GNUtoo|laptop> GarthPS, np
Dec 14 16:23:49 <GNUtoo|laptop> GarthPS, let's say you have a shell script that does that:
Dec 14 16:23:56 <GNUtoo|laptop> export PATH=$(pwd):$PATH
Dec 14 16:24:24 <GNUtoo|laptop> arm-something-gcc source.c -o binary
Dec 14 16:24:42 <GNUtoo|laptop> so now....if you run the script it will export the path
Dec 14 16:24:53 <GNUtoo|laptop> and arm-something-gcc will be in the path and run
Dec 14 16:24:56 <GNUtoo|laptop> now...
Dec 14 16:25:03 <GNUtoo|laptop> imagine you remove the arm-gcc call
Dec 14 16:25:05 <GNUtoo|laptop> and run it
Dec 14 16:25:10 <GNUtoo|laptop> it won't do anything
Dec 14 16:25:12 <GNUtoo|laptop> why?
Dec 14 16:25:23 <CIA-107> freesmartphone.org: 03mok 07cornucopia * r3d01c1b8df7f 10/fsodeviced/src/plugins/gpio_input/plugin.vala: 
Dec 14 16:25:23 <CIA-107> freesmartphone.org: fsodeviced: fix parsing gpio_input events
Dec 14 16:25:23 <CIA-107> freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Dec 14 16:25:29 <GNUtoo|laptop> simply because the scope of the export is not the one you think it is
Dec 14 16:25:38 <GNUtoo|laptop> basically it only export within the script
Dec 14 16:25:53 <GNUtoo|laptop> so PATH only changes within the script
Dec 14 16:25:56 <GNUtoo|laptop> if you do
Dec 14 16:25:59 <GNUtoo|laptop> echo $PATH
Dec 14 16:26:04 <GNUtoo|laptop> run the script
Dec 14 16:26:05 <GNUtoo|laptop> and re-do
Dec 14 16:26:07 <GNUtoo|laptop> echo $PATH
Dec 14 16:26:13 <GNUtoo|laptop> $PATH won't change
Dec 14 16:26:19 <GarthPS> ah ok!
Dec 14 16:26:33 <GarthPS> understood! it is like one shoot thing
Dec 14 16:26:41 <GNUtoo|laptop> now....export will export theses variables in your current shell
Dec 14 16:26:51 <GNUtoo|laptop> oops
Dec 14 16:27:04 <GNUtoo|laptop> I mean source will export theses variables in your current shell
Dec 14 16:27:28 <GNUtoo|laptop> it's like if you run the *content* of the script in your current shell
Dec 14 16:27:32 <GNUtoo|laptop> PATH will change 
Dec 14 16:27:33 <GNUtoo|laptop> etc...
Dec 14 16:31:22 <GarthPS> GNUtoo|laptop: so I source my devshelll and then I can compile like if i was on the target right ?
Dec 14 16:32:09 <GarthPS> is it normale this bash: "alias: `./configure': invalid alias name" when I source my devshell ?
Dec 14 16:33:11 <GNUtoo|laptop> yes
Dec 14 16:33:14 <GNUtoo|laptop> yes
Dec 14 16:33:31 <GNUtoo|laptop> I don't know why it does this but I've no issues at all
Dec 14 16:33:40 <GNUtoo|laptop> basically run arm-foo-gcc
Dec 14 16:33:48 <GNUtoo|laptop> and scp the result to the target
Dec 14 16:34:28 <GarthPS> GNUtoo|laptop: ok and then "exit" to comeback in my normal environement right ?
Dec 14 16:34:49 <GNUtoo|laptop> open a new shell
Dec 14 16:35:08 <GNUtoo|laptop> exit will close your shell
Dec 14 16:35:31 <GNUtoo|laptop> basically it's like if you typed the command that were in the script yourself
Dec 14 16:35:44 <GNUtoo|laptop> if you type exit after typing all theses commands
Dec 14 16:35:50 <GNUtoo|laptop> it will exit the current shell
Dec 14 16:35:57 <GNUtoo|laptop> and leave you without a shell
Dec 14 16:36:10 <GNUtoo|laptop> so new-tab to get a normal shell
Dec 14 16:36:40 <GarthPS> GNUtoo|laptop: ok thx!!
Dec 14 16:38:57 <mickey|office> mrmoku: hmm, cool patch, i wonder though why the strip doesn't work?
Dec 14 16:40:05 <mickey|office> aah
Dec 14 16:40:06 <mrmoku> mickey|office: data contains still stuff from the previouse event
Dec 14 16:40:08 <mickey|office> the null termination
Dec 14 16:40:10 <mrmoku> which was disconnected
Dec 14 16:40:12 <mrmoku> :)
Dec 14 16:40:15 <mickey|office> null termination is missing
Dec 14 16:40:18 <mrmoku> yup
Dec 14 16:40:24 <mickey|office> that's why the (string)data leads to a wrong result
Dec 14 16:40:29 <mickey|office> ok
Dec 14 16:40:38 <mickey|office> good catch
Dec 14 16:40:50 <mrmoku> should have seen that with my first logger
Dec 14 16:40:54 <mrmoku> oversaw it
Dec 14 16:40:56 <GNUtoo|laptop> mickey|office, freerunner has 2 accelerometers?
Dec 14 16:41:01 <mrmoku> and learned something about kernel_input :)
Dec 14 16:41:05 <mickey|office> GNUtoo|laptop: yes, but we only use one
Dec 14 16:41:10 <GNUtoo|laptop> which one?
Dec 14 16:41:10 <mickey|office> mrmoku: :)
Dec 14 16:41:20 <mickey|office> GNUtoo|laptop: dunno, first one :)
Dec 14 16:41:20 <GNUtoo|laptop> top or bottom
Dec 14 16:41:21 <GNUtoo|laptop> ?
Dec 14 16:41:24 <GNUtoo|laptop> ah?
Dec 14 16:41:28 <GNUtoo|laptop> they are the same?
Dec 14 16:41:32 <mickey|office> the one with the lower i2c address
Dec 14 16:41:37 <mickey|office> i don't know which one that actually is
Dec 14 16:41:54 <GNUtoo|laptop> there are 2 /dev/input/ nodes
Dec 14 16:41:59 <GNUtoo|laptop> anyway I'll look
Dec 14 16:42:11 <GNUtoo|laptop> are they enabled by default or only when you open them?
Dec 14 16:42:19 <mickey|office> only when you open them,
Dec 14 16:42:24 <GNUtoo|laptop> by open I mean open in C
Dec 14 16:42:25 <mickey|office> (which makes much sense)
Dec 14 16:42:26 <GNUtoo|laptop> ok
Dec 14 16:42:28 <mickey|office> yes, me too
Dec 14 16:43:39 <GNUtoo|laptop> what's the use of having 2 accelerometers? more precision trough a mean value?
Dec 14 16:44:42 * mrmoku off doing pickup service for the elder son :/
Dec 14 16:44:42 <mrmoku> bbl
Dec 14 16:46:00 <CIA-107> SHR: 03mail 07libphone-ui-shr * r3851b7b7276c 10/src/view/message-list-view.c: message-list-view: fixed a typo, correctly remove the show callback!
Dec 14 16:48:06 <CIA-107> SHR: 03mail 07libphone-ui-shr * r1a3bf8ea8e41 10/src/view/message-show-view.c: message-show-view: set read only an incoming message when showing it
Dec 14 16:48:08 <mickey|office> oh well
Dec 14 16:48:20 <mickey|office> the idea was to have a more precise value in corner cases
Dec 14 16:48:31 <mickey|office> at the end of the day it didn't quite work out
Dec 14 16:48:45 <mickey|office> besides there is even a small hardware quirk
Dec 14 16:49:02 <mickey|office> adding a gyro instead would have been much better
Dec 14 16:49:04 <mickey|office> or a compass
Dec 14 16:49:06 <mickey|office> *shrug*
Dec 14 16:49:08 <mickey|office> gta04...
Dec 14 16:56:44 <GNUtoo|laptop> mickey|office, are you really sure you want an input node?
Dec 14 16:57:01 <GNUtoo|laptop> ok
Dec 14 16:57:10 <GNUtoo|laptop> because the official kernel has sys nodes
Dec 14 16:58:23 <GNUtoo|laptop> ah sorry
Dec 14 16:58:33 <GNUtoo|laptop> This driver also provides an absolute input class device, allowing the device to act as a pinball machine-esque joystick.
Dec 14 16:58:57 <GNUtoo|laptop> so the official driver has both
Dec 14 17:11:49 <CIA-107> SHR: 03mail 07libphone-ui-shr * rfd2ec8bcc25d 10/src/view/message-list-view.c: message-list-view: update msg_end value on message removal
Dec 14 17:14:38 <GNUtoo|laptop> is accelges supposed to work?
Dec 14 17:14:46 <GNUtoo|laptop> on the freerunner
Dec 14 17:14:54 <GNUtoo|laptop> it says 
Dec 14 17:14:57 <GNUtoo|laptop> make the gesture
Dec 14 17:15:02 <GNUtoo|laptop> and then I try to make it
Dec 14 17:15:04 <GNUtoo|laptop> and nothing
Dec 14 18:26:40 <playya> GNUtoo|laptop, does libisi depend on libnl or libnl2?
Dec 14 19:03:19 <mickeyl> try libnl2 first
Dec 14 19:03:30 <mickeyl> if it doesn't work, we need the old one 
Dec 14 19:03:32 <playya> yes. libfsobasics depends on it
Dec 14 19:03:48 <GNUtoo|laptop> playya, I don't know
Dec 14 19:04:03 <GNUtoo|laptop> I'm not sure the netlink stuff is the same than libnl
Dec 14 19:04:08 <GNUtoo|laptop> I didn't check
Dec 14 19:04:26 <GNUtoo|laptop> anyway it compile with oe_runmake
Dec 14 19:11:10 <mickeyl> hmm
Dec 14 19:11:26 <mickeyl> if the wl12xx lacks ad-hoc mode, how can mobilehotspot be working?
Dec 14 19:11:38 <playya> are we using enum binding stuff somewhere?
Dec 14 19:12:00 <GNUtoo|laptop> mickeyl, kernel power
Dec 14 19:12:08 <GNUtoo|laptop> kernel power doesn't lack ad-hoc
Dec 14 19:12:20 <mickeyl> what on earth is kernel power?
Dec 14 19:12:23 <GNUtoo|laptop> but expect a lot of frame drop
Dec 14 19:12:28 <GNUtoo|laptop> the kernel we use
Dec 14 19:12:35 <GNUtoo|laptop> imagine the 2.6.28 kernel
Dec 14 19:12:38 <GNUtoo|laptop> with a lot of hacks
Dec 14 19:12:40 <GNUtoo|laptop> such as:
Dec 14 19:12:43 <GNUtoo|laptop> *overclocking
Dec 14 19:12:46 <GNUtoo|laptop> *ad-hoc
Dec 14 19:12:48 <GNUtoo|laptop> etc...
Dec 14 19:13:13 <mickeyl> we use it already?
Dec 14 19:13:45 <GNUtoo|laptop> yes
Dec 14 19:13:53 <GNUtoo|laptop> not sure if it's a good thing but we do
Dec 14 19:14:04 <GNUtoo|laptop> ah usb host mode is in there too
Dec 14 19:14:11 <GNUtoo|laptop> usb host is nice
Dec 14 19:14:24 <mickeyl> hmm
Dec 14 19:14:28 <mickeyl> did you try?
Dec 14 19:14:32 <GNUtoo|laptop> yes
Dec 14 19:14:34 <GNUtoo|laptop> works fine
Dec 14 19:14:34 <mickeyl> i alway get device busy
Dec 14 19:14:36 <mickeyl> how ?
Dec 14 19:14:40 <GNUtoo|laptop> let me look
Dec 14 19:15:06 <GNUtoo|laptop> echo hosth > /sys/devices/platform/musb_hdrc/mode
Dec 14 19:15:14 <GNUtoo|laptop> sh booston
Dec 14 19:15:15 <mickeyl> no, thanks
Dec 14 19:15:16 <GNUtoo|laptop> echo F > /proc/driver/musb_hdrc
Dec 14 19:15:21 <mickeyl> i'm talking bout wifi
Dec 14 19:15:21 <mickeyl> :)
Dec 14 19:15:24 <GNUtoo|laptop> ah ok
Dec 14 19:15:39 <mickeyl> ok, it works only if set right after initializing the device
Dec 14 19:15:53 <GNUtoo|laptop> I'll try wifi
Dec 14 19:16:30 <GNUtoo|laptop> ah ?
Dec 14 19:16:57 <mickeyl> ok, now lets see get all the iptable forwarding working again
Dec 14 19:17:58 <GNUtoo|laptop> hmmm it doesn't see my captain-ad-hoc essid
Dec 14 19:18:33 <GNUtoo|laptop> I'll try to connect to it blindely from the openmoko
Dec 14 19:21:42 <mickeyl> mmmh
Dec 14 19:22:05 <mickeyl> nat table not present
Dec 14 19:22:15 * GNUtoo|laptop never used ad-hoc
Dec 14 19:22:21 <GNUtoo|laptop> or at least never succedded
Dec 14 19:23:26 <mickeyl> we need some more modules in the kernel
Dec 14 19:25:10 <mickeyl> is the config in oe or in the kernel tree?
Dec 14 19:25:20 <GNUtoo|laptop> in oe I think
Dec 14 19:25:41 <mickeyl> ok#
Dec 14 19:25:50 * mickeyl adds some NAT
Dec 14 19:31:31 <PaulFertser> GNUtoo|laptop: i used ibss successfully on FR.
Dec 14 19:35:24 <GNUtoo|laptop> what is ibss?
Dec 14 19:35:41 <Heinervdm> mrmoku: is fso in shr-u working after your SRC_REV bump?
Dec 14 19:36:23 <PaulFertser> GNUtoo|laptop: independent bss (or smth like that), commonly know as ad-hoc wifi networking, where every host is beaconing and can organise communication with others.
Dec 14 19:36:37 <PaulFertser> http://en.wikipedia.org/wiki/Independent_Basic_Service_Set
Dec 14 19:36:38 <mrmoku> Heinervdm: working as in building?
Dec 14 19:37:04 <Heinervdm> mrmoku: working as in everything what was working before is still working :)
Dec 14 19:37:20 <mrmoku> Heinervdm: JaMa|Off reported it does not build for gta02 :/
Dec 14 19:37:24 <mrmoku> builds fine for n900
Dec 14 19:37:39 <Heinervdm> mrmoku: ok, then i won't cherry-pick those patches
Dec 14 19:37:49 <mrmoku> Heinervdm: no, better don't yet
Dec 14 19:39:25 <CIA-107> freesmartphone.org: 03Frederik.Sdun 07autofoo * r13e670c5af2d 10libisi/ (21 files in 5 dirs): convert to autotools, except wireshark plugin
Dec 14 19:39:34 <playya> GNUtoo|laptop, ^
Dec 14 19:40:31 <playya> wireshark doesn't provide a .pc file
Dec 14 19:41:33 <GNUtoo|laptop> playya, thanks a lot!!!!
Dec 14 19:41:57 <GNUtoo|laptop> PaulFertser, ok
Dec 14 19:45:16 <GNUtoo|laptop> playya, you conveted to GPLv3?
Dec 14 19:45:27 <GNUtoo|laptop> ofono is v2 only
Dec 14 19:46:39 <playya> oh. sorry
Dec 14 19:46:54 <playya> autogenerated by autotools
Dec 14 19:46:56 <GNUtoo|laptop> could you correct it and commit the result
Dec 14 19:47:02 <GNUtoo|laptop> yes that's what I tought
Dec 14 19:51:36 <CIA-107> freesmartphone.org: 03Frederik.Sdun 07autofoo * r40ea263de28a 10libisi/ (5 files in 4 dirs): Add missing changes for autotools
Dec 14 19:51:37 <CIA-107> freesmartphone.org: 03Frederik.Sdun 07autofoo * ra4b4ee14b75a 10libisi/COPYING: change license to GPLv2 because ofono is v2
Dec 14 19:51:53 <GNUtoo|laptop> thanks a lot!!!!
Dec 14 19:51:57 <GNUtoo|laptop> I'll try it at once
Dec 14 19:52:24 <playya> btw. you only need vala if you compile the tests
Dec 14 19:54:09 <GNUtoo|laptop> ok
Dec 14 19:54:50 <GNUtoo|laptop> btw do we really need libnl?
Dec 14 19:55:34 <playya> yes. for the netlink functions
Dec 14 19:55:41 <GNUtoo|laptop> really?
Dec 14 19:55:46 <GNUtoo|laptop> look at the netlink header
Dec 14 19:55:59 <GNUtoo|laptop> ./src/gisi/netlink.h
Dec 14 19:56:33 <GNUtoo|laptop> libln is not found on my laptop
Dec 14 19:56:37 <playya> doh
Dec 14 19:56:40 <GNUtoo|laptop> by the configure
Dec 14 19:56:43 <GNUtoo|laptop> and it worked before
Dec 14 19:56:50 <GNUtoo|laptop> so I bet the netlink is another header
Dec 14 19:56:56 <GNUtoo|laptop> not the one from libnl
Dec 14 19:57:03 <playya> then the include was wrong and apt-file tricked me
Dec 14 19:57:12 <GNUtoo|laptop> yes
Dec 14 19:57:15 <GNUtoo|laptop> apt-file?
Dec 14 19:57:37 <GNUtoo|laptop> do you have a ultra-cool-and-easy way to autotoolize programs?
Dec 14 19:58:44 <playya> no
Dec 14 19:58:48 <GNUtoo|laptop> ah ok
Dec 14 19:59:00 <playya> but search for file's package
Dec 14 20:01:57 <GNUtoo|laptop> are you removing libnl dep or should I do it?
Dec 14 20:02:50 <GNUtoo|laptop> also it worked with vala 0.8.0
Dec 14 20:03:02 <GNUtoo|laptop> (libnl dep is removed locally)
Dec 14 20:04:21 <GNUtoo|laptop> wow it compiled everything under my laptop
Dec 14 20:04:32 <GNUtoo|laptop> should I commit or were you doing the changes
Dec 14 20:04:33 <GNUtoo|laptop> ?
Dec 14 20:05:34 <mickeyl> where's the r55 coming from in our kernel package?
Dec 14 20:06:17 <GNUtoo|laptop> mickeyl, the machine file
Dec 14 20:06:21 <mrmoku> mickeyl: nokia900.conf
Dec 14 20:06:22 <GNUtoo|laptop> s/file/config
Dec 14 20:06:29 <mickeyl> aah
Dec 14 20:06:38 <mickeyl> so we increase the PR there if we do changes to the defconfig?
Dec 14 20:06:49 * GNUtoo|laptop hopes mickeyl has fast parsing in newer bitbake
Dec 14 20:06:53 <mrmoku> mickeyl: btw. your n900 did not yet explode? safe to switch on the charging plugin?
Dec 14 20:07:01 <mrmoku> (for me locally)
Dec 14 20:07:18 <mrmoku> and yes to PR bump
Dec 14 20:07:49 <mickeyl> mrmoku: yes, it's still running. please have a look at the code before trying it though, a second set of eyes wouldn't hurt
Dec 14 20:08:04 <mrmoku> mickeyl: ok, will try to compare with the charging script
Dec 14 20:08:11 <mickeyl> mrmoku: right, thanks!
Dec 14 20:08:27 <CIA-107> freesmartphone.org: 03Frederik.Sdun 07autofoo * ra76b0e6f5195 10libisi/ (configure.ac src/Makefile.am src/modem.c): remove libnl from dependencies
Dec 14 20:08:31 <CIA-107> freesmartphone.org: 03Frederik.Sdun 07autofoo * r47b56dfdbe50 10libisi/.gitignore: add test/*.c to gitignore
Dec 14 20:08:33 <CIA-107> freesmartphone.org: 03Frederik.Sdun 07autofoo * r33da5bd3cf27 10libisi/src/gisi/client.c: remove _GNU_SOURCE definition from src/gisi/client.c
Dec 14 20:08:42 <mickeyl> ok, the new modules are built
Dec 14 20:08:52 <mickeyl> lets see whether i can NAT now
Dec 14 20:08:53 <GNUtoo|laptop> thanks playya you beat me(I often write huge commit messages)
Dec 14 20:09:18 <playya> small commits=small commit mesages :)
Dec 14 20:09:52 <mickeyl> something with the PM still looks bogus
Dec 14 20:10:03 <mickeyl> with wifi on it appears to suck more than 500mA
Dec 14 20:10:18 <mickeyl> so we discharge while being on USB
Dec 14 20:11:23 <GNUtoo|laptop> playya, I'll change valac to 0.8.0
Dec 14 20:13:18 <mickeyl> hmm
Dec 14 20:13:19 <mickeyl> grr
Dec 14 20:13:23 <mickeyl> need to flash the new kernel
Dec 14 20:13:36 <GNUtoo|laptop> ah ok
Dec 14 20:13:50 <mickeyl> obviously enabling the connection tracking and NAT stuff adds some symbols to the kernel
Dec 14 20:14:04 <mickeyl> can i safely do that from within a running kernel or is it better to use the 0xffff?
Dec 14 20:14:13 <GNUtoo|laptop> use 0xFFFF
Dec 14 20:14:23 <GNUtoo|laptop> I can guide you if you want
Dec 14 20:14:29 <GNUtoo|laptop> basically
Dec 14 20:14:42 <GNUtoo|laptop> 0xFFFF -p kernel%/path/to/zImage
Dec 14 20:15:03 <mickeyl> ok
Dec 14 20:15:09 <mickeyl> and then rebooting?
Dec 14 20:15:22 <GNUtoo|laptop> 0xFFFF -R
Dec 14 20:15:31 <mickeyl> while the device is running?
Dec 14 20:15:38 <mickeyl> is it halting when it reboots and 0xffff is running?
Dec 14 20:15:53 <GNUtoo|laptop> no
Dec 14 20:15:56 <PaulFertser> mickeyl: no, you need to hold u while powering it on by inserting usb
Dec 14 20:16:03 <GNUtoo|laptop> really?
Dec 14 20:16:07 <GNUtoo|laptop> I do that
Dec 14 20:16:13 <GNUtoo|laptop> #prepare 0xffff command
Dec 14 20:16:15 <PaulFertser> mickeyl: i mean you power off the device, then you press u, then insert usb and it boots.
Dec 14 20:16:16 <GNUtoo|laptop> sudo su
Dec 14 20:16:25 <mickeyl> hmm
Dec 14 20:16:29 <mickeyl> i don't have a zImage
Dec 14 20:16:30 <mickeyl> only a uImage
Dec 14 20:16:35 <GNUtoo|laptop> ./0xFFFF -p kernel%/path/to/zImage
Dec 14 20:16:41 <mickeyl> PaulFertser: ok, thanks. i'll try that
Dec 14 20:16:42 <GNUtoo|laptop> mickeyl, you use rm_work?
Dec 14 20:16:43 <PaulFertser> mickeyl: i'm afraid uimage might be of no good.
Dec 14 20:16:49 <mickeyl> bummer
Dec 14 20:16:51 <mickeyl> why are we shipping one then?
Dec 14 20:17:03 <mickeyl> shouldn't land in tmp/deploy/...
Dec 14 20:17:03 <GNUtoo|laptop> mickeyl, mrmoku didn't finish uboot....lol
Dec 14 20:17:10 <mickeyl> ah, future
Dec 14 20:17:10 <mickeyl> ok
Dec 14 20:17:17 <mrmoku> nah
Dec 14 20:17:56 <mrmoku> mickeyl: http://buffalo.nas-central.org/wiki/How_to_Extract_an_uImage :P
Dec 14 20:18:02 <GNUtoo|laptop> yes that works too
Dec 14 20:21:34 <mickeyl> hmm
Dec 14 20:21:35 <mickeyl> i got a bunch of
Dec 14 20:21:37 <mickeyl> Invalid header
Dec 14 20:21:37 <mickeyl> Invalid header
Dec 14 20:21:38 <mickeyl> Invalid header
Dec 14 20:21:38 <mickeyl> Invalid header
Dec 14 20:21:38 <mickeyl> Invalid header
Dec 14 20:21:40 <mickeyl> while flashing
Dec 14 20:21:45 <mickeyl> something to worry about?
Dec 14 20:21:54 <GNUtoo|laptop> that's not normal
Dec 14 20:22:07 <GNUtoo|laptop> but nothing to worry, don't reboot(useless)
Dec 14 20:22:15 <GNUtoo|laptop> and try to flash a correct kernel
Dec 14 20:22:20 <GNUtoo|laptop> try to find a zImage
Dec 14 20:22:27 <GNUtoo|laptop> in the workdir
Dec 14 20:22:34 <GNUtoo|laptop> in arch/arm/boot/
Dec 14 20:23:27 <mickeyl> hmm
Dec 14 20:23:28 <mickeyl> darn
Dec 14 20:23:32 <GNUtoo|laptop> ?
Dec 14 20:23:34 <mickeyl> that didn't quite work
Dec 14 20:23:41 <mickeyl> can no longer load g_ether
Dec 14 20:23:44 <mickeyl> invalid symbols
Dec 14 20:23:47 <GNUtoo|laptop> ouch
Dec 14 20:23:48 <mickeyl> looks like it didn't flash the kernel
Dec 14 20:23:52 <GNUtoo|laptop> indeed
Dec 14 20:24:02 <GNUtoo|laptop> reflash the old one
Dec 14 20:24:24 <mickeyl> well
Dec 14 20:24:27 <mickeyl> i have the modules overwritten
Dec 14 20:24:30 <mickeyl> so i need the new one :)
Dec 14 20:24:35 <GNUtoo|laptop> bitbake shr-image?
Dec 14 20:25:47 <mickeyl> how big is your kernel?
Dec 14 20:25:56 <GNUtoo|laptop> not 0
Dec 14 20:25:59 <GNUtoo|laptop> let me look
Dec 14 20:26:05 <mickeyl> mine is 1869980
Dec 14 20:26:47 <mickeyl> hmm
Dec 14 20:26:50 <mickeyl> you're using -p ?
Dec 14 20:26:53 <mickeyl> what's the different to -F?
Dec 14 20:27:02 <GNUtoo|laptop> -F is for fiasco images
Dec 14 20:27:08 <mickeyl> oops
Dec 14 20:27:09 <mickeyl> :)
Dec 14 20:27:09 <GNUtoo|laptop> don't use it unless you have a fiasco image
Dec 14 20:27:14 * mickeyl reboot
Dec 14 20:27:17 <GNUtoo|laptop> don't
Dec 14 20:27:39 <GNUtoo|laptop> fire up the flash command before rebooting
Dec 14 20:29:18 <PaulFertser> GNUtoo|laptop: he rebooted from non-working linux to always-working nolo :)
Dec 14 20:29:29 <GNUtoo|laptop> yes 
Dec 14 20:29:39 <GNUtoo|laptop> ah ok
Dec 14 20:29:54 <GNUtoo|laptop> I thought it would have tried to run the non-working kernel or the old one
Dec 14 20:30:03 <GNUtoo|laptop> one day I flashed a 0b kernel
Dec 14 20:30:06 <mickeyl> ok, backk again
Dec 14 20:30:07 <GNUtoo|laptop> it kept the old one
Dec 14 20:31:44 <mickeyl> ok, next try w/ ad-hoc & NAT
Dec 14 20:31:50 <GNUtoo|laptop> ok
Dec 14 20:34:30 <GNUtoo|laptop> pespin, make install didn't install the tests
Dec 14 20:34:48 <GNUtoo|laptop> I'll pastebin the recipe
Dec 14 20:35:17 <GNUtoo|laptop> http://pastebin.com/5RetGmUi
Dec 14 20:35:28 <mickeyl> ok, device handed out a DHCP address
Dec 14 20:35:35 <GNUtoo|laptop> nice!
Dec 14 20:40:20 <mickeyl> hmm
Dec 14 20:40:22 <mickeyl> *sigh*
Dec 14 20:40:27 <mickeyl> i think my iptables config is wrongt
Dec 14 20:40:32 * mickeyl reads up on that
Dec 14 20:41:52 <GNUtoo|laptop> mickeyl, iptables is just for connection sharing?
Dec 14 20:42:06 <GNUtoo|laptop> what's your setup?
Dec 14 20:42:50 <playya> if i look at the C code of libisi: there's some glue required if you don't want to use dbus lowlevel and gio's async stuff
Dec 14 20:42:50 <mickeyl> iPad <Wifi> N900 <USB> PC <Internet>
Dec 14 20:43:16 <GNUtoo|laptop> n900 is sharing the internet then
Dec 14 20:44:09 <mickeyl> yes
Dec 14 20:44:17 <mickeyl> i see packets coming in tot the n900
Dec 14 20:44:28 <mickeyl> for some reason it doesn't give something back
Dec 14 20:45:48 <GNUtoo|laptop> I use that as iptables command
Dec 14 20:46:16 <GNUtoo|laptop> iptables  -t  nat  -A  POSTROUTING  -o  ppp0  -j  MASQUERADE
Dec 14 20:46:33 <GNUtoo|laptop> iptables  -A  FORWARD -j  ACCEPT
Dec 14 20:46:39 <GNUtoo|laptop> iptables -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu # /!\run this line only if you have ppp
Dec 14 20:47:05 <GNUtoo|laptop> replace ppp0 by the interface connected to internet(usb0)
Dec 14 20:47:16 <GNUtoo|laptop> and don't run the third line
Dec 14 20:47:24 <mickeyl> ok, that's a very liberal setting
Dec 14 20:47:26 <mickeyl> and...
Dec 14 20:47:27 <mickeyl> it works
Dec 14 20:47:27 <GNUtoo|laptop> indeed
Dec 14 20:47:27 <mickeyl> :D
Dec 14 20:47:37 <mickeyl> i mixed some nets up i guess
Dec 14 20:47:41 * mickeyl dances a jig
Dec 14 20:47:45 <GNUtoo|laptop> I do access control in the server's configs
Dec 14 20:49:30 <mickeyl> speed is amazing
Dec 14 20:49:33 <mickeyl> don't see any lost packages
Dec 14 20:49:43 <mickeyl> will go some further away to check signal range
Dec 14 20:49:44 <mickeyl> bbl
Dec 14 20:49:44 <GNUtoo|laptop> ok nice
Dec 14 20:49:47 <mickeyl> thanks!
Dec 14 20:49:47 <mrmoku> mickeyl: hmm... there is one difference to the script
Dec 14 20:50:10 <mrmoku> the script is resetting the timer the first time without mask like you do in onTimeout
Dec 14 20:50:23 <mrmoku> but inside the while loop the script is using a mask
Dec 14 20:53:07 <mickeyl> ah, true
Dec 14 20:53:38 <mickeyl> it's probably irrelevant since the status bits are not readable anyways
Dec 14 20:53:43 <mickeyl> but for consistence we should change it
Dec 14 20:53:45 <mickeyl> can you?
Dec 14 20:53:53 <mrmoku> hmm... how
Dec 14 20:54:05 <mickeyl> -pushByteToI2C( fd, 0x6b, 0x00, 0x80 );
Dec 14 20:54:05 <mrmoku> you use onTimeout for both
Dec 14 20:54:20 <mrmoku> the intial one
Dec 14 20:54:23 <mickeyl> ah
Dec 14 20:54:24 <mrmoku> and the continuous one
Dec 14 20:55:22 <mickeyl> perhaps we should just keep it that way
Dec 14 20:55:31 <mrmoku> yeah
Dec 14 20:55:38 <mickeyl> at least this is tested here and works ;)
Dec 14 20:55:56 <mrmoku> ok, will enable it too now :)
Dec 14 20:56:01 <mickeyl> cool
Dec 14 20:56:07 <mickeyl> the programming is the critical thing
Dec 14 20:56:10 <mickeyl> the tickling is uncritical
Dec 14 20:56:23 <mrmoku> yup
Dec 14 20:56:59 <mickeyl> ah, with programming voltage and sleep during idle we reduce power consumption a lot
Dec 14 20:57:10 <mickeyl>  your cpufreq module should probably do that as well
Dec 14 20:57:34 <mickeyl> anyways, checking wifi strength
Dec 14 20:57:35 <mickeyl> bbl
Dec 14 20:57:39 <mrmoku> powersupply_n900 is instead of the kernel one?
Dec 14 20:58:05 <mrmoku> will just try :P
Dec 14 21:03:31 <JaMa|Off> HeinervdmOff: you can build it with small manual hack or with small revert in i2c-tools
Dec 14 21:15:40 <CIA-107> freesmartphone.org: 03mok 07cornucopia * rdde1a0e2319a 10/fsodeviced/src/plugins/kernel26_cpufreq/plugin.vala: 
Dec 14 21:15:40 <CIA-107> freesmartphone.org: fsodeviced: move collecting the cpufreq sysfs nodes to the factory function
Dec 14 21:15:40 <CIA-107> freesmartphone.org: Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Dec 14 21:16:44 <CIA-107> SHR: 03mail 07libphone-ui-shr * rac579bc1c68c 10/src/view/message-list-view.c: message-list-view: don't add to the list new messages when not in the same subset
Dec 14 21:20:36 <GNUtoo|laptop> mickeyl, are accelerometer really important? can't we wait for mainline/newer kernel ?
Dec 14 21:29:44 <GNUtoo|laptop> ok I'll forget about importing the new driver
Dec 14 21:30:04 <GNUtoo|laptop> it depends on some new interupt system
Dec 14 21:30:17 <GNUtoo|laptop> basically here's the issue,
Dec 14 21:30:37 <GNUtoo|laptop> the kernel developement is the fastest ever....
Dec 14 21:30:46 <GNUtoo|laptop> it's faster than any software we knows
Dec 14 21:31:54 <GNUtoo|laptop> I'll try to input-ify it
Dec 14 21:31:59 <GNUtoo|laptop> but is it really necessary
Dec 14 21:32:41 <GNUtoo|laptop> basically 4300 lines added,1800 lines removed and 1500 lines modified per day
Dec 14 21:32:51 <GNUtoo|laptop> in 2007-2008
Dec 14 21:32:57 <GNUtoo|laptop> we're nearly in 2011
Dec 14 21:33:04 <GNUtoo|laptop> so...it should be a lot worse
Dec 14 21:33:09 <GNUtoo|laptop> or a lot better
Dec 14 21:33:15 <GNUtoo|laptop> depending on the point of view
Dec 14 21:33:22 <GNUtoo|laptop> (source http://www.youtube.com/watch?v=L2SED6sewRw )
Dec 14 21:33:49 <mrmoku> I will try to work on the new kernel... if it's a lot of work do the modem instead :-)
Dec 14 21:34:08 <GNUtoo|laptop> I don't know but I don't think it's worth it
Dec 14 21:34:14 <GNUtoo|laptop> just to have accelerometres
Dec 14 21:34:17 <mrmoku> yeah, modem is more important
Dec 14 21:34:22 <GNUtoo|laptop> indeed
Dec 14 21:34:31 <mrmoku> and if it comes for free with the new kernel...
Dec 14 21:34:36 <GNUtoo|laptop> indeed
Dec 14 21:34:37 <GNUtoo|laptop> it does
Dec 14 21:34:44 <GNUtoo|laptop> it's in kernel since 2.6.32
Dec 14 21:34:48 <mrmoku> good
Dec 14 21:34:50 <GNUtoo|laptop> and has an input dev
Dec 14 21:34:56 <GNUtoo|laptop> and sysfs too
Dec 14 21:35:30 * mrmoku off to bed now
Dec 14 21:35:33 <mrmoku> GNUtoo|laptop: good night :)
Dec 14 21:35:35 <GNUtoo|laptop> mrmoku, for the new kernel first thing is to know what is lacking
Dec 14 21:35:38 <GNUtoo|laptop> but no one knows
Dec 14 21:35:43 <mrmoku> yeah
Dec 14 21:35:47 <mrmoku> I will find out :)
Dec 14 21:35:53 <GNUtoo|laptop> sre has some sort of doc about that
Dec 14 21:35:56 <GNUtoo|laptop> on his website
Dec 14 21:35:58 <mrmoku> ok
Dec 14 21:36:16 <GNUtoo|laptop> https://elektranox.org/n900/kernel/status.html
Dec 14 21:36:51 <pespin> GNUtoo|laptop, I'm sorry but I'll be very busy till thursday next week, I have lots of exams and other work these days. I don't think I'll be able to look at anything till the end of next week
Dec 14 21:37:10 <GNUtoo|laptop> pespin, ok so I package without the tests?
Dec 14 21:37:25 <mrmoku> interesting matrix
Dec 14 21:37:49 <mrmoku> guess most of the not-mainline points are in meego
Dec 14 21:37:58 <GNUtoo|laptop> mrmoku, note that meego has a lot of patches that are not upstream but still more recent than 2.6.28
Dec 14 21:38:02 <GNUtoo|laptop> yes
Dec 14 21:38:03 <pespin> GNUtoo|laptop, well I'm not quite aware of what you are doing, didn't have time to look at it ;)
Dec 14 21:38:08 <GNUtoo|laptop> meego lacks dvfs tough
Dec 14 21:38:28 <GNUtoo|laptop> pespin, basically there is no telephony on n900
Dec 14 21:38:30 <mrmoku> GNUtoo|laptop: I know... the meego 1.1 kernel is based on 2.6.33... current development on 2.6.35
Dec 14 21:38:36 <GNUtoo|laptop> ofono is free and has support for it
Dec 14 21:38:44 <mrmoku> anyway... good night :)
Dec 14 21:38:52 <GNUtoo|laptop> libisi is ofono bits taken and put in a lib
Dec 14 21:39:02 <GNUtoo|laptop> that will be used by fso
Dec 14 21:39:02 <pespin> GNUtoo|laptop, afaik you are doing a recipe for some lib which you'll use in fso to have telephony on n900 right?
Dec 14 21:39:05 <GNUtoo|laptop> mrmoku, good night
Dec 14 21:39:07 <pespin> ok :)
Dec 14 21:39:45 <pespin> GNUtoo|laptop, and you are doing the vala bindings right?
Dec 14 21:39:56 <GNUtoo|laptop> no
Dec 14 21:39:58 <pespin> and something is not building correclty?
Dec 14 21:40:03 <GNUtoo|laptop> I'm integrating in fso
Dec 14 21:40:10 <GNUtoo|laptop> vala bindings are already done
Dec 14 21:40:14 <pespin> ah ok
Dec 14 21:40:27 <GNUtoo|laptop> for now I did an oe recipe
Dec 14 21:40:34 <GNUtoo|laptop> and it didn't install the tests
Dec 14 21:40:36 <GNUtoo|laptop> that's all
Dec 14 21:41:02 <pespin> GNUtoo|laptop, does installing work out of OE?
Dec 14 21:41:10 <GNUtoo|laptop> I don't know
Dec 14 21:41:12 <GNUtoo|laptop> I'll check
Dec 14 21:41:20 <pespin> okk
Dec 14 21:41:31 <pespin> dinner time, I'll return later (a bit late)
Dec 14 21:41:54 <GNUtoo|laptop> ok
Dec 14 22:39:48 <[Rui]> hi all
Dec 14 22:54:14 <pespin_> GNUtoo|laptop, hi, im here
Dec 14 22:54:23 <GNUtoo|laptop> ok
Dec 14 22:54:35 <GNUtoo|laptop> I think I won't care about tests for now
Dec 14 22:54:36 <pespin_> GNUtoo|laptop, I think you'll need to add some FILES_ and PACKAGE_ for the tests
Dec 14 22:54:47 <GNUtoo|laptop> I'll work on modem instead
Dec 14 22:55:19 <pespin_> GNUtoo|laptop, have a look into e_wm and elementary recipes, there are tests there which may be of help to add what you need to recipe
Dec 14 22:55:52 <GNUtoo|laptop> the problem is not the recipe
Dec 14 22:56:13 <GNUtoo|laptop> I know how to use PACKAGES+= and FILES_${PN}-test = 
Dec 14 22:56:13 <pespin_> ? so autotools problem?
Dec 14 22:56:16 <GNUtoo|laptop> yes
Dec 14 22:56:25 <GNUtoo|laptop> tests aren't installed
Dec 14 22:56:36 <GNUtoo|laptop> also on my laptop
Dec 14 22:57:02 <pespin_> GNUtoo|laptop, I remember reading that it didn't use autotools but only Makefile, is that correct?
Dec 14 22:57:15 <GNUtoo|laptop> yes
Dec 14 22:59:25 <pespin_> GNUtoo|laptop, david samblas from tuxbrain just passed to me this links. it might be of interest to you:
Dec 14 22:59:25 <pespin_> http://sdgsystems.com
Dec 14 22:59:44 <pespin_> GNUtoo|laptop, http://sdgsystems.com/index.php?option=com_content&view=article&id=112&Itemid=63
Dec 14 22:59:51 <GNUtoo|laptop> ok he can come here if he wants
Dec 14 23:01:22 <GNUtoo|laptop> he's only in #jlime
Dec 14 23:01:42 <GNUtoo|laptop> so you got him via xmpp
Dec 14 23:01:59 <pespin_> yes :)
Dec 14 23:02:05 <GNUtoo|laptop> ok
Dec 14 23:02:22 <pespin_> GNUtoo|laptop, he'll enter in a mom
Dec 14 23:02:29 <GNUtoo|laptop> ok
Dec 14 23:02:31 <GNUtoo|laptop> hi tuxbrain 
Dec 14 23:02:38 <[Rui]> tuxbrain: hola David! Como vas? :)
Dec 14 23:02:39 <tuxbrain> hi :)
Dec 14 23:03:32 <GNUtoo|laptop> tuxbrain, for the geeksphone leviathan has an university exam,he's working on it, he told me that he will develop for the htcdream again when done with the exam
Dec 14 23:04:09 <GNUtoo|laptop> and for the geeksphone too
Dec 14 23:05:18 <pespin_> GNUtoo|laptop, btw, I don't have a great knowledge on Makefiles, but if you can pastebin it now I'll look give it a look :)
Dec 14 23:05:33 <tuxbrain> I was talking with pespin about a new SHRizable device
Dec 14 23:05:33 <tuxbrain> ok no rush with geekphone, Is basically a toy... this one is real business
Dec 14 23:05:33 <tuxbrain> http://sdgsystems.com/index.php?option=com_content&view=article&id=112&Itemid=63
Dec 14 23:05:59 <tuxbrain> [Rui]: :) peleando como siempre :)
Dec 14 23:06:02 <GNUtoo|laptop> pespin_, ok I'll paste
Dec 14 23:06:43 <GNUtoo|laptop> tuxbrain, do you have more specs
Dec 14 23:06:48 <GNUtoo|laptop> *more detailed specs
Dec 14 23:07:16 <tuxbrain> I'm asking for them right now, and better news is that I will have a device also soon
Dec 14 23:07:19 <GNUtoo|laptop> for instance what's the wifi chip
Dec 14 23:07:25 <[Rui]> urgh win mobile
Dec 14 23:07:31 <[Rui]> I fear for the device drivers
Dec 14 23:07:43 <GNUtoo|laptop> I fear for the bootloader rather
Dec 14 23:07:44 <tuxbrain> they also sell it with OE anstrom :)
Dec 14 23:07:49 <GNUtoo|laptop> ah ok nice
Dec 14 23:08:05 <GNUtoo|laptop> so if it runs angstrom it should be easy....in theory
Dec 14 23:08:16 <tuxbrain> yes that's the point :)
Dec 14 23:08:24 <GNUtoo|laptop> modem interface?
Dec 14 23:08:24 <[Rui]> detailed specs here: http://www.mypidion.com/products/bm_170/default_02.asp
Dec 14 23:08:35 <[Rui]> CPU 	PXA 320, 806MHz
Dec 14 23:08:38 <GNUtoo|laptop> [Rui], yes but that's not detailed enough
Dec 14 23:08:51 <[Rui]> yes, severely underspecified
Dec 14 23:08:55 <GNUtoo|laptop> as usual
Dec 14 23:09:07 <[Rui]> not even what S3C it has :(
Dec 14 23:09:13 <[Rui]> tuxbrain: you know which one it is?
Dec 14 23:09:41 <GNUtoo|laptop> tuxbrain, what's the final cost for the consumer btw?
Dec 14 23:09:45 <tuxbrain> I'm asking for that tech info, sources and all usefull stuff
Dec 14 23:09:50 <tuxbrain> is not cheap
Dec 14 23:09:54 <GNUtoo|laptop> I mean will it be cheaper than n900?
Dec 14 23:10:09 <tuxbrain> is intended to industrial propouses
Dec 14 23:10:11 <GNUtoo|laptop> n900 is about 600E
Dec 14 23:10:13 <GNUtoo|laptop> ok
Dec 14 23:10:27 <GNUtoo|laptop> so you need it for industrial stuff?
Dec 14 23:10:32 <CIA-107> SHR: 03mail 07libphone-ui * r6610d385eccb 10/src/ (3 files): phoneui-utils: Added phoneui_utils_messages_query
Dec 14 23:12:42 <tuxbrain> full equip (vga, gps, 3g, bt, wifi) is about 850 eur
Dec 14 23:12:51 <GNUtoo|laptop> ok
Dec 14 23:13:01 <[Rui]> tuxbrain: O-U-C-H-I-E-!
Dec 14 23:13:02 <tuxbrain> vat not included
Dec 14 23:13:03 <GNUtoo|laptop> what do you need it for?
Dec 14 23:13:16 <GNUtoo|laptop> industrial stuff? or community product?
Dec 14 23:13:31 <pespin_> Price: $863 <--http://www.pcdistrict.com/reviews/bluebird-pidion-bm-170-reviews-134203.html
Dec 14 23:15:30 <pespin_> http://sdgsystems.com/download/datasheets/%5bBrochure%5d%20BM-170_EN.pdf
Dec 14 23:15:38 <pespin_> http://sdgsystems.com/download/datasheets/%5bSpecSheet%5d%20BM-170.pdf
Dec 14 23:15:50 * pespin_ opens them now :P
Dec 14 23:16:04 <pespin_> GNUtoo|laptop, ^
Dec 14 23:16:15 <GNUtoo|laptop> I'm reading them
Dec 14 23:17:01 <GNUtoo|laptop> there is the same infos than before
Dec 14 23:17:07 <[Rui]> GNUtoo|laptop: yeah :(
Dec 14 23:17:08 <tuxbrain> mmm what version, there are variants (qvga, with or 3g, etc..) the cheaper one is about 530€
Dec 14 23:18:41 <GNUtoo|laptop> do you have some sources somewhere?
Dec 14 23:19:06 <tuxbrain> but is barelly a pda (qvga+BT) 
Dec 14 23:19:48 <tuxbrain> GNUtoo|laptop: I will ask for all that, that people are very colaborative and good technicians so I guess there will be no problem (or at least not so many problems a I got with geekphone)
Dec 14 23:20:04 <GNUtoo|laptop> ok
Dec 14 23:20:16 <tuxbrain> just want to head up the SHR community :)
Dec 14 23:20:19 <GNUtoo|laptop> the main problem with geeksphone is that it's based on qualcomm MSM
Dec 14 23:21:46 <GNUtoo|laptop> I found some source
Dec 14 23:21:57 <GNUtoo|laptop> http://familiar.sdgsystems.com/recon/
Dec 14 23:23:23 <tuxbrain> the fact is I already have a costumer (linux solution provider) that was searching for hardware to run his pyqt solution and Pideon products fits their needs, so taking advantage of that dealings I will have aviable some loaned hardware, and lets face that it will look nicer with an SHR than a bare X11 :P
Dec 14 23:24:08 <GNUtoo|laptop> indeed
Dec 14 23:24:17 <GNUtoo|laptop> and easier to program
Dec 14 23:24:22 <GNUtoo|laptop> as there would be FSO
Dec 14 23:24:24 <tuxbrain> yes
Dec 14 23:24:36 <tuxbrain> that's also the point of my reason to port 
Dec 14 23:24:51 <GNUtoo|laptop> ok
Dec 14 23:25:08 <tuxbrain> FSO will be interesting also for the BIP-6000 series
Dec 14 23:25:43 <tuxbrain> and maybe NOMAD+GSM/GPRS (only data) modem
Dec 14 23:29:30 <tuxbrain> I will own a BIP-6000-D, and will have a BIP-6000-E , a BM-170, and a NOMAD-800XE for a couple of months loaned
Dec 14 23:29:46 <GNUtoo|laptop> ok
Dec 14 23:30:22 <GNUtoo|laptop> so we will be able to findout if it's worth
Dec 14 23:30:52 <GNUtoo|laptop> the problem is, with the huge price, will it gather a community?
Dec 14 23:31:15 <tuxbrain> mmm not a user comunity but a solution provider comunity
Dec 14 23:32:20 <GNUtoo|laptop> ok
Dec 14 23:32:37 <GNUtoo|laptop> with maybe 1 or 2 users
Dec 14 23:32:41 <GNUtoo|laptop> a bit like buglabs
Dec 14 23:33:09 <tuxbrain> mmmm not I don't think so
Dec 14 23:34:14 <tuxbrain> define user
Dec 14 23:34:19 <tuxbrain> final user?
Dec 14 23:34:38 <tuxbrain> street user?
Dec 14 23:34:44 <tuxbrain> then yes
Dec 14 23:34:51 <tuxbrain> maybe less
Dec 14 23:34:54 <tuxbrain> :P
Dec 14 23:36:26 <tuxbrain> but if you where a OpenERP consultant and need to offer to a costumer a device you sure will offer one that one instead of a Windows based one (arround the same price)
Dec 14 23:36:52 <GNUtoo|laptop> user means interested develloper
Dec 14 23:37:32 <tuxbrain> the I think at  lot more
Dec 14 23:37:41 <GNUtoo|laptop> ok
Dec 14 23:37:56 <GNUtoo|laptop> the issue is that a lot of people have the nokia n900 now
Dec 14 23:38:04 <GNUtoo|laptop> and are porting SHR to it
Dec 14 23:38:09 <GNUtoo|laptop> some don't
Dec 14 23:38:11 <GNUtoo|laptop> but some do
Dec 14 23:38:25 <GNUtoo|laptop> I don't know how many maybe 4 or 5 devs
Dec 14 23:38:33 <tuxbrain> really I will be happy just with the fso part ported
Dec 14 23:38:48 <GNUtoo|laptop> I can help you evaluate the port
Dec 14 23:38:52 <GNUtoo|laptop> that's the first thing to do
Dec 14 23:39:06 <GNUtoo|laptop> I bet the kernels are old
Dec 14 23:39:12 <GNUtoo|laptop> like 2.6.20 or something like that
Dec 14 23:39:26 <tuxbrain> yes they are 2.6.27 if I rememeber
Dec 14 23:39:30 <GNUtoo|laptop> ah nice
Dec 14 23:39:51 <GNUtoo|laptop> that render them compatible with compat-wireless
Dec 14 23:40:09 <GNUtoo|laptop> my bugs 1.x have 2.6.27
Dec 14 23:40:21 <tuxbrain> ok that sounds encouraging :)
Dec 14 23:41:16 <tuxbrain> but don't worry, once I got all info and the devices I will come back, but I think is the oportunity to put FSO in industry ... or at least in industrial devices :P
Dec 14 23:41:22 <pespin_> I think first thing to know is the machine arch and if the config recipe files are in some public repo (as well as the 2.6.27 kernel)
Dec 14 23:41:41 <pespin_> so we can build images
Dec 14 23:41:59 <GNUtoo|laptop> machine arch is PXA270 right?
Dec 14 23:42:03 <pespin_> and all this has to exist if they claim that they are using Angstron OE on it
Dec 14 23:42:14 <GNUtoo|laptop> ah sorry
Dec 14 23:42:16 <GNUtoo|laptop> pxa320
Dec 14 23:42:19 <tuxbrain> yes pespint that was the second point on the mail I send :)
Dec 14 23:43:46 * pespin_ blames his harddrive and goes to move the lit of its box to get it working another time
Dec 14 23:44:07 <pespin_> hopefully I'll get a new PC on christmas :D
Dec 14 23:46:23 <pespin_> quick glance at machines/ dir in OE git repo doesn't show any pxa320
Dec 14 23:46:27 <GNUtoo|laptop> the mail was sent to pespin  ot to a mailing list
Dec 14 23:46:35 <pespin_> I bet they'll have their recipes somewhere else
Dec 14 23:46:53 <pespin_> GNUtoo|laptop, to the people behind the device I think
Dec 14 23:47:07 <GNUtoo|laptop> ah ok sorry
Dec 14 23:50:00 <GNUtoo|laptop> still armv5?
Dec 14 23:51:46 <pespin_> just found XScale PXA270 ->ARMv5TE 
Dec 14 23:52:30 <tuxbrain> ok guys, I will come back with any news about it , time to some sleep, some intesive php coding tomorrow. thanks a lot guys :), maybe we have to extend FSO to support Barcode scanners soon :P
Dec 14 23:54:14 <pespin_> tuxbrain_away, gnight :)
Dec 14 23:56:50 <pespin_> acording to wikipedia this chip is also used in some blackberrys
Dec 14 23:58:17 <pespin_> "The XScale is also used in devices such as PVPs (Portable Video Players), PMCs (Portable Media Centres), including the Creative Zen Portable Media Player and Amazon Kindle E-Book reader, and industrial embedded systems"
Dec 14 23:59:44 <pespin_> * RedBoot open-source bootloader, the standard boot firmware shipped with XScale boards
Dec 15 00:00:24 <pespin_> GNUtoo|laptop, ^ here you have the bootloader ;)
Dec 15 00:00:32 <GNUtoo|laptop> ok
Dec 15 00:01:01 <pespin_> GNUtoo|laptop, btw, you didn't paste the Makefile :P
Dec 15 00:01:05 <GNUtoo|laptop> ah sorry
Dec 15 00:01:08 <GNUtoo|laptop> I do it now
Dec 15 00:04:00 <GNUtoo|laptop> http://pastebin.com/5HTyg4R8
Dec 15 00:04:04 <GNUtoo|laptop> test/Makefile
Dec 15 00:04:44 <pespin_> GNUtoo|laptop, do you have a full output of Make from clean source tree?
Dec 15 00:04:55 <GNUtoo|laptop> I'll pastebin that
Dec 15 00:05:40 <GNUtoo|laptop> make or make install?
Dec 15 00:05:40 <pespin_> ugh quite long for what I expected habing been generated without autotools
Dec 15 00:06:10 <pespin_> GNUtoo|laptop, make output looks ok? (test compile?)
Dec 15 00:06:19 <GNUtoo|laptop> yes
Dec 15 00:06:46 <pespin_> then make install :)
Dec 15 00:06:53 <GNUtoo|laptop> http://pastebin.com/QeyqUaBK
Dec 15 00:06:54 <GNUtoo|laptop> ok
Dec 15 00:08:33 <GNUtoo|laptop> http://pastebin.com/bC7yYXSn
Dec 15 00:15:15 <pespin_> GNUtoo|laptop, btw, in the Makefile header it says it was generated by automake... so there should be some Makefile.in or .am, shouldn't it? :S
Dec 15 00:15:36 <GNUtoo|laptop> yes
Dec 15 00:15:39 <GNUtoo|laptop> there are
Dec 15 00:16:37 <pespin_> GNUtoo|laptop, ah, then those are the interesting ones ;)
Dec 15 00:16:55 <GNUtoo|laptop> yes they should
Dec 15 00:17:02 <GNUtoo|laptop> I'll paste them
Dec 15 00:17:16 <pespin_> I thougth you said the Makefile was written directly
Dec 15 00:17:19 <GNUtoo|laptop> (I'm tired and confonded you with playya )
Dec 15 00:17:27 <GNUtoo|laptop> *confused
Dec 15 00:17:34 <GNUtoo|laptop> so sorry
Dec 15 00:17:44 <pespin_> and configure.in configure.ac?
Dec 15 00:17:46 <GNUtoo|laptop> it was before playya autotoolized the work
Dec 15 00:17:55 <pespin_> aah ok
Dec 15 00:17:57 <GNUtoo|laptop> all is available here:
Dec 15 00:18:14 <pespin_> so now it's autotoolized ;)
Dec 15 00:18:22 <GNUtoo|laptop> http://git.freesmartphone.org/?p=libisi.git;a=shortlog;h=refs/heads/autofoo
Dec 15 00:18:24 <GNUtoo|laptop> yes
Dec 15 00:18:30 <pespin_> ok perfect
Dec 15 00:19:31 <GNUtoo|laptop> the only detail is that it doesn't install the tests
Dec 15 00:21:04 <pespin_> uhm I cant find makefile.in/am
Dec 15 00:21:19 <GNUtoo|laptop> .in is autogenerated
Dec 15 00:21:25 <GNUtoo|laptop> .am should be there
Dec 15 00:21:32 <GNUtoo|laptop> autofoo branch
Dec 15 00:22:06 <GNUtoo|laptop> http://git.freesmartphone.org/?p=libisi.git;a=blob;f=test/Makefile.am;h=5c436ae71ce2747a1af0301585e05bab9a605fce;hb=refs/heads/autofoo
Dec 15 00:22:08 <pespin_> ah yes, was looking wrong brach :P
Dec 15 00:23:37 <pespin_> GNUtoo|laptop, lol quick glance: noinst_PROGRAMS = $(TEST_PROGS)
Dec 15 00:23:48 <pespin_> noinst? that's a suspicious name :P
Dec 15 00:23:53 <GNUtoo|laptop> indeed lol
Dec 15 00:24:00 <GNUtoo|laptop> maybe I'll look tomorrow
Dec 15 00:24:08 <GNUtoo|laptop> it's 01:22 here
Dec 15 00:24:08 <CIA-107> SHR: 03mail 07libphone-ui-shr * r4c1c21d7dbbf 10/src/view/message-list-view.c: message-list-view: don't sanitize the content message by default
Dec 15 00:25:05 <pespin_> GNUtoo|laptop, same here. but relaxing a bit in the sofa looking "House", so it's ok :P
Dec 15 00:25:20 <GNUtoo|laptop> ok
Dec 15 00:28:14 <[Rui]> well, it's less one hour than that here, but I'm off to bed :)
Dec 15 00:28:51 <pespin_> GNUtoo|laptop, is it correct to "noinst_PROGRAMS = $(TEST_PROGS)" before setting TEST_PROGS? I don't think so
Dec 15 00:29:18 <pespin_> s/setting/initializing
Dec 15 00:31:53 <pespin_> GNUtoo|laptop, I would try moving the noinst_PROGRAMS = ... line to the end of the file
**** ENDING LOGGING AT Wed Dec 15 02:59:57 2010