**** BEGIN LOGGING AT Mon Oct 19 02:59:59 2009
Oct 19 05:01:55 <rebelThor> hey guys, anyone figure out how to build that elusive vala-dbus-binding-tool-native_git.bb yet? I still get No package 'gee-1.0' found
Oct 19 05:02:43 <TeLLuS> rebelThor: not yet
Oct 19 05:03:22 <rebelThor> TeLLuS: bummer.. and it looks like we're the only two persons having this issue, right ? at least I'm glad I'm not alone on this one..
Oct 19 05:09:25 <BillK> rebelThor: shot in the dark - remove then rebuild the vala packages its depending on - something
Oct 19 05:09:37 <BillK> is dragging it in.  Think I had this in the past
Oct 19 05:09:55 <BillK> and it was vala-native - not sure now - too long ago ...
Oct 19 05:10:28 <rebelThor> BillK: i know it might be a stupid question on my part, but what do you mean by removing them? bitbake -c clean package_name ?
Oct 19 05:17:03 <BillK> rebelThor: yes
Oct 19 05:17:47 <BillK> rebelThor: remove all that might be suspect, then make image and
Oct 19 05:17:59 <BillK> hope they get built again in the right order.
Oct 19 05:27:29 <TeLLuS> We have libgee installed and configure say it is missing (gee-1.0), I think there could be a problem in the configure, Maybe because of the 0.5 git name
Oct 19 05:32:52 <rebelThor> as a sidequestion, any way I can speed up or skip the step where it says NOTE: Handling BitBake files: | (5829/6959) [83 %] in bitbaking anything? it really takes a lot of time to perform that one :(
Oct 19 05:33:54 <mrmoku> TeLLuS, rebelThor: the missing thing is libgee-NATIVE
Oct 19 05:34:08 <mrmoku> and I'm adding a recipe for that now
Oct 19 05:34:18 * rebelThor loves mrmoku
Oct 19 05:34:19 <mrmoku> are you guys building shr/import org shr/merge?
Oct 19 05:34:58 <rebelThor> mrmoku: i have no idea :( how do I know which one is which lol
Oct 19 05:35:07 <mrmoku> TAsn: there probably is one major difference between your installation and my installation...
Oct 19 05:35:29 <mrmoku> I manually upgraded glib for my threading tests :P
Oct 19 05:35:42 <mrmoku> rebelThor: if you don't know... then shr/import
Oct 19 05:35:59 <mrmoku> shr/merge would have needed manual handcrafting :P
Oct 19 05:36:44 <rebelThor> mrmoku: guess so :) i just followed the rules on the wiki.. is shr/merge very difficult to achieve? or is there any guide around ?
Oct 19 05:36:59 <mrmoku> rebelThor: no guide... not needed
Oct 19 05:37:03 <mrmoku> it will be the default soon
Oct 19 05:39:22 <TeLLuS> mrmoku: Yes, we have no libgee-native , only libgee. Thanks for adding.
Oct 19 05:40:15 * rebelThor is curious on how to get shr/merge :>
Oct 19 05:40:58 <TeLLuS> or rather what is missing without it?
Oct 19 05:41:00 <mrmoku> rebelThor: you would have to switch the openembedded branch it is building
Oct 19 05:41:35 <rebelThor> mrmoku: yeah, i figured that much out :D where to switch it, well, that's beyond my guessing abilities :D
Oct 19 05:44:58 <mrmoku> rebelThor: either you cange shr/import to shr/merge in the toplevel Makefile and remove the shr-unstable tree
Oct 19 05:45:27 <mrmoku> or you manually checkout the shr/merge branch in shr-unstable/openembedded
Oct 19 05:45:53 <rebelThor> mrmoku: first one sounds easier, trying that now.. thank you!
Oct 19 05:48:50 <PaulFertser> DocScrutinizer-8: sorry, was asleep by that time already
Oct 19 05:52:45 <mrmoku> TeLLuS: as I probably will add the libgee-native to shr/merge only... I set a fixed rev for the vala-binding-tools thing
Oct 19 05:52:53 <mrmoku> make update and it should build...
Oct 19 06:06:32 <TeLLuS> ok
Oct 19 06:07:27 <blindcoder> good morning
Oct 19 06:07:47 <blindcoder> is there a way to tell shr-messages to use the *phone fields from the contacts to look for a phone number?
Oct 19 06:08:11 <blindcoder> For example, since I used PISI I have 'Work phone' , 'Cell phone', 'Home phone' but shr-messages seems to just check against 'Phone'
Oct 19 06:20:01 <PaulFertser> blindcoder: is there shr-messages version with opimd support already?
Oct 19 06:25:38 <blindcoder> PaulFertser: sorry, I meant opimd-messages
Oct 19 06:26:15 <blindcoder> PaulFertser: I'm currently hacking opimd-messages to check for all 4 fields, but if there'll be a fifth field, it'll suck again :(
Oct 19 06:34:38 * TAsn hates mrmoku|away :)
Oct 19 06:34:43 <TAsn> mrmoku|away, I have to to to work
Oct 19 06:34:47 <TAsn> though I'll test that soon.
Oct 19 06:46:19 <blindcoder> here you go: http://pallas.crash-override.net/~blindcoder/opmidpisicompat.patch
Oct 19 06:46:35 <blindcoder> opimd-messages now talks with the syntax pisi uses
Oct 19 06:49:22 <rebelThor> blindcoder: not very familiar with the whole architecture and stuff, but it looks like opimd might need to know what fields it currently has (like cell, home, work,etc) and other programs would get it using a function call or something? this would allow any kind of extension... just a thought :D
Oct 19 06:50:51 <tmzt> pisi?
Oct 19 06:51:05 <blindcoder> rebelThor: other programs get it via a dbus call, but the dbus call says: Get me the contacts where 'Phone' has the value <number>
Oct 19 06:51:08 <tmzt> rebelThor: dbus?
Oct 19 06:51:42 <blindcoder> tmzt: pisi can synch .vcf, opimd, ldap, syncml and google contacts
Oct 19 06:51:51 <tmzt> what is it?
Oct 19 06:51:53 <tmzt> cool
Oct 19 06:52:02 <tmzt> what's it written in?
Oct 19 06:52:19 <blindcoder> tmzt: unfortunately, it'll use 'Home phone', 'Work phone', 'Cell phone'
Oct 19 06:52:23 <tmzt> google contacts with gdata or activesync/airsync?
Oct 19 06:52:31 <blindcoder> tmzt: no idea, just ran it once to synch my old .vcf to opimd
Oct 19 06:52:54 <blindcoder> tmzt: http://projects.openmoko.org/tracker/index.php?func=detail&aid=279&group_id=156&atid=673
Oct 19 06:52:59 <tmzt> ok
Oct 19 06:53:02 <tmzt> I'll look
Oct 19 06:53:12 <blindcoder> python I'm afraid
Oct 19 06:53:30 <tmzt> same as conduit
Oct 19 06:53:34 <tmzt> wonder how it works
Oct 19 06:55:32 <blindcoder> bbl
Oct 19 07:14:24 <JaMa> rebelThor: BB_SRCREV_POLICY="cache" to conf/local.conf for large speedup
Oct 19 07:14:45 <rebelThor> JaMa: thanks a lot
Oct 19 07:16:02 <JaMa> mrmoku|away: 1.7.1-rc2, libX11-1.3.1.. do you want them also for shr/import? I'll test it only in shr/merge...
Oct 19 07:43:44 <mrmoku> JaMa: we should really concentrate on shr/merge
Oct 19 07:44:08 <mrmoku> JaMa: one problem I have in shr/merge is that limiting locales to en_US does not work
Oct 19 07:44:17 <mrmoku> it wants to install en_GB into the image :|
Oct 19 07:52:18 <JaMa> thats minor issue for me as frameworkd doesn't work here :/
Oct 19 07:52:57 <JaMa> mrmoku: sqlite.so segfaults in opim and othere parts of framework fail because of python-ctypes errors
Oct 19 07:55:21 <mrmoku> ouch
Oct 19 07:55:51 <mrmoku> mickeyl: ^^^ any hint?
Oct 19 07:59:08 <JaMa> mrmoku: probably not fso fault
Oct 19 07:59:11 <JaMa> we had Size: 180076
Oct 19 07:59:11 <JaMa> Filename: python-ctypes_2.6.2-ml7.1_armv4t.ipk
Oct 19 07:59:36 <JaMa> and shr/merge Size: 136236
Oct 19 07:59:36 <JaMa> Filename: python-ctypes_2.6.2-ml8.0_armv4t.ipk
Oct 19 07:59:46 <JaMa> maybe some files are just missing
Oct 19 07:59:59 <JaMa> frameworkd.log http://pastebin.ca/1629060
Oct 19 08:02:03 * mrmoku remembers some strange python-ctypes problems in the past...
Oct 19 08:05:39 <Weiss> did someone ping me? (not enough scrollback...)
Oct 19 08:08:39 <mrmoku> JaMa!n=martin@161-24.13.24.78.awnet.cz: Weiss: cc1: warnings being treated as errors
Oct 19 08:08:53 <mrmoku> (17-10-2009 02:06:06)
Oct 19 08:12:43 <JaMa> Weiss: I have patch for this..
Oct 19 08:12:48 <Weiss> did I break something?
Oct 19 08:13:46 <JaMa> Weiss: not you.. just that warning seems reasonable, I'm not sure where do you expect pScrn to initialize http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=7de5b4216f0916b4e03b6c8297d95bfc21ba3aa7
Oct 19 08:17:45 <Weiss> hmm.. if you do that, do you get any KMS/non-KMS message at all?
Oct 19 08:20:00 <CIA-26> SHR: 03mok 07phoneui-apps * rc27e620302d0 10/data/Makefile.am: remove superfluous backslash in data/Makefile.am
Oct 19 08:20:35 <Weiss> I think I may have been a little bit dim while writing that function..
Oct 19 08:25:53 <mrmoku> mickeyl: configure.ac:84: required file `vapigen/Makefile.in' not found
Oct 19 08:26:04 <mrmoku> is what I get with your vala tarball...
Oct 19 08:26:10 <JaMa> Weiss: no.. not at all now
Oct 19 08:27:02 <Weiss> http://git.bitwiz.org.uk/?p=xf86-video-glamo.git;a=commitdiff;h=f9ad3d94703932c94182d5eac15c887e54133857
Oct 19 08:28:08 <JaMa> Weiss: much better, thanks
Oct 19 08:28:27 <Weiss> no problem :)
Oct 19 08:28:58 <Weiss> JaMa: I'm about to push a whole load of goodies out onto the Mesa branch, but I'd hold off testing for now (it doesn't work)
Oct 19 08:29:07 <Weiss> also the libdrm rebase
Oct 19 08:31:42 <JaMa> Weiss: great
Oct 19 08:48:26 <Deubeuliou> I'm trying to compile libfsobasics on debian lenny but it misses sys/eventfd.h. It is "vapi'd" in linux26.vapi and required by the configure.ac.  However, it is only used, in libfsobasics' sources, by utilities.vala in a "EventFd" class. And this class isn't used anywhere
Oct 19 08:48:49 <Deubeuliou> So I'm wondering what is eventfd required for ?
Oct 19 09:00:30 <ameyp> while building an image from source, how can i force it to use the local files for everything and not connect to svn?
Oct 19 09:00:44 <ameyp> the guide on the wiki only talks about overriding a particular recipe
Oct 19 09:01:16 <Weiss> ameyp: are you trying to use OE without a network connection?
Oct 19 09:01:38 <ameyp> Weiss: i have a network connection. just not a very good one
Oct 19 09:01:47 <Weiss> I found that to make that work, I only had to alter one recipe which tried to connect to the internet during parsing of the BB files
Oct 19 09:02:23 <ameyp> well, i don't know much about recipes, so could you tell me how to do it?
Oct 19 09:03:30 <Weiss> I did this: in recipes/epdfview/epdfview_svn.bb, comment out the line "SRCREV = "${AUTOREV}"" (with a "#")
Oct 19 09:04:11 <Weiss> perhaps it'll still try to connect if you're online, though
Oct 19 09:04:48 <ameyp> my build process gets stuck at 1% for a while and then gives a bunch of timeouts
Oct 19 09:05:03 <ameyp> i don't think it's reaching epdf, but i'll give it a shot
Oct 19 09:05:34 <ameyp> pythm_svn.bb is where it's getting stuck for the first time
Oct 19 09:05:52 <ameyp> i'll just ifdown then, thanks
Oct 19 09:09:45 <Heinervdm> you have to download the source for every package first and then set all AUTOREV'd packages the the revision you downloaded 
Oct 19 09:10:07 <mrmoku> too late :P
Oct 19 09:10:33 <Heinervdm> oh :)
Oct 19 09:10:51 <Heinervdm> mrmoku: did you try to build an shr/merge image?
Oct 19 09:11:05 <mrmoku> yup
Oct 19 09:11:23 <Heinervdm> and?
Oct 19 09:11:23 <mrmoku> fails because it wants to install en_GB locale
Oct 19 09:11:30 <mrmoku> and I limited locales to en_US :(
Oct 19 09:12:19 <DocScrutinizer-8> en_GB, hehe - I like that ;-P
Oct 19 09:12:19 <Heinervdm> why is there a local hardcoded? i noticed that for shr/import too, when i tried to build an image with de_DE :)
Oct 19 09:13:26 <JaMa> Weiss: can I use KMS with drm and glamo-drm as module in kernel?
Oct 19 09:14:06 <DocScrutinizer-8> maybe to teach those bloody Americans to talk a correct English
Oct 19 09:14:31 <JaMa> Weiss: I merged your gta02_drm_defconfig with newer gta02_packaging_defconfig, then enabled ubifs for testing and changed drm to modules as I want to see if it will resolve my wsod issue
Oct 19 09:16:44 <JaMa> ameyp, Heinervdm: first try with BB_SRCREV_POLICY="cache" to conf/local.conf for large speedup
Oct 19 09:17:15 <Heinervdm> JaMa: he is gone ;)
Oct 19 09:17:50 <PaulFertser> DocScrutinizer-8: hehe
Oct 19 09:17:52 <JaMa> I noticed too late.. and as I had it already written... maybe he will find out in logs :)
Oct 19 09:20:25 * DocScrutinizer-8 wonders if WSOD still around, with powering down LCM_VDD in PMU, and setting al glamo lines to LCM to 0V
Oct 19 09:21:10 <DocScrutinizer-8> should be killed for good, since almost a year
Oct 19 09:22:26 <DocScrutinizer-8> but maybe another case of "fixing" things fubar... dunno
Oct 19 09:24:01 <JaMa> DocScrutinizer-8: I have it only with glamo-drm enabled
Oct 19 09:24:26 <DocScrutinizer-8> whatever glamo-drm may be
Oct 19 09:25:59 <JaMa> DocScrutinizer-8: stuff from Weiss KMS enabled branch
Oct 19 09:27:26 <DocScrutinizer-8> JaMa: I have no slightest idea if that glamo-drm is aware of the mandatory disabling of glamo-outputs during lcm-suspend
Oct 19 09:35:53 <DocScrutinizer-8> (locale) tbh I don't get it why we need one particular locale at all (for buildprocess). LANG=C should suffice, no?
Oct 19 09:43:51 <blindcoder> anyone here familiar with automake?
Oct 19 09:46:28 * DocScrutinizer-8 hides and starts shivering
Oct 19 09:47:32 <DocScrutinizer-8> ~lart autotools
Oct 19 09:47:33 * apt pushes the wall down onto autotools whilst whistling innocently
Oct 19 09:48:57 <blindcoder> hrm
Oct 19 09:48:58 <blindcoder> :P
Oct 19 09:49:27 <blindcoder> I have it compiling my app, but now I need it to install a default rc file but can't find usable documentation
Oct 19 09:49:29 <mrmoku> blindcoder: I'm faaaar from being familiar with it... but just ask... maybe someone knows :)
Oct 19 09:49:38 <mrmoku> ahh
Oct 19 09:51:00 <Weiss> JaMa: you won't get a console until the module is loaded, but it might work.. not sure, though
Oct 19 09:52:02 <Weiss> DocScrutinizer-8 / JaMa: yep, KMS does the pixel clock disabling thing as well. maybe there's something I missed, though
Oct 19 09:52:02 <mrmoku> blindcoder: desktopdir = $(datadir)/applications
Oct 19 09:52:02 <mrmoku> dist_desktop_DATA = phoneui-contacts.desktop \
Oct 19 09:52:02 <mrmoku> EXTRA_DIST = $(desktop_DATA)
Oct 19 09:52:06 <mrmoku> is what we do for desktoop files...
Oct 19 09:52:13 <mrmoku> might work with anything else too 
Oct 19 09:52:53 <DocScrutinizer-8> Weiss: you need to switch *all* lines running to lCM to either low or input
Oct 19 09:55:00 <DocScrutinizer-8> Weiss: please refer to schematics not to miss a single line which then may reverse-feed LCM, thus blocking a decent total reset and causing WSOD
Oct 19 09:56:13 * Weiss will check
Oct 19 09:56:32 <Weiss> I templated the KMS code from the previous glamo-fb code though, but maybe I missed something
Oct 19 09:57:08 <DocScrutinizer-8> Weiss: the rationale was we (OM) ever seen a single report of WSOD on boot. So we tried to make suspend/resume absolutely identical to full powercycling for POV of LCM
Oct 19 09:58:03 <DocScrutinizer-8> Weiss: I'm *not* sure the previos glamo-fb code was (still?) correct wrt that
Oct 19 09:58:44 <Weiss> but it was at some previous point?
Oct 19 09:58:56 <Weiss> or it is in more recent versions?
Oct 19 09:59:14 <DocScrutinizer-8> Andy stated it was, around 2008-12
Oct 19 10:00:00 <DocScrutinizer-8> probably nobody ever proofread this, and nobody took care after Andy left
Oct 19 10:01:12 <Weiss> DocScrutinizer-8: have to go and help with something at work now, but I might ask you some more questions about this later..
Oct 19 10:01:30 <DocScrutinizer-8> yw. go ahead
Oct 19 10:18:11 <blindcoder> mrmoku: found it
Oct 19 10:18:13 <blindcoder> mrmoku: etcdir = @sysconfdir@
Oct 19 10:18:16 <blindcoder> mrmoku: etc_DATA = fltkworldclockrc
Oct 19 10:18:43 <blindcoder> getting a SYSCONFDIR #define'd was a bit nastier, though
Oct 19 10:28:05 <blindcoder> mrmoku: thanks for the desktop lines. s/desktop/foo/ and you can do it for everything else, too
Oct 19 10:28:28 <blindcoder> mrmoku: foodir = xxx \n foo_DATA = yyy \n  and yyy will be installed into xxx directory
Oct 19 11:17:58 <JaMa> ERROR: Cannot satisfy the following dependencies for task-x11-illume: libdrm (>= 2.4.15+gitr1+fdd960a95cca00b19d912a437a2ca3e69fee017e)
Oct 19 11:18:25 <JaMa> changing SCM url in recipe resets SRCPV sequence :/ was it the same in shr/import?
Oct 19 11:18:38 <JaMa> probably yes but I haven't noticed
Oct 19 11:19:56 <mrmoku> JaMa: uhhh... another nastiness regarding git SRCREVs...
Oct 19 11:22:28 <JaMa> maybe srcrev cache should be handled based on recipe path and SCM uri or something like that, instead of just SCM uri
Oct 19 11:32:20 <blindcoder> test -z "/usr/share/pixmaps" || /bin/mkdir -p "/home/blindcoder/SHR/shr-unstable/tmp/work/armv4t-angstrom-linux-gnueabi/fltkclock-41-r0/image/usr/share/pixmaps"
Oct 19 11:32:23 <blindcoder> wtf?
Oct 19 11:34:00 <JaMa> what's wrong with that?
Oct 19 11:34:33 <blindcoder> JaMa: shouldn't the first path also be "/home/..."?
Oct 19 11:34:44 <blindcoder> that's part of make install output
Oct 19 11:35:04 <JaMa> it depends how its used later I would say
Oct 19 11:35:27 <JaMa> if its something like PIXMAP_PREFIX
Oct 19 11:36:35 <blindcoder> hmm, guess you're right
Oct 19 11:36:53 <JaMa> and later its used ${ROOT}${PIXMAP_PREFIX} and ${ROOT} is expected to exist always
Oct 19 11:36:57 <blindcoder> is there a way to check which files get packaged into an .ipk without installing it?
Oct 19 11:37:07 <blindcoder> JaMa: yes, I see it now :)
Oct 19 11:37:08 <tmzt> blindcoder: ipkg files *.ipkg
Oct 19 11:37:12 <tmzt> *.ipk
Oct 19 11:37:39 <tmzt> or you can always ar x it
Oct 19 11:37:39 <tmzt> and tar tf data.tar.gz
Oct 19 11:37:39 <JaMa> blindcoder: I sometimes ar x and untar it
Oct 19 11:37:40 <JaMa> :) as tmzt 
Oct 19 11:38:04 <blindcoder> I'll try that
Oct 19 11:38:09 <blindcoder> the ipkg is surprisingly small
Oct 19 11:38:13 <blindcoder> just 20 kB
Oct 19 11:38:20 <blindcoder> before I switched to autotools it was >100
Oct 19 11:40:42 <blindcoder> hmm... all the files are there
Oct 19 11:42:12 <blindcoder> binary is much smaller
Oct 19 11:43:04 <blindcoder> about 10% as large
Oct 19 11:43:08 <blindcoder> aah
Oct 19 11:43:29 <blindcoder> fltk-config gives libfltk.a, but now it links only against libfltk.so
Oct 19 11:43:39 <blindcoder> that would explain
Oct 19 11:46:54 <JaMa> mrmoku: confirmed that image creation is checked for errors in shr/merge :) so no more unmet dependencies..
Oct 19 11:46:57 <JaMa> log_check: Using /home/projects/OE/tmpdir-dev-shr/work/om-gta02-angstrom-linux-gnueabi/shr-image-2.0-r4/temp/log.do_rootfs.6042 as logfile
Oct 19 11:47:00 <JaMa> log_check: There were error messages in the logfile
Oct 19 11:47:03 <JaMa> log_check: Matched keyword: [Cannot satisfy the following dependencies]
Oct 19 11:48:04 <JaMa> but why does task-x11-illume still depend on libdrm (>= 2.4.15+gitr1+fdd960a95cca00b19d912a437a2ca3e69fee017e) even after do_clean in task-x11-illume :(
Oct 19 11:48:23 <mrmoku> yup, that is a good thing :)
Oct 19 11:49:18 <JaMa> is there any better way to fix this or just increment PV or even PE as PV is right now..
Oct 19 11:50:52 <mrmoku> JaMa: did you try to clean task-x11-illume?
Oct 19 11:51:18 <mrmoku> JaMa: btw... what is PE?
Oct 19 11:51:49 <JaMa> package epoch probably, its most important part of version
Oct 19 11:52:11 <JaMa> mrmoku: bitbake -c clean -b ..path_to_recipe
Oct 19 11:52:33 <mrmoku> ahh, ok... and is not visible...
Oct 19 11:52:50 <JaMa> mrmoku: but PE probably creates package names like libegl1 libegl2 etc
Oct 19 11:53:10 <JaMa> PNPE_PVPR maybe
Oct 19 11:53:26 <JaMa> I'll set it in libdrm and we'll see
Oct 19 11:54:15 <JaMa> then I'll send cookies
Oct 19 11:56:01 <mrmoku> ok :)
Oct 19 11:59:52 <Tanuva> can I make the current shr-messages app use the sqlite backend instead of the sim?
Oct 19 12:03:58 <blindcoder> Tanuva: use opimd-messages
Oct 19 12:04:25 <baruch> mrmoku, when are you going to make shr-u unstable again? It's been too stable and I actually manage to use the phone at times, this is hardly a good situation!
Oct 19 12:04:46 <baruch> I used to have a perfect reason why I don't answer calls and now I lost that excuse
Oct 19 12:05:44 <mrmoku> baruch: TAsn and I are working hard to break it again ;)
Oct 19 12:06:18 <JaMa> mrmoku: libdrm-1_2.4.15+gitr0 so PN-PE_PV
Oct 19 12:06:58 <mrmoku> and PE=0 is omitted
Oct 19 12:07:05 <mrmoku> and default 
Oct 19 12:07:19 <JaMa> yes
Oct 19 12:08:11 <rebelThor> damn, anything I can clear during the build process, I seem to be running out of space on the partition I'm performing the build on :D
Oct 19 12:09:03 <rebelThor> nevermind, just reached 0, canceled it `till I find a way to increase the space
Oct 19 12:09:42 <JaMa> rebelThor: build part by part like virtual/kernel then shr-lite-image then shr-image
Oct 19 12:10:16 <JaMa> rebelThor: it will clean workdir in the end of task queue
Oct 19 12:10:34 <rebelThor> JaMa: thanks, will try
Oct 19 12:10:54 <JaMa> rebelThor: or you can finish few packages by hand to save some space now.. but first try to finish virtual/kernel
Oct 19 12:11:19 <rebelThor> JaMa: is "bitbake -c build virtual/kernel" going to work ?
Oct 19 12:11:26 <JaMa> rebelThor: it can clean much (cross and build tools and lots of -native stuff)
Oct 19 12:11:37 <JaMa> you don't need -c build
Oct 19 12:11:49 <JaMa> just bitbake virtual/kernel
Oct 19 12:11:51 <rebelThor> oh, ok
Oct 19 12:12:10 <mrmoku> TAsn: ping
Oct 19 12:12:53 <rebelThor> JaMa: what about clearing the "downloads" folder?
Oct 19 12:15:23 <JaMa> if you don't care about downloading again if you need to rebuild something.. then ok..
Oct 19 12:16:23 <JaMa> but I don't know about tool like eclean-dist in gentoo which could be used to remove only older source tarballs or not used tarballs
Oct 19 12:18:44 <rebelThor> JaMa: you rock, building the virtual/kernel sure did clear up about 1.5GB of space.. thanks :)
Oct 19 12:33:22 <Weiss> JaMa: r.e. WSoD with KMS: the 2.6.31 glamo-fb disables Glamo's LCD engine in its own suspend hook, whereas the KMS version just saves the pixel timings and switched jbt6k74 off and lets glamo-core disable the LCD engine. That's possibly what's causing it
Oct 19 12:34:16 <tmzt> Weiss: shoudln't fb be a client of kms?
Oct 19 12:34:52 <Weiss> "glamo-kms-fb" is, glamo-fb isn't (that's the old-style framebuffer)
Oct 19 12:34:54 <Weiss> "old-style"
Oct 19 12:35:47 <Weiss> when you configure the kernel, you choose between glamo-fb or KMS+glamo-kms-fb
Oct 19 12:36:04 <Weiss> (you could theoretically have KMS without glamo-kms-fb, and it's work fine, just no console)
Oct 19 12:39:36 <JaMa> Weiss: strange that it doesn't happen with your setup
Oct 19 12:40:15 <JaMa> Weiss: so what should be tested first? suspend with drm module unloaded? or something else?
Oct 19 12:42:11 <Weiss> try sticking a "__glamo_engine_disable(gdrm->glamo_core, GLAMO_ENGINE_LCD);" at the end of glamo_display_suspend() in glamo-display.c
Oct 19 12:42:34 <Weiss> (maybe the jbt6k74 line needs to move to the end after that?)
Oct 19 12:45:35 <PaulFertser> Weiss: the idea about preventing WSOD is to just cut all the power to glamo, including all the data lines that can feed (and lock up) the chip when its Vcc is turned off.
Oct 19 12:46:12 <cz_jc> glamo even feeds off of data lines ?
Oct 19 12:46:51 <cz_jc> PaulFertser, so basically, you even have to turn off the damn usd card ?
Oct 19 12:47:13 <cz_jc> just to reset glamo completely
Oct 19 12:47:54 <PaulFertser> cz_jc: oh
Oct 19 12:48:18 <Weiss> PaulFertser: just to be clear, you mean the whole chip and not just the LCD engine?
Oct 19 12:48:21 <PaulFertser> cz_jc: indeed that method is not useful for display blanking. But when you suspend the whole device you can safely turn off all glamo.
Oct 19 12:48:50 <cz_jc> PaulFertser, hmm that would mean suspend would be solution for WSOD then, wouldn't it 
Oct 19 12:48:54 <PaulFertser> Weiss: both the glamo chip and jbt6k74 should be off in suspend i guess.
Oct 19 12:49:47 <cz_jc> btw. when it did happen to me, it was usually when I used xrandr to rotate screen during big CPU load times
Oct 19 12:50:00 <Weiss> PaulFertser: according to the version of glamo-core.c I have in front of me, power to Glamo remains but the PLLs etc. are fiddled with
Oct 19 12:51:00 <PaulFertser> Weiss: i seem to remember that the problem was mainly with jbt6k itself and not glamo, so probably ensuring jbt6k can't get power from anywhere is enough.
Oct 19 12:51:56 <PaulFertser> Weiss: anyway i think larsc has quite some experience with that, he even has rewritten kernel state machine for this stuff (combining glamo and jbt6k together).
Oct 19 12:52:01 <PaulFertser> iirc
Oct 19 12:52:09 <Weiss> yeah, I noticed the 2.6.31 version is different
Oct 19 12:52:33 <alexxy> hi all!
Oct 19 12:52:36 <Weiss> moulding the KMS stuff to fit the 2.6.31 branch may make this all work
Oct 19 12:52:58 <alexxy> if i'd like to switch to next shr unstable what branch should i use
Oct 19 12:53:00 <JaMa> eolson: I can wait for 2.6.31 if you don't have time to help me debug this in 2.6.26..
Oct 19 12:53:17 <alexxy> seems in http://build.shr-project.org/tests/mrmoku there more then one 
Oct 19 12:53:22 <JaMa> alexxy: really next? now experimental one?
Oct 19 12:53:33 <JaMa> alexxy: shr/merge is our experimental one
Oct 19 12:53:44 <alexxy> JaMa: or experimental one
Oct 19 12:53:45 <alexxy> =)
Oct 19 12:54:01 <alexxy> JaMa: is it usable?
Oct 19 12:54:09 <JaMa> alexxy: shr/import is used shr-unstable with Xorg but not as experimental as shr/merge
Oct 19 12:54:27 <JaMa> alexxy: not as phone now.. but it'll be fixed in few days I hope
Oct 19 12:54:48 <alexxy> http://build.shr-project.org/tests/mrmoku/feed/ <- what is here
Oct 19 12:55:01 <alexxy> and here http://build.shr-project.org/tests/mrmoku/unstable/
Oct 19 12:55:02 <alexxy> ?
Oct 19 12:55:29 <alexxy> and here http://build.shr-project.org/tests/mrmoku/shr-kms/ 
Oct 19 12:55:30 <alexxy> =)
Oct 19 12:56:03 <JaMa> alexxy: you want to switch existing installation or reflash new image?
Oct 19 12:56:12 <JaMa> alexxy: dont upgrade existing ...
Oct 19 12:56:14 <alexxy> i want to switch existing one
Oct 19 12:56:24 <JaMa> alexxy: shr-kms is just another kernel from shr/merge KMS-enabled
Oct 19 12:56:51 <JaMa> alexxy: upgrade-path is not tested and probably doesn't work
Oct 19 12:57:10 <alexxy> JaMa: can you describe branches?
Oct 19 12:57:20 <alexxy> http://build.shr-project.org/tests/mrmoku/feed/ 
Oct 19 12:57:26 <alexxy> http://build.shr-project.org/tests/mrmoku/unstable/
Oct 19 12:58:06 <JaMa> alexxy: ask mrmoku.. he manages it in buildhost..
Oct 19 12:58:22 <JaMa> alexxy: i'm sure only about oemerge and shr-kms
Oct 19 12:58:36 <alexxy> mrmoku: ?? ^^^
Oct 19 12:59:50 <JaMa> alexxy: and in git shr/import is used for shr-testing and shr-unstable but about a month ago there was change to Xorg and mrmoku started to build shr-unstable to tests
Oct 19 12:59:54 <alexxy> Ainulindale: hi. do you know something about this branches? ^
Oct 19 13:00:23 <Ainulindale> Sorry but I'm utterly unavailable right now :-)
Oct 19 13:00:24 <JaMa> alexxy: then started shr/merge with stuff from shr/import also with Xorg from start but tracking oe.dev
Oct 19 13:00:57 <alexxy> hmmm
Oct 19 13:00:58 <JaMa> alexxy: download and check content of angstrom-version*ipk from all dirs and find yourself :)
Oct 19 13:01:40 <JaMa> http://build.shr-project.org/tests/mrmoku/feed/ is from shr/import
Oct 19 13:03:07 <mrmoku> alexxy: tests/mrmoku/feed == tests/mrmoku/unstable/feed
Oct 19 13:03:34 * mrmoku should finally remove that one ;)
Oct 19 13:04:17 <alexxy> mrmoku: so what branch can be usable as phone?
Oct 19 13:07:09 <mrmoku> alexxy: tests/mrmoku/unstable is what some of us use as daily phone
Oct 19 13:07:34 <alexxy> mrmoku: ok then i made right chois 
Oct 19 13:07:35 <alexxy> =)
Oct 19 13:07:36 <mrmoku> (which equals shr/import branch for now)
Oct 19 13:13:44 <Arigead> mrmoku: I'm very close to moving my "real" sim to the OpenMoko with tests/mrmoku/unstable it seems very stable.
Oct 19 13:16:41 <CIA-26> SHR: 03mok 07phonefsod * r14534e1f3c46 10/src/phonefsod.c: don't quit mainloop on unknow signals (which seems to happen on suspend)
Oct 19 13:16:43 <mrmoku> Arigead: nice to hear :)
Oct 19 13:18:35 <CIA-26> SHR: 03mok 07phoneuid * reff7833429c0 10/data/ (5 files): give the dbus activation config an User entry - we're on system bus again
Oct 19 13:21:13 <tmzt> http://members.lycos.nl/phunbringer/tmp/linuxm8howto.txt
Oct 19 13:21:24 <Arigead> mrmoku: Must have a look at trac and try and help out. Been building libframeworkd-phonegui-efl2 and getting my head around the code. Think a few things I'd change are possibly in illume though.
Oct 19 13:21:27 <tmzt> (Meizu, in contacts with some people but not vendors)
Oct 19 13:23:22 <baruch> mrmoku, can web-manager be added to the shr feeds? it's an autotools source package so the bb recipe should be simple enough
Oct 19 13:23:55 <baruch> I got a complaint that my package from shr-u doesnt work on whatever the user has which I assume is some form of tests/mrmoku feed
Oct 19 13:28:34 <rebelThor> JaMa: heh, removing the downloads wasn't such a good idea, i've got an error with a non-existing file, git_git.freesmartphone.org.framework.git_043cef6d2122bb62dcbae3211ed94c21d9c7d901.tar.gz , anyone know where I can download it from?
Oct 19 13:28:52 <baruch> mrmoku, web-manager lives at http://github.com/baruch/web-manager
Oct 19 13:29:09 <CIA-26> SHR: 03mok 07phoneuid * r2834fe83f017 10/src/phoneuid.c: give the logger back the nicer timestamp and log domain instead of hardcoded phoneui
Oct 19 13:30:32 <mrmoku> baruch: ok, will do a recipe for it
Oct 19 13:31:12 <mrmoku> baruch: do you commit only when it compiles fine? or shall we set a fixed rev and you ping us when it's time to bump?
Oct 19 13:31:53 <baruch> mrmoku, I only push upstream when it works fine
Oct 19 13:31:59 <JaMa> rebelThor: did you removed also file ending with md5 or something like that?
Oct 19 13:32:09 <rebelThor> JaMa: yeah...
Oct 19 13:32:21 <CIA-26> SHR: 03mok 07phonefsod * r37571dc5ce4a 10/src/phonefsod.c: use fopen and strftime for logging
Oct 19 13:32:26 <mrmoku> baruch: ok, good... will set it to AUTOREV then
Oct 19 13:32:28 <JaMa> rebelThor: then it should try to download it later..
Oct 19 13:32:42 <baruch> mrmoku, great, thanks!
Oct 19 13:32:54 <JaMa> rebelThor: first it looks for tarballed snapshots.. and then it downloads it with git clone
Oct 19 13:33:25 <JaMa> mrmoku: I've found out where python-ctypes problem is.. maybe you'll remember how to fix it..
Oct 19 13:33:32 <JaMa> mrmoku: Only in /media/om/usr/lib/python2.6: lib-dynload/_ctypes.so
Oct 19 13:33:32 <JaMa> Only in /media/om/usr/lib/python2.6: lib-dynload/_ctypes_test.so
Oct 19 13:33:35 <baruch> If I'm in the mode for asking, a vala package would be nice as well, I currently use the vapis from my desktop and not the ones from the moko and there are some that would make my life easier
Oct 19 13:33:39 <rebelThor> JaMa: hmm, well, the whole process stopped, ERROR: TaskFailed event exception, aborting, going to try it again in a sec
Oct 19 13:33:52 <JaMa> where /media/om is partition with older shr-unstable from shr/import :)
Oct 19 13:33:56 <baruch> I remember vaguely looking for the glib jsob vapi
Oct 19 13:34:08 <baruch> s/jsob/json/
Oct 19 13:34:08 <apt> baruch meant: I remember vaguely looking for the glib json vapi
Oct 19 13:34:54 <JaMa> rebelThor: if your build process failed between tasks fetch and unpack, then maybe you have to call bitbake -c clean for those failing recipes
Oct 19 13:35:03 <rebelThor> JaMa: thanks
Oct 19 13:35:11 <baruch> ooooh, and I wanted to look at using upstart for the init process, though I guess for that I'd better figure out how to build the oe tree and use it directly
Oct 19 13:39:22 <JaMa> mrmoku: and from python do_compile log Failed to configure _ctypes module (res=16128) or missing conffile=build/temp.linux-x86_64-2.6/libffi/fficonfig.py
Oct 19 13:39:23 <mrmoku> baruch: mmmhhh... upstart
Oct 19 13:39:43 * mrmoku is interested in upstart too :)
Oct 19 13:39:45 <JaMa> mrmoku: looking for buildhost shr-image if its included there...
Oct 19 13:39:51 <mrmoku> JaMa: hmm... I grepped my irc logs... and didn't find anything
Oct 19 13:40:06 <mrmoku> JaMa: let me first check my local build
Oct 19 13:40:32 <JaMa> mrmoku: i thing libffi is removed from source and system libffi should be used
Oct 19 13:41:41 <JaMa> ah not removed.. just something passed there for arm[67]
Oct 19 13:42:58 <mrmoku> have the same in my log
Oct 19 13:43:59 <JaMa> and no _ctypes in lib-dynload in package?
Oct 19 13:45:11 <mrmoku> JaMa: in which log?
Oct 19 13:45:49 <JaMa> mrmoku: work/armv4t-angstrom-linux-gnueabi/python-2.6.2-ml8.0/temp/log.do_compile.25490
Oct 19 13:46:39 <mrmoku> then no
Oct 19 13:46:51 <mrmoku> *** WARNING: renaming "_ctypes_test" since importing it failed: build/lib.linux-x86_64-2.6/_ctypes_test.so: wrong ELF class:
Oct 19 13:47:04 <mrmoku> and
Oct 19 13:47:05 <mrmoku> Failed to configure _ctypes module (res=16128) or missing conffile=build/temp.linux-x86_64-2.6/libffi/fficonfig.py
Oct 19 13:47:13 <mrmoku> are the only _ctypes I have in my log
Oct 19 13:47:33 <JaMa> you have 64bit too .. buildhost is x86?
Oct 19 13:47:39 <mrmoku> no 64bit
Oct 19 13:48:57 <JaMa> maybe its because our new binutils.. or something like that :/
Oct 19 13:49:31 <mrmoku> building a distro is quite complicated :P
Oct 19 13:51:08 <JaMa> I'll rebuild python from shr/import to see log difference
Oct 19 13:51:27 <mrmoku> JaMa: I have shr/import logs around... let me check
Oct 19 13:52:35 <alexxy> mrmoku: also if you intrested in changiong init system you can take a look at openrc
Oct 19 13:52:45 <mrmoku> JaMa: difference is that it builds _ctypes
Oct 19 13:52:59 <mrmoku> though in the end it has it in the list of failed modules...
Oct 19 13:53:09 <JaMa> mrmoku: what about log_configure?
Oct 19 13:53:28 <JaMa> mrmoku: i diffed recipes but seems quite the same wrt ctypes
Oct 19 13:53:49 <mrmoku> no _ctypes in both configure logs
Oct 19 13:54:19 <mrmoku> but the module configure is in the compile log
Oct 19 13:54:36 <alexxy> JaMa / mrmoku : what better to use as frameworkd-phonegui?
Oct 19 13:55:34 <mrmoku> JaMa: aclocal.m4:14: error: this file was generated for autoconf 2.61.
Oct 19 13:55:35 <mrmoku> You have another version of autoconf.  If you want to use that,
Oct 19 13:55:35 <mrmoku> you should regenerate the build system entirely.
Oct 19 13:55:51 <mrmoku> alexxy: libphone-ui :)
Oct 19 13:56:08 <alexxy> hmm 
Oct 19 13:56:13 <JaMa> mrmoku: its from shr/merge I guess where we have autoconf 2.63
Oct 19 13:56:27 <alexxy> mrmoku: libframeworkd-phonegui-efl.so.0 or next version?
Oct 19 13:56:46 <mrmoku> alexxy: we're rewriting all of that right now
Oct 19 13:57:17 <mrmoku> alexxy: interested in code or in running stuff on the phone?
Oct 19 13:58:12 <JaMa> mrmoku: maybe easiest should be to move to python-2.6.3 :) hopefully configured by 2.63 too :)
Oct 19 13:58:45 <mrmoku> mickeyl: ping
Oct 19 13:59:13 <mrmoku> mickeyl: have to interrupt you in your iphone coding euphoria ;)
Oct 19 14:00:26 <mrmoku> JaMa: is that in oe.dev?
Oct 19 14:01:17 <alexxy> mrmoku: currently i'm intresting in phone
Oct 19 14:01:18 <alexxy> =)
Oct 19 14:01:33 <alexxy> but i cant test experimental stuff
Oct 19 14:02:00 <alexxy> http://dpaste.com/109277/
Oct 19 14:02:11 <alexxy> btw errors from xorg-server
Oct 19 14:02:14 <alexxy> ^^^
Oct 19 14:03:26 <JaMa> mrmoku: no..
Oct 19 14:03:53 <JaMa> alexxy: but then it starts, doesn't it?
Oct 19 14:04:01 <alexxy> yep
Oct 19 14:04:03 <alexxy> =)
Oct 19 14:04:06 <JaMa> alexxy: opkg install libegl1 will fix the message
Oct 19 14:04:08 <alexxy> but there are errors
Oct 19 14:04:29 <alexxy> JaMa: shouldnt it be added to xorg-server deps?
Oct 19 14:04:33 <JaMa> alexxy: not sure why its not included in image from RDEPENDS, mrmoku any idea? or maybe its just old build..
Oct 19 14:05:23 <Weiss> libgl1*
Oct 19 14:06:04 <Weiss> do you have the right input driver for the power button?
Oct 19 14:06:15 <Weiss> the AIGLX error shouldn't cause the server to bail out
Oct 19 14:06:27 <JaMa> Weiss: no there is libegl1 in shr/merge.. not sure where 'e' goes from
Oct 19 14:06:49 <Weiss> hmm.. what does it contain?
Oct 19 14:07:06 <Weiss> there's some EGL stuff in the latest Mesa, but we don't need/use/want it right now
Oct 19 14:07:10 <JaMa> Weiss: and that PreInit is because that event file is already used by something else.. happens here to
Oct 19 14:07:13 <JaMa> o
Oct 19 14:08:19 <Weiss> hmm, ok
Oct 19 14:08:20 <JaMa> Weiss: so maybe tha package is named wrong http://shr.pastebin.ca/1629768
Oct 19 14:08:57 <Weiss> hmm.. do you know which recipe creates that?
Oct 19 14:09:48 <JaMa> Weiss: its in mesa_git.bb as FILES_${PN} += dri.. but ${PN} is expanded to libegl not sure where.. checked mesa-common.inc etc without success
Oct 19 14:10:30 <Weiss> yeah, I'm looking at the same thing now..
Oct 19 14:10:32 <mrmoku> baruch: configure.ac:9: warning: macro `AM_PROG_VALAC' not found in library
Oct 19 14:10:36 <mrmoku> configure.ac:10: warning: macro `AM_SILENT_RULES' not found in library
Oct 19 14:11:01 <JaMa> Weiss: but kernel with drm_config but with DRM and GLAMO_DRM as modules it booted but Xorg didn't start.. console isn't shown too (probably as I did it remotely again).. because I disabled fbdev too as its in drm_config
Oct 19 14:12:03 <Weiss> did the DRM module get modprobe'd at any point?
Oct 19 14:12:33 <JaMa> no after start.. 
Oct 19 14:12:38 <JaMa> i modprobed it by hand now
Oct 19 14:13:11 <JaMa> and now I've WSOD probably.. when i launched Xorg :/
Oct 19 14:13:15 <Weiss> :(
Oct 19 14:13:24 <Weiss> after modprobe, X should be able to start
Oct 19 14:13:27 <JaMa> it doesn't respond to ping
Oct 19 14:13:39 <JaMa> but modprobe worked ok...
Oct 19 14:14:03 * mrmoku moving downstairs
Oct 19 14:14:03 <baruch> mrmoku, it works for me :-)
Oct 19 14:14:06 <mrmoku> ahh
Oct 19 14:14:38 <JaMa> Weiss: last output http://shr.pastebin.ca/1629777
Oct 19 14:14:38 <baruch> I guess I use a newer autotools 
Oct 19 14:14:38 <mrmoku> brb
Oct 19 14:14:38 <mrmoku> what version?
Oct 19 14:14:52 <JaMa> Weiss: more tests/debug later.. need physical access to reboot it :)
Oct 19 14:15:30 <JaMa> Weiss: are you using our shr/merge or shr/import branch or still yours?
Oct 19 14:15:32 <Weiss> ok, that looks like it went smoothly..
Oct 19 14:16:11 <Weiss> an old version of shr/import - I'm going to update fully soon (you've done a much better job of the recipes than I ever could)
Oct 19 14:16:39 <JaMa> Weiss: next time I'll launch Xorg by hand and see where it failed..
Oct 19 14:17:03 <alexxy> JaMa: it cannot find  libegl1
Oct 19 14:17:45 <JaMa> Weiss: strange that now it happend when launching Xorg after boot, not in resume time.. but maybe its simmilar problem when drm is initialized later as module as in resume
Oct 19 14:19:10 <alexxy> JaMa: is libphone-ui-shr usable?
Oct 19 14:19:17 <Weiss> JaMa: entirely possible..
Oct 19 14:19:18 <JaMa> alexxy: what did you installed? http://build.shr-project.org/tests/mrmoku/unstable/ ? there its maybe named something else..
Oct 19 14:19:25 <JaMa> alexxy: no idea about libphone-ui-shr
Oct 19 14:19:36 <alexxy> JaMa: yep  http://build.shr-project.org/tests/mrmoku/unstable/
Oct 19 14:19:47 <alexxy> just upgraded form shr-u
Oct 19 14:19:53 <alexxy> upgrade works
Oct 19 14:21:31 <JaMa> alexxy: seachr for mesa or libgl
Oct 19 14:21:49 <JaMa> alexxy: I'm not using it anymore..
Oct 19 14:22:14 <JaMa> because using broken shr/merge makes me fix issues faster :)
Oct 19 14:25:44 <alexxy> JaMa: is it usable as phone?
Oct 19 14:25:46 <JaMa> Weiss: also strange.. that I've seen this (WSOD during boot) after my pScrn patch added to xf86-video-glamo.. but I wasn't sure if I switched modules from non-KMS kernel to KMS ones.. so I switch kernel back to non-KMS and it booted ok again..
Oct 19 14:25:56 <JaMa> alexxy: as i said before then no..
Oct 19 14:26:08 <alexxy> unstable is usable =)
Oct 19 14:26:17 <JaMa> alexxy: but I've 4 sims and 3 phones.. so i can live with this setup :)
Oct 19 14:26:24 <alexxy> mrmoku:  libphone-ui is it usable?
Oct 19 14:26:35 <alexxy> JaMa: i have 2 phones
Oct 19 14:26:45 <mrmoku> alexxy: if you have 2 phones... test it :P
Oct 19 14:26:45 <alexxy> but i prefer neo as my primary one
Oct 19 14:26:52 <mrmoku> I'm actively working on it
Oct 19 14:26:57 <mrmoku> if you have a PIN on your SIM... wait
Oct 19 14:27:03 <mrmoku> (because I have to fix that first ;)
Oct 19 14:27:19 <alexxy> it has undefinde symbols in tests/mrmoku/unstable 
Oct 19 14:27:39 <alexxy> currently i use libframeworkd-phonegui-efl.so.0
Oct 19 14:28:32 <JaMa> alexxy: are you bringing kde-4.4 to neo too? :)
Oct 19 14:30:20 <alexxy> JaMa: well i have such plans
Oct 19 14:30:31 <alexxy> but i'll test it on hx4700 first
Oct 19 14:30:32 <alexxy> =)
Oct 19 14:31:11 <JaMa> great
Oct 19 14:31:38 <alexxy> so gentoo arm team will scream on me
Oct 19 14:31:41 <JaMa> anothere telephony stack starting with 'k' :)
Oct 19 14:48:40 <ptitjes> Ainulindale: ping
Oct 19 14:48:44 <Ainulindale> Pong
Oct 19 14:52:06 <JaMa> alexxy: I just built mesa for latest shr/import and I have Packaged contents of mesa-dri into /home/projects/OE/tmpdir-shr-shr/deploy/glibc/ipk/om-gta02/libegl1_7.5.1+gitr1+cfe6153d7a7ce6cb4d15d2ec6a6ab7020d162267-r3_om-gta02.ipk
Oct 19 14:53:45 <JaMa> for older mesa used in old build in tests/mrmoku/unstable there is http://build.shr-project.org/tests/mrmoku/unstable/feed/armv4t/libgl1_7.2-r6_armv4t.ipk
Oct 19 14:53:57 <Weiss> JaMa: did you figure out where the "e" came from?
Oct 19 14:54:28 <JaMa> mrmoku: please apply cookies and run shr-image build for unstable too
Oct 19 14:55:08 <JaMa> Weiss: no
Oct 19 14:55:33 <TAsn> dos1, any comments?
Oct 19 14:55:44 <TAsn> mrmoku, pong :)
Oct 19 14:56:19 <JaMa> Weiss: but I can add dri to another new package if you really don't like libegl1
Oct 19 14:56:39 <dos1> TAsn: about memo?
Oct 19 14:56:47 <TAsn> yeah.
Oct 19 14:56:54 <TAsn> (btw, what did I say there? I don't remember)
Oct 19 14:56:59 <Weiss> JaMa: I'm not bothered if there's a valid reason for it, but I'd like to know..
Oct 19 14:57:05 <dos1> about unicode in field types
Oct 19 14:57:15 <JaMa> Weiss: there is just 'FILES_${PN} += "${libdir}/dri/*.so"' in mesa-dri_git.bb and it ends in libegl1, I added FILES_mesa-utils = "${bindir}/*" because I didn't like libegl1-utils.. so I can do the same for dri modules
Oct 19 14:57:56 <TAsn> dos1, what about it?:)
Oct 19 14:58:00 <TAsn> I don't remember
Oct 19 14:58:04 <JaMa> Weiss: btw what is --enable-glx-tls for?
Oct 19 14:58:08 <TAsn> oh nvm
Oct 19 14:58:11 <TAsn> I remember :)
Oct 19 14:58:15 <TAsn> ok
Oct 19 14:58:15 <TAsn> and do you agree?
Oct 19 14:58:47 <JaMa> Weiss: in oe.dev its moved to separate class and decided based on libc version
Oct 19 14:59:26 <dos1> TAsn: well, i agree :P
Oct 19 14:59:34 <TAsn> cool ;)
Oct 19 14:59:38 <TAsn> is is supported yet?
Oct 19 14:59:53 <Weiss> JaMa: glx-tls is to do with GL function dispatch. The X server and Mesa have to agree on it: http://www.mesa3d.org/dispatch.html has some details (possibly more than you wanted)
Oct 19 15:00:37 <mrmoku> JaMa: Applying: shr/import: drop libdrm-glamo patch and switch back to rebased glamo branch
Oct 19 15:00:40 <mrmoku> fatal: corrupt patch at line 271
Oct 19 15:00:43 <mrmoku> Patch failed at 0001 shr/import: drop libdrm-glamo patch and switch back to rebased glamo branch
Oct 19 15:01:06 <mrmoku> TAsn: I built stuff on the buildhost
Oct 19 15:01:21 <Weiss> JaMa: hmm.. maybe you misunderstood how the packages work? "libgl.so" is the thing which decides which Mesa driver to work, talks "GLX-speak" and so on. /usr/lib/dri/{swrast_dri,glamo_dri}.so and friends are the individual Mesa DRI drivers. normally they're kept separate..
Oct 19 15:02:05 <TAsn> mrmoku, finally! :)
Oct 19 15:02:18 <TAsn> I was without a phone today!
Oct 19 15:02:19 <TAsn> :(
Oct 19 15:02:49 <TAsn> btw
Oct 19 15:02:55 <TAsn> please create a dummy package in arm4
Oct 19 15:03:00 <TAsn> :)
Oct 19 15:03:01 <CIA-26> SHR: 03mok 07phonefsod * rf072dc2b2a20 10/src/Makefile.am: define G_LOG_DOMAIN
Oct 19 15:03:02 <CIA-26> SHR: 03mok 07phonefsod * r1497fbabe599 10/src/phonefsod-fso.c: fso: do not try to register when set_antenna_power failed
Oct 19 15:03:23 <TAsn> I hope it'll update glib correctly ;)
Oct 19 15:03:26 <mrmoku> TAsn: refusing to do that for mrmoku/tests ;)
Oct 19 15:03:33 <TAsn> hehe ;)
Oct 19 15:03:33 <mrmoku> TAsn: no updated glib
Oct 19 15:03:38 <prahal> how could I get the source of the alsa-base used by shr ?
Oct 19 15:03:46 <TAsn> mrmoku, why not?
Oct 19 15:04:04 <mrmoku> want to see first if that is the reason
Oct 19 15:05:14 * JaMa curse vim
Oct 19 15:05:20 <JaMa> mrmoku: I'll resend patch
Oct 19 15:06:21 <mrmoku> JaMa: great
Oct 19 15:06:23 <JaMa> mrmoku: all rejected, new sent
Oct 19 15:06:58 <JaMa> mrmoku: there was just 'r' on some line.. not sure how it gets there.. but my fault
Oct 19 15:08:01 <mrmoku> applied :)
Oct 19 15:08:21 <TAsn> dos1, concerning the opimd resolving bug, what have you decided?
Oct 19 15:08:31 <JaMa> thanks.. shr-image build fine again
Oct 19 15:09:39 <TAsn> dos1, and btw, please update shr-settings to work with phonefsod and phoneuid and *not* ophonekitd. ;)
Oct 19 15:19:51 <blindcoder> TAsn: opimd resolving bug?
Oct 19 15:19:57 <TAsn> yes.
Oct 19 15:20:08 <TAsn> opimd is broken and dos1 won't admit it.
Oct 19 15:20:21 <blindcoder> TAsn: does it have anything to do with it not recognizing phone numbers outside of the 'Phone' field?
Oct 19 15:20:38 <TAsn> no
Oct 19 15:20:44 <TAsn> that's not a bug
Oct 19 15:20:45 <blindcoder> too bad :(
Oct 19 15:20:48 <TAsn> it's just a missing feature.
Oct 19 15:25:58 <TAsn> mrmoku, bah, still installing.
Oct 19 15:26:03 <TAsn> man, I was behind :)
Oct 19 15:26:29 <mrmoku> :P
Oct 19 15:26:45 <TAsn> mrmoku, btw
Oct 19 15:26:55 <TAsn> when did you build shr-today?
Oct 19 15:27:06 <mrmoku> not today ;)
Oct 19 15:27:07 <TAsn> or better, I'll just look at the rev
Oct 19 15:27:08 <TAsn> shit.
Oct 19 15:27:15 <TAsn> since I sent a patch yesterday night.
Oct 19 15:27:24 <TAsn> please rebuild as it's already committed ;)
Oct 19 15:27:53 <mrmoku> it is building an image right now... so I can't
Oct 19 15:28:04 <mrmoku> oohh... just failed :|
Oct 19 15:28:09 <Heinervdm> mrmoku: what image do you build?
Oct 19 15:28:15 <TAsn> yay! ? ;)
Oct 19 15:28:29 <mrmoku> JaMa: intel_bufmgr_gem.c:312: error: implicit declaration of function 'AO_fetch_and_add1_full'
Oct 19 15:28:36 <mrmoku> Heinervdm: shr/import
Oct 19 15:29:39 <TAsn> mrmoku, 
Oct 19 15:29:44 <TAsn> are the shr-* apps
Oct 19 15:29:46 <TAsn> old or new?
Oct 19 15:29:49 <mrmoku> old
Oct 19 15:29:50 <TAsn> probably old.
Oct 19 15:29:52 <mrmoku> phoneui-apps-*
Oct 19 15:29:55 <TAsn> thanks :)
Oct 19 15:30:18 <rebelThor> hmm, how come fso-abyss didn't get build by default on a new shr/merge build run (bitbake shr-lite-image) ?
Oct 19 15:30:21 <TAsn> btw
Oct 19 15:30:27 <TAsn> please make a dependency package
Oct 19 15:30:29 <TAsn> called
Oct 19 15:30:31 <TAsn> phoneui-apps
Oct 19 15:30:36 <TAsn> that'll depends on all.
Oct 19 15:30:36 <TAsn> :)
Oct 19 15:30:52 <rtp> mrmoku: hmmm... I may be wrong but I've seen a AO_fetch_and_add1_full in libatomic_ops. missing dependancy or something like that ?
Oct 19 15:31:16 <mrmoku> rtp: good question... no idea
Oct 19 15:32:12 <TAsn> mrmoku, 
Oct 19 15:32:14 <TAsn> phoneuid: evas_cache_image.c:1163: evas_cache_image_surface_alloc: Assertion `im->cache' failed.
Oct 19 15:32:19 <TAsn> the double close bug is still there
Oct 19 15:32:35 <TAsn> sec, rebooting to make sure it's not remains from the old installation.
Oct 19 15:33:47 <mrmoku> TAsn: how to reproduce that one?
Oct 19 15:34:03 <TAsn> open dialer
Oct 19 15:34:09 <TAsn> close dialer
Oct 19 15:34:09 <TAsn> open dilaer
Oct 19 15:34:19 <TAsn> (don't open contacts/messages anything else though)
Oct 19 15:34:40 <mrmoku> TAsn: can open/close dialer 10 times... no problem
Oct 19 15:36:05 <TAsn> please try rebuilding glib in host
Oct 19 15:36:15 <mrmoku> why?
Oct 19 15:37:20 <JaMa> mrmoku: thats quite old issue.. please diff libdrm recipe with shr/merge.. its missing something like --disable-intel, I have to go now.. sister is waiting for me outside...
Oct 19 15:37:39 <mrmoku> JaMa: ok, thanks
Oct 19 15:38:11 <JaMa> ah strange that it compiled fine for me..
Oct 19 15:38:17 <JaMa> but still have to go..
Oct 19 15:38:50 <TAsn> mrmoku, no idea :|
Oct 19 15:38:53 <TAsn> can't think of anything else.
Oct 19 15:39:14 <TAsn> mrmoku, 
Oct 19 15:39:19 <TAsn> please opkg list_installed
Oct 19 15:39:23 <TAsn> I'll compare with mine.
Oct 19 15:39:36 <mrmoku> TAsn: I reflashed image from tests/mrmoku
Oct 19 15:39:38 <mrmoku> upgraded
Oct 19 15:39:42 <mrmoku> and installed the new stuff
Oct 19 15:39:52 <TAsn> now this sounds interesting.
Oct 19 15:40:13 <TAsn> btw, the image you are building ships with phoneuid as default?
Oct 19 15:40:30 <TAsn> mrmoku, please provide this list it'll only take two seconds :)
Oct 19 15:40:34 <TAsn> opkg list_installed > tasn.
Oct 19 15:44:42 <mrmoku> TAsn: sent
Oct 19 15:45:50 <TAsn> thanks.
Oct 19 15:45:50 <TAsn> :)
Oct 19 15:50:06 <TAsn> mrmoku, the only difference that seems even somewhat related
Oct 19 15:50:16 <TAsn> is the fact that I use x11-16 and niebiee
Oct 19 15:50:20 * TAsn is trying to drop that.
Oct 19 15:54:03 <mrmoku> TAsn: btw... I very much dislike the fprintf for logging :|
Oct 19 15:54:12 <TAsn> why?
Oct 19 15:54:17 <mrmoku> it is buffering
Oct 19 15:54:19 <TAsn> that's the proper way to do it...
Oct 19 15:54:30 <TAsn> you can fflush
Oct 19 15:54:34 <TAsn> if you really want to.
Oct 19 15:54:36 <mrmoku> you get the log in big hunks
Oct 19 15:54:46 <TAsn> fflush after each message.
Oct 19 15:54:55 <mrmoku> TAsn: thats the reason why you had no log in phoneuid
Oct 19 15:55:18 <mrmoku> what would be the advantage over using write?
Oct 19 15:55:32 <TAsn> mrmoku, first of all
Oct 19 15:55:38 <TAsn> the logs I didn't have
Oct 19 15:55:39 <mrmoku> (and "the proper way to do it" is not what I want to hear) ;)
Oct 19 15:55:53 <TAsn> were with your write :)
Oct 19 15:55:56 <TAsn> second of all
Oct 19 15:56:04 <TAsn> fprintf is easier to handle
Oct 19 15:56:15 <TAsn> and more generic
Oct 19 15:56:33 <TAsn> fopen/ffoobar are the proper way to handle files in C
Oct 19 15:57:01 <TAsn> ok, it's not niebiee
Oct 19 15:57:01 <mrmoku> open/write are more lowlevel... which might be good for logging
Oct 19 15:57:15 <mrmoku> and we have to sprintf our thing anyway...
Oct 19 15:57:23 <mrmoku> so no need for Fprintf
Oct 19 15:57:29 <TAsn> why sprintf?
Oct 19 15:57:30 <mrmoku> ehhm fprintF
Oct 19 15:57:35 <TAsn> look at what I did.
Oct 19 15:57:38 <TAsn> strftime...
Oct 19 15:57:43 <TAsn> no weird sprintf... :)
Oct 19 15:57:44 <mrmoku> well... the strftime
Oct 19 15:57:47 <mrmoku> is what I mean
Oct 19 15:57:59 <TAsn> and fprintf writes straight to file
Oct 19 15:58:18 <mrmoku> hmmm... ok... but I will add the fflush then
Oct 19 15:58:26 <mrmoku> as not getting the log immediately is annoying
Oct 19 15:58:28 <TAsn> no need to allocate a string of our own.
Oct 19 15:58:41 <TAsn> especially if you print a message about failing to allocate string.)
Oct 19 15:58:42 <TAsn> ;)
Oct 19 15:58:50 <mrmoku> fflush(logfile); 
Oct 19 15:58:52 <mrmoku> like this?
Oct 19 15:59:23 <mrmoku> yup
Oct 19 15:59:56 <CIA-26> SHR: 03mok 07phonefsod * r5b0d2d28e059 10/src/phonefsod.c: flush while logging
Oct 19 16:00:22 <TAsn> :)
Oct 19 16:00:33 <TAsn> iirc yeah.
Oct 19 16:00:53 <CIA-26> SHR: 03mok 07phoneuid * r415c0bbc9c5a 10/src/Makefile.am: define G_LOG_DOMAIN
Oct 19 16:00:54 <CIA-26> SHR: 03mok 07phoneuid * r238288fef8b7 10/src/phoneuid.c: flush after logging
Oct 19 16:02:01 <rebelThor> i'm using the latest (updated) shr/merge branch, and I'm getting a fail on xorg-lib/libx11 : http://pastebin.com/m2079ae87 .. am I doing something wrong ?
Oct 19 16:02:18 <TAsn> mrmoku, what do I need to backup before reflashing?
Oct 19 16:02:50 <TAsn> <TAsn> opimd
Oct 19 16:02:52 <TAsn> <TAsn> home
Oct 19 16:02:52 <TAsn> <TAsn> dropbear ssl key
Oct 19 16:02:52 <TAsn> <TAsn> and?
Oct 19 16:03:20 <mrmoku> no idea what kind of stuff you have on your phone ;)
Oct 19 16:03:24 <mrmoku> ringtones?
Oct 19 16:03:27 <mrmoku> gps maps?
Oct 19 16:03:32 <mrmoku> porno?
Oct 19 16:03:36 <mwester> pron collection?
Oct 19 16:03:40 <mrmoku> :)
Oct 19 16:03:48 <mwester> oops, mrmoku already mentioned that
Oct 19 16:03:49 <mwester> :D
Oct 19 16:03:55 <TAsn> mrmoku, ok, backed up porn.
Oct 19 16:04:02 <mrmoku> we all know TAsn ;)
Oct 19 16:04:18 <mrmoku> TAsn: btw... SIM with PIN does not work (yet)
Oct 19 16:04:20 <TAsn> mrmoku, hm.. just latest unstable from mrmoku tests?
Oct 19 16:04:20 <DocScrutinizer-8> youporn over gprs - eeew that get me hot :-P
Oct 19 16:04:27 <mrmoku> TAsn: yup
Oct 19 16:04:33 <TAsn> mrmoku, thanks :)
Oct 19 16:04:39 <mrmoku> DocScrutinizer-8: and your modem too :P
Oct 19 16:04:46 <DocScrutinizer-8> lol
Oct 19 16:05:08 <TAsn> btw, I know I asked already, I jsut don't remember if you answered, latest image you tried to generate included phoneuid or not?
Oct 19 16:05:47 <mrmoku> yup
Oct 19 16:05:53 <TAsn> yay :)
Oct 19 16:06:06 <mrmoku> guess I want to fix PIN first though :P
Oct 19 16:06:22 <TAsn> heh probably.
Oct 19 16:06:25 <TAsn> btw
Oct 19 16:06:28 <TAsn> do calls
Oct 19 16:06:30 <TAsn> on all direction
Oct 19 16:06:34 <TAsn> directions*
Oct 19 16:06:36 <TAsn> work?
Oct 19 16:06:57 <mrmoku> did not try calling after I reflashed
Oct 19 16:07:01 <mrmoku> but they did work before
Oct 19 16:07:08 <mrmoku> anyway...
Oct 19 16:07:14 * mrmoku off for dinner now
Oct 19 16:07:24 <mrmoku> TAsn: I'm building phoneuid + phonefsod with fflush now
Oct 19 16:07:34 <mrmoku> bbl
Oct 19 16:07:39 <TAsn> bye.
Oct 19 16:17:53 <TAsn> mrmoku|away, now it works ;)
Oct 19 16:17:54 <TAsn> thanks.
Oct 19 16:18:00 <TAsn> (new image)
Oct 19 16:18:13 <TAsn> oh
Oct 19 16:18:15 <TAsn> it's fucking ophonekitd
Oct 19 16:18:16 <TAsn> :|
Oct 19 16:18:26 <TAsn> bah, sec upgrading. :|
Oct 19 16:19:00 <rebelThor> does libX11 compile properly for you guys? i seem to be a magnet for all sort of nasty issues
Oct 19 16:27:39 <Weiss> rebelThor: yes, all the bits of X can be tricky..
Oct 19 16:27:56 <Weiss> JaMa works hard to keep the problems at bay..
Oct 19 16:28:24 <rebelThor> Weiss: i'm getting some very weird output, and I can't even figure out what's the actual error from it.. : http://pastebin.com/m2079ae87
Oct 19 16:28:58 <rebelThor> i'm using the latest updated head of shr/merge, so if it compiles for you, i must be doing some strange voodoo to break it
Oct 19 16:29:10 <Weiss> hmm.. is there a "--disable-docs" option or something?
Oct 19 16:34:22 <rebelThor> Weiss: how would I check for that option?
Oct 19 16:35:04 <Weiss> "cd /home/thor/Openmoko/shr-unstable/tmp/work/i686-linux/libx11-native-1_1.3.1-r3/libX11-1.3.1; ./configure --help" maybe
Oct 19 16:41:03 <TAsn> okie
Oct 19 16:41:03 <TAsn> works :)
Oct 19 16:41:05 <TAsn> mrmoku|away, ^
Oct 19 17:02:52 <TAsn> http://scap.linuxtogo.org/files/23bdd6a81d11330c327e372c8eb8dc6b.png
Oct 19 17:02:52 <TAsn> funky :)
Oct 19 17:09:14 <rebelThor> Weiss: no such option unfortunately... however, it appears that it's using my own system's groff/troff utilities to handle those conversions? Maybe it's my system, not the OE build
Oct 19 17:09:42 <Weiss> rebelThor: possibly. JaMa probably knows..
Oct 19 17:10:09 <rebelThor> I'll poke around `till he gets here to shine some light
Oct 19 17:10:28 <mrmoku> TAsn: nice scap, yes
Oct 19 17:10:29 <Weiss> I tend to just an OE setup running which has recent enough versions of everything for my development, then just leave it be while I work on that
Oct 19 17:10:43 <mrmoku> TAsn: so... all good now?
Oct 19 17:11:07 <rebelThor> Weiss: that's what I'm trying to do actually, but i've never managed to actually get an image to build, and I've tried lots of times..
Oct 19 17:17:23 <rebelThor> Weiss: I can't believe it, it does use my system's "groff" utility, and all I needed to do was "sudo apt-get install groff".. it has compiled successfully now.. thanks for the support ;)
Oct 19 17:19:04 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r42369873c8db 10/fsogsmd/src/ (6 files in 2 dirs): fsogsmd: define Constants.CALL_INDEX_MAX. fsogsmd will have support for up to 7 concurrent calls.
Oct 19 17:19:40 <DocScrutinizer-8> 7? why not 9?
Oct 19 17:19:52 <Weiss> rebelThor: hehe, no problem
Oct 19 17:20:18 <mickeyl> DocScrutinizer-8: 7 is supposed to be the maximum
Oct 19 17:20:33 <mickeyl> read that in some gsm docs
Oct 19 17:20:46 <mickeyl> don't ask me where now, read a ton of stuff during weekend
Oct 19 17:20:47 <DocScrutinizer-8> ooh,really? you found a clear def?
Oct 19 17:21:28 <mickeyl> somewhat clear, ya. at least it was said that for things like +CHLD=2x, 1 <= x <= 7
Oct 19 17:21:53 <DocScrutinizer-8> hmm, that might be proprietary
Oct 19 17:22:08 <DocScrutinizer-8> for a specific implementation
Oct 19 17:23:01 <DocScrutinizer-8> bah, never mind. We hardly ever will see anyone running into that
Oct 19 17:23:15 <mickeyl> probably not, yeah :)
Oct 19 17:23:26 <mickeyl> and if so... it's just a constant anyways
Oct 19 17:23:37 <DocScrutinizer-8> :-D
Oct 19 17:23:54 <mickeyl> i have been convinced to enhance the state logic for theoretically unlimited calls
Oct 19 17:23:58 <mickeyl> *shrug*
Oct 19 17:24:43 <DocScrutinizer-8> hehe, sounds like you actually studied sw engineering
Oct 19 17:25:10 <mickeyl> oh well, it's always a compromise between taste for design, capabilities, and lazyness
Oct 19 17:26:15 <DocScrutinizer-8> yep, but the taste thing depends strongly on educational background / experience ;-)
Oct 19 17:26:21 <mickeyl> true
Oct 19 17:27:48 <dos1> every thing strongly depends on lazyness
Oct 19 17:27:52 <dos1> at least in my case ;)
Oct 19 17:27:58 <DocScrutinizer-8> hehehe
Oct 19 17:29:14 <DocScrutinizer-8> mickeyl: given those factors I'd even say we're happy wit an upper limit of 3 for now, plus a clear note in api specs this is an arbitrary number subject to change anytime
Oct 19 17:37:18 <mickeyl> ya, could do that to save some memory and a marginal amount of processing time
Oct 19 17:37:51 <DocScrutinizer-8> yep
Oct 19 17:37:54 <DocScrutinizer-8> :-)
Oct 19 17:39:22 <DocScrutinizer-8> mickeyl: kleinvieh macht auch mist ;-D
Oct 19 17:40:13 <mickeyl> AT^SM20=0
Oct 19 17:40:14 <mickeyl> oops
Oct 19 17:40:17 <mickeyl> DocScrutinizer-8: correct
Oct 19 17:41:03 <DocScrutinizer-8> mickeyl: I guess apps would like to query actual setting of this upper limit
Oct 19 17:42:04 <mickeyl> no problem
Oct 19 17:44:38 <DocScrutinizer-8> natural place in api spec to mention the not-a-constant properties of the query result
Oct 19 17:45:55 <rebelThor> anyone know how to manually build glibc-binary-localedata-en-gb ? I'm getting * ERROR: Cannot satisfy the following dependencies for task-shr-minimal-x: glibc-binary-localedata-en-gb when building shr-lite-image
Oct 19 17:46:22 <Heinervdm> rebelThor: it's part of glibc
Oct 19 17:46:38 <Heinervdm> you've restricted locales in local.conf, i guess
Oct 19 17:46:44 <mickeyl> hmm, good
Oct 19 17:46:53 <DocScrutinizer-8> wasn't this a topic here  this very afternoon?
Oct 19 17:46:53 <mickeyl> +CHLD=11 also cancels an outgoing call
Oct 19 17:47:00 <rebelThor> Heinervdm: yup, should I unrestrict them? it'll take forever to build after that, right? :)
Oct 19 17:47:29 <mickeyl> can someone check whether +CHDL=11 is supported as dropping an outgoing call on calypso?
Oct 19 17:47:42 <Heinervdm> rebelThor: add en_GB or unrestrict them, it will taka about 1 hour
Oct 19 17:48:01 <mickeyl> (no hurries, just by chance)
Oct 19 17:48:19 <DocScrutinizer-8> mickeyl: mickeyterm?
Oct 19 17:48:53 <mickeyl> yeah
Oct 19 17:48:58 <mickeyl> or 'DebugCommand'
Oct 19 17:49:58 <DocScrutinizer-8> cancels
Oct 19 17:50:06 <mickeyl> awesome, thanks
Oct 19 17:50:10 <DocScrutinizer-8> np
Oct 19 17:51:40 <mickeyl> due to enhanced convenience, i'll not move over to calypso until everything works with the gsm devel board attached to my workstation
Oct 19 17:52:08 * mickeyl tries to avoid crosscompiling turn arounds
Oct 19 17:52:12 <DocScrutinizer-8> duh
Oct 19 17:57:37 <mrmoku> mickeyl: hello, saw my ping? :)
Oct 19 17:58:44 <mickeyl> no
Oct 19 17:58:45 <mickeyl> mrmoku: pong
Oct 19 17:58:47 <mrmoku> :)
Oct 19 17:58:54 <mrmoku> configure.ac:84: required file `vapigen/Makefile.in' not found
Oct 19 17:58:59 <mrmoku> for the new vala tarbal
Oct 19 17:58:59 <mrmoku> l
Oct 19 17:59:34 <mickeyl> even when configuring with --disable-vapigen?
Oct 19 17:59:54 <mickeyl> let me pack an update
Oct 19 18:00:11 <mrmoku> if it's not neede I can add --disable-vapigen...
Oct 19 18:02:33 <mrmoku> mickeyl: recipe has a specific --enable-vapigen in vala.inc
Oct 19 18:04:33 <mickeyl> we don't need it
Oct 19 18:04:33 <mickeyl> please try fso4 w/ --disable-vapigen
Oct 19 18:04:49 <mrmoku> ok, thanks
Oct 19 18:04:58 <mickeyl> vala has some make dist problems, but i'm too lazy to investigate atm.
Oct 19 18:05:07 <mrmoku> mickeyl: is it safe to change in vala.inc? for oe.dev too?
Oct 19 18:05:20 <mickeyl> mrmoku: yes. nothing in oe needs vapigen atm.
Oct 19 18:05:24 <mrmoku> ok, good
Oct 19 18:05:34 <mickeyl> add an Acked-by if you want
Oct 19 18:06:10 <larsc> DocScrutinizer-8: you are the hw genius here: How can we emulate sort of usb-otg with the freerunner?
Oct 19 18:06:27 <DocScrutinizer-8> hehe
Oct 19 18:06:44 <mickeyl> hi onen|openBmap 
Oct 19 18:07:03 <onen|openBmap> mickeyl: hallo du ;-)
Oct 19 18:07:19 <DocScrutinizer-8> it's rather tricky if not completely impossible. OTG uses VBUS-USB for a kinky kind of data-line
Oct 19 18:07:27 <onen|openBmap> mickeyl: I check FSO/pre  pages every day for updates ;-)
Oct 19 18:08:23 <DocScrutinizer-8> larsc: and the PSU and buffer Cs, as well as sensing capabilities, of FR are not up to those specs in OTG
Oct 19 18:08:49 <mickeyl> onen|openBmap: :) we have some progress, but the great breakthrough is not happening yet. we can talk to one of the modem channels though via AT, which is an achievement. Unfortunately it's not the 'call' channel, but the 'data' channel, so more work needs to be done. Still trying to reuse ogsmd in its present form rather than reinventing the binary protocol Palm uses
Oct 19 18:12:45 <mwester> "kinky kind of data-line"  :D
Oct 19 18:12:55 <DocScrutinizer-8> larsc: without hw mods I think it's quite impossible
Oct 19 18:13:16 <larsc> DocScrutinizer-8: hm, ok :(
Oct 19 18:13:37 <DocScrutinizer-8> sorry for no better news
Oct 19 18:14:47 <DocScrutinizer-8> nevertheless I'll revisit the issue eventually... When I feel creative
Oct 19 18:15:06 <larsc> i was hopeing that with all the sensors we would be able to tell, whether the connected devices is drawing or pushing power
Oct 19 18:15:11 <vanous123> larsc: i was just typing an email to ask about this in community :)
Oct 19 18:15:15 <DocScrutinizer-8> maybe we can get some sort of botch at least
Oct 19 18:17:30 <DocScrutinizer-8> well, for most basic usage there is the ID-pin on mini-usb that's supposed to be shorted to GND on host side of a miniUSB-miniUSB cable, and shall be NC on the device side
Oct 19 18:18:49 <DocScrutinizer-8> so with a correct cable and Neo kernel obeying the ID pin spec, we should get a basic "OTG", a very basic though
Oct 19 18:19:28 <mrmoku> mickeyl: still no go... slightly different though
Oct 19 18:19:29 <mrmoku> Makefile.am:5: required directory ./vapigen does not exist
Oct 19 18:19:32 <mrmoku> :)
Oct 19 18:19:42 <larsc> but that would only be possible if we for example connect a neo to another usb mini host, right?
Oct 19 18:19:53 <DocScrutinizer-8> right
Oct 19 18:19:54 <mickeyl> mrmoku: argh. let me check
Oct 19 18:20:56 <mickeyl> mrmoku: hmm, that is with -fso4 and --disable-vapigen?
Oct 19 18:21:02 <mrmoku> mickeyl: yup
Oct 19 18:21:17 <DocScrutinizer-8> larsc: well not completely. Also works when connecting to another PC host, and when connecting to a usb-device. Always given we use correct adapters
Oct 19 18:21:45 <larsc> DocScrutinizer-8: what do correct adapters look like?
Oct 19 18:21:59 <DocScrutinizer-8> larsc: and of course the cable right end to right side ;-)
Oct 19 18:22:45 <mickeyl> mrmoku: which Makefile.am is it meaning?
Oct 19 18:23:25 <mrmoku> mickeyl: probably I did it wrong... I changed the --enable-vapigen to be --disable-vapigen
Oct 19 18:23:36 <mrmoku> but it is for EXTRA_OECONF
Oct 19 18:23:43 <mrmoku> and it bails out before configuring
Oct 19 18:23:50 <DocScrutinizer-8> larsc: for PC host that is simply a standard USB cable like comes with FR, or a A-male-2-miniUSB-female adapter to plug to one end of the double-miniUSB cable
Oct 19 18:24:29 <DocScrutinizer-8> larsc: for device connected to FR it depends on actual receptacle of the device
Oct 19 18:24:44 <mrmoku> mickeyl: which Makefile.am? .. no idea
Oct 19 18:26:04 <mrmoku> mickeyl: guess the toplevel one... as it's ./Makefile.am and line 5 (which is the VAPIGEN_SUBDIRS define)
Oct 19 18:26:46 <mickeyl> hmm, but there's this if ENABLE_VAPIGEN
Oct 19 18:26:49 <mickeyl> that should cover it
Oct 19 18:28:21 <mrmoku> EXTRA_OECONF should be the right place for it?
Oct 19 18:28:27 <mickeyl> yes
Oct 19 18:28:36 <mickeyl> just check whether it's not overridden in the concrete bb
Oct 19 18:28:44 <mickeyl> I#ll take a look at the make dist problem meanwhile
Oct 19 18:29:18 <mrmoku> mickeyl: nothing in the bb
Oct 19 18:30:53 <mickeyl> hold on, trying a new tarball
Oct 19 18:32:07 <mickeyl> vala-0.7.7+fso5.tar.bz2
Oct 19 18:32:07 <mickeyl> this one passes make distcheck
Oct 19 18:32:10 <mickeyl> so that should really work now
Oct 19 18:32:24 <mrmoku> ok, thanks:)
Oct 19 18:35:09 <larsc> DocScrutinizer-8: so i would need one cable if i want to connect a usb host which connects usbid to gnd and another one for devices which leave it floating?
Oct 19 18:35:39 <DocScrutinizer> yep
Oct 19 18:36:09 <DocScrutinizer> just the other way round
Oct 19 18:36:19 <larsc> ok. and if i want to act as a device how can i read the state of usbid if i'm suposed to let it float?
Oct 19 18:36:26 <larsc> or host
Oct 19 18:36:30 <larsc> in that case then
Oct 19 18:36:31 <DocScrutinizer> short to GND triggers hostmode on FR
Oct 19 18:38:18 <larsc> hm usb_id is pull down on the freerunner, if i read the schematics correctly
Oct 19 18:38:22 <DocScrutinizer> err, we have a AD to PMU for ID pin. FR can not actively short that pin to GND. Cable has to do that. And - as cables are 4 wire usually, that shorting in FR would make no sense anyway
Oct 19 18:38:54 <DocScrutinizer> larsc: (pulldown) I'd be surprised to learn that ;-)
Oct 19 18:39:30 <larsc> ok then i'm reading it wrong
Oct 19 18:40:14 <DocScrutinizer> yep, usb_id goes to R1731 R1732
Oct 19 18:40:15 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r4e516bfddf2a 10/fsogsmd/src/ (5 files in 2 dirs): fsogsmd: more work on call handling
Oct 19 18:40:34 <DocScrutinizer> U1701
Oct 19 18:40:35 <DocScrutinizer>  ADCIN1
Oct 19 18:41:42 <DocScrutinizer> larsc: also see "USB_ID function" on sheet 7
Oct 19 18:42:09 <mrmoku> mickeyl: yup worked :D
Oct 19 18:44:01 <mrmoku> mickeyl: is the good practice to replace the old vala (0.7.7+fso1) or to add a recipe?
Oct 19 18:46:17 <DocScrutinizer> larsc: however be aware OTG is something way more sophisticated: both devices negotiate who's host and who's device, by weird pulsing of the 5V VBUS line
Oct 19 18:47:10 <DocScrutinizer> larsc: FR can not do this (presumably)
Oct 19 18:47:11 <mickeyl> mrmoku: that's a decision for case-by-case. in general we try to keep old recipes, in the vala case it makes more sense to update, since everything is so much in flux that we depend on the bleeding edge version anyways. so, git mv please
Oct 19 18:47:57 <rebelThor> anyone knows where "configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails sanity check" came from?
Oct 19 18:49:21 <DocScrutinizer> larsc: http://www.usb.org/developers/onthego/
Oct 19 18:51:09 <larsc> i don't want be otg compatible, i just want to switch between host and device mode depending on what's connected
Oct 19 18:52:05 <larsc> connect to laptop switch to device mode. connect to keyboard switch to host mode
Oct 19 18:54:17 <Blu3> rebelThor, look at the config.log
Oct 19 18:56:39 <mickeyl> that's not going to happen IIRC
Oct 19 18:57:56 <mickeyl> ah wait, it could work, once you autoswitch back when the gadget disconnects
Oct 19 18:58:17 <mickeyl> because otherwise you won't get enumerated again
Oct 19 19:02:32 <rebelThor> Blu3: error seems to be /home/thor/Openmoko/shr-unstable/tmp/cross/armv4t/lib/gcc/arm-angstrom-linux-gnueabi/4.4.1/include-fixed/limits.h:122:61: error: limits.h: No such file or d...
Oct 19 19:03:09 <TAsn> mrmoku, for the meanwhile, yeah. sec, I went to sleep for an hour
Oct 19 19:03:14 <TAsn> I'll give it a real go now.
Oct 19 19:03:55 <spaetz_> TAsn: I answered the alphalog guy to his mail
Oct 19 19:04:15 <TAsn> in shr-devel?
Oct 19 19:04:22 <spaetz_> I'll be gone for the next 3 days (hospital stay), can you check into the git repositories where needed?
Oct 19 19:04:23 <TAsn> when did he send a new one?
Oct 19 19:04:30 <TAsn> sure
Oct 19 19:04:32 <TAsn> shr-themes
Oct 19 19:04:33 <spaetz_> mail to shr..devel yes
Oct 19 19:04:35 <TAsn> don't worry ;)
Oct 19 19:04:41 <TAsn> I alreayd answered him there as well ;)
Oct 19 19:04:46 <spaetz_> ahh, it's an ols mail
Oct 19 19:04:46 <TAsn> hehe.
Oct 19 19:04:52 <spaetz_> old mail. Just discovered that now
Oct 19 19:04:56 <spaetz_> stupid me :)
Oct 19 19:05:06 <spaetz_> well, another reminder doesn't hurt :)
Oct 19 19:05:09 <TAsn> we probably look like a couple of idiots ;)
Oct 19 19:05:16 <TAsn> I also sent him a reminder
Oct 19 19:05:17 <TAsn> today :)
Oct 19 19:05:21 <spaetz_> hehe
Oct 19 19:05:51 <spaetz_> ok, gone now. Have fun...
Oct 19 19:06:39 <TAsn> you too :)
Oct 19 19:08:53 <DocScrutinizer-8> larsc: we don't sense plugin of any device, as long as we don't power the usb-vbus
Oct 19 19:09:27 <DocScrutinizer-8> we want to start powering usb as soon as we sense a device ;-P
Oct 19 19:10:18 <larsc> hm
Oct 19 19:10:52 <DocScrutinizer-8> larsc: so only way to trigger powering usb is sensing for id short to GND
Oct 19 19:11:27 <DocScrutinizer-8> or app user-interface (interactively powering up usb)
Oct 19 19:14:10 <mrmoku> mickey|tv: did my first two commits to oe.dev :)
Oct 19 19:14:14 <mrmoku> TAsn: good morning then ;)
Oct 19 19:14:41 <TAsn> mrmoku, thanks ;)
Oct 19 19:14:57 <TAsn> btw, do you have occasional segfaults with contact app?
Oct 19 19:15:13 <mrmoku> TAsn: not that I would have noticed :P
Oct 19 19:15:24 <mrmoku> but did not stress-test it yet
Oct 19 19:15:36 <TAsn> btw, confirmed
Oct 19 19:15:43 <TAsn> software-16
Oct 19 19:15:46 <TAsn> causes segfaults
Oct 19 19:15:54 <TAsn> when opening and closing.
Oct 19 19:15:57 <mrmoku> TAsn: ooohh... that is bad :(
Oct 19 19:16:14 <mrmoku> very bad
Oct 19 19:16:16 <TAsn> maybe it's just niebiee
Oct 19 19:16:22 <TAsn> but something is causing segfaults
Oct 19 19:16:28 <TAsn> something with font drawing.
Oct 19 19:16:30 <TAsn> yes, indeed.
Oct 19 19:17:29 <TAsn> please verify
Oct 19 19:18:00 <mrmoku> later... right now I'm debugging the sim pin thing
Oct 19 19:18:25 <TAsn> ok, it's not niebiee
Oct 19 19:18:31 <TAsn> it's X11-16
Oct 19 19:18:42 <DocScrutinizer-8> sim pin thing?
Oct 19 19:19:05 <TAsn> DocScrutinizer, we decided to brute force sim pin
Oct 19 19:19:07 <TAsn> s
Oct 19 19:19:11 <TAsn> as it's just annoying
Oct 19 19:20:01 <TAsn> it seems like I got you into serious trauma
Oct 19 19:20:07 <TAsn> I'm j/k.
Oct 19 19:21:36 <mrmoku> DocScrutinizer-8: automatic upload of PINs to palm.com :P
Oct 19 19:21:56 * mrmoku thought that would be trendy ;)
Oct 19 19:22:38 <TAsn> mrmoku, I think we already caused him enough of heart damage ;)
Oct 19 19:23:44 <dos1> DocScrutinizer-8, BTW, i'm going to drop sqlite from opimd at all and store everything in binary blob with internal data structure. are you fine with that?
Oct 19 19:23:44 <TAsn> mrmoku, actually
Oct 19 19:23:45 <dos1> :>
Oct 19 19:24:07 <TAsn> with index, x11-16 is not *really* that bad
Oct 19 19:24:09 <mrmoku> dos1: TAsn will be happy... as long as numbers resolve ;)
Oct 19 19:24:13 <TAsn> but yeah, it's annoying and should be fixed.
Oct 19 19:24:17 <dos1> TAsn: i think that killed him for sure ;)
Oct 19 19:24:19 <TAsn> dos1, I'm willing to compromise on that
Oct 19 19:24:25 <dos1> oh
Oct 19 19:24:26 <TAsn> as long as you fix my hack ;]
Oct 19 19:24:30 <TAsn> dos1, hehe, probably. ;)
Oct 19 19:24:42 <TAsn> though you also made my heart ache :)
Oct 19 19:24:44 <dos1> and i'm removing numbers resolving, as i realised it's not opimd job
Oct 19 19:24:51 <dos1> (and now TAsn is also killed :D)
Oct 19 19:24:58 <TAsn> hehe :)
Oct 19 19:25:13 <TAsn> I don't mind writing yet another daemon, called phone-opimd-name-resolver
Oct 19 19:25:19 <DocScrutinizer-8> larsc: if you got 2 cables/adapters, 1) miniUSB-IDshort2GND--to--USB-A-receptacle (for connecting devices), and 2) usual cable from FR accesories (for connecting to hosts), then you should get as much as reasonably feasible
Oct 19 19:25:22 <TAsn> that resolves name *with* my hack ;)
Oct 19 19:25:41 <TAsn> dos1, I still have to git diff opened in an "always on top" window ;)
Oct 19 19:26:46 <TAsn> oh shit
Oct 19 19:26:50 <TAsn> forgot to fix it here
Oct 19 19:26:55 <TAsn> and forgot to remove notifier as well
Oct 19 19:26:55 <TAsn> :)
Oct 19 19:27:04 <TAsn> mrmoku, this image sucks (with all this crap installed) :)
Oct 19 19:28:31 <Gnutoo> hi mrmoku 
Oct 19 19:28:52 <Gnutoo> I saw that there was an SHR/merge branch in oe
Oct 19 19:28:56 <Gnutoo> what's happening?
Oct 19 19:29:03 <Gnutoo> you are merging with oe.dev?
Oct 19 19:29:11 <dos1> Gnutoo: yup. shr/merge is based on oe.dev
Oct 19 19:29:16 <Gnutoo> what should I do for my patches?
Oct 19 19:29:31 <Gnutoo> I should abandon the specific fixes for old stuff?
Oct 19 19:29:33 <TAsn> dos1, 
Oct 19 19:29:35 <TAsn>             if not isinstance(field_value, (str, dbus.String)):
Oct 19 19:29:39 <Gnutoo> like:
Oct 19 19:29:40 <TAsn>                 logger.debug(field_name + " - " + str(type(field_value)))
Oct 19 19:29:40 <TAsn> enough debug info?
Oct 19 19:29:44 <Gnutoo> -QEMU_OPTIONS_armv6-novfp = ""-cpu arm1136" +QEMU_OPTIONS_armv6-novfp = "-cpu arm1136"
Oct 19 19:29:47 <Gnutoo> for instance
Oct 19 19:30:08 <Gnutoo> and send only the macihne specific for xorg and kdrive?
Oct 19 19:30:12 <TAsn> dos1, ;] :)
Oct 19 19:30:23 <Gnutoo> and frameworkd.conf
Oct 19 19:31:18 <TAsn> btw
Oct 19 19:31:26 <TAsn> mrmoku, did you notice hover-sels work?
Oct 19 19:31:37 <TAsn> oh, not really.
Oct 19 19:31:45 <TAsn> I can pop them
Oct 19 19:31:48 <TAsn> but clicking does nothing.
Oct 19 19:31:50 <TAsn> :|
Oct 19 19:31:57 <TAsn> (only in shr-settings)
Oct 19 19:32:03 <TAsn> though in other places they completely work
Oct 19 19:32:09 <TAsn> I think they do work ;)
Oct 19 19:33:09 <TAsn> and I also figured out why I never got debug messages last time I was testing this crap :)
Oct 19 19:33:45 <TAsn> and I feel like such an idiot.
Oct 19 19:33:48 <TAsn> :)
Oct 19 19:33:55 <TAsn> (didn't set debugging mode)
Oct 19 19:34:22 <TAsn> anyhow mrmoku hover-sels seem to work.
Oct 19 19:34:31 <TAsn> ;)
Oct 19 19:34:31 <TAsn> ciao.
Oct 19 19:37:54 <dos1> TAsn: nothing changed about hoversels
Oct 19 19:38:13 <dos1> TAsn: they doesn't work with some, looking like correct, callbacks
Oct 19 19:38:48 <dos1> TAsn: and debug info should be ok
Oct 19 19:39:01 <mrmoku> TAsn: they don't even work in elementary_test
Oct 19 19:40:04 <mrmoku> Gnutoo: just commit to oe.dev... we pull regularily
Oct 19 19:40:47 <Gnutoo> mrmoku, I've already done that but I want to commit kdrive,xorg,frameworkd.conf and that goes into shr's folders
Oct 19 19:41:09 <Gnutoo> no?
Oct 19 19:41:59 <mrmoku> Gnutoo: hmm... ok. stuff that is not yet in org.oe.dev feel free to commit to shr/merge
Oct 19 19:42:29 <Gnutoo> mrmoku, by commit you mean that I commit without sending for review? are you shure?
Oct 19 19:42:46 <mrmoku> Gnutoo: you won't break stuff... will you :P
Oct 19 19:43:14 <Gnutoo> I don't always test before pushing but I always check what I'm pushing
Oct 19 19:43:25 <mrmoku> that should be sufficient :)
Oct 19 19:43:30 <Gnutoo> ok thanks
Oct 19 19:43:44 <Gnutoo> I'll prepare good config files then
Oct 19 19:43:47 <Gnutoo> thanks
Oct 19 19:44:53 <larsc> ok thanks
Oct 19 19:48:05 <Gnutoo> larsc, btw did you push tslib?
Oct 19 19:48:20 <Gnutoo> because I realy need it for shr
Oct 19 19:49:50 <TAsn> mrmoku, weird
Oct 19 19:50:36 <Gnutoo> x/tslib/xf86-input-tslib
Oct 19 19:51:00 <mrmoku> TAsn: yup, weird
Oct 19 19:52:18 <TAsn> hm..
Oct 19 19:52:18 <TAsn> dos1, 
Oct 19 19:52:18 <TAsn> it seems that isinstance
Oct 19 19:52:18 <TAsn> it what causing the break.
Oct 19 19:52:19 <TAsn> weird.
Oct 19 19:52:21 <TAsn> but that's what fails.
Oct 19 19:52:25 <TAsn> (or I did something else wrong)
Oct 19 19:52:56 <CIA-26> SHR: 03mok 07libphone-ui-shr * rcf231ff079cc 10/src/Makefile.am: define G_LOG_DOMAIN
Oct 19 19:53:09 <TAsn> what's our rev?
Oct 19 19:53:13 <TAsn> 42873?
Oct 19 19:53:17 <TAsn> or 387?
Oct 19 19:53:49 <TAsn> in the meanwhile, got any ideas what's broken with x11-16?
Oct 19 19:53:55 <larsc> Gnutoo: you know, i have nothing to do with shr or oe
Oct 19 19:54:20 <Gnutoo> larsc, ah so why did you do a patch for xf86-input-tslib?
Oct 19 19:55:01 <Gnutoo> larsc, maybe I talked to the wrong person...if it's the case I'm sorry
Oct 19 19:55:07 <TAsn> mrmoku, 
Oct 19 19:55:08 <TAsn> here with
Oct 19 19:55:13 <TAsn> Rev: 42775
Oct 19 19:55:28 <TAsn> (not on moko)
Oct 19 19:55:28 <TAsn> hoversels in elmentary test
Oct 19 19:55:28 <TAsn> don't really do anything
Oct 19 19:55:37 <TAsn> but they don't segfault
Oct 19 19:55:37 <TAsn> or output any message
Oct 19 19:55:41 <CIA-26> SHR: 03mok 07libphone-ui * rfea56dc04aa2 10/src/Makefile.am: define G_LOG_DOMAIN
Oct 19 19:55:48 <Gnutoo> larsc, ah no it was you
Oct 19 19:55:49 <mrmoku> TAsn: they don't segfault nowhere
Oct 19 19:55:58 <mrmoku> TAsn: they just don't sel
Oct 19 19:56:00 <TAsn> s
Oct 19 19:56:00 <TAsn> but they do pop.
Oct 19 19:56:04 <TAsn> is this what's expected from elementary_test
Oct 19 19:56:20 <TAsn> ?
Oct 19 19:56:20 <TAsn> oh, i c.
Oct 19 19:56:23 <mrmoku> well... to be honest I don't remember how they worked in elm_test
Oct 19 19:56:23 <TAsn> I'll upgrade tomorrow to latest and check that.
Oct 19 19:56:36 <mrmoku> but I suspect them to select as otherwise it would be just hovers ;)
Oct 19 19:56:42 <TAsn> hehe :)
Oct 19 19:56:47 <mrmoku> TAsn: doing that almost daily
Oct 19 19:56:59 <TAsn> mrmoku, really?
Oct 19 19:57:03 <mrmoku> maybe someone should ask in #e if semantics changed or someting...
Oct 19 19:57:03 <TAsn> then I won't ;)
Oct 19 19:57:07 <mrmoku> TAsn: on my laptop, yes
Oct 19 19:58:36 <mrmoku> TAsn: good spoken (on #e) :P
Oct 19 19:58:49 <Gnutoo> <larsc>	Gnutoo: my plan is to fix xf86-input-tslib for xserver 1.7.0 tonight
Oct 19 19:58:49 <TAsn> hehe ;)
Oct 19 19:58:49 <larsc> yes
Oct 19 19:58:49 <Gnutoo> do you have a patch?
Oct 19 19:58:50 <Gnutoo> that is finished?
Oct 19 19:58:57 <Gnutoo> or should I finish it?
Oct 19 19:58:58 <larsc> yes, you have it
Oct 19 19:59:05 <larsc> except for the #ifdefs
Oct 19 19:59:08 <Gnutoo> ok so I'll have to put ifdefs and that'll be ok
Oct 19 19:59:12 <larsc> no i have it with ifdefs
Oct 19 19:59:20 <larsc> give me a moment to upload it
Oct 19 19:59:22 <Gnutoo> ok thanks...
Oct 19 19:59:34 <Gnutoo> who should I credit btw?
Oct 19 20:01:14 <TAsn> mrmoku, who starts who? (phoneuid vs phonefsod)
Oct 19 20:01:40 <mrmoku> TAsn: they start independently
Oct 19 20:01:50 <mrmoku> phonefsod via init and phoneuid via xsession
Oct 19 20:01:53 <TAsn> okie.
Oct 19 20:02:22 <TAsn> I'm glad :)
Oct 19 20:02:26 <mrmoku> this PIN problem is really strange... phoneuid log says it shows it... but it does not popup
Oct 19 20:02:28 <TAsn> phonefsod should start in init.
Oct 19 20:02:35 <mrmoku> is not visible but somehow running
Oct 19 20:02:37 <TAsn> mrmoku, :|
Oct 19 20:02:53 <Heinervdm> mrmoku: should we try tslib instead of evdev too?
Oct 19 20:03:24 <mrmoku> Heinervdm: no opinion on that... probably it might be better?
Oct 19 20:03:35 <TAsn> mrmoku, :|
Oct 19 20:03:35 <Heinervdm> mrmoku: we have to try :)
Oct 19 20:04:14 <TAsn> Heinervdm, please try to save us, do everything in your power ;]
Oct 19 20:04:14 <TAsn> (/me is trying to sound dramatic)
Oct 19 20:04:37 <larsc> Gnutoo: https://dev.openwrt.org/browser/packages/Xorg/driver/xf86-input-tslib/patches/030-xserver-1.7.patch
Oct 19 20:05:11 <Gnutoo> larsc, thanks a lot...btw when you told me you were not related to oe I thought about openwrt....
Oct 19 20:05:39 <Gnutoo> I'll credit openwrt then
Oct 19 20:05:49 <Heinervdm> larsc: what did you change compared to my patch? i can't see a difference :)
Oct 19 20:06:02 <larsc> Heinervdm: I don't know, but it works for me
Oct 19 20:06:17 <Heinervdm> it's running too?
Oct 19 20:06:32 <larsc> at least xorg is not crashing
Oct 19 20:07:03 <Heinervdm> ok, then there have to be a difference :)
Oct 19 20:13:44 <larsc> but i wasn't able to test it with a real ts device yet since my kernel still lacks a ts driver
Oct 19 20:14:58 <Gnutoo> larsc, I've one
Oct 19 20:15:04 <Gnutoo> so I'll try
Oct 19 20:15:06 <Gnutoo> thanks a lot
Oct 19 20:15:09 <larsc> good
Oct 19 20:16:37 <mrmoku> TAsn: #e is very verbose tonight ;)
Oct 19 20:18:39 <Heinervdm> mrmoku: i've send a patch for tslib, but i can't test it, because my build env isn't populated :)
Oct 19 20:18:52 <TAsn> shit
Oct 19 20:18:57 <TAsn> mrmoku, like always. ;)
Oct 19 20:19:06 <Heinervdm> mrmoku: can you build it?
Oct 19 20:19:08 <larsc> does xserver-properties.h exist in earlier xorg versions?
Oct 19 20:19:29 <Heinervdm> don't know have checked just for 1.7
Oct 19 20:21:22 <mrmoku> Heinervdm: shr/merge?
Oct 19 20:21:28 <Heinervdm> mrmoku: import
Oct 19 20:21:43 <Heinervdm> mrmoku: but you can apply to both
Oct 19 20:23:27 <mrmoku> Heinervdm: just try if xf86-input-tslib builds?
Oct 19 20:23:35 <Heinervdm> mrmoku: yes
Oct 19 20:23:45 <Heinervdm> then i will install it 
Oct 19 20:24:34 <Heinervdm> i deleted my recipe from testing, so i don't know if i applyed the patches in the correct order
Oct 19 20:24:45 <Heinervdm> oh, i forgot the patch=1...
Oct 19 20:25:24 <prahal> found one issue . If link is not in active calls http://git.shr-project.org/git/?p=shr.git;a=blob;f=libframeworkd-phonegui-efl/src/view/call-common.c;h=b1fa32a04fa311180c177ad2b11e7888761c9a2e;hb=4367c60f454137d36c16d0b031ad808555d75c89#l345 fails due to the check for win after dequeueing (and thus ophonekitd dies) . Also should not the check for win value be win != -1 or win >= 0 instead of !win?
Oct 19 20:26:18 <Heinervdm> mrmoku: and i think dynamic-xy will not apply
Oct 19 20:26:51 <prahal> this made ophonekitd dies when receiving a call while in communication already
Oct 19 20:28:27 <prahal> ok NULL is fine ... only there needs to be a check for it before dequeueing it seems
Oct 19 20:30:46 <mrmoku> Heinervdm: well... it applied
Oct 19 20:30:51 <mrmoku> (building right now)
Oct 19 20:31:07 <Heinervdm> mrmoku: did you add the missing patch=1 ?
Oct 19 20:31:32 <Heinervdm> else there is no change ;)
Oct 19 20:31:42 <mrmoku> Heinervdm: no just applied your path
Oct 19 20:31:45 <mrmoku> +c
Oct 19 20:32:00 <Heinervdm> then it won't build
Oct 19 20:32:01 <mrmoku> Heinervdm: shall I stop and add it?
Oct 19 20:32:08 <Heinervdm> yes
Oct 19 20:32:27 <mrmoku> it is still building other stuff
Oct 19 20:32:33 <mrmoku> fixesproto no
Oct 19 20:32:33 <mrmoku> w
Oct 19 20:35:35 <TAsn> prahal, efl is kinda deprecated, though the error you described looks interesting
Oct 19 20:35:39 <TAsn> will take a look later
Oct 19 20:35:54 <TAsn> thanks.
Oct 19 20:37:07 <mrmoku> prahal, TAsn: a second incoming call while having an active one is a long standing bug :(
Oct 19 20:37:41 <prahal> TAsn, to add more it looks like the crash happened because I did not activated the second call . Thus it was not in active list and dequeue of it aborted ophonekitd
Oct 19 20:38:13 <TAsn> mrmoku, no it's not.
Oct 19 20:38:28 <TAsn> it works flawlessly for a couple of months now.
Oct 19 20:38:39 <TAsn> I fixed it a long time ago.
Oct 19 20:38:48 <mrmoku> huh, really?
Oct 19 20:39:22 <mrmoku> Heinervdm: Running task 1700 of 3015
Oct 19 20:39:29 <mrmoku> this will take some time :|
Oct 19 20:39:40 <mrmoku> don't know if I will survive it :P
Oct 19 20:40:01 <prahal> TAsn, should I still use ophonekitd ? should I switch to efl2 only or more (phoneuid, phonefsod ... I am lost
Oct 19 20:40:25 <mrmoku> prahal: new is: phonefsod + phoneuid + libphone-ui + libphone-ui-shr
Oct 19 20:40:39 <prahal> thanks 
Oct 19 20:40:39 <mrmoku> phonefsod + phoneuid == oponekitd
Oct 19 20:40:44 <mrmoku> libphone-ui == libframeworkd-phonegui
Oct 19 20:40:54 <mrmoku> libphone-ui-shr == libframeworkd-phonegui-efl(2)
Oct 19 20:41:24 <mrmoku> prahal: looks like it works fine
Oct 19 20:41:30 <mrmoku> apart from PIN entry
Oct 19 20:41:38 <mrmoku> so if your SIM has a PIN... no go
Oct 19 20:41:48 <prahal> I don't use pin so fine it will be
Oct 19 20:41:52 <mrmoku> :)
Oct 19 20:42:15 <TAsn> prahal, but you also need to get
Oct 19 20:42:46 <TAsn> phoneui-apps-*
Oct 19 20:42:46 <TAsn> for every app
Oct 19 20:42:46 <TAsn> and remove shr-*
Oct 19 20:42:46 <TAsn> for every app
Oct 19 20:44:03 <TAsn> prahal, ok, let us know if you find bugs :)
Oct 19 20:45:15 <prahal> sure ... I ll attempt to contribute back also ... 
Oct 19 20:45:53 <TAsn> great ;)
Oct 19 20:46:17 <prahal> if I stop trying to find out why mplayer does not work with dmix with debian libraries (I succeed in getting sound but one could barely call this music)
Oct 19 20:46:31 <TAsn> prahal, if you can
Oct 19 20:46:38 <TAsn> we need help in segfaulting assurance
Oct 19 20:46:39 <Gnutoo> btw there is something wrong in my frameworkd.conf
Oct 19 20:46:43 <TAsn> and memory management
Oct 19 20:46:52 <TAsn> we started with a leaking segfaulting code
Oct 19 20:46:57 <Gnutoo> something power off the light of my screen
Oct 19 20:46:57 <TAsn> and tried to fix as much as we could
Oct 19 20:47:00 <Gnutoo> what can it be?
Oct 19 20:47:10 <TAsn> but we haven't found all the segfaults and all the leaks just yet.
Oct 19 20:47:21 <TAsn> which reminds me
Oct 19 20:47:23 <CIA-26> SHR: 03mok 07libphone-ui-shr * reae926d0d496 10/src/phoneui-sim-auth.c: sim-auth: actually show the window
Oct 19 20:47:31 <TAsn> mrmoku, I'll run valgrind on it sometime soon :)
Oct 19 20:47:46 <Tanuva> what a commit message... *g*
Oct 19 20:47:47 <mrmoku> ooohh... nooo :P
Oct 19 20:47:58 <TAsn> it'll help us catch most if not all of the nasty leaks.
Oct 19 20:48:14 <TAsn> though I assume our main leakage comes from hash tables
Oct 19 20:48:19 <mrmoku> it will nicely visualize our incompetence in the commit history ;)
Oct 19 20:48:35 <TAsn> when we pass strdup(bla) values when we should just pass the value.
Oct 19 20:48:39 <TAsn> or the other way around.
Oct 19 20:49:01 <Gnutoo> I'll try somethign
Oct 19 20:49:01 <mrmoku> all hashtable we get from dbus must be destroyed
Oct 19 20:49:08 <mrmoku> don't think we destroy even one :P
Oct 19 20:52:04 <mrmoku> TAsn: building new libphone-ui-shr now... hopefully PIN works now :)
Oct 19 20:52:35 <Gnutoo> does someone knows the framework?
Oct 19 20:52:44 <Gnutoo> It power off the light of my screen
Oct 19 20:52:52 <Gnutoo> how can I prevent that?
Oct 19 20:53:22 <mrmoku> Gnutoo: temporarily or permanent?
Oct 19 20:53:35 <mrmoku> if you request the Display resource it will stay on
Oct 19 20:53:38 <Gnutoo> mrmoku, basically it's the same than echo 0 > /sys/class/led/lcd-something/brightness
Oct 19 20:53:42 <Gnutoo> ok
Oct 19 20:53:57 <Gnutoo> I've to echo 255 to make it re-work
Oct 19 20:54:19 <Gnutoo> mrmoku, how do I request the display resource?
Oct 19 20:55:02 <JaMa> Weiss: are you still here?
Oct 19 20:55:05 <mrmoku> good question... a program can request the resource via a dbus call... but the resource will be released automaticall when the program terminates
Oct 19 20:55:17 <JaMa> Weiss: this WSOD now is nasty one.. its still there after reboot
Oct 19 20:55:22 <mrmoku> you can set the ResourcePolicy for Display to enabled
Oct 19 20:55:30 <Gnutoo> mrmoku, basically in illume without FSO it works...that is to say when you touch the screen it becomes 255 again
Oct 19 20:55:59 <Gnutoo> mrmoku, maybe I get it
Oct 19 20:56:07 <JaMa> Weiss: after baterry removal (screen goes off, but during kernel init WSOD again.., u-boot menu works.. but if I power down from there and start kernel with Qi again.. then WSOD again..
Oct 19 20:56:13 <Gnutoo> mrmoku, I should register the touchscreen or a button to FSO no?
Oct 19 20:56:14 <mrmoku> Gnutoo: probably the correct fix would be to teach frameworkd how to handle your display
Oct 19 20:56:14 <TAsn> YAY
Oct 19 20:56:22 <Gnutoo> ok
Oct 19 20:56:36 <TAsn> oh not yay
Oct 19 20:56:37 <TAsn> sec.
Oct 19 20:56:41 <Gnutoo> I need to do that before commiting the config file
Oct 19 20:57:40 <Tanuva> any idea why my recipe, or rather the distutils, fail copying the icon to /usr/share/pixmaps/? http://pastebin.ca/1630686 Seems like it wants to copy into the 'real' filesystem, but why?
Oct 19 20:57:44 <mrmoku> TAsn: working on opimd?  :P
Oct 19 20:58:00 <JaMa> Weiss: its solvable by booting another kernel from u-boot or Qi.. so no big problem, but maybe it will help you discover the problem.. maybe its just that last screen which is saved in memory and if i wait enough for xorg to init again then I would get normal screen after refresh
Oct 19 20:58:30 <mrmoku> Tanuva: don't give distutils absolute paths
Oct 19 20:58:32 <mrmoku> won't work
Oct 19 20:59:34 <mrmoku> Heinervdm: hehe... build failed at mesa-dri
Oct 19 20:59:42 <Heinervdm> :)
Oct 19 20:59:55 <Tanuva> mrmoku: so what should I tell it instead? ./usr/share/pixmaps?
Oct 19 20:59:57 <Heinervdm> do we have mesa-dri in shr/import?
Oct 19 21:00:07 <mrmoku> glamo_cmdq.c:35: error: 'drm_glamo_cmd_burst_t' undeclared (first use in this function)
Oct 19 21:00:14 <mrmoku> looks like
Oct 19 21:00:27 <TAsn> mrmoku, yes.
Oct 19 21:00:56 <mrmoku> Tanuva: don't know... just remember the absolute path problem
Oct 19 21:01:04 * mrmoku is python noob
Oct 19 21:01:06 <Heinervdm> Tanuva: how does your setup.py look like?
Oct 19 21:01:14 <TAsn> man, I'm laggy.
Oct 19 21:01:14 <TAsn> brb
Oct 19 21:02:01 <JaMa> mrmoku: libdrm should be updated first..
Oct 19 21:02:57 <Gnutoo> mrmoku, ok in what part of frameworkd it is?
Oct 19 21:04:47 <mrmoku> Gnutoo: not sure... but my guess would be odeviced... powercontrol_neo.py
Oct 19 21:04:56 <Gnutoo> ok thanks a lot
Oct 19 21:05:31 <Tanuva> Heinervdm: http://pastebin.ca/1630709
Oct 19 21:05:37 <TAsn> shitty isp.
Oct 19 21:06:27 <mwester> Hey mrmoku - what would happen if I were to download the latest unstable image?  Would I be happy?
Oct 19 21:06:53 <TAsn> mwester, like everything in life this only depends on how low your standards are, and how many beers you had.
Oct 19 21:06:53 <TAsn> :)
Oct 19 21:07:21 <mwester> I don't drink beer, and my standards are among the toughest anywhere.
Oct 19 21:07:27 <mwester> So I guess I'd be happy, then.
Oct 19 21:07:30 <mwester> Right? :D
Oct 19 21:07:30 <TAsn> :)
Oct 19 21:07:40 <TAsn> probably.
Oct 19 21:07:40 <TAsn> :)
Oct 19 21:07:41 <TAsn> j/k
Oct 19 21:07:44 <TAsn> I'm happy with it
Oct 19 21:07:46 <Gnutoo> mrmoku, thanks I think it's there
Oct 19 21:07:46 <TAsn> it's a lot faster
Oct 19 21:07:50 <TAsn> a lot more stable
Oct 19 21:08:00 <TAsn> and generally better
Oct 19 21:08:03 <TAsn> though there are issues
Oct 19 21:08:13 <mwester> Truthfully -- mrmoku told me not to try to build it, hence I'm asking if there's a prebuilt image that works better.
Oct 19 21:08:16 <TAsn> as it haven't even reached a developer snapshot status :)
Oct 19 21:08:35 <Heinervdm> Tanuva: it should look like that: http://pastebin.ca/1630717
Oct 19 21:08:55 <TAsn> ffs I'm such an idiot. :) accidentally pressed up arrow and then enter
Oct 19 21:08:58 <TAsn> just shut down my moko
Oct 19 21:09:04 <mrmoku> mwester: to meet your standards we need one more day of testing :)
Oct 19 21:09:05 <Heinervdm> Tanuva: all entry's from script are copied to /usr/bin automatically
Oct 19 21:09:05 <TAsn> since the last thing I did was "reboot"
Oct 19 21:09:12 <TAsn> mrmoku, and fixing some issues
Oct 19 21:09:18 <TAsn> like name resolving in messages
Oct 19 21:09:21 <TAsn> (both places)
Oct 19 21:09:35 <TAsn> and mwester strikes me as a guy that uses pin lock :)
Oct 19 21:09:46 <Heinervdm> Tanuva: but entries for the user directory shouldn't be included in the package, they should be autogenerated on startup
Oct 19 21:09:46 <TAsn> so we'll have to address that as well.
Oct 19 21:09:51 <mwester> actually I don't... I should though.
Oct 19 21:09:53 * mrmoku just booted the hopefully pin fixed thing
Oct 19 21:10:06 <TAsn> mrmoku, without a pin locked sim? :)
Oct 19 21:10:08 <mrmoku> waiting for the dialog to pop up :)
Oct 19 21:10:18 <mrmoku> TAsn: took wifeys to test :P
Oct 19 21:10:22 <TAsn> hehe :)
Oct 19 21:10:33 <Gnutoo> mrmoku, disabling odeviced fixed it
Oct 19 21:10:34 <Gnutoo> thanks
Oct 19 21:10:36 <mrmoku> YEAH... pops up :D
Oct 19 21:10:37 <Heinervdm> Tanuva: because packages are installed as root, and the programm is probably not run as root
Oct 19 21:10:47 <TAsn> mrmoku, wife must be thrilled :)
Oct 19 21:11:08 <mrmoku> hmm... Checking window does not go away though :P
Oct 19 21:11:18 <Tanuva> Heinervdm: sounds reasonable, gonne retry...
Oct 19 21:11:28 <mrmoku> TAsn: wifey is not using it much... though she did not even notice ;)
Oct 19 21:11:37 <TAsn> :)
Oct 19 21:11:49 <TAsn> I meant, it sounds like you are one step closer to buying her a moko
Oct 19 21:11:57 <TAsn> I bet she doesn't like the sound of that :)
Oct 19 21:13:17 * mwester puts a battery in his gta02, and wonders if it will even power up any more...
Oct 19 21:13:23 <Gnutoo> btw there was a split problem with sms now there is a split problem with USSD
Oct 19 21:13:27 <Gnutoo> at least I think
Oct 19 21:13:43 <mrmoku> well TAsn you still have to learn a lot - I will get me a PalmPre and she will get my old beloved FR ;)
Oct 19 21:13:48 * mwester notices that his SIM card has gone missing from his gta02...
Oct 19 21:14:05 <mrmoku> mwester: the 'no SIM present' dialog works :P
Oct 19 21:14:29 <Tanuva> lol
Oct 19 21:14:36 <mwester> hehe
Oct 19 21:14:47 <Heinervdm> that was a fast boot, within 30 seconds :P
Oct 19 21:15:11 <TAsn> mrmoku, hehe :)
Oct 19 21:15:14 <TAsn> I also want a plam pre
Oct 19 21:15:19 <TAsn> once we got SHR running on it.
Oct 19 21:15:39 <Heinervdm> i read that the akku lasts only 2 days on the Pre...
Oct 19 21:16:11 <mwester> It boots... 
Oct 19 21:16:19 <mwester> the shr image on it is from 06 June 2009
Oct 19 21:16:22 <mwester> :D
Oct 19 21:16:26 <mwester> I've been away for a while, I guess.
Oct 19 21:16:31 <mrmoku> :
Oct 19 21:16:32 <mrmoku> )
Oct 19 21:16:36 <mwester> Ahh.. love that "Don't Panic".
Oct 19 21:16:43 <mwester> My blackberry doesn't do that...
Oct 19 21:17:08 <TAsn> mrmoku, solved the resolving issue! :)
Oct 19 21:17:18 <mrmoku> nice :)
Oct 19 21:17:41 <[Rui]> oh my shr-u tree is building!
Oct 19 21:17:47 <TAsn> as I suspected and told dos1 a long time ago
Oct 19 21:17:53 <TAsn> some numbers are identified as unicode
Oct 19 21:17:56 <TAsn> (by framework)
Oct 19 21:18:02 <TAsn> no idea why
Oct 19 21:18:06 <TAsn> but it doesn't matter.
Oct 19 21:18:33 * Tanuva has a 3d terminal... alternating bold red and normal white lines...
Oct 19 21:18:44 <mwester> Now surely I dont' have to reflash -- "opkg upgrade" should work.
Oct 19 21:18:51 <mwester> It's only been from June.
Oct 19 21:19:22 * mrmoku considers to go to bed before mwester fires oof the opkg command :P
Oct 19 21:20:50 <[Rui]> mrmoku: I see the dust hasn't settled yet :)
Oct 19 21:21:24 <Kensan> mwester: did the same yesterday and lo behold id dideth boot.
Oct 19 21:22:03 <mrmoku> TAsn: will fix the second part of PIN tomorrow
Oct 19 21:22:07 <TAsn> mrmoku, cool :)
Oct 19 21:22:08 <mrmoku> need some sleep now
Oct 19 21:22:09 <mwester> Kensan,  hmmm...
Oct 19 21:22:14 <TAsn> mwester, opkg upgrade worked great for me.
Oct 19 21:22:19 <mrmoku> mwester: good luck :)
Oct 19 21:22:25 <mrmoku> and good night :D
Oct 19 21:22:32 <Kensan> mwester: I mean the plug in the battery and boot up part. not the upgrade thing...
Oct 19 21:22:33 <mwester> What are these developers doing that opkg upgrades don't work; it's only been since June!
Oct 19 21:22:36 <mwester> :P
Oct 19 21:22:46 <mwester> Oh - mine booted.
Oct 19 21:23:03 <mickey|tv> mwester: welcome back :)
Oct 19 21:23:05 <mwester> and it has some stored SMS too.
Oct 19 21:23:13 <mwester> mickey|tv,  greetings!
Oct 19 21:23:13 <Kensan> mwester: I had to make a phonecall because otherwise the operator would have deactivated my sim
Oct 19 21:23:37 <TAsn> mrmoku|away, !!!!
Oct 19 21:23:41 <TAsn> please tell me you are still here ;)
Oct 19 21:23:42 <mwester> Kensan,  they don't care if you call, here, they just want you to pay them more money every month or three.
Oct 19 21:23:46 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r3e9f338e9db2 10/fsogsmd/src/ (4 files in 2 dirs): fsogsmd: org.freesmartphone.GSM.Call.SendDtmf() done
Oct 19 21:24:25 <[Rui]> mrmoku|away: good night
Oct 19 21:24:26 <Kensan> mwester: That's why I got a prepaid card. Luckily somebody told me that you have to use the sim card (write text message or make a phonecall) once a year or it will get deactivated.
Oct 19 21:24:39 <Kensan> mwester: and of course any remaining credit will be lost.
Oct 19 21:24:45 <[Rui]> TAsn: is the phone part working?
Oct 19 21:24:54 <TAsn> [Rui], amazingly well, yeah ;)
Oct 19 21:25:00 <[Rui]> TAsn: really?
Oct 19 21:25:17 <[Rui]> TAsn: 'cause I'm a bit tempted but.... also afraid :)
Oct 19 21:25:59 <mwester> Ah.  Prepaid works differently here.  How much time you get depends on how much you pre-pay, and all you have to do is keep pre-paying before that time period is up.  So I've been adding $10 every month, and now have over $100 prepaid -- I guess I need to get active with the device again to use some of that up.
Oct 19 21:26:01 <TAsn> s/well,/well (here),/
Oct 19 21:26:01 <apt> TAsn meant: [Rui], amazingly well (here), yeah ;)
Oct 19 21:26:02 <TAsn> :)
Oct 19 21:27:07 <[Rui]> mwester: that's how prepaid works in Portugal too
Oct 19 21:27:08 <Kensan> mwester: well I am sure there's enough projects who are waiting for somebody like you *heh*
Oct 19 21:27:17 <[Rui]> apt: I don't understand :)
Oct 19 21:27:18 <apt> You don't understand :)?
Oct 19 21:27:38 <[Rui]> apt: your meaning :)
Oct 19 21:28:39 <mwester> apt: you are a foolish bot
Oct 19 21:28:40 <apt> I think you lost me on that one, mwester
Oct 19 21:28:43 <[Rui]> well... keeping fingers crossed... I'm stopping Xglamo to save up memory for the upgrade
Oct 19 21:28:46 <mwester> apt: I'm not surprised.
Oct 19 21:29:18 <Kensan> mwester: did you see http://docs.openmoko.org/trac/ticket/1024
Oct 19 21:29:43 <mwester> that's closed, right.
Oct 19 21:30:39 <mwester> I added some capacitance as indicated, and have one of my GTA02's that works wonderfully -- that was a week or so before I ended up dropping from the face of the earth.
Oct 19 21:30:47 <Kensan> mwester: yep, I remember you were chipping at that way back.
Oct 19 21:31:08 <Kensan> mwester: ah I see.
Oct 19 21:35:01 <[Rui]> huh? 
Oct 19 21:35:15 <[Rui]> TAsn: opkg upgrade to what?
Oct 19 21:35:28 <TAsn> please read in list
Oct 19 21:35:30 <[Rui]> TAsn: I thought shr-u was synced
Oct 19 21:35:31 <TAsn> I explained there :)
Oct 19 21:35:33 <TAsn> no
Oct 19 21:35:36 <TAsn> mrmoku test
Oct 19 21:35:42 <TAsn> opkg upgrading in a weird way there
Oct 19 21:37:59 <Tanuva> with an install from august I still get no updates, is the merge still going on?
Oct 19 21:38:01 <[Rui]> TAsn: which list?
Oct 19 21:38:05 <TAsn> btw
Oct 19 21:38:11 <TAsn> find the solution to the hovesel issue.
Oct 19 21:41:38 <[Rui]> TAsn: you found it?
Oct 19 21:42:09 <TAsn> I asked in e and they told me the answer
Oct 19 21:42:13 <TAsn> so I kinda found it ;]
Oct 19 21:42:37 <[Rui]> TAsn: great :9
Oct 19 21:42:57 <TAsn> "selected"
Oct 19 21:43:00 <TAsn> is the new signal name.
Oct 19 21:43:16 <larsc> Gnutoo: did you had the time to test it yet?
Oct 19 21:53:51 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r65f60278725e 10/fsogsmd/src/lib/ (atcall.vala atcommands.vala): fsogsmd: more work on call handling, pending conference, transfer, and join
Oct 19 21:59:33 <Tanuva> Yay, my recipe/setup.py finally works :D
Oct 19 22:02:35 <TAsn> Tanuva, grats! :)
Oct 19 22:04:31 <Tanuva> time for bed now. fix my program and send the recipe to shr-devel tomorrow...
Oct 19 22:06:09 <DocScrutinizer> ~say: !lart apt
Oct 19 22:06:43 <DocScrutinizer> ~ping
Oct 19 22:06:44 <apt> ~pong
Oct 19 22:07:15 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r5c7d2aa7013d 10/fsogsmd/src/lib/ (atunsolicited.vala modem.vala): fsogsmd: call: enable call waiting URC and retrigger call syncing upon detection
Oct 19 22:55:37 <prahal> DocScrutinizer, I wonder how comes the asound.conf you have works . For me the card only accept 44100 and as the default for alsa is 48000 . Weird . Maybe my kernel is buggy or too old 
Oct 19 22:56:13 <prahal> I indeed managed to produce sound by tweaking but not continuous streams
Oct 19 23:15:16 <DocScrutinizer-8> full OT: can anybody share a pointer why we never seen a meteorite made of dark mater? Why isn't there a couple of dark mater planets, even a dark mater core in our planet?
Oct 19 23:16:11 <lindi-> DocScrutinizer-8: maybe there are?
Oct 19 23:16:54 <DocScrutinizer-8> we should be able to tell dark mater planets, from orbit equations of visible planets
Oct 19 23:22:10 <DocScrutinizer-8> lindi-: iirc you might know some colleagues to pester with these questions. Any pointer to info sorces really appreciated
Oct 19 23:24:10 <DocScrutinizer-8> to me a dark mater with gravitational interaction to barionic mater but refusing to concentrate seems rather paradox
Oct 19 23:49:26 <CIA-26> freesmartphone.org: 03mickey 07cornucopia * r376c357db750 10/fsogsmd/src/ (7 files in 2 dirs): 
Oct 19 23:49:26 <CIA-26> freesmartphone.org: fsogsmd: org.freesmartphone.GSM.Network.GetStatus() done.
Oct 19 23:49:26 <CIA-26> freesmartphone.org: NOTE: Look at atmediators.vala:625-680 if you want to see a real beauty!
Oct 19 23:49:26 <CIA-26> freesmartphone.org: It's the monster of a mediator, but still pretty readable thanks
Oct 19 23:49:28 <CIA-26> freesmartphone.org: to our coroutines (and the stellar fsogsmd architecture, of course ;)
Oct 20 00:07:40 <prahal> phonefsod replaces fso-abyss ?
Oct 20 00:08:31 <prahal> hum no
Oct 20 00:09:32 <prahal> still wondering if it should start before or after frameworkd (making a init header for dependency based init)
Oct 20 02:43:50 <BillK> which should we be using for own builds - shr/import or shr/merge?
**** ENDING LOGGING AT Tue Oct 20 02:59:57 2009