**** BEGIN LOGGING AT Sun Jan 09 02:59:58 2011
Jan 09 06:09:08 <GNUtoo|laptop> hi,
Jan 09 06:09:10 <GNUtoo|laptop> sigh
Jan 09 06:09:16 <GNUtoo|laptop> nokia900 is unusable
Jan 09 06:09:30 <GNUtoo|laptop> touchscreen pressure is not correct
Jan 09 06:09:40 <GNUtoo|laptop> battery charging doesn't work anymore
Jan 09 06:09:53 <GNUtoo|laptop> it express-charges from the bootloader
Jan 09 06:09:55 <GNUtoo|laptop> it boots
Jan 09 06:10:05 <GNUtoo|laptop> and then doesn't charge within fsodeviced
Jan 09 06:10:09 <GNUtoo|laptop> and reboots
Jan 09 06:10:33 <GNUtoo|laptop> added to that the huge battery consumation because of the lack of DVFS
Jan 09 06:10:53 <GNUtoo|laptop> with the fact that userland didn't catch up with the newer kernel
Jan 09 06:11:06 <GNUtoo|laptop> xorg.conf catched up
Jan 09 06:11:12 <GNUtoo|laptop> but not alsa routing
Jan 09 06:11:16 <GNUtoo|laptop> or similar stuff
Jan 09 06:11:32 <GNUtoo|laptop> side button too for instance didn't catchup
Jan 09 06:11:42 <GNUtoo|laptop> mickeyl, ^^^
Jan 09 06:12:04 <GNUtoo|laptop> bluetooth is unusable because of the lack of bt coex
Jan 09 11:36:12 <mrmoku> hi GNUtoo|laptop 
Jan 09 11:36:18 <GNUtoo|laptop> hi
Jan 09 11:36:39 <mrmoku> do yo remember what the problem with fsodeviced is? multiple plugins for one resource?
Jan 09 11:36:42 <mrmoku> making it segfault?
Jan 09 11:36:46 <GNUtoo|laptop> yes
Jan 09 11:37:03 <GNUtoo|laptop> multiple plugin for one resource makes some issues
Jan 09 11:37:11 <GNUtoo|laptop> I don't remember if it segfaulted at the end
Jan 09 11:37:16 <GNUtoo|laptop> but at least it exited
Jan 09 11:37:19 <mrmoku> it segfaults on gta02
Jan 09 11:37:28 <mrmoku> it does not segfault when disabling the rkill plugin
Jan 09 11:38:10 <GNUtoo|laptop> when having only one plugin for one resource it didn't exit
Jan 09 11:38:33 <GNUtoo|laptop> but I don't remember if the exit is because of a segfault
Jan 09 11:38:38 <GNUtoo|laptop> but it should tell you
Jan 09 11:38:48 <GNUtoo|laptop> #fsodeviced
Jan 09 11:38:52 <GNUtoo|laptop> run it like that
Jan 09 11:39:53 <mrmoku> hmm... and on GTA02 it's bluetooth using rfkill and openmoko_powercontrol plugins then :/
Jan 09 11:40:33 <mrmoku> mickeyl: ping, we should decide how to fix that rather soon :)
Jan 09 11:41:13 <mrmoku> ahh... wifi too
Jan 09 11:41:17 <GNUtoo|laptop> mrmoku, then send a mail describing how om-gta02 handle that on the fso-userland ml
Jan 09 11:41:23 <GNUtoo|laptop> responding to my mail
Jan 09 11:41:28 <GNUtoo|laptop> on resource stuff
Jan 09 11:41:43 <mrmoku> ok
Jan 09 11:43:11 <mrmoku> ** (process:342): CRITICAL **: file dbusresource.c: line 287: uncaught error: An object is already exported for the interface org.freesmartphone.Resource at /org/freesmartphone/Resource/Bluetooth (g-io-error-quark, 2)
Jan 09 11:43:15 <mrmoku> Segmentation fault
Jan 09 11:43:32 <GNUtoo|laptop> yes that
Jan 09 11:43:47 <GNUtoo|laptop> btw n900 is now unusable:
Jan 09 11:43:58 <GNUtoo|laptop> touchscreen is unusable with current kernel
Jan 09 11:44:25 <GNUtoo|laptop> battery charging doesn't work anymore(maybe it has to do with bootloader fast-charging the battery)
Jan 09 11:44:47 <GNUtoo|laptop> it consume battery very rapidely(no DVFS)
Jan 09 11:45:27 <mrmoku> I responded to your kernel mail
Jan 09 11:45:30 <GNUtoo|laptop> and finally userland didn't finish to catch up with the newer kenrel(alsa routing,side button etc...)
Jan 09 11:45:34 <GNUtoo|laptop> ok
Jan 09 11:45:46 <mrmoku> have to go now... family time
Jan 09 11:45:50 <GNUtoo|laptop> ok
Jan 09 11:46:26 <mrmoku> bbl
Jan 09 12:00:20 <mickeyl> good morning. i have some important things to do but will be avilable 2nd half of day
Jan 09 12:00:26 <mickeyl> lets talk then
Jan 09 12:05:21 <GNUtoo|laptop> ok let's talk the second half of the day
Jan 09 12:59:33 * mrmoku wonders when for mickeyl the second half of the day starts... as for me it's around high noon ;)
Jan 09 13:23:45 <mickeyl> mrmoku: heh
Jan 09 13:23:48 <mickeyl> :)
Jan 09 13:24:01 <mickeyl> the joys of not yet being parents...
Jan 09 13:24:06 <mickeyl> sleeping long
Jan 09 13:28:42 <lindi-> gena2x: 2.6.37 just hit the resume bug and the u-boot watchdog rebooted it :)
Jan 09 13:29:14 <gena2x> lindi-: so, now you have workaround and stop attempts to fix it? :)
Jan 09 13:29:49 <gena2x> lindi-: but anyway, nice that it works!
Jan 09 13:30:33 <gena2x> lindi-: i can't find anything in my .config which can make my UBI read-only in .37 :(
Jan 09 13:31:53 <lindi-> this looks like a different resume bug
Jan 09 13:35:05 <gena2x> what is different?
Jan 09 13:35:50 <lindi-> gena2x: kernel is able to log something
Jan 09 13:36:01 <gena2x> it is actually very nice i think
Jan 09 13:36:17 <gena2x> for debugging at least
Jan 09 13:37:30 <gena2x> anyway, with watchdog you can add some printfs to ram even in bootloader :)
Jan 09 13:39:28 <lindi-> gena2x: or maybe the watchdog timeout killed it
Jan 09 13:39:58 <gena2x> 42 seconds to resume?
Jan 09 13:40:17 <gena2x> time to kill :)
Jan 09 13:40:32 <mrmoku> mickeyl: yeah
Jan 09 13:40:50 * mrmoku lunch now though
Jan 09 13:40:52 <lindi-> gena2x: it really didn't wait for 42 seconds
Jan 09 13:40:54 <mrmoku> bb after
Jan 09 13:41:10 <lindi-> gena2x: so either I have configured the watchdog wrongly or something else than watchdog rebooted it
Jan 09 13:41:41 <gena2x> lindi-: hm, you should just max-out all values.
Jan 09 13:42:12 <gena2x> lindi-: something else sounds strange
Jan 09 13:43:12 <gena2x> lindi-: and if PCLK didn't really go mad (which is really unlikely), you should get 42 and no more, no less
Jan 09 13:44:54 <lindi-> gena2x: the patch is http://paste.debian.net/104127/
Jan 09 13:46:08 <lindi-> gena2x: I'll revert back to 2.6.29 and see if I get the same issue
Jan 09 13:46:41 <gena2x> look like overcomplicated
Jan 09 13:47:03 <gena2x> i think you just can set all velues in registers
Jan 09 13:47:27 <lindi-> gena2x: what do you mean?
Jan 09 13:50:02 <CIA-70> freesmartphone.org: 03mickey 07specs * r5da948dd2a14 10/ (10 files in 4 dirs): start w/ org.freesmartphone.Context.Manager and org.freesmartphone.Context.Client APIs
Jan 09 13:50:03 <CIA-70> freesmartphone.org: 03mickey 07specs * r5f893651d22d 10/ (3 files in 2 dirs): bump version
Jan 09 13:51:10 <gena2x> lindi-: ah, my bad. it's ok
Jan 09 13:52:23 <CIA-70> freesmartphone.org: 03mickey 07specs * r1eb759263f91 10/ (3 files in 3 dirs): org.freesmartphone.Context.Client is a NoReply interface
Jan 09 13:53:23 <CIA-70> freesmartphone.org: 03mickey 07gdbus * r42c5f5aadf32 10libfso-glib/configure.ac: bump
Jan 09 13:53:29 <lindi-> gena2x: ok so I'll retry with 2.6.29. if it still doesn't buzz for 42 seconds then I need to investigate u-boot/watchdog more
Jan 09 13:53:42 <lindi-> gena2x: if it does buzz for 42 seconds with 2.6.29 then something else is rebooting 2.6.37
Jan 09 13:54:17 <gena2x> lindi-: may be kernel resetups watchdog in wrong moment?
Jan 09 13:54:55 <gena2x> lindi-: it may be worth checking how kernel setup it
Jan 09 13:55:23 <lindi-> gena2x: maybe
Jan 09 14:00:54 <CIA-70> freesmartphone.org: 03mickey 07gdbus * r89666f20284c 10libfso-glib/src/Makefile.am: install context API
Jan 09 14:23:06 <mrmoku> mickeyl: yeah better start the 'get-up-early' training :)
Jan 09 14:23:40 <mickeyl> *sigh* ;)
Jan 09 14:24:21 <mrmoku> :P
Jan 09 14:24:26 <mrmoku> so what is Context.Manager? 
Jan 09 14:24:38 <mrmoku> the solution to the multiple plugins problem?
Jan 09 14:25:23 <mickeyl> no, i wanted to get more input before tackling that
Jan 09 14:25:27 <mrmoku> ok
Jan 09 14:25:33 <mickeyl> contextmanager is the combined location stuff
Jan 09 14:25:41 <mrmoku> ah, ok
Jan 09 14:26:00 <mickeyl> so, shall we talk about the device resources?
Jan 09 14:26:03 <mrmoku> yup
Jan 09 14:26:07 <mrmoku> it's quite pressing
Jan 09 14:26:22 <mrmoku> maybe on of the last things before we can sync gdbus to the world
Jan 09 14:26:38 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * r143177941f01 10/libfsoframework/fsoframework/interfaces.vala: libfsoframework: add context interface
Jan 09 14:26:40 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * r7d26af3b8e71 10/fsotdld/ (7 files in 5 dirs): fsotdld: start with contextmanager plugin
Jan 09 14:26:41 <mickeyl> ok
Jan 09 14:26:47 <mrmoku> GNUtoo|laptop: here?
Jan 09 14:26:47 <mickeyl> sooo
Jan 09 14:27:13 <mrmoku> right now fsodeviced segfaults
Jan 09 14:27:13 <mrmoku> ** (process:342): CRITICAL **: file dbusresource.c: line 287: uncaught error: An object is already exported for the interface org.freesmartphone.Resource at /org/freesmartphone/Resource/Bluetooth (g-io-error-quark, 2)
Jan 09 14:27:18 <mrmoku> Segmentation fault
Jan 09 14:27:24 <GNUtoo|laptop> mrmoku, yes
Jan 09 14:27:25 <mickeyl> right
Jan 09 14:27:33 <mickeyl> this is something that has to be fixed in any case
Jan 09 14:27:44 <mickeyl> do you have a full BT?
Jan 09 14:27:51 <mrmoku> no
Jan 09 14:27:54 <mrmoku> can try to get one though
Jan 09 14:27:59 <mickeyl> ok, doesn't matter i can reproduce that somehow
Jan 09 14:28:21 <mrmoku> good :)
Jan 09 14:28:33 <mrmoku> so, what possible solutions do we have for that?
Jan 09 14:28:41 <mrmoku> we need rfkill
Jan 09 14:28:42 <mickeyl> wait a minute
Jan 09 14:28:46 <mickeyl> here comes the problem description
Jan 09 14:29:05 <mickeyl> problem description is different peripherals have needs of powering on / off. among the various needs are: (un)loading modules, starting/stopping helper processes, rfkill, bringing up/down network interfaces
Jan 09 14:29:12 <mickeyl> any more means?
Jan 09 14:29:22 <mrmoku> sysfs dances
Jan 09 14:29:26 <mickeyl> right
Jan 09 14:29:43 <mickeyl> anything more?
Jan 09 14:30:18 <mrmoku> hmm... GNUtoo|laptop you have anything more?
Jan 09 14:30:31 * mrmoku thinks that would be it
Jan 09 14:30:44 <mrmoku> but would do no harm if the solution to it is 'extensible'
Jan 09 14:30:45 <GNUtoo|laptop> mrmoku, ?
Jan 09 14:30:57 <mrmoku> GNUtoo|laptop: we're talking about the 2 plugins 1 resource problem
Jan 09 14:30:59 <GNUtoo|laptop> ok reading
Jan 09 14:31:14 <GNUtoo|laptop> there is also sysfs
Jan 09 14:31:20 <GNUtoo|laptop> that has sometimes to be accesed
Jan 09 14:31:25 <GNUtoo|laptop> like for instance
Jan 09 14:31:32 <mrmoku> 15:25 < mrmoku> sysfs dances
Jan 09 14:31:34 <GNUtoo|laptop> echo $MAC_ADDR /sys/
Jan 09 14:31:42 <GNUtoo|laptop> and not only echo 0 or 1
Jan 09 14:31:45 <mickeyl> ok. until linux gains a higher level powering interface for things like that, i only see two solutions in FSO to handle this problem. a) abstract that in quirks_<device>, b) come up with a smart plugin that can handle multiple ways, so that the only thing to be done per device is a description of the actual means (like a script, but without the forking, process control, etc.)
Jan 09 14:32:13 <mickeyl> a) means a quick solution on the expense of copy/pastenig code
Jan 09 14:32:22 <GNUtoo|laptop> what about a helper ?
Jan 09 14:32:27 <GNUtoo|laptop> so that it's handled in quirks
Jan 09 14:32:29 <GNUtoo|laptop> for instance
Jan 09 14:32:39 <mickeyl> b) means a nice expandable solution which is elegant, but takes some thought to implement it properly
Jan 09 14:32:47 <GNUtoo|laptop> activate_ifconfig()
Jan 09 14:32:57 <GNUtoo|laptop> activate_rfkill()
Jan 09 14:32:59 <mrmoku> how much work is a) ?
Jan 09 14:33:09 <mrmoku> could we do a) immediately and b) when done?
Jan 09 14:33:38 <GNUtoo|laptop> b) is like what I said
Jan 09 14:33:43 <GNUtoo|laptop> but done in quirk_device
Jan 09 14:34:30 <mickeyl> i'm somewhat hesitant to implement throw-away-solutions
Jan 09 14:34:40 <mickeyl> i.e. code that i know will not outlife the same month :)
Jan 09 14:34:45 <mrmoku> ok
Jan 09 14:35:01 <mickeyl> it doesn't need to be supergeneric
Jan 09 14:35:10 <mickeyl> just generic enough so that it covers our handful of usecases
Jan 09 14:35:30 <mrmoku> yup
Jan 09 14:36:40 <mickeyl> the segfault can easily be worked around by means of .conf for now
Jan 09 14:36:49 <mrmoku> well... how?
Jan 09 14:36:54 <mrmoku> I can disable rfkill
Jan 09 14:36:57 <mickeyl> yep
Jan 09 14:37:01 <mrmoku> but then wifi and bluetooth won't work
Jan 09 14:37:12 <mickeyl> the disable "the other one"
Jan 09 14:37:23 <mrmoku> which is the openmoko_powercontrol
Jan 09 14:37:30 <mrmoku> don't think we can disable it, no?
Jan 09 14:37:41 <mickeyl> i'm sure we can
Jan 09 14:37:52 <mickeyl> let me look what it does these days
Jan 09 14:38:22 <mrmoku> it does wifi sysfs dance, bt sysfs dance and usb host mode
Jan 09 14:38:45 <mickeyl> right
Jan 09 14:38:51 <mickeyl> so
Jan 09 14:38:52 <mrmoku> do wifi and bt work with rfkill only ?
Jan 09 14:38:58 <mickeyl> openmoko_powercontrol is older kernels
Jan 09 14:39:01 <mickeyl> rfkill is newer kernels
Jan 09 14:39:01 <mickeyl> no?
Jan 09 14:39:08 <mrmoku> dunno
Jan 09 14:39:09 <mickeyl> i thought that's what larsc implemented
Jan 09 14:39:14 <mrmoku> ahh, ok
Jan 09 14:39:23 <mickeyl> doing the sysfs dance should not be necessary on systems that implement rfkill
Jan 09 14:39:27 <mickeyl> otherwise it wuold be completely braindead
Jan 09 14:39:34 <mrmoku> yeah, right
Jan 09 14:39:36 * mrmoku tries
Jan 09 14:39:38 <mickeyl> one additional layer of complexity for nothing
Jan 09 14:39:39 <mickeyl> :)
Jan 09 14:40:40 <mrmoku> so disabling openmoko_powercontrol would let us loose only usb host mode
Jan 09 14:40:42 <PaulFertser> rfkill _is_ braindead.
Jan 09 14:40:45 <mrmoku> :)
Jan 09 14:40:48 <mickeyl> correct
Jan 09 14:40:53 <mickeyl> that means
Jan 09 14:40:59 <mickeyl> we can rip out BT and WiFi out of openmoko_powercontrol
Jan 09 14:41:04 <mrmoku> yup
Jan 09 14:41:04 <mickeyl> and keep both in the conf
Jan 09 14:41:24 <mickeyl> perhaps adding a switch
Jan 09 14:41:28 <mickeyl> in the .conf
Jan 09 14:41:35 <mickeyl> not completely losing compatibility with older kernels
Jan 09 14:41:42 <mrmoku> which would let us sync gdbus to the public and gives us more time to work on b)
Jan 09 14:41:47 <mickeyl> exactly
Jan 09 14:42:00 <mickeyl> i'm actually quite satisfied with gdbus
Jan 09 14:42:09 <mickeyl> apart from the necessary program changes (which were huge on the C side, sorry)
Jan 09 14:42:15 <mickeyl> it seeems to bear no new problems
Jan 09 14:42:18 <mrmoku> hehe, yeah
Jan 09 14:42:30 <mrmoku> but much nicer thing gdbus
Jan 09 14:42:34 <mrmoku> I like it too
Jan 09 14:42:46 <mickeyl> good. i will add this switch in openmoko_powercontrol then
Jan 09 14:42:48 <mickeyl> now
Jan 09 14:42:52 <mrmoku> great :)
Jan 09 14:45:05 <mrmoku> mickeyl: hmm... disabling openmoko_powercontrol does not help
Jan 09 14:47:05 <mickeyl> why not?`
Jan 09 14:47:07 <mrmoku> it still segfaults the same way
Jan 09 14:47:24 * mrmoku installing fsodeviced-dbg
Jan 09 14:47:33 <mickeyl> install libfsoframework-dbg
Jan 09 14:47:43 <mickeyl> the critical occurs there
Jan 09 14:47:52 <mickeyl> iirc
Jan 09 14:48:19 <mrmoku> got installed as dep of fsodeviced-dbg
Jan 09 14:48:22 <mrmoku> warning: the debug information found in "/usr/sbin/.debug/fsodeviced" does not match "/usr/sbin/fsodeviced" (CRC mismatch).
Jan 09 14:48:27 <mrmoku> is what gdb tells me
Jan 09 14:48:33 * mrmoku tries via gdbserver
Jan 09 14:48:54 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * r33577ddfdeed 10/fsodeviced/src/plugins/openmoko_powercontrol/plugin.vala: 
Jan 09 14:48:55 <CIA-70> freesmartphone.org: fsodeviced: openmoko_powercontrol: introduce three switches for newer kernels:
Jan 09 14:48:55 <CIA-70> freesmartphone.org: [fsodevice.openmoko_powercontrol]
Jan 09 14:48:55 <CIA-70> freesmartphone.org: ignore_wifi = false
Jan 09 14:48:55 <CIA-70> freesmartphone.org: ignore_bluetooth = false
Jan 09 14:48:55 <CIA-70> freesmartphone.org: ignore_usbhost = false
Jan 09 14:50:18 <mrmoku> GNUtoo|laptop: any idea what gdb means with CRC mismatch?
Jan 09 14:52:07 <mrmoku> ahh
Jan 09 14:52:07 <mrmoku> shit
Jan 09 14:52:16 * mrmoku switches opkg to the tests feed :P
Jan 09 14:52:20 <GNUtoo|laptop> yes
Jan 09 14:52:29 <GNUtoo|laptop> .debug doesn't match your binary
Jan 09 14:52:58 <mrmoku> yeah, wrong feed :P
Jan 09 14:54:24 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * rde03e18c249a 10/libfsoframework/fsoframework/subsystem.vala: libfsoframework: subsystem: handle potential errors during object registration
Jan 09 14:55:27 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * rc937f9f3de01 10/libfsoframework/fsoframework/subsystem.vala: libfsoframework: subsystem: more info in error message
Jan 09 14:55:49 <mrmoku> mickeyl: http://shr.pastebin.com/Gs7XmZ8t
Jan 09 14:57:22 <mickeyl> hmm
Jan 09 14:57:49 <mickeyl> trying to load any more plugins that try to register WiFi or BT?
Jan 09 15:01:53 <mrmoku> mickeyl: not that I would know... or is rfkill an input device too?
Jan 09 15:02:15 <mrmoku> 2011-01-09T14:50:57.851486Z [INFO]  Kernel26RfKillPowerControl <0:Bluetooth:softon:hardon>: created.
Jan 09 15:02:17 <mrmoku> 2011-01-09T14:50:57.854364Z [INFO]  Kernel26RfKillPowerControl <1:WiFi:softoff:hardon>: created.
Jan 09 15:02:20 <mrmoku> 2011-01-09T14:50:57.856773Z [INFO]  Kernel26RfKillPowerControl <2:Bluetooth:softon:hardon>: created.
Jan 09 15:02:23 <mrmoku> 2011-01-09T14:50:58.150896Z [INFO]  KernelIdleNotifier </dev/input>: Skipping event4 as instructed by configuration
Jan 09 15:02:26 <mrmoku> 2011-01-09T14:50:58.155384Z [INFO]  KernelIdleNotifier </dev/input>: Skipping event3 as instructed by configuration
Jan 09 15:02:45 <mrmoku> ohh
Jan 09 15:02:52 <mrmoku> mickeyl: rfkill takes bluetooth twice ;)
Jan 09 15:02:59 <mickeyl> d'oh
Jan 09 15:03:15 <mickeyl> wtf
Jan 09 15:03:42 <mrmoku> root@om-gta02 /sys/class/rfkill # cat */name
Jan 09 15:03:42 <mrmoku> gta02-pm-bt
Jan 09 15:03:42 <mrmoku> ar6000
Jan 09 15:03:42 <mrmoku> hci0
Jan 09 15:03:53 <mrmoku> fun :P
Jan 09 15:03:56 <mickeyl> uhm
Jan 09 15:04:53 <mickeyl> i can add an ignore switch, but that looks not correct
Jan 09 15:05:14 <mickeyl> anyways, it should already work
Jan 09 15:05:19 <mickeyl> since i catch this error now
Jan 09 15:05:26 <mickeyl> (update libfsoframework)
Jan 09 15:08:36 <mrmoku> ok
Jan 09 15:09:25 <mrmoku> root@om-gta02 /sys/class/rfkill # modprobe -r btusb
Jan 09 15:09:29 <mrmoku> root@om-gta02 /sys/class/rfkill # ls
Jan 09 15:09:30 <mrmoku> rfkill0  rfkill1
Jan 09 15:10:21 <mickeyl> oh
Jan 09 15:10:34 <mickeyl> spannend
Jan 09 15:11:16 <mrmoku> mickeyl: and, yes. wifi works without openmoko_powercontrol
Jan 09 15:11:44 <mrmoku> mickeyl: btw. what about more than one bt or wifi device?
Jan 09 15:11:50 <mrmoku> that wouldn't work then too
Jan 09 15:12:03 <mickeyl> yes, this is not covered yet
Jan 09 15:12:22 <mrmoku> ok, maybe we can solve that with b) too 
Jan 09 15:12:26 <mickeyl> yes
Jan 09 15:13:13 <GNUtoo|laptop> mickeyl, maybe it acts like that
Jan 09 15:13:30 <GNUtoo|laptop> a new rfkill appear after loading bluetooth
Jan 09 15:13:33 <GNUtoo|laptop> like on htcdream
Jan 09 15:14:23 <mickeyl> yes, but... it's the same bluetooth device
Jan 09 15:14:32 <mickeyl> i think it's an error to have two rfkill devices for the same physical device
Jan 09 15:14:59 <mickeyl> or is btusb controlling a non-existing device?
Jan 09 15:15:08 <mickeyl> i.e. another one connnected via usb?
Jan 09 15:15:25 <mrmoku> no such thing in my case
Jan 09 15:15:45 <mrmoku> if it does not discover my laptops one via usb :P
Jan 09 15:17:16 <mickeyl> hehe
Jan 09 15:25:51 <CIA-70> freesmartphone.org: 03mickey 07specs * rc85607f03aaf 10/ (2 files in 2 dirs): org.freesmartphone.Context.Manager: add INVALID value to check for invalid values (heh)
Jan 09 15:26:20 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * rf24ca13013bf 10/fsotdld/src/plugins/contextmanager/plugin.vala: fsotdld: contextmanager: add parameter check
Jan 09 15:28:30 <mickeyl> bbiab
Jan 09 15:47:42 <mrmoku> mickeyl: is it safe to bump cornucopia rev? And does it need bumping of libfso-glib too? Or should I wait a bit for you to finish context managing?
Jan 09 15:58:33 <mickeyl> mrmoku: context stuff will take a couple of more weeks, rather than hours or days. feel free to bump cornucopia, libfso, and specs
Jan 09 16:03:56 <mrmoku> mickeyl: ok
Jan 09 16:28:03 <mickeyl> morphis: yes, Object.new() does not call named/usual constructors, however it does call the unnamed construct() constructor
Jan 09 16:28:20 <mickeyl> so that can be used for unconditional per-object initializations
Jan 09 16:30:59 <yamitenshi> hi
Jan 09 16:31:38 <yamitenshi> when I have a SIM card present in both SHR-t and SHR-u, enlightenment SEGV's. Are there any logfiles I might look into to see what the problem might be, or any other method I might use to find out?
Jan 09 16:32:26 <yamitenshi> Haven't tries the tests SHR-t and SHR-u yet, by the way
Jan 09 16:32:33 <yamitenshi> s/tries/tried/
Jan 09 16:32:33 <apt> yamitenshi meant: Haven't tried the tests SHR-t and SHR-u yet, by the way
Jan 09 16:33:35 <yamitenshi> Also, the error only occurs after I've entered my SIM pin, or when I disable the SIM pin
Jan 09 16:55:06 <TAsn> this reminds me
Jan 09 16:55:18 <TAsn> mrmoku, what do you guys do about e_dbus?
Jan 09 16:55:32 <TAsn> (as used in e and obviously e's gsm widget)
Jan 09 16:55:39 <TAsn> you guys = guys porting to gdbus :)
Jan 09 17:07:00 <mrmoku> TAsn: we ignore it ;)
Jan 09 17:07:16 <mrmoku> TAsn: why should we care?
Jan 09 17:07:24 <TAsn> gsm gadget...
Jan 09 17:07:32 <TAsn> (and battery?)
Jan 09 17:07:35 <mrmoku> yeah, but it does not use libfso-glib, no?
Jan 09 17:07:42 <mrmoku> so it does not matter
Jan 09 17:07:48 <mrmoku> and in fact all still works :)
Jan 09 17:07:54 <TAsn> really gdbus is dbus compatible?
Jan 09 17:08:00 <TAsn> really?*
Jan 09 17:08:05 <mrmoku> gdbus is not a different server
Jan 09 17:08:15 <TAsn> then?
Jan 09 17:08:16 <mrmoku> hmm
Jan 09 17:08:30 <TAsn> I thought the whole internal design has changed
Jan 09 17:08:40 <mrmoku> gdbus is a different client lib to do dbus apps
Jan 09 17:08:42 <TAsn> i.e messages passed between processes
Jan 09 17:08:51 <TAsn> ok I will just wait and see.
Jan 09 17:08:55 <TAsn> (the benchmarks)
Jan 09 17:09:15 <mrmoku> you mean like 'how many secs to segfault' ?
Jan 09 17:10:05 <mrmoku> TAsn: the API over the bus is still the same... just because we use libfso-glib (which switched to gdbus) we had to adjust stuff
Jan 09 17:10:19 <mrmoku> as callbacks have different signatures... functions different names...
Jan 09 17:10:44 <mrmoku> and as the gsm widget does not use any libfso-glib... no need to do anything
Jan 09 17:10:52 <TAsn> sec I'm in the middle of an anime episode
Jan 09 17:10:58 <TAsn> I will explain what I thought later
Jan 09 17:11:04 <TAsn> but in summary
Jan 09 17:11:09 <TAsn> I thought they changed the protocol
Jan 09 17:11:26 <mrmoku> no
Jan 09 17:12:18 <mickeyl> please don't imagine i'd be _that_ crazy
Jan 09 17:12:26 <mickeyl> proposing we change to something with a different on-the-wire-protocol
Jan 09 17:12:28 <mickeyl> :D
Jan 09 17:12:45 <mickeyl> rendering all existing clients useless
Jan 09 17:12:52 <mickeyl> (and servers)
Jan 09 17:13:04 <yamitenshi> Is there a difference between the shr-testing and shr-testing2011 images?
Jan 09 17:14:02 <yamitenshi> Nvm, testing2011 appears way more recent. Any significant usability issues with that image?
Jan 09 17:14:02 <mrmoku> yamitenshi: yup, shr-testing2011 is the *new* testing candidate I think
Jan 09 17:14:34 <mrmoku> yamitenshi: probably Heinervdm knows what state it is in
Jan 09 17:14:37 * mrmoku did not try it
Jan 09 17:14:57 <yamitenshi> hmm, might try that one then. Anybody know if I need to change anything in config files, like in the tests versions?
Jan 09 17:32:33 <yamitenshi> Here goes nothing...
Jan 09 17:33:30 <Heinervdm> mrmoku: if buildhost is idle we can build an RC2 for testing
Jan 09 17:33:37 <yamitenshi> bbl, dinner
Jan 09 17:33:54 <Heinervdm> yamitenshi: it's the same as tests version
Jan 09 17:34:00 <Heinervdm> that's just a link
Jan 09 17:34:36 <Heinervdm> with the rc2 image i changed the configs
Jan 09 17:35:11 <Heinervdm> but thoses images aren't build 
Jan 09 17:38:47 <Heinervdm> mrmoku: can we change the link from testing2011 to testing2011.1 ? :)
Jan 09 17:51:01 <mrmoku> Heinervdm: sure
Jan 09 17:51:58 <mrmoku> done
Jan 09 17:52:41 <Heinervdm> ok, thx
Jan 09 17:52:47 <mrmoku> yw
Jan 09 17:52:49 <yamitenshi> Bah, enlightenment still crashes after I put in my SIM card >_<
Jan 09 17:53:44 <yamitenshi> Though the phone functions appear to be working, I just received an SMS with the enlightenment crash window still up
Jan 09 17:53:59 <yamitenshi> Is there a way to read SMS messages over SSH?
Jan 09 17:56:21 <PaulFertser> yamitenshi: with what os?
Jan 09 17:56:38 <yamitenshi> PaulFertser: SHR
Jan 09 17:56:55 <yamitenshi> testing, from the testing2011 directory
Jan 09 17:59:01 <ryanjh> Hey, sorry if this is the wrong place to ask for help, but how can I diagnose/fix not receiving incoming SMS on SHR unstable?
Jan 09 17:59:22 <ryanjh> I've googled around but none of the e-mail threads I've found have been all that useful to me.
Jan 09 17:59:52 <Heinervdm> yamitenshi: you can use mdbus2 to read it
Jan 09 18:00:21 <Heinervdm> yamitenshi: and i don't know if you read it, but testing2011 is the same as from tests
Jan 09 18:00:25 <Heinervdm> that's just a link
Jan 09 18:00:43 <Heinervdm> so you have to change the config too, that will change with the next image
Jan 09 18:01:23 <yamitenshi> Ah, okay
Jan 09 18:01:34 <Heinervdm> ryanjh: do you have any logs?
Jan 09 18:02:16 <ryanjh> Which ones would be useful?
Jan 09 18:02:44 <Heinervdm>  /var/log/fsogsmd.log
Jan 09 18:03:07 <Heinervdm> from the time when the sms should have arrived
Jan 09 18:05:04 <ryanjh> Some interesting messages in there but not sure about the time correlation.  I'll send another test message so I can be sure.
Jan 09 18:05:26 <Heinervdm> ok
Jan 09 18:06:12 <PaulFertser> yamitenshi: in shr-utils there's opimd-cli
Jan 09 18:06:30 <Heinervdm> opimd-utils
Jan 09 18:07:38 <yamitenshi> yeah! that worked! :D Thanks :)
Jan 09 18:08:29 <yamitenshi> Also, are there any log files that might be useful in finding out why enlightenment crashes?
Jan 09 18:09:33 <Heinervdm> yamitenshi: it's probably the gsm-gadget that's causing the crash
Jan 09 18:09:50 <Heinervdm> but i don't know where one can find the logs
Jan 09 18:10:18 <Heinervdm> but you can get a backtrace with gdb
Jan 09 18:11:43 <yamitenshi> which process should I attach to?
Jan 09 18:13:11 <Heinervdm>  /usr/bin/enlightenment
Jan 09 18:13:17 <Heinervdm> i think
Jan 09 18:14:24 <yamitenshi> guess I'll need a reboot first
Jan 09 18:15:44 <Heinervdm> would be great if you can get a bt
Jan 09 18:20:28 <yamitenshi> Okay, I've attached to enlightenment upon crash, now what? I'm not that experienced with gdb :P
Jan 09 18:21:28 <yamitenshi> or should I just let it run and press recover on the neo's screen, see what pops up?
Jan 09 18:25:35 <yamitenshi> Okay, not a lot of useful stuff here, just says that the program receives a SIGSEGV in function strlen()
Jan 09 18:25:53 <yamitenshi> And a lot of "thread debugging will not be available" messages
Jan 09 18:30:12 <yamitenshi> guess this is a dead end for now :(
Jan 09 18:31:16 <ryanjh> Heinervdm: Nothing's appeared in that log file since I sent the message ~20 minutes ago.
Jan 09 18:31:43 <ryanjh> There was some funny stuff earlier:
Jan 09 18:31:53 <ryanjh> [WARN]  libfsotransport <0710:3>: Timeout while waiting for an answer to '+CCWA=1,1'
Jan 09 18:32:03 <ryanjh> libfsotransport <0710:3>: SRC: "+CCWA=1,1" -> [ "+CME ERROR: 512" ]
Jan 09 18:32:13 <ryanjh>  libfsotransport <0710:3>: URC: [ "+CME ERROR: 512" ]
Jan 09 18:32:18 <Heinervdm> yamitenshi: type bt after the SIGSEGV
Jan 09 18:32:30 <ryanjh> [WARN]  TiCalypsoModem <4C>: No handler for URC +CME ERROR w/ rhs 512, please report to Mickey <smartphones-userland@linuxtogo.org>
Jan 09 18:32:33 <yamitenshi> ah, will do
Jan 09 18:32:37 <ryanjh> Is that likely to be related?
Jan 09 18:33:04 <Heinervdm> ryanjh: i don't think
Jan 09 18:33:30 <Heinervdm> it looks like nothing arrives at the phone
Jan 09 18:35:07 <ryanjh> My signal is otherwise fine; I can send and receive calls.
Jan 09 18:36:06 <ryanjh> Is there something else I can try?
Jan 09 18:36:47 <Heinervdm> we can ask mickeyl if he has an idea
Jan 09 18:36:56 <mickeyl> ryanjh: can you give me the full libfsotransport log, i.e. starting with the process start? 512 is the killer bug, i wonder whether we call COLP=0 before
Jan 09 18:37:25 <mickeyl> fwiw, it's http://docs.openmoko.org/trac/ticket/1192
Jan 09 18:39:16 <ryanjh> I'd be happy to.  Where is it?  :-)
Jan 09 18:39:26 <yamitenshi> I'm gonna paste all of the output from GDB to pastebin, personally I can't make anything out of it, maybe one of you guys can?
Jan 09 18:39:49 <mickeyl> i don't know
Jan 09 18:39:53 <mickeyl> check the fsogsmd.conf
Jan 09 18:39:56 <mickeyl> it's written there
Jan 09 18:40:05 <mickeyl> log_*
Jan 09 18:41:01 <ryanjh> Ah, okay.  Looks like it's /var/log/fsogsmd.log still, unless I'm misreading this.
Jan 09 18:41:24 <yamitenshi> output is at http://pastebin.com/WwgVdf1B
Jan 09 18:42:16 <Heinervdm> yamitenshi: yes it's the gsm gadget
Jan 09 18:42:29 <Heinervdm> yamitenshi: can you install e-wm-dbg ?
Jan 09 18:42:38 <Heinervdm> but do it with -nodeps
Jan 09 18:42:57 <Heinervdm> else you have to install 500MB 
Jan 09 18:43:02 <yamitenshi> I needed to change something in the config files to install packages, right?
Jan 09 18:43:36 <ryanjh> mickeyl: Here it is: http://pastebin.com/nrFv51ra
Jan 09 18:43:37 <Heinervdm> yamitenshi: yes in /etc/opkg/*.conf
Jan 09 18:43:50 <Heinervdm> yamitenshi: replace http://build.shr-project.org/shr-testing/ipk/ by http://build.shr-project.org/tests/shr-testing/ipk/
Jan 09 18:44:08 <ryanjh> I have to run for a few hours, but I'll stay logged in; thanks for your help!
Jan 09 18:44:30 <yamitenshi> okay, will do
Jan 09 18:44:34 <mickeyl> ryanjh: thanks, got it
Jan 09 18:46:34 <Heinervdm> mickeyl:  perhaps he haven't updated the GSM firmware?
Jan 09 18:46:48 <mickeyl> possible
Jan 09 18:46:49 <Heinervdm> s/have/has
Jan 09 18:47:17 <Heinervdm> ryanjh: did you update the GSM Firmware?
Jan 09 18:47:50 <Heinervdm> ryanjh: http://wiki.openmoko.org/wiki/GSM/Flashing#.C2.B5SD-card_Image_.28GTA02_only.29
Jan 09 18:52:14 <yamitenshi> Heinervdm: okay, I installed e-wm-dbg, now I just try again?
Jan 09 18:52:36 <Heinervdm> yamitenshi: yes, now you should get a more detailed backtrace
Jan 09 18:52:48 <Heinervdm> with line numbers :)
Jan 09 18:52:53 <Heinervdm> wait
Jan 09 18:53:08 <Heinervdm> i think that was the wrong package :)
Jan 09 18:53:39 <Heinervdm> yamitenshi: install shr-e-gadgets-dbg too
Jan 09 18:53:48 <yamitenshi> okay, will do :P
Jan 09 18:53:58 <yamitenshi> with nodeps again?
Jan 09 18:54:03 <Heinervdm> yes
Jan 09 18:56:13 <yamitenshi> will I have to reboot for it to work, or can I just attach to enlightenment?
Jan 09 18:56:35 <Heinervdm> just attach
Jan 09 18:58:02 <yamitenshi> hmm, doesn't seem to be much more detailed...
Jan 09 18:58:43 <yamitenshi> just a few more lines, but they might be useful :)
Jan 09 18:59:28 <yamitenshi> New one at http://pastebin.com/8LQVeThs
Jan 09 19:00:26 <Heinervdm> TAsn: shr-e-gadgets is from you, isn't it?
Jan 09 19:00:36 <TAsn> it is.
Jan 09 19:00:41 <TAsn> what did I do wrong? :P
Jan 09 19:01:08 <TAsn> p.s gsm gadget isn't tasn-related
Jan 09 19:01:20 <yamitenshi> lol
Jan 09 19:01:34 <TAsn> if you are having trouble with that gadget
Jan 09 19:01:37 <TAsn> you probably want
Jan 09 19:01:43 <TAsn> e-modules-extra-dbg
Jan 09 19:01:46 <TAsn> or something like that
Jan 09 19:01:50 <TAsn> or actually
Jan 09 19:01:53 <TAsn> nvm
Jan 09 19:01:55 <TAsn> gsm gadget
Jan 09 19:01:57 <TAsn> is in my package
Jan 09 19:02:01 <TAsn> Heinervdm is right.
Jan 09 19:02:20 <Heinervdm> :)
Jan 09 19:02:52 <TAsn> yep, bt, gsm, usb and wifi are all in my package
Jan 09 19:03:00 <TAsn> I took them all from illume
Jan 09 19:03:07 <TAsn> but I don't remember handling the license correctly
Jan 09 19:03:17 <TAsn> Oh, it's bsd at origin, nvm :)
Jan 09 19:04:04 <TAsn> and I arbitrarily made it gpl (cause I just packed e-related stuff in that package and put them all in the same license) :P
Jan 09 19:04:07 <Heinervdm> http://git.shr-project.org/git/?p=shr-e-gadgets.git;a=blob;f=src/shelf-gadgets/e_mod_gad_gsm.c#l943
Jan 09 19:04:37 <TAsn> just to make sure you guys know
Jan 09 19:04:39 <GNUtoo|laptop> hmmm, how do I recharge the n900 if fsodeviced fails? maybe I'll try the shadowjk script
Jan 09 19:04:40 <Heinervdm> yamitenshi: what's the name of your operator, so what does other phones show as operator name
Jan 09 19:04:41 <TAsn> I didn't write those gadgets
Jan 09 19:04:46 <TAsn> just adapted them
Jan 09 19:04:58 <Heinervdm> TAsn: but you can help finding the bug ;)
Jan 09 19:05:03 <TAsn> I can.
Jan 09 19:05:04 <TAsn> :)
Jan 09 19:05:10 <TAsn> but I need debug signals
Jan 09 19:05:16 <TAsn> *symbols
Jan 09 19:05:18 <TAsn> and a bt
Jan 09 19:05:19 <yamitenshi> Heinervdm: KPN, Hi or Hi KPN depending on the phone, IIRC
Jan 09 19:05:20 <Heinervdm> http://pastebin.com/8LQVeThs
Jan 09 19:05:53 <Heinervdm> yamitenshi: ok, i hoped it would be something strange :)
Jan 09 19:05:54 <TAsn> ok
Jan 09 19:05:59 <TAsn> either the name is not NULL terminated
Jan 09 19:06:13 <TAsn> or it's NULL and no one did any checks for it anywhere down the line
Jan 09 19:06:18 <TAsn> as Heinervdm suggested
Jan 09 19:06:22 <TAsn> a printf just there
Jan 09 19:06:25 <TAsn> will do wonders :P
Jan 09 19:06:42 <yamitenshi> any variables I can check in gdb? I still have it attached :P
Jan 09 19:06:51 <TAsn> yamitenshi, yes
Jan 09 19:06:54 <TAsn> go up
Jan 09 19:07:00 <TAsn> until that function of e-gadgets
Jan 09 19:07:02 <TAsn> and print the string
Jan 09 19:07:17 <yamitenshi> wait, up? do I just type up? :P
Jan 09 19:07:21 <TAsn> yes
Jan 09 19:07:24 <TAsn> but you need debug symbols
Jan 09 19:07:33 <TAsn> write up
Jan 09 19:07:36 <TAsn> until you get to level 4
Jan 09 19:07:45 <TAsn> and then print
Jan 09 19:07:56 <yamitenshi> level 4, setLabel?
Jan 09 19:08:06 <TAsn> yes
Jan 09 19:08:07 <TAsn> and print 
Jan 09 19:08:08 <TAsn> label
Jan 09 19:08:11 <yamitenshi> okay
Jan 09 19:08:43 <yamitenshi> no symbol "label" in current context
Jan 09 19:08:53 <yamitenshi> :\
Jan 09 19:08:53 <TAsn> did you install debug symbols?
Jan 09 19:09:07 <TAsn> nvm
Jan 09 19:09:09 <TAsn> looking at the bt
Jan 09 19:09:11 <TAsn> you didn't
Jan 09 19:09:15 <yamitenshi> I installed e-wm-dbg and e-shr-gadgets-dbg
Jan 09 19:09:24 <TAsn> and did you restart gdb?
Jan 09 19:09:49 <yamitenshi> I started it after I installed them both
Jan 09 19:09:59 <yamitenshi> I can try again though
Jan 09 19:10:27 <TAsn> hm.. maybe you need to restart e as well? honestly, I have no idea how the out-of-the-file debug symbols work
Jan 09 19:10:46 <yamitenshi> I'll try
Jan 09 19:11:28 * Heinervdm konws only bt of gdb
Jan 09 19:11:53 <yamitenshi> okay, I'll need to restart my phone completely for that, enlightenment doesn't respond anymore to presses on the screen
Jan 09 19:12:08 <TAsn> yamitenshi, waaiiittt
Jan 09 19:12:16 <TAsn> it's because you attached gdb
Jan 09 19:12:22 <TAsn> quit gdb
Jan 09 19:12:22 <yamitenshi> no, it was detached
Jan 09 19:12:38 <TAsn> you can just restart e
Jan 09 19:12:42 <TAsn> but if you want, restart your phone
Jan 09 19:13:00 <yamitenshi> well, luckily SHR boots fairly fast :P
Jan 09 19:13:35 <yamitenshi> so, I'll attach gdb before I enter my pin and just type continue, is that okay?
Jan 09 19:14:01 <yamitenshi> it allowed me to enter my pin before, but I don't know if that'll give the correct bt
Jan 09 19:14:16 <TAsn> that's ok.
Jan 09 19:14:18 * yamitenshi feels like a complete newbie at geek stuff :P
Jan 09 19:14:19 <TAsn> just attach
Jan 09 19:14:19 <GNUtoo|laptop> ah seem to work with old rootfs
Jan 09 19:14:21 <TAsn> and press continue
Jan 09 19:14:32 <TAsn> *write "continue"
Jan 09 19:14:33 <TAsn> in gdb.
Jan 09 19:14:55 <GNUtoo|laptop> somebody needs gdb tutorial?
Jan 09 19:15:06 <GNUtoo|laptop> like gdbserver+gdb-cross?
Jan 09 19:15:38 <TAsn> I'm fine with it. but it is lacking
Jan 09 19:15:41 <TAsn> *the topic
Jan 09 19:15:52 <TAsn> I mean no decent docs about it
Jan 09 19:16:02 <GNUtoo|laptop>  I wrote one
Jan 09 19:16:09 <GNUtoo|laptop> at elinux.org
Jan 09 19:16:12 <TAsn> nice.
Jan 09 19:16:14 <GNUtoo|laptop> or rather improved one
Jan 09 19:16:22 <TAsn> now you need to promote it at google
Jan 09 19:16:31 <TAsn> because I know a colleague of mine searched a lot
Jan 09 19:16:32 <yamitenshi> okay, I got the SIGSEGV, I'll update the bt on pastebin
Jan 09 19:16:43 <TAsn> yamitenshi, I don't care about the bt :P
Jan 09 19:16:45 <TAsn> just the print
Jan 09 19:16:46 <TAsn> over there
Jan 09 19:16:56 <TAsn> GNUtoo|laptop, and failed finding a decent one
Jan 09 19:17:03 <TAsn> GNUtoo|laptop, forcing me to explain how.
Jan 09 19:17:05 <yamitenshi> okay, up until I get to setLabel and print label, right?
Jan 09 19:17:10 <TAsn> yep.s
Jan 09 19:17:25 <GNUtoo|laptop> I'm pushing source code so the net is slow
Jan 09 19:17:38 <GNUtoo|laptop> look in toolsbox in elinux.org
Jan 09 19:17:39 <yamitenshi> hmm, I guess I don't have the debug symbols, I get the same output
Jan 09 19:17:53 <yamitenshi> No symbol "label" in current context
Jan 09 19:18:25 <TAsn> please write
Jan 09 19:18:33 <TAsn> info share<TAB>
Jan 09 19:18:38 <GNUtoo|laptop> http://www.elinux.org/GDB
Jan 09 19:18:43 <TAsn> where TAB is a tab (I don't remember the exact name)
Jan 09 19:18:50 <yamitenshi> info sharedlibrary
Jan 09 19:18:53 <TAsn> and tell me if there's a * near
Jan 09 19:18:57 <TAsn> shr-e-gadgets
Jan 09 19:19:11 <TAsn> GNUtoo|laptop, cool, will pass it around at work.
Jan 09 19:19:12 <TAsn> thanks.
Jan 09 19:20:37 <yamitenshi> I don't see a shr-e-gadgets anywhere :\
Jan 09 19:20:47 <yamitenshi> Could be I just need new glasses though
Jan 09 19:21:39 <TAsn> no idea :|
Jan 09 19:22:32 <GNUtoo|laptop> also feel free to improve it
Jan 09 19:22:53 <TAsn> GNUtoo|laptop, do I have access?
Jan 09 19:23:11 <GNUtoo|laptop> just create an account on that wiki then
Jan 09 19:23:48 <TAsn> when I'll have things to change :P
Jan 09 19:24:04 <GNUtoo|laptop> ok
Jan 09 19:25:27 <yamitenshi> How should I have installed the debugging symbols?
Jan 09 19:27:49 <yamitenshi> Oh hey, found it, I guess
Jan 09 19:27:59 <yamitenshi> /usr/lib/enlightenment/modules/shr-e-gadgets/linux-gnueabi-arm-ver-pre-svn-08/module.so
Jan 09 19:28:04 <yamitenshi> could that be right?
Jan 09 19:28:40 <Heinervdm> that's the library
Jan 09 19:28:54 <yamitenshi> it has a * in front of it, by the way :P
Jan 09 19:29:07 <yamitenshi> so I guess that means I'm still missing some debugging info
Jan 09 19:29:16 <Heinervdm> TAsn: there is a * for the gadets
Jan 09 19:29:32 <TAsn> yep.
Jan 09 19:29:37 <TAsn> that's what this means
Jan 09 19:30:12 <yamitenshi> maybe I should leave out the --nodeps?
Jan 09 19:30:40 <TAsn> doesn't matter
Jan 09 19:31:01 <TAsn> and I gtg, sorry. :(
Jan 09 19:31:13 <Heinervdm> the debug symbols are in a different directory, perhaps one have to specify that somewhere
Jan 09 19:31:15 <TAsn> but once you get to print "label"
Jan 09 19:31:27 <TAsn> everything will be better. :P
Jan 09 19:31:44 <yamitenshi> lol :P
Jan 09 19:31:53 <mrmoku> TAsn: what should the label contain?
Jan 09 19:32:05 <yamitenshi> Heinervdm: does the "file" command have anything to do with it?
Jan 09 19:32:08 <TAsn> hopefully garbage
Jan 09 19:32:19 <TAsn> which means the bug isn't tasn-related
Jan 09 19:32:24 <yamitenshi> lol :P
Jan 09 19:32:38 <TAsn> but finding out if it's a null or garbage
Jan 09 19:32:42 <TAsn> will help us find the source
Jan 09 19:32:48 <TAsn> and the source will yield the answers.
Jan 09 19:32:55 <GNUtoo|laptop> usually debug symbols are installed using the -dbg package
Jan 09 19:32:57 <Heinervdm> yamitenshi: i have nearly zero knowledge about gdb ;)
Jan 09 19:32:58 <yamitenshi> wait, does it have to be print label or print "label"?
Jan 09 19:33:01 <GNUtoo|laptop> if it doesn't exist
Jan 09 19:33:13 <TAsn> yamitenshi, without "
Jan 09 19:33:21 <yamitenshi> okay, so I did do it right :P
Jan 09 19:33:26 <GNUtoo|laptop> it means that the recipe making the package has splitted the install output
Jan 09 19:33:34 <yamitenshi> print "label" just gave me $1 = "label" :P
Jan 09 19:33:36 <Heinervdm> GNUtoo|laptop: he installed the -gdb and i checked the package, it in there
Jan 09 19:33:36 <GNUtoo|laptop> and that the -dbg are in the main package's -dbg version
Jan 09 19:33:52 <yamitenshi> yeah, it's in there and installes
Jan 09 19:34:00 <yamitenshi> s/installes/installed/
Jan 09 19:34:00 <apt> yamitenshi meant: yeah, it's in there and installed
Jan 09 19:35:37 <GNUtoo|laptop> lol -gdb
Jan 09 19:35:45 <GNUtoo|laptop> nice typo
Jan 09 19:35:53 <Heinervdm> :)
Jan 09 19:36:09 <GNUtoo|laptop> he debug on target with gdb on target?
Jan 09 19:36:11 <mrmoku> yamitenshi: did you check /var/log/Xsession.log ?
Jan 09 19:36:16 <GNUtoo|laptop> or does he use gdbserver+gdb-cross?
Jan 09 19:36:29 <yamitenshi> hmm, good idea
Jan 09 19:36:45 <mrmoku> check if it contains
Jan 09 19:36:46 <mrmoku> E_MOD_GAD_GSM_DEBUG_PRINTF("updateStatus registered = TRUE"); 
Jan 09 19:37:01 <GNUtoo|laptop> gdbserver+gdbcross are usually used when the program is big
Jan 09 19:37:05 <mrmoku> and E_MOD_GAD_GSM_DEBUG_PRINTF("updateStatus finished"); after that
Jan 09 19:37:14 <GNUtoo|laptop> -dbg symbols are charged in memory
Jan 09 19:37:14 <mrmoku> my guess would be it does not have the second one
Jan 09 19:37:19 <GNUtoo|laptop> which makes the phone OOM
Jan 09 19:37:22 <GNUtoo|laptop> if the program is big
Jan 09 19:38:05 <yamitenshi> yeah, it does have updateStatus registered=TRUE, but not updateStatus finished after that
Jan 09 19:39:16 <TAsn> back for a mmnt
Jan 09 19:39:28 <TAsn> mrmoku, he already spotted the problem
Jan 09 19:39:31 <TAsn> he attached gdb
Jan 09 19:39:34 <TAsn> and found the point where it segs
Jan 09 19:39:44 <TAsn> and found the malformed string as well
Jan 09 19:39:51 <TAsn> we just don't know how it's malformed
Jan 09 19:39:54 <TAsn> (null or garbage)
Jan 09 19:39:59 <TAsn> and where the suckiness started at.
Jan 09 19:40:04 <TAsn> now for real, gtg.
Jan 09 19:40:26 <Heinervdm> i will build a package with a printf :)
Jan 09 19:41:00 <mrmoku> TAsn: yeah, and I'm looking at the code to find out ;)
Jan 09 19:41:40 <yamitenshi> well, I guess I'll do what I can to help resolve the problem :) In the meantime, I'll have to stick to QtMoko...
Jan 09 19:42:00 <Heinervdm> yamitenshi: we will find the bug today ;)
Jan 09 19:42:33 <yamitenshi> Heinervdm: do I get a beer if you don't? ;)
Jan 09 19:42:46 <mrmoku> no, but we get one if we do ;)
Jan 09 19:42:51 <Heinervdm> :)
Jan 09 19:43:40 <yamitenshi> lol, I'm half-inclined to actually ship a glass of beer halfway across the world :P
Jan 09 19:43:53 <yamitenshi> unless it's not halfway across the world of course :P
Jan 09 19:44:38 <Heinervdm> yamitenshi: http://heinervdm.dyndns.info/shr/armv4t/shr-e-gadgets_0.0.0+gitr0+ce3de686930676b54e182190216d66930ddc0cb4-r10.6_armv4t.ipk http://heinervdm.dyndns.info/shr/armv4t/shr-e-gadgets-dbg_0.0.0+gitr0+ce3de686930676b54e182190216d66930ddc0cb4-r10.6_armv4t.ipk
Jan 09 19:45:08 <Heinervdm> the version is probably incorrect, so you have to  remove the package first
Jan 09 19:45:18 <mrmoku> yamitenshi: could you do the following too please:
Jan 09 19:45:25 * pespin fighting against gdb and emtooth2 too
Jan 09 19:45:41 <mrmoku> mdbus2 -s org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Network.GetStatus
Jan 09 19:45:48 <yamitenshi> Heinervdm: okay, just remove shr-e-gadgets and shr-e-gadgets-dbg and install those?
Jan 09 19:45:55 <mrmoku> and pastebin the result
Jan 09 19:45:57 <Heinervdm> yamitenshi: wait that wont work
Jan 09 19:45:59 <pespin> I've installed emtooth2-dbg but when I run "bt" I don't get useful info I think
Jan 09 19:46:02 <GNUtoo|laptop> pespin, hi
Jan 09 19:46:08 <pespin> GNUtoo|laptop, hi :)
Jan 09 19:46:10 <Heinervdm> yamitenshi: i will build one with a bigger version
Jan 09 19:46:19 <GNUtoo|laptop> pespin, I'll do some oe work
Jan 09 19:46:27 <GNUtoo|laptop> I don't push emtooth2 yet right?
Jan 09 19:46:43 <pespin> GNUtoo|laptop, I think audio/input UI should work now with last rev. I'll recheck the cod elater, as I did yesterday and was late.
Jan 09 19:47:02 <Heinervdm> yamitenshi: http://heinervdm.dyndns.info/shr/armv4t/shr-e-gadgets_0.0.1+gitr0+ce3de686930676b54e182190216d66930ddc0cb4-r10.6_armv4t.ipk http://heinervdm.dyndns.info/shr/armv4t/shr-e-gadgets-dbg_0.0.1+gitr0+ce3de686930676b54e182190216d66930ddc0cb4-r10.6_armv4t.ipk
Jan 09 19:47:02 <GNUtoo|laptop> do you want me to wait for pushing your recipe?
Jan 09 19:47:13 <Heinervdm> yamitenshi: just install those
Jan 09 19:48:10 <pespin> GNUtoo|laptop, yep, I'll try to debug it this evening :)
Jan 09 19:48:25 <GNUtoo|laptop> ok 
Jan 09 19:48:29 <pespin> so better wait a bit
Jan 09 19:48:29 <pespin> GNUtoo|laptop, I get this -> http://paste.pocoo.org/show/317825/
Jan 09 19:48:54 <Heinervdm> yamitenshi: with that version you'll get "setLabel() label=..." in XSession.log
Jan 09 19:49:11 <Heinervdm> and ... is the interesting part
Jan 09 19:50:31 <pespin> GNUtoo|laptop, I'm afraid that can be some glib2 error, as I don't get that segfault on computer
Jan 09 19:50:45 <yamitenshi> mrmoku: ({"provider": "","strength": 70,"display": "","lac": "1186","mode": "automatic","code": "20408","cid": "3045","pdp.cid": "","pdp.lac": "","pdp.registration": "unregistered","network": "","registration": "home","act": "GSM"}
Jan 09 19:51:22 <mrmoku> yamitenshi: yeah, as suspected... provider and network are empty
Jan 09 19:51:22 <GNUtoo|laptop> pespin, ok look with gdbserver+gdb
Jan 09 19:51:36 <mrmoku> mickeyl: means his provider is missing in the db ?
Jan 09 19:51:39 <GNUtoo|laptop> pespin, do you have a clean rootfs?
Jan 09 19:52:16 <Heinervdm> mrmoku: but the gadget shouldn't segfault in that case :)
Jan 09 19:52:18 <pespin> GNUtoo|laptop, nop. I use this rootfs as daily phone.
Jan 09 19:52:27 <Heinervdm> so we should add a NULL check
Jan 09 19:52:31 <yamitenshi> Heinervdm: do I have to remove the old shr-e-gadgets and -dbg first?
Jan 09 19:52:32 <TAsn> Heinervdm, aye.
Jan 09 19:52:35 <pespin> same reason why I don't want to upgrade till packages in feeds works properly
Jan 09 19:52:47 <TAsn> yamitenshi, wait, issue found.
Jan 09 19:52:48 <mrmoku> Heinervdm: sure it should not :P
Jan 09 19:52:55 <TAsn> if NULL return
Jan 09 19:52:56 <pespin> I think I'll stop debugging till I can upgrade
Jan 09 19:52:57 <TAsn> should solve it.
Jan 09 19:52:57 <Heinervdm> yamitenshi: opkg should update the packages
Jan 09 19:53:01 <GNUtoo|laptop> pespin, because with the gdbus migration things could have gone wrong
Jan 09 19:53:18 <GNUtoo|laptop> get a new microsd card and try a clean rootfs...if you can, else gdb it
Jan 09 19:53:42 <mrmoku> JaMa: btw. I understood the hard way what you meant by bitbake disliking branch switching :P
Jan 09 19:54:08 <Heinervdm> TAsn, mrmoku: will one of you commit a patch for shr-e-gadgets?
Jan 09 19:54:20 <pespin> GNUtoo|laptop, uhm but gdb is not geaving useful info here. and I have emtooth-dbg installed.
Jan 09 19:54:29 * TAsn is on it.
Jan 09 19:54:40 <GNUtoo|laptop> pespin, ok I'll look soon
Jan 09 19:54:47 <Heinervdm> TAsn: great
Jan 09 19:54:52 <GNUtoo|laptop> pespin, how do you run GDB?
Jan 09 19:54:57 <GNUtoo|laptop> pastebin the whole stuff
Jan 09 19:55:00 <GNUtoo|laptop> try set sysroot /
Jan 09 19:55:14 <pespin> GNUtoo|laptop, I'm not using gdbserver. I'm just using gdb in the phone :P
Jan 09 19:55:33 <pespin> I don't know how all that gdbserver stuff works ;)
Jan 09 19:56:14 <pespin> GNUtoo|laptop, http://paste.pocoo.org/show/317829/
Jan 09 19:57:20 <GNUtoo|laptop> you seem to miss a lot of symbols
Jan 09 19:57:46 <TAsn> Heinervdm, there, I think.
Jan 09 19:57:50 <GNUtoo|laptop> also gdbserver+gdb (howto available here: http://www.elinux.org/GDB ) is the only way to debug big programs that fails on your phone
Jan 09 19:57:51 <Heinervdm> TAsn: thx
Jan 09 19:58:00 <GNUtoo|laptop> else the normal GDB result in OOM
Jan 09 19:58:06 <Heinervdm> TAsn: will push updated SRCREV to oe
Jan 09 19:58:16 <pespin> GNUtoo|laptop, do I need all the dbg symbols of all libs?
Jan 09 19:58:17 <TAsn> great. :)
Jan 09 19:58:20 <GNUtoo|laptop> and your computer doesn't always catch up all phone segfaults
Jan 09 19:58:27 <GNUtoo|laptop> that would be better
Jan 09 19:58:46 <GNUtoo|laptop> /lib/libc.so.6: No such file or directory.
Jan 09 19:58:51 <GNUtoo|laptop> you miss critical debug stuff
Jan 09 19:58:56 <GNUtoo|laptop> try setting sysroot as /
Jan 09 20:00:01 <pespin> GNUtoo|laptop, uhm what's that sysroot thing and how do I do it?
Jan 09 20:00:49 <GNUtoo|laptop> set sysroot /
Jan 09 20:00:53 <GNUtoo|laptop> there was an issue with it before
Jan 09 20:00:59 <GNUtoo|laptop> as I don't know if it's fixed
Jan 09 20:01:02 <GNUtoo|laptop> better doing that
Jan 09 20:01:47 <pespin> before using "run" ?
Jan 09 20:02:31 <pespin> yeah now I get more info
Jan 09 20:02:50 <mrmoku> interesting
Jan 09 20:03:02 <pespin> #0  0x40146f5e in ?? () from /usr/lib/libglib-2.0.so.0
Jan 09 20:03:02 <pespin> #1  0x401449d6 in ?? () from /usr/lib/libglib-2.0.so.0
Jan 09 20:03:02 <pespin> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Jan 09 20:03:07 <mrmoku> that probably explains why I always fail to get good bts on the phone
Jan 09 20:03:16 <pespin> :P
Jan 09 20:04:04 <pespin> I'll try upgrading liblgib2 from feeds, hope I don't break anything ;)
Jan 09 20:04:40 <GNUtoo|laptop> pespin, yes before using run
Jan 09 20:05:05 <Heinervdm> mrmoku: can trigger a build for shr-t?
Jan 09 20:05:35 <mrmoku> Heinervdm: with update before?
Jan 09 20:05:47 <Heinervdm> mrmoku: yes, just pushed the fix
Jan 09 20:06:08 <CIA-70> freesmartphone.org: 03morphis 07next * rdef30972e7ce 10msmcomm/msmcommd/src/stateservice.vala: msmcommd: fix misc unsolicited response handling
Jan 09 20:06:14 <CIA-70> freesmartphone.org: 03morphis 07next * rab462612e022 10msmcomm/ (msmcomm-specs/src/state.vala msmcommd/src/stateservice.vala): msmcommd: add next unsolicited response message for state subsystem
Jan 09 20:06:16 <CIA-70> freesmartphone.org: 03morphis 07next * rc3bc16303dfb 10msmcomm/ (18 files in 7 dirs): msmcomm: implement sim service with only verify-pin command currently working
Jan 09 20:06:37 <pespin> same problem with updted glib
Jan 09 20:06:58 <pespin> I'll try installing glib2-dbg
Jan 09 20:08:26 <GNUtoo|laptop> mrmoku, what do you think of what I said in #oe
Jan 09 20:08:28 <GNUtoo|laptop> ?
Jan 09 20:08:32 <GNUtoo|laptop> I push or not?
Jan 09 20:10:56 <pespin> got the info! :) http://paste.pocoo.org/show/317835/
Jan 09 20:13:04 <mrmoku> GNUtoo|laptop: DP=-1 for all but SHR sounds good
Jan 09 20:13:14 <GNUtoo|laptop> ok
Jan 09 20:14:53 <mrmoku> Heinervdm: building
Jan 09 20:16:35 <Heinervdm> mrmoku: feed + images, or just the gadget?
Jan 09 20:16:45 <mrmoku> images and no feed
Jan 09 20:16:58 <mrmoku> + index
Jan 09 20:17:12 <Heinervdm> ok, i haven't updated feed packages
Jan 09 20:17:17 <Heinervdm> so it shouldn't matter
Jan 09 20:17:23 <mrmoku> yup
Jan 09 20:17:41 <Heinervdm> yamitenshi: in 1h or so you can try to opkg upgrade
Jan 09 20:17:53 <yamitenshi> yay :D
Jan 09 20:18:03 <pespin> LOL. it was some bluez bug. I upgraded to feed's version and emtooth2 doesn't segfault now
Jan 09 20:18:56 <pespin> it was probably sending some garbage as bool which glib2 didn't like
Jan 09 20:21:01 <pespin> GNUtoo|laptop, I'll go find my bt kb and do some tries to see if it's working now :)
Jan 09 20:22:47 <GNUtoo|laptop> ok
Jan 09 20:47:02 <GNUtoo|laptop> ahh maybe it need bq2x00 to charge
Jan 09 20:47:13 <GNUtoo|laptop> maybe it exits or something like that if that's absent
Jan 09 21:04:00 <Heinervdm> buildhost needs really long for just rebuilding vala and fso :)
Jan 09 21:05:19 <mrmoku> Heinervdm: qemu-native rebuilt too
Jan 09 21:05:32 <Heinervdm> oh
Jan 09 21:05:34 <Heinervdm> ok
Jan 09 21:07:03 <mrmoku> and now mesa-dri
Jan 09 21:08:21 <Heinervdm> hmm, there were some more pending patches in the queue :)
Jan 09 21:08:30 <mrmoku> looks like :P
Jan 09 21:09:04 <Heinervdm> will go to sleep now, holidays are over. so i have to get up early tomorow :)
Jan 09 21:12:30 <pespin> GNUtoo|laptop, bt Input is working at rev 119 :)
Jan 09 21:12:42 <pespin> try it if you want ^^
Jan 09 21:17:36 <yamitenshi> Any use trying to opkg upgrade yet? :P Or should I try later/tomorrow?
Jan 09 21:18:21 <GNUtoo|laptop> pespin, nice, I'll try later
Jan 09 21:18:42 <CIA-70> freesmartphone.org: 03morphis 07next * r00030c80af77 10msmcomm/ (8 files in 5 dirs): msmcomm: add some more sim relevant messages
Jan 09 21:25:52 <mrmoku> yamitenshi: not yet
Jan 09 21:25:55 <mrmoku> it's still building
Jan 09 21:26:01 <yamitenshi> okay :)
Jan 09 21:36:29 <CIA-70> SHR: 03mok 07libphone-ui-shr * rd45d5242a734 10/src/view/idle-view.c: idle-view: set keyboard mode to off
Jan 09 21:39:33 * pespin loves when bluetoothd suddenly crashes
Jan 09 21:40:37 <yamitenshi> Ahhh, sudden crashes... Gotta love 'em. Remind me of the good ol' days when I still used windows regularly :P
Jan 09 21:43:05 <pespin>  I should debug bluetoothd and emtooth2 at the same time I think hehe
Jan 09 21:56:02 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * r572861ad8309 10/fsotdld/ (3 files in 2 dirs): fsotdld: add gio-hacks.vapi for our special needs
Jan 09 21:57:55 <yamitenshi> be back in a bit, just gonna move my laptop
Jan 09 22:15:28 <mrmoku> if yamitenshi comes back... somebody tell him that the build finished please :)
Jan 09 22:15:31 * mrmoku off to bed
Jan 09 22:15:36 <mrmoku> good night all
Jan 09 22:33:12 <mickeyl> g'night mrmoku 
Jan 09 22:52:11 <yamitenshi> I noticed that in the tests SHR-t the package containing the opkg conf files has been updated. Should I apply the changes (basically just removing the tests part from the files) or should I keep them the way they were (manually edited to contain the tests directory)?
Jan 09 23:05:47 <CIA-70> freesmartphone.org: 03mickey 07specs * r822b2dd82018 10/ (3 files in 3 dirs): org.freesmartphone.Context.Manager: add 100KM as possible accuracy granularity
Jan 09 23:06:14 <CIA-70> freesmartphone.org: 03mickey 07gdbus * rfb1c5bc750a6 10libfso-glib/configure.ac: bump
Jan 09 23:27:54 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * r1ac963b198fe 10/fsotdld/ (7 files in 6 dirs): fsotdld: more work on contextmanager location updates
Jan 09 23:30:00 <yamitenshi> gtg, bye
Jan 09 23:35:28 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * r78aa68f84579 10/libfsobasics/fsobasics/utilities.vala: libfsobasics: simplify string <-> uint8[] conversion
Jan 09 23:43:55 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * r8b1e71c1da1d 10/fsotdld/src/plugins/provider_location_freegeoip/plugin.vala: fsotdld: repair provider_location_freegeoip
Jan 09 23:47:25 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * rcc21d859d955 10/fsotdld/src/plugins/provider_location_freegeoip/plugin.vala: fsotdld: provider_location_freegeoip: deliver accuracy, if we have a lat/lon pair
Jan 10 00:05:24 <CIA-70> freesmartphone.org: 03mickey 07cornucopia * ra8fb9d57d9e8 10/fsotdld/src/plugins/contextmanager/plugin.vala: fsotdld: contextmanager/location: first version working
Jan 10 01:51:01 <GNUtoo|laptop> mrmoku, hi
Jan 10 01:51:11 <GNUtoo|laptop> mrmoku, does your dvfs tree really has dvfs?
Jan 10 01:51:16 <GNUtoo|laptop> I see no dvfs patch
Jan 10 01:51:38 <GNUtoo|laptop> nokia900/dvfs-meego-wip seem to have dvfs tough
Jan 10 01:57:28 <ryanjh> mickeyl/Heinervdm: (from seven hours ago) No, I'm pretty sure I haven't upgraded the GSM firmware!  I'll try that out.
Jan 10 02:40:42 <pespin> GNUtoo|laptop, I have a misterious bug in emtooth code of hashtable.get_values() messing the hashtable itself (quite weird). I'll continue looking at it tomorrow with a person in #vala. Hope you'll be able to push it tomorrow afternoon or so :)
Jan 10 02:41:03 <pespin> gnight!
Jan 10 02:41:05 <GNUtoo|laptop> not sure
Jan 10 02:41:07 <GNUtoo|laptop> good night
Jan 10 02:41:20 <pespin> ok, np :)
**** ENDING LOGGING AT Mon Jan 10 02:59:58 2011