**** BEGIN LOGGING AT Thu May 14 02:59:57 2009
May 14 04:41:26 <PaulFertser> mwester: Hey, just read you patches, great work. I've several questions though.
May 14 04:42:32 <PaulFertser> mwester: Am i missing something or wallcharger presence will be intepreted as usb connected?
May 14 04:44:29 <PaulFertser> mwester: And is it the same set of patches you've asked to test on the device? I don't see netif_carrier_on/off getting called anywhere (except where it was called earlier).
May 14 05:10:42 <mwester> netif carrier func is called indirectly, waaaaay down the call chain, by the udc driver, as it enables/disables the connection (beneath the g_ether driver).  The bit being tested in the pcf struct by the mach-gta02.c code is one specific to USB, not charger.
May 14 05:11:10 <PaulFertser> mwester: ok, great :)))
May 14 05:12:42 <mwester> I don't know what will happen if you plug in to a host (to establish a connection and enumerate the USB), then unplug (dropping the carrier) and plug into a dumb (100ma) charger -- it may erroneously claim carrier to be up.  It may also attempt to force the USB to be re-enumerated, fail, and result in the link staying down.  
May 14 05:14:43 * mwester goes to test that...
May 14 05:15:02 <mwester> sweet.
May 14 05:15:11 <tmzt> it works (fails)?
May 14 05:15:23 <mwester> does exactly what it's supposed to.
May 14 05:15:33 <tmzt> which is?
May 14 05:15:44 <mwester> charge is set to 100ma, but the link remains down.
May 14 05:15:54 <mwester> (usb car charger)
May 14 05:16:00 <tmzt> ok, cool
May 14 05:16:58 <tmzt> so it detects d+, sees it's gone and brings down the netdev?
May 14 05:17:53 <tmzt> then detects vbus (charger) and sets it to draw 100mA?
May 14 05:18:25 <mwester> That would be how the existing driver expects to work.  Of course, the gta02 doesn't do that.
May 14 05:19:48 <mwester> The GTA02 wires vbus to the PMU chip, so the SoC (and the udc driver) don't ever see it.  So the driver assumes it's always present.   The PMU driver hooks into a callback from the UDC so that it can know when the USB has been enumerated.
May 14 05:19:58 <mwester> This is the signal that it can swtich from 100ma to 500ma.
May 14 05:20:12 <mwester> The PMU knows (by resistor) if it can go to 1000ma.
May 14 05:20:42 <mwester> So what the patch does, is add a polling mechanism to the udc driver, that looks for a change in the USB status from the PMU driver.  Ick.
May 14 05:43:42 <tobii_> good morning
May 14 06:52:34 <SHR-WugBranler> tracfeed: Ticket #440 (Problem with battery applet on gta01) created <http://trac.shr-project.org/trac/ticket/440>
May 14 07:49:41 <methril|work> good mornign
May 14 07:50:36 <mrmoku> methril|work: hey, morning
May 14 07:50:43 <mrmoku> still waiting for my mail?
May 14 07:51:13 <mrmoku> did not yet get to it :(
May 14 07:51:42 <mrmoku> methril|work: how evolved are your elementary skills?
May 14 08:20:35 <methril|work> mrmoku: elementary? really basics
May 14 08:21:24 <mrmoku> methril|work: one thing we should do in efl2 is switch the lists to elm_genlists... I think
May 14 08:21:57 <methril|work> i'll take a look to elm_genlists
May 14 08:23:02 <methril|work> i've to update my elm knowledge ;)
May 14 08:24:37 <mrmoku> great, thanks :)
May 14 08:28:54 <methril|work> you're wellcome
May 14 08:32:50 <methril|work> mrmoku: i see a lot of packages that were in overlay, in OE dev, when fso/ms5 is released, is some plan to merge all this stuff to OE?
May 14 08:34:15 <mrmoku> methril|work: plan is to get rid of the overlay, yes
May 14 08:34:38 <methril|work> mrmoku: ilike this!! :)
May 14 09:12:00 <Ainulindale> mrmoku: ah?
May 14 09:12:06 <Ainulindale> mrmoku: Well that wasn't my plan :-)
May 14 09:12:20 <Ainulindale> I want to keep the overlay as a sandbox for developers, and a buffer for OE commits
May 14 09:12:20 <mrmoku> Ainulindale: no?
May 14 09:12:41 <Ainulindale> But we may be able to talk this through :-)
May 14 09:12:46 <Ainulindale> THis was my own idea
May 14 09:12:53 <mrmoku> hmm... I thought plan was to be able to build SHR completely without overlay
May 14 09:13:03 <Ainulindale> We won't be able, due to OE rules, to give commit access to lots of people
May 14 09:13:14 <Ainulindale> That's why I think a buffer is nice
May 14 09:13:22 <Ainulindale> mrmoku: SHR release/testing yes
May 14 09:13:30 <Ainulindale> but if we can't
May 14 09:13:37 <Ainulindale> that is: we have a patch which won't be committed
May 14 09:13:43 <Ainulindale> we'll need this overlay anyway
May 14 09:13:45 <MarcOChapeau> Hey guys :)
May 14 09:13:48 <mrmoku> yeah, I agree...
May 14 09:13:50 <Ainulindale> MarcOChapeau: damn you're alive
May 14 09:13:54 <MarcOChapeau> I am !
May 14 09:13:58 <MarcOChapeau> wohoo 
May 14 09:14:27 <MarcOChapeau> Ainulindale: how's life ?
May 14 09:15:55 <Ainulindale> good :-)
May 14 09:16:14 <Ainulindale> Yours?
May 14 09:16:31 <MarcOChapeau> quite good too
May 14 09:16:51 <Ainulindale> Ready for FSOSHRUDCON? :-)
May 14 09:17:30 <MarcOChapeau> Ainulindale: I hope I can make it. My boss changed my schedule without warning, and I might be on duty next week-end...
May 14 09:18:42 <MarcOChapeau> Ainulindale: If I don't, I guess I'll see you at one of those bearstech meetings. Do you know if they have a date set for the buzzfix party ?
May 14 09:21:29 <MarcOChapeau> frack... It was on Mai 7th...
May 14 09:21:52 <MarcOChapeau> great... Now how do I get it fixed...
May 14 09:22:31 <rtp> MarcOChapeau: no FR was fixed during this party :/
May 14 09:22:50 <rtp> MarcOChapeau: http://bearstech.com/actualites/lapres-buzz-fix-party
May 14 09:24:59 <MarcOChapeau> rtp: ok, thanks. Just saw this article. I guess I'll subscribe to the RSS feed so I make it to the next party :)
May 14 09:49:32 <Ainulindale> Sheesh
May 14 09:49:37 <Ainulindale> Damn meeting this afternoon
May 14 10:55:55 <PaulFertser> mickey|zzZZzz: shoragan: I have a perfect opportunity to test your new debugging via TCP socket as frameworkd is not responding to DBus and nothing interesting in the log. What should i do?
May 14 10:56:41 <shoragan> PaulFertser, i think you need to enable the loophole stuff via config first, i've not used it myself though
May 14 10:57:39 <PaulFertser> shoragan: luckily i did that long time ago (it's -l command line switch actually).
May 14 10:57:42 <PaulFertser> :)
May 14 10:58:23 <shoragan> are all dbus connections broken?
May 14 10:59:31 <PaulFertser> shoragan: i guess yes. frameworkd doesn't react to Zhone, mdbus introspection is broken too.
May 14 10:59:55 <shoragan> mdbus will block at the first broken connection
May 14 11:00:02 <shoragan> could you try cli-framework?
May 14 11:00:51 <PaulFertser> shoragan: sure, just guide me through it, what should i type there?
May 14 11:01:10 <shoragan> just try i.e. usage.ListResources()
May 14 11:01:27 <shoragan> dir() to show all interfaces
May 14 11:01:54 <PaulFertser> shoragan: ListResources doesn't return.
May 14 11:02:01 <shoragan> hmm
May 14 11:02:12 <PaulFertser> Introspect error ousaged
May 14 11:02:42 <PaulFertser> shoragan: http://rafb.net/p/6LlyFV32.html
May 14 11:02:53 <PaulFertser> alphaone: ping
May 14 11:03:05 <alphaone> PaulFertser: pong
May 14 11:03:18 <PaulFertser> alphaone: probably you can help debugging?
May 14 11:03:18 <shoragan> and some other interface? device?
May 14 11:03:44 <alphaone> PaulFertser: Hmm
May 14 11:03:49 <alphaone> When did that happen?
May 14 11:03:57 <alphaone> What did the phone do before?
May 14 11:03:59 <PaulFertser> alphaone: 30 min ago.
May 14 11:04:45 <PaulFertser> Tail frameworkd.log here: http://rafb.net/p/YRAUqX36.html
May 14 11:05:36 <PaulFertser> shoragan: gsmdevice.ListResources() gives the same (with ogsmd mentioned of course).
May 14 11:05:59 <shoragan> 2009.05.14 14:12:20.231 ogsmd.server         INFO     online status now offline
May 14 11:06:13 <shoragan> i've had cases where shutting down ppp killed everything
May 14 11:06:19 <alphaone> PaulFertser: Does frameworkd respond to anything?
May 14 11:06:20 <shoragan> try strace'ing frameworkd
May 14 11:07:25 <PaulFertser> shoragan: why don't we try the integrated debugging interface? I have the -l switch. I'm just afraid to type something wrong there because i've seen it halt after improper closing of connection.
May 14 11:07:37 <PaulFertser> alphaone: it doesn't look like it.
May 14 11:08:00 <shoragan> i don't know how to use the debug interface
May 14 11:08:11 <shoragan> :/
May 14 11:08:21 <PaulFertser> shoragan: it gives interactive prompt with frameworkd controller object.
May 14 11:08:43 <shoragan> ues
May 14 11:09:00 <shoragan> but i'm not sure how we can use that to figure out the dbus stalls
May 14 11:09:57 <shoragan> pls check with strace if it is looping around some futex stuff
May 14 11:11:21 <PaulFertser> shoragan: yep, futex stuff: http://rafb.net/p/EeUF0s78.html
May 14 11:11:40 <shoragan> hmm
May 14 11:11:52 <shoragan> i've never figured out what happens there
May 14 11:12:01 <shoragan> it never woke up again
May 14 11:12:55 <PaulFertser> shoragan: so, it's python itself hanging on some futex... I can gdb to it and bt probably...
May 14 11:13:05 <shoragan> that would be nice
May 14 11:13:48 <PaulFertser> shoragan: sem_wait@@GLIBC_2.4 from PyThread_acquire_lock () from unknown function, nothing of interest :(
May 14 11:14:15 <PaulFertser> shoragan: http://rafb.net/p/C9S4Dp82.html
May 14 11:14:33 <shoragan> perhaps you need the -dbg packages
May 14 11:15:23 <PaulFertser> shoragan: only 3 functions in callstack...
May 14 11:16:26 <PaulFertser> shoragan: well, as it's python itself hanging on a futex, probably we can't do much here, can we?
May 14 11:16:32 <shoragan> yes :/
May 14 11:16:57 <shoragan> but it would be nice to know what it is waiting for
May 14 11:19:08 * PaulFertser never used futexes, has no idea how to debug... 
May 14 11:20:27 <PaulFertser> I'll wait for some more ideas, i guess those who want to contact me will do it via fixed line anyway, as i'm at home atm.
May 14 12:01:10 <tonyg> hi all. thanks for the help getting my builds working yesterday. i'm feeling much better about the situation now that i have a clean build :)
May 14 12:05:21 <tonyg> so does anyone here actually work with a GTA01?
May 14 12:05:31 <tonyg> i am wondering about if there's a need to update my uboot
May 14 12:05:41 <tonyg> it's still the one that shipped with it from the factory
May 14 12:06:31 <DocScrutinizer> hehe, PMU hangup yesterday. didn't even accept power from USB. didn't react to powerbutton.
May 14 12:32:25 <SHR-WugBranler> tracfeed: Ticket #80 (Incoming call screen should have a "Silent" button) updated <http://trac.shr-project.org/trac/ticket/80#comment:4>
May 14 12:36:33 <tonyg> hmm hmm hmm uh oh. i just flashed a kernel without checking, and it's too big for the default gta01 kernel partition
May 14 12:36:42 <tonyg> and of course the one i had on there is long gone
May 14 12:36:46 <tonyg> uh oh uh oh.
May 14 12:38:07 <tonyg> is resizing the partition table possible?
May 14 12:38:18 <tonyg> i've been searching the wiki which hints at it but doesn't describe what's involved.
May 14 12:41:08 <neomilium> tonyg: just to be sure, you are talking about mtd partition table?
May 14 12:49:57 <raster> aaaariibaaa
May 14 12:50:43 <mrmoku> raster: hey :)
May 14 12:55:02 <spaetz> twinklephone and pulseaudio lead to suttering sound on my lappie, it works fine if I stop pulseaudo
May 14 12:55:05 * spaetz is annoyed
May 14 12:55:22 <spaetz> too many layers of brokenness stacked upon each other
May 14 12:55:44 <DocScrutinizer> raster: speedy gonzales? fastest coder of mexico? :-)
May 14 12:56:05 <spaetz> arriba arriba andalee
May 14 12:56:58 <raster> mrmoku: booo!
May 14 12:56:58 <Zorkman> lol
May 14 12:57:11 <raster> DocScrutinizer: docster!
May 14 12:57:25 <DocScrutinizer> spaetz: PA is evil :-)
May 14 12:58:13 * spaetz nods. But even without PA there are too many layers of brokenness left
May 14 12:58:25 <DocScrutinizer> ack
May 14 12:58:40 <spaetz> even poor ALSA led to some stuttering (although somewhat better), using OSS makes it work jsut fine
May 14 12:59:01 <spaetz> poor alsa? I meant pure ALSA :)
May 14 12:59:10 <DocScrutinizer> though alsa is kinda useable sinc 0.13
May 14 12:59:21 <DocScrutinizer> hehe
May 14 12:59:32 <spaetz> freudian slip of the tongue :)
May 14 13:00:14 <raster> spaetz: its possibly just your netbr0k
May 14 13:02:27 <spaetz> hehe
May 14 13:02:32 <DocScrutinizer> spaetz: "using OSS"? you're talking about alsa OSS compatibility layer, no?
May 14 13:02:36 <spaetz> yep
May 14 13:03:26 <DocScrutinizer> so guess by yourself where's the problem, when adding a compatibility layer "fixes" things
May 14 13:03:59 <raster> not sure thats a problem
May 14 13:04:06 <raster> as oss is so hellishly simply
May 14 13:04:08 <raster> simple
May 14 13:04:18 <raster> maybe its emulating the frequency?
May 14 13:04:28 <raster> eg it asks for 44.1 and your sound card only does 48
May 14 13:04:34 <raster> so tis software-upsampling
May 14 13:04:41 * spaetz is a linux audio noob. Might be anything
May 14 13:04:53 <spaetz> but it's a Macbook, so the sounds card should be decent enough
May 14 13:05:18 <DocScrutinizer> usually it's a problem of alsa default implementing a stack cosnisting of dmix plugin and using a fixed samplerate to hw after this
May 14 13:05:28 <raster> spaetz: does xmms/beep-media or audacious play ok?
May 14 13:06:23 <DocScrutinizer> spaetz: you should try 'aplay -vv somefile" to understand what's actually happening
May 14 13:07:11 <spaetz> raster: yeah, plays just fine.
May 14 13:07:12 <DocScrutinizer> spaetz: the use 'aplay -D plughw:0,0 ...' to test without the whole default stack
May 14 13:07:20 <PaulFertser> raster: Hey :) Probably you have any futex experience, do you have any idea how to find out why python hangs on some futex? (i have that atm, strace and gdb available).
May 14 13:08:13 <spaetz> DocScrutinizer: works fine as well
May 14 13:08:26 <spaetz> well, I'll just use OSS compatibility layer.
May 14 13:08:28 <DocScrutinizer> hey paul! :-))) congrats
May 14 13:09:49 <max_posedon2> congrads me too, I got visa)
May 14 13:09:53 <DocScrutinizer> spaetz: problem with OSS is it blocks all other audio
May 14 13:10:24 <DocScrutinizer> max_posedon: heya! TWO success stories :-)
May 14 13:11:01 <raster> spaetz: my guess is its more likely a twinkle audio issue
May 14 13:11:08 <raster> its not keping its buffers filled as much
May 14 13:11:36 <raster> more likely because it wants to reduce lag (which mp3 players can frankly just ignore)
May 14 13:11:57 <raster> PaulFertser: uym... someoen has the futex locked?
May 14 13:12:03 <raster> or.. someone forgot to unlock it more likely
May 14 13:12:12 <raster> and thus comes the danger of threads
May 14 13:12:29 <raster> someone will always forget somewhere in some code-path
May 14 13:13:16 <DocScrutinizer> raster: spaetz: huh, twinkle? was this about twinkle??
May 14 13:13:37 <PaulFertser> raster: sure, but how to debug it now? ;)
May 14 13:14:09 <PaulFertser> DocScrutinizer: :D
May 14 13:14:21 <DocScrutinizer> oh yes, now I see
May 14 13:14:23 <raster> DocScrutinizer:  ja
May 14 13:14:36 <raster> PaulFertser: read code very carefully.thatds the only way
May 14 13:14:41 <raster> read it and know the program flow
May 14 13:14:47 <raster> look at every lock and unlock
May 14 13:15:01 <PaulFertser> raster: heh, the code of the python intepreter itself? Nice suggestion ;)
May 14 13:15:17 <DocScrutinizer> hmm, think I need to chat with spaetz. is OT here, but one of my major competence topics ;-)
May 14 13:15:24 <PaulFertser> raster: probably there's a way to ask the system about who has which futex, i was asking basically about that.
May 14 13:15:53 <raster> PaulFertser:  seriously - thats the only way i know of
May 14 13:16:07 <raster> unlike memory where u can find memoryleak debugging utils all over the place
May 14 13:16:14 <raster> thread lock debug utils - never seen one
May 14 13:16:27 <PaulFertser> raster: ok, thanks :)
May 14 13:17:04 <DocScrutinizer> PaulFertser: build a debug-executable with a wrapper around futex()
May 14 13:17:32 <DocScrutinizer> or try to simulate the same with gdb
May 14 13:18:12 <PaulFertser> DocScrutinizer: complete frameworkd lockup is not something that is easily reproducible, unfortunately.
May 14 13:18:41 <raster> PaulFertser: that will make your life even more of a bitch
May 14 13:18:47 <raster> in that case it may be easier to just read it
May 14 13:19:08 <DocScrutinizer> hmm, so probably a debug-patched exe to write each futex() call to a log is your best bet
May 14 13:19:50 <PaulFertser> DocScrutinizer: i guess i won't dare to debug python itself and it seems it's a problem inside interpreter.
May 14 13:20:26 <DocScrutinizer> hmm, writing a short wrapper for futex() isn't that hard
May 14 13:21:15 <DocScrutinizer> the logging to file might be tho, as you might find you must not access files in the context
May 14 13:22:16 <DocScrutinizer> so some mem-ringbuffer might be better, as it doesn't need any claas to sys-functions
May 14 13:22:40 <DocScrutinizer> s/claas/calls/
May 14 13:22:40 <bzzbot> DocScrutinizer meant: so some mem-ringbuffer might be better, as it doesn't need any calls to sys-functions
May 14 13:27:56 <methril|work> i see raster very happy over the channels ;)
May 14 13:28:24 <raster> bing
May 14 13:28:25 <raster> :)
May 14 13:34:11 <PaulFertser> raster: btw, do you by any chance want to comment on oFono initiative?
May 14 13:34:29 <DocScrutinizer> hmmpfff
May 14 13:35:05 <TAsn> what's the package edje-native is for?
May 14 13:35:12 <TAsn> s/is //
May 14 13:35:12 <bzzbot> TAsn meant: what's the package edje-native for?
May 14 13:35:27 <max_posedon> TAsn, it is "compiler/preprocessor"
May 14 13:35:34 <DocScrutinizer> <quote> FSO is basically an AT interface wrapped into dbus calls </quote>
May 14 13:35:47 <TAsn> max_posedon, i don't think I got you.
May 14 13:35:54 <dos1> they suck ;p
May 14 13:35:55 <DocScrutinizer> ophono :x
May 14 13:36:07 <TAsn> max_posedon, oh
May 14 13:36:11 <TAsn> I'm not talking about edje
May 14 13:36:24 <TAsn> I'm talking abouth the difference between edje and edje-native ;]
May 14 13:36:31 <TAsn> max_posedon, ^
May 14 13:36:45 <mrmoku> TAsn: edje-native is needed to have edje_cc
May 14 13:36:50 <dos1> TAsn: i think edje-native is used for compiling edje files by bitbake
May 14 13:36:55 * PaulFertser was accused of writing arrogant crap by Neovento guy. LOL
May 14 13:37:03 <TAsn> dos1, i c
May 14 13:37:10 <TAsn> so ejde-native is for staging?
May 14 13:37:31 <DocScrutinizer> wtf is neovento?
May 14 13:37:41 <mrmoku> TAsn: for bitbaking stuff that has .edc files
May 14 13:37:48 <TAsn> oh
May 14 13:38:01 <TAsn> so what's evas-native for?
May 14 13:38:22 <mrmoku> maybe evas is a dependency of edje?
May 14 13:38:33 <PaulFertser> DocScrutinizer: some Debian on Freerunner bastard, developed by some guys at web-forums.
May 14 13:38:35 <TAsn> it is.
May 14 13:38:37 <TAsn> ok nvm. ;]
May 14 13:39:58 <DocScrutinizer> PaulFertser: maybe you should ignore them?
May 14 13:42:12 * DocScrutinizer just cares about kernel, middleware (=fso), and some apps running on a decent win-manager/X
May 14 13:43:24 <raster> PaulFertser: ofono. i dont know enough about it to say. what i suspect though is. in reality, unless FSO can get an actual hw vendor that ships more than a token small shipment of phones (ie has to ship > 100k units), fso will have an uphill battle in gaining acceptance :( don't get me wrong. my heart is in so and wanting it to succeed, but i am facing reality here :(
May 14 13:44:19 <raster> other than that i cannot comment on the "their api vs vfo's api".
May 14 13:48:16 <tonyg> neomilium, yep the NAND flash partitions
May 14 13:48:29 <PaulFertser> DocScrutinizer: i'm not offended, it's just funny.
May 14 13:48:36 <DocScrutinizer> I can comment on some chats with "rationale" why they didn't like to contribute to FSO rather than inventing wheel again (see above quote): nausea
May 14 13:48:42 <PaulFertser> raster: have you read Harald's post about it?
May 14 13:49:09 <raster> PaulFertser:  actually no.
May 14 13:49:30 <PaulFertser> DocScrutinizer: have you read my "interview" with Holtmann? It seems like he is so open-source minded that he can't even understand the questions about free software.
May 14 13:49:32 <raster> i havent been online much the past 2 weeks
May 14 13:49:47 <PaulFertser> raster: http://laforge.gnumonks.org/weblog/2009/05/12#20090512-ophono_fso it's small
May 14 13:50:04 <DocScrutinizer> PaulFertser: nope
May 14 13:50:09 <tonyg> neomilium, looks like maybe "mtdparts" when i'm connected to the uboot prompt is what i need?
May 14 13:50:12 <PaulFertser> (or i'm bad at questioning)
May 14 13:50:29 <tonyg> at least, http://wiki.openmoko.org/wiki/NetBSD is the best i've found so far on the topic of resizing partitions
May 14 13:51:32 <raster> PaulFertser: no new info there.
May 14 13:51:43 <raster> standard opinion aroun the fso etc. parts
May 14 13:51:51 <raster> ie why not just use fso and work on it/ help improve it
May 14 13:51:52 <PaulFertser> DocScrutinizer: http://logs.nslu2-linux.org/livelogs/ofono.txt
May 14 13:52:09 <raster> and the obvious - both nokia and intel are envisagng linux phone in the future
May 14 13:52:22 <PaulFertser> raster: do you think it's ok to prepare a competing project under the covers without even discussing it with the FSO team?
May 14 13:52:34 <raster> PaulFertser:  its a free world
May 14 13:52:40 <PaulFertser> raster: i just consider it uber-unfriendly. That's not how you treat fellow developers.
May 14 13:52:41 <raster> how dare i do enlightenment
May 14 13:52:45 <raster> it compted with fvwm
May 14 13:52:57 <raster> i should have collaboratd with fvwm's author
May 14 13:53:15 <raster> or how dare gnome exist - it didnt want to collaborate with e and e existed first
May 14 13:53:27 <raster> etc.
May 14 13:53:30 <PaulFertser> Wrong analogy, imho. Not the same situation at all.
May 14 13:53:36 <raster> i dont think its a valid argument
May 14 13:53:41 <raster> oh its the same
May 14 13:53:52 <raster> its a competing piece of software
May 14 13:53:53 <methril|work> well, i don't like the assumptions, what in what way it differ?
May 14 13:53:54 <raster> simple as that
May 14 13:54:07 <methril|work> s/it/they 
May 14 13:54:15 <raster> it may have saved work andavoided a split
May 14 13:54:19 <raster> if they had workd with fso
May 14 13:54:32 <TAsn> who forked?
May 14 13:54:37 <methril|work> yes, but the same as you post with the other sw
May 14 13:54:41 <raster> but no way can you go around saying that no oneshould ever think of comptition
May 14 13:55:13 <methril|work> the main problem as i see is that there is so many frameworks for telephony but the most open is fso
May 14 13:55:16 <raster> and to be honest
May 14 13:55:27 <raster> fso has no market penetration worth talking about at themoment
May 14 13:55:36 <raster> so regardless of the technical side
May 14 13:55:43 <raster> they arent going up against an installbase
May 14 13:55:44 <raster> :(
May 14 13:55:47 <methril|work> sadly :(
May 14 13:55:48 <raster> as is aid
May 14 13:55:50 <raster> dont get me wrong
May 14 13:55:54 <raster> my heard lies with fso
May 14 13:55:58 <raster> i am simply being objctive
May 14 13:56:12 <raster> no one should EVER be told NOT to develop software
May 14 13:56:15 <raster> een if its a fork
May 14 13:56:16 <TAsn> who forked what?
May 14 13:56:17 <raster> or competition
May 14 13:56:23 <raster> even if it fragmnts
May 14 13:56:38 <raster> without competition you would not get innovation
May 14 13:56:50 <raster> and you are simply telling peole that they have their own freedoms limited
May 14 13:56:55 <methril|work> but it could be so polite to ask and argue and try to help....
May 14 13:56:58 <TAsn> (it seems that someone forked fso, though I don't get who and why and when and what to)
May 14 13:57:03 <raster> they same freedoms open source espouses, you are denying to developers
May 14 13:57:17 <raster> denying their freedom to do "what they want with their code. time and effort"
May 14 13:57:19 <methril|work> TAsn: is not a fork, is a new implementation (ofono)
May 14 13:57:26 <DocScrutinizer> PaulFertser: yup, that's been my <quote>
May 14 13:57:35 <DocScrutinizer> May 12 07:17:10 <holtmann> I am aware of FSO, but we think their API is putting to much knowledge into the UI. From our point of view it should be really simple to write phone applications like dialer, text msg or integrate it with existing apps. Keywords like customization and branding of the UI come to mind.
May 14 13:57:35 <raster> TAsn: www.ofono.org
May 14 13:57:41 <TAsn> thanks.
May 14 13:58:10 <PaulFertser> DocScrutinizer: i've asked him more questions later.
May 14 13:58:20 <DocScrutinizer> May 12 07:17:31 <holtmann> The FSO API is basically a AT command set converted into a D-Bus API.
May 14 13:59:22 <DocScrutinizer> PaulFertser: I stopped reading after this nonsense comment. There's no use in listening to idiots spreading FUD
May 14 13:59:42 <PaulFertser> raster: The way they do it is just unfair imho. They're backed up by Intel and Nokia, so they might win regardless technical arguments.
May 14 14:00:09 <raster> PaulFertser: bingo
May 14 14:00:16 <raster> but welcom to the real world 
May 14 14:00:18 <raster> its NOT fair
May 14 14:00:29 <raster> those with more money can pay mroe engineers to develop things faster
May 14 14:00:29 <methril|work> maybe if they give this arguments the $$$ of the project goes down
May 14 14:00:31 <raster> or develop more
May 14 14:00:37 <raster> thaey can buy mrketing and publicity
May 14 14:00:51 <raster> that is... unfrotunately... life.
May 14 14:00:51 <TAsn> any advantages over fso? (ofono)
May 14 14:00:52 <methril|work> they bougth marketing and publicity :)
May 14 14:01:14 <raster> thats the benefit of mony
May 14 14:01:16 <raster> money
May 14 14:01:17 <methril|work> everybody is talking about it
May 14 14:01:20 <raster> in the end it all coms down to money
May 14 14:01:24 <raster> TAsn: no idea
May 14 14:01:30 <PaulFertser> raster: Marcel should have enforced fair play. Imagine you're going to play with a weak person. And if you feel that you're stronger you should enforce fairness yourself. Marcel should have done it personally.
May 14 14:01:31 <TAsn> anything exists?
May 14 14:01:46 <raster> PaulFertser: this is businss
May 14 14:01:58 <TAsn> let's hope this announcement will speed up fso's development ;]
May 14 14:02:00 <PaulFertser> TAsn: read the link, there holtmann gives a technical comparision talking with shoragan.
May 14 14:02:00 <raster> there is no such tnhing as giving those smaller/weakr a far go
May 14 14:02:13 <raster> you compete for the most dollars as hardas you can within the law.
May 14 14:02:13 <PaulFertser> TAsn: http://logs.nslu2-linux.org/livelogs/ofono.txt
May 14 14:02:18 <raster> thats business.
May 14 14:02:31 <raster> of course how you play will change yur perception by customers
May 14 14:02:32 <PaulFertser> raster: My brother wouldn't do that to me, you know.
May 14 14:02:40 <raster> and they may stop buying your products if they hate you
May 14 14:02:42 <PaulFertser> raster: i'm talking about Marcel personally.
May 14 14:03:04 <TAsn> PaulFertser, wow, that's long! ;]
May 14 14:03:05 <raster> but tere are no such things as iving a smaller waker company a bonus chance
May 14 14:03:07 <PaulFertser> My friend would have warned me in advance, you know.
May 14 14:03:08 <raster> PaulFertser:  this is not personal
May 14 14:03:09 <TAsn> will read, sec.
May 14 14:03:17 <raster> he has ben instructed by his company to work on a solution
May 14 14:03:20 <raster> and he is doingit
May 14 14:03:25 <PaulFertser> raster: imagine my brother working for Intel. He would have warned me for sure.
May 14 14:03:28 <raster> the way he believes is best
May 14 14:03:30 <raster> thats his job
May 14 14:03:39 <raster> this has nothingto do with brothers
May 14 14:03:41 <raster> its notfamily
May 14 14:03:57 <raster> and as best i know
May 14 14:04:04 <raster> \marcel has had squat diddly to do with fso
May 14 14:04:09 <raster> he isnt related in any way
May 14 14:04:16 <raster> he has no stake in fso
May 14 14:04:23 <DocScrutinizer> obviousle he is incompetent then, as he's not understanding nature of FSO
May 14 14:04:25 <raster> nor has he contributed to it nor does he use it
May 14 14:04:32 * raster shrugs
May 14 14:04:51 <raster> i dont think its fair that you tell people how to do things
May 14 14:04:52 <raster> its his job
May 14 14:04:54 <raster> his life
May 14 14:04:56 <raster> his career
May 14 14:05:05 <raster> its his business
May 14 14:05:09 <raster> if you really care
May 14 14:05:10 <neomilium> I'm trying to build an FSO based distro using instructions provided at http://wiki.openmoko.org/wiki/Building_FSO, but if it seems easy on wiki, "make fso-gta02-milestone5.5-image" or "make fso-gta02-testing-image" doesn't work... Is wiki up to date ? Is there are problems in current FSO git ? OpenEmbedded related ?
May 14 14:05:13 <raster> make sure fso succeeds
May 14 14:05:19 <DocScrutinizer> his incompetence, his image
May 14 14:05:39 <raster> DocScrutinizer: lets see. i have not looked at ofon's api nore fso's and comapred
May 14 14:05:45 <raster> so i cant say if he is or isnt incompetent
May 14 14:05:49 <raster> or has made a good call
May 14 14:06:02 <DocScrutinizer> see quote above, raster
May 14 14:06:04 <PaulFertser> DocScrutinizer: in fact, emdete, the leader of pyneo project likes oFone API as it's similar to pyneo's.
May 14 14:06:21 <raster> DocScrutinizer: i cantcomment on it
May 14 14:06:23 <raster> i dont know.
May 14 14:06:26 <PaulFertser> raster: All good people are brothers.
May 14 14:06:41 <DocScrutinizer> PaulFertser: :-D
May 14 14:06:47 <PaulFertser> raster: especially free software programers.
May 14 14:07:15 <raster> PaulFertser: so - by that logic i need to inform nokia of all my advances and work in grahics so they can compete farily?
May 14 14:07:24 <PaulFertser> One might like his brother or not. But he mustn't screw him.
May 14 14:07:30 <raster> i need to give all other wm authors a heads u on what i'm doing
May 14 14:07:31 <raster> and how i do it
May 14 14:07:40 <DocScrutinizer> obviously intel and nokia are exploiting FOSS for business purposes
May 14 14:07:41 <raster> and allow them to guide me and help them compte?
May 14 14:07:46 <raster> dont be silly.
May 14 14:07:53 <raster> its not my businss nor my job or responsibility.
May 14 14:08:06 <raster> DocScrutinizer: of course they are. eery company does that uses it.
May 14 14:08:15 <PaulFertser> raster: i'd prefer to be silly then.
May 14 14:08:31 <PaulFertser> And your case is absolutely different. Really.
May 14 14:08:35 <raster> PaulFertser:  it sint
May 14 14:08:41 <raster> its just a more ESTABLISHEd case
May 14 14:08:48 <DocScrutinizer> raster: yup. but it's determining factor for their mindset
May 14 14:08:50 <raster> its been around for a decade+
May 14 14:09:41 <neomilium> Hey, enjoyed by ofono and/or FSO guys (raster, PaulFertser or Doc) ;) . Could you give me some hints around my problem, please ?
May 14 14:09:59 <DocScrutinizer> well, at least it lines up neatly with android etc
May 14 14:10:19 <tonyg> neomilium, what specifically is failing
May 14 14:10:25 <tonyg> i went through getting the build to work yesterday
May 14 14:10:52 <neomilium> ERROR: 'Projets/Openmoko/Distributions/FSO/build/fso-testing/openembedded/recipes/glibc/glibc_2.6.1.bb' failed
May 14 14:10:57 <PaulFertser> neomilium: i don't recommend you to try to build FSO distro.
May 14 14:11:05 <PaulFertser> neomilium: you know, FSO isn't into distro business.
May 14 14:11:21 <PaulFertser> neomilium: You better follow SHR instructions to build SHR and it'll include FSO as well.
May 14 14:11:41 <neomilium> What do you recommend to use as developement environment on GTA02 ?
May 14 14:11:44 <tonyg> neomilium, are you using mokomakefile or the more manual git checkout etc?
May 14 14:11:44 <PaulFertser> neomilium: or try to find out how Angus (nytowl) builds his OM2009 images.
May 14 14:11:54 <raster> DocScrutinizer:  android isnt even linux so it doesnt count
May 14 14:11:57 <raster> it mayaswell be symbian
May 14 14:12:00 <raster> or wince
May 14 14:12:11 <raster> hell - bsd is closer
May 14 14:12:13 <DocScrutinizer> sure
May 14 14:12:29 <neomilium> tonyg: I try to use FsoMakefile
May 14 14:12:41 <neomilium> I'll switch one mokomakefile
May 14 14:12:57 <DocScrutinizer> anyway... bbl
May 14 14:13:09 <neomilium> or try PaulFertser advice: use SHR
May 14 14:13:18 <PaulFertser> neomilium: and btw don't expect that building OE is easy. There're always some stupid obstacles :-/
May 14 14:13:38 <tonyg> maybe try shr. i tried mokomakefile, but actually prefer the more manual setup, since then at least i know what's going on under the hood :)
May 14 14:13:43 <tonyg> PaulFertser, amen to that
May 14 14:13:51 <tonyg> yesterday's stupid obstacles for me were caused by a stale wiki
May 14 14:13:54 <tonyg> i've updated it a bit
May 14 14:14:09 <PaulFertser> tonyg: SHR by hand is a bit harder because they use some hack they call "SHR overlay".
May 14 14:14:11 <tonyg> actually neomilium if you like we can work on making the wikipage better?
May 14 14:14:14 <neomilium> Why guys prefers OE as OpenWrt... OpenWrt have a powerful build and packages system...
May 14 14:14:32 <tonyg> no silver bullet re build systems i'm afraid
May 14 14:14:33 <PaulFertser> But anyway i'd recommend to read makefiles, be it SHRMakefile or FSOMakefile...
May 14 14:15:13 <tonyg> this is the page i updated following my experiences yesterday: http://wiki.openmoko.org/wiki/OpenEmbedded
May 14 14:15:25 <PaulFertser> neomilium: and btw your error message lacks necessary details. You need to find out why it fails to build.
May 14 14:15:33 <neomilium> tonyg: I'll be happy to do that, but I can only improve wiki page if I found a way to do my stuff ^^
May 14 14:18:55 <tonyg> :) well i'm happy to help to the best of my ability
May 14 14:19:05 <neomilium> PaulFertser: build system try to execute : /home/romuald/Projets/Openmoko/Distributions/FSO/build/fso-testing/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.6.1-r15/locale-tree/bin/localedef and "file" command on it give me: "ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped"... conclusion this build process try to execute ARM code on x86, 
May 14 14:19:07 <neomilium> isn't it ?
May 14 14:19:08 <tonyg> i should mention the last time i did any serious OM dev was at the beginning of 2008
May 14 14:20:06 <tonyg> well, the NetBSD page's instructions on resizing the mtd partition table seemed to work OK
May 14 14:20:15 <tonyg> uploading a kernel to my new partitions has worked
May 14 14:20:18 <tonyg> the rootfs is going up now
May 14 14:20:24 <tonyg> then i'll restore the splash backup
May 14 14:20:42 <tonyg> and hope like hell i didn't brick anything :)
May 14 14:21:29 <neomilium> tonyg: I already had partition size problem on mtd, and would like to warn you about: reflash bootloader will override mtdparts... If it could help..
May 14 14:22:15 <tonyg> thanks
May 14 14:22:20 <tonyg> i've never attempted reflashing uboot
May 14 14:22:25 <tonyg> i'm still on the factory one!
May 14 14:22:33 <tonyg> i'm just updating the kernel and rootfs
May 14 14:23:15 <tonyg> actually: when I use cu to talk to the uboot runtime, it echoes (and presumably processes?) one keystroke behind my typing. does anyone else see that?
May 14 14:26:49 <PaulFertser> neomilium: i'm not sure, i told you building OE is tricky sometimes. Probably you need to disable locale generation or smth.
May 14 14:27:32 <PaulFertser> neomilium: in fact OE tries to do locale generation in Qemu ARM virtual machine.
May 14 14:27:47 <DocScrutinizer> reflashing bootloader overrides mtdparts? wtf?
May 14 14:29:10 <alphaone> DocScrutinizer: http://totalueberwachung.de/~alphaone/cgi-bin/analyze-long-term-trace.cgi
May 14 14:29:13 <alphaone> :-)
May 14 14:29:23 <alphaone> I now have a Freerunner connected to my server
May 14 14:29:48 * tonyg really wishes rootfs upload was faster
May 14 14:30:23 * TAsn really wishes it won't check all the .bbs all the time.
May 14 14:30:51 <alphaone> DocScrutinizer: Raw trace available here: http://totalueberwachung.de/~alphaone/openmoko/ti_calypso-1024-long-term-trace
May 14 14:33:20 <methril|work> tonyg: if we have USB2.0 speeds.....
May 14 14:33:39 <tonyg> heh
May 14 14:35:20 <tonyg> wow wow wow it's booting
May 14 14:35:27 <tonyg> x may even be starting
May 14 14:35:34 <tonyg> yay
May 14 14:36:28 <tonyg> illume looks lovely
May 14 14:36:32 <DocScrutinizer> alphaone: looks good
May 14 14:36:51 <DocScrutinizer> alphaone: tantalum, or 22uF ceram-C?
May 14 14:38:11 <tonyg> where's the dialer? in base fso
May 14 14:38:14 <tonyg> illume
May 14 14:39:27 <alphaone> DocScrutinizer: It's one of the 22µF caps used near the PCF
May 14 14:39:34 <alphaone> DocScrutinizer: So MO-CAP 22uF 6.3V 20% SMT0805 X5R H=1.45mm(MAX) CV21X5R226M06AT AVX/KYOCERA LR
May 14 14:39:48 <DocScrutinizer> X5R is good
May 14 14:40:28 <DocScrutinizer> iirc
May 14 14:41:05 <alphaone> C1708 or C1709
May 14 14:42:41 <DocScrutinizer> alphaone: you considered further about ambient light sensor?
May 14 14:43:44 <TAsn> raster, any ready made right aligned text elements I can check?
May 14 14:44:12 <CIA-75> SHR: 03tom 07shr-overlay * r40443658ab5c 10/patches/efl1/ (0001-rtl-patch.patch 0001-rtl-support-evas-edje.patch): fix evas-native and edje-native so they won't break in new builds, applied the patches to them as well
May 14 14:45:18 <mrmoku> TAsn: NO... not again ;)
May 14 14:45:32 <TAsn> you don't have to rebuild
May 14 14:45:36 <mrmoku> :)
May 14 14:45:37 <TAsn> it's a fix for new builds
May 14 14:45:56 <TAsn> since evas-native requires evas_svn.bb
May 14 14:46:01 <TAsn> since evas-native requires evas.inc *
May 14 14:46:14 <TAsn> and edje-native requires edje_svn.bb
May 14 14:46:18 <TAsn> edje got patched
May 14 14:46:20 <TAsn> and evas didn't
May 14 14:46:25 <TAsn> so he wouldn't compile
May 14 14:46:35 <mrmoku> ok
May 14 14:46:41 <alphaone> DocScrutinizer: Not really
May 14 14:46:47 <alphaone> Nothing concrete anyway
May 14 14:46:50 <TAsn> complaining about missing functions.
May 14 14:47:03 <TAsn> mrmoku, anyhow, finally after tracking this issue
May 14 14:47:11 <DocScrutinizer> k, me away for foodhunting now
May 14 14:47:12 <TAsn> i'm testing libframework-phonegui-efl
May 14 14:47:15 <TAsn> char counting patch
May 14 14:49:05 <dos1> so... i've read ofono discussion...
May 14 14:49:08 <mrmoku> we should also fix that 'don't split long SMS' issue before release...
May 14 14:49:27 <TAsn> mrmoku, and the support for longer than 1 sms
May 14 14:49:34 <TAsn> mrmoku, we should probably clean trac.
May 14 14:49:48 <mrmoku> yo :)
May 14 14:49:59 <TAsn> preferably all, though major+ must be resolved
May 14 14:50:03 <dos1> for me it looks like ofono is for playing with GSM, and FSO is for doing real smartphones stuff
May 14 14:50:04 <dos1> ;x
May 14 14:50:25 <TAsn> dos1, they said they initially wanted to wrap around ogsmd iirc
May 14 14:51:38 <dos1> TAsn: but they know almost nothing about FSO...
May 14 14:51:52 <TAsn> dos1, I also got this impression
May 14 14:52:09 <TAsn> it looked like he doesn't know what's he's talking about
May 14 14:52:30 <TAsn> dos1, we lost a potential contributor, though still, may the best man win.
May 14 14:53:31 <dos1> TAsn: contributor*s*. there will be uncombatible apps writen for ofono after all...
May 14 14:53:43 <TAsn> dos1, let's hope not. ;]
May 14 14:54:04 <TAsn> though as raster said earlier, it's like the gtk/qt/e/whatever battle.
May 14 14:54:08 <dos1> i was waiting for death of ASU in people minds...
May 14 14:54:25 <TAsn> it only improved our lives ];
May 14 14:54:26 <TAsn> ;]
May 14 14:54:50 <dos1> TAsn: some people was developing for ASU instead of FSO
May 14 14:55:22 <TAsn> dos1, i think, fso was the first decent framework for developers in all of mokos history
May 14 14:55:33 <TAsn> I don't see why people actually bothered to develop for asu
May 14 14:55:36 * mrmoku thinks we should worry less... work harder... and build the best phone ever ;D
May 14 14:55:42 <TAsn> mrmoku, duh. ;]
May 14 14:55:56 <TAsn> mrmoku, I swear, I'm not slacking off, my code is compiling...
May 14 14:56:00 <dos1> TAsn: i was hoping to get one unified stardard - and then be able to use any app with my phone system
May 14 14:56:08 <mrmoku> dos1: what about your code? ;)
May 14 14:56:16 <mrmoku> ahh... forgot... python... no need to compile :P
May 14 14:56:31 <TAsn> dos1, wishes rarely come true ;]
May 14 14:57:14 <dos1> TAsn: i know, but... we could also write our own dbus...
May 14 14:57:23 <dos1> why we didn't? ;p
May 14 14:57:25 <TAsn> dos1, sounds like a great idea ;]
May 14 14:57:29 <TAsn> dos1, lack of time?
May 14 14:57:30 <TAsn> ;]
May 14 14:58:37 <TAsn> (it seems like you are in advance state of shock, just to make sure, I WAS JOKING!)
May 14 14:58:54 <mrmoku> DocScrutinizer: found food? 
May 14 14:58:59 <mrmoku> DocScrutinizer: restarted my twinkle efforts...
May 14 14:59:09 <mrmoku> DocScrutinizer: still hanging at ccrtp
May 14 14:59:11 <mrmoku> No package 'libccgnu2' found
May 14 15:05:22 <CIA-75> SHR: 03ptitjes 07libmodulo * r11fc92c68130 10/src/ (modulo-api.vala modulo-container.vala): Use Gee.Set<string> in place of string arrays
May 14 15:16:22 <CIA-75> SHR: 03ptitjes 07libmodulo * re58d8060365d 10/src/ (modulo-component-manager.vala modulo-container.vala): - Removed some unused code
May 14 15:16:22 <CIA-75> SHR: 03ptitjes 07libmodulo * r5e5d2f7d9b83 10/src/ (2 files): Fix unhandled errors
May 14 15:16:24 <dos1> TAsn: it wasn't shock - it was just disconnect ;)
May 14 15:19:33 <mrmobil> dos1, with dhcp for usb connman is much nicer :)
May 14 15:20:53 <mrmobil> lets see if it automatically switches when i come back to my pc
May 14 15:21:51 * dos1 has a flu
May 14 15:22:11 <tonyg> *is* there a dialer for FSO (bitbake fso-illume-image)?
May 14 15:22:37 <mrmobil> zhone?
May 14 15:22:38 <dos1> mrmobil: that would be good news ;)
May 14 15:22:44 <dos1> tonyg: zhone
May 14 15:22:56 <tonyg> mrmobil, dos1, thanks
May 14 15:23:07 <tonyg> not included with base installation -- build and upload time i guess :) ta
May 14 15:23:16 <alphaone> tonyg: That would be fso-zhone-image then
May 14 15:23:23 <dos1> tonyg: or paroli
May 14 15:23:29 <tonyg> alphaone, aha thanks
May 14 15:23:40 <dos1> or SHR stuff, which is on top of FSO too
May 14 15:24:01 <tonyg> i may as well simply concentrate on dusting off my erlang stuff directly i guess
May 14 15:25:39 <alphaone> tonyg: What are you doing in erlang?
May 14 15:26:09 <mrmobil> hmm... got an ip but defaultroute did not change...
May 14 15:27:13 <tonyg> alphaone, http://wiki.openmoko.org/wiki/User:TonyGarnockJones -- note that that is status as of early 2008
May 14 15:27:21 <tonyg> and it's rotted a fair bit since then
May 14 15:29:27 <alphaone> tonyg: So are you planning on developing something parallel to framework?
May 14 15:29:54 <alphaone> tonyg: If so please provide the same DBus API. See http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/index.html;hb=HEAD
May 14 15:32:40 <ptitjes|tv> mrmoku: hello
May 14 15:32:49 <mrmoku> ptitjes|tv: hey
May 14 15:32:57 <ptitjes|tv> mrmoku: any progress with ophonekitd/vala ?
May 14 15:32:58 <ptitjes|tv> :)
May 14 15:33:35 <mrmoku> ptitjes: still having a problem with gobject-introspection...
May 14 15:33:42 <ptitjes> arf
May 14 15:34:15 <mrmoku> it is looking for system/usr/include... as include path :(
May 14 15:34:28 <ptitjes> mrmoku: I wanted to build it on my side yesterday
May 14 15:34:39 <ptitjes> but you didn't commit your recipes did you ?
May 14 15:34:55 <mrmoku> heh.. no
May 14 15:35:10 <mrmoku> maybe I should.... wanted to have it build first
May 14 15:35:26 <ptitjes> I think I can help you on this pb but I would need the recipe :)
May 14 15:35:48 <ptitjes> mrmoku: 1 request before you commit
May 14 15:36:12 <mrmoku> ptitjes: yep?
May 14 15:36:15 <ptitjes> mrmoku: could you put libfso-glib in the freesmartphone directory and ophonekitd in the shr one plz ?
May 14 15:36:41 <mrmoku> ptitjes: I don't have access to the freesmartphone directory...
May 14 15:36:58 <ptitjes> mrmoku: in the overlay ?
May 14 15:37:18 <mrmoku> is there a freesmartphone directory? hmm can add it if not...
May 14 15:37:44 <ptitjes> mrmoku: indeed there is one in oe (this is where vala-dbus-binding-tool is :))
May 14 15:37:57 <mrmoku> in oe.. yes
May 14 15:38:02 <mrmoku> but not in the overlay IIRC
May 14 15:38:40 <ptitjes> mrmoku: ok but when moving to oe, libfso should be in recipes/freesmartphone/ so why not put it straight away :)
May 14 15:39:00 <mrmoku> ptitjes: yeah... will add it
May 14 15:39:18 <ptitjes> mrmoku: muchas gracias
May 14 15:39:24 <mrmoku> ptitjes: denada
May 14 15:39:29 <ptitjes> :)
May 14 15:45:32 <TAsnn> where are the packages list of opkg located at?
May 14 15:46:14 <tonyg> alphaone, there's certainly stuff to learn from the dbus api, but since I'm working in pure erlang and am using erlang's internal messaging, i'm unlikely to try to reach out to non-erlang systems yet. it's an experiment in getting erlang to control as much of the system as possible
May 14 15:46:33 <mrmoku> ptitjes: you have to rebuild with the new stuff then...
May 14 15:46:37 <ptitjes> mrmoku and others: are there any reason not to put a road map on a git (or any vcs) ?
May 14 15:46:49 <ptitjes> mrmoku: commited ? :)
May 14 15:47:03 <mrmoku> ptitjes: not yet :(
May 14 15:47:35 <ptitjes> mrmoku: so I didn't understand "you have to rebuild with the new stuff then..."
May 14 15:48:12 <mrmoku> ptitjes: will commit a shr distro conf file... and you will have to rebuild from scratch with it
May 14 15:48:22 <ptitjes> cool
May 14 15:48:25 <mrmoku> ptitjes: just give me some minutes...
May 14 15:48:28 <ptitjes> np
May 14 15:48:32 <ptitjes> take your time
May 14 15:48:43 <ptitjes> doing thirteen things at the same time ;)
May 14 15:49:38 <ptitjes> guys after some weeks I am very happy of my laptop choice, I had to say it
May 14 15:49:44 <ptitjes> and I'm proud of it ;)
May 14 15:50:07 <ptitjes> (the choice not the laptop... or maybe both :))
May 14 15:50:25 <DocMobilizer> dd to /media/card: error 110 on rw-cmd, response 0x0, cardstatus 0x400d00;  glamo-mci.0 error after cmd 0xc120
May 14 15:50:35 <dos1> ptitjes: oh no! you brain is being eaten by mac!!!
May 14 15:50:36 <dos1> ;D
May 14 15:50:40 <dos1> s/you/your/
May 14 15:50:46 <ptitjes> héhéhé :)
May 14 15:50:49 <dos1> or your soul
May 14 15:50:52 <dos1> or even both ;)
May 14 15:51:01 <ptitjes> dos1: I have best of both worlds :)
May 14 15:51:19 <ptitjes> dos1: the interface and the gentoo in a vbox :)
May 14 15:51:56 <alphaone> tonyg: Okay, well have fun anyway :-)
May 14 15:52:01 <dos1> ptitjes: i don't like mac os x interface... but it's your crap... err, choice ;)
May 14 15:52:06 <ptitjes> dos1: in fact I am an afficionados of Mac since the first bougth by my parents...
May 14 15:52:44 <ptitjes> dos1: in 1988! but you wasn't born, were you ? :)
May 14 15:52:44 <CIA-75> SHR: 03mok 07shr-overlay * rc6c45cc77b36 10/openembedded/conf/distro/include/shr-autorev-unstable.inc: autorev: add libframeworkd-phonegui-gtk2
May 14 15:52:55 <CIA-75> SHR: 03mok 07shr-overlay * ra3776df6ee16 10/openembedded/conf/distro/shr.conf: add a shr distro config
May 14 15:53:01 <dos1|neo> oh
May 14 15:53:19 <dos1> ptitjes: 4 years later ;)
May 14 15:53:36 <ptitjes> dos1: you are from the geek generation
May 14 15:54:06 <ptitjes> dos1: you grew with a computer, did you ?
May 14 15:54:40 <ptitjes> (dos1: this is just my curiosity...)
May 14 15:54:58 <ptitjes> (no offense)
May 14 15:55:16 <dos1> mrmoku: is build from scratch supposed to work now?
May 14 15:55:22 <dos1> ptitjes: no problem ;)
May 14 15:55:31 <dos1> ptitjes: yep, you are right
May 14 15:55:42 <mrmoku> dos1: missing some stuff in the overlay still... need some more minutes
May 14 15:55:42 <ptitjes> nice
May 14 15:55:52 <ptitjes> mrmoku: pffffff
May 14 15:55:54 <ptitjes> :D
May 14 15:56:04 <TAsnn> dos1, you were born in 1992?
May 14 15:56:11 <dos1> TAsnn: yep
May 14 15:56:14 <TAsnn> cool.
May 14 15:56:19 <TAsnn> younger than my younger brother ;]
May 14 15:58:29 <mrmoku> the one that crashed your car? is he still alive? :P
May 14 15:58:31 <tonyg> alphaone, for sure :-)
May 14 15:58:34 * DocMobilizer heads away on his wheelchair, mumbling swearwords about glamo-mci interface
May 14 15:58:44 <mrmoku> hehe
May 14 15:58:46 <TAsnn> mrmoku, I'm checking my patch for char counting on phonegui-efl when the time comes i'll ask you to apply it to efl2 so you can also test it, ok? ;]
May 14 15:58:51 <TAsnn> mrmoku, yeah, he is alive.
May 14 15:59:02 <mrmoku> TAsnn: ok
May 14 15:59:10 <TAsnn> cool, thanks.
May 14 15:59:12 <alphaone> DocMobilizer: Wheelchair?
May 14 15:59:27 <TAsnn> since I don't yet use efl2
May 14 15:59:32 <mrmoku> grr... looks like I lost my patch to popt by 'make update-openembedded' :(
May 14 15:59:45 <mrmoku> ptitjes: will have to eat first... and commit the rest after that, sorry
May 14 16:00:05 <DocMobilizer> well, *1992 makes me feel like thats the right metapher
May 14 16:00:08 * mrmoku --> dinner
May 14 16:00:42 <ptitjes> mrmoku: gut apetiten
May 14 16:00:46 <TAsnn> DocMobilizer, hehe, I agree. ;]
May 14 16:01:10 <alphaone> DocMobilizer: Hehe
May 14 16:02:00 <DocMobilizer> FSCK sdcard-io errors anyway :-(
May 14 16:04:43 <DocMobilizer> prolly have to tweak sdio-driverpower to kick tthose 16G addresslines :-/
May 14 16:06:45 <CIA-75> SHR: 03tom 07shr * r4d7300fce75a 10/libframeworkd-phonegui-efl/src/view/message-new-view.c: added a fix for character counting error, bug #396
May 14 16:08:17 <TAsnn> mrmoku, please apply on efl2 as well. ;]
May 14 16:08:18 <SHR-WugBranler> tracfeed: Ticket #396 (The messages app doesn't count characters correctly.) updated <http://trac.shr-project.org/trac/ticket/396#comment:4> || Ticket #396 (The messages app doesn't count characters correctly.) closed <http://trac.shr-project.org/trac/ticket/396#comment:3>
May 14 16:08:22 <TAsnn> easy fix, mostly the same.
May 14 16:08:37 <TAsnn> the patch will probably just work.
May 14 16:10:10 <CIA-75> SHR: 03tom 07shr-overlay * r2f0586898296 10/openembedded/recipes/shr/libframeworkd-phonegui-efl_git.bb: bumped phonegui-efl PV
May 14 16:10:36 <dos1> TAsnn: you don't have to bump PV
May 14 16:10:45 <TAsnn> i meant rev
May 14 16:10:46 <dos1> TAsnn: only when modifing recipe itself
May 14 16:10:54 <TAsnn> but ok
May 14 16:10:59 <TAsnn> should I revert?
May 14 16:11:01 <dos1> hmm
May 14 16:11:06 <dos1> moment
May 14 16:11:36 <dos1> s/PV/PR/ :P
May 14 16:11:44 <dos1> and you can revert if you want
May 14 16:12:10 <dos1> but i don't think it's necessary. it shouldn't change anything
May 14 16:12:14 <TAsnn> ok
May 14 16:12:41 <dos1> TAsnn: i will apply on efl2. can you confirm it's tested and works? ;)
May 14 16:13:21 <TAsnn> dos1, tested on works on efl1
May 14 16:13:33 <TAsnn> as for efl2 it's a minor change
May 14 16:13:38 <TAsnn> so it shouldn't break anything
May 14 16:14:00 <TAsnn> it's mostly the same, just the function hearer is different (type-wise, though it's easily adoptable)
May 14 16:14:16 <TAsnn> I just don't want to apply something I haven't tested...
May 14 16:14:59 <dos1> TAsnn: +    /*FIXME: BAD BAD BAD! will cause an overflow when using a long translation!!! */
May 14 16:14:59 <dos1> +    sprintf(text, D_("%d characters left [%d]"), limit - (len % limit), (len / limit) + 1);
May 14 16:15:03 <dos1> i think it should be just commented
May 14 16:15:14 <TAsnn> huh?
May 14 16:15:26 <TAsnn> what should be commented?
May 14 16:15:31 <dos1> that sprintf
May 14 16:15:41 <dos1> oh
May 14 16:15:43 <dos1> sorry
May 14 16:15:48 <TAsnn> ...
May 14 16:15:50 <TAsnn> ;]
May 14 16:15:56 <dos1> that's not that printf which i mean ;D
May 14 16:15:57 <TAsnn> it shouldn't be hard to handle
May 14 16:16:13 <TAsnn> just didn't feel like doing it late last night ];
May 14 16:16:17 <TAsnn> =)
May 14 16:16:20 <dos1> you already commented it
May 14 16:16:21 <dos1> g_debug("content: %s", content);
May 14 16:16:22 <dos1> ;)
May 14 16:16:25 <TAsnn> and no time now.
May 14 16:16:49 <TAsnn> dos1, was plain annoying since you already had that in gui...
May 14 16:17:05 <dos1> TAsnn: i know. it was annoying me too ;)
May 14 16:17:11 <TAsnn> :)
May 14 16:17:55 <dos1> string_strip_html(content);
May 14 16:18:12 <TAsnn> dos1, took it from efl2
May 14 16:18:18 <TAsnn> assumed someone did it correct there
May 14 16:18:22 <TAsnn> didn't feel like checking anything
May 14 16:18:26 <TAsnn> or fixing anything
May 14 16:18:28 <dos1> that line tells me, that i have to test it ;x
May 14 16:18:36 <TAsnn> just added the correct handling ;]
May 14 16:18:53 <dos1> i think it was removed from efl1 before efl2 was created
May 14 16:18:55 <dos1> but i can be wrong
May 14 16:19:23 <TAsnn> oh, so if you can restore it to efl1 as well
May 14 16:19:26 <TAsnn> whatever you decide ;]
May 14 16:19:36 <TAsnn> I thought efl2 was more recent, therefore I based my code on that.
May 14 16:19:41 <dos1> TAsnn: no problem
May 14 16:19:58 <dos1> TAsn: efl2 is just fork with opimd support, nothing else ;)
May 14 16:20:26 <TAsn> I don't know git that good
May 14 16:20:38 <TAsn> though there must be a way to update efl2 automatically when efl updates
May 14 16:21:03 <TAsn> so you'll make the non opimd specific changes to efl2
May 14 16:21:06 <TAsn> so you'll make the non opimd specific changes to efl1
May 14 16:21:13 <TAsn> and the specific ones to efl2
May 14 16:21:26 <TAsn> or at least everyone should dev on efl1 and update efl2 when needed
May 14 16:22:07 <TAsn> actually, as I told Ainulindale yesterday, I think using #ifdef is way more subtle comparing to a fork.
May 14 16:22:37 <dos1> TAsn: ATM efl2 is more like playground...
May 14 16:22:52 <TAsn> i c.
May 14 16:24:26 <TAsn> dos1, man, this fix is a life savior (for me) I used to loose sms because they were longer than 1 sms
May 14 16:24:37 <TAsn> no indication of any kind this happened, just an sms drop.
May 14 16:26:59 <khiraly1> nytowl: there?
May 14 16:28:24 <khiraly1> where is freesmartphone installed?
May 14 16:29:20 <khiraly1> ok. got it
May 14 16:32:03 <nytowl> khiraly1, huh ?
May 14 16:32:37 <khiraly1> what is the easiest to overwrite an older FSO in the current image?
May 14 16:32:51 <khiraly1> easiest way
May 14 16:33:10 <nytowl> where are you getting the new fso from ?
May 14 16:33:12 <lindi-> khiraly1: use your package manager?
May 14 16:33:17 <khiraly1> I want to test different freesmartphone version, to identify if the slowdon comes from freesmartphone itself
May 14 16:33:32 <dos1> khiraly1: which image?
May 14 16:33:57 <khiraly1> http://downloads.openmoko.org/distro/unstable/NeoFreerunner/fso-paroli-image-om-gta02.tar.gz
May 14 16:34:09 <khiraly1> yesterday's and a week older
May 14 16:34:20 <khiraly1> I have all the two here at my computer
May 14 16:34:23 <nytowl> khiraly1, where are you planning to get the different version from ?
May 14 16:34:33 <nytowl> ah as ipkgs ?
May 14 16:34:35 <TAsn> dos1, any eta for opimd? or at least some part of opimd? I mean we can always use a part opimd a part sim phonegui-efl until it'll be completely ready...
May 14 16:35:04 <khiraly1> I have two fso-paroli-image-om-gta02.tar.gz file. I want to overwrite files from one tar.gz into other
May 14 16:35:23 <khiraly1> is it possible? freesmartphone is simple python. So it seems possible
May 14 16:35:34 <dos1> TAsn: right now there is only adding new fields to existing contact left
May 14 16:35:42 <dos1> TAsn: which isn't implemented in actual gui
May 14 16:35:48 <TAsn> ok
May 14 16:36:01 <TAsn> so it's usable?
May 14 16:36:14 <TAsn> I think we should start moving one step at a time
May 14 16:36:14 <nytowl> unzip them on your desktop and scp them form usr/lib/python2.6/site-packages/frameworkd
May 14 16:36:35 <TAsn> and not wait for everything
May 14 16:36:45 <TAsn> because opimd has many wanted features
May 14 16:36:59 <khiraly1> nytowl: /usr/lib/python2.6/site-packages/framework/ <-- can I simply overwrite it?
May 14 16:37:58 <nytowl> and copy over /usr/binframeworkd
May 14 16:37:58 <nytowl> khiraly1, have you done a top when you see this slowdown ?
May 14 16:38:07 <nytowl> khiraly1, should work
May 14 16:38:35 <dos1> TAsn: we have to init sim backend in ophonekitd
May 14 16:38:50 <dos1> TAsn: and then we can use name resolving via opimd
May 14 16:39:11 <dos1> TAsn: and after fixing segfaults - use opimd in contact list
May 14 16:39:20 <TAsn> ok
May 14 16:39:23 <TAsn> I see, long time left.
May 14 16:39:25 <TAsn> ;]
May 14 16:41:41 <khiraly1> nytowl: yepp. When calling python process 45% cpu and 18% mem
May 14 16:42:31 <nytowl> khiraly1, is it the process number of framework or paroli ?
May 14 16:42:41 <khiraly1> when idle, python 0.0% and 16.4% mem
May 14 16:42:50 <khiraly1> paroli has its own name
May 14 16:42:59 <khiraly1> i think
May 14 16:43:57 <khiraly1> i have paroli process 1652, and python's pid 1555
May 14 16:44:21 <khiraly1> so yes, I assume the python process is freesmartphone
May 14 16:45:34 <nytowl> khiraly1, it's captured in the logs you sent earlier
May 14 16:45:49 <khiraly1> which line?
May 14 16:46:41 <nytowl> that was a question , the logs you sent earlier was when the sytem was showing  the slowness you describe
May 14 16:46:55 <khiraly1> yepp. The slowness is always there
May 14 16:46:58 <khiraly1> right now too
May 14 16:47:07 <khiraly1> when I call it does not ring
May 14 16:47:23 <nytowl> and speechd is not running 
May 14 16:47:36 <khiraly1> so I could search in the current /var/log/frameworkd.log for specifics
May 14 16:48:16 <khiraly1> i do not find any speechd in the .log file
May 14 16:48:28 <nytowl> khiraly1, is speechd or navit installed ?
May 14 16:48:38 <nytowl> opkg list_installed
May 14 16:48:41 <dos1> nytowl: speech-dispatcher
May 14 16:48:50 <khiraly1> navit surely not, it is vanilla om2009
May 14 16:48:54 <nytowl> dos1, oops thx
May 14 16:49:26 <khiraly1> neither
May 14 16:49:31 <khiraly1> no navit and no speechd
May 14 16:49:39 <khiraly1> opkg list_installed |grep navit
May 14 16:49:41 <nytowl> if you issue a AT+CGMR using mickeyterm what does it return
May 14 16:49:43 <khiraly1> opkg list_installed |grep speech
May 14 16:50:07 <khiraly1> +CGMR: "GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11"
May 14 16:50:30 <khiraly1> OK
May 14 16:50:48 <nytowl> hmm , ok I have to run now but will look at the logs later on
May 14 16:51:00 <khiraly1> but where are the pid number in the log?
May 14 16:52:04 <khiraly1> there is no difference between the two /usr/bin/frameworkd, no need to overwrite it
May 14 16:53:20 <khiraly1> ok. Im going to overwrite /usr/lib/python2.6/site-packages/framework and see
May 14 17:03:32 <ptitjes> mrmoku: the distro conf is nice
May 14 17:24:16 <qknight> hey
May 14 17:24:39 <qknight> http://rafb.net/p/usvpx939.html <- this is my opkg update
May 14 17:24:43 <qknight> why does it not work?
May 14 17:26:15 <dos1> qknight: configure usb networking correctly...
May 14 17:31:09 <qknight> right
May 14 17:31:17 <qknight> dos1: ok, thanks!
May 14 17:38:23 <qknight> now i could install navit, how nice
May 14 17:39:04 <qknight> oh, nothing changed
May 14 17:39:08 <qknight> navit still does not work
May 14 17:39:09 <qknight> ;P
May 14 17:39:49 <qknight> is shr testing made to be used with 'opkg update; opkg upgrade"?
May 14 17:41:03 <dos1> qknight: it may work, but ATM noone checks it and fix if it doesn't
May 14 17:41:17 <dos1> qknight: we will handle upgrades after first release
May 14 17:41:22 <qknight> k
May 14 17:41:32 <qknight>  * ERROR: Cannot satisfy the following dependencies for frameworkd-config-shr-dev:
May 14 17:41:35 <qknight>          *  frameworkd-config-shr (= 0.8.5.1+gitr1365+668dde7d810425fefc3c885ef4f7f2eb5034f698-21+99525cd5cd631a9b3e66381fcbda43a271163b3a-r5) *
May 14 17:41:38 <qknight> r
May 14 17:41:41 <qknight> ;P
May 14 17:45:07 <qknight> i have a strannge bug
May 14 17:45:32 <qknight> somehow the widgets can be moved in their rendering box
May 14 17:45:35 <dos1> qknight: it's normal, that package needs to be rebuilded on server
May 14 17:45:46 <dos1> qknight: it's not bug, it's a feature :P
May 14 17:45:47 <dos1> really
May 14 17:45:53 <dos1> it's finger scrolling
May 14 17:46:05 <qknight> but i can't 'reenable' the auto-suspend
May 14 17:46:07 <dos1> we only need to block scrolling in y-axis in shr-settings
May 14 17:46:14 <qknight> because instead of moving the slider the widget is moving ;P
May 14 17:46:21 <dos1> qknight: move quickly
May 14 17:46:22 <dos1> :D
May 14 17:46:32 <qknight> no way
May 14 17:46:35 <qknight> it's borken here
May 14 17:46:38 <qknight> i have a question
May 14 17:46:48 <qknight> can these settings also be switched by a command line?
May 14 17:47:23 <mrmoku> ptitjes: well... it is basically a copied openmoko.conf ;)
May 14 17:47:45 <ptitjes> but it is nice
May 14 17:47:55 <qknight> dos1: i wonder if the gui is so slow on your installation as well
May 14 17:48:05 <qknight> dos1: i looks like playing a opengl game using mesa
May 14 17:48:12 <dos1> qknight: with X11-16 it isn't that slow
May 14 17:48:16 <qknight> dos1: all widgets and sliders are very slow
May 14 17:48:28 <qknight> dos1: what is x11-16?
May 14 17:48:40 <dos1> qknight: rendering engine
May 14 17:48:41 <dos1> google for it
May 14 17:48:46 <qknight> ah ok
May 14 17:50:10 <qknight> how to enable etk-engines-software-x11-16?
May 14 17:50:58 <qknight> found nothing using google
May 14 17:51:20 <qknight> http://wiki.openmoko.org/wiki/Edje_examples <- this?
May 14 17:51:24 <qknight> op.add_option("-e", "--engine", type="choice", choices=("x11", "x11-16"), default="x11-16",
May 14 17:51:37 <dos1> no
May 14 17:51:42 <dos1> you're not interested in etk
May 14 17:51:56 <dos1> it's just env ELM_ENGINE = x11-16
May 14 17:52:04 <mrmoku> ptitjes: have do redo the patch for popt and add that one and one for glib to the overlay
May 14 17:52:05 <dos1> and one setting in illume wrench
May 14 17:52:09 <dos1> (SOFTWARE_16)
May 14 17:52:36 <ptitjes> oki
May 14 17:53:39 <qknight> dos1: where to write that? i nwhich config file?
May 14 17:54:15 <dos1> qknight: if you are using neo, you should know ;)
May 14 17:54:22 <dos1> you can export ELM_ENGINE in /etc/profile
May 14 17:54:39 <dos1> and software_16 you can set from gui
May 14 17:55:06 <qknight> in the settings?
May 14 17:55:28 <TAsn> qknight, wrench in the shelf
May 14 17:55:29 <TAsn> ...
May 14 17:57:29 <qknight> can't find
May 14 17:57:34 <qknight> damn mobile
May 14 17:57:38 <qknight> never mind
May 14 17:57:42 <qknight> don't wast your time
May 14 17:57:44 <qknight> just go on
May 14 17:57:45 <qknight> thanks
May 14 18:00:07 <TAsn> can't find the wrench?
May 14 18:00:11 <TAsn> or the settings?
May 14 18:01:21 <TAsn> wrench -> advanced -> engine
May 14 18:01:28 <TAsn> and choose software_16 there.
May 14 18:06:43 <CIA-75> SHR: 03mok 07shr-overlay * r9b557324f31c 10/patches/popt/0001-popt-do-not-try-to-install-non-existing-static-lib.patch: patches: add patch to make newer popt build
May 14 18:06:49 <mrmoku> ptitjes: ok... next the gobject-instrospection thingies...
May 14 18:06:51 <CIA-75> SHR: 03mok 07shr-overlay * rb0683deeb454 10/patches/glib-native/0001-glib-native-stage-glibconfig.h-in-libdir-too.patch: patches: add patch to make glib-native stage glibconfig.h in libdir too
May 14 18:06:52 <CIA-75> SHR: 03mok 07shr-overlay * r77f5231d3833 10/patches/python/0001-python-native-build-with-ctypes.patch: patches: add patch from mickey to build python-native with ctypes
May 14 18:09:48 <SHR-WugBranler`> tracfeed: Ticket #438 (problem gnome-config->dbus) updated <http://trac.shr-project.org/trac/ticket/438#comment:1>
May 14 18:11:48 <SHR-WugBranler`> tracfeed: Ticket #432 (Broken line breaks) closed <http://trac.shr-project.org/trac/ticket/432#comment:2>
May 14 18:12:30 <dos1> mrmoku: build from scratch is supposed to work now? ;)
May 14 18:13:49 <SHR-WugBranler`> tracfeed: Ticket #436 (No autosuspend/autodimming when not touching touchscreen.) closed <http://trac.shr-project.org/trac/ticket/436#comment:2>
May 14 18:16:17 <TAsn> dos1, can I opkg upgrade to get the fix for 432?
May 14 18:16:33 <dos1> TAsn: i think yes
May 14 18:16:37 <dos1> it works for me
May 14 18:16:43 <TAsn> cool, thanks.
May 14 18:16:48 <TAsn> that was amazingly annoying ;]
May 14 18:17:03 <TAsn> dos1, btw, did you patch efl2?
May 14 18:17:10 <dos1> TAsn: no
May 14 18:17:15 <TAsn> okie.
May 14 18:17:28 <DocScrutinizer> TAsn: 436 was, ack
May 14 18:17:44 <TAsn> DocScrutinizer, I wanna see it in my own eyes ;]
May 14 18:17:50 <TAsn> I think I saw the commit earlier
May 14 18:17:52 <dos1> DocScrutinizer: it's closed as upstream :P
May 14 18:18:21 <DocScrutinizer> hehe, seems I need to update eventually
May 14 18:18:48 <dos1> it's #410 on FSO trac
May 14 18:19:39 <TAsn> dos1, 432 not fixed here.
May 14 18:19:57 <dos1> TAsn: unstable of course?
May 14 18:19:58 <mrmoku> dos1: should... change distro to shr in auto.conf
May 14 18:20:01 <TAsn> dos1, duh.
May 14 18:20:10 <TAsn> dos1, though I might broke something
May 14 18:20:16 <TAsn> so I can't really tell ;]
May 14 18:20:22 <TAsn> I mean it may not upgrade because of me
May 14 18:20:31 <TAsn> hm.. gimme a sec.
May 14 18:21:14 <TAsn> mrmoku, did you build it after my char counting fix or before?
May 14 18:21:31 <TAsn> hm.. seems like before.
May 14 18:21:50 <TAsn> (pv=30)
May 14 18:22:54 <CIA-75> SHR: 03mok 07shr-overlay * r82d554b41c86 10/openembedded/recipes/gobject-introspection/ (3 files): add (not yet working) recipes for gobject-introspection
May 14 18:23:23 <mrmoku> TAsn: did not build, no
May 14 18:23:38 <TAsn> mrmoku, oh, so there's still no fix? just potential?
May 14 18:23:40 <TAsn> ;]
May 14 18:24:09 * mrmoku looks at TAsn's fix now ;)
May 14 18:24:41 <TAsn> mrmoku, ;]
May 14 18:25:00 <TAsn> dos1, what do you think about #157? should be close as fix, right?
May 14 18:25:08 <TAsn> (the illume left and right arrows do just that)
May 14 18:26:07 <TAsn> mrmoku, as I told you, I didn't patch efl2
May 14 18:26:42 * mrmoku likes it when people comment stuff :D
May 14 18:27:27 <TAsn> mrmoku, this is very intuitive, no need for extra commenting
May 14 18:27:41 <TAsn> though I did explain what I think that may be broken.
May 14 18:27:56 <TAsn> (not with my code, but with the all approach)
May 14 18:27:57 <mrmoku> TAsn: hey... was a compliment for the comments you *did* do :)
May 14 18:28:05 <TAsn> mrmoku, oh, ok ;]
May 14 18:28:07 <TAsn> thanks.
May 14 18:28:10 <mrmoku> regarding other broken code ;)
May 14 18:28:37 <TAsn> mrmoku, I got blind when I saw the "char buf[64]" or what ever it was.
May 14 18:31:41 <SHR-WugBranler`> tracfeed: Ticket #121 (Support of long SMSes) updated <http://trac.shr-project.org/trac/ticket/121#comment:6>
May 14 18:33:00 <TAsn> mrmoku, for bug #121: http://shr.bearstech.com/trac/ticket/121#comment:7
May 14 18:33:53 <SHR-WugBranler`> tracfeed: Ticket #121 (Support of long SMSes) updated <http://trac.shr-project.org/trac/ticket/121#comment:7>
May 14 18:34:03 <TAsn> dos1, I think it's safe to close #268 what do you think?
May 14 18:35:01 <dos1> TAsn: yep, close
May 14 18:35:42 <TAsn> okie.
May 14 18:37:01 <mrmoku> TAsn: (121) yes... have to do it ourselves then
May 14 18:37:02 <SHR-WugBranler`> tracfeed: Ticket #291 (long press on AUX button : do "something" ?) updated <http://trac.shr-project.org/trac/ticket/291#comment:5>
May 14 18:37:34 <TAsn> mrmoku, yep.
May 14 18:37:51 <onen> hi everyone
May 14 18:37:53 <TAsn> while you are at it, please consider making chat-like sms
May 14 18:37:55 <TAsn> ;]
May 14 18:38:16 <mrmoku> hehe... I said *ourselves* ... not *myself* ;)
May 14 18:38:17 <SHR-WugBranler`> tracfeed: Ticket #268 (kernel - 2.6.24-oe5+gitrfb42ce6724576fc173faf8abfb04aa2c36d213b7-r0) closed <http://trac.shr-project.org/trac/ticket/268#comment:2>
May 14 18:38:56 <TAsn> mrmoku, sh.. ;]
May 14 18:39:05 <onen> questions to European people: I am looking at buying a laptop. but in France, you cannot easily get one without the os from redmond at main resellers (dell, etc...). Is it possible in your country?
May 14 18:39:05 <mrmoku> ptitjes: (roadmap repo) I think that is a good idea... have a git repo for our documents...
May 14 18:39:08 <TAsn> Ainulind1le, please consider fixing 335
May 14 18:40:07 <ptitjes> mrmoku: oh yes having a repo for documents, sure. but I was thinking about keeping the roadmap for each projects in the git for that project, just like TODO
May 14 18:40:13 <TAsn> sorting the tickets a bit.
May 14 18:40:34 <mrmoku> ptitjes: ahh - misunderstood you then :)
May 14 18:40:45 <TAsn> anyhow mrmoku, dos1 what do you think about 157?
May 14 18:41:05 <TAsn> I think the illume left and right suffice
May 14 18:41:07 <SHR-WugBranler`> tracfeed: Ticket #330 (add minimo to the repository) updated <http://trac.shr-project.org/trac/ticket/330#comment:1>
May 14 18:41:09 <TAsn> and do exactly that.
May 14 18:41:37 <mrmoku> TAsn: how do you catch them?
May 14 18:41:50 <TAsn> and can someone please explain #126? I don't get it, I only have one list, here to get.
May 14 18:41:54 <TAsn> mrmoku, catch what?
May 14 18:42:00 <mrmoku> left to right?
May 14 18:42:04 <mrmoku> or right to left?
May 14 18:42:21 <TAsn> (I think I don't get the joke) :]
May 14 18:42:48 <mrmoku> TAsn: #157... going back by swiping with the finger from right to left
May 14 18:42:59 <mrmoku> you asked what I would think about #157, no?
May 14 18:43:04 <dos1> TAsn: i think we should close it as wontfix
May 14 18:43:14 <TAsn> mrmoku, oh
May 14 18:43:19 <TAsn> I'm talking about the illume shelf
May 14 18:43:21 <TAsn> right button
May 14 18:43:23 <TAsn> left button
May 14 18:43:26 <TAsn> much better than sliding
May 14 18:43:31 <TAsn> and already exists
May 14 18:43:39 <mrmoku> regarding #126... once upon a time... there were folders
May 14 18:43:43 <dos1> no, it doesn't exist
May 14 18:43:53 <TAsn> dos1, close enough, don't you think?
May 14 18:43:58 <dos1> arrows in illume just switches between windows
May 14 18:44:00 <TAsn> the window switching
May 14 18:44:01 <TAsn> yeah
May 14 18:44:10 <TAsn> oh
May 14 18:44:14 <TAsn> he wants to close windows
May 14 18:44:17 <dos1> TAsn: try to do that when writing message
May 14 18:44:20 <dos1> :P
May 14 18:44:21 <TAsn> ic, well yeah, won't fix.
May 14 18:44:28 <TAsn> dos1, I do that all the time. ;]
May 14 18:44:36 <TAsn> in order to read what the other party wrote.
May 14 18:44:50 <TAsn> mrmoku, so I'm also closing #126
May 14 18:45:26 <dos1> TAsn: but check your written message when you select recipients in that way
May 14 18:45:28 <dos1> ;)
May 14 18:45:43 <mrmoku> we should take a look at quickdevs code... anybody remembers why he deactivated the folders?
May 14 18:45:58 <dos1> mrmoku: because we are using only inbox now?
May 14 18:46:29 <TAsn> dos1, why is that?
May 14 18:46:40 <dos1> TAsn: cause we don't have opimd support?
May 14 18:46:41 <dos1> ;)
May 14 18:46:59 <SHR-WugBranler`> tracfeed: Ticket #157 (Default behavior for going back) closed <http://trac.shr-project.org/trac/ticket/157#comment:1>
May 14 18:47:36 <TAsn> dos1, doesn't the simcard keep them?
May 14 18:47:39 <TAsn> dos1, well, whatever.
May 14 18:47:57 <dos1> TAsn: i can only have 20 messages on sim card
May 14 18:48:09 <dos1> storing sent messages would be overkill
May 14 18:48:10 <SHR-WugBranler`> tracfeed: Ticket #126 (Opening messages/folders is currently cumbersome) closed <http://trac.shr-project.org/trac/ticket/126#comment:2>
May 14 18:48:10 <mrmoku> dos1: well... there is also sent messages, no?
May 14 18:48:15 <TAsn> what about the timestamps and epoch bugs in messages?
May 14 18:48:23 <dos1> mrmoku: we don't store sent messages
May 14 18:48:24 <TAsn> mrmoku, you fixed those, right?
May 14 18:48:40 <mrmoku> dos1: aren't those stored on SIM automatically?
May 14 18:48:48 <dos1> mrmoku: no
May 14 18:48:54 <TAsn> they are
May 14 18:48:56 <mrmoku> TAsn: partly me... partly dos1 :)
May 14 18:48:59 <TAsn> though they are erase
May 14 18:49:01 <TAsn> d
May 14 18:49:04 <TAsn> after they are sent.
May 14 18:49:19 <TAsn> mrmoku, nvm the details, they are fixed, right?
May 14 18:49:25 <mrmoku> ahh... ok... then folders are clearly opimd stuff
May 14 18:49:36 <mrmoku> TAsn: I thinks so :P
May 14 18:49:39 <mrmoku> dos1: fixed?
May 14 18:49:52 <dos1> mrmoku: it works for me
May 14 18:49:52 <TAsn> ok marking as fixed.
May 14 18:50:05 <mrmoku> ptitjes: did you start building?
May 14 18:50:55 <ptitjes> mrmoku: yeah I'm trying to cope with Required build target 'gobject-introspection' has no buildable providers.
May 14 18:50:56 <SHR-WugBranler`> tracfeed: Ticket #349 (time in SMSes is GMT instead of GMT+1) closed <http://trac.shr-project.org/trac/ticket/349#comment:9> || Ticket #205 (SMS Timestamps set to Unix Epoch) closed <http://trac.shr-project.org/trac/ticket/205#comment:11>
May 14 18:51:33 <ptitjes> I don't have python-dev ??
May 14 18:51:34 <mrmoku> ptitjes: try gobject-introspection-native...
May 14 18:51:49 <mrmoku> isn't native the one that is needed?
May 14 18:51:58 <mrmoku> I did not yet work on the target one
May 14 18:52:00 <ptitjes> yeah first you're right
May 14 18:52:33 <ptitjes> mrmoku: do you have an ophonekitd one ?
May 14 18:52:57 * mrmoku checks...
May 14 18:52:59 <SHR-WugBranler`> tracfeed: Ticket #342 ([shr-testing 20090303] tangogps segfaults when changing Cache Dir) updated <http://trac.shr-project.org/trac/ticket/342#comment:3>
May 14 18:53:07 <TAsn> dos1, mrmoku, what do you think should be done with bugs like 361?
May 14 18:53:16 <TAsn> seems old and outdated.
May 14 18:53:34 <ptitjes> hummmm :) libffi :)
May 14 18:53:40 <mrmoku> ptitjes: no... never got that far...
May 14 18:53:52 <mrmoku> before we need libfso-glib, no?
May 14 18:54:04 <mrmoku> s/before/first/
May 14 18:54:05 <bzzbot> mrmoku meant: first we need libfso-glib, no?
May 14 18:54:41 <TAsn> mrmoku, dos1, also 353
May 14 18:54:44 <TAsn> seems old
May 14 18:55:08 <ptitjes> mrmoku: yeah and libfso does not depend on g-i
May 14 18:55:09 <SHR-WugBranler`> tracfeed: Ticket #361 (Unable to close a phone call and GSM failure) updated <http://trac.shr-project.org/trac/ticket/361#comment:1>
May 14 18:55:18 <TAsn> will leave 353 open though.
May 14 18:55:54 <mrmoku> ptitjes: ok... will do that one then... is there already something somewhere?
May 14 18:56:10 <mrmoku> I thought Deubeuliou was building against it...
May 14 18:56:14 <ptitjes> mrmoku: I think playya did one
May 14 18:56:15 <dos1> TAsn: 353 looks like invalid for me
May 14 18:56:38 <mrmoku> ptitjes: ahh.. yeah found it
May 14 18:56:41 <TAsn> dos1, I think it's just a symptom of the "busy"in framework bug.
May 14 18:56:43 <mrmoku> trying now
May 14 18:56:56 <dos1> TAsn: i don't think so
May 14 18:56:59 <TAsn> dos1, btw, 416 looks fixed
May 14 18:57:07 <dos1> busy bug is only after resume
May 14 18:57:29 <ptitjes> mrmoku: I would need a template to help you. what recipes does use vala and makes libraries, deploy vapi,... ?
May 14 18:57:35 <TAsn> (booting my moko to test, for some reason it was off)
May 14 18:57:54 <mrmoku> ptitjes: good question...
May 14 18:58:09 <mrmoku> ptitjes: libeflvala?
May 14 18:59:31 <onen> shoragan: ping
May 14 18:59:41 <onen> alphaone: ping
May 14 19:00:02 <TAsn> just tested
May 14 19:00:09 <TAsn> 416 isn't working here
May 14 19:00:16 <TAsn> although it's claimed to be fixed upstream.
May 14 19:00:25 <TAsn> in a rev lower than ours
May 14 19:00:26 <TAsn> (e)
May 14 19:00:44 <onen> ptitjes: hi. car sharing section added to wiki
May 14 19:00:54 <mrmoku> ptitjes: playas recipe is not perfect :P
May 14 19:00:56 <mrmoku> 0002 mok@mrdenker[pts/7]:~/src/other/openmoko/shrbuild/shr/shr-unstable-> find tmp/deploy/glibc/ipk/ -name libfso\*     
May 14 19:01:00 <mrmoku> tmp/deploy/glibc/ipk/armv4t/libfso-glib-dev_0.0.1-gitr22+28f8a574abd532fd8d6b0cd0800f44583813256b-r0_armv4t.ipk
May 14 19:01:03 <mrmoku> tmp/deploy/glibc/ipk/armv4t/libfso-glib-dbg_0.0.1-gitr22+28f8a574abd532fd8d6b0cd0800f44583813256b-r0_armv4t.ipk
May 14 19:01:12 <mrmoku> or is it correct that there is just a dev package?
May 14 19:01:35 <ptitjes> just sources ?
May 14 19:02:00 <SHR-WugBranler`> tracfeed: Ticket #416 (elementary_alarm doesn't handle dst) updated <http://trac.shr-project.org/trac/ticket/416#comment:4>
May 14 19:02:03 <mrmoku> did not look into the package...
May 14 19:02:16 <ptitjes> onen: oh??
May 14 19:02:16 <mrmoku> thinking about it... maybe its correct?
May 14 19:02:46 <mrmoku> ptitjes: does libfso-glib contain an actual lib that is needed when running?
May 14 19:03:37 <TAsn> mrmoku, what do you think about 290?
May 14 19:03:38 <SHR-WugBranler`> tracfeed: Ticket #426 (opendoom + duke3d) updated <http://trac.shr-project.org/trac/ticket/426#comment:1>
May 14 19:03:57 <TAsn> isn't the acceleration e offers enough?
May 14 19:04:08 <onen> ptitjes: ???
May 14 19:04:33 <mrmoku> ptitjes: added it anyway...
May 14 19:04:37 <CIA-75> SHR: 03mok 07shr-overlay * rbf59437fe756 10/openembedded/recipes/freesmartphone/libfso-glib_git.bb: add recipe for libfso-glib
May 14 19:05:09 <mrmoku> TAsn: (290) well... personally I use my finger to scroll... so :P
May 14 19:05:29 <TAsn> mrmoku, I mean, it's a won't fix
May 14 19:05:29 <ptitjes> thank you moku
May 14 19:05:49 <TAsn> because the scrolling is good
May 14 19:06:02 <TAsn> for especially long lists, there's the suggestion to have letters on the right
May 14 19:06:07 <TAsn> which is way better
May 14 19:06:09 <mrmoku> if you ask me... yes wontfix
May 14 19:06:22 <mrmoku> yep... shorter lists is the way to go
May 14 19:06:31 <TAsn> ok, if Ainulind1le will ask me I'll tell him it was you ;]
May 14 19:07:10 <mrmoku> and I will tell him to check the track log... to see who has comitted the crime for real ;)
May 14 19:10:00 <SHR-WugBranler`> tracfeed: Ticket #290 (wider scrol bar = finger friendly) closed <http://trac.shr-project.org/trac/ticket/290#comment:1>
May 14 19:10:56 <mrmoku> ptitjes: heh... libfso-glib... not good ;)
May 14 19:10:57 <mrmoku> NOTE: nothing to compile
May 14 19:11:04 <mrmoku> is the complete compile log :P
May 14 19:11:36 <ptitjes> hum mrmoku it seems I have something different than you http://pastebin.com/d64e8030e
May 14 19:12:12 <mrmoku> ptitjes: you did not rm tmp... did you?
May 14 19:12:34 <mrmoku> ptitjes: ahh... and did you modify auto.conf? exchange openmoko with shr?
May 14 19:12:53 <ptitjes> hola
May 14 19:13:20 <ptitjes> because of the libtol change
May 14 19:13:33 * mrmoku hopes ptitjes' macbook is *FAST* ;)
May 14 19:13:57 <TAsn> dos1, btw, please don't make opimd depend on sim registration, make it detect changes in sim registration and then using it as a source, it should also work when there's no sim.
May 14 19:14:20 <dos1> TAsn: it doesn't depend
May 14 19:14:24 <ptitjes> hehehe
May 14 19:14:25 <TAsn> cool ;]
May 14 19:14:27 <dos1> TAsn: only SIM backend will depend
May 14 19:14:36 <TAsn> duh.
May 14 19:14:42 <dos1> all other backends are inited at startup now
May 14 19:14:51 <TAsn> though it'll auto-load upon registration.
May 14 19:15:20 <TAsn> dos1, ok, but there's a unified interface to get contacts that's not back-end dependent, right?
May 14 19:15:46 <dos1> TAsn: yep
May 14 19:16:04 <mrmoku> ptitjes: what are the dependencies for libfso-glib? vala-native? something else?
May 14 19:16:28 <TAsn> btw
May 14 19:16:33 <ptitjes> mrmoku: ideally this should use the fso specs
May 14 19:16:45 <TAsn> in my opinion, we should have a notification shelf gadget
May 14 19:16:52 <ptitjes> important configure var SPECS_PATH
May 14 19:16:53 <SHR-WugBranler`> tracfeed: Ticket #198 (Turning off the GSM modem, should result in a 'not active' GSM icon in the ...) updated <http://trac.shr-project.org/trac/ticket/198#comment:5>
May 14 19:16:57 <TAsn> one that's entirely controlled by dbus calls
May 14 19:17:08 <TAsn> you can make it show a missed call icon, new msg icon
May 14 19:17:11 <mrmoku> ptitjes: ahh... so we need a recipe for the specs?
May 14 19:17:12 <TAsn> etc etc
May 14 19:17:16 <TAsn> what do you think?
May 14 19:17:37 <mrmoku> ptitjes: or is it a remote path?
May 14 19:17:49 <ptitjes> mrmoku: set SPECS_PATH=path/to/fso-specs/ and it will bind the XML descriptions to Vala source files in the makefile
May 14 19:18:06 <ptitjes> mrmoku: arf no I did not implemented that :)
May 14 19:18:13 <mrmoku> ptitjes: which means we need a recipe for the specs...
May 14 19:18:15 <ptitjes> mrmoku: but if you have specs in oe...
May 14 19:18:16 <sypher7> TAsn: i was actually thinking about that the other night. it could be a generic notification service that could probably even do alarms and stuff
May 14 19:18:32 <mrmoku> ptitjes: checking now...
May 14 19:18:43 <playya_> should it be possible to provide 2 git repos in SRC_URI?
May 14 19:18:55 <TAsn> sypher7, not sure about alarms, I don't like the idea of a daemon-panel gadget, though it can certainly get notified to show an alarm
May 14 19:19:01 <mrmoku> ptitjes: no... need to write a recipe for them
May 14 19:19:18 <TAsn> It will do everything concerning notifications ;]
May 14 19:19:30 <playya_> and then a do_configure_prepend(){SPECS_PATH=${D}/specs}
May 14 19:19:32 <mrmoku> what would be the correct place to put them? usr/share/fso-specs?
May 14 19:19:41 <sypher7> TAsn: i like that idea, and dbus-driven seems like the logical choice
May 14 19:19:55 <mrmoku> playya_: EXTRA_OECONF ?
May 14 19:19:57 <TAsn> sypher7, yeah, since the moko is dbus driven ;]
May 14 19:20:06 <sypher7> right :-P
May 14 19:20:48 <TAsn> shit
May 14 19:20:49 <playya_> mrmoku, EXTRA_OECONF afaik appends flags to configure
May 14 19:21:05 <TAsn> I don't remember where is the source code for the gsm gadget
May 14 19:21:11 <ptitjes> hum it was already SHR ;)
May 14 19:21:13 <TAsn> any idea? (inside e's svn)
May 14 19:21:49 <ptitjes> mrmoku: starting it again from scratch now :/
May 14 19:22:36 * ptitjes goes walking
May 14 19:22:50 <TAsn> ok found it.
May 14 19:22:51 <TAsn> nvm
May 14 19:25:56 <mrmoku> ptitjes: you need the xml or the xml.in?
May 14 19:26:13 <playya_> the xml in specs/xml
May 14 19:26:27 <playya_> ok. we need 2 recipes
May 14 19:26:50 <TAsn> ok, I'm off to bed, I hope I did enough mayhem in trac, night.
May 14 19:27:17 <mrmoku> TAsn: thanks... good work
May 14 19:28:00 <TAsn> all I did is closing old tickets... I wish I had the time to close "real" bugs.
May 14 19:28:30 <mrmoku> playya_: fso-specs and libfso-glib you mean?
May 14 19:28:47 <playya_> yes
May 14 19:29:26 <playya_> maybe fso-specs should only be a builddep
May 14 19:29:43 <playya_> they aren't needed on the device
May 14 19:29:47 <mrmoku> how do you specify a builddep?
May 14 19:30:28 <playya_> i don't know if it possible to define it
May 14 19:30:30 <SHR-WugBranler`> tracfeed: Ticket #398 (Make the messages app "chat style") updated <http://trac.shr-project.org/trac/ticket/398#comment:2>
May 14 19:30:40 <mrmoku> hmm...
May 14 19:30:46 * mrmoku reads OE docs...
May 14 19:30:50 <playya_> i only know depends and rdepends
May 14 19:31:25 <dos1> isn't DEPENDS builddeps?
May 14 19:31:41 <dos1> and RDEPENDS packagedeps?
May 14 19:32:04 <dos1> that's how i understand it right now
May 14 19:33:44 <mrmoku> dos1: but DEPENDS get installed too...
May 14 19:33:45 <playya_> RDEPENDS is runtime depencies
May 14 19:34:01 <mrmoku> I think the way to go is to just have a -dev package...
May 14 19:34:56 <dent> mrmoku: often there are -native packages in DEPENDS... I don't think those would be pushed to the target...
May 14 19:35:13 <TAsn> dos1, just came for a sec and saw #398, thanks a lot, I even forgot I opened it!
May 14 19:35:27 <TAsn> night.
May 14 19:35:32 <dos1> night :)
May 14 19:36:08 <dent> Gnutoo: ping
May 14 19:36:18 <Gnutoo> dent, hi
May 14 19:36:34 <TAsn> ok will close more bugs before I go
May 14 19:36:38 <Gnutoo> dent, if you need to cope with GNU-hash I know how
May 14 19:36:42 <TAsn> dos1, 46 should probably die, agree?
May 14 19:36:47 <dent> Gnutoo: did you dig into that boost/atomic_ops issue?
May 14 19:36:56 <dent> Gnutoo: GNU-what? :)
May 14 19:37:00 <Gnutoo> dent, HASH
May 14 19:37:09 <Gnutoo> dent, for the shared libraries
May 14 19:37:21 <TAsn> as fixed, and if he wants he can upload the 2007 artwork and he'll get his splash.
May 14 19:37:32 * dent probably joined a wrong channel :))
May 14 19:37:34 <Gnutoo> dent, someone gave me a C++ implementation that work 
May 14 19:37:47 <Gnutoo> dent, why I'm talking about boost
May 14 19:38:33 <Gnutoo> dent, I could send you the modified 38 recipe if you want
May 14 19:38:47 <Gnutoo> dent, I'm cross-compiling it right now
May 14 19:39:04 <Gnutoo> dent, but...I didn't solve the wesnoth issue yet...I'm cross-compiling gnash
May 14 19:40:00 <mrmoku> dent: nothing native comes to the target yeah...
May 14 19:40:23 <dos1> TAsn: oh, shr-splash-theme-openmoko. good idea :P
May 14 19:40:24 <SHR-WugBranler`> tracfeed: Ticket #46 (Redistribute the "old" original om2007.2 boot splash) closed <http://trac.shr-project.org/trac/ticket/46#comment:4>
May 14 19:40:31 <mrmoku> but if you specify a target lib as DEPEND... it gets installed without having to specify it as RDEPEND
May 14 19:40:42 <dos1> ok, i'm going to bed too...
May 14 19:40:49 <dos1> that flu is really tiring...
May 14 19:41:00 <vininim> bacon flu?
May 14 19:41:04 <dos1> i couldn't think all day...
May 14 19:41:12 <mrmoku> dos1: well sleep well, fast and hard then
May 14 19:41:13 <dent> Gnutoo: well, if you made any improvements, it would be great to push them to the overlay... as there's alread some version
May 14 19:41:15 <dos1> vininim: maybe ;D
May 14 19:41:25 <SHR-WugBranler`> tracfeed: Ticket #384 (Add the call recorder to the repos) closed <http://trac.shr-project.org/trac/ticket/384#comment:1>
May 14 19:41:30 <Gnutoo> dent, I'll send the improvement to you
May 14 19:41:33 <dent> Gnutoo: still, I don't know what hash you're talking about
May 14 19:41:34 <dos1> mrmoku: thanks :)
May 14 19:41:43 <dent> Gnutoo: ok
May 14 19:41:44 <Gnutoo> dent, it's a QA thing
May 14 19:41:58 <PaulFertser> GNU Hash, the most free hashish one can get.
May 14 19:42:12 <dos1> and good night
May 14 19:42:26 <SHR-WugBranler`> tracfeed: Ticket #313 (Icon for Midori is missing) closed <http://trac.shr-project.org/trac/ticket/313#comment:1>
May 14 19:42:33 <dent> Gnutoo: did you look into this atomic ops thing? I tried to look into gcc sources... couldn't see a "fast" impl. there, but couldn't see pthreads being used (when looking with gdb) on the target either (?)
May 14 19:42:39 <Gnutoo> dent, openembedded now abort if you don't have gnu hash into your binaries...you only need to pass the good ldflags
May 14 19:42:48 <dent> aha
May 14 19:42:58 <dent> PaulFertser lol :)
May 14 19:43:03 <Gnutoo> dent, I've a correct C++ implementation of the atomic thing
May 14 19:43:06 <Gnutoo> it should work
May 14 19:43:07 <dent> one more thing I know nil about...
May 14 19:43:13 <Gnutoo> I'll test it on gnash
May 14 19:44:45 <mrmoku> PaulFertser: and I never heard of anybody getting problems with the police... while consuming GNU Hash ;)
May 14 19:44:56 <dent> Gnutoo: what you mean by "correct c++"? there's an implementation in libstdc++ - it's always correct, question being: is it fast on arm?
May 14 19:45:16 <PaulFertser> mrmoku: Wow, quite beneficial comparing to proprietary equivalents ;)
May 14 19:45:29 <mrmoku> hehe :')
May 14 19:45:45 <Gnutoo> dent, that uses cmpxchg
May 14 19:46:00 <Gnutoo> dent, I think so
May 14 19:46:08 <Gnutoo> dent, you could do profiling if you want
May 14 19:46:17 <dent> Gnutoo: I'm talking about __gnu_cxx::__atomic_add() and friends
May 14 19:46:20 <SHR-WugBranler`> tracfeed: Ticket #201 (Bad alsa state restored at the end of an outgoing call with headset) closed <http://trac.shr-project.org/trac/ticket/201#comment:1>
May 14 19:46:36 <Gnutoo> dent, I just uploaded my boost version
May 14 19:46:59 <Gnutoo> dent, http://gnutoo.homelinux.org/open_embedded/boost_v2.tar.bz2
May 14 19:47:05 <Gnutoo> dent, look into it
May 14 19:47:25 <dent> thx
May 14 19:48:10 <Gnutoo> dent, if you can't wait for downloading here's the patch: http://rafb.net/p/EO9bea25.html
May 14 19:48:23 <TAsn> ok, night.
May 14 19:49:06 <SHR-WugBranler`> tracfeed: Ticket #274 (illume-keyboard) closed <http://trac.shr-project.org/trac/ticket/274#comment:2>
May 14 19:49:08 <dent> Gnutoo: interesting
May 14 19:50:13 <Gnutoo> dent, beware it's setup for debuging
May 14 19:50:28 <Gnutoo> dent, remove the debug in the ./configure like variable
May 14 19:52:36 <dent> Gnutoo: I'll try to compare this __kernel_cmpxchg against __gnu_cxx::__atomic_* performance-wise
May 14 19:52:44 <Gnutoo> ok wow
May 14 19:53:27 <dent> because I still am not sure what exactly does  __gnu_cxx::__atomic_* lead to... if it's pthreads, it's performance hell... if it's something better, then it might be ok too
May 14 19:53:35 <dent> I looked into gcc sources, but was none the wiser :-(
May 14 20:03:56 <tonyg> re
May 14 20:07:47 <CIA-75> SHR: 03mok 07shr-overlay * rad8fda87023c 10/openembedded/ (2 files in 2 dirs): add recipe for fso-specs
May 14 20:07:49 <mrmoku> playya_: ok, recipe is done
May 14 20:09:16 <playya_> btw. mokomaze_0.5.1 fails :(
May 14 20:09:20 <ptitjes> mrmoku: both works in fact but I'm used to feed with the one in xml/
May 14 20:09:39 <mrmoku> ptitjes: have it in usr/share/fso-specs now :)
May 14 20:10:01 <mrmoku> what was the conf var? SPECS_PATH?
May 14 20:10:58 <ptitjes> something like this
May 14 20:11:00 <ptitjes> 2sec
May 14 20:11:44 <mrmoku> yes... SPECS_PATH :)
May 14 20:13:03 <mrmoku> playya_: yeah... mokomaze fails on libode being to old
May 14 20:13:20 <playya_> thats 0.5.0
May 14 20:13:47 <mrmoku> both I would guess..
May 14 20:13:55 <playya_> 0.5.0 fails imho because of a wrong link
May 14 20:15:04 <playya_> if you download http://projects.openmoko.org/frs/download.php/781/0.5.1.tar.gz you get a mokomaze-0.5.0.tar.gz oO
May 14 20:16:45 <mrmoku> playya_: haha... that one is tricky ;)
May 14 20:16:55 <mrmoku> made me going mad twice :P
May 14 20:17:09 <mrmoku> it does not matter what filename you pass it
May 14 20:17:15 <mrmoku> the only thing that matters is 781
May 14 20:17:35 <mrmoku> if you downloaded it once with the wrong number... you have to remove the tarball from the downloads dir
May 14 20:17:36 <playya_> muhaha
May 14 20:27:13 <playya_> mrmoku, sourceforge tells me that the latest version is 0.11 oO
May 14 20:27:37 <mrmoku> libode? yes
May 14 20:53:52 <mrmoku> ptitjes: ok... /home/mok/src/other/openmoko/shrbuild/shr/shr-unstable/tmp/staging/x86_64-linux/usr/bin/valac -C --pkg vala-1.0 --pkg dbus-gl
May 14 20:53:53 <SHR-WugBranler`> tracfeed: Ticket #441 (pyphonelog crash on shr-testing (02-May-2009)) created <http://trac.shr-project.org/trac/ticket/441>
May 14 20:53:55 <mrmoku> Unknown option --gir
May 14 20:54:07 <mrmoku> guess now we need gobject-introspection :P
May 14 20:56:43 <Ainulind1le> Hey there
May 14 20:58:59 <ptitjes> mrmoku: nah wrong vala branch :)
May 14 20:59:47 <mrmoku> ptitjes: hmm...
May 14 21:00:06 <jonkristian> Stuff under Settings aren't saved after a reboot, for example wlan on/off, gprs settings(i have a successfull connection), and auto dimming, probably more.
May 14 21:00:10 <jonkristian> in SHR
May 14 21:00:54 <jonkristian> also calculating battery time is strange after a reboot, i have Remaining time: 1092 h 15 min.
May 14 21:01:13 <mrmoku> ptitjes: yes... wrong branch :)
May 14 21:01:29 <ptitjes> this is what I'm watching too
May 14 21:01:54 <ptitjes> I thought we were ok with mickeyl to use pending-upstream-move
May 14 21:02:21 <ptitjes> mrmoku: is it possible to override that in a Preffered_version style ?
May 14 21:03:05 <CIA-75> SHR: 03mok 07shr-overlay * r5234e6130e0b 10/openembedded/recipes/ (2 files in 2 dirs): work on fso-glib.bb ... might eventually work too
May 14 21:03:11 <mrmoku> ptitjes: well... we override it :)
May 14 21:03:25 <mrmoku> just that I built in an OE tree that has the wrong override :P
May 14 21:03:26 <ptitjes> mrmoku: the SRC_URI ?
May 14 21:03:30 <mrmoku> yep
May 14 21:03:50 <ptitjes> mrmoku: still the same libtool problem
May 14 21:04:02 <mrmoku> ptitjes: anyway... need some sleep now... I putted it and might even work
May 14 21:04:06 <ptitjes> I had rm -rf tmp/
May 14 21:04:16 <mrmoku> and you changed conf/auto.conf?
May 14 21:04:16 <ptitjes> oki
May 14 21:04:27 <ptitjes> it was already "shr"
May 14 21:04:58 <mrmoku> DISTRO = "shr" ?
May 14 21:05:03 <ptitjes> yep
May 14 21:05:21 <ptitjes> it does not mind
May 14 21:05:27 <ptitjes> have a nice night
May 14 21:05:31 <mrmoku> hmm... it solved the libtool problem for me...
May 14 21:05:37 <mrmoku> ptitjes: thanks... good night
May 14 21:06:10 <mrmoku> cu
May 14 21:06:59 <SHR-WugBranler`> tracfeed: Ticket #441 (pyphonelog crash on shr-testing (02-May-2009)) updated <http://trac.shr-project.org/trac/ticket/441#comment:1>
May 14 22:05:11 <tonyg> w00t! erlang on openmoko again, after a year or so hiatus
May 14 22:05:39 <tonyg> now to update my code for all the altered /sys/... paths since dec 2007
May 14 22:07:19 <lindi-> tonyg: don't hardcode such paths :)
May 14 22:07:34 <tonyg> lindi-, how should i look them up then ;)
May 14 22:21:31 <lindi-> tonyg: helper program, config file
May 14 22:21:47 <tonyg> yep -- except that no doubt the format of the data has changed too
May 14 22:22:09 <tonyg> this is pretty low-level stuff I'm playing with, so I'm reasonably happy programming tightly to specific kernel interfaces
May 14 22:25:28 <lindi-> tonyg: library is good then
May 14 23:00:44 <tonyg> so if i want to develop gui tools using python and glade... what's my best bet
May 15 01:08:56 <Toaster`> ~seen raster
May 15 01:08:56 <bzzbot> raster <n=raster@enlightenment/developer/raster> was last seen on IRC in channel #openmoko-cdevel, 10h 56m 45s ago, saying: 'hell - bsd is closer'.
May 15 01:09:34 <Toaster`> damnit... this 7 hour time difference is making it difficult to get things done
May 15 01:31:22 <DocScrutinizer> bah, better than a 7h delay to saturn station
May 15 01:31:54 <Toaster`> Quite true, but at that point HAL will be in control of the situation anyways.
**** ENDING LOGGING AT Fri May 15 02:59:58 2009