**** BEGIN LOGGING AT Wed Oct 14 02:59:56 2009
Oct 14 06:43:33 <tmzt> raster: hypervisor, the thread on ps2dev is very detailed on how
Oct 14 06:44:21 <raster> ?
Oct 14 06:56:21 <PaulFertser> raster: that was some very interesting hack that made GPU accessible to "other oses" but not in a generic way, there was (planned) a library to write demoscene-kind of apps.
Oct 14 06:57:16 <DocScrutinizer> *yawn*
Oct 14 06:57:40 <tmzt> PaulFertser: I think you mean using spu as gpu
Oct 14 06:57:47 <tmzt> for that library
Oct 14 06:58:01 <PaulFertser> tmzt: nope, i meant access of nvidia GPU to do 3D.
Oct 14 06:58:03 <tmzt> the thread (don't have link but it's long)
Oct 14 06:58:12 <raster> PaulFertser: doesnt much matter. the gpu on a ps3 is pretty weak by todays desktop gpu standards
Oct 14 06:58:35 <raster> for a device that big... i dont think its that interesting
Oct 14 06:58:39 <raster> yes - it is cheap...
Oct 14 06:58:47 <tmzt> is accessing gpu by manipulating some map to gain access to sarea
Oct 14 06:59:05 <tmzt> and the they got as far as a few triagnles and textured video
Oct 14 06:59:15 <tmzt> sice raster mentioned fast f
Oct 14 06:59:19 <tmzt> fb
Oct 14 06:59:50 <tmzt> it was due to hv not validating 0 or some other value in a mapping call
Oct 14 06:59:53 <PaulFertser> raster: it was claimed in some presentation that ps3 was the only device not "cracked" to run homebrew because it allowed homebrew in almost acceptable way from the start. All other devices were cracked and as a result run illegally copied game titles too.
Oct 14 07:00:29 <PaulFertser> tmzt: nope, that was inherent feature of hv, not really patchable.
Oct 14 07:01:23 <tmzt> what?
Oct 14 07:01:32 <tmzt> it was patched in later firmwares
Oct 14 07:01:42 <tmzt> it's not there anymore
Oct 14 07:01:47 <tmzt> 0 no longer works
Oct 14 07:01:49 <PaulFertser> tmzt: i need to reread the thread then
Oct 14 07:01:54 <tmzt> it's all in the thread
Oct 14 07:03:04 <Defiant> PaulFertser: presentation at chaos commununication congress?
Oct 14 07:03:07 <PaulFertser> I wonder why some talented hackers care so much not to actually crack copy protection and help "pirates". I guess by not exposing GPU to "other os" in a sane way they pretty much deserved it.
Oct 14 07:03:16 <PaulFertser> Defiant: yes, i saw the video from that.
Oct 14 07:03:28 <raster> PaulFertser: i havent kept up with who cracks what etc. etc. :)
Oct 14 07:07:22 <spaetz> new PS3 doesn't allow Linux anymore, right?
Oct 14 07:07:30 <spaetz> not that I'd care a lot
Oct 14 07:09:16 <raster> spaetz:  not as of the ps3 slim
Oct 14 07:09:31 <tmzt> yeah
Oct 14 07:09:40 <tmzt> did thy free up a spu then?
Oct 14 07:09:47 <tmzt> or still hv for games?
Oct 14 07:10:16 <tmzt> ppu
Oct 14 07:10:19 <tmzt> sorry
Oct 14 07:10:52 <raster> i dont know what they did
Oct 14 07:11:01 <raster> just linux is no longer installable on new ps3's
Oct 14 07:11:16 <raster> they probably dont see that continuing support for it is worth the money
Oct 14 07:11:27 <raster> ie ever5y firmware rev they need to tes
Oct 14 07:11:34 <raster> test it against manyirf not all games
Oct 14 07:11:37 <raster> and test against linux
Oct 14 07:11:44 <raster> one thing less to test angainst and fix
Oct 14 07:11:55 <raster> and for sony its a thing that doesnt bring in ehough revenue - if any
Oct 14 07:15:11 <PaulFertser> tmzt: i think that's the thread: http://forums.ps2dev.org/viewtopic.php?p=59485
Oct 14 07:17:03 <tmzt> thanks, let me check
Oct 14 07:18:02 <mrmoku> mickey|office: be prepared to get a nice testcase now ;)
Oct 14 07:22:12 <PaulFertser> I wished IronPeter would actually try to break ps3 fully open rather than keeping it closed for "illegally" copied games.
Oct 14 07:25:15 <mrmoku> TAsn: in case you ever want to register some dbus marshallers.... please do it _after_ creating a connection to the bus :P
Oct 14 07:25:24 <mrmoku> (could save you some time ;)
Oct 14 07:27:06 <TAsn> mrmoku, please mail them, I think they should really add that to their manual...
Oct 14 07:27:06 <TAsn> ;)
Oct 14 07:29:42 <TAsn> mrmoku, so everything is cool now?
Oct 14 07:36:11 <mrmoku> TAsn: the testcase for mickey|office is cool, yes :P
Oct 14 07:36:26 <TAsn> mrmoku, what testcase?
Oct 14 07:36:43 <mrmoku> to show that fsousaged sends a wrong signal for GSM being ready
Oct 14 07:36:52 <TAsn> heh :)
Oct 14 07:37:14 <TAsn> ogsmd does something wrong as well! (I already opened a bug about it that no one responded to ;( )
Oct 14 07:37:20 <TAsn> anyhow, I really gotta go.
Oct 14 07:37:21 <TAsn> cya ;)
Oct 14 07:37:24 <mrmoku> cya
Oct 14 07:38:35 <mickey|office> mrmoku: excellent! i'm all ears
Oct 14 07:38:56 <mrmoku> mickey|office: check mail :)
Oct 14 07:39:00 <mickey|office> ah, got it
Oct 14 07:40:04 <mickey|office> wow! in C
Oct 14 07:40:08 <mickey|office> thought you'd hack it up in Py
Oct 14 07:40:28 <mrmoku> hehe... might have been faster
Oct 14 07:41:44 <mrmoku> those freaking marshallers costed me half day
Oct 14 07:41:50 <mickey|office> yeah
Oct 14 07:42:19 <mrmoku> until I read in the dbus source that you must register them after opening a connection to the bus
Oct 14 07:42:42 <mickey|office> docs suck a bit as well, ya
Oct 14 07:42:46 <mrmoku> yup
Oct 14 07:42:48 <mickey|office> that's why i appreciate vala
Oct 14 07:42:49 <mickey|office> find . -name "*.vala"|xargs wc -l
Oct 14 07:42:53 <mickey|office> 4854
Oct 14 07:42:56 <mickey|office> now let's see the .C code
Oct 14 07:43:09 <mickey|office> find . -name "*.c"|xargs wc -l 
Oct 14 07:43:13 <mickey|office> 34964
Oct 14 07:43:21 <mickey|office> almost factor 10
Oct 14 07:43:23 <tmzt> DocScrutinizer: if you here/have a minut can you join #mer ?
Oct 14 07:43:23 <tmzt>  ?
Oct 14 07:43:25 <mrmoku> c way superiour ;)
Oct 14 07:43:28 <tmzt> sorry
Oct 14 07:45:30 <FiXion> hmm. my new Debian install on openmoko stops after the kernel has loaded.. it doesn't show any init activity.
Oct 14 07:46:06 <FiXion> and now it white screened and said "device boot reload failed"
Oct 14 07:46:31 <CIA-26> freesmartphone.org: 03baruch 07framework * r6b345558913d 10/framework/subsystems/ogpsd/ubx.py: 
Oct 14 07:46:31 <CIA-26> freesmartphone.org: ogpsd: Correct the comment about usage of SBAS
Oct 14 07:46:31 <CIA-26> freesmartphone.org: We set mode to 1 which means we use SBAS but not if its in test-mode.
Oct 14 07:46:58 <tmzt> DocScrutinizer: if your not here, problem is screen flicker when cpufreq scaling on s3c something
Oct 14 07:48:53 <CIA-26> freesmartphone.org: 03baruch 07framework * r043cef6d2122 10/ (2 files in 2 dirs): 
Oct 14 07:48:53 <CIA-26> freesmartphone.org: ogpsd: Set NAV2 parameters to define the static threshold to reduce movement noise
Oct 14 07:48:53 <CIA-26> freesmartphone.org: when the GPS is stationary.
Oct 14 07:53:54 <FiXion> with the default 2.6.28 kernel in the deb. install (installed using install.sh all) it simply stopped showing anything on the screen, after the first 4 g_ether complaints (which I also get with qtmoko distro, which boots fine)
Oct 14 07:54:43 <FiXion> and then it fails after quite a while with the same device boot reload failed.
Oct 14 07:54:49 <FiXion> which I suspect is just some timeout
Oct 14 07:55:07 <FiXion> I have the sd card mounted and running on nand again
Oct 14 07:55:16 <FiXion> any hints as to what I should look for ?
Oct 14 07:55:28 <tmzt> FiXion: #openmoko-debian unless you think it's kernel
Oct 14 07:56:06 <tmzt> well, I don't know where that message comes from
Oct 14 07:57:21 <Weiss> larsc: you came back after I'd left work (no internet at home yet). I wouldn't have made it tonight anyway (hadn't had dinner until about 10pm), but would be interested in coming next week or later if the same thing is happening
Oct 14 07:57:32 <FiXion> tmzt: okay - both that and this channel is listed on the debianonfreerunner wiki entry - I'll try the other
Oct 14 07:58:11 <tmzt> Weiss: it's at the end of the year
Oct 14 07:58:24 <tmzt> if you mean the conference
Oct 14 07:58:53 <FiXion> tmzt: I'm rather certain it's a kernel message
Oct 14 07:58:57 <FiXion> it never gets to init
Oct 14 07:59:07 <tmzt> not one I've seen
Oct 14 07:59:09 <FiXion> I know it's a kernel message - googleing says so.
Oct 14 07:59:17 <Weiss> tmzt: just the weekly local meeting
Oct 14 07:59:19 <FiXion> but it's just a timeout.. something else is wrong
Oct 14 07:59:23 <tmzt> but could be related to resume
Oct 14 07:59:31 <tmzt> what is the message?
Oct 14 08:01:34 <FiXion> http://lists.openmoko.org/pipermail/devel/2009-January/004466.html
Oct 14 08:01:36 <FiXion> same as that
Oct 14 08:01:50 <FiXion> except no VFS line
Oct 14 08:01:59 <FiXion> and no kernel panic
Oct 14 08:02:26 <FiXion> I'll try appending loglevel=8
Oct 14 08:04:05 <tmzt> right
Oct 14 08:04:16 <tmzt> so very odd
Oct 14 08:04:19 <FiXion> indeed
Oct 14 08:04:24 <FiXion> never seen a kernel stop like that
Oct 14 08:04:33 <FiXion> but I haven't played with kernels on openmoko :)
Oct 14 08:05:31 <FiXion> the andy-tracking kernel stops outputting at: Freeing init memory: 152k
Oct 14 08:05:46 <mickey|office> EABI/OABI mismatch?
Oct 14 08:05:48 <FiXion> if I remember correctly - that's where init is normally supposed to take over
Oct 14 08:05:53 <mickey|office> sounds much like it
Oct 14 08:05:59 <FiXion> and it says it mounted root correctly
Oct 14 08:06:07 <FiXion> mickey|office: what is EABI/OABI ?
Oct 14 08:06:37 <FiXion> if I insert usb - it writes that I've done so
Oct 14 08:06:42 <mickey|office> different ways of parameter representation on the stack
Oct 14 08:06:44 <FiXion> so it looks like a continuous dmesg
Oct 14 08:06:53 <mickey|office> please google for it
Oct 14 08:06:59 <tmzt> that should still be after VFS
Oct 14 08:07:01 <FiXion> mickey|office: I will.
Oct 14 08:07:11 <mickey|office> if you compile a kernel without OABI support, handing out an OABI rootfs, it will hang exactly like taht
Oct 14 08:07:20 <mickey|office> and vice versa
Oct 14 08:07:30 <tmzt> mickey|office: before mounting root?
Oct 14 08:07:32 <mickey|office> yes
Oct 14 08:07:38 <tmzt> how?
Oct 14 08:07:38 <FiXion> the rw option to append did it
Oct 14 08:08:06 <FiXion> I found another post on rw missing in append-GTA02
Oct 14 08:08:14 <tmzt> if the binaries are on rootfs
Oct 14 08:08:31 <FiXion> all is in one partition /
Oct 14 08:08:39 <mickey|office> the kernel obviously needs to know which ABI you are using for the syscalls
Oct 14 08:08:46 <mickey|office> if it's not matching, you get a hang
Oct 14 08:09:05 <mickey|office> you can compile support for both ABIs in though
Oct 14 08:09:10 <tmzt> but no syscalls are made until kernel mounts root
Oct 14 08:09:25 <tmzt> and exec's init
Oct 14 08:09:32 <tmzt> the it hangs
Oct 14 08:09:52 <tmzt> then
Oct 14 08:12:12 <FiXion> I really need a usb->miniusb adapter for a keyboard :(
Oct 14 08:13:26 <FiXion> gsm didn't work and I couldn't log in - root password was appearently not blank
Oct 14 08:13:40 <FiXion> thank god for nand :)
Oct 14 08:17:47 <tmzt> lis are accels?
Oct 14 08:17:59 <tmzt> so probably not related
Oct 14 08:27:13 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r504d8d1a850d 10/src/view/ (common-utils.c common-utils.h): added more utility functnios
Oct 14 08:27:14 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * r1eea430d5a08 10/src/view/contact-list-common.c: contact-list: fix uppercasing the index chars
Oct 14 08:27:14 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * rd598aeb400c6 10/src/ (7 files in 2 dirs): renamed and fixed all the uses for skip_prefix_
Oct 14 08:27:15 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r6032fb3976a3 10/ (TODO src/view/contact-list-common.c): fixed the segfault when there's no name to a contact and updated todo
Oct 14 08:27:18 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * re112e1ffca54 10/src/view/ (common-utils.c common-utils.h): renamed common_utils_add_prefix
Oct 14 08:27:24 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r6e96920d3dc5 10/src/phonegui-contacts.c: fixed a typo
Oct 14 08:27:26 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * rd8740b72943c 10/src/ (phonegui-contacts.c view/contact-show-view.c): added a workaround for the gvalue hell can't add contact from sms/phonelog issue
Oct 14 08:27:29 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * r0a1f354bfb86 10/ (4 files in 2 dirs): message-new-view: use elm_genlist for the recipients
Oct 14 08:27:32 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * rcf9006c51372 10/src/view/contact-list-view.c: contacts: show a contact by longpressing on the list and not select
Oct 14 08:27:35 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r131d197d5c52 10/src/ (4 files in 2 dirs): removed the string_is_number and string_strip_html and used the phone_utils and elm alternatives - more testing is needed as I'm tired and maybe not fit for testing :)
Oct 14 08:27:43 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r6bfd4f4401db 10/src/view/contact-show-view.c: s/8\//*\//
Oct 14 08:27:46 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r6cab9bab86fb 10/TODO: changed todo
Oct 14 08:27:48 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r2c1eb1a3d957 10/src/view/message-list-view.c: removed weird spacing
Oct 14 08:27:51 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r8ee1e38ed925 10/src/ (util/helper.c util/helper.h view/message-list-view.c): removed all traces to that horrible time_stringtotimestamp function
Oct 14 08:27:54 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * rd5a905a7aeeb 10/TODO: updated todo
Oct 14 08:27:56 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * re5c3e21c6874 10/src/phonegui-contacts.c: fixed a typo, should have been phone, though it was number
Oct 14 08:27:59 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * rb096a6a1bcda 10/src/view/message-new-view.c: removed all the data saving mess and put it where it belongs, content change (where we already strip and do everything needed, this keeps consistency of data)
Oct 14 08:28:09 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * rd3556f78ac74 10/src/view/ (contact-list-view.c message-new-view.c): fix sending SMS from the contact list
Oct 14 08:28:12 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * rc16489d1dd42 10/src/view/ (call-active-view.c call-incoming-view.c): add missing window_show to call screens
Oct 14 08:28:15 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * rb994b233a87e 10/src/view/ussd-view.c: ussd: remove obsolete callback_close from options and use the new exit_cb instead
Oct 14 08:28:20 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * r4ba3d9362bc6 10/src/view/dialog-view.c: remove elm_exit from dialog-view
Oct 14 08:28:23 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * r6cbf32fd07b4 10/src/ (9 files): add phonegui_backend_loop
Oct 14 08:28:26 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r34876e16ec3d 10/src/util/ (helper.c helper.h): removed string_replace_newline which is useless and ugly
Oct 14 08:28:33 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * rb63319b091d5 10/ (17 files in 5 dirs): Merge branch 'master' into no-async
Oct 14 08:28:36 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r0750187fa36f 10/TODO: added something to TODO
Oct 14 08:28:38 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * r1c3dab73c322 10/src/phonegui-init.c: remove extra context/mainloop from phonegui_backend_init
Oct 14 08:28:45 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r5566764cfe4e 10/src/view/message-new-view.c: added a missing g_strstrip to strip trailing newline
Oct 14 08:28:48 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * ree41dbc607b8 10/src/view/call-incoming-view.c: use correct view data struct to release a call
Oct 14 08:28:51 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * rad55cc304927 10/src/ (6 files in 2 dirs): added common-utils.h|c and started using common_utils_skip_tel_prefix everywhere
Oct 14 08:28:56 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * rfad27c25ee73 10/src/view/message-new-view.c: remove doubled gl_label (caused by mismerging master)
Oct 14 08:28:59 <CIA-26> SHR: 03mok 07libframeworkd-phonegui-efl2 * r7fc8a60c5f88 10/src/ (16 files in 3 dirs): give window_view_show an exit_cb to be able to wipe a static win
Oct 14 08:30:57 <mrmoku> hehe... merging branches is a nice way to spam the chan ;)
Oct 14 08:36:37 <mickey|office> indeed
Oct 14 09:05:37 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r0b15555f96ff 10/fsogsmd/ (6 files in 4 dirs): fsogsmd: rename plugin gsm_device to dbus_service
Oct 14 09:14:10 <tmzt> ~/wi 11
Oct 14 09:28:24 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * rdc9f049fa4e8 10/libfsoframework/fsoframework/interfaces.vala: libfsoframework: interfaces: add well-known GPS prefixes
Oct 14 09:29:03 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r3484d0a4368a 10/fsogpsd/ (14 files in 8 dirs): fsogpsd: rename gps_device to dbus_service; rename protocol_nmea to device_nmea; add tests skeleton
Oct 14 09:33:04 * spaetz looks forward to 1)a new regular -unstable snapshot and 2) more fso...d goodness :)
Oct 14 09:33:28 <mickey|office> :)
Oct 14 09:34:05 <tmzt> mickey|office: Pre progress?
Oct 14 09:34:59 <mickey|office> not here, just unpacked it and played a bit. I'm concentrating on fso2 this week and don't want to work on too many construction sites at once
Oct 14 09:35:16 <mickey|office> stefan and the guys are working on it
Oct 14 09:35:22 <tmzt> ah, ok
Oct 14 09:35:36 <tmzt> still doing ogsmd for it?
Oct 14 09:35:45 <mickey|office> i will come in play once the first bits are reverse engineered
Oct 14 09:36:11 <mickey|office> it depends a bit on the RE results
Oct 14 09:36:23 <tmzt> I jump around a bit too much :)
Oct 14 09:36:27 <mickey|office> *nod*
Oct 14 09:36:33 <mickey|office> don't lose focus
Oct 14 09:37:04 <mickey|office> if the pre is really using a binary protocol, then i might consider not adding support for it in ogsmd
Oct 14 09:37:09 <mickey|office> but rather in fsogsmd right from the start
Oct 14 09:37:14 <mickey|office> since it's lot of work anyways
Oct 14 09:37:25 <mickey|office> if though we can somehow talk AT to it, i'd start in ogsmd, since that's already there
Oct 14 09:37:27 <tmzt> ah yeah, should have said *gsmd
Oct 14 09:37:53 <mickey|office> yeah, that for sure
Oct 14 09:38:10 <tmzt> is the timeout code similar in the vala stuff?
Oct 14 09:38:10 <mickey|office> i just leave the dirty RE bits to folks that are better with that
Oct 14 09:38:26 <tmzt> right
Oct 14 09:38:49 <mickey|office> the timeout concept is rougly similar, but fsogsmd will attempt retransmissions, if asked for
Oct 14 09:38:59 <tmzt> ok
Oct 14 09:39:03 <spaetz> RE is a pain in the ass. TO *rediscover* what others have consciously *obfuscated* seem like sucha waste of resources
Oct 14 09:39:21 <spaetz> but I'm preaching to the converted here, so I'll shut up:)
Oct 14 09:39:30 <mickey|office> tmzt: I'm trying to be less AT-centric right from the start, btw
Oct 14 09:39:32 <mickey|office> spaetz: ;)
Oct 14 09:39:44 <tmzt> I think you are overestimating the amount of binary on the pre though
Oct 14 09:40:00 <tmzt> but I donqt have hardware so I have to rely on third parties
Oct 14 09:40:06 <tmzt> AT centric?
Oct 14 09:40:10 <mickey|office> err
Oct 14 09:40:19 <mickey|office> yes, that and GSM-centric (as opposed to cdma)
Oct 14 09:40:35 <tmzt> nice, thanks
Oct 14 09:40:48 <mickey|office> like, it's going to be easier to introduce binary protocols in fsogsmd than ogsmd
Oct 14 09:41:34 <tmzt> hate to bring this up again, but ignoring dbus api what do you think of ofono's gatchat implementation or have you looked at it at all?
Oct 14 09:42:52 <mickey|office> i did look at it when it first was commited, but that's long ago
Oct 14 09:42:55 <mickey|office> let me take a brief look again
Oct 14 09:43:52 <mickey|office> heh, fun, they're using the qtopia code as well now 
Oct 14 09:43:55 <tmzt> they are supporting binary protocols and userspace mux and potentially ppp with same infrastructure
Oct 14 09:43:59 <tmzt> where?
Oct 14 09:44:06 <tmzt> I only saw glib and c
Oct 14 09:44:18 <mickey|office> gsm0710.c is from qtopia
Oct 14 09:44:47 <mickey|office> ya, looks not bad
Oct 14 09:44:52 <mickey|office> my transport abstraction is better though
Oct 14 09:45:48 <mickey|office> my AT abstraction as well
Oct 14 09:45:58 <mickey|office> as it enables us to override certain AT commands with vendor-specifics
Oct 14 09:46:06 <mickey|office> without touching the mediator
Oct 14 09:46:16 <mickey|office> (the one that mediates between the modem protocol and the dbus API)
Oct 14 09:46:24 <spaetz> tmzt: stop distracting mickey with "pre" stuff, he needs to focus on making the FR superior now ;-)
Oct 14 09:46:31 <mickey|office> hehe
Oct 14 09:46:41 <mickey|office> well
Oct 14 09:46:58 <mickey|office> if all goes well, we all benefit from everything
Oct 14 09:47:03 <mickey|office> like... SHR and FSO on the pre
Oct 14 09:47:09 <mickey|office> which would be the ultimate goal
Oct 14 09:47:29 <spaetz> yep, that would be cool. But for now I would be happy tomake it work well on the FR before expaning the scope :)
Oct 14 09:47:44 <mickey|office> sure
Oct 14 09:47:58 <mickey|office> right now i think the major problem is the reliability
Oct 14 09:48:15 <mickey|office> and all the unstableness due to release management
Oct 14 09:48:21 <mickey|office> but we all are working on that
Oct 14 09:48:28 <mickey|office> like... shr/merge and oe.dev and all
Oct 14 09:53:52 <tmzt> spaetz: right, ok
Oct 14 09:54:15 <tmzt> where is stefen, etc. working on this then?
Oct 14 09:54:30 <tmzt> or it's all in person? which is prbably much quicker
Oct 14 09:55:18 <larsc> Weiss: sure
Oct 14 09:55:50 <spaetz> mickey|office: true, that is a major source of flakiness currently
Oct 14 09:56:44 <spaetz> don't know if it gets any better when using dev.oe.org but working as much "upstream" as possible is always good
Oct 14 09:57:11 <spaetz> I am just annoyed at bitbake silently failing to compile packages with some of them missing in the final image
Oct 14 09:57:41 <spaetz> silently == there is some ERROR line hidden in some log but the image creation succeeds
Oct 14 10:01:16 <dos1> spaetz: disable threads in bitbake
Oct 14 10:09:07 <tmzt> 21:25 < rmt> Seems to all work as it should.. "sb2 valac helloworld.vala" uses amd64 valac + cross compiling gcc to produce an arm helloworld binary .. sb2 ./helloworld then runs it.
Oct 14 10:09:12 <tmzt> neat.
Oct 14 10:09:30 <tmzt> (scratchbox2 with qemu-arm)
Oct 14 10:11:22 <mickey|office> tmzt: stefan_schmidt, he's not much on irc these days, but hopefully that'll improve
Oct 14 10:12:01 <mickey|office> tmzt: we need to check where our work is best communicated, we don't want to create a "parallel society" but rather work inside the webos-internals community in addition to the FSO folks
Oct 14 10:12:24 <tmzt> right
Oct 14 10:12:35 <tmzt> I think documentation should be internals
Oct 14 10:12:38 <mickey|office> yep
Oct 14 10:13:01 <tmzt> somewhat the original goal of the channel/site
Oct 14 10:13:01 <tmzt> and implementation here?
Oct 14 10:13:01 <mickey|office> since webos is so cool (really), i have no idea how many folks are interested in replacing it completely
Oct 14 10:13:04 <mickey|office> but lets see
Oct 14 10:13:14 <mickey|office> eventually we should think about renaming this channel IMO
Oct 14 10:13:34 <tmzt> I took c to mean native in the beginning :)
Oct 14 10:13:39 <tmzt> not community
Oct 14 10:13:41 <mickey|office> aaah
Oct 14 10:13:45 <tmzt> thought that was cool
Oct 14 10:13:46 <mickey|office> heh, never thought of that
Oct 14 10:13:56 <mickey|office> but actually... it fits ;)
Oct 14 10:14:03 * mickey|office doing C development as well
Oct 14 10:14:06 <mickey|office> :D
Oct 14 10:14:44 <tmzt> by the way, not saying use scratchbox or anything, but seems they solved a problem you have with oe/bitbake
Oct 14 10:14:51 <tmzt> not sure
Oct 14 10:15:12 <mickey|office> well, it's different
Oct 14 10:15:18 <mickey|office> scratchbox is better for developers
Oct 14 10:15:24 <mickey|office> oe is better for system integrators
Oct 14 10:16:36 <tmzt> ah, ok
Oct 14 10:20:02 <mrmoku> TAsn: ping
Oct 14 10:24:22 <Heinervdm> mrmoku: can you apply JaMa's patch to shr/merge?
Oct 14 10:24:43 <spaetz> they should really apply for commit access...
Oct 14 10:28:25 <Heinervdm> spaetz: for shr/merge it would be ok, because that's currently a playground. But for rest it's to dangorus, because we don't know the rules for OE...
Oct 14 10:28:41 <mrmoku> Heinervdm: applied
Oct 14 10:28:48 <Heinervdm> mrmoku: thc
Oct 14 10:28:50 <Heinervdm> thx
Oct 14 10:29:08 <mrmoku> btw. I still have problems with blktool :(
Oct 14 10:29:31 <Heinervdm> strange, i tried to rebuild it and it build
Oct 14 10:30:04 <mrmoku> Heinervdm: it might depend on the buildhost...
Oct 14 10:30:21 <mrmoku> scsi.c:19:18: error: glib.h: No such file or directory
Oct 14 10:30:49 <Heinervdm> strange nerver seen this
Oct 14 10:34:36 <mrmoku> dos1: could you think about what is necessary on frameworkd side when we want to switch to efl2?
Oct 14 10:34:45 <mrmoku> like the triggers patch... different rules... dunno
Oct 14 10:34:52 <JaMa> do you have problems with building new libXft?
Oct 14 10:35:11 <mrmoku> as with the new ophonekitd old efl probably will cease to work :P
Oct 14 10:35:14 <mrmoku> JaMa: blktool
Oct 14 10:35:31 <JaMa> I have, but it looks like some autoconf magic failed.. the same version compiled fine on my host
Oct 14 10:35:40 <mrmoku> anyway... have to do kindergarten pickup... bbl
Oct 14 10:36:22 <Heinervdm> JaMa: you did sth wrong with new mesa ;)
Oct 14 10:36:31 <dos1> mrmoku|away: i think only triggers patch... i'll look at rules too
Oct 14 10:36:47 <dos1> mrmoku|away: btw, merge org.oe.dev to shr/merge ;)
Oct 14 10:37:02 <Heinervdm> mesa 7.5.1 doesn't exists, and you set you should have set preferred provider in shr-om-gta02.conf
Oct 14 10:39:51 <JaMa> Heinervdm: thats because your bitbake doesn't understand 7.5.1% in preferred version :/, I think you should remove mesa from preferred versions now.. because if the version you updated there exists its picked up instead of mesa-dri_git.bb
Oct 14 10:40:02 <JaMa> but I'll recheck
Oct 14 10:40:38 <Heinervdm> JaMa: in shr-om-gta02.conf preferred provider is overwritten with mesa
Oct 14 10:40:44 <Heinervdm> that's the problem
Oct 14 10:40:48 <JaMa> Heinervdm: PREFERRED_PROVIDER_mesa ?= "mesa-dri" is in conf/machine/om-gta02.conf
Oct 14 10:41:09 <Heinervdm> PREFERRED_PROVIDER_mesa = "mesa" in shr-om-gta02.conf ;)
Oct 14 10:41:33 <JaMa> Heinervdm: ah please remove those two (libdrm too)
Oct 14 10:41:56 <Heinervdm> ok :)
Oct 14 10:42:15 <JaMa> I'll send patch.. mmt
Oct 14 10:46:54 <Heinervdm> we should set a fixed SRCREV for every package on github...
Oct 14 10:47:16 <JaMa> yes failed about 5 times yesterday for me on advancedcaching :/
Oct 14 10:47:25 <Heinervdm> for me too
Oct 14 10:48:01 <Heinervdm> we should have as less AUTOREV'd packages as possible...
Oct 14 10:48:38 <JaMa> Heinervdm: sent
Oct 14 10:50:15 <JaMa> but then we could miss some important updates :/ ie that advancedcaching was developing pretty fast when I created bbfile.. and I don't like checking repo or even opkg.org if new version is released :/ 
Oct 14 10:50:52 <Heinervdm> JaMa: does the dev not send an email to ML?
Oct 14 10:51:04 <JaMa> ah :(
Oct 14 10:51:08 <JaMa> wrong list :/
Oct 14 10:51:11 <JaMa> shit
Oct 14 10:51:27 <Heinervdm> where did you sent it to?
Oct 14 10:52:40 <spaetz> JaMa: I agree with Heinervdm that we should use as little AUTOREV as possible
Oct 14 10:52:56 <spaetz> why? for each bitbake build it contacts all the GIT repos to check for the latest revision
Oct 14 10:53:09 <spaetz> that takes lots of time and chances are that some git repo might be down.
Oct 14 10:53:31 <Heinervdm> ok, will be back in an hour or so, have to paint the door :)
Oct 14 10:53:42 <spaetz> which prevents me building stuff even though nothing has changed there most of the time :)
Oct 14 10:56:21 <JaMa> Heinervdm: openembedded-devel@lists.openembedded.org, but their patchwork is much slower to pick it
Oct 14 10:56:41 <JaMa> spaetz: you can ask bitbake to cache it..
Oct 14 10:57:03 <JaMa> Heinervdm: spaetz: BB_SRCREV_POLICY="cache"
Oct 14 10:57:37 <JaMa> to conf/local.conf
Oct 14 11:01:58 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r6c774ac55ec5 10/fsogpsd/src/lib/receiver.vala: fsogpsd: receiver: add some logic from fsogsm modem class
Oct 14 11:03:06 <mickey|office> only unstable should use AUTOREV in the first place. stable and testing should use pinpointed versions
Oct 14 11:03:27 <dos1> and in fact we have only unstable atm ;D
Oct 14 11:03:34 <spaetz> mickey|office: sure, that's totally obvious.
Oct 14 11:03:43 <mickey|office> dos1: (which is the root problem...)
Oct 14 11:03:52 <spaetz> but we don't even have a -testing release :)
Oct 14 11:05:40 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r64ba87e46e99 10/fsogsmd/src/lib/modem.vala: fsogsmd: modem: data is now a class in the modem interface, not a toplevel class
Oct 14 11:07:48 <DocScrutinizer> moin mickey|official ;-D
Oct 14 11:07:59 <mickey|office> heh, not quite
Oct 14 11:08:01 <mickey|office> morning
Oct 14 11:08:29 <JaMa> Heinervdm: http://patchwork.openembedded.org/patch/1120/
Oct 14 11:08:40 <JaMa> Heinervdm: http://patchwork.openembedded.org/patch/1121/
Oct 14 11:14:47 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r008b6608a79d 10/ (4 files in 4 dirs): add fsogspd to top-level Makefile
Oct 14 11:19:07 <spaetz> fsogspd ?
Oct 14 11:19:23 <spaetz> fsogspd -> fsogpsd, I guess
Oct 14 11:31:32 <mrmoku> dos1: what about opimd config in frameworkd.conf?
Oct 14 11:32:38 <dos1> mrmoku: should be ok
Oct 14 11:32:51 <dos1> mrmoku: maybe s/SIM-Messages-FSO/SQLite-Messages/ as default backend?
Oct 14 11:35:27 <mrmoku> yup, might be worth a thought :)
Oct 14 11:37:26 <JaMa> mrmoku: could you apply http://patchwork.openembedded.org/patch/1120/ and http://patchwork.openembedded.org/patch/1121/ to shr/merge? or should I resend to shr ml?
Oct 14 11:38:25 <mrmoku> JaMa: if they apply as is... no need to resend
Oct 14 11:38:27 * mrmoku tries
Oct 14 11:39:50 <dos1> mrmoku: and merge org.oe.dev ;)
Oct 14 11:40:03 <mrmoku> ok ;)
Oct 14 11:41:05 <mrmoku> done
Oct 14 11:41:45 <mrmoku> Heinervdm: do you have a glib.h hanging around somehwere in your include path?
Oct 14 11:41:48 <mrmoku> (on the buildhost)
Oct 14 11:44:47 <JaMa> mrmoku: thanks
Oct 14 11:46:34 <playya> bitbake is using header files on the host again?
Oct 14 11:46:54 <Heinervdm> mrmoku: will have a look
Oct 14 11:49:08 <Heinervdm> mrmoku: /usr/include/glib-2.0/glib.h
Oct 14 11:49:10 <JaMa> Running task 958 of 9002 again, because leading / in TMPDIR path breaks staging :/
Oct 14 11:51:28 <mrmoku> Heinervdm: hmm... have that one too... looking at the recipe it is broken anyway
Oct 14 11:51:34 <mrmoku> missing depend for glib-2.0
Oct 14 11:51:54 <mrmoku> and using autotools instead of pkgconfig
Oct 14 11:52:29 <mrmoku> trying if that fixes it now
Oct 14 12:00:21 <Heinervdm> make[2]: *** No rule to make target `types.vala', needed by `fsobasics.vala.stamp'.  Stop.
Oct 14 12:13:52 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * rea0928984658 10/libfsobasics/fsobasics/types.vala: libfsobasics: add missing file, thanks heinervdm
Oct 14 12:19:21 <mrmoku> mickey|office: took a look at the testcase yet? :)
Oct 14 12:19:39 <mickey|office> i don't have my neo with me :/
Oct 14 12:19:54 <mrmoku> ahh :)
Oct 14 12:19:54 <mrmoku> ok
Oct 14 12:20:20 <mickey|office> ogsmd does not work with transport sockets (just as fsogsmd), so i can't hook it to the phonesim
Oct 14 12:20:34 <mickey|office> i could try w/ fsogsmd though
Oct 14 12:22:19 <mrmoku> mickey|office: just tell me if it does not build or is creating other problems :)
Oct 14 12:22:26 <mrmoku> should build though as I tested it
Oct 14 12:23:12 <mickey|office> builds fine
Oct 14 12:23:17 <mickey|office> i'll try w/ fsogsmd
Oct 14 12:23:35 <mickey|office> what shoudl the output look like if working OK/not OK?
Oct 14 12:23:38 <tmzt> the transpor abstraction stuff? how does that compare with gio? looked like a lowlevel callbacks for buffer management
Oct 14 12:23:53 <tmzt> somewhat like tty layer in the kernel
Oct 14 12:24:37 <dos1> mrmoku: http://patchwork.dev.bearstech.com/patch/285/
Oct 14 12:24:38 <mickey|office> tmzt: the transport abstraction provides a way to transmit data over a socket/tty/pty/libgsm0710
Oct 14 12:24:43 <mickey|office> with always the same API
Oct 14 12:24:49 <mickey|office> hooks into the gmainloop
Oct 14 12:24:59 <mickey|office> and calls you back when there is data to read or an exceptional condition
Oct 14 12:25:19 <mrmoku> mickey|office: http://shr.pastebin.com/m18b6096e
Oct 14 12:25:45 <mickey|office> hmm
Oct 14 12:25:47 <mickey|office> Error: Message did not receive a reply (timeout by message bus)
Oct 14 12:25:47 <mickey|office> ?
Oct 14 12:25:48 <mrmoku> mickey|office: it shows ResourceChanged(GSM,ready) twice
Oct 14 12:26:02 <mrmoku> mickey|office: that is normal as the resource is not yet there
Oct 14 12:26:30 <mrmoku> it continues to request it... and retries on error
Oct 14 12:26:34 <mickey|office> hmm, there should not be a timeout though
Oct 14 12:26:41 <mickey|office> anyways, lines 10-13 show the problem
Oct 14 12:26:52 <mrmoku> yup
Oct 14 12:27:09 <mickey|office> interesting.
Oct 14 12:27:12 <mickey|office> ok, first i need to reproduce that
Oct 14 12:28:48 <mrmoku> Heinervdm: you're creating patches faster than I'm able to apply :P
Oct 14 12:30:51 <dos1> shr@opmbuild:~/shr-oemerge$ bitbake -k task-shr-minimal task-shr && bitbake package-index
Oct 14 12:30:56 <dos1> let's see what'll happen ;)
Oct 14 12:30:59 <playya> that's git magic
Oct 14 12:31:08 <mickey|office> mrmoku: could you log me an mdbus -s -l output while you're performing this test case, please?
Oct 14 12:31:35 <playya> the double signal should be fixed
Oct 14 12:31:56 <mickey|office> yo stefan_schmidt 
Oct 14 12:32:06 <stefan_schmidt> hi mickey|office 
Oct 14 12:32:11 <mrmoku> mickey|office: ok
Oct 14 12:32:20 <stefan_schmidt> mickey|office: Alwaysin the new office now :)
Oct 14 12:32:32 <playya> i disabled ophonekitd, ran a mdbus -s -l org.freesmartphone.ousaged and requested the resource from cli
Oct 14 12:32:45 <mickey|office> stefan_schmidt: ya, especially during those dark days, it's very nice
Oct 14 12:33:29 <stefan_schmidt> mickey|office: :)
Oct 14 12:34:33 <dos1> stefan_schmidt: how's palm pre? :)
Oct 14 12:35:07 <stefan_schmidt> dos1: nice :)
Oct 14 12:35:16 <stefan_schmidt> Just booted a selfcompiled kernel
Oct 14 12:35:28 <mickey|office> great. everythign still working?
Oct 14 12:35:31 <stefan_schmidt> And set back to the old one over bootloader console
Oct 14 12:35:49 <mickey|office> wew, nice
Oct 14 12:35:52 <stefan_schmidt> mickey|office: nope, the modules do not load as OE changes the LOCALVERSION :)
Oct 14 12:36:06 <mickey|office> stefan_schmidt: ah, that needs to be fixed
Oct 14 12:36:07 <stefan_schmidt> call was working but wifi and usb not
Oct 14 12:36:18 <stefan_schmidt> mickey|office: yeah, but that should be easy
Oct 14 12:36:34 <stefan_schmidt> at least I was able to go bakc to the olde kernel over the bootloader without problems
Oct 14 12:37:39 <DocScrutinizer-8> mickeyl: seen haralds most recent mail? the part about "moden almost identical to N900" sounded quite exciting to me
Oct 14 12:38:19 <mickey|office> hmm, well
Oct 14 12:38:22 <mickey|office> yes and no
Oct 14 12:38:43 <mickey|office> i don't know why i'm not excited about Nokia
Oct 14 12:38:47 <mickey|office> i really don't know
Oct 14 12:38:54 <mickey|office> it's something subjective 
Oct 14 12:38:57 <mickey|office> can't explain
Oct 14 12:39:12 <mickey|office> but yes, being able to have the modem on a developer board is good
Oct 14 12:39:19 <mickey|office> even if they go ofono
Oct 14 12:39:37 <DocScrutinizer-8> that's the point probably ;-)
Oct 14 12:39:38 <mickey|office> err, when, that is
Oct 14 12:40:12 <mickey|office> dunno
Oct 14 12:40:22 <mickey|office> i don't like the way Nokia and some Intel guys are treating other people
Oct 14 12:40:27 <mickey|office> i think that's rather it
Oct 14 12:40:46 <mickey|office> lets see how Palm guys behave
Oct 14 12:40:48 <DocScrutinizer-8> hmm, I could understand that as well
Oct 14 12:42:50 <mickey|office> hmm
Oct 14 12:42:52 <mickey|office> i need a whiteboard
Oct 14 12:42:53 <mickey|office> *sigh*
Oct 14 12:42:56 <DocScrutinizer-8> mickey|office: but hey, we don't have to love the hw-manufs, to exploit and root their devices
Oct 14 12:43:46 <mrmoku> mickey|office: http://pastie.org/654374
Oct 14 12:44:58 <mickey|office> mrmoku: thanks
Oct 14 12:45:06 <mickey|office> playya: you mean mrmoku's bug or something else?
Oct 14 12:47:08 <Heinervdm> mrmoku: i want to have a working image as soon as possible, so i have to be fast :P
Oct 14 12:48:17 <playya> mickey|office, mrmokus bug
Oct 14 12:48:33 <mickey|office> playya: d'oh. so it's fixed already? not a bug in fsousaged?
Oct 14 12:48:49 <playya> i think it's in frameworkd
Oct 14 12:49:00 <mrmoku> Heinervdm: :)
Oct 14 12:49:24 <playya> frameworkd return OK when all 4 channels are open, not if they are ready
Oct 14 12:50:00 <JaMa> Heinervdm: I think that we still need patches for disabling cursor and and calibration for shr/merge if you want to use that image not just build it successfully :)
Oct 14 12:50:37 <mickey|office> http://shr.pastebin.com/d519bccb0
Oct 14 12:50:45 <playya> mickey|office, this should be fixed with: http://git.freesmartphone.org/?p=cornucopia.git;a=blobdiff;f=fsousaged/src/plugins/controller/resource.vala;h=406eac6ac03fc8fb5271d331b011f0ed6444c631;hp=4cc988e25d808e8f71dfd3f1ab1a10cbb215b257;hb=4e671d9a3a2a2ead4a19156694f9ae7b8752cab8;hpb=38457666000ed0865f0e89fd157a28c4738e525f
Oct 14 12:51:11 <Heinervdm> JaMa: oh, that's right. But a buildable image would be the first step. I think there is more missing then just cursor and calibration :)
Oct 14 12:51:41 <mickey|office> playya: please include the project prefix in commits, as cornucopia hosts multiple projects
Oct 14 12:51:53 <playya> ok. sorry.
Oct 14 12:51:56 <tmzt> Heinervdm: what were you working on with that? I forget
Oct 14 12:52:18 <playya> i need a git pro to prefix my commits. all of them :)
Oct 14 12:52:20 <tmzt> I think JaMa got evdev working without kernel support now
Oct 14 12:52:47 <JaMa> tmzt: its working for all in new shr-unstable from shr/import..
Oct 14 12:53:06 <tmzt> you hardcoded the script?
Oct 14 12:53:09 <JaMa> tmzt: we just need to use the same in shr/merge but be carefull not to break other devices
Oct 14 12:53:19 <JaMa> tmzt: yes
Oct 14 12:53:21 <tmzt> what do you mean? it's committed?
Oct 14 12:53:28 <JaMa> yes
Oct 14 12:53:33 <JaMa> its committed
Oct 14 12:53:33 <tmzt> no more sysfs? or is that still there
Oct 14 12:53:38 <playya> wow. my 4GB RAM machine swaps
Oct 14 12:53:41 <JaMa> sysfs version is commited
Oct 14 12:53:49 <tmzt> ah, ok
Oct 14 12:54:01 <tmzt> so it's sysfs and hal
Oct 14 12:54:08 <tmzt> not xinput script
Oct 14 12:54:10 <tmzt> got it
Oct 14 12:54:20 <JaMa> tmzt: xinput version didn't work without sysfs echos before
Oct 14 12:54:30 <JaMa> tmzt: and xinput is not installed in shr-image by default..
Oct 14 12:54:47 <tmzt> yeah, I think that's because of the way the driver is written
Oct 14 12:54:54 <tmzt> which works fine on freerunner
Oct 14 12:55:14 <Heinervdm> JaMa: we need to find a way, to calibrate the screen for evdev, this static version is just a hack
Oct 14 12:55:21 <JaMa> tmzt: so add if to calibration script for using xinput if available.. but didn't commit it as it didn't work later
Oct 14 12:55:33 <tmzt> kernel is fine :) it was just an experiment and will be helpful on other devices
Oct 14 12:55:40 <tmzt> if?
Oct 14 12:55:53 <tmzt> ah, I see
Oct 14 12:56:11 <tmzt> it's only needed if each device needs to be calibrated
Oct 14 12:56:20 <tmzt> freerunner is very stable
Oct 14 12:56:31 <JaMa> http://shr.pastebin.ca/1619284
Oct 14 12:56:34 <tmzt> so the script is not needed and kernel data is preferred
Oct 14 13:00:23 <JaMa> Heinervdm: so should I send patches for static cursor calibration/disable for shr/merge?
Oct 14 13:00:55 <Heinervdm> JaMa: yes :)
Oct 14 13:01:24 <tmzt> do you have patches for rotating touchscreen on xrandr?
Oct 14 13:01:32 <tmzt> was the posted here maybe?
Oct 14 13:01:50 <Heinervdm> tmzt: i posted it in #mer last week
Oct 14 13:01:56 <tmzt> and cursor enable/disable on hotplug of REL device?
Oct 14 13:01:58 <tmzt> right
Oct 14 13:02:01 <tmzt> that was it
Oct 14 13:02:22 <tmzt> I knew we had talked about it
Oct 14 13:02:29 <tmzt> I'm getting tired
Oct 14 13:02:36 <Heinervdm> tmzt: http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/xorg-xserver/xserver-xorg/randr-support-1.7.0.patch?h=shr/merge
Oct 14 13:02:54 <tmzt> and cursor?
Oct 14 13:02:54 <Heinervdm> cursor enable disable?
Oct 14 13:02:59 <tmzt> yeah
Oct 14 13:03:08 <Heinervdm> that would be interesting :)
Oct 14 13:03:08 <tmzt> for plugging a mouse in usb
Oct 14 13:03:24 <tmzt> detect if REL is supported
Oct 14 13:03:31 <tmzt> cap mouse I think
Oct 14 13:03:41 <Heinervdm> tmzt: do you a patch for that?
Oct 14 13:03:46 <tmzt> no
Oct 14 13:04:00 <tmzt> somebody must though
Oct 14 13:04:06 <tmzt> I thought it worked
Oct 14 13:04:18 <Heinervdm> but not in shr
Oct 14 13:04:37 <tmzt> using evdev?
Oct 14 13:04:49 <tmzt> and your xrandr was evdev not tslib right?
Oct 14 13:05:13 <Heinervdm> my xrandr works with evdev
Oct 14 13:05:22 <tmzt> sorry, just so many drivers
Oct 14 13:05:23 <tmzt> ok
Oct 14 13:05:31 <Heinervdm> don't but i think it can work wit others too
Oct 14 13:05:40 <tmzt> that's why it was important to get evdev working
Oct 14 13:05:42 <tmzt> hah
Oct 14 13:05:49 <tmzt> I remember now
Oct 14 13:05:53 <Heinervdm> i showed you some patches from openwrt for tslib
Oct 14 13:06:01 <tmzt> yeah
Oct 14 13:06:42 <tmzt> all this stuff is still in my browser session, but there's so much of it
Oct 14 13:06:43 <Heinervdm> JaMa: sth is still wrong with mesa, it tries to build mesa_7.0.2
Oct 14 13:06:50 <Heinervdm> :)
Oct 14 13:07:24 <Weiss> Heinervdm: instead of mesa-dri_git, or something else?
Oct 14 13:07:49 <Heinervdm> Weiss: instead of mesa-dri and instead of newer mesa version :)
Oct 14 13:11:41 <tmzt> Heinervdm: url in svn is the good version?
Oct 14 13:11:46 <tmzt> patch
Oct 14 13:12:08 <Heinervdm> tmzt: that's the patch we use in shr, for xserver 1.7.0
Oct 14 13:12:50 <tmzt> ok
Oct 14 13:13:26 <Heinervdm> hmm we have PREFERRED_PROVIDER_mesa = "mesa-dri" but it builds mesa instead of mesa-dri...
Oct 14 13:13:52 <Ainulindale> Heinervdm: bitbake -vvv is your friend :-)
Oct 14 13:14:18 <mickey|office> mrmoku|away: are you using HEAD of fsousaged?
Oct 14 13:14:31 <mickey|office> mrmoku|away: w/ fsogsmd (see pastebin) I can't reproduce the problem. will try w/ ogsmd when I'm home
Oct 14 13:14:57 * mickey|office cranks a new Channel abstraction that can be used from fsogpsd as well as from fsogsmd
Oct 14 13:15:36 <Heinervdm> ${FREESMARTPHONE_GIT}/cornucopia;protocol=git;branch=master and it's on ${AUTOREV}
Oct 14 13:15:51 <spaetz> mickey|office: yes, fsousaged is AUWTWOREV'd
Oct 14 13:16:25 <spaetz> AUTOREV'd, even
Oct 14 13:17:02 <mickey|office> i see. the problem can only be in resource.py then
Oct 14 13:17:12 <mickey|office> need to compare that to the vala version
Oct 14 13:17:55 <Heinervdm> Ainulindale: bitbake says that it's checking mesa: NOTE: checking PREFERRED_PROVIDER_mesa but it doesn't select mesa-dri
Oct 14 13:18:28 <Ainulindale> Check it's not overriden at some point
Oct 14 13:21:33 <Heinervdm> JaMa: where is shr-om-gta02.conf included?
Oct 14 13:22:42 <Weiss> incidentally, was anyone able to make mesa-dri work with the non-DRI environment?
Oct 14 13:23:56 <Weiss> perhaps by enabling the xlib driver (as well as glamo_dri.so and swrast_dri.so), the same package can be made to work for both
Oct 14 13:26:54 <Heinervdm> JaMa: shr-autorev.inc
Oct 14 13:28:03 <mrmoku> mickey|office: heh... had an older local build of fsousaged installed :(
Oct 14 13:28:10 <mrmoku> updating and retrying now
Oct 14 13:28:47 <dos1> Heinervdm: 
Oct 14 13:28:49 <dos1> ERROR: '/home/shr/shr-oemerge/openembedded/recipes/libgee/libgee_git.bb' failed
Oct 14 13:28:50 <dos1> ERROR: '/home/shr/shr-oemerge/openembedded/recipes/freesmartphone/libfso-glib_git.bb' failed
Oct 14 13:28:52 <dos1> ERROR: '/home/shr/shr-oemerge/openembedded/recipes/mesa/mesa_7.0.2.bb' failed
Oct 14 13:28:53 <dos1> ERROR: '/home/shr/shr-oemerge/openembedded/recipes/matchbox2/matchbox-panel-2_svn.bb' failed
Oct 14 13:28:55 <dos1> ERROR: '/home/shr/shr-oemerge/openembedded/recipes/webkit/webkit-gtk_svn.bb' failed
Oct 14 13:29:21 <dos1> Heinervdm: but i suppose you already know that ;)
Oct 14 13:29:30 <Heinervdm> dos1: lebgee and libfso were working for me
Oct 14 13:29:35 <JaMa> Weiss: I'm using this combination.. mesa-dri-glamo and now non-drm kernel + xf86-video-glamo
Oct 14 13:29:48 <dos1> hmm
Oct 14 13:29:57 <dos1> Heinervdm: so checking, why they fail
Oct 14 13:30:03 <JaMa> Weiss: that's why i merged mesa-dri-glamo and mesa-dri now to one package for both distro versions
Oct 14 13:30:31 <JaMa> Heinervdm: sent patch for calibration and cursor disable..
Oct 14 13:30:45 <JaMa> Heinervdm: but still waiting for image build to finish to test it..
Oct 14 13:31:03 <JaMa> Heinervdm: just spitz xorg-image build successfully but its not shr and not with glamo :)
Oct 14 13:31:32 <dos1> Heinervdm: http://tinderbox.openembedded.net/public/logs/task/3216764.txt
Oct 14 13:31:47 <Heinervdm> JaMa: it's selecting mesa instead of mesa-dri... but in shr-om-gta02.conf is a preferred provider set
Oct 14 13:32:24 <dos1> Heinervdm: http://tinderbox.openembedded.net/public/logs/task/3216766.txt
Oct 14 13:32:34 <Arigead> Good work, well done! Been away for a few days so did a git pull in my local libframeworkd-phonegui-efl2 and build and installed it. Sending and receiving long sms messages! Brilliant!
Oct 14 13:32:43 <JaMa> Heinervdm: shr-om-gta02.conf should be included somewhere as $DISTRO-$MACHINE automagically I guess
Oct 14 13:33:04 <Heinervdm> JaMa: yes in shr-autorev.inc
Oct 14 13:34:10 <Heinervdm> dos1: no idea...
Oct 14 13:34:43 <dos1> Heinervdm: rebuilding vala-dbus-binding-tool-native
Oct 14 13:35:21 <Heinervdm> dos1: ok, if it's not working after that mickey|office has to look on it :)
Oct 14 13:35:42 <Heinervdm> JaMa: does it build mesa-dri for you?
Oct 14 13:38:05 <Tanuva> an the shr phone tools use something else than the sim to store sms messages? I liked not to have to delete them in paroli :)
Oct 14 13:38:18 <Tanuva> *can
Oct 14 13:38:34 <dos1> Tanuva: opimd, with phonegui-efl2
Oct 14 13:38:48 <dos1> Heinervdm: looks like libfso-glib works now
Oct 14 13:39:43 <dos1> Heinervdm: but libgee still fails
Oct 14 13:39:45 <Heinervdm> webkit-gtk worked for me too, mesa_7.0.2 shouldn't be compiled, it should compile mesa-dri_git instead :)
Oct 14 13:39:56 <Tanuva> dos1: not wanting to build myself I need to wait, right?
Oct 14 13:39:58 <JaMa> Heinervdm: its far away now :( Running task 2881 of 9002
Oct 14 13:40:05 <Heinervdm> JaMa: oh
Oct 14 13:40:21 <Heinervdm> but it's building mesa_7.0.2 for dos1 too
Oct 14 13:40:29 <JaMa> Heinervdm: but it worked before (but I have my modified bitbake accepting 7.5.1% as preferred version
Oct 14 13:40:29 <Heinervdm> so sth is strange
Oct 14 13:40:47 <JaMa> Heinervdm: try bitbake -e | grep mesa
Oct 14 13:40:48 <Heinervdm> JaMa: you removed the preferred version ;)
Oct 14 13:41:09 <JaMa> Heinervdm: yes.. because you couldn't preferre AUTOREVed version..
Oct 14 13:41:44 <JaMa> Heinervdm: in mesa-dri_git.bb is highest PV and DEFAULT_PREFERENCE_om-gta02=2 so it should be used as best version for mesa/mesa-dri
Oct 14 13:42:00 <dos1> Heinervdm: after clenaning, libgee works
Oct 14 13:42:06 <dos1> i'll do the same to others ;)
Oct 14 13:42:30 <JaMa> Heinervdm: thats why i put 7.5.1 as preferred before (I know it says that it doesn't exist later..., but behaves as with removed preferred)
Oct 14 13:42:43 <Heinervdm> dos1: for matchbox-panel clean the svn dir in downloads too
Oct 14 13:42:48 <Weiss> JaMa: cool.. and you get (unaccelerated) 3D with the non-DRM kernel?
Oct 14 13:42:49 <dos1> ok
Oct 14 13:43:28 <Heinervdm> JaMa: should we add a PROVIDES = "mesa" to mesa-dri?
Oct 14 13:43:34 <JaMa> Weiss: tested just 2D (illume and navit maps etc) :/
Oct 14 13:43:48 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * rd638a04abec1 10/libfsotransport/fsotransport/ (Makefile.am parser.vala): libfsotransport: add generic Parser class (from fsogsmd)
Oct 14 13:44:26 <JaMa> Heinervdm: hmm PROVIDES = "virtual/libgl" from mesa-common.inc
Oct 14 13:44:39 <JaMa> Heinervdm: maybe virtual/libgl is set somewhere?
Oct 14 13:44:49 <Heinervdm> JaMa: yes it is
Oct 14 13:46:02 <JaMa> Heinervdm: to mesa?
Oct 14 13:46:15 <Heinervdm> JaMa: can't find it now :)
Oct 14 13:47:06 <mrmoku> mickey|office, playya: hmm... looks like I'm plain stupid... my test case works with current fsousaged
Oct 14 13:47:20 <JaMa> Heinervdm: I haven't found PROVIDES = "mesa
Oct 14 13:47:21 <mrmoku> verifying with ophonekitd now... and sorry for wasting your time :(
Oct 14 13:47:29 <JaMa> Heinervdm: in shr/merge or shr/import :/
Oct 14 13:47:30 <mrmoku> will book it as marshalling learning session then :P
Oct 14 13:48:16 <Weiss> JaMa: hmm.. I suspect 3D (e.g. running LIBGL_DEBUG=verbose glxinfo) won't work..
Oct 14 13:48:41 <Heinervdm> JaMa: http://shr.pastebin.com/m24154a31
Oct 14 13:48:53 <JaMa> Weiss: SHR root@gojama ~ $ LIBGL_DEBUG=verbose glxinfo
Oct 14 13:48:53 <JaMa> name of display: :0.0
Oct 14 13:48:53 <JaMa> libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
Oct 14 13:48:53 <JaMa> display: :0  screen: 0
Oct 14 13:49:13 <JaMa> OpenGL version string: 2.1 Mesa 7.7-devel
Oct 14 13:49:15 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r1e0da4c1dacf 10/fsogsmd/ (5 files in 2 dirs): fsogsmd: catch up with parser moving to libfsotransport
Oct 14 13:49:22 <mickey|office> mrmoku: well, glad to hear.
Oct 14 13:50:19 <Weiss> JaMa: interesting.. could you pastebin the whole output?
Oct 14 13:51:10 <Weiss> JaMa: also Xorg.0.log
Oct 14 13:51:16 <JaMa> Weiss: http://pastebin.ca/1619392
Oct 14 13:52:14 <JaMa> Weiss: http://pastebin.ca/1619394
Oct 14 13:53:51 <Heinervdm> JaMa: seen my pastebin?
Oct 14 13:54:04 <Weiss> JaMa: interesting. seems there's some magic that makes swrast_dri.so get used even though the DDX isn't DRI aware. that's a Useful thing...
Oct 14 13:54:23 <Weiss> JaMa: does glxgears work? (you'll get about 2 fps)
Oct 14 13:55:16 <JaMa> Weiss: I can't see it but I get 27 frames in 5.2 seconds =  5.242 FPS
Oct 14 13:55:32 <Weiss> can't see it?
Oct 14 13:55:44 <JaMa> because I'm at work and neo is at home..
Oct 14 13:55:49 <Weiss> ah, ok
Oct 14 13:56:15 <JaMa> ah but in this image i have kms DDX
Oct 14 13:56:22 <JaMa> just kernel is non-drm
Oct 14 13:56:51 <JaMa> I switched to non-drm kernel because of that WSODs I have
Oct 14 13:57:01 <Weiss> that's OK - the KMS DDX is essentially two drivers, with a choice between the two made very early on. no KMS->no DRI2 initialisation
Oct 14 13:58:07 <JaMa> Heinervdm: seen but do you have all deps build? or did you just used -b ..mesa-dri_git?
Oct 14 13:58:26 <Heinervdm> JaMa: all deps built
Oct 14 14:01:44 <JaMa> Heinervdm: my old tmpdir says mesa-dri-1_7.5.1+gitr0+5a3f2c987a134f8079206a0b9529993a85dd6d4a-r1.do_build
Oct 14 14:02:02 <JaMa> its even the same revision as you have
Oct 14 14:02:23 <Heinervdm> then a dep is missing...
Oct 14 14:02:30 <JaMa> Heinervdm: libdrm builded ok?
Oct 14 14:02:44 <JaMa> Heinervdm: I needed newer libpthreads for that
Oct 14 14:02:55 <Heinervdm> JaMa: i think so, will look for it
Oct 14 14:03:01 <JaMa> Weiss: what about that libdrm rebase?
Oct 14 14:04:35 <Weiss> JaMa: is a merge with upstream OK?
Oct 14 14:05:18 <JaMa> builds ok.. but cannot test it now
Oct 14 14:05:50 <Weiss> I can't remember if you mentioned or not.. did you rebase against master, or modesetting-gem, or something else?
Oct 14 14:07:14 <JaMa> master
Oct 14 14:08:20 <Weiss> ah, that's probably why your rebase generated so many conflicts
Oct 14 14:08:42 <Weiss> great news that everything builds properly with my stuff on top of master, though - that wasn't the case previously
Oct 14 14:08:50 <Weiss> (even KMS works?)
Oct 14 14:09:36 <JaMa> I hope to test it tonight..  if image builds ok now..
Oct 14 14:10:01 <JaMa> I broke all my builddirs with building both angstrom and shr in same directory :/
Oct 14 14:10:06 <Weiss> ok, great
Oct 14 14:10:32 <Weiss> I was using modesetting-gem before because it was needed for a smooth build with GEM+KMS ("obviously")
Oct 14 14:12:00 <JaMa> nothing new in modesetting-gem for last 6 months.. so hopefully everything usefull is alredy merged to master
Oct 14 14:12:15 <JaMa> nouveau KMS works too with master
Oct 14 14:13:39 <Weiss> yeah
Oct 14 14:14:09 <Weiss> let me know if it works, and if so then I'll spin a fresh branch built on master (probably exactly the same as your branch)
Oct 14 14:14:18 <Weiss> (or I could just use your branch)
Oct 14 14:16:40 <JaMa> you could just apply that patch from OE repo on fresh branch to have whole history of commits
Oct 14 14:17:22 <JaMa> do you want me to test something specific? or just boot drm kernel and KMS.. output of glxinfo?
Oct 14 14:19:48 <Heinervdm> JaMa: what's right libdrm version?
Oct 14 14:20:35 <JaMa> Heinervdm: libdrm-2.4.15+gitr1+fc8f6be5a9bd84e10149770b76ff9353d25ce2a7-r0
Oct 14 14:20:42 <JaMa> Heinervdm: from libdrm_git
Oct 14 14:21:45 <Weiss> JaMa: if Xorg.0.log says "Using KMS" and you get a (correct) picture on the screen, and if glxinfo says it's using Mesa-DRI Glamo, and glxdemo works, then everything's good
Oct 14 14:22:27 <Heinervdm> JaMa: ok, i had 2.4.11
Oct 14 14:24:07 <JaMa> Heinervdm: hmm I left SRCPV in shr/merge and it looks like working
Oct 14 14:24:14 <JaMa> Heinervdm: its in that libdrm_git.bb
Oct 14 14:24:25 <Heinervdm> SRCPV is working
Oct 14 14:24:38 <Heinervdm> because SRCPV is definied in shr.conf
Oct 14 14:24:57 <Heinervdm> but we can't with that we can't merge back
Oct 14 14:25:00 <JaMa> Heinervdm: ah so just for shared packages its not possible to use?
Oct 14 14:25:28 <Heinervdm> JaMa: i think we wan't to merge everthing to org.oe.dev?
Oct 14 14:25:43 <JaMa> Heinervdm: but I'm building angstrom with that (not this package exactly but its parsed too) and it works
Oct 14 14:26:05 <Heinervdm> hmm
Oct 14 14:26:29 <JaMa> XorA has whole branch for srcpv.. so maybe its enabled in angstrom too now
Oct 14 14:26:32 <Heinervdm> i think we have to ask in #oe about that
Oct 14 14:26:51 <JaMa> http://cgit.openembedded.net/cgit.cgi/openembedded/log/?h=xora/angstrom-srcpv
Oct 14 14:27:23 <JaMa> ok
Oct 14 14:27:55 <Heinervdm> libdrm faild: SRCREV: 3a387a983ec40cd443e22c1f8d9a6b5b5a8fa0d1
Oct 14 14:30:52 <JaMa> Heinervdm: log?
Oct 14 14:31:27 <JaMa> patch didn't apply after fc8f6be5a9bd84e10149770b76ff9353d25ce2a7 i guess
Oct 14 14:31:40 <Heinervdm> http://shr.pastebin.com/m3db2c9d6
Oct 14 14:32:07 <Heinervdm> do you build from freedesktop or from Weiss git?
Oct 14 14:33:34 <JaMa> Heinervdm: from freedesktop and Weiss's glamo patch applied on top
Oct 14 14:33:44 <JaMa> Heinervdm: try to add --disable-intel
Oct 14 14:39:28 <JaMa> Heinervdm: please look at #oe (/me and XorD) it looks like SRCPV could be used after merge
Oct 14 14:41:48 <Heinervdm> hmm i'm too late, i think ;)
Oct 14 14:42:07 <JaMa> Heinervdm: http://shr.pastebin.ca/1619528 first part
Oct 14 14:44:34 * mrmoku needs to read about PE .....
Oct 14 14:46:44 <z0mgs> hi people where can i find information about the paroli messages data format?
Oct 14 14:47:08 <larsc> z0mgs: paroli source code ;)
Oct 14 14:47:21 <z0mgs> great where is it?
Oct 14 14:47:23 <z0mgs> ;)
Oct 14 14:47:47 <larsc> on your neo
Oct 14 14:47:55 <larsc> if you have paroli installe
Oct 14 14:47:56 <larsc> d
Oct 14 14:48:14 <z0mgs> is it written in an interpreted lang?
Oct 14 14:48:19 <larsc> python
Oct 14 14:48:24 <z0mgs> ah i see
Oct 14 14:48:25 <z0mgs> great
Oct 14 14:48:43 <Heinervdm> JaMa: --disable-intel works
Oct 14 14:49:03 <Heinervdm> JaMa: shouldn't we disable everything expect glamo?
Oct 14 14:51:47 <Heinervdm> JaMa: ok, that's already everything :)
Oct 14 14:52:51 <JaMa> Heinervdm: --enable-nouveau-experimental-api --enable-radeon-experimental-api are disabled by default
Oct 14 14:53:07 <JaMa> Heinervdm: I've add --enable-glamo-experimental-api and enabled it for glamo
Oct 14 14:53:34 <JaMa> Heinervdm: just forget to --disable-intel for glamo as its defined somewhere else in configure.ac :)
Oct 14 14:54:06 <JaMa> by somewhere else I mean I didn't have it in my diff :)
Oct 14 14:55:06 <JaMa> Heinervdm: but it build successfully even with intel for me (maybe it was disabled automaticaly in configure or its just problem with newer toolchain you have)
Oct 14 14:55:25 <Heinervdm> JaMa: now it builds
Oct 14 14:55:32 <Heinervdm> sent a patch for that
Oct 14 14:55:41 <JaMa> Heinervdm: btw what's the change you did to openssl-native that it builds for you?
Oct 14 14:55:58 <Heinervdm> JaMa: good question
Oct 14 14:56:06 <Heinervdm> that's so long ago :)
Oct 14 14:56:28 <Heinervdm> but current shr/merge should build it
Oct 14 14:56:31 <JaMa> Heinervdm: It still fails for me and now even older openssl-native-0.9.8g fails for me in shr/import
Oct 14 14:57:28 <JaMa> Heinervdm: it ends with md5-x86_64.s: Assembler messages:
Oct 14 14:57:28 <JaMa> md5-x86_64.s:41: Error: 0xd76aa478 out range of signed 32bit displacement
Oct 14 14:57:39 <JaMa> I guess its other error than before
Oct 14 14:57:46 <JaMa> and this one is on clean builddir again :/
Oct 14 14:58:28 <Heinervdm> hmm, i think i solved it by updating some other packages
Oct 14 14:58:43 <JaMa> and newer libxft-1_2.1.14 fails too :/
Oct 14 14:59:28 <JaMa> any autoconf guru here?
Oct 14 14:59:49 <JaMa> a bit expirienced autoconf user should be enough :)
Oct 14 15:09:40 <Heinervdm> i can't get shr-image to build mesa-dri instead of mesa
Oct 14 15:12:03 <Weiss> JaMa: I'm a little bit experienced..
Oct 14 15:12:15 <Weiss> but I'm probably going to have no idea about your problem..
Oct 14 15:13:22 <JaMa> Heinervdm: try to add provider for that virtual/libgl too
Oct 14 15:13:34 <JaMa> Heinervdm: not provider but preferred_provider I mean
Oct 14 15:14:50 <Heinervdm> JaMa: i've done that already
Oct 14 15:14:53 <JaMa> Weiss: its about this change http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=dac73a51981632908ce86cff26af5b0bcfcdd770
Oct 14 15:15:28 <JaMa> Weiss: its replaced while creating Xft.h from Xft.h.in on my host, but not when build from bitbake
Oct 14 15:16:28 <JaMa> Weiss: I tried to use aclocal.m4 from host (newer autoconf/automake), but its the same
Oct 14 15:17:30 <Weiss> the substitution of XFT_MAJOR etc. doesn't happen, you mean?
Oct 14 15:18:57 <JaMa> Weiss: Xft.h looks the same after ./configure
Oct 14 15:19:34 <Weiss> Xft.h shouldn't exist at all before that, I think..?
Oct 14 15:20:31 <JaMa> yes.. its created by ./configure but without that replace
Oct 14 15:20:45 <JaMa> Heinervdm: this ^^^ didn't happen to you?
Oct 14 15:21:08 <Heinervdm> JaMa: no, it compiles fine
Oct 14 15:21:23 <Weiss> does the configure script exist in the source (as checked out)?
Oct 14 15:21:46 <JaMa> Weiss: no its created from configure.ac
Oct 14 15:21:56 <dos1> Heinervdm: with applied everything from patchwork
Oct 14 15:21:57 <dos1> Heinervdm: NOTE: Running task 3756 of 6583 (ID: 4812, /home/shr/shr-oemerge/openembedded/recipes/mesa/mesa_7.0.2.bb, do_package)
Oct 14 15:22:11 <Heinervdm> dos1:  yes, that's the problem
Oct 14 15:22:25 <JaMa> Weiss: ah sorry, it exists from tarball
Oct 14 15:22:31 <Heinervdm> dos1: can't figure out how to preferre mesa-gir_git
Oct 14 15:24:29 <Weiss> JaMa: is there an autogen.sh? if so, try making BB run that before doing any configuration. alternatively, "autoreconf" should do the same thing. maybe the configure script in the tarball is out of date..
Oct 14 15:27:05 <JaMa> Weiss: configure script is regenerated by bitbake but then doesn't work, configure script from tarball is ok
Oct 14 15:28:17 <JaMa> Weiss: and recipe just have inherit autotools pkgconfig
Oct 14 15:29:41 <JaMa> Weiss: here is log what it did http://pastebin.ca/1619673
Oct 14 15:29:47 <playya_> afaik bb deletes autogen.sh and uses autoreconf -v --install
Oct 14 15:30:48 <Weiss> even if configure already exists?
Oct 14 15:31:24 <playya_> look into run.do_configure in your tem dir
Oct 14 15:31:30 <playya_> tempdir
Oct 14 15:33:38 <JaMa> its shown in that log.do_configure too
Oct 14 15:37:02 * JaMa si finally going home.. bbl
Oct 14 15:46:13 <TAsn> mrmoku, sup?
Oct 14 15:47:27 <TAsn> Heinervdm, JaMa: anything new concerning the huge resume time?
Oct 14 15:47:39 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * re5b50df81947 10/ (9 files in 4 dirs): libfsotransport: commandqueue moves to here, comes from fsogsmd
Oct 14 15:47:47 <Heinervdm> TAsn: we have no new image to test :)
Oct 14 15:48:06 <TAsn> Heinervdm, so you maybe fixed it?
Oct 14 15:48:15 <TAsn> just issue a 
Oct 14 15:48:18 <TAsn> dos1, build
Oct 14 15:48:20 <TAsn> command :)
Oct 14 15:48:28 <TAsn> (dos1: j/k)
Oct 14 15:48:43 <Heinervdm> TAsn: no, but we updated some things :)
Oct 14 15:48:49 <dos1> NOTE: Tasks Summary: Attempted 6453 tasks of which 6355 didn't need to be rerun and 2 failed.
Oct 14 15:48:50 <dos1> ERROR: '/home/shr/shr-oemerge/openembedded/recipes/mesa/mesa_7.0.2.bb' failed
Oct 14 15:48:52 <dos1> ERROR: '/home/shr/shr-oemerge/openembedded/recipes/freesmartphone/libfsobasics_git.bb' failed
Oct 14 15:49:23 <playya_> dos1, do you have vala installed on your host?
Oct 14 15:49:40 <dos1> it's buildhost
Oct 14 15:49:42 <dos1> and i don't think so
Oct 14 15:49:45 <playya_> it's a configure error?
Oct 14 15:49:51 <dos1> dunno, checking it now
Oct 14 15:50:18 <playya_> i think it is missing linux.vapi and posixextra.vapi
Oct 14 15:51:00 <mrmoku> TAsn: foobar
Oct 14 15:51:10 <dos1> playya_: missing linux.vapi and posixextra.vapi was when vala (not vala-native) was staged in oe
Oct 14 15:51:16 <dos1> playya_: cleaning vala were fixing that
Oct 14 15:51:28 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r885f3b0859c6 10/libfsotransport/tests/ (Makefile.am testcommandqueue.vala): libfsotransport: add test for command queue
Oct 14 15:51:29 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * rf2fb7f79434a 10/fsogsmd/ (4 files in 2 dirs): fsogsmd: catch up with commandqueue moving to libfsotransport
Oct 14 15:51:34 <TAsn> mrmoku, I meant about ophonekitd :)
Oct 14 15:51:53 <dos1> configure: error: Couldn't find sys/eventfd.h... your glibc is too old :( 
Oct 14 15:51:58 <dos1> Heinervdm: ^^^^^^
Oct 14 15:52:04 <dos1> that's in libfsobasics
Oct 14 15:52:20 <Heinervdm> then, you're not up to date
Oct 14 15:52:25 <playya_> you are using glib 2.7?
Oct 14 15:52:43 <playya_> s/glib/glibc/
Oct 14 15:52:43 <apt> playya_ meant: you are using glibc 2.7?
Oct 14 15:52:58 <Heinervdm> dos1: i've updated glibc to 2.7 in shr/merge
Oct 14 15:53:01 <dos1> Heinervdm: git says different thing
Oct 14 15:53:02 <dos1> Already up-to-date.
Oct 14 15:53:02 <mrmoku> TAsn: me too ;)
Oct 14 15:53:04 <dos1> :P
Oct 14 15:53:09 <TAsn> mrmoku, :|
Oct 14 15:53:15 <mrmoku> TAsn: what do we do about logging?
Oct 14 15:53:23 <TAsn> mrmoku, what do you mean by logging?
Oct 14 15:53:25 <mrmoku> right now ophonekitd just outputs to stdout
Oct 14 15:53:31 <TAsn> oh
Oct 14 15:53:37 <TAsn> that's good enough in the meanwhile.
Oct 14 15:53:41 <mickey|office> sorry, you need 2.9
Oct 14 15:53:44 <mrmoku> and the output is piped to /var/log/frameworkd.conf on startup in xsession script
Oct 14 15:53:47 <mrmoku> (IIRC)
Oct 14 15:53:49 <mrmoku> TAsn: no it is not
Oct 14 15:53:56 <TAsn> mrmoku, bah, ok :)
Oct 14 15:54:06 <mrmoku> it works for ophonekitd but not for phoneuid
Oct 14 15:54:14 <TAsn> oh right
Oct 14 15:54:15 <mrmoku> which is supposed to be started via dbus activation
Oct 14 15:54:18 <TAsn> as for phoneuid
Oct 14 15:54:19 <dos1> Heinervdm: you see?
Oct 14 15:54:26 <TAsn> we should have a config option
Oct 14 15:54:29 <TAsn> a default value
Oct 14 15:54:33 <TAsn> *and a default value
Oct 14 15:54:38 <Heinervdm> http://cgit.openembedded.net/cgit.cgi/openembedded/tree/conf/distro/include/preferred-shr-versions.inc?h=shr/merge&id=1b46c5e05387f1adde984c7edd5fec611d08baa2 glibc = 2.7
Oct 14 15:54:51 <TAsn> and should probably make a logging handler
Oct 14 15:54:52 <TAsn> mrmoku, 
Oct 14 15:54:59 <TAsn> write a filler
Oct 14 15:55:01 <Heinervdm> mickey|office: that's a problem
Oct 14 15:55:09 <TAsn> oh wait, it's harder than that.
Oct 14 15:55:10 <TAsn> :|
Oct 14 15:55:17 <Heinervdm> mickey|office: glibc 2.9 says our kernel is to old
Oct 14 15:55:20 <TAsn> as the lib writes as well.
Oct 14 15:55:21 <TAsn> hm..
Oct 14 15:55:34 <mickey|office> Heinervdm: strange, that worked for me in oe.dev
Oct 14 15:55:40 <mrmoku> all via glib logging though
Oct 14 15:55:46 <Heinervdm> mickey|office: with shr kernel?
Oct 14 15:55:50 <mrmoku> so we can set a default handler, no?
Oct 14 15:55:51 <Heinervdm> latest andy-tracking?
Oct 14 15:55:51 <TAsn> mrmoku, we should probably pipe stdout
Oct 14 15:55:53 <TAsn> and stderr
Oct 14 15:56:06 <TAsn> (from the daemon)
Oct 14 15:56:08 <mrmoku> se can't for startup via dbus-activation
Oct 14 15:56:09 <mickey|office> Heinervdm: some andy-tracking i suppose
Oct 14 15:56:12 <mrmoku> s/se/we/
Oct 14 15:56:13 <apt> mrmoku meant: we can't for startup via dbus-activation
Oct 14 15:56:17 <TAsn> mrmoku, from the daemon...
Oct 14 15:56:27 <Heinervdm> mickey|office: hmm, then i will try again
Oct 14 15:56:39 <TAsn> but I wonder
Oct 14 15:56:41 <TAsn> maybe g_lib
Oct 14 15:56:45 <mickey|office> 2.6.29 should be fine for glibc 2.9
Oct 14 15:56:48 <TAsn> has a sane way to do it in their functions
Oct 14 15:56:56 <mrmoku> that's what I mean...
Oct 14 15:57:04 <mrmoku> g_log_set_default_handler ()
Oct 14 15:57:25 <TAsn> http://library.gnome.org/devel/glib/unstable/glib-Message-Logging.html
Oct 14 15:57:29 <TAsn> mrmoku, exactly hehe :)
Oct 14 15:57:34 <TAsn> I was looking at the same thing.
Oct 14 15:57:44 <TAsn> well, we should just implement our own logging function
Oct 14 15:57:50 <TAsn> and set it in phoneuid
Oct 14 15:57:52 <TAsn> that's good enough ;)
Oct 14 15:58:17 <mrmoku> ok
Oct 14 15:59:53 <TAsn> it's just a simple
Oct 14 15:59:55 <TAsn> fprintf
Oct 14 16:00:00 <TAsn> actually
Oct 14 16:00:02 <TAsn> fvprintf
Oct 14 16:00:28 <TAsn> mrmoku, btw
Oct 14 16:00:43 <TAsn> dos1, mrmoku please see which bugs you can handle in trac
Oct 14 16:00:49 <TAsn> and take ownership over them.
Oct 14 16:01:08 <TAsn> and the ones you can't, move your ownership
Oct 14 16:01:09 <TAsn> Ainulindale, ping.
Oct 14 16:01:24 <Ainulindale> Pong.
Oct 14 16:01:52 <TAsn> Ainulindale, what do you think about adding a "no one"
Oct 14 16:01:58 <TAsn> user that'll be the default for
Oct 14 16:02:10 <Ainulindale> I think that's dumb :-)
Oct 14 16:02:12 <TAsn> phonegui, ophonekitd, libframe and etc?
Oct 14 16:02:18 <Ainulindale> Tickets should be assigned to someone
Oct 14 16:02:24 <Ainulindale> If that someone isn't appropriate
Oct 14 16:02:31 <Ainulindale> Then he/she should reassign
Oct 14 16:02:42 <Ainulindale> Else nobody sees the tickets and that's bad
Oct 14 16:03:15 <playya_> TAsn, mrmoku, you can close stdout and stderr and use a different file for it
Oct 14 16:03:16 <TAsn> Ainulindale, but this way
Oct 14 16:03:17 <TAsn> I can't tell
Oct 14 16:03:17 <TAsn> when reviewing the list
Oct 14 16:03:17 <TAsn> actually never
Oct 14 16:03:17 <TAsn> mind
Oct 14 16:03:19 <TAsn> there's the accepted status
Oct 14 16:03:21 * TAsn is an idiot.
Oct 14 16:03:23 <TAsn> Ainulindale, go back to sleep. :)
Oct 14 16:03:27 <TAsn> Ainulindale, do you review your tickets?
Oct 14 16:03:29 <TAsn> does spaetz reviews his?
Oct 14 16:03:34 <TAsn> playya_, yeah, that's what I said
Oct 14 16:03:40 <TAsn> but using the glib handler is better.
Oct 14 16:03:51 <TAsn> <TAsn> mrmoku, we should probably pipe stdout
Oct 14 16:03:51 <TAsn> <Heinervdm> latest andy-tracking?
Oct 14 16:03:51 <TAsn> <TAsn> and stderr
Oct 14 16:03:51 <TAsn> <TAsn> (from the daemon)
Oct 14 16:03:55 <TAsn> playya_, that's what I meant ^
Oct 14 16:03:58 <Ainulindale> TAsn: I didn't review anything for two or three months
Oct 14 16:04:05 <Ainulindale> (I know I'm a bad boy)
Oct 14 16:04:07 <TAsn> Ainulindale, hehe, thought so :)
Oct 14 16:04:13 <TAsn> you are not the only one btw.
Oct 14 16:04:21 <Ainulindale> Well the problem is I should do it
Oct 14 16:04:30 <playya_> and you can pipe it, if you wrap  your daemon into a script
Oct 14 16:04:31 <Ainulindale> I lack of time and willingness these days
Oct 14 16:04:43 <TAsn> playya_, the second one is also a cool idea.
Oct 14 16:05:05 <TAsn> but closing and reopening is what I thought is right, before I thought about the glib way of doing it
Oct 14 16:05:14 <TAsn> which is the most correct in my opinion.
Oct 14 16:05:19 <mrmoku> playya_: that would work with dbus-activation as well?
Oct 14 16:05:33 <CIA-26> freesmartphone.org: 03mickey 07libeflvala * r5ef80503aaaa 10/vapi/elm.vapi: elm.vapi: catch up with Photocam API as per upstream rev 43072
Oct 14 16:05:42 <playya_> i think both should work
Oct 14 16:05:54 <mrmoku> oohh... that would be something fast to try out :)
Oct 14 16:05:57 <mrmoku> good
Oct 14 16:06:44 <TAsn> mrmoku, NOO
Oct 14 16:06:48 <TAsn> just reimplement the glib function
Oct 14 16:06:49 <TAsn> please.
Oct 14 16:06:54 <TAsn> please please please
Oct 14 16:06:56 <TAsn> or at least
Oct 14 16:07:04 <TAsn> fclose(stderr)
Oct 14 16:07:06 <Heinervdm>  * ERROR: Cannot satisfy the following dependencies for task-x11-illume: *  libdrm2 (>= 2.4.11) *  libdrm2 (>= 2.4.11) *
Oct 14 16:07:10 <TAsn> stderr = fopen...
Oct 14 16:07:14 <Heinervdm> but nothing depends on libdrm2
Oct 14 16:07:47 <dos1> ERROR: Unable to parse conf/bitbake.conf (Could not include required file conf/distro/include/glibc-${TOOLCHAIN_TYPE}.inc)
Oct 14 16:08:01 <dos1> i have shr/merge merged with org.oe.dev
Oct 14 16:08:02 <dos1> ;x
Oct 14 16:08:36 <playya_> i get a compile error for imagemagick with shr/merge
Oct 14 16:10:35 <TAsn> Ainulindale, mrmoku dos1: are you fine with me announcing the results of the logo contest right now and not waiting for a quorum? We already have 4 votes in favor of announcing which is more than enough, and we can't wait forever, especially since it's such a small matter. btw please reply to my second mail in shr-core (you asses)
Oct 14 16:11:01 <Ainulindale> Yeap I'm fine with it :-)
Oct 14 16:12:35 <TAsn> cool, I'm taking your call as a veto.
Oct 14 16:12:36 <TAsn> :)
Oct 14 16:12:51 * TAsn is going to write an announcement mail.
Oct 14 16:15:52 <TAsn> dos1, please rebuild phone_utils, phonegui and efl2 in mrmok/tests
Oct 14 16:16:36 <Heinervdm> configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails sanity check
Oct 14 16:37:58 * mrmoku dinner
Oct 14 17:04:31 <Blu3> PaulFertser i take it back.  my SD card is now showing signs of filesystem instability even without doing GSM things.  i noticed a spot of solder across a couple pins of the SD card, it looks like an intentional bridge but i'm not sure.  (to anyone) is there supposed to be a solder bridge on two of the SD socket pins?
Oct 14 17:08:42 <johnsu01> Blu3: yes
Oct 14 17:09:23 <Blu3> ok
Oct 14 17:11:25 <JaMa> ahh I'm not alone with libxft problem, shr-unstable builder from shr/import has same issue (autoconf stuff) http://tinderbox.openembedded.net/public/logs/task/3218137.txt
Oct 14 17:12:50 <dos1> ERROR: '/home/shr/shr-unstable/openembedded/recipes/xorg-lib/libxft_2.1.14.bb' failed
Oct 14 17:12:56 <dos1> yup, it's on our buildhost
Oct 14 17:13:04 <DocScrutinizer-8> Blu3: on sd card, or on holder?
Oct 14 17:13:16 <DocScrutinizer-8> johnsu01: yes???
Oct 14 17:13:19 <Blu3> i have both libXft 2.1.13 and 2.1.14 compiled fine w/ gentoo
Oct 14 17:13:26 <Blu3> on the holder
Oct 14 17:13:56 <johnsu01> (assumed Blu3 meant on the holder)
Oct 14 17:14:02 <Blu3> aye
Oct 14 17:14:17 <DocScrutinizer-8> on the holder there might be a 0402 capacitor, which doesn't look like solder
Oct 14 17:16:46 <johnsu01> looks kind of like solder to me :)
Oct 14 17:17:12 <JaMa> Blu3: me too on gentoo :)
Oct 14 17:17:35 <JaMa> dos1: I have nasty hack to make it compile... its probably because of older autoconf we have
Oct 14 17:17:36 <DocScrutinizer-8> and to me looks like a pair of ants doing nasty things ;-p
Oct 14 17:18:53 <DocScrutinizer-8> johnsu01: solder is supposed to be silver. The C is brown (and right-angled btw, while solder always is round)
Oct 14 17:19:20 <DocScrutinizer-8> roundish at least
Oct 14 17:19:31 <Blu3> doc, definitely not a cap.  definitely a blob of solder
Oct 14 17:19:39 <johnsu01> http://wiki.openmoko.org/wiki/Image:SOP_for_GPS_capacitor_rework.pdf 
Oct 14 17:19:55 <johnsu01> looks like what I've seen in several phones
Oct 14 17:20:03 <Blu3> JaMa, no hacks for me on libXft, straight out of portage
Oct 14 17:20:19 <DocScrutinizer-8> Blu3: that's BAAAD then
Oct 14 17:22:10 <JaMa> Blu3: I know.. here to (on gentoo) but we have older autoconf in bitbake...
Oct 14 17:22:28 <DocScrutinizer-8> Blu3: try to remove it with a wooden toothpick
Oct 14 17:22:32 <Blu3> maybe the cap itself is bridged.  it's square but entirely shiny.  i'll order another 10pF and solder it into place.
Oct 14 17:22:36 <JaMa> Blu3: it works without hacks also in different branch (ie shr/merge is ok)
Oct 14 17:22:38 <Blu3> or mostly bridged
Oct 14 17:22:59 <Blu3> i don't use bitbake.  just cross-armv4l-....-* toolchain
Oct 14 17:23:22 <DocScrutinizer-8> Blu3: can you send a photo?
Oct 14 17:23:26 <JaMa> to much work to build whole shr-image by hand :)
Oct 14 17:23:37 <JaMa> s/^to/too/
Oct 14 17:23:47 <Blu3> not at the moment, i don't have it w/ me.  i'll try this afternoon
Oct 14 17:23:57 <DocScrutinizer-8> k
Oct 14 17:24:27 <Blu3> jama, i wanted to do it by hand to make up -better- instructions on what needed to be done
Oct 14 17:24:53 <Blu3> too much vagueness and lack of documentation/stale documentation
Oct 14 17:26:56 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r38700af42ca9 10/src/ (util/helper.c view/contact-show-view.c): added a debug message
Oct 14 17:50:35 <JaMa> Heinervdm: PROVIDES = "mesa" solved preferred version, I have no idea how it worked before without it..
Oct 14 17:51:05 <Heinervdm> JaMa: i tried that, and it didn't worked for me...
Oct 14 17:51:24 <Heinervdm> but building now from scratch to search for buildproblems
Oct 14 17:51:45 <Heinervdm> our autotools version isn't that old btw
Oct 14 17:52:44 <Heinervdm> we have autoconf 2.63 and automake 1.10.2
Oct 14 17:55:10 <JaMa> in shr/merge
Oct 14 17:55:18 <JaMa> the problem is in shr/import
Oct 14 17:55:41 <TAsn> dos1, here?
Oct 14 17:55:44 <Heinervdm> JaMa: ok
Oct 14 17:55:50 <JaMa> where is 2.61 and 1.9.6
Oct 14 17:56:08 <Heinervdm> can't we update it in shr/import too?
Oct 14 17:56:21 <Heinervdm> i had no issues after updating
Oct 14 17:56:45 <Heinervdm> and i build nearly the complete feed
Oct 14 17:57:34 <JaMa> I tried it before (adding autoconf/automake versions from oe.dev and updating versions in preferred..) but it failed on lots of packages
Oct 14 17:57:53 <JaMa> probably because I should also upgrade m4 etc
Oct 14 17:58:05 <JaMa> and then rebuild builddir
Oct 14 17:58:20 <CIA-26> SHR: 03tom 07libphone-utils * rad4604111320 10/src/ (phone-utils-gsm.c phone-utils-gsm.h): added documentation for all the functions corrosponding to this header
Oct 14 17:58:21 <CIA-26> SHR: 03tom 07libphone-utils * rc01e1c0c7868 10/src/ (phone-utils.c phone-utils.h.in str-utils.h): added documentation for all the functions in phone-utils.h
Oct 14 17:58:41 <TAsn> Heinervdm, any leads concerning Xorg resume issue? (I had to go in the middle of the discussion yesterday)
Oct 14 18:00:24 <Heinervdm> TAsn: larsc uses an older Xorg and Weiss uses another kernel and mesa-dri
Oct 14 18:00:34 <Heinervdm> so we try mesa-dri first
Oct 14 18:00:52 <Heinervdm> and then i will try drm-tracking kernel instead of andy-tracking
Oct 14 18:01:12 <TAsn> cool
Oct 14 18:01:15 <TAsn> ;)))
Oct 14 18:02:22 <Heinervdm> if that doesn't help we have do to more research :)
Oct 14 18:02:34 <JaMa> last 2 :)
Oct 14 18:02:35 <JaMa> ERROR: '/home/projects/OE/shr/recipes/openssl/openssl-native_0.9.8j.bb' failed
Oct 14 18:02:38 <JaMa> ERROR: '/home/projects/OE/shr/recipes/pango/pango_1.22.0.bb' failed
Oct 14 18:03:05 <Heinervdm> merge or import?
Oct 14 18:03:05 <JaMa> Heinervdm: resume here is quite fast.. so including shr-om-gta02-kms should be enough :)
Oct 14 18:03:09 <JaMa> import
Oct 14 18:03:38 <Heinervdm> i think  i updated sth to get openssl-native compile...
Oct 14 18:03:52 <JaMa> Heinervdm: merge is way back here Running task 1220 of 8909
Oct 14 18:04:20 <Heinervdm> NOTE: Running task 489 of 7612
Oct 14 18:04:22 <Heinervdm> :)
Oct 14 18:04:22 <JaMa> Heinervdm: but first I've seen other issue in openssl-native now it complains about assembler code..
Oct 14 18:06:48 <Heinervdm> JaMa: i think the glibc bump solved the openssl issue...
Oct 14 18:14:32 <DocScrutinizer-8> what's state of testing?
Oct 14 18:14:38 * DocScrutinizer-8 ducks
Oct 14 18:15:54 <CIA-26> SHR: 03tom 07shr * r3aae3a02a971 10/libframeworkd-phonegui/ (3 files in 2 dirs): added phongeui contact delete
Oct 14 18:16:04 <CIA-26> SHR: 03tom 07shr * r3a5f9326335d 10/libframeworkd-phonegui/src/ (frameworkd-phonegui-utility.c frameworkd-phonegui-utility.h): added phonegui_call_send_dtmf
Oct 14 18:19:00 <Heinervdm> Found the solution for the kernel too old Error :)
Oct 14 18:19:50 <Heinervdm> We have to set OLDEST_KERNEL
Oct 14 18:20:09 <Heinervdm> Should we set it to 2.6.29, or some older version?
Oct 14 18:20:42 <DocScrutinizer-8> TAsn: (...send_DTMF) you know how to handle 12345w0p9p8  ?
Oct 14 18:20:53 <CIA-26> SHR: 03tom 07shr * r3c281b6e4c5d 10/libframeworkd-phonegui/src/ (frameworkd-phonegui-utility.c frameworkd-phonegui-utility.h): added phonegui_network_send_ussd_request
Oct 14 18:20:54 <TAsn> DocScrutinizer, no
Oct 14 18:20:57 <TAsn> it's just a wrapper
Oct 14 18:21:00 <TAsn> to the fso call
Oct 14 18:21:01 <Heinervdm> What's the oldes kernel used in SHR?
Oct 14 18:21:10 <TAsn> it's just to let the backend writers
Oct 14 18:21:16 <TAsn> and easier programming framework
Oct 14 18:21:21 <TAsn> *an
Oct 14 18:21:36 <DocScrutinizer-8> TAsn: w waits for "call establisched", the rest is sent as DTMF
Oct 14 18:21:57 <TAsn> DocScrutinizer, well, as I said, it's frameworks job :)
Oct 14 18:22:22 <DocScrutinizer-8> I don't think so, but actually that's debatable
Oct 14 18:22:27 <dos1> tests/mrmoku/oemerge feed is there
Oct 14 18:23:17 <DocScrutinizer-8> TAsn: I have to confess I never tested if modem itself maybe handles that
Oct 14 18:23:46 <TAsn> DocScrutinizer-8, I don't know if it's their job
Oct 14 18:23:49 <TAsn> but they do it
Oct 14 18:23:51 <TAsn> and that's a fact ;)
Oct 14 18:23:53 <DocScrutinizer-8> maybe it's even already implemented
Oct 14 18:24:09 <DocScrutinizer-8> :-)
Oct 14 18:25:11 <DocScrutinizer-8> bah, I can't enter "w" to dialer :-/
Oct 14 18:26:10 <mrmoku> dos1: ooohhh
Oct 14 18:26:16 <TAsn> DocScrutinizer, hehe :)
Oct 14 18:26:24 <CIA-26> SHR: 03tom 07shr * r8fc7cfc44519 10/libframeworkd-phonegui/src/ (frameworkd-phonegui-utility.c frameworkd-phonegui-utility.h): added phongeui_message_delete
Oct 14 18:26:43 <TAsn> dos1, does it work? is this the highly anticipated oe merge?
Oct 14 18:26:55 <mrmoku> no image though
Oct 14 18:27:05 <dos1> dunno if it works. i just created symlinks :P
Oct 14 18:27:16 <Heinervdm> mrmoku: we need to set OLDEST_KERNEL for glibc-2.9, i set it to 2.6.29. Is that ok?
Oct 14 18:27:17 <dos1> it's shr-oemerge, built with shr/merge branch
Oct 14 18:27:32 <mrmoku> no idea...
Oct 14 18:27:47 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r53265b741471 10/src/view/ (6 files): dropped many ogsmd stuff and strated using the phonegui_* alternatives instead
Oct 14 18:27:47 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * rd2b86aa1f293 10/src/view/ (contact-delete-view.c contact-list-view.c): strated using phonegui_contact_delete
Oct 14 18:28:01 <TAsn> anyhow
Oct 14 18:28:03 <TAsn> mrmoku, dos
Oct 14 18:28:14 <TAsn> since we already chose a logo
Oct 14 18:28:20 <TAsn> I think it's time to start using it.
Oct 14 18:28:30 <Heinervdm> mrmoku: i think glibc will not run with any older kernel then
Oct 14 18:28:31 <TAsn> dos1, mind adding it to your boot screen?
Oct 14 18:28:39 <dos1> TAsn: no
Oct 14 18:28:42 <TAsn> Heinervdm, then that's not even a question, just do it ;)
Oct 14 18:28:46 <TAsn> dos1, waiting for svg?
Oct 14 18:28:50 <dos1> TAsn: but i'll create shr-splash-theme-default with that logo :P
Oct 14 18:28:57 <TAsn> good enough :)
Oct 14 18:28:58 <dos1> TAsn: and that one will be default :P
Oct 14 18:29:02 <Heinervdm> TAsn: i sent patch already ;)
Oct 14 18:29:15 <TAsn> Heinervdm, I'm glad we think the same :)
Oct 14 18:29:20 <TAsn> dos1, cool :)
Oct 14 18:29:22 <TAsn> just a big logo
Oct 14 18:29:24 <JaMae> Heinervdm: I think you can set it to something older..
Oct 14 18:29:31 <TAsn> and a smaller shr is booting notice
Oct 14 18:29:34 <TAsn> or something like that :)
Oct 14 18:29:41 <TAsn> dos1, 
Oct 14 18:29:41 <Heinervdm> JaMae: i can, but is it needed?
Oct 14 18:29:43 * TAsn is excited :)
Oct 14 18:29:49 <TAsn> I like logos :)
Oct 14 18:30:05 <Heinervdm> JaMae: perhaps it's more optimiced like this ;)
Oct 14 18:30:53 <JaMae> Heinervdm: I know but even on optimized gentoo with glibc_2.10 I have also older kernel enabled..
Oct 14 18:31:17 <Heinervdm> JaMae: we're faster then gentoo :P
Oct 14 18:31:34 <JaMae> Heinervdm: its quite bad when someone wants to test something ie wifi driver with older kernel and glibc just says that your kernel like 2.6.26 is too old for this glibc
Oct 14 18:31:50 <JaMae> Heinervdm: I would use the same as angstrom uses :)
Oct 14 18:31:52 <DocScrutinizer-8> TAsn: opimd-contacts refuses to dial a number like 5667w1
Oct 14 18:31:57 <DocScrutinizer-8> :-(
Oct 14 18:32:09 <JaMae> Heinervdm: so update to 2.10.1 :P
Oct 14 18:32:30 <TAsn> DocScrutinizer-8, :|
Oct 14 18:32:36 <TAsn> DocScrutinizer, that's dos's fault
Oct 14 18:32:46 <TAsn> though coming to think about it
Oct 14 18:32:49 <DocScrutinizer-8> hmm, prolly
Oct 14 18:32:55 <Heinervdm> JaMae: where is 2.10.1?
Oct 14 18:33:10 <TAsn> I also restricted something like that in phone_utils (as I wrote this function for sms usage, and haven't thought about calling)
Oct 14 18:34:13 <JaMa> Heinervdm: upstream?
Oct 14 18:34:35 <Heinervdm> JaMa: but not in org.oe.dev, isn't it?
Oct 14 18:35:00 <dos1> TAsn, DocScrutinizer-8: how can it be my fault? :P
Oct 14 18:35:10 <dos1> i'm just calling FSO with InitiateCall IIRC
Oct 14 18:35:11 <TAsn> dos1, did you do any number restriction?
Oct 14 18:35:14 <JaMa> Heinervdm: no .. it was just becouse you said we're faster than gentoo :P
Oct 14 18:35:15 <dos1> TAsn: no
Oct 14 18:35:16 <TAsn> oh really?
Oct 14 18:35:20 <TAsn> than it's fso's fault :)
Oct 14 18:36:21 <Heinervdm> JaMa: but i'm too lazy for an new glibc recipe, that looks complicated ;)
Oct 14 18:36:46 <CIA-26> SHR: 03tom 07shr * r29782ca94224 10/libframeworkd-phonegui/src/frameworkd-phonegui-utility.c: added missing include and added a missing bracket
Oct 14 18:37:15 <JaMa> Heinervdm: I was just kidding.. we don't need to be so bleeding edje..
Oct 14 18:37:18 <dos1> Heinervdm: try 2.6.24
Oct 14 18:37:31 <JaMa> Heinervdm: we should save something for shr-experimental :)
Oct 14 18:37:45 <dos1> as i never saw older kernel for freerunner
Oct 14 18:37:52 <dos1> than 2.6.24 ;)
Oct 14 18:38:00 <Heinervdm> dos1: ok, after my build i will set it down to 2.6.24 :)
Oct 14 18:38:49 <TAsn> mrmoku, started using -Wall -Wextra -Werror in phone_utils :)
Oct 14 18:39:06 <TAsn> I really hate no newline at end of file warnings though.
Oct 14 18:39:06 <TAsn> :|
Oct 14 18:39:09 <cichlid> hi
Oct 14 18:39:20 <TAsn> cichlid, hello.
Oct 14 18:39:32 <cichlid> sorry what is the usb .ko module to load to get usb working ?
Oct 14 18:40:10 <TAsn> no idea.
Oct 14 18:40:11 <cichlid> (what is your output of lsmod|grep usb i meant :-)
Oct 14 18:41:54 <TAsn> cichlid, only bt stuff.
Oct 14 18:42:53 <cichlid> my usb0 doesn't show up (whatever the case) on a 2.6.29 kernel under debian
Oct 14 18:43:17 <TAsn> no idea, sorry.
Oct 14 18:43:18 <TAsn> :|
Oct 14 18:44:15 <cichlid> doesn't matter
Oct 14 18:46:53 <JaMa> gether
Oct 14 18:47:02 <JaMa> aha on host side?
Oct 14 18:47:28 <JaMa> usbnetcdc_ether               2905  0
Oct 14 18:47:29 <JaMa> usbnet                 11292  1 cdc_ether
Oct 14 18:47:57 <mrmoku> TAsn: and I hate you for not adding that newline ;)
Oct 14 18:48:10 <TAsn> hehe :)
Oct 14 18:48:14 <TAsn> here it compiles!
Oct 14 18:48:24 <TAsn> oh, you mean in general
Oct 14 18:48:33 <TAsn> what do you need em forL?
Oct 14 18:49:31 <TAsn> we should btw start using message id as an int
Oct 14 18:49:33 <TAsn> not path
Oct 14 18:49:39 <TAsn> and only parse it in function
Oct 14 18:49:45 <TAsn> (phongeui wrapper function)
Oct 14 18:49:51 <TAsn> for being really general
Oct 14 18:52:54 <mrmoku> TAsn: I need them for scrolling around while thinking :)
Oct 14 18:53:05 <TAsn> huh?
Oct 14 18:53:11 <mrmoku> TAsn: (id instead of path) not sure if that is a good thing...
Oct 14 18:53:58 <TAsn> why?
Oct 14 18:54:00 <TAsn> same thing
Oct 14 18:54:03 <TAsn> (end of path)
Oct 14 18:54:30 <mrmoku> TAsn: not sure... path is more flexible
Oct 14 18:55:09 <TAsn> but it's opimd dependant
Oct 14 18:55:13 <mrmoku> dos1: what about messages in different folders? still unique id?
Oct 14 18:55:16 <TAsn> actually current implementation of opimd dependant
Oct 14 18:55:21 <TAsn> mrmoku, yes.
Oct 14 18:55:30 <mrmoku> TAsn: what about email messages (someday..)?
Oct 14 18:56:08 <TAsn> different ids.
Oct 14 18:56:12 <DocScrutinizer-8> even those usually have id - though alphanum
Oct 14 18:56:19 <TAsn> (I think)
Oct 14 18:56:26 <TAsn> DocScrutinizer-8, we are talking about internal opimd design.
Oct 14 18:56:34 <TAsn> though that's a good tip for dos1
Oct 14 18:56:37 <DocScrutinizer-8> sure, me too
Oct 14 18:56:41 <mrmoku> nah... we're talking about our dbus API
Oct 14 18:56:55 <dos1> nah... we're talking about my dinner, i'm starving!
Oct 14 18:57:04 <mrmoku> dos1: eat some ids then ;)
Oct 14 18:58:37 * DocScrutinizer-8 envisions his next nightmare of a MUA storing mails neither in MBOX nor in folder/file format, but in opimd over dbus
Oct 14 18:58:57 <dos1> :>>>
Oct 14 18:59:29 <DocScrutinizer-8> WITH ATTACHMENTS --- WAAAAAHHHHH
Oct 14 19:00:00 * dos1 has enough inspiration now to write e-mail support in opimd! :D
Oct 14 19:00:20 <DocScrutinizer-8> @couch*
Oct 14 19:00:22 <Heinervdm> as a backend für messages domain :)
Oct 14 19:00:23 <CIA-26> SHR: 03tom 07shr * r05c459dd10b6 10/libframeworkd-phonegui/src/ (frameworkd-phonegui-utility.c frameworkd-phonegui-utility.h): added phonegui_contact_add/update functions
Oct 14 19:00:35 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r6dca22c4889e 10/src/view/contact-show-view.c: started using phonegui_contact opimd alternatives
Oct 14 19:00:47 <TAsn> dos1, not before implementing the redesign ideas! (please)
Oct 14 19:01:29 <dos1> ;DD
Oct 14 19:02:09 <TAsn> ffs
Oct 14 19:02:16 <TAsn> I'm missing a null termination (or so it seems)
Oct 14 19:02:17 <TAsn> somewher
Oct 14 19:02:21 <TAsn> somewhere
Oct 14 19:02:24 <TAsn> no idea where though :|
Oct 14 19:02:39 <mrmoku> TAsn: path is more secure for the future... I don't want to change our API just because in some months we discover some need for id not being enough...
Oct 14 19:03:01 <TAsn> mrmoku, 
Oct 14 19:03:05 <TAsn> we are using id
Oct 14 19:03:07 <TAsn> assuming
Oct 14 19:03:18 <TAsn> we can construct path from id
Oct 14 19:03:28 <mrmoku> where?
Oct 14 19:03:36 <TAsn> sprintf
Oct 14 19:03:36 <TAsn> ...
Oct 14 19:03:40 <mrmoku> where?
Oct 14 19:03:41 <TAsn> (in phonegui)
Oct 14 19:04:04 * mrmoku looks
Oct 14 19:04:59 <mrmoku> you mean something like
Oct 14 19:05:11 <mrmoku> _phonegui_message_show(id)
Oct 14 19:05:34 <mrmoku> but that is just because we pass in the id instead of the path
Oct 14 19:05:39 <CIA-26> SHR: 03tom 07libframeworkd-phonegui-efl2 * r277800550df1 10/src/view/contact-show-view.c: hopefully fixed the appending chars bug
Oct 14 19:05:48 <TAsn> mrmoku, no
Oct 14 19:05:49 <TAsn> I mean
Oct 14 19:05:57 <TAsn> phonegui_delete_message(id...)
Oct 14 19:05:59 <TAsn> instead of
Oct 14 19:06:05 <TAsn> phonegui_delete_message(path...)
Oct 14 19:06:18 <mrmoku> same thing
Oct 14 19:06:23 <dos1> help
Oct 14 19:06:25 <dos1> ERROR: Unable to parse conf/bitbake.conf (Could not include required file conf/distro/include/glibc-${TOOLCHAIN_TYPE}.inc)
Oct 14 19:06:26 <dos1> ;x
Oct 14 19:06:38 <TAsn> this will allow us to cope with future opimd API changes (for instance when it'll move to fso2, or maybe do some of the redesign suggestions)
Oct 14 19:06:43 <mrmoku> uuhh.. TOOLCHAIN_TYPE ;)
Oct 14 19:06:45 <dos1> TAsn: better use path
Oct 14 19:06:51 <TAsn> dos1, why?
Oct 14 19:06:58 <dos1> TAsn: as opimd returns path quite often
Oct 14 19:06:59 <mrmoku> because it _is_ a path
Oct 14 19:07:09 <dos1> and yup, it is path
Oct 14 19:07:12 <TAsn> but it's not nearly as generic as it should be :|
Oct 14 19:07:14 <TAsn> but ok. :|
Oct 14 19:07:24 <dos1> and using path is better to coope with api changes
Oct 14 19:07:25 <dos1> :P
Oct 14 19:07:29 <mrmoku> yup :)
Oct 14 19:07:44 <TAsn> dos1, no it's not
Oct 14 19:07:58 <TAsn> as people suggested dropping this path 
Oct 14 19:07:59 <TAsn> thingie
Oct 14 19:08:00 <TAsn> :)
Oct 14 19:08:08 <TAsn> (and I agree with them btw)
Oct 14 19:08:21 <dos1> TAsn: when/where/why?
Oct 14 19:08:40 <TAsn> baruch (and me), because it makes everything clumsy and it's not really needed.
Oct 14 19:08:44 * DocScrutinizer-8 wonders wtf "path" might mean wrt a database
Oct 14 19:09:29 <TAsn> dos1, and probably DocScrutinizer-8 as well ;)
Oct 14 19:09:44 <larsc> DocScrutinizer-8: does the gta01 suffer from the same gpb hardware bug than gta02?
Oct 14 19:09:45 <DocScrutinizer-8> and AIUI opimd *is* a database, no?
Oct 14 19:10:16 <DocScrutinizer-8> larsc: what's gpb hw bug?
Oct 14 19:10:24 <dos1> mrmoku: do you have some time?
Oct 14 19:10:27 <dos1> mrmoku: it's /home/shr/shr-oemerge/
Oct 14 19:10:56 <mrmoku> TAsn: dbus is all about paths...
Oct 14 19:11:09 <TAsn> mrmoku, I know.
Oct 14 19:11:15 <mrmoku> dos1: I think we just have to define TOOLCHAIN_TYPE to something...
Oct 14 19:11:22 <TAsn> but you don't have to have chanigng paths
Oct 14 19:11:25 <larsc> DocScrutinizer-8: missing driver transistors for the leds, or something it
Oct 14 19:11:25 <TAsn> as it's just confusing
Oct 14 19:11:27 <dos1> mrmoku: but it worked ;x
Oct 14 19:11:32 <TAsn> and makes us call dbus 3 times!
Oct 14 19:11:33 <dos1> is that some change in oe.dev?
Oct 14 19:11:34 <TAsn> instead of once.
Oct 14 19:11:41 <mrmoku> ERROR: Build of /home/mok/src/other/openmoko/shrmerge/shr-unstable/openembedded/recipes/util-linux-ng/util-linux-ng_2.15.bb do_configure failed
Oct 14 19:11:45 <mrmoku> :(
Oct 14 19:11:51 <DocScrutinizer-8> larsc: A5 does for AUX led
Oct 14 19:12:01 <mrmoku> dos1: you wanted me to pull in org.oe.dev ;)
Oct 14 19:12:02 <DocScrutinizer-8> A6 and newer are fixed
Oct 14 19:12:06 <larsc> DocScrutinizer-8: yes. and what's about gta01?
Oct 14 19:12:18 <larsc> DocScrutinizer-8: cause they use the same workaround code
Oct 14 19:12:20 <DocScrutinizer-8> larsc: gta01 has no leds?
Oct 14 19:12:40 <CIA-26> SHR: 03tom 07shr * r0e2241138878 10/libframeworkd-phonegui/src/frameworkd-phonegui-utility.h: fixed a typo
Oct 14 19:12:56 <TAsn> mrmoku, ^
Oct 14 19:12:59 <TAsn> it's only because
Oct 14 19:13:10 <TAsn> we don't compile with Wall Wextra and Werror ;)
Oct 14 19:13:22 <mrmoku> :)
Oct 14 19:13:46 <larsc> DocScrutinizer-8: ok. and no other hw bug, which causes gpb to malfunction?
Oct 14 19:14:02 <DocScrutinizer-8> not afaik
Oct 14 19:14:16 <larsc> ok
Oct 14 19:14:18 <larsc> thx
Oct 14 19:14:33 <DocScrutinizer-8> yw
Oct 14 19:18:43 <TAsn> ok, fixed the bug :)
Oct 14 19:18:51 <TAsn> and fixed another potential bug :)
Oct 14 19:19:38 <Heinervdm> to TOOLCHAIN_TYPE: there is no distro/include/glibc-*.inc so this commit is wrong :)
Oct 14 19:20:32 <Heinervdm> ah it comes 1 commit later...
Oct 14 19:22:24 <mrmoku> pull org.oe.dev?
Oct 14 19:22:52 <Heinervdm> mrmoku: dos1 pulled org.oe.dev on it's own ;)
Oct 14 19:23:05 <Heinervdm> it's not in shr/merge till now
Oct 14 19:23:51 <mrmoku> yeah... that explains why my git grep showed nothing ;)
Oct 14 19:23:57 <Heinervdm> :)
Oct 14 19:24:08 <mrmoku> dos1: bad boy :P
Oct 14 19:24:41 <dos1> we're working with org.oe.dev, so i'm merging with it :P
Oct 14 19:24:49 <mrmoku> [21:11]          TAsn | and makes us call dbus 3 times!
Oct 14 19:24:54 <mrmoku> that I don't understand...
Oct 14 19:25:01 <TAsn> why not?
Oct 14 19:25:05 <TAsn> query
Oct 14 19:25:08 <TAsn> result count
Oct 14 19:25:14 <TAsn> get entries
Oct 14 19:25:16 <TAsn> 3 times.
Oct 14 19:25:23 <TAsn> instead of 1.
Oct 14 19:25:33 <mrmoku> I thought you we're refering to path vs. id
Oct 14 19:25:43 <TAsn> no
Oct 14 19:25:54 <TAsn> I was referring to the ugly path 
Oct 14 19:26:08 <mrmoku> nothing to do with it though...
Oct 14 19:26:17 <TAsn> why not?
Oct 14 19:26:29 <mrmoku> why has it?
Oct 14 19:26:46 <TAsn> what?
Oct 14 19:26:58 <mrmoku> why has it to do with the path of a message?
Oct 14 19:27:07 <TAsn> oh
Oct 14 19:27:12 <TAsn> because you first query for a path
Oct 14 19:27:29 <mrmoku> huh?
Oct 14 19:27:35 <TAsn> actually, nvm my last coment
Oct 14 19:27:39 <TAsn> you query for a query path
Oct 14 19:27:43 <TAsn> as for message path
Oct 14 19:27:52 <TAsn> that has nothing to do with what I said :)
Oct 14 19:27:58 <mrmoku> :)
Oct 14 19:28:01 <TAsn> anyhow
Oct 14 19:28:05 <TAsn> mrmoku, dos1 Ainulindale 
Oct 14 19:28:11 <TAsn> respond to my shr-core mail!
Oct 14 19:28:33 <dos1> which?
Oct 14 19:28:34 <mrmoku> got no such thing...
Oct 14 19:28:35 <mrmoku> :)
Oct 14 19:28:43 * dos1 is totally confused today...
Oct 14 19:29:26 <TAsn> theme
Oct 14 19:29:29 <TAsn> you asses !
Oct 14 19:30:12 <mrmoku> ahh... the theme Contest?
Oct 14 19:30:16 <TAsn> yes.
Oct 14 19:30:23 <TAsn> I think this is the logical next step :)
Oct 14 19:30:27 <TAsn> as we really need a theme
Oct 14 19:30:32 <TAsn> and I saw great user contributions
Oct 14 19:30:35 * mrmoku thought TAsn would prefer me to fix ophonekitd instead :P
Oct 14 19:30:44 <TAsn> mrmoku, you should fix ophonekitd
Oct 14 19:30:49 <TAsn> I will take care of the theme contest.
Oct 14 19:30:49 <TAsn> :)
Oct 14 19:30:53 <mrmoku> ok :)
Oct 14 19:30:53 <Heinervdm> TAsn: alphalog has written that he want to make a svg version, so don't you want to wait for that?
Oct 14 19:30:54 <mrmoku> good plan
Oct 14 19:31:00 <DocScrutinizer-8> one more rant about path/id: this always should be primary-key no-dupkey (aka unique for the contact, sms, whatever), and for a primary-key you prefer int usually
Oct 14 19:31:08 <TAsn> Heinervdm, I already mailed them about that. 
Oct 14 19:31:18 <Heinervdm> ok :)
Oct 14 19:31:31 <TAsn> Heinervdm, the mail in shr-core was about the intention, not actually making a post now. ;)
Oct 14 19:31:51 <TAsn> but I really want a new theme, and the users proved to be amazingly talented. :)
Oct 14 19:32:04 <Heinervdm> Theme Contest ;)
Oct 14 19:33:14 <JaMa> Heinervdm: could you please pastebin log.do_compile from your openssl-native?
Oct 14 19:33:41 <TAsn> btw mrmoku 
Oct 14 19:33:42 <Heinervdm> JaMa: not build till now
Oct 14 19:33:51 <TAsn> still no index in messages contact add ;|
Oct 14 19:33:56 <Heinervdm> JaMa: started a build from scratch...
Oct 14 19:35:03 <TAsn> damn, this tel: thingie is such a mess! so much special handling! :(
Oct 14 19:35:21 <TAsn> dos1, I HATE IT!
Oct 14 19:35:28 <dos1> :D
Oct 14 19:35:35 <TAsn> :)
Oct 14 19:37:28 <mrmoku> Heinervdm: configure: error: C compiler cannot create executables
Oct 14 19:37:37 <mrmoku> for util-linux-ng
Oct 14 19:37:40 <DocScrutinizer-8> TAsn: +1
Oct 14 19:37:42 <mrmoku> seen that?
Oct 14 19:39:28 <Heinervdm> mrmoku: no
Oct 14 19:40:21 <Heinervdm> mrmoku: building now from scratch, because i switch important glibc and other important libs during build, will see what will fail now
Oct 14 19:41:03 <JaMa> Heinervdm: now I know why its failing here (openssl-native) in crypto/md5/Makefile
Oct 14 19:41:06 <JaMa> install: @[ -n "$(INSTALLTOP)" ] # should be set by top Makefile...
Oct 14 19:41:07 <JaMa> and its empty
Oct 14 19:41:19 <JaMa> defined in top Makefile but not "exported"
Oct 14 19:41:29 <Heinervdm> hmm
Oct 14 19:52:54 <DocScrutinizer-8> where are the api defs of opimd? fso?
Oct 14 19:53:18 <mrmoku> yup
Oct 14 19:53:30 <DocScrutinizer-8> k
Oct 14 19:54:01 <Blu3> have they been updated to be current?  last i heard dos1 say is they were outdated
Oct 14 19:54:34 <DocScrutinizer-8> mrmoku: ever did a simple "time grep <unique-key> xxx" with xxx is 10k lines of 50char each?
Oct 14 19:54:58 <DocScrutinizer-8> on FR of course
Oct 14 19:55:51 <DocScrutinizer-8> here it's <0.7sec
Oct 14 19:55:58 <dos1> Blu3: they just missed few methods
Oct 14 19:56:03 <dos1> i updated them some time ago
Oct 14 19:56:08 <dos1> http://docs.freesmartphone.org/
Oct 14 19:56:18 <dos1> but some work on descriptions is still needed
Oct 14 19:56:37 <mrmoku> DocScrutinizer-8: and?
Oct 14 19:57:08 <DocScrutinizer-8> well, I compare this to speed of opimd 
Oct 14 19:57:15 <DocScrutinizer-8> just thinking
Oct 14 19:57:32 <mrmoku> DocScrutinizer-8: hmm... it's difficult to compare
Oct 14 19:58:36 <DocScrutinizer-8> yes, I know. That's why I asked for the api specs ;-)
Oct 14 20:02:11 <TAsn> DocScrutinizer-8, added info to http://wiki.openmoko.org/wiki/Opimd_redesign
Oct 14 20:02:16 <TAsn> baruch, same goes for you ^
Oct 14 20:07:09 <TAsn> http://scap.linuxtogo.org/files/2ac5e1aaed533dbc5fc94366771010d8.png
Oct 14 20:07:09 <baruch> Looks fine to me, though I'm not sure we should really allow anyone to add fields willy nilly
Oct 14 20:07:10 <TAsn> cool :))))
Oct 14 20:08:01 <DocScrutinizer-8> TAsn: that's actually beyond critical mass for me to start and add on it :-)
Oct 14 20:08:05 <baruch> Looks fine to me, though I'm not sure we should really allow anyone to add fields willy nilly
Oct 14 20:08:12 <TAsn> baruch, users of the API, they should be able to add fields if they want.
Oct 14 20:08:31 <baruch> We should have a basic set of fields we have defined at all times
Oct 14 20:08:31 <TAsn> DocScrutinizer-8, I'm glad :)
Oct 14 20:08:36 <TAsn> baruch, yes.
Oct 14 20:08:47 <TAsn> of course
Oct 14 20:08:59 <TAsn> First name is a must
Oct 14 20:09:02 <TAsn> though other than that
Oct 14 20:09:05 <TAsn> we don't demand anything.
Oct 14 20:09:11 <DocScrutinizer-8> but we need X-user-field-foo as well
Oct 14 20:09:33 <TAsn> DocScrutinizer, they can add whatever they want.
Oct 14 20:09:40 <TAsn> will just be type general
Oct 14 20:10:13 <baruch> I dont mean to require fields, I mean to have a set of fields that have a pre-set meaning (Home,Work,Mobile are all phones, Email is email and so on)
Oct 14 20:10:15 <mrmoku> TAsn: I think baruch was talking about field types
Oct 14 20:10:21 <DocScrutinizer-8> TAsn: that was to baruch to make clear that's a minimum number of mandatory fields, but it's extensable
Oct 14 20:10:50 <TAsn> baruch, that's just a config
Oct 14 20:11:00 <TAsn> oh, types are set by opimd
Oct 14 20:11:02 <TAsn> and opimd alone.
Oct 14 20:11:13 <TAsn> DocScrutinizer-8, ok. ;)
Oct 14 20:11:22 <TAsn> do you guys agree with what I wrote?
Oct 14 20:11:24 <DocScrutinizer-8> baruch: and of course there has to be sort of conventions about semantics of particular fields
Oct 14 20:11:45 <DocScrutinizer-8> TAsn: 99% yes
Oct 14 20:12:28 <DocScrutinizer-8> TAsn: I need to find sume dinner now. Will add a few rant to the wiki later
Oct 14 20:12:54 <TAsn> DocScrutinizer-8, happily :)
Oct 14 20:13:06 <TAsn> I added it in secs
Oct 14 20:13:12 <TAsn> frow what I recalled.
Oct 14 20:13:25 <TAsn> we discussed about.
Oct 14 20:13:32 <TAsn> there's probably more to be said.
Oct 14 20:13:56 <DocScrutinizer-8> first I need to learn about the api
Oct 14 20:14:10 <TAsn> DocScrutinizer, sure thing. have fun.
Oct 14 20:14:16 <DocScrutinizer-8> then think about if it has all I'd like to see
Oct 14 20:14:27 <baruch> the wiki says the api will include addfield (it says addfiled but I understand it as addfield :-)
Oct 14 20:14:30 <TAsn> DocScrutinizer-8, what I wrote there
Oct 14 20:14:33 <TAsn> is not all I want
Oct 14 20:14:36 <TAsn> just most of what I want.
Oct 14 20:14:38 <baruch> addfield should have name and type, so type is set by user
Oct 14 20:14:46 <TAsn> baruch, 
Oct 14 20:14:47 <TAsn> no
Oct 14 20:14:48 <DocScrutinizer-8> yup
Oct 14 20:14:54 <TAsn> you have a limited type of types
Oct 14 20:15:13 <TAsn> which are offered by opimd
Oct 14 20:15:58 <baruch> TAsn, you fail to parse anything I say...
Oct 14 20:16:08 <TAsn> nah, it's not parsing
Oct 14 20:16:13 <baruch> obviously the type fields is not unlimited, consider it an enum
Oct 14 20:16:20 <TAsn> yeah.
Oct 14 20:16:34 <DocScrutinizer-8> and every fieldtype should have properties, which could be precedence (replacing your default idea) like this is field1 for tel, this is field2 for tel
Oct 14 20:16:36 <TAsn> an enum in the db.
Oct 14 20:17:11 <TAsn> DocScrutinizer-8, that's too complicated in my pov
Oct 14 20:17:17 <TAsn> I don't want to handle splitting phone numebrs
Oct 14 20:17:20 <TAsn> or even contacting strings
Oct 14 20:17:51 <TAsn> it's too hard to handle
Oct 14 20:17:54 <TAsn> and too annoying.
Oct 14 20:18:15 <DocScrutinizer-8> that's not about splitting anything
Oct 14 20:18:25 <TAsn> then I misunderstood you.
Oct 14 20:18:43 <DocScrutinizer-8> replace int precedence by bool default if you like that better
Oct 14 20:18:51 <TAsn> oh
Oct 14 20:18:56 <TAsn> you are talking about multi numbers?
Oct 14 20:19:00 <TAsn> ok
Oct 14 20:19:02 <DocScrutinizer-8> yup
Oct 14 20:19:05 <TAsn> now I got you.
Oct 14 20:19:20 <TAsn> hm..
Oct 14 20:19:24 <TAsn> I think users will prefer
Oct 14 20:19:33 <TAsn> having Home Work Office Cell
Oct 14 20:19:36 <TAsn> better than a precedence
Oct 14 20:19:43 <TAsn> I know I'd prefer that.
Oct 14 20:19:45 <DocScrutinizer-8> all this a draft of the moment from top of my head
Oct 14 20:20:02 <DocScrutinizer-8> sure 
Oct 14 20:20:04 <TAsn> DocScrutinizer-8, of course.
Oct 14 20:20:06 <TAsn> in my head as well.
Oct 14 20:20:16 <TAsn> DocScrutinizer-8, but yeah, I think we should have a way to set precedence
Oct 14 20:20:29 <TAsn> though not by a "per#:" prefix *wink*
Oct 14 20:20:32 <DocScrutinizer-8> so you have a field with type tel, name home, and default = true
Oct 14 20:20:59 <DocScrutinizer-8> another one with name office, type tel, and default=false
Oct 14 20:21:10 <TAsn> DocScrutinizer-8, kinda, the only problem with this
Oct 14 20:21:18 <Hardy> TAsn: oh it seems there is a way for an graphical slider for output volume right?
Oct 14 20:21:19 <TAsn> is that you gotta take care of all the defaults
Oct 14 20:21:23 <TAsn> and this can generate bug.
Oct 14 20:21:27 <TAsn> Hardy, not quite
Oct 14 20:21:32 <TAsn> (there's none)
Oct 14 20:21:35 <TAsn> I merged the reports
Oct 14 20:21:43 <Hardy> ah i see
Oct 14 20:21:47 <TAsn> though it'l not *really* that hard to make
Oct 14 20:22:08 <Hardy> but its not that inportant also
Oct 14 20:22:14 <DocScrutinizer-8> bbl
Oct 14 20:22:17 <TAsn> Hardy, actually it's VERY important
Oct 14 20:22:20 <TAsn> DocScrutinizer-8, ciao :)
Oct 14 20:22:23 <TAsn> at least in my pov
Oct 14 20:22:33 <TAsn> it's just not as important ;)
Oct 14 20:23:06 <Hardy> why that?, one time configurated, (each Neo is different), and it wouldnt care anymore
Oct 14 20:23:44 <Blu3> is there a /proc or /sys interface to re-init/awaken the ar6000?
Oct 14 20:23:56 <TAsn> Hardy, exactly
Oct 14 20:24:00 <TAsn> every neo is different
Oct 14 20:24:05 <TAsn> many revisions
Oct 14 20:24:09 <TAsn> different hw hacks
Oct 14 20:24:12 <TAsn> (individual)
Oct 14 20:24:20 <TAsn> i.e, hell. :)
Oct 14 20:24:50 <Hardy> ow now i now what ya mean ^^
Oct 14 20:24:50 <Hardy> know
Oct 14 20:25:57 <Hardy> cause the users should be able to configure the volume themself without cracking out the code xD
Oct 14 20:26:16 <TAsn> exactly.
Oct 14 20:26:24 <Hardy> or be terrorised by "backsetting default values" of the alsamixer
Oct 14 20:26:34 <Hardy> xD
Oct 14 20:26:54 <TAsn> like I do
Oct 14 20:27:03 <TAsn> (and overwrite once in a while since I'm an idiot)
Oct 14 20:27:04 <TAsn> :)
Oct 14 20:27:08 <Blu3> much of the freerunner software currently available is a bit far from user-friendly in this manner
Oct 14 20:27:15 <Hardy> TAsn:  xD
Oct 14 20:27:19 <Blu3> mixer volumes being one of the worst offenders
Oct 14 20:27:34 <TAsn> Blu3, actually, as Isaid many times before
Oct 14 20:27:41 <TAsn> it's not that bad.
Oct 14 20:27:51 <TAsn> I mean, in regular phones you can't really change the volume settings
Oct 14 20:27:58 <TAsn> you can only change in call and ringing volume
Oct 14 20:27:58 <Blu3> ?
Oct 14 20:28:08 <TAsn> we let users do the second
Oct 14 20:28:12 <Blu3> i change them all the time in several of my phones
Oct 14 20:28:14 <TAsn> (fso doesn't support it yet though)
Oct 14 20:28:33 <TAsn> Blu3, and as for in call, that's needed :)
Oct 14 20:28:37 <Hardy> Blu3: you should just have one: The NEO ^^
Oct 14 20:29:42 <Blu3> hardy, the neo is like driving around town sitting on a welded bar on a vehicle that has almost zero side panels, no accessories, and a whole lot of empty space for your foot to slip through and scrape on the pavement
Oct 14 20:30:02 <Blu3> it's a little rough
Oct 14 20:30:18 <juri_> and whats that make the 1973? :P
Oct 14 20:30:55 <TAsn> Blu3, nah, I use it as a daily phone
Oct 14 20:31:05 <Blu3> i try to
Oct 14 20:31:15 <Hardy> Blu3: nice diffination, im suprised ^^ but ya, it was a joke ^^
Oct 14 20:31:19 <TAsn> there's everything I need (especially since I got a motorcycle so I don't really need the phone speaker)
Oct 14 20:31:33 <Blu3> juri, you don't even get the welded bar to sit on.  you gotta balance yourself on the wrench you're using to steer with
Oct 14 20:31:34 <Blu3> :>
Oct 14 20:31:48 <TAsn> Blu3, :)
Oct 14 20:31:59 <Hardy> xD
Oct 14 20:32:19 <cichlid_> PaulFertser: can you give me a hand to get my wifi working on debian with wifi_ifupdown.patch please ?
Oct 14 20:32:32 <cichlid_> or anyone else actually ?
Oct 14 20:33:15 <Hardy> dont look at me, im a fool of neo updating xD
Oct 14 20:33:29 <Blu3> cichlid, if i knew, i would :)  my wifi randomly works
Oct 14 20:34:00 <Blu3> when it does, it's rock solid.  when it doesn't, i have no idea how to make it try
Oct 14 20:34:00 <cichlid_> the thing is i have to apply http://docs.openmoko.org/trac/ticket/2277
Oct 14 20:34:34 <TAsn> Blu3, as you can see,
Oct 14 20:34:41 <TAsn> we are trying to make 
Oct 14 20:34:44 <TAsn> shr usable
Oct 14 20:34:56 <TAsn> we started working in parallel :)
Oct 14 20:35:04 <TAsn> users on logo (and hopefully theme soon)
Oct 14 20:35:11 <TAsn> and the rest of us on 
Oct 14 20:35:14 <TAsn> xorg
Oct 14 20:35:15 <Blu3> yes, and so am i
Oct 14 20:35:18 <TAsn> oe merge
Oct 14 20:35:23 <TAsn> opimd
Oct 14 20:35:26 <TAsn> efl3
Oct 14 20:35:26 <Hardy> TAsn: im soo prowd of ya ;D
Oct 14 20:35:26 <Blu3> but there are times when my frustration reaches boiling point
Oct 14 20:35:28 <TAsn> efl2*
Oct 14 20:35:35 <TAsn> Hardy, it's barely me, mostly mrmoku 
Oct 14 20:35:38 <TAsn> Heinervdm
Oct 14 20:35:41 <TAsn> JaMa
Oct 14 20:35:42 <TAsn> dos1
Oct 14 20:35:48 <mrmoku> and TAsn :P
Oct 14 20:35:59 <TAsn> mrmoku, when I don't have tests
Oct 14 20:36:07 <Blu3> i can't work on my MMS stuff when the sd card is constantly going offline because of gsm activity
Oct 14 20:36:16 <TAsn> Blu3, :(
Oct 14 20:36:20 <TAsn> MMS is important! :|
Oct 14 20:36:24 <cichlid_> last question, to access NOR disk from the SD How shoud i do ?
Oct 14 20:36:35 * mrmoku remembers to have some binary message on his SIM...
Oct 14 20:36:39 <cichlid_> i mean NOR flash memory
Oct 14 20:36:39 <TAsn> Blu3, that's a weird bug.
Oct 14 20:36:43 <TAsn> mrmoku, never got binary
Oct 14 20:36:44 <Blu3> things get corrupted.  i have to stop everything, pull the SD, stick it in my laptop, fix the errors, and start again
Oct 14 20:36:56 <Hardy> okay i call them all: I'm so prowd of ya, mrmoku, Tasn, Heiner, Jama and dos1, let me wishes came true...  (and let me logo win wuhaha xD, its bad also xD)
Oct 14 20:36:57 <TAsn> when someone sent me an sms
Oct 14 20:37:05 <Blu3> currently it's close to 100% breakable so i'm trying to work around things
Oct 14 20:37:07 <mrmoku> Hardy: :)
Oct 14 20:37:11 <TAsn> I got a message from orange saying: "you got an mms go to this website..."
Oct 14 20:37:24 <TAsn> Hardy, + Heinervdm 
Oct 14 20:37:31 <Blu3> cichlid, it's mtd block ...1? i think
Oct 14 20:37:34 <TAsn> Hardy, logo contest is over.
Oct 14 20:37:43 <Hardy> shit? realy?
Oct 14 20:37:55 <Hardy> i called him as heiner
Oct 14 20:38:00 <TAsn> oh
Oct 14 20:38:02 <TAsn> didn't see :)
Oct 14 20:38:15 <Hardy> open up ya eyes maaan ^^
Oct 14 20:38:22 <TAsn> I'm tired. :)
Oct 14 20:38:42 <Hardy> so get a sleep for some more moko-power
Oct 14 20:38:56 <TAsn> sleeping is a waste of good deving time.
Oct 14 20:38:56 <TAsn> :)
Oct 14 20:39:02 <TAsn> mrmoku, which reminds me
Oct 14 20:39:08 <TAsn> we really need to start documenting functions!
Oct 14 20:39:24 <Blu3> ...please
Oct 14 20:39:25 <TAsn> (assumptions, method and purpose)
Oct 14 20:39:28 <TAsn> Blu3, heeh :)
Oct 14 20:39:36 * mrmoku will waste some deving time first :P
Oct 14 20:39:36 <TAsn> Blu3, we are still cleaning up the mess!
Oct 14 20:39:43 <TAsn> mrmoku, happily. ;)
Oct 14 20:39:50 <TAsn> mrmoku, how's phoneuid doing?
Oct 14 20:39:58 <Blu3> strangled spaghetti documentation is one of the achilles heels of OM
Oct 14 20:40:00 <mrmoku> logging works fine :)
Oct 14 20:40:11 <TAsn> mrmoku, please tell me you used that glib function
Oct 14 20:40:17 <mrmoku> now I have the problem that I killed my image by upgrading...
Oct 14 20:40:19 <mrmoku> TAsn: yup
Oct 14 20:40:51 <TAsn> hehe :)
Oct 14 20:40:58 <TAsn> (glib) good! :)
Oct 14 20:41:08 <Hardy> TAsn: without sleep you wouldn't need your timer function ^^ (saves some place xD)
Oct 14 20:41:23 <TAsn> I was afraid you'd wrap it with a script.
Oct 14 20:41:28 <TAsn> Hardy, :)
Oct 14 20:41:30 <Hardy> and ya'll pass the suspend shit
Oct 14 20:41:39 <TAsn> suspend is a bitch.
Oct 14 20:41:48 <TAsn> most of my dev work is done
Oct 14 20:42:06 <TAsn> with the hope I'll be able to buy a decent phone (different hw) that'll be able to run shr
Oct 14 20:42:06 <TAsn> :)
Oct 14 20:42:20 <Hardy> xD
Oct 14 20:42:36 <TAsn> as I think SHR is (and will be) way better than any proprietary phone system
Oct 14 20:42:46 <TAsn> even better than the jesus phone (which sucks!)
Oct 14 20:42:59 <Hardy> jesus phone?
Oct 14 20:43:05 <mrmoku> anyway... before fixing my image I will sleep a bit :)
Oct 14 20:43:08 <mrmoku> gnight all
Oct 14 20:43:13 <Hardy> gn8
Oct 14 20:43:16 <TAsn> mrmoku|away, night.
Oct 14 20:43:19 <TAsn> Hardy, iphone.
Oct 14 20:43:40 <Hardy> ow... okay, moko will bite that apple
Oct 14 20:43:45 <TAsn> :)
Oct 14 20:44:18 <TAsn> ok
Oct 14 20:44:23 <soltys> ;)
Oct 14 20:44:25 <TAsn> I think it's time for me to get something to drink
Oct 14 20:44:26 <Heinervdm> mrmoku|away: you left shr/merge in an unbuildable state...
Oct 14 20:44:37 <TAsn> and hopefully do some deving after.
Oct 14 20:44:43 <TAsn> Heinervdm, he's a lazy bum (j/k)
Oct 14 20:44:49 <Heinervdm> mrmoku|away: http://patchwork.dev.bearstech.com/patch/289/ was important ;)
Oct 14 20:44:57 <soltys> :)
Oct 14 20:45:02 <TAsn> mrmoku|away, please come back 1:)
Oct 14 20:45:03 <Heinervdm> TAsn: he applied 2 of 3 ;)
Oct 14 20:45:16 * TAsn doesn't have access :(
Oct 14 20:45:19 <TAsn> ohoh
Oct 14 20:45:21 <TAsn> Ainulindale, ping
Oct 14 20:45:23 <TAsn> ^
Oct 14 20:45:39 <soltys> hihi
Oct 14 20:45:39 <Hardy> TAsn: go asleep too xD
Oct 14 20:45:50 <TAsn> Hardy, I don't tend to waste my time with sleeping.
Oct 14 20:45:52 <Blu3> tasn, the freerunner can run all our software, we just need to make it better instead of wrapping function after function after function which makes things friggen slow
Oct 14 20:45:53 <Hardy> for your health
Oct 14 20:46:04 <TAsn> Blu3, nah.
Oct 14 20:46:08 <TAsn> well kinda
Oct 14 20:46:12 <TAsn> but not really.
Oct 14 20:46:20 <slaxxer> mrmoko latest images shr  usable?
Oct 14 20:46:24 <TAsn> what we do doesn't make naything slower
Oct 14 20:46:29 <TAsn> as the functions we wrap
Oct 14 20:46:45 <TAsn> are called once every couple of minutes if ever.
Oct 14 20:47:00 <TAsn> the noly thing that's slow is opimd
Oct 14 20:47:07 <TAsn> which will hopefully improve.
Oct 14 20:47:21 <Heinervdm> a vala rewrite will speed it up :)
Oct 14 20:47:29 <cichlid_> where are the source of the 26.29 kernel please ?
Oct 14 20:47:49 <Heinervdm> slaxxer:  image from 06.09.2009?
Oct 14 20:48:05 <Heinervdm> cichlid_: git.openmoko.org
Oct 14 20:48:47 <Heinervdm> cichlid_: SHR uses this: http://git.openmoko.org/?p=kernel.git;a=shortlog;h=andy-tracking
Oct 14 20:49:22 <cichlid_> thx, i just need to recompile my ar6000.c, so how shoud i do ?
Oct 14 20:49:33 <cichlid_> just using the andy branch ?
Oct 14 20:49:52 <cichlid_> may i do that directky on the freerunner ?
Oct 14 20:49:53 <Heinervdm> cichlid_: i don't know how to compile a single module...
Oct 14 20:53:06 <TAsn> Heinervdm, not only
Oct 14 20:53:12 <TAsn> a redesign is needed
Oct 14 20:53:18 <TAsn> and taht's what we are trying to do.
Oct 14 20:53:39 <Heinervdm> that will speed it up even more ;)
Oct 14 20:54:10 <Heinervdm> mrmoku|away: applied 289, but forgot to remove it from Patchwork :)
Oct 14 20:54:25 <PaulFertser> cichlid_: why do you think any patch is necessary.
Oct 14 20:56:06 <cichlid_> PaulFertser: because of http://docs.openmoko.org/trac/ticket/2277
Oct 14 20:56:23 <TAsn> Heinervdm, please explain
Oct 14 20:56:26 <TAsn> what are you doing atm?
Oct 14 20:56:32 <TAsn> merging shr wit oe?
Oct 14 20:56:34 <TAsn> with*
Oct 14 20:56:35 <cichlid_> how would you manage this wifi issue please ?
Oct 14 20:56:37 <PaulFertser> cichlid_:  Ticket #2277 (closed defect: fixed)
Oct 14 20:56:39 <TAsn> (/me wants to know)
Oct 14 20:56:49 <Heinervdm> TAsn: yes exactly that :)
Oct 14 20:57:04 <TAsn> cool :))))
Oct 14 20:57:37 <cichlid_> ok the thing is my wifi isn't working isn't even scaning with iwlist :-(
Oct 14 20:58:28 <TAsn> cichlid, did you turn it on?
Oct 14 20:58:33 <TAsn> shr-settings
Oct 14 20:59:09 <TAsn> I think I'll regard this silence as an "oops"?
Oct 14 20:59:13 <TAsn> -?
Oct 14 21:00:53 <cichlid_> TAsn: how do you do that ?
Oct 14 21:01:03 <PaulFertser> cichlid_: are you sure you use the latest andy-tracking?
Oct 14 21:01:05 <cichlid_> on debian
Oct 14 21:01:18 <cichlid_> no
Oct 14 21:01:22 <TAsn> cichlid_, mdbus
Oct 14 21:01:23 <TAsn> something
Oct 14 21:01:25 <TAsn> not sure
Oct 14 21:01:34 <TAsn> it's a dbus call to fso
Oct 14 21:01:47 <TAsn> PaulFertser, it seems he didn't turn wifi on
Oct 14 21:01:56 <TAsn> actually I'm not sure it has to be done in debain
Oct 14 21:01:59 <TAsn> but in shr you have to.
Oct 14 21:02:03 <Heinervdm> you can turn it on with a sysfs call too
Oct 14 21:02:09 <TAsn> cichlid, ^
Oct 14 21:02:10 <TAsn> ;)
Oct 14 21:02:27 <PaulFertser> cichlid_: have you turned your wifi on?
Oct 14 21:02:38 <cichlid_> i do not know the way
Oct 14 21:02:41 <cichlid_> i am sorry
Oct 14 21:03:48 <PaulFertser> cichlid_: tried reading the wiki: http://wiki.openmoko.org/wiki/WiFi ?
Oct 14 21:03:50 <TAsn> cichlid, I think there's something in the wiki.
Oct 14 21:04:04 <TAsn> PaulFertser, that's a very nice to say RTFM! :)
Oct 14 21:04:16 <TAsn> way to*
Oct 14 21:05:01 <Kensan> raster: hi
Oct 14 21:05:17 <PaulFertser> TAsn: i've just woken up, not enough tired yet to be rude to strangers ;)
Oct 14 21:05:25 <TAsn> hehe :)
Oct 14 21:05:54 <cichlid_> wiki page is outdated
Oct 14 21:06:10 <Kensan> PaulFertser: gradb a cup of coffee and get grumpy like the rest of us
Oct 14 21:06:11 <cichlid_> from time immemorial
Oct 14 21:06:20 <TAsn> cichlid, but at least it says you should turn on wifi :)
Oct 14 21:06:27 <TAsn> just see how shr-settings does it.
Oct 14 21:06:47 <slaxxer> http://build.shr-project.org/tests/mrmoku/unstable/images/om-gta02/?C=M;O=D
Oct 14 21:06:47 <cichlid_> debian is less user-friendly than shr-settings, man
Oct 14 21:06:54 <slaxxer> those images
Oct 14 21:07:02 <TAsn> shr is pretty usable
Oct 14 21:07:09 <TAsn> as I said, I use it as a daily phone.
Oct 14 21:07:11 <slaxxer> are  they usable
Oct 14 21:07:16 <PaulFertser> Kensan: i don't like coffee, it makes me thirsty. :)
Oct 14 21:07:18 <TAsn> slaxxer, yes.
Oct 14 21:07:23 <slaxxer> ok
Oct 14 21:07:25 <TAsn> BUT
Oct 14 21:07:31 <slaxxer> :_
Oct 14 21:07:32 <TAsn> (I'm using them)
Oct 14 21:07:33 <TAsn> but
Oct 14 21:07:38 <Heinervdm> slaxxer: the 20091006 image runs fine
Oct 14 21:07:40 <TAsn> name resolving for incoming calls
Oct 14 21:07:42 <TAsn> doesn't work
Oct 14 21:07:46 <slaxxer> what dont work?
Oct 14 21:07:48 <TAsn> for contacts that are saved
Oct 14 21:07:58 <TAsn> in a non normalized number
Oct 14 21:07:59 <slaxxer> o
Oct 14 21:08:09 <TAsn> and shr-settings controlling domains is broken
Oct 14 21:08:11 <TAsn> other than that
Oct 14 21:08:15 <TAsn> everything is great
Oct 14 21:08:17 <TAsn> and uses opimd
Oct 14 21:08:19 <TAsn> (iirc)
Oct 14 21:09:00 <TAsn> but it rocks :)
Oct 14 21:09:02 <TAsn> anyhow, night.
Oct 14 21:09:03 <TAsn> ciao
Oct 14 21:09:38 <PaulFertser> cichlid_: i checked it has necessary info before passing you a link.
Oct 14 21:09:45 <cichlid_> thx
Oct 14 21:14:42 <cichlid_> that drives me mad
Oct 14 21:16:31 <cichlid_> echo s3c2440-sdi > /sys/bus/platform/drivers/s3c2440-sdi/bind
Oct 14 21:16:40 <cichlid_> ? that stuff ???
Oct 14 21:16:41 <Hardy> me go sleep to
Oct 14 21:16:54 <Hardy> good night @ all
Oct 14 21:17:00 <PaulFertser> cichlid_: sure
Oct 14 21:17:18 <cichlid_> outdated
Oct 14 21:17:30 <Blu3> unbind/bind isn't producing any ar6 messages for me atm for some reason
Oct 14 21:17:39 <cichlid_> bloody outdated
Oct 14 21:18:00 <Blu3> cichlid, *gasp* never! :)
Oct 14 21:18:02 <Blu3> erg
Oct 14 21:35:50 <JaMa> 2 beers later and openssl-native still doesn't build :(
Oct 14 21:36:28 <TAsn> JaMa, I think this proves it, beer doesn't make computers work better.
Oct 14 21:36:32 <Heinervdm> JaMa: it builds fine for me...
Oct 14 21:36:44 <Heinervdm> ah your in shr/import...
Oct 14 21:36:49 <TAsn> it can only make women look better.
Oct 14 21:37:04 <Heinervdm> JaMa: tried to bump glbc to 2.7?
Oct 14 21:38:47 <JaMa> Heinervdm: I tested it on angstrom/oe.dev too and it fails
Oct 14 21:38:59 <JaMa> Heinervdm: so maybe something on my host :/
Oct 14 21:39:08 <Heinervdm> maybe
Oct 14 21:39:22 <JaMa> Heinervdm: I tried to downgrade binutils sys-devel/binutils-2.20.51.0.2 -> sys-devel/binutils-2.20.51.0.1 but didn't help
Oct 14 21:39:41 <JaMa> Heinervdm: if i modify that INSTALLTOP in Makefile it compiles fine..
Oct 14 21:40:03 <JaMa> Heinervdm: so it looks like similar problem I had in *fso* libgee and other stuff before
Oct 14 21:40:19 <Heinervdm> strange
Oct 14 21:41:11 <JaMa> btw if someone is interested in kexecboot or "qi bootmenu" 20:55:04 < Jay7> icons coming soon :)
Oct 14 21:41:36 <Heinervdm> mrmoku will be shocked when he looks at patchwork tomorow :)
Oct 14 21:42:21 <TAsn> Heinervdm, I hope he will :)
Oct 14 21:42:27 <TAsn> +be
Oct 14 21:43:53 <JaMa> Heinervdm: just those 4 patches or do you have something on stack? :)
Oct 14 21:44:08 <JaMa> Heinervdm: I can send 4 more, but need to test it better in shr/import
Oct 14 21:44:11 <Heinervdm> 4 in 15 Minutes
Oct 14 21:44:42 <Heinervdm> hmm, wrong python version build...
Oct 14 21:45:46 <Heinervdm> ah no, it's python-native
Oct 14 21:59:31 <Zorkman> anyone know what this scao is about?: http://scap.linuxtogo.org/files/6c2fc7936984ca67f8bb4b7571e5bc99.png
Oct 14 22:13:27 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r7ef85123e3e2 10/fsogpsd/src/ (4 files in 2 dirs): fsogpsd: create channel
Oct 14 22:15:10 <Blu3> zorkman, that looks like D&D
Oct 14 22:16:35 <Blu3> probably 3.5ed because it has the Base Attack Bonus (BAB)
Oct 14 22:17:40 <Zorkman> Blu3: is it available as an ipk somewhere?
Oct 14 22:17:59 <Blu3> no idea at all.  it looks like a simple character reference tool
Oct 14 22:18:22 <Blu3> personally i don't do 3.5 anymore, all my stuff is now 4ed
Oct 14 22:18:30 <Sharwin_F> Zorkman, an app I'm developing to learn python :P
Oct 14 22:19:07 <Sharwin_F> Zorkman, only python sources atm, and it's not quite finished (and I'm sure the code is sooo ugly hehe)
Oct 14 22:19:27 <Sharwin_F> atm it only reads character sheets in xml format
Oct 14 22:19:55 <Zorkman> Sharwin_F: will it be a character viewer only, or an actual game?
Oct 14 22:20:14 <Zorkman> (and congratulations on trying to learn how to code python)
Oct 14 22:20:27 <Sharwin_F> Zorkman, in fact I'm trying to build some classes, and from there I create the GUI. So it may be possible to use it in game and similar stuff
Oct 14 22:21:04 <Sharwin_F> in the future I'll add more backends, such as opening Bioware's BIC file format from NeverWinter nights
Oct 14 22:21:45 <Sharwin_F> and it will have more classes for different type-games, rules, etc.
Oct 14 22:21:57 <Zorkman> nice
Oct 14 22:23:15 <Sharwin_F> Zorkman, if you want to take a look at it (thought it's not worth at all I think :P) http://sourceforge.net/projects/pyrolemanager/
Oct 14 22:24:11 <Zorkman> Sharwin_F: thanks, but i'll hit the sack now
Oct 14 22:24:52 <Zorkman> just returned  yesterday from a short holiday to sardinia (mapping gsm cells for openbmap :)) and a workrelated meeting in holland (mapping the cells also :))
Oct 14 22:25:29 <Zorkman> keep up the good work,
Oct 14 22:25:38 <Zorkman> looking forward to what you will devellop :)
Oct 14 22:25:44 <Zorkman> g'night
Oct 14 22:26:52 <Sharwin_F> Zorkman, thanks, gnight :)
Oct 14 22:28:34 <monto_> hi all
Oct 14 22:29:17 <monto_> need a simple info, which is the status of shr-u and where can i get a recent image?
Oct 14 23:12:22 <JaMa> Heinervdm: configure: error: *** The available kernel headers are older than the requested shr/merge we need to bump linux-libc-headers or lower minimal kernel, now we have 2.6.23
Oct 14 23:32:00 <JaMa> Heinervdm: It failed a bit later in gcc sanity check.. (could not find limits.h).. so instead of rebuilding old gcc I upgraded gcc to 4.4.1 and rebuiding shr/merge now again
Oct 15 00:28:19 <wireddd> so my htc hermes has a really similar processor to the freerunner, what do you think my chances are of getting openmoko's code working on my phone?
Oct 15 00:29:55 <PaulFertser> wireddd: you need kernel port which includes not only SoC part but also many other ICs. Also gsm is usually a problem. 
Oct 15 00:30:57 <wireddd> yeah, I figured that much, I know nothing about how gsm works, I'm sure that would be the hardest driver to write
Oct 15 00:31:35 <PaulFertser> wireddd: http://209.85.129.132/search?q=cache:o06wXwzZjrQJ:wiki.xda-developers.com/index.php%3Fpagename%3DHermes_Linux+htc+hermes+linux&cd=2&hl=en&ct=clnk
Oct 15 00:31:55 <wireddd> the free runner is a sc32442b and mine has a sc32442a
Oct 15 00:32:56 <PaulFertser> wireddd: s3c but yes. The differences are minor afaik, probably some pullup/downs on gpios. The kernel on your device already boots, read the link.
Oct 15 00:39:40 <wireddd> yeah, I 'll play with it later
Oct 15 01:44:15 <tmzt> just relalized smartq is like a giant gta02-core :)
Oct 15 01:51:59 <raster> minus bt, minus gsm, minus accelerometrs, minus gps...
Oct 15 01:52:08 <raster> well actually sorry - thats gta02
Oct 15 01:52:18 <raster> dont know what core has changed
Oct 15 01:52:29 <raster> but the smartq5 has by far a better cpu/soc
Oct 15 02:02:20 <tmzt> yeah, no bt
Oct 15 02:02:40 <tmzt> though with tiny btusb devices that might not be an issue
Oct 15 02:02:49 <tmzt> didn't know about lack of accels
Oct 15 02:11:21 <raster> it is nice tho
Oct 15 02:11:27 <raster> i have one
Oct 15 02:11:32 <raster> cheap and well features
Oct 15 02:11:56 <raster> i would adivse a lot of people who are hacking theri gta02s and think it is too slow- try a smartq5
Oct 15 02:12:10 <raster> thats half way between gta02 and real modern phones
Oct 15 02:12:12 <raster> :)
**** ENDING LOGGING AT Thu Oct 15 02:59:56 2009