**** BEGIN LOGGING AT Sun Dec 27 02:59:56 2009
Dec 27 11:02:08 <daniele_athome> hello
Dec 27 11:02:30 <daniele_athome> i'm using fso-glib bindings, inside a async callback I receive a GLib.Error
Dec 27 11:02:37 <daniele_athome> how can I test what type of error it is?
Dec 27 11:02:58 <daniele_athome> "is" operator against FreeSmartphone.UsageError (for example) doesn't work
Dec 27 11:03:09 <daniele_athome> I mean I tried many errors, but none matches
Dec 27 11:03:30 <daniele_athome> (vala language)
Dec 27 11:04:00 <mickeyl|flu> if it's a GLib.Error, then is will not match against an FSO error
Dec 27 11:04:14 <mickeyl|flu> what's the e.message?
Dec 27 11:05:17 <daniele_athome> mickeyl|flu, e.message is something like "available resources are: ['TEST']"
Dec 27 11:05:25 <daniele_athome> the callback is a request_resource callback
Dec 27 11:05:33 <daniele_athome> I request gsm (which is not available)
Dec 27 11:05:35 <mickeyl|flu> hmm, this indeed looks like an FSO error then
Dec 27 11:05:41 <mickeyl|flu> are you catching for FSO errors?
Dec 27 11:05:43 <mickeyl|flu> like
Dec 27 11:06:01 <mickeyl|flu> catch ( FreeSmartphone.Usage.Error e ) ?
Dec 27 11:06:14 <daniele_athome> mickeyl|flu, no because the error is passed to the async callback as a argument
Dec 27 11:06:18 <daniele_athome> so no try catch I guess
Dec 27 11:06:30 <daniele_athome> void callback(GLibError .e) { ... }
Dec 27 11:06:37 <daniele_athome> ops GLib.Error e
Dec 27 11:06:38 <daniele_athome> :)
Dec 27 11:06:53 <mickeyl|flu> hmm, oh, you're using the callback style working. 
Dec 27 11:07:19 <daniele_athome> mickeyl|flu, anyway a try catch with a dbus sync call didn't work either
Dec 27 11:07:33 <daniele_athome> it always goes in DBus.Error catch block
Dec 27 11:07:44 <mickeyl|flu> do you have an example program for me?
Dec 27 11:08:50 <daniele_athome> mickeyl|flu, the actual source file i'm writing is pretty simple
Dec 27 11:08:53 <daniele_athome> i'll pastebin it
Dec 27 11:09:24 <daniele_athome> ok no :D i'll paste only the involved section
Dec 27 11:10:00 <daniele_athome> mickeyl|flu, this is with try-catch: http://pastebin.com/dccf21a9
Dec 27 11:10:05 <mickeyl|flu> i can't reproduce without a full example, but at least i can glance over the code
Dec 27 11:10:14 <daniele_athome> mickeyl|flu, ok ok
Dec 27 11:10:20 <daniele_athome> i'll make an example so :)
Dec 27 11:10:55 <mickeyl|flu> excellent :)
Dec 27 11:11:01 <mickeyl|flu> note that i would recommend you to use static dbus
Dec 27 11:11:08 <mickeyl|flu> i'm not sure how well dynamic dbus works w/ errors
Dec 27 11:11:24 <mickeyl|flu> and it's slower and less type-safe
Dec 27 11:11:26 <mickeyl|flu> not to mention...
Dec 27 11:12:01 <mickeyl|flu> (i know that means you need async though)
Dec 27 11:12:08 <mickeyl|flu> sync is only supported for dynamic dbus atm.
Dec 27 11:12:26 <mickeyl|flu> anyways, let me work on an example as well now...
Dec 27 11:12:43 <daniele_athome> mickeyl|flu, in the meantime
Dec 27 11:12:55 <daniele_athome> this is the error print from the try block
Dec 27 11:12:56 <daniele_athome> ** (process:3981): CRITICAL **: file gsm.vala.c: line 338: uncaught error: Known resources are ['TEST'] (dbus-glib-error-quark, 32)
Dec 27 11:13:02 <mickeyl|flu> ah
Dec 27 11:13:04 <daniele_athome> which of course doesn't get catched
Dec 27 11:13:30 <mickeyl|flu> i think that's due to the dynamic dbus
Dec 27 11:13:33 <mickeyl|flu> try catching DBus.Error
Dec 27 11:13:54 <daniele_athome> mickeyl|flu, it works with Dbus.Error, but I can't test what error exactly is
Dec 27 11:16:56 <mickeyl|flu> give me a 5 minutes to come up with an example that works
Dec 27 11:17:23 <daniele_athome> mickeyl|flu, i'm writing it don't worry
Dec 27 11:20:39 <daniele_athome> mickeyl|flu, http://pastebin.com/f3e97e340
Dec 27 11:20:57 <DocScrutinizer51> mickeyl|flu: o/  :-)
Dec 27 11:21:09 <daniele_athome> fso error doesn't get catched, and run() method error finishes in DBus.Error catch block in main()
Dec 27 11:21:21 <daniele_athome> so same problem :(
Dec 27 11:23:22 <daniele_athome> mickeyl|flu, a note: i'm using the latest vala compiler, vala-dbus-bindings-tool, fso-glib directly from FSO git repository
Dec 27 11:25:39 <mickeyl|flu> http://vala.pastebin.com/dd3f011a
Dec 27 11:25:41 <daniele_athome> I tried also to do some compare like e.code == UsageError.RESOURCE_UNKNOWN but it's not possible
Dec 27 11:25:52 <mickeyl|flu> this emits a spurious GLib.Error critical, but seems to work anyways
Dec 27 11:27:19 <daniele_athome> mmm
Dec 27 11:27:31 <mickeyl|flu> s/critical/warning/
Dec 27 11:27:32 <apt> mickeyl|flu meant: this emits a spurious GLib.Error warning, but seems to work anyways
Dec 27 11:27:44 <daniele_athome> mickeyl|flu, http://vala.pastebin.com/m6b02d897
Dec 27 11:28:10 <mickeyl|flu> good
Dec 27 11:28:11 <mickeyl|flu> seems to work
Dec 27 11:28:16 <mickeyl|flu> the dbus error is your problem :)
Dec 27 11:28:19 <mickeyl|flu> fix your dbus configuration
Dec 27 11:28:51 <daniele_athome> mickeyl|flu, yes for the second line
Dec 27 11:28:53 <daniele_athome> but the first?
Dec 27 11:28:58 <daniele_athome> about gerror
Dec 27 11:29:05 <mickeyl|flu> that's the warning i was referring to
Dec 27 11:29:15 <daniele_athome> mmm
Dec 27 11:29:21 <daniele_athome> so I suppose it is ok 
Dec 27 11:29:21 <mickeyl|flu> that's probably a bug in vala
Dec 27 11:29:24 <mickeyl|flu> yep
Dec 27 11:29:31 <mickeyl|flu> here the call gets through
Dec 27 11:29:33 <mickeyl|flu> and correctly emits:
Dec 27 11:29:46 <mickeyl|flu> ** Message: fso.vala:25: Resource unknown, error catched OK
Dec 27 11:29:54 <mickeyl|flu> [when fsousaged runs]
Dec 27 11:30:24 <mickeyl|flu> i'll open a bug against Vala now for the error thing
Dec 27 11:32:47 <daniele_athome> mickeyl|flu, that's strange: http://pastebin.com/f48c97fa2
Dec 27 11:33:04 <daniele_athome> request_resource goes correctly
Dec 27 11:33:09 <daniele_athome> :S
Dec 27 11:36:25 <mickeyl|flu> hmm, this is a strange bug
Dec 27 11:36:33 <mickeyl|flu> if i copy the interface directly into the code, the warning is gone
Dec 27 11:36:36 <mickeyl|flu> *sigh*
Dec 27 11:36:58 <daniele_athome> mmm
Dec 27 11:37:13 <mickeyl|flu> vala's dbus support is still very buggy
Dec 27 11:37:39 <daniele_athome> mickeyl|flu, do you think it's a good idea using dbus with vala?
Dec 27 11:37:47 <mickeyl|flu> yes
Dec 27 11:37:53 <mickeyl|flu> vala and dbus is a perfect match
Dec 27 11:38:03 <mickeyl|flu> apart from the annoying errors, it's a superproductive combination
Dec 27 11:38:15 <DocScrutinizer51> mickeyl|flu: is that notorious "foo in (a)sync for pending bar deprecated" still present?
Dec 27 11:38:37 <mickeyl|flu> DocScrutinizer51: not in my version of dbus
Dec 27 11:38:49 <mickeyl|flu> i use a newer one without that patch
Dec 27 11:38:53 <mickeyl|flu> SHR possibly as well
Dec 27 11:38:57 <lindi-> mickeyl|flu: is the bug still present?
Dec 27 11:39:12 <DocScrutinizer51> is it fixed or just logging commented out? ;-D
Dec 27 11:39:22 <PaulFertser> lindi-: btw, what is your solution to small non-tweakable dbus timeout in debian?
Dec 27 11:39:26 <mickeyl|flu> i don't think anyone worked on that
Dec 27 11:39:29 <mickeyl|flu> so it's likely still present
Dec 27 11:39:38 <mickeyl|flu> but fso2 is not affected
Dec 27 11:39:42 <mickeyl|flu> so i tend to ignore it
Dec 27 11:39:51 <lindi-> PaulFertser: retry :)
Dec 27 11:40:46 <PaulFertser> lindi-: hm, not exactly an option for someone who wants to use full fso stack i assume...
Dec 27 11:41:21 <DocScrutinizer51> is there any mini howto for dbus noobs? preferrably python
Dec 27 11:41:48 <mickeyl|flu> DocScrutinizer51: http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html
Dec 27 11:42:04 <DocScrutinizer51> mickeyl|flu: cool
Dec 27 11:42:08 <DocScrutinizer51> thanks
Dec 27 11:42:33 <lindi-> PaulFertser: not really yes if you depend on dbus to turn the backlight on or something else that makes UI unusable in case of failure
Dec 27 11:46:29 <PaulFertser> lindi-: folks say that due to dbus timeouts they miss pin request dialog and such on debian.
Dec 27 11:48:38 <lindi-> PaulFertser: but if you do while (1) { if (poll_for_pin() == PIN_NOT_SET) { send_pind(); } } you are not affected :)
Dec 27 11:49:43 <mickeyl|flu> nice duct tape *cough*
Dec 27 11:51:11 <PaulFertser> lindi-: given i'm not doing anything useful for quite some time i consider to install shr to nand and use debian for all non-telephony tasks in chroot. I'm so fed up with an unusable phone, and that's my only cellphone.
Dec 27 11:51:34 <mickeyl|flu> good idea, SHR is making great progress
Dec 27 11:52:14 <mickeyl|flu> despite all its greatness, debian is notoriously bad for some things such as rapidly evolving software and embedded system tailored packages
Dec 27 11:52:55 <mickeyl|flu> although you can argue that the root problem is rather on the side of the dbus folks in that particular case
Dec 27 11:53:33 <mickeyl|flu> their desktop centric nature of watching things is hurting us a bit
Dec 27 11:53:39 <mickeyl|flu> *shrug*
Dec 27 11:55:55 <DocScrutinizer51> a bit is rather euphemistic wording
Dec 27 11:57:06 <PaulFertser> mickeyl|flu: do they provide any arguments as to why extending/tweaking dbus a bit to make it more suitable for embedded can hurt their main target?
Dec 27 11:57:42 <mickeyl|flu> no, they're just not interested
Dec 27 11:58:09 <DocScrutinizer51> why isn't that a config parameter very first instance? :-S
Dec 27 11:58:27 <mickeyl|flu> they say "for cross compilation you have to build your own version anyways, hence you might as well patch it, fix it, and install sane defaults for your target as well"
Dec 27 11:58:48 <mickeyl|flu> (loosely transcribed from the last couple of years dbus mailing list)
Dec 27 11:58:58 <mickeyl|flu> DocScrutinizer51: after our patch it is :)
Dec 27 11:59:18 <mickeyl|flu> but as much as we can beat on dbus folks, here comes debian stubbornness
Dec 27 11:59:44 <mickeyl|flu> in refusing to accept that as a problem
Dec 27 12:00:47 <DocScrutinizer51> well a sane patch to make that a runtime config no way can be rejected by upstream
Dec 27 12:00:59 <DocScrutinizer51> emphasis on "sane"
Dec 27 12:01:42 <daniele_athome> mickeyl|flu, those patches for emebedded use are implemented in SHR, aren't they?
Dec 27 12:02:06 <mickeyl|flu> daniele_athome: yes, they're in OE, hence all OE-built distros contain these things
Dec 27 12:02:14 <daniele_athome> good
Dec 27 12:10:21 <PaulFertser> mickeyl|flu: suggesting to patch dbus to suit target doesn't seem to be a sane response :(
Dec 27 12:10:41 <mickeyl|flu> PaulFertser: yes, these were my thoughts as well
Dec 27 12:11:14 <daniele_athome> mickeyl|flu, I think there is another bug in vala
Dec 27 12:11:40 <daniele_athome> If I do try-catch with error variable name "e"
Dec 27 12:11:51 <daniele_athome> and after then, another try-catch with the same error variable name "e"
Dec 27 12:12:01 <daniele_athome> gcc compiler complains about "duplicate member "e""
Dec 27 12:12:14 <daniele_athome> (this if I put the try-catch blocks in the same method)
Dec 27 12:12:30 <mickeyl|flu> good find
Dec 27 12:12:30 <mickeyl|flu> https://bugzilla.gnome.org/show_bug.cgi?id=596861
Dec 27 12:12:41 <mickeyl|flu> guess why i did use different names in my code? :)
Dec 27 12:13:27 <mickeyl|flu> this one has at least a simple workaround
Dec 27 12:13:36 <daniele_athome> :)
Dec 27 12:14:05 <mickeyl|flu> chances are Jürg has some more time to work on Vala next year
Dec 27 12:14:20 * mickeyl|flu hoping for 0 more features, but only bugfixes until Vala 1.0
Dec 27 12:14:48 <mickeyl|flu> as much as I like more syntax sugar, I'm running into a Vala bug every couple of days
Dec 27 12:14:59 <mickeyl|flu> yes, I'm guilty for using all the complex things
Dec 27 12:15:04 <mickeyl|flu> async, closures, dbus, errors
Dec 27 12:15:09 <mickeyl|flu> delegates, structs, etc.
Dec 27 12:15:17 <mickeyl|flu> in combination...
Dec 27 12:15:34 <daniele_athome> eheh
Dec 27 12:16:05 <mickeyl|flu> but if i was only to use a safe subset of a language, i'd go back to C++ 
Dec 27 12:16:11 <mickeyl|flu> this time i want to use all features :)
Dec 27 12:17:12 <DocScrutinizer51> I'd say any different approach was nonsense
Dec 27 12:18:04 <daniele_athome> of course :)
Dec 27 12:20:06 <DocScrutinizer51> though I have to acknowledge it's a demanding and ambitious task to write a whole new project like framework using a whole new language
Dec 27 12:20:47 <mickeyl|flu> indeed. and if this was a commercial project it would have probably been shut down due to immaturity of Vala being a "business risk"
Dec 27 12:21:09 <mickeyl|flu> but with it being a sparetime project i have the luxury of continuing to pursue my vision
Dec 27 12:21:23 <mickeyl|flu> knowing that at some point of time Vala will be mature enough
Dec 27 12:21:59 <mickeyl|flu> and if all fails, i might as well start hacking Vala on my own *shrug*
Dec 27 12:22:09 <mickeyl|flu> not that i would really want to
Dec 27 12:22:23 <DocScrutinizer51> :-D Feels good I'm not completely wrong with my notions
Dec 27 12:28:45 <daniele_athome> mickeyl|flu, i warn you if vala will stop I will have to switch to google's go :P
Dec 27 12:29:10 <daniele_athome> personally I don't want to
Dec 27 12:29:11 <mickeyl|flu> eeks
Dec 27 12:29:31 <mickeyl|flu> I think Vala has a bright future, just have a bit patience
Dec 27 12:29:38 <daniele_athome> ;)
Dec 27 12:29:48 <mickeyl|flu> one day we might even see the gobject heritage vanishing...
Dec 27 12:29:53 <mickeyl|flu> (check the new dova branch...)
Dec 27 12:30:09 <daniele_athome> mmm
Dec 27 12:31:06 <daniele_athome> mickeyl|flu, where is it in git?
Dec 27 12:32:48 <mickeyl|flu> http://gitorious.org/dova/vala i think
Dec 27 12:33:00 <daniele_athome> mickeyl|flu, just found it right there :)
Dec 27 12:33:37 <daniele_athome> mickeyl|flu, anyway I don't think from the compiler source i will understand something :)
Dec 27 12:33:39 <daniele_athome> in a few words?
Dec 27 12:33:59 <mickeyl|flu> dova is a new backend for vala, think glib/gobject 4
Dec 27 12:34:13 <daniele_athome> mmm
Dec 27 12:34:16 <daniele_athome> interesting
Dec 27 12:34:24 <daniele_athome> so no more dependency on glib/gobject?
Dec 27 12:34:49 <mickeyl|flu> yeah, vala would contain its own backend for this profile
Dec 27 12:35:06 <mickeyl|flu> but don't hold your breath, i think this is post vala 1.0
Dec 27 12:35:23 <daniele_athome> mickeyl|flu, will this be a benefit? I mean vala was supposed to make glib/gobject compatible libraries
Dec 27 12:35:28 <mickeyl|flu> the dova branch is Jürg's language feature playground, where he can do things that the glib/gobject backend makes very complicated
Dec 27 12:35:30 <daniele_athome> so one can use it in vala or in C
Dec 27 12:35:36 <mickeyl|flu> well
Dec 27 12:35:42 <mickeyl|flu> vala will still generate C libs
Dec 27 12:35:46 <mickeyl|flu> that won't change
Dec 27 12:35:52 <mickeyl|flu> just the generated C code will change
Dec 27 12:36:07 <daniele_athome> I know but they will not be "gobjected"
Dec 27 12:36:13 <mickeyl|flu> yep
Dec 27 12:36:36 <mickeyl|flu> if you use the dova profile, you will probably have to make this compromise
Dec 27 12:36:59 <daniele_athome> right...
Dec 27 12:37:03 <daniele_athome> mickeyl|flu, where are you from?
Dec 27 12:37:08 <mickeyl|flu> germany
Dec 27 12:37:13 <mickeyl|flu> Frankfurt am Main, to be exact
Dec 27 12:44:21 <mickeyl|flu> bbiab, resting an hour on the sofa
Dec 27 15:01:11 <dos1> Heinervdm: i've got cookies for ya
Dec 27 15:07:18 * mwester wants ginger snap cookies!
Dec 27 15:40:03 <CIA-78> SHR: 03david 07shr * r4b323368d493 10/ (6 files in 6 dirs): Add galician and spanish translations
Dec 27 15:46:46 <CIA-78> SHR: 03david 07shr-settings * r0b034d0d569a 10/data/ (13 files in 4 dirs): Add galician and spanish translations
Dec 27 15:52:50 <CIA-78> SHR: 03david 07shr-installer * r8608816ea1a1 10/ (6 files in 4 dirs): Add galician and spanish translations
Dec 27 15:58:14 <TAsn> dos1, thanks :P
Dec 27 15:58:29 <CIA-78> SHR: 03david 07opimd-utils * r869f1dbc16e6 10/ (26 files in 5 dirs): Add galician and spanish translations
Dec 27 16:03:43 <CIA-78> SHR: 03david 07libphone-ui-shr * re89e6f824202 10/po/ (es.po gl.po): Add galician and spanish translations
Dec 27 16:04:23 <dos1> TAsn: ok, done :P
Dec 27 16:04:27 <TAsn> :)
Dec 27 16:04:59 <bumbl> btw. dos1: somehow opimd magically (without any updates) stopped producing duplicate sms
Dec 27 16:05:15 <TAsn> bumbl, it only produces them (at least here)
Dec 27 16:05:26 <TAsn> when you do an heavy opimd query
Dec 27 16:05:29 <TAsn> while getting a new sms
Dec 27 16:05:38 <TAsn> this jams frameworkd
Dec 27 16:05:48 <TAsn> which doesn't return an ack to the modem
Dec 27 16:05:51 <TAsn> which sends it again
Dec 27 16:05:58 <TAsn> at least that's what I got from dos1 :P
Dec 27 16:06:06 <TAsn> *understand
Dec 27 16:06:19 <dos1> yup, at least that's what i suppose ;)
Dec 27 16:06:45 <bumbl> TAsn: yep i was there when you discussed this - just wanted to say that somehow it is fine now for a week of heavy smsing
Dec 27 16:06:48 <TAsn> Looks correct to me.
Dec 27 16:06:55 <TAsn> bumbl, it's terrible here :P
Dec 27 16:07:04 <TAsn> I sometimes get the same message 10 times.
Dec 27 16:07:06 <TAsn> btw dos1 
Dec 27 16:07:07 <TAsn> another bug
Dec 27 16:07:16 <TAsn> messages appear again after reboot
Dec 27 16:07:20 <TAsn> after I removed them
Dec 27 16:07:22 <TAsn> (some)
Dec 27 16:07:35 <TAsn> very weird :|
Dec 27 16:07:50 <TAsn> I bet they are stored on sim and for some reason removing from sim doesn't work from opimd or something similar
Dec 27 16:07:55 <TAsn> no time to verify though :P
Dec 27 16:08:00 <TAsn> gotta go and play COD.
Dec 27 16:08:02 <TAsn> :)
Dec 27 16:08:03 <TAsn> ciao.
Dec 27 17:46:07 <Deubeuliou> é~.
Dec 27 17:51:42 <playya_> Deubeuliou, fell asleep on you keyboard?
Dec 27 18:42:47 <khiraly11> !logs
Dec 27 18:42:47 <cdbot2> Channel logs for #openmoko-cdevel are archived at:
Dec 27 18:42:48 <cdbot2> http://hentges.net/tmp/logs/irc/%23openmoko-cdevel
Dec 27 18:42:49 <cdbot2> Live-logs are available at
Dec 27 18:42:51 <cdbot2> http://hentges.net/tmp/logs/irc/livelogs/%23openmoko-cdevel.livelog
Dec 27 18:42:53 <cdbot2> See ?? help-logs for usage instructions
Dec 27 18:54:10 <Deubeuliou> playya_: no, the connection is a bit unstable :)
Dec 27 18:55:06 <thessy>  hi all, have a problem with shr-testing. does not suspend anymore. /var/log/fsousaged says: FsoUsageNullLowLevel [WARNING] : NullLowlevel::resume() - this is probably not what you want
Dec 27 18:55:20 <thessy> any hints?
Dec 27 18:56:07 <playya_> Deubeuliou, you don't have a wired connection? only wifi?
Dec 27 18:56:55 <bumbl> TAsn: how hard would it be to replace the input number widget from the messages app with the input number widget from the dialer app?
Dec 27 19:00:28 <TAsn> i.e enter numbers in the messages app in a sane way? :P
Dec 27 19:00:39 <TAsn> (instead of using a keyboard)
Dec 27 19:00:42 <TAsn> shouldn't be that hard.
Dec 27 19:00:56 <TAsn> please write that in the phoneui page
Dec 27 19:00:58 <TAsn> in the wiki
Dec 27 19:01:05 <TAsn> so we'll remember to do that in the rewrite.
Dec 27 19:01:23 <TAsn> though actually, to tell you the truth, I really do prefer entering the number with a keyboard :P
Dec 27 19:01:29 <TAsn> and the new numberic jeyboard is great.
Dec 27 19:01:31 <TAsn> keyboard*
Dec 27 19:07:06 <thessy> any hint for me, how can I debug why shr-testing does not suspend anymore?
Dec 27 19:08:49 <lindi-> thessy: how do you try to make it suspend?
Dec 27 19:09:30 <thessy> I try it with power button an 'suspend', on terminal with 'apm -s'
Dec 27 19:09:45 <thessy> both has the same result: nothing happens
Dec 27 19:12:10 <lindi-> thessy: what about "pm-suspend"?
Dec 27 19:14:07 <thessy> what is 'pm-suspend'? a command in terminal?
Dec 27 19:14:38 <TAsn> thessy, 
Dec 27 19:14:46 <TAsn> opkg list_installed | grep apm
Dec 27 19:16:05 <thessy> apmd, fso-apm, libapm1 is installed
Dec 27 19:16:05 <TAsn> if you have apm instead of fso-apm, remove it and install fso-apm
Dec 27 19:16:42 <thessy> sorry forget to say, that yesterday after flashing shr-testing does work
Dec 27 19:16:53 <TAsn> looks fine to me.
Dec 27 19:16:56 <bumbl> TAsn: yeah i also prefer using a keyboard which is really small because we don't have any space available in this cluttered dialouge
Dec 27 19:17:29 <TAsn> bumbl, what are you talking about?! it's big enough, I'll up a scap sec.
Dec 27 19:18:21 <dvermd> can someone give me a link to help me package a french dvorak keyboard for shr ?
Dec 27 19:18:33 <TAsn> dvermd, yes
Dec 27 19:18:49 <TAsn> dvermd, mail the keyboard to shr-devel
Dec 27 19:18:52 <TAsn> we'll package it.
Dec 27 19:19:23 <dvermd> ok, I'll finalise it and send it to you soon
Dec 27 19:19:53 <dvermd> TAsn, Do I need to make a icon ?
Dec 27 19:19:53 <TAsn> http://scap.linuxtogo.org/files/e468f6b1b556f138948e3a29c2b8eaf3.png
Dec 27 19:20:07 <TAsn> dvermd, nah, we'll just use the french flag.
Dec 27 19:20:24 <dvermd> TAsn, ok
Dec 27 19:20:35 <TAsn> bumbl, http://scap.linuxtogo.org/files/e468f6b1b556f138948e3a29c2b8eaf3.png
Dec 27 19:20:38 <TAsn> what's wrong with this?
Dec 27 19:21:27 <dvermd> TAsn, There's an icon done by the french dvorak commuity, what is the icon format and size, maybe we can use this one ?
Dec 27 19:22:04 <dvermd> TAsn, http://bepo.fr/wiki/Accueil
Dec 27 19:22:09 <TAsn> dvermd, http://git.shr-project.org/git/?p=illume-keyboards.git;a=tree;h=refs/heads/master;hb=master
Dec 27 19:22:35 <TAsn> dvermd, the "bepo" icon?
Dec 27 19:22:45 <dvermd> TAsn, yes
Dec 27 19:23:00 <bumbl> TAsn: http://img697.imageshack.us/img697/442/e468f6b1b556f138948e3a2.png
Dec 27 19:23:08 <TAsn> dvermd, I think a french flag will better fit there.
Dec 27 19:23:15 <TAsn> and it'll conform with the other packages.
Dec 27 19:23:36 <TAsn> bumbl, yeah, so? :P
Dec 27 19:23:46 <dvermd> TAsn, No problem, I'll put the link in the README
Dec 27 19:24:01 <TAsn> we'll remake the screen and make it look better :P
Dec 27 19:25:24 <bumbl> btw. i'd love to have a more tab like experience - one main program - tab 1 dialer - tab 2 contacts - tab 3 last calls - tab 4 missed calls
Dec 27 19:26:00 <TAsn> bumbl, why? :P
Dec 27 19:26:18 <TAsn> I don't like it (I don't really mind implementing when the time comes, but I don't like it)
Dec 27 19:26:36 <bumbl> TAsn: as this is the way i do phoneing ;p
Dec 27 19:26:53 <bumbl> and i don't think kiss is cool when it comes to phones
Dec 27 19:27:00 <TAsn> :P
Dec 27 19:27:12 <TAsn> kiss is always better.
Dec 27 19:30:35 <bumbl> how could i force reinstalling a package as i forgot to say Y to the question that asked whether it should overwrite existing config files
Dec 27 19:32:09 <TAsn> -force-reinstall
Dec 27 19:35:35 <bumbl> thank you
Dec 27 19:40:49 <TAsn> np.
Dec 27 19:47:52 <bumbl> TAsn: a new image coming up the way? i think i have fucked up some things
Dec 27 19:47:55 <bumbl> ;p
Dec 27 19:48:49 <TAsn> we are on a christams vacation ;P
Dec 27 19:48:58 <bumbl> ;)
Dec 27 19:49:19 <TAsn> mrmoku|away is back on the 2nd, we'll probably continue then. 
Dec 27 19:50:08 <bumbl> i'll flash the image from the 13th then
Dec 27 21:33:28 <lindi-> DocScrutinizer: in the mood to debug s3c2440 SRCPND register issues? ;) (re http://docs.openmoko.org/trac/ticket/2324 )
Dec 27 22:09:50 <CIA-78> SHR: 03seba.dos1 07opimd-utils * r00cfffcb4efd 10/setup.py: Fix setup.py
Dec 27 22:39:53 <CIA-78> freesmartphone.org: 03morphis 07msmcomm * r70f338501244 10/msmcommd/ (include/msmcomm/internal.h src/network.c src/serial.c): msmcommd: add more management network access related code
Dec 27 23:18:35 <nomeata> Hi. I just installed SHR testing, and fso-settings does not start any module. Console output says Loading module shr_profile.Profile.... Is that a known problem?
Dec 27 23:19:18 <playya> fso-settings?
Dec 27 23:19:52 <nomeata> sorry, shr-settings
Dec 27 23:25:22 <nomeata> Same when starting the module via the Illume settings menu
Dec 27 23:29:06 <spaetz> nomeata: how do you mean does not start any module?
Dec 27 23:29:13 <spaetz> does shr-settings start?
Dec 27 23:29:35 <spaetz> or do you have a failure when starting a single module from the command line?
Dec 27 23:29:51 <nomeata> spaetz: yes, the launcher starts, and clicking on a button opens a window that freezes
Dec 27 23:31:06 * nomeata reboots
Dec 27 23:39:01 <nomeata> ok, time works
Dec 27 23:39:19 <nomeata> now phone works as well. Guess the restart helped.
Dec 27 23:42:34 <khiraly1> !logs
Dec 27 23:42:34 <cdbot2> Channel logs for #openmoko-cdevel are archived at:
Dec 27 23:42:35 <cdbot2> http://hentges.net/tmp/logs/irc/%23openmoko-cdevel
Dec 27 23:42:36 <cdbot2> Live-logs are available at
Dec 27 23:42:38 <cdbot2> http://hentges.net/tmp/logs/irc/livelogs/%23openmoko-cdevel.livelog
Dec 27 23:42:40 <cdbot2> See ?? help-logs for usage instructions
Dec 28 00:06:05 <nomeata> I found illume-keyboard-german, but is there also a package with a german word list?
Dec 28 00:46:35 <max_posedon> PaulFertser, hi! I remember I bet that I bet ubifs testing and benchmarking, I still haven't done it, but you may be interested in tests from sheevaplug
Dec 28 00:46:53 <max_posedon> http://www.plugcomputer.org/plugwiki/index.php/Enabling_UBIFS
**** ENDING LOGGING AT Mon Dec 28 02:59:57 2009