**** BEGIN LOGGING AT Fri Sep 19 02:59:57 2008
Sep 19 04:30:30 <rwhitby> mickey|tv: typo in fso-image.bb s/fso-gspd/fso-gpsd/
Sep 19 07:17:06 <kvk> i have installed vmware-server on debian system, but when im trying to run the image then it is giving error like " (vmware:5978): libgnomevfs-WARNING **: Cannot load module `/usr/lib/gnome-vfs-2.0/modules/libfile.so' (/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6))
Sep 19 07:40:15 <rwhitby> kvk: you're running vmware-server on debian on an openmoko device?
Sep 19 07:46:03 <kvk> rwhitby: im not running vmware server on the device
Sep 19 07:46:51 <rwhitby> oh, so it's a generic vmware-server on linux question then?
Sep 19 07:58:39 <kvk> rwhitby: yaa
Sep 19 07:59:21 <kvk> rwhitby: i have got a temporary solution for that, but it works with root
Sep 19 08:00:01 <rwhitby> I've switched to VirtualBox myself.
Sep 19 08:00:14 <rwhitby> (used to run vmware workstation, now run virtualbox)
Sep 19 08:00:32 <kvk> rwhitby: ok
Sep 19 09:11:01 <b0ef> I got a problem with zhone dying on incoming calls, but when I kill zhone and frameworkd, the vibrator won't stop buzzing
Sep 19 09:11:29 <b0ef> looking at the processes, I can't find anyone that might be doing it
Sep 19 09:11:43 <b0ef> it just won't shut up
Sep 19 09:11:58 <b0ef> I'm ready to chop it with an axe, pretty soon
Sep 19 09:12:10 <b0ef> die, die, die
Sep 19 09:12:28 <b0ef> any pointers?
Sep 19 09:12:40 <b0ef> I'm on debian
Sep 19 10:58:35 <quickdev> Hey
Sep 19 11:04:46 <quickdev> AndreasD, did you play with ophonekitd?
Sep 19 11:05:10 <AndreasD> quickdev: yes, a bit 
Sep 19 11:05:28 <quickdev> java is used to store sms?
Sep 19 11:05:32 <quickdev> *jana
Sep 19 11:06:14 <AndreasD> yes
Sep 19 11:06:42 <emdete> b0ef: there is no process needed to keep the neo vibrating... just issue a `echo 0 > /sys/devices/platform/neo1973-vibrator.0/leds/neo1973:vibrator/brightness
Sep 19 11:08:38 <mickeyl> something seems to be wrong wrt. our rules
Sep 19 11:08:50 <mickeyl> check /etc/freesmartphone/, rules file is somewhere there
Sep 19 11:10:38 <quickdev> AndreasD, do you know what libjana is for? there isn't much information on it on the internet
Sep 19 11:11:26 <mickeyl> libjana is a gtk utility class
Sep 19 11:11:29 <mickeyl> containing some widgets
Sep 19 11:12:27 <quickdev> mickeyl, so there's not libjana without gtk?
Sep 19 11:13:17 <AndreasD> quickdev: have you looked at http://chrislord.net/blog/
Sep 19 11:13:35 <mickeyl> quickdev: nope
Sep 19 11:13:48 <mickeyl> everything o-hand does is pretty much tied to gtk
Sep 19 11:13:50 <quickdev> AndreasD, yes, but I wondered wether there is libjana without gtk
Sep 19 11:14:00 <mickeyl> or rather... most of it
Sep 19 11:14:10 <quickdev> ok, then I'll remove jana things from ophonekitd
Sep 19 11:15:06 <AndreasD> hmm I think Chris have split it into several packages
Sep 19 11:15:19 <AndreasD> but I do not know if gtk is still needed
Sep 19 11:29:05 <AndreasD> quickdev: if you want to avoid gtk simply remove libjana-gtk in configure.ac
Sep 19 11:29:16 <quickdev> AndreasD, did that some minutes ago, yes :)
Sep 19 11:30:01 <b0ef> emdete: no; that's not right, because it's pulsating
Sep 19 11:30:19 <AndreasD> quickdev: long term we probably want to move the jana stuff into some lib
Sep 19 11:30:43 <b0ef> it seems it's possible to have the chip pulsate on its own
Sep 19 11:30:52 <b0ef> from the log, it says: 
Sep 19 11:31:18 <mickeyl> echo "none" to .../trigger
Sep 19 11:31:27 <b0ef> writing 'timer' to '/sys/class/leds/neo1973:vibrator/trigger'
Sep 19 11:31:27 <b0ef> writing '300' to '/sys/class/leds/neo1973:vibrator/delay_on'
Sep 19 11:31:27 <b0ef> writing '700' to '/sys/class/leds/neo1973:vibrator/delay_off
Sep 19 11:31:29 <b0ef> right
Sep 19 11:31:46 <b0ef> so, everybody has been telling me it's not possible and now mickeyl comes and clears it up;)
Sep 19 11:31:47 <AndreasD> quickdev: I guess we really want to keep ophonekitd PIM independent
Sep 19 11:31:50 <AndreasD> but lets try and get something working first
Sep 19 11:32:46 <quickdev> AndreasD, yes, did the gtk ui work?
Sep 19 11:33:20 <AndreasD> quickdev: it pops up on calls 
Sep 19 11:33:33 <quickdev> AndreasD, sms or sim ui?
Sep 19 11:33:35 <b0ef> mickeyl: it seems indeed the case that my sim does not hold more sms and contacts, btw;)
Sep 19 11:33:43 <AndreasD> and disappears on HELD/RELEASE(D)
Sep 19 11:34:05 <mickeyl> b0ef: *phew* glad to hear (in some sense)
Sep 19 11:34:24 <b0ef> mickeyl: yeah, but really weird; only 2 contacts on the sim and about 100 in the phone
Sep 19 11:34:33 <mickeyl> must be a very old sim card
Sep 19 11:34:44 <AndreasD> quickdev: talking ui, sms should work as well however was some time ago
Sep 19 11:34:45 <b0ef> yeah, it's very old
Sep 19 11:38:23 <rwhitby> mickeyl: ping - were you going to do an announcement email?
Sep 19 11:38:54 <mickeyl> yeah
Sep 19 11:39:05 <mickeyl> had to post it on my blog first though
Sep 19 11:39:08 <rwhitby> cool
Sep 19 11:39:23 <quickdev> what to announce? :)
Sep 19 11:39:35 <rwhitby> downloads.freesmartphone.org
Sep 19 11:40:36 <b0ef> mickeyl: now to the crash thing; I got logs when it crash, but they are about 6Mio; what to do?
Sep 19 11:40:57 <mickeyl> tar.bz2 'em up and give me some URL to download
Sep 19 11:44:27 <quickdev> AndreasD, the libframeworkd-phonegui-* should be allowed to access libframeworkd-glib, right?
Sep 19 11:45:04 <AndreasD> quickdev: yes
Sep 19 11:45:18 <AndreasD> why?
Sep 19 11:46:59 <mickeyl> b0ef: excellent, thanks. *downloading*
Sep 19 11:48:22 <quickdev> AndreasD, because my efl lib is actually doing it that way
Sep 19 11:50:16 <b0ef> mickeyl: this log is from when I received a call and it just stopped responding to anything; couldn't press the button to take the call no matter how many times I pressed it
Sep 19 11:50:25 <AndreasD> quickdev: okay, we would naturally like to keep as much common code in ophonekitd
Sep 19 11:51:34 <quickdev> yes
Sep 19 11:57:11 <ptitjes> hi
Sep 19 11:57:17 <ptitjes> please what package builds the kernel via MokoMakefile ??
Sep 19 11:59:54 <ptitjes> how to rebuild the kernel with MokoMakefile ?
Sep 19 12:01:05 <jmichel> ptitjes: the package is linux-openmoko
Sep 19 12:01:21 <ptitjes> jmichel: thx
Sep 19 12:01:35 <jmichel> so to rebuild kernel you do "make clean-package-linux-openmoko" and "make build-package-linux-openmoko"
Sep 19 12:03:21 <jmichel> I have a problem with the toolchain when building I have this error: "libtool: link: cannot find the library `/usr/lib/libusb-1.0.la'"
Sep 19 12:03:53 <jmichel> why is it looking in /usr/lib/? It should be looking in /usr/local/openmoko/...
Sep 19 12:04:09 <jmichel> I can't find where to configure this
Sep 19 12:12:25 <mickeyl> b0ef: ok, thanks. I'll take a look
Sep 19 12:28:03 <quickdev> I need the linker to get the -E option. How do I do that with automake? Searched many minutes on google..
Sep 19 12:34:03 <quickdev> ok, solved it.
Sep 19 12:35:11 <AndreasD> quickdev: solved what? :-)
Sep 19 12:35:46 <quickdev> AndreasD, I needed to add -E to the LDFLAGS
Sep 19 12:37:12 <AndreasD> quickdev: what are you doing? Sorry had to move to another room
Sep 19 12:37:34 <Weiss> when reading the accelerometer data, is it necessary to wait for a sync message, or does the kernel do magic that means that the first thing you read is always the start of a message?
Sep 19 12:37:40 <quickdev> AndreasD, I'm going to use dlopen() to load the phonegui libs defined in a config file
Sep 19 12:41:33 <quickdev> AndreasD, is there something against that approach?
Sep 19 12:43:35 <AndreasD> quickdev: No, it is actually quite nice :-)
Sep 19 13:47:41 <quickdev> Ainulindale, how are you?
Sep 19 13:48:24 <quickdev> Sup3rkiddo, will your odeviced be integrated into frameworkd?
Sep 19 13:48:46 <Sup3rkiddo> quickdev, i have started working on that...
Sep 19 13:48:56 <quickdev> ah, wonderful :)
Sep 19 13:49:42 <Sup3rkiddo> quickdev, theres already sources in the git repos...although no recipe yet....still working on a generic controller for the subsystems..
Sep 19 13:50:27 <quickdev> Sup3rkiddo, I assume it isn't easy to control C things through python?
Sep 19 13:51:36 <Sup3rkiddo> quickdev, theres cython and pyrex...ctypes too if you are crazy enough....but i haven't done anything with them yet...so wouldn't know how easy it is..
Sep 19 13:54:00 <Ainulindale> quickdev: I'm currently in a meeting I'll talk to you in an hour or so
Sep 19 13:54:33 <quickdev> Ainulindale, ok, thanks, good luck
Sep 19 13:58:41 <quickdev> mickeyl, is there atm any access to the vibrator via frameworkd dbus?
Sep 19 13:59:08 <Sup3rkiddo> quickdev, LED interface
Sep 19 13:59:48 <quickdev> Sup3rkiddo, http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.LED.html;hb=HEAD - how do I specify the led / vibrator?
Sep 19 14:00:14 <mickeyl> just use the proper object path
Sep 19 14:00:27 <mickeyl> use mdbus -s to introspect what's available
Sep 19 14:01:08 <quickdev> ah, wonderful, thanks
Sep 19 14:13:56 <jmichel> Sorry to ask again this question but when building with the toolchain I have this error: "libtool: link: cannot find the library `/usr/lib/libusb-1.0.la'"
Sep 19 14:14:20 <jmichel> I have installed libusb in my toolchain and the file is in /usr/local/openmoko/.../lib
Sep 19 14:14:33 <jmichel> why is it looking in /usr/lib/? It should be looking in /usr/local/openmoko/... and I don't know where to configure this
Sep 19 14:17:47 <quickdev> jmichel, did you execute setup-env before?
Sep 19 14:17:57 <jmichel> yes
Sep 19 14:18:23 <jmichel> om-build worls flawlessly and I can build other project that don't require libusb
Sep 19 14:18:41 <jmichel> sorry:  worls = works  
Sep 19 14:19:28 <quickdev> try to find the place where libusb is referred to...maybe /ur/lib is hardcoded...if it's done very dirty
Sep 19 14:20:04 <quickdev> AndreasD, it's planned that ophonekitd and openmoko-dialer3 use the same libframeworkd-phonegui-gtk, right?
Sep 19 14:20:34 <Ainulindale> quickdev: yes
Sep 19 14:23:52 <jmichel> quickdev: There is no ref to libusb other than in the configure.ac (-llibusb) for dynamic linking so the error must in the files genarated by the toolchain
Sep 19 14:24:22 <quickdev> jmichel, did you do om-conf projectdir ?
Sep 19 14:24:29 <jmichel> quickdev: I will check the Makefile generated by om-conf
Sep 19 14:24:39 <quickdev> ok
Sep 19 14:24:44 <jmichel> yes om-conf works 
Sep 19 14:27:48 <quickdev> jmichel, what does `env` say?
Sep 19 14:30:14 <jmichel> quickdev: http://pastebin.ca/1205870
Sep 19 14:31:19 <quickdev> jmichel, /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib - is your lib there?
Sep 19 14:31:49 <jmichel> yes
Sep 19 14:32:22 <quickdev> jmichel, show us your Makefile please
Sep 19 14:32:28 <jmichel> the .la and .so are in this folder because I installed libusb with opkg-target in my toolchain
Sep 19 14:35:55 <jmichel> quickdev: here it is: http://pastebin.ca/1205873
Sep 19 14:37:04 <quickdev> jmichel, LDFLAGS seems to be ok, doesn't it?
Sep 19 14:38:13 <jmichel> yes.... that is what I don't understand
Sep 19 14:40:39 <quickdev> jmichel, is your lib name equal to 'libusb-1.0.la'?
Sep 19 14:41:56 <jmichel> what do you mean by lib name?
Sep 19 14:42:33 <quickdev> the file located in /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib
Sep 19 14:42:47 <quickdev> ls -alF /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib/libusb-1.0.la
Sep 19 14:43:43 <jmichel> I have this file: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib/libusb-1.0.la
Sep 19 14:44:03 <jmichel> and this one: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib/libusb.la
Sep 19 14:45:38 <jmichel> and in my LDFLAGS I have -lusb so I thought it would use the right one
Sep 19 14:47:44 <jmichel> Another thing is that when the error occurs the build is running a script called ./libtool which I guess was also generated by the om-conf application?
Sep 19 15:26:36 <quickdev> AndreasD, thinking logically: Shouldn't libframeworkd-phonegui-efl be called libophonekitd-efl ?
Sep 19 15:27:31 <AndreasD> quickdev: got a point :-)
Sep 19 15:35:04 <CIA-57> freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * r992d7cff845f 10/fsod/ (4 files in 3 dirs): refactor code for requesting DBus names
Sep 19 15:35:04 <CIA-57> freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * r10158f3274ee 10/fsod/ (6 files in 4 dirs): 
Sep 19 15:35:04 <CIA-57> freesmartphone.org: 1.) Reintroduce Subsystem.Manager abstract class for use by the
Sep 19 15:35:05 <CIA-57> freesmartphone.org: Subsystems
Sep 19 15:35:06 <CIA-57> freesmartphone.org: 2.) Add ListOb
Sep 19 15:35:08 <CIA-57> freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * r5a369181d445 10/fsod/src/fsod.vala: commit properly
Sep 19 15:53:52 <quickdev> Ainulindale, should we rename libframeworkd-phonegui-* to libophonekit-gui-*?
Sep 19 16:07:46 <Ainulindale> quickdev: Nope :-)
Sep 19 16:08:12 <Ainulindale> The implemented functions are related to frameworkd
Sep 19 16:08:18 <Ainulindale> ophonekitd is mainly a link
Sep 19 16:08:26 <Ainulindale> and the name is a private joke
Sep 19 16:08:56 <Ainulindale> And I seriously think that even if the name was libspankmewithashovel-gui-* it wouldn't matter :-)
Sep 19 16:09:02 <quickdev> ah, yeah, makes sense, too
Sep 19 16:09:17 <quickdev> I'm just implementing a module loader
Sep 19 16:09:28 <Ainulindale> Nice :-)
Sep 19 16:10:10 <quickdev> Ainulindale, don't you think that the phonegui_destroy_pin_UI() method is dispensable?
Sep 19 16:10:36 <quickdev> the ui will know if it should close itself 
Sep 19 16:11:19 <quickdev> instead of phonegui_disply_pin_ui() and phonegui_destroy_pin_ui() a function phonegui_trigger_sim_auth_UI() would be sufficient, wouldn't it?
Sep 19 16:13:01 <quickdev> Ainulindale, what do you think?
Sep 19 16:23:05 <Ainulindale> quickdev: wrong
Sep 19 16:23:18 <Ainulindale> quickdev: if you type a wrong pin
Sep 19 16:23:24 <Ainulindale> or if you need PUK because you locked your pin
Sep 19 16:23:47 <Ainulindale> We did that having in mind the fact that destroying/constructing an UI might be power consuming
Sep 19 16:23:59 <Ainulindale> So we don't display/destroy if it's not truly necessary
Sep 19 16:24:14 <quickdev> Ainulindale, my application already handles wrong pin / puk and it quits if auth is successful.
Sep 19 16:24:30 <Ainulindale> quickdev: your application shouldn't handle that
Sep 19 16:24:34 <Ainulindale> The daemon should
Sep 19 16:24:41 <Ainulindale> The application should know what it has to ask
Sep 19 16:24:57 <Ainulindale> But not be told that kind of information related to the "model"
Sep 19 16:25:03 <Ainulindale> (that's my opinion :-) )
Sep 19 16:25:07 <quickdev> Ainulindale, ophonekitd should handle PIN / PUK, wrong and right?
Sep 19 16:25:18 <Ainulindale> "wrong and right" ?
Sep 19 16:25:31 <quickdev> Ainulindale, PIN correct, PUK correct and wrong
Sep 19 16:25:38 <Ainulindale> quickdev: the fact is :
Sep 19 16:25:43 <wurp2|working> Ainulindale: I suspect he means ophonekitd should properly handle entry of both correct and incorrect pins
Sep 19 16:25:55 <Ainulindale> You can't ask, in your UI, if what you gave is right
Sep 19 16:26:00 <Ainulindale> Because this information should be managed by the daemon
Sep 19 16:26:12 <Ainulindale> So yes, ophonekitd should manage the authentication status
Sep 19 16:26:23 <Ainulindale> But in the end that means that your UI should only know what it has to ask for
Sep 19 16:26:29 <quickdev> Ainulindale, should the phonegui have any access to libframeword-glib at all?
Sep 19 16:26:33 <Ainulindale> probably to display the right information
Sep 19 16:26:47 <Ainulindale> quickdev: that depends and that is a bit fuzzy for me for some things
Sep 19 16:27:01 <Ainulindale> I think all the logical manipulation linked with GSM shouldn't be in phonegui
Sep 19 16:27:07 <Ainulindale> Things as ponctual actions should
Sep 19 16:27:13 <Ainulindale> e.g. initiate a call, hangup
Sep 19 16:27:35 <Ainulindale> But that's my conception of the thing
Sep 19 16:27:45 <Ainulindale> And you can do as you wish
Sep 19 16:28:04 <Ainulindale> I just think mixing the GSM logic and the UI stuff is painful and confusing
Sep 19 16:28:13 <quickdev> of course I'd like to go the best way..hm
Sep 19 16:28:23 <Ainulindale> If we can identify a behaviour common to all the UIs
Sep 19 16:28:28 <Ainulindale> It should go in ophonekitd IMH>O
Sep 19 16:28:32 <quickdev> yeah
Sep 19 16:28:33 <Ainulindale> s/>//
Sep 19 16:28:49 <Ainulindale> That's why, in my mind
Sep 19 16:29:02 <Ainulindale> The PIN screen should not know if its pin is right or wrong
Sep 19 16:29:08 <Ainulindale> If it's right, ophonekitd will destroy it
Sep 19 16:29:19 <Ainulindale> If it's wrong, ophonekitd will trigger a re-display
Sep 19 16:29:24 <Ainulindale> Giving it the code to a sk
Sep 19 16:29:28 <Ainulindale> PIN or PUK
Sep 19 16:29:40 <Ainulindale> That way the UI stays in memory
Sep 19 16:29:49 <Ainulindale> There's no unecessary "destroy()"
Sep 19 16:29:53 <quickdev> Ainulindale, I'd like to display a success message. What about that?
Sep 19 16:30:03 <Ainulindale> I did that because I felt the painful experience of 2007.2 :-p
Sep 19 16:30:10 <Ainulindale> quickdev: that's no problem
Sep 19 16:30:21 <Ainulindale> you implement that in the phonegui destroy function
Sep 19 16:30:38 <Ainulindale> You have several choices for that
Sep 19 16:30:42 <quickdev> Ainulindale, where do you get the status in the destroy function? UI don't know status..
Sep 19 16:30:50 <Ainulindale> You can even use the glib to use libnotify 
Sep 19 16:30:51 <quickdev> *doesn't know
Sep 19 16:30:58 <Ainulindale> Thus destroying the UI and displaying a message at the same time
Sep 19 16:31:18 <Ainulindale> quickdev: if the UI is destroyed, that's because authentication went well
Sep 19 16:31:39 <quickdev> Ainulindale, so there must be a third function: redo_authentication() ?
Sep 19 16:31:43 <Ainulindale> The whole assumption is that the UI is destroyed once its purpose reaches its end
Sep 19 16:31:48 <Ainulindale> nope
Sep 19 16:31:59 <Ainulindale> You just recall the display function
Sep 19 16:32:11 <Ainulindale> WHich could be misnamed if this is what you're blocing on
Sep 19 16:32:12 <Ainulindale> +k
Sep 19 16:32:23 <quickdev> that would load the whole ui again?
Sep 19 16:32:35 <Ainulindale> Not if your UI manages it 
Sep 19 16:32:40 <quickdev> ah, yeah
Sep 19 16:32:40 <Ainulindale> Let me explain the whole process :
Sep 19 16:32:46 <Ainulindale> First you have the phonegui init things
Sep 19 16:32:53 <Ainulindale> In which you can attach to the mainloop
Sep 19 16:32:57 <Ainulindale> init your toolkit libraries
Sep 19 16:33:00 <Ainulindale> even preload screens
Sep 19 16:33:13 <Ainulindale> the phonegui_display_* functions merely display screens
Sep 19 16:33:20 <Ainulindale> It doesn't care if they are preloaded or what
Sep 19 16:33:36 <Ainulindale> the destroy function is just a way to say you hide the window
Sep 19 16:33:58 <Ainulindale> It should be named "hide" if you think this is confusing
Sep 19 16:34:27 <Ainulindale> Whether you actually hide (in the case of the talking screen) or destroy (in the case of the pin) is a matter managed within the library
Sep 19 16:34:56 <Ainulindale> Is it clearer ?
Sep 19 16:35:48 <quickdev> Ainulindale, yes it, I think it makes most sense. let's name it phonegui_show_sim_auth_ui() and phonegui_hide_sim_auth_ui() ?
Sep 19 16:36:00 <Ainulindale> You can do that if you wish it so
Sep 19 16:36:07 <Ainulindale> But don't focus on names :-)
Sep 19 16:36:11 <Ainulindale> I agree names are important
Sep 19 16:36:25 <Ainulindale> But we can do a bunch of renaming when things will work :-)
Sep 19 16:36:25 <quickdev> Ainulindale, phonegui-gtk isn't used atm, is it?
Sep 19 16:36:34 <Ainulindale> It isn't functional so no it isn't used
Sep 19 16:36:45 <Ainulindale> quickdev: If you have time for that we could work together to identify screens
Sep 19 16:36:46 <quickdev> ok, fine
Sep 19 16:36:56 <Ainulindale> and declare the correspondant functions in the header
Sep 19 16:37:06 <quickdev> identify screens? what screens?
Sep 19 16:37:14 <Ainulindale> Screens related to GSM management
Sep 19 16:37:16 <Ainulindale> E.g. :
Sep 19 16:37:18 <Ainulindale> Talking
Sep 19 16:37:19 <Ainulindale> Pin
Sep 19 16:37:21 <Ainulindale> Dial
Sep 19 16:37:23 <Ainulindale> DTMF
Sep 19 16:37:51 <Ainulindale> And define their parameter
Sep 19 16:37:54 <quickdev> ah..yes..I'll implement mine and then you can see what you think is missing
Sep 19 16:37:57 <Ainulindale> E.g. : Talking(Outgoing|Incoming)
Sep 19 16:38:07 <Ainulindale> quickdev: I'd rather discuss about that :-)
Sep 19 16:38:18 <quickdev> yeah, ok ;)
Sep 19 16:38:23 <Ainulindale> Might be more time consuming but I think it will be easier for all of us
Sep 19 16:38:29 <Ainulindale> And I'm sure I don't have the whole picture in mind
Sep 19 16:39:10 <quickdev> I will start rewriting my ui in about half an hour..
Sep 19 16:40:17 <quickdev> Ainulindale, libframeworkd-glib should contain the libframeworkd-phonegui.h file as you said?
Sep 19 16:40:24 <Ainulindale> yep
Sep 19 16:41:04 <quickdev> did you look at my patch?
Sep 19 16:41:45 <Ainulindale> Not at all, I spent the whole day in meetings
Sep 19 16:43:54 <quickdev> ok, no prob
Sep 19 16:44:00 <Ainulindale> But I will
Sep 19 16:44:15 <Ainulindale> I'm truly sorry I'm not able to spend time to help you these days :-)
Sep 19 16:44:37 <Ainulindale> We're on a big contract and the delivery time for the proposition is next week
Sep 19 16:46:04 <Ainulindale> Well I'm going home
Sep 19 16:46:06 <Ainulindale> See you later
Sep 19 16:46:11 <quickdev> Ainulindale, of course your life is much more serious :)
Sep 19 16:46:22 <quickdev> good luck with your preposition
Sep 19 16:46:25 <quickdev> see you later :)
Sep 19 17:09:18 <CIA-57> freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * recaa10250a9b 10/fsod/src/subsystems/Device/ (Device.vala helpers.vala): Not all subsystems would have plugins to load
Sep 19 17:15:34 <CIA-57> freesmartphone.org: 03sudharsh 07openmoko-gsoc2008 * r03f02f707772 10/fsod/src/subsystem.vala: Commit properly
Sep 19 17:26:26 <quickdev> damn connection.
Sep 19 17:37:26 <Weiss> anyone know what the units are from the accelerometer data?
Sep 19 17:49:11 <sirkha> ok, fso, milestone three image, whenever i do a discovery, it lasts less than a second, doesn't discover anything, and then completes, anyone know how to fix this?
Sep 19 17:51:36 <wurp2|working> sirkha: Install another image
Sep 19 17:53:18 <Ainulindale> wurp2|working: stop trolling !
Sep 19 17:54:13 <wurp2|working> Ainulindale: trolling is all I have left; don't take that away from me!
Sep 19 17:54:28 <quickdev> Ainulindale, back?
Sep 19 17:58:01 <quickdev> Ainulindale, back?
Sep 19 17:58:35 <Ainulindale> and forth
Sep 19 17:58:47 <Ainulindale> I have to go for some time
Sep 19 17:58:51 <Ainulindale> Is this important ? :-)
Sep 19 17:59:07 <quickdev> no, leave! ;)
Sep 19 18:00:08 <wurp2|working> heh, that makes your decision easy, Julien
Sep 19 19:37:26 <quickdev> good evening
Sep 19 19:37:49 <quickdev> Ainulindale, here to do some api work? ;)
Sep 19 22:10:59 <rwhitby> morning
Sep 19 22:11:41 <wurp2|working> rwhitby: where the hell are you?
Sep 19 22:11:51 <rwhitby> GMT+9:30
Sep 19 22:11:58 <rwhitby> ~ugt anyway
Sep 19 22:12:14 <wurp2|working> well, if you call anything AM morning...
Sep 19 22:12:50 <rwhitby> 7:42am is usually morning, but UGT applies anyway
Sep 19 22:13:07 <wurp2|working> Yeah, 7:42 is morning to me... are you in Aus?
Sep 19 22:13:15 <rwhitby> http://www.total-knowledge.com/~ilya/mips/ugt.html
Sep 19 22:13:25 <rwhitby> adelaide, austraila
Sep 19 22:13:29 <rwhitby> australia even
Sep 19 22:14:01 <wurp2|working> Aus is the only place I knew in GMT+7 range that would have 1/2 hour time zones...
Sep 19 22:14:22 <rwhitby> Nepal has an interesting timezone
Sep 19 22:14:33 <rwhitby> Chatham Islands too
Sep 19 22:14:45 <wurp2|working> Sorry, gotta go
Sep 19 22:14:49 <wurp2|working> wife is here
Sep 19 22:14:52 <wurp2|working> Have a good weekend!
Sep 19 22:15:35 <sicu> wurp2|gone: good to see someone is keeping you in line
Sep 19 22:18:28 <rwhitby> mickey|sofa: I'm fixing python-pygobject in preferred-om-2008-versions.inc and fixing the fso-testing feed and image accordingly
Sep 19 22:18:42 <rwhitby> 2.14.2 is what we want, right?
Sep 19 23:12:31 <rwhitby> fso-testing feeds and images should be fixed now
**** ENDING LOGGING AT Sat Sep 20 02:59:57 2008