**** BEGIN LOGGING AT Mon Nov 23 02:59:56 2009
Nov 23 03:00:56 <else58> budfive_: I wasted hours  because that page says to BB_GIT_CLONE_FOR_SRCREV = "1" 
Nov 23 03:00:57 <larsc> DocScrutinizer-8: probably not (learn anything important)
Nov 23 03:05:28 <budfive_> else58: should that BB_GIT_CLONE_FOR_SRCREV = "1" setting not be there? I don't know enough about OE 
Nov 23 03:06:28 <else58> you just missed a long discussion about cloning every git repo that oe points to
Nov 23 03:08:08 <else58> so if that is what you are seeing it doing (I did), do comment it out!
Nov 23 03:08:16 <budfive_> else58: apparently so. :) Thanks for the tip
Nov 23 03:10:40 <else58> now, I dieing in matchbox-panel-2 do_fetch with a svn problem:
Nov 23 03:10:53 <else58> "svn: Failed to add directory 'matchbox-panel-2/applets': an unversioned directory of the same name already exists"
Nov 23 03:13:02 <else58> Can I just skip that recipe and continue with shr-image build without matchbox?
Nov 23 03:13:58 <else58> is there a bb option or file I can modify?
Nov 23 03:15:09 * rozzin finally gets to a point where he can test his recipe.
Nov 23 03:20:08 <fredrin> yay
Nov 23 03:22:45 <else58> FYI, I fixed my matchbox svn problem with: "cd ../downloads/svn/svn.o-hand.com/repos/matchbox/trunk/matchbox-panel-2; rm -rf *; svn update"
Nov 23 03:28:31 <rozzin> else58: I think that's where my build failed, too....
Nov 23 03:30:23 <else58> rozzin: once you fix it, you can test it by just building that package (instead of waiting for it to get there again) with:
Nov 23 03:30:26 <else58> . ./setup-env; bb -b recipes/matchbox2/matchbox-panel-2_svn.bb
Nov 23 03:32:38 * mwester_ reads the most recent email on the om kernel lists, and shakes his head at the incredible arrogance.
Nov 23 03:33:02 <mwester_> Oh well.  Us silly mortals, that we would question a God of the Kernel.
Nov 23 03:33:51 <budfive_> When shr-today is locked (slider movement needed to unlock the phone), how much cpu should be active if the slider is moved half-way, with the finger holding it there? I'm seeing my gta02 almost redline in that situation. Is this what's expected?
Nov 23 03:35:26 <larsc> mwester_: wtf is your problem?
Nov 23 03:36:02 <mwester_> *I* have no problem.  
Nov 23 03:36:44 <mwester_> Clearly certain others, who will not even hear anyone else's point of view, might be viewed to have a problem.
Nov 23 03:37:52 <mwester_> Do whatever the **** you want with the kernel, I have no more time to spend arguing the case for the users; clearly we users are too stupid to understand what you are thinking; we warrant no explanation nor discussion, just a decree.
Nov 23 03:38:05 <mwester_> That attitude just pisses me off.
Nov 23 03:38:29 <mwester_> But you're right - I can fork the kernel; I've done it before.  :)  So have fun.
Nov 23 03:39:00 <mwester_> The Kernel will be Pure.  And Good.  It won't do anything for users, perhaps, but that's not the purpose of the Kernel, apparently! :D What an attitude!
Nov 23 03:40:05 <larsc> poor you
Nov 23 03:40:21 <mwester_> Nice response.
Nov 23 03:40:36 <mwester_> Go back to your sandbox and shovel and pail.
Nov 23 03:41:16 <mwester_> Come back and discuss when you learn how to *work with others*
Nov 23 03:43:09 <larsc> hm...
Nov 23 03:43:58 <larsc> i can't understand how you can get so angry about such a stupid issue
Nov 23 03:45:20 <else58> larsc: I think the route of the problem is your statement, "And updating the kernel isn't a distro change?"
Nov 23 03:46:09 <else58> At least in the desktop world, that is false.
Nov 23 03:53:24 <larsc> i don't think that's the main problem, neither do i think it's false.
Nov 23 03:54:14 <fredrin> what works and not work with the .31 kernel?
Nov 23 03:56:20 <fredrin> mwester_: new kernel kids in town, you're just old and grumpy :P 
Nov 23 03:56:34 * fredrin hides 
Nov 23 03:56:42 <larsc> i guess most things exepect userspace work
Nov 23 03:57:15 <fredrin> *space work 
Nov 23 03:57:25 <fredrin> everything runs as root anyway
Nov 23 03:57:26 <mwester_> My main problem with this is not the change itself any longer, but that apparently an answer like "Yes I did." is considered adequate, apparently it is too much to bother to explain why.
Nov 23 03:57:42 <mwester_> fredrin: I *used* to think I wanted to do kernel work, but I found that I empathize too much with users.
Nov 23 03:57:49 <mwester_> :D
Nov 23 03:58:03 <fredrin> :D
Nov 23 03:58:11 <else58> of course it depends on the kernel version jump:  I would expect many userspace changes going from 2.4 to 2.6
Nov 23 03:58:22 <larsc> mwester_: explain, why i know something?
Nov 23 03:58:33 <mwester_> That's my point.
Nov 23 03:59:20 <larsc> "Yes I did, because I read it somewhere"?
Nov 23 03:59:43 <mwester_> Perhaps we have a major cultural or language gap, though.  Perhaps you did not intend to be dismissive with that email response.  It certainly comes across as a slap-down, though.
Nov 23 04:00:26 <larsc> i'm not good with languages
Nov 23 04:01:06 <larsc> natural languages that is
Nov 23 04:01:39 <rozzin> Maybe you guys should, like... talk to one another on the phone or something.
Nov 23 04:02:03 <rozzin> So much more bandwidth there....
Nov 23 04:02:07 <fredrin> kek
Nov 23 04:02:08 <gonzoism> heh, that would keep things from getting heated...
Nov 23 04:02:25 <fredrin> i suggest videoconferance room 
Nov 23 04:02:28 <rozzin> It'd be particularly fitting... on a project developing *phone* software, too :)
Nov 23 04:02:51 <larsc> what were I supposed to answer to that question. i already explained earlier that i'm not feeling to well with breaking the api, but i considered it the lesser evil.
Nov 23 04:03:09 <mwester_> If one cannot express why userspace will be broken with a concise and clear email, then I fail to understand how a verbal discussion would be any better, rozzin. 
Nov 23 04:04:24 <fredrin> larsc +1 good with some api changes now, send out a message that big thing with the whole shr have changed, maybe app devs will update their apps 
Nov 23 04:04:28 <mwester_> larsc: it would seem to me that the obvious response would be to explain why you think that way, and justify your decision to go opposite what seemed to be the word of a rather important kernel developer - Linus himself.
Nov 23 04:04:57 <mwester_> As your email stands, it reads to me that you do not care to explain your position or reasoning to anyone.
Nov 23 04:05:44 <mwester_> And just to be clear on the issue, let's not discuss the stupid vibrator any longer -- I am convinced that the gta01/gta02 prefix is of little matter.  It is the removal of the other interfaces that is worrisome.
Nov 23 04:05:57 <rozzin> Mike: http://www.xkcd.com/438/
Nov 23 04:05:58 <mwester_> That is what still needs discussion and explanation, not dismissal.
Nov 23 04:06:28 <larsc> mwester_: to me that email read like: "Your master and God Linus said ... therefore you shall obey"
Nov 23 04:07:25 <rozzin> Hrm.
Nov 23 04:07:43 <mwester_> Good point.  But if you bristle at an email like that, then you should be careful, because to be very honest, your emails sound like you are presenting yourself as the master and God of the OM kernels.
Nov 23 04:07:52 <rozzin> So..., I'm working on a bitbake recipe for my package...
Nov 23 04:08:18 <mwester_> If you wish to be that, then you'll get some angry subjects, such as I -- but then you are free to change/break/remove interfaces at will.
Nov 23 04:08:30 <rozzin> should I name the recipe-file after the upstream package name, or with the convention used in OE for this class of packages?
Nov 23 04:08:34 <mwester_> Otherwise, one would presume that one can discuss the issue... and that clearly hasn't happened.
Nov 23 04:10:21 <larsc> those changes already happend long time ago when my patchset was not in the om git repositories.
Nov 23 04:13:20 <larsc> and for the more recent ones. i've been discussing them here in this channel with several people
Nov 23 04:13:54 <larsc> i know i might have should send an mail to all of the persons that might be interested in the issue.
Nov 23 04:14:48 <larsc> my excuse is that i try see if something actually is implementable before being stuck in a discussion of pros and cons
Nov 23 04:15:02 <larsc> s/try see/try to see/
Nov 23 04:15:02 <apt> larsc meant: my excuse is that i try to see if something actually is implementable before being stuck in a discussion of pros and cons
Nov 23 04:15:51 <larsc> and it's not as if those changes are undoable
Nov 23 04:16:07 <larsc> not undoable
Nov 23 04:16:44 <larsc> i'm really trying not to be the evil guy
Nov 23 04:25:31 <larsc> and please accept my appologies for whatever i've done that made you being mad at me.
Nov 23 04:25:55 <larsc> and from now on let's work together towards a good solution
Nov 23 04:27:18 <fredrin_> :)
Nov 23 04:27:27 <fredrin_> what do i need to do to test .31 kernel
Nov 23 04:27:46 <fredrin_> is it jus to replace the one i got on the fat partion on the sd-card ?
Nov 23 04:29:31 <larsc> yes
Nov 23 04:29:57 <larsc> but as mwester_ pointed out your userspace probably won't work
Nov 23 04:30:14 <fredrin_> jej, just want to feel the speed 
Nov 23 04:30:18 <fredrin_> and then switch back
Nov 23 04:30:46 <larsc> what speed?
Nov 23 04:31:04 <fredrin_> app start, scrolling ++
Nov 23 04:31:08 <fredrin_> some say
Nov 23 04:31:38 <larsc> scrolling is xf86-video-glamo
Nov 23 04:32:05 <larsc> suspend is faster, and maybe booting
Nov 23 04:32:31 <larsc> but for regular use it should be the same
Nov 23 04:32:55 <fredrin_> mrmoku said it felt faster, even to start apps 
Nov 23 04:33:06 <fredrin_> i'll test anyway
Nov 23 04:33:36 <max_posedon> fredrin, you should check latest kms .31 kernel
Nov 23 04:33:43 <max_posedon> there most of gui improvments
Nov 23 04:33:52 <larsc> well, if you have your userland on a sd card, maybe yes, because sd card access is faster
Nov 23 04:34:38 <fredrin> i'll test this 
Nov 23 04:34:39 <fredrin> http://build.shr-project.org/tests/mrmoku/2.6.31/images/om-gta02/
Nov 23 04:34:45 <fredrin> do i need the extra modules? 
Nov 23 04:35:38 <max_posedon> I think yes
Nov 23 04:43:36 <else58> shr-unstable build do_rootfs failed: Cannot satisfy the following dependencies for task-shr-minimal-x: *  eglibc-binary-localedata-en-us * 
Nov 23 04:44:07 <else58> and ERROR: The following packages conflict with fso-apm: *  apm * 
Nov 23 04:49:59 <max_posedon> fredrin, that kernel really bad
Nov 23 04:50:13 <max_posedon> just tested, its significant! faster
Nov 23 04:50:27 <fredrin> :D
Nov 23 04:50:32 <fredrin> i'll soon test now
Nov 23 04:50:36 <max_posedon> but, can't parse partition table on uSD, no gsm, no sound
Nov 23 04:51:49 <max_posedon> but.. it might be fixed by update-modules
Nov 23 04:52:37 <max_posedon> or may be not
Nov 23 04:52:58 <fredrin> let me see
Nov 23 04:53:08 <fredrin> booting now
Nov 23 04:57:20 <fredrin> hmm it booted in 29 :(
Nov 23 04:57:35 <fredrin> wat
Nov 23 04:59:02 <fredrin> what ever
Nov 23 04:59:05 <fredrin> i'm off to bed
Nov 23 05:42:29 <parilo> Hi,All! I see in Xorg.0.log:
Nov 23 05:42:29 <parilo> (II) Glamo: driver for glamo: Glamo                                                           
Nov 23 05:42:29 <parilo> (WW) Falling back to old probe method for Glamo                                               
Nov 23 05:42:29 <parilo> (II) Loading sub module "fbdevhw"                                                             
Nov 23 05:42:29 <parilo> (II) LoadModule: "fbdevhw"                                                                    
Nov 23 05:42:30 <parilo> (II) Loading /usr/lib/xorg/modules/linux/libfbdevhw.so                                        
Nov 23 05:42:32 <parilo> (II) Module fbdevhw: vendor="X.Org Foundation"                                                
Nov 23 05:42:34 <parilo>         compiled for 1.7.1, module version = 0.0.2                                            
Nov 23 05:42:36 <parilo>         ABI class: X.Org Video Driver, version 6.0                                            
Nov 23 05:42:38 <parilo> (II) Not using KMS                                                                            
Nov 23 05:42:40 <parilo> (II) Glamo(0): using default device
Nov 23 05:42:42 <parilo> is it normal for last shr-unstable image?
Nov 23 06:39:45 <else58> What causes the armv4t/Packages to be rebuilt when a new ipk is added to the directory?
Nov 23 07:16:42 <gonzoism> are the dialer, sms program, and contacts program, maintained by shr or somebody else, like OE ?
Nov 23 07:22:22 <spaetz_> morning
Nov 23 07:22:32 <spaetz_> mmh, modules stripping
Nov 23 07:24:08 <JaMa> mrmoku: stripping fixed, PR bumped.. please rebuild all 3
Nov 23 07:27:13 <mrmoku> JaMa|Wrk: great, thanks. will do in a bit
Nov 23 07:29:51 <spaetz_> 08:25 < spaetz> JaMa: can you have a look at the module_autoload stuff?
Nov 23 07:29:52 <spaetz_> 08:25 < spaetz> now that you are familiar with kernel.bbclass :-)
Nov 23 07:29:52 <spaetz_> 08:26 < spaetz> e.g. we should we loading g_ether and our sound modules through  that rather than a hackish image_do_rootf thingie
Nov 23 07:29:55 <spaetz_> 08:26 < spaetz> because things like this break upgrading via opkg for sure....
Nov 23 07:29:58 <spaetz_> sorry, got disconnected
Nov 23 07:37:24 <spaetz_> JaMae: is it correct that modules_autoload handling writes out ${PKGD}/etc/modutils/basenameblah ?
Nov 23 07:37:37 <spaetz_> I am always confused with those path vars
Nov 23 07:44:41 <parilo> Hi,All! I see in Xorg.0.log:
Nov 23 07:44:42 <parilo> (II) Glamo: driver for glamo: Glamo                                                           
Nov 23 07:44:42 <parilo> (WW) Falling back to old probe method for Glamo                                               
Nov 23 07:44:42 <parilo> (II) Loading sub module "fbdevhw"                                                             
Nov 23 07:44:42 <parilo> (II) LoadModule: "fbdevhw"                                                                    
Nov 23 07:44:42 <parilo> (II) Loading /usr/lib/xorg/modules/linux/libfbdevhw.so                                        
Nov 23 07:44:44 <parilo> (II) Module fbdevhw: vendor="X.Org Foundation"                                                
Nov 23 07:44:46 <parilo>         compiled for 1.7.1, module version = 0.0.2                                            
Nov 23 07:44:48 <parilo>         ABI class: X.Org Video Driver, version 6.0                                            
Nov 23 07:44:50 <parilo> (II) Not using KMS                                                                            
Nov 23 07:44:52 <parilo> (II) Glamo(0): using default device
Nov 23 07:44:54 <parilo> is it normal for last shr-unstable image?
Nov 23 07:45:12 <parilo> my shr become very sloooooooly
Nov 23 07:47:05 <budfive_> parilo: I'm looking at this right now to make my shr useable again, and I'm finding that even without KMS,  the glamo is much more snapy with the newer 2.6.31 kernel
Nov 23 07:48:06 <budfive_> parilo: the 2.6.31 image that mrmoku has posted doesn't reliably suspend, though so that's little comfort. I'm now building the 2.6.29-drm branch to see if that's a workable combination.  The developers should know a lot more, obviously
Nov 23 07:48:28 <Flyser> shr-settings crashes after opkg update ; opkg upgrade (using the 20112009 shr-u image)
Nov 23 07:49:32 <mrmoku> Flyser: hmm... probably have to rebuild it
Nov 23 07:50:29 <mrmoku> moment....
Nov 23 07:50:35 <mrmoku> I did not even sync yet
Nov 23 07:50:48 <mrmoku> why is there a python-elementary update in the feed?
Nov 23 07:51:40 <parilo> budfive_: snapy means faster? unfortunately my dictionary haven't this word... :(
Nov 23 07:52:12 <budfive_> parilo: snappy. typo. yes, faster
Nov 23 07:57:39 <spaetz> mrmoku: yep latest python-elementary already seems to requirer newer elementary and crashes (see mail somewhere)
Nov 23 07:58:07 <spaetz> parilo: yes, that msgs should be normal, I think. And yes sth is making things slow ATM
Nov 23 07:58:21 <spaetz> parilo: but you are wrong in that developers know more about why....
Nov 23 07:58:31 <spaetz> err, budfive_ ^^^
Nov 23 08:03:41 <mrmoku> spaetz, Flyser: synced the complete EFL update now...
Nov 23 08:04:06 <spaetz> ok cool
Nov 23 08:04:11 <mrmoku> spaetz: the mail TAsn forwarded? that change we don't have yet
Nov 23 08:04:36 <spaetz> no someone complaining about a broken python-elementary reference with a crash
Nov 23 08:04:44 <mrmoku> ahh, ok
Nov 23 08:04:57 <spaetz> yep, I know we don't have the python callback change yet
Nov 23 08:05:07 <mrmoku> fine after upgrade shr-settings starts again :)
Nov 23 08:05:14 <spaetz> but hoversels might be fixed in the rev we have now?
Nov 23 08:05:28 <mrmoku> checking
Nov 23 08:05:29 <spaetz> or have we still an older EFL?
Nov 23 08:05:52 <spaetz> I might be able to take a look at shr-setting hoversels tomorrow
Nov 23 08:06:03 <spaetz> and see if bumped EFL fixes things
Nov 23 08:06:15 <mrmoku> spaetz: hmm... we have newer EFL
Nov 23 08:06:19 <mrmoku> and they still don't work :|
Nov 23 08:06:34 <spaetz> mmh, I'll look tomorrow.No time today
Nov 23 08:06:48 * mrmoku busy too
Nov 23 08:09:05 <JaMa|Wrk> spaetz: yes.. there was bug which was fixed later
Nov 23 08:09:51 <gonzoism> woohoo !  opkg install zile !
Nov 23 08:10:04 <JaMa|Wrk> spaetz: its as you said, it writes to ${PKGD}/etc/modutils/basenameblah and its packaged to kernel-module-basenameblah
Nov 23 08:10:20 <gonzoism> are the dialer, sms program, and contacts program, maintained by shr or somebody else, like OE ?
Nov 23 08:11:45 <mrmoku> spaetz: Exception TypeError: "domainWindow() got multiple values for keyword argument 'domain'" in 'elementary.c_elementary._hoversel_callback' ignored
Nov 23 08:11:57 <mrmoku> is what I get for the PIM domains hoversel
Nov 23 08:13:05 <spaetz> JaMa|Wrk: ok cool, then we sholdn't be needing the shr-image.inc:root_fs hack anymore...
Nov 23 08:13:10 <spaetz> will check if it works now
Nov 23 08:13:37 <spaetz> we should also set the other modules via autoload (g_ether and ppp_generic) rather than hacking the rootf
Nov 23 08:13:42 <spaetz> +s
Nov 23 08:13:52 <spaetz> mrmoku: weird
Nov 23 08:14:07 <spaetz> I'll have a look tomorrow if dos doesn't fix it before :)
Nov 23 08:14:32 <blindcoder> JaMa|Wrk: pong
Nov 23 08:14:55 <budfive_> spaetz: thanks
Nov 23 08:16:05 <JaMa|Wrk> spaetz: if so, then postinst has modprobe call and update-modules call to merge /etc/modutils/* 
Nov 23 08:16:49 <spaetz> ok, that would be the correct things to do. IMO
Nov 23 08:16:53 <JaMa|Wrk> blindcoder: have you seen the needed changes Heinervdm requested for your recipes?
Nov 23 08:16:56 <spaetz> will check later
Nov 23 08:18:24 <blindcoder> JaMa|Wrk: removal of gcc dep, but the PV issue I didn't understand
Nov 23 08:25:08 <spaetz> hehe, mrmoku got one ack by Koen
Nov 23 08:31:53 <Weiss> argh
Nov 23 08:32:00 <Weiss> that thread on OM-Kernel hurts to read :(
Nov 23 08:32:25 <mrmoku`> spaetz: me? where=?
Nov 23 08:35:08 <mrmoku`> JaMae: the two extra kernels are built... building the standard one now
Nov 23 08:35:59 <mrmoku`> Weiss: do not let it demotivate you :)
Nov 23 08:37:06 <mrmoku`> Weiss: as 95% of mankinds problems... caused by lack of communication :P
Nov 23 08:38:24 <mrmoku`> JaMae: huh
Nov 23 08:38:39 <mrmoku`> JaMa|Wrk: it did not do the modules package
Nov 23 08:38:57 <mrmoku`> spaetz_: where did I get an ACK?
Nov 23 08:39:17 <spaetz_> SORRY, was disconnected :)
Nov 23 08:39:20 <spaetz_> flaky wlan
Nov 23 08:39:28 <spaetz_> your e-wm split menu off patch
Nov 23 08:40:01 <spaetz_> Re: [oe] [PATCH] e-wm_svn.bb: split ${sysconfdir}/xdg/menus/applications.menu into it's own package
Nov 23 08:40:14 <mrmoku`> spaetz_: heh, got disconnected too :|
Nov 23 08:40:28 <parilo> where opimd stores his data, I can't see my notes in opimd-notes?
Nov 23 08:40:42 <mrmoku`> spaetz_: did not yet get that one :|
Nov 23 08:40:52 <mrmoku`> ohhh
Nov 23 08:40:55 * mrmoku` stupid
Nov 23 08:40:58 * mrmoku` needs coffee
Nov 23 08:41:10 * mrmoku` starts mail fetching process :P
Nov 23 08:41:13 <spaetz_> hehe
Nov 23 08:41:21 * spaetz_ hands mrmoku` a coffee
Nov 23 08:41:37 <mrmoku`> spaetz_: thanks :)
Nov 23 08:42:33 <spaetz_> I sit in the coffeeteria (?sp), so no problem :)
Nov 23 08:51:46 <blindcoder> Heinervdm: g'morning. I've seen the gcc thing, I'll fix that today. But what's bad about PV being equal to SRCREV?
Nov 23 08:53:01 <Heinervdm> blindcoder: Version 66? better make 0.66 or sth like that
Nov 23 08:53:15 <Heinervdm> but that was JaMae 
Nov 23 08:53:19 <Heinervdm> how mentioned this
Nov 23 08:53:38 <JaMa|Wrk> blindcoder: rename recipes to name_svn.bb
Nov 23 08:53:57 <JaMa|Wrk> blindcoder: and put revision in PV string like this PV = "1.0+svnr${SRCPV}"
Nov 23 08:54:25 <Heinervdm> blindcoder: and then: do you really need bash?
Nov 23 08:54:31 <JaMa|Wrk> blindcoder: you can use whatever you like instead of 1.0 but please the rev should be store like this
Nov 23 08:55:10 <gonzoism> how should i change my default shell ? edit  /etc/passwd and /etc/passwd- ?
Nov 23 08:55:27 <gonzoism> i don't see any chsh or usermod packages.
Nov 23 08:55:31 <Heinervdm> blindcoder: and additional files come to a files subdir in the recipe dir
Nov 23 08:56:27 <JaMa|Wrk> Heinervdm: what do you think about moving them to fltk directory?
Nov 23 08:56:53 <blindcoder> Heinervdm: aside from learning and linking against libcurl, yes, fltkhackdiet does need bash... but I think maybe I can fix the script to run with a sh
Nov 23 08:56:53 <JaMa|Wrk> Heinervdm: one topic on OEDEM seems to be about splitting tree and not polluting their namespace :)
Nov 23 08:57:13 <blindcoder> JaMa|Wrk: okay, then it'll be 1.0+svn$SRCREV
Nov 23 08:57:45 <blindcoder> Heinervdm: the additional file was a leftover, it's now all in SVN. I'll put out a completely new patchset shortly, or should I do incremental diffs?
Nov 23 08:57:48 <Heinervdm> JaMa|Wrk: yes, fltk is currently only the fltk recipe and no fltk apps
Nov 23 08:58:10 <spaetz_> fltk directory makes sense to me
Nov 23 08:58:15 <Heinervdm> blindcoder:  no you can do new patches
Nov 23 08:58:44 <JaMa|Wrk> Heinervdm: what do you think about http://pastebin.ca/1683431 ? I will try to do it without bash specifics if you think its worth trying..
Nov 23 08:58:52 <JaMa|Wrk> blindcoder: "1.0+svnr${SRCPV}"
Nov 23 08:59:01 <JaMa|Wrk> blindcoder: or read really long e-mail in oe-devel :P
Nov 23 08:59:27 <mrmoku> JaMa|Wrk: something is wrong with your module stripping... or I'm doing something wrong :P
Nov 23 08:59:36 <mrmoku> JaMa|Wrk: you stripped the complete tar.gz ;)
Nov 23 08:59:44 <JaMa|Wrk> mrmoku: that's right..
Nov 23 09:00:06 <blindcoder> JaMa|Wrk: I'm only on oe-announce, maybe I should subscribe to -devel again.
Nov 23 09:00:13 <mrmoku> JaMa|Wrk: that's right?
Nov 23 09:00:14 <Heinervdm> JaMa|Wrk: this should be ok
Nov 23 09:00:46 <JaMa|Wrk> mrmoku: RP said that we don't need not-stripped tar.gz :)
Nov 23 09:00:49 <JaMa|Wrk> mrmoku: my patch in oe-devel created both.. he said he don't like it and that not-stripped are not needed
Nov 23 09:01:06 <JaMa|Wrk> blindcoder: just use +svnr${SRCPV} please
Nov 23 09:01:12 <blindcoder> JaMa|Wrk: okay.
Nov 23 09:01:28 <Heinervdm> JaMa|Wrk: i think we had only dbg modules in tar.gz and stripped modules in image
Nov 23 09:01:29 <JaMa|Wrk> blindcoder: otherwise I won't commit your recipe and change it in that if someone else commits it..
Nov 23 09:01:32 <Heinervdm> and kernel packages
Nov 23 09:01:43 <JaMa|Wrk> blindcoder: as I did about a week ago for all svn recipes in OE tree
Nov 23 09:01:59 <JaMa|Wrk> Heinervdm: we had no stripped modules..
Nov 23 09:02:08 <JaMa|Wrk> Heinervdm: it was broken in 2 places :)
Nov 23 09:02:12 <mrmoku> JaMa|Wrk: but I have neither?
Nov 23 09:02:16 <mrmoku> no modules.tar.gz
Nov 23 09:02:28 <Heinervdm> JaMa|Wrk: we had stipped modules in shr/import
Nov 23 09:02:36 <JaMa|Wrk> Heinervdm: yes
Nov 23 09:02:53 <Heinervdm> and there the modules in tar.gz weren't stripped
Nov 23 09:03:01 <JaMa|Wrk> Heinervdm: that's true.. I didn't think about middleage anymore :)
Nov 23 09:03:23 <Heinervdm> :DE
Nov 23 09:03:41 <JaMa|Wrk> Heinervdm: you can read about stripping in my yesterday's session in #oe with RP
Nov 23 09:03:58 <JaMa|Wrk> Heinervdm: or check last few commits to kernel.bbclass and module_strip.bbclass
Nov 23 09:04:22 <JaMa|Wrk> now daywork..
Nov 23 09:04:24 <JaMa|Wrk> bbl
Nov 23 09:07:29 <TAsn> mrmoku, should I opkg upgrade?
Nov 23 09:08:35 <blindcoder> JaMa|Wrk: what's the difference between SRCREV and SRCPV?
Nov 23 09:10:01 <mrmoku> TAsn: have to run... bbiab
Nov 23 09:13:14 <JaMa|Wrk> blindcoder: no difference for svn recipes, big difference for git, but goal is to clean tree to use SRCPV for all SCM based recipes
Nov 23 09:13:51 <blindcoder> JaMa|Wrk: alright, but SRCREV is still used for svn co, or should I use SRCPV for that, too?
Nov 23 09:14:05 <blindcoder> sorry for the big amount of asking, just trying to get it right
Nov 23 09:14:12 <JaMa|Wrk> blindcoder: no.. specifi SRCREV as you did, thats right
Nov 23 09:14:22 <JaMa|Wrk> blindcoder: just dont use it in PV string
Nov 23 09:14:31 <JaMa|Wrk> specify
Nov 23 09:15:21 <blindcoder> okay.
Nov 23 09:22:11 <mrmoku> TAsn: sorry... had to pick up my wife
Nov 23 09:22:18 <mrmoku> TAsn: I upgraded this morning
Nov 23 09:22:27 <mrmoku> at least it did not break everything :P
Nov 23 09:23:09 <mrmoku> JaMa|Wrk: can I do something about the modules?
Nov 23 09:23:39 <JaMa|Wrk> mrmoku: not sure whats wrong there.. I built it ok here
Nov 23 09:23:57 <JaMa|Wrk> blindcoder: btw what is "APPDESKTOP = "${WORKDIR}"" for?
Nov 23 09:24:08 <JaMa|Wrk> blindcoder: the same for "APPTYPE = "binary""
Nov 23 09:24:25 <blindcoder> JaMa|Wrk: I took that from another package, to be honest.
Nov 23 09:25:23 <JaMa|Wrk> blindcoder: you forget to rename bb files to _svn.bb :/
Nov 23 09:25:29 <blindcoder> argh...
Nov 23 09:25:56 <JaMa|Wrk> blindcoder: and that APPTYPE binary I would remove, found it in few packages but still no idea what it is for..
Nov 23 09:26:01 <JaMa|Wrk> APPDESKTOP too
Nov 23 09:26:04 <blindcoder> I need to calm down before sending stuff
Nov 23 09:26:16 <JaMa|Wrk> :)
Nov 23 09:26:27 <blindcoder> used to be the same in rocklinux back then
Nov 23 09:26:33 <JaMa|Wrk> i know that feeling.. I always notice something just after Enter click
Nov 23 09:26:44 <JaMa|Wrk> boss is comming..
Nov 23 09:27:04 <blindcoder> yeah, funny commit messages like "hotfix for package" and 5 seconds later "hotfix for hotfix for package"
Nov 23 09:27:18 <TAsn> mrmoku, :P
Nov 23 09:28:04 <JaMa|Wrk> blindcoder: and APPTYPE+APPDESKTOP is imho for recipes inheriting some auto .desktop generation feature ie from opie2 class
Nov 23 09:28:24 <blindcoder> ah, okay.
Nov 23 09:34:03 <blindcoder> what about SECTION, it's mentioned in openmoko wiki, but no example values.
Nov 23 09:38:36 <parilo> I tested some 2 images one from mrmoko directory shr-full-eglibc-ipk--20091116-om-gta02.rootfs.jffs2 with uImage-2.6.29-oe11+gitr119859+8c65792a5c83c76d662a617a7c4e1ae8104bb6a5-r3.5-om-gta02.bin 
Nov 23 09:38:36 <parilo> and shr-full-eglibc-ipk--20091119-om-gta02.rootfs.jffs2 with uImage-2.6.29-oe11+gitr119860+8c65792a5c83c76d662a617a7c4e1ae8104bb6a5-r3.5-om-gta02.bin  from official folder
Nov 23 09:38:36 <parilo> and first much more faster, but still "Not using KMS" etc
Nov 23 09:38:36 <parilo> Is it possible turn on KMS and etc...?
Nov 23 09:41:14 <JaMa|Wrk> parilo: you need kernel from tests/mrmoku/kms
Nov 23 09:41:52 <JaMa|Wrk> parilo: but we all get WSOD during resume, that's why DRM is not enabled in standard SHR kernel
Nov 23 09:43:08 <JaMa|Wrk> parilo: or you can try 2.6.31 from tests/mrmoku/2.6.31 but that's what we are currently just testing and don't expect you neo working as phone with it... yet..
Nov 23 09:44:55 <JaMa|Wrk> mrmoku: you're right about modules.tgz.. I always called -c deploy manually and that works
Nov 23 09:45:22 <Weiss> JaMa|Wrk: with the latest 2.6.31+DRM, you still get WSoD/BSoD/general Doom I guess?
Nov 23 09:46:00 <parilo> JaMa|Wrk: ok, I'll not use kmsed kernel for now and will be waiting for it stability
Nov 23 09:47:44 <blindcoder> JaMa|Wrk: before cluttering the ML even more, here's a pastebin of how the recipes (renamed to *_svn.bb) look like now: http://pastebin.org/56289
Nov 23 09:48:07 <mrmoku> JaMa|Wrk: so... bitbake -c deploy virtual/kernel ?
Nov 23 09:48:19 <blindcoder> JaMa|Wrk: one question: the linked recipe contains a third party image licensed as CC-by-nc-sa, should that be visible in the LICENSE tag, or should I leave that as PD/GPLv2?
Nov 23 09:50:32 <JaMa|Wrk> Weiss: haven't tested yet :/
Nov 23 09:50:53 <JaMa|Wrk> mrmoku: yes.. found bug.. I'll ask RP
Nov 23 09:51:13 <JaMa|Wrk> blindcoder: not sure about licence.. you can ask in #oe maybe
Nov 23 09:51:42 <JaMa|Wrk> mrmoku: if you have rm_work, then probably -c build and then -c deploy
Nov 23 09:52:01 <JaMa|Wrk> mrmoku: my guess is that do_deploy is called before PKGD is populated..
Nov 23 09:52:55 <JaMa|Wrk> blindcoder: much better.. looks good.. what do you think about moving them to some subdirectory?
Nov 23 09:53:33 <blindcoder> JaMa|Wrk: sure, why not?
Nov 23 09:53:48 <blindcoder> JaMa|Wrk: fltk/?
Nov 23 09:54:10 <JaMa|Wrk> blindcoder: not sure if thats right solution
Nov 23 09:54:29 <JaMa|Wrk> but looks better then too many fltk* packages directly in recipes/
Nov 23 09:55:04 <JaMa|Wrk> but if you need aditional files for your recipes then it would be better to use ie recipes/fltk/package_name/blah.desktop
Nov 23 09:55:19 <blindcoder> JaMa|Wrk: in rocklinux we had packages/<maintainer>/<package>, but I don't know what 'you guys' decided to do with sorting 3rd party packages
Nov 23 09:55:21 <JaMa|Wrk> Heinervdm: agreed? ^^^
Nov 23 09:55:37 <blindcoder> JaMa|Wrk: no more additional files, it's all in svn now. the .desktop file was a leftover
Nov 23 09:55:56 <JaMa|Wrk> blindcoder: as we have now everything in oe.dev branch.. its more about #oe policy
Nov 23 09:56:05 <JaMa|Wrk> blindcoder: than our policy
Nov 23 09:56:30 <JaMa|Wrk> blindcoder: we're just tryiny as litle noise as possible :)
Nov 23 09:56:52 <Heinervdm> JaMa|Wrk, blindcoder: it's ok (using fltk directory)
Nov 23 09:56:55 <blindcoder> JaMa|Wrk: of course
Nov 23 09:57:15 <blindcoder> Heinervdm: alright, then it'll be fltk/fltkhackdiet_svn.bb right?
Nov 23 09:57:34 <Heinervdm> yes
Nov 23 09:57:43 <blindcoder> okay
Nov 23 09:59:53 <blindcoder> I'll add all packages but the cocktailbar package now and send a mail regarding fltkcocktailbar-data, as that one is a bit tricky to maintain in a central repository.
Nov 23 10:01:17 <blindcoder> in about five minutes after a coffee :-)
Nov 23 10:01:20 <blindcoder> thanks guys!
Nov 23 10:05:39 <TAsn> mickey|zzZZzz, http://www.vanille-media.de/site/index.php/2009/11/10/towards-the-end-of-2009/#comment-122520 <--- We do use fsodeviced as default (SHR) :)
Nov 23 10:15:13 <mrmoku> JaMa|Wrk: hmm, no. -c build and then -c deploy still does not give me the modules.tar.gz
Nov 23 10:15:23 <mrmoku> JaMa|Wrk: guess I will just wait until it is fixed :)
Nov 23 10:15:45 <JaMa|Wrk> mrmoku: we almost have a fix with RP
Nov 23 10:18:16 <mrmoku> :)
Nov 23 10:25:30 <TAsn> cool
Nov 23 10:25:34 <TAsn> we changed mplayer default conf :)
Nov 23 10:26:10 <TAsn> not so cool: I didn't know about it and waited for hours for it to finish upgrading, and now that I checked, I noticed it just stopped because the config |:
Nov 23 10:26:46 <JaMa|Wrk> we changed it long time ago..
Nov 23 10:27:02 <TAsn> only now it got built though...
Nov 23 10:27:08 <TAsn> (I upgraded 2 days ago iirc)
Nov 23 10:27:09 <JaMa|Wrk> TAsn: why ist upgraded now for you? ah :)
Nov 23 10:27:25 <JaMa|Wrk> hmm last revision bump in mplayer maybe 5 days ago imho..
Nov 23 10:27:35 <TAsn> JaMa|Wrk, but no one built it...
Nov 23 10:27:43 <JaMa|Wrk> ah ok :)
Nov 23 10:27:45 <TAsn> anyhow, upgrade is done. :)
Nov 23 10:28:14 <JaMa|Wrk> TAsn: sorry for that upgrade :P
Nov 23 10:28:28 <JaMa|Wrk> TAsn: but I'll fix fix modules.tgz for you ..
Nov 23 10:28:29 <TAsn> it's ok :)
Nov 23 10:28:36 <TAsn> for me?
Nov 23 10:28:41 <TAsn> for everyone =)
Nov 23 10:29:48 <JaMa|Wrk> you're the one, who cares about users :)
Nov 23 10:29:57 <JaMa|Wrk> TAsn: but kernel-module*.ipk are already fixed..
Nov 23 10:30:04 <JaMa|Wrk> TAsn: only modules.tgz is missing now..
Nov 23 10:30:26 <TAsn> JaMa|Wrk, you actually fixed the more important one :)
Nov 23 10:33:21 <TAsn> Exception TypeError: "setCurrentProfile() got multiple values for keyword argument 'name'" in 'elementary.c_elementary._hoversel_callback' ignored
Nov 23 10:33:29 <TAsn> shr-settings, choosing profile ^
Nov 23 10:35:39 <TAsn> mrmoku, so hoversels in shr-settings still don't work. :|
Nov 23 10:35:54 <mrmoku> yup :(
Nov 23 10:36:53 <JaMa|Wrk> mrmoku: fixed.. no PR bump..
Nov 23 10:38:35 <GarthPS> Hi where can I found the differences between last week image and this night image?
Nov 23 10:38:44 <GarthPS> any anoucement?
Nov 23 10:39:30 <TAsn> GarthPS, no announcements.
Nov 23 10:39:31 <TAsn> EFL bump
Nov 23 10:39:41 <TAsn> fixed the wizard screen a bit
Nov 23 10:39:51 <TAsn> upgraded fsodeviced
Nov 23 10:39:52 <GarthPS> and ffalarm no?
Nov 23 10:39:53 <TAsn> nothing too fancy.
Nov 23 10:39:58 <TAsn> GarthPS, no idea.
Nov 23 10:40:00 <TAsn> I'm off.
Nov 23 10:40:02 <TAsn> ciao.
Nov 23 10:40:03 <GarthPS> ok thx
Nov 23 10:40:28 <TAsn> anyhow, don't flash this image, it's probably best to wait for tomorrow as we'll add more cool stuff :P
Nov 23 10:41:08 <mrmoku> JaMa|Wrk: thanks
Nov 23 10:41:10 <GarthPS> TAsn: ok thx ;)
Nov 23 11:08:36 <mrmoku> JaMa|Wrk: hmm... still no modules.tar.gz
Nov 23 11:08:49 <mrmoku> JaMa|Wrk: I did -c clean before rebuilding
Nov 23 11:08:54 <mrmoku> (and updated OE of course)
Nov 23 11:14:39 <mrmoku> JaMa|Wrk: should I bump kernel rev again?
Nov 23 11:26:22 <JaMa|Wrk> mrmoku: mmt I'll build those 2 again.. but it worked for 2.6.31 here..
Nov 23 11:26:49 <mrmoku> JaMa|Wrk: 2.6.31 was the first I tried
Nov 23 11:27:11 <mrmoku> JaMa|Wrk: or should I do the -c build; -c deploy thing?
Nov 23 11:27:40 <JaMa|Wrk> no just -c clean -c build should work now
Nov 23 11:29:02 * mrmoku picks up son from kindergarten and retries afterwards...
Nov 23 11:36:48 <spaetz_> can that be a problem for fflarms doesn't wake up issue? :
Nov 23 11:36:50 <spaetz_> rtcwake -s 20
Nov 23 11:36:54 <spaetz_> rtcwake: can't open '/dev/misc/rtc': No such file or directory
Nov 23 11:37:16 <spaetz_> perhaps even incoming call wen suspended doesn't work issue?
Nov 23 11:45:34 <spaetz_> also /dev/rtc can't be connected as it's reported as busy. rtcwake -s 20 -d /dev/rtc0 
Nov 23 11:45:38 <spaetz_> rtcwake: can't open '/dev/rtc0': Device or resource busy
Nov 23 11:48:19 <JaMa|Wrk> spaetz_: fuser /dev/rtc0 ?
Nov 23 11:48:57 <spaetz_> fuser /dev/rtc0
Nov 23 11:48:57 <spaetz_> 1345
Nov 23 11:49:05 <spaetz_> what does this mean?
Nov 23 11:50:06 <JaMa|Wrk> pid of process using it
Nov 23 11:50:08 <JaMa|Wrk> which is?
Nov 23 11:50:12 <mrmoku> spaetz_: ps ax | grep 1345
Nov 23 11:50:13 <spaetz_> ahh, checking process
Nov 23 11:50:32 <spaetz_> /usr/bin/fsodeviced
Nov 23 11:50:38 <mrmoku> heh
Nov 23 11:51:42 <JaMa|Wrk> spaetz_: then why does ffalarms touch /dev/rtc or rtcwake? cannot it be done through some fso service?
Nov 23 11:52:01 <mrmoku> that is what it does I think
Nov 23 11:52:07 <mrmoku> with atd-over-fso
Nov 23 11:53:02 * mrmoku tries alarm/suspend/resume with ffalarms
Nov 23 11:55:13 <spaetz_> atd-over-fso is supposed to wake up the device
Nov 23 11:55:30 <spaetz_> but if fsosuspend hogs /dev/rtc that could easily fail, I guess.
Nov 23 11:55:41 <JaMa|Wrk> ah then atd-over-fso is not talking to fsodeviced?
Nov 23 11:55:52 * spaetz_ shrugs
Nov 23 11:55:54 <spaetz_> no clue :)
Nov 23 11:56:06 <spaetz_> I just know that people report that wake up with ffalarms is broken for some
Nov 23 11:56:42 <mrmoku> just verified
Nov 23 11:56:50 <mrmoku> for me too
Nov 23 11:56:53 <spaetz_> alarm comes on when you manually resume.
Nov 23 11:56:56 * JaMa|Wrk has no idea which fso daemon is responsible for what..
Nov 23 11:57:01 <spaetz_> is what I was told
Nov 23 11:58:41 <mrmoku> 2009-11-23T11:52:48.241241Z Kernel26Rtc [INFO] <FsoFramework.Device.Rtc @ /sys/class/rtc/rtc0 : /dev/rtc0>: RTC time equals
Nov 23 11:58:44 <mrmoku> 2009-11-23 12:52:50
Nov 23 11:58:55 <mrmoku> which was when I set the alarm (fsodeviced.log)
Nov 23 11:59:22 <TAsn> I always thought ffalarms talks asks fso for an alarm
Nov 23 11:59:32 <TAsn> but either way
Nov 23 11:59:47 <TAsn> fso should *not* hog /dev/rtc0
Nov 23 11:59:56 <TAsn> as there may be more applications wanting to use that
Nov 23 12:00:03 <TAsn> (not openmoko aware ones)
Nov 23 12:00:25 <spaetz_> TAsn: right
Nov 23 12:00:41 <spaetz_> but atd-over-fso and fsodeviced might be 2 independent pieces
Nov 23 12:00:55 <spaetz_> so if fsodeviced hogs it and atd-over-fso can't talk to it....
Nov 23 12:01:08 <spaetz_> where is that atd-over-fso recipe'
Nov 23 12:01:08 <spaetz_> ?
Nov 23 12:01:33 <mrmoku> spaetz_: in ffalarms folder
Nov 23 12:01:44 <spaetz_> ahh, k
Nov 23 12:01:46 <spaetz_> looking
Nov 23 12:02:36 <spaetz_> "Lightweight At Daemon working on top of org.freesmartphone.otimed"
Nov 23 12:03:02 <spaetz_> TAsn: ^^^ if fsodeviced exclusively hogs /dev/rtc0 then frameworkd can't access it
Nov 23 12:03:17 <TAsn> :|
Nov 23 12:03:24 <JaMa|Wrk> mrmoku: use bitbake virtual/kernel ( if you have switched provider in kms and 2.6.31 or recipe name) without -c build..
Nov 23 12:03:29 <TAsn> someone sholud probably pm mickey|zzZZzz about it. :|
Nov 23 12:03:40 <TAsn> JaMa|Wrk, btw, did me move to 2.6.31?
Nov 23 12:03:46 <TAsn> as moving there is *bad*
Nov 23 12:03:54 <TAsn> mrmoku, we should *not* move to 2.6.31
Nov 23 12:04:17 <spaetz_> WTF is $HANDHELDS_CVS for a source repo?
Nov 23 12:04:37 <JaMa|Wrk> TAsn: no move..
Nov 23 12:04:54 <JaMa|Wrk> TAsn: just switched provider for those 2 alternative kernel builds
Nov 23 12:05:07 <mrmoku> JaMa|Wrk: that was the first thing I tried
Nov 23 12:05:12 <mrmoku> TAsn: ???
Nov 23 12:05:15 <spaetz_> pfeww: http://handhelds.org/cgi-bin/cvsweb.cgi/apps/atd/
Nov 23 12:05:19 <TAsn> http://lists.openmoko.org/pipermail/openmoko-kernel/2009-November/010717.html
Nov 23 12:05:22 <JaMa|Wrk> mrmoku: and still no modules.tgz?
Nov 23 12:05:23 <TAsn> read this before doing anything hasty.
Nov 23 12:05:27 <spaetz_> last touched 3 years ago, it seems :)
Nov 23 12:05:51 <mrmoku> JaMa|Wrk: yeah, but let me retry
Nov 23 12:05:52 <JaMa|Wrk> mrmoku: problem is that do_deploy is defined after do_package but not before do_build
Nov 23 12:06:37 <mrmoku> TAsn: I read the complete thread
Nov 23 12:06:41 <mrmoku> and irc backlog in here
Nov 23 12:07:04 <TAsn> mrmoku, cool. :P
Nov 23 12:07:12 <mrmoku> TAsn: and nobody wants to switch to it before our userspace is ready
Nov 23 12:07:12 <spaetz_> so if "cat /dev/rtc" fails with "resource busy" then atd-over-fso will fail here for sure too: rtcfd = open ("/dev/rtc", O_RDONLY);
Nov 23 12:07:15 <mrmoku> BUT
Nov 23 12:07:21 <mrmoku> 2.6.31 really rocks
Nov 23 12:07:35 <mrmoku> dialer starts in 0.5s instead of 1.2 or something
Nov 23 12:07:35 <TAsn> mrmoku, was just making sure you know userspace should get ready
Nov 23 12:07:36 <TAsn> :)
Nov 23 12:07:42 <TAsn> mrmoku, really?
Nov 23 12:07:46 <mrmoku> yup
Nov 23 12:07:47 <mrmoku> try it
Nov 23 12:07:50 <mrmoku> it rocks :)
Nov 23 12:07:53 <TAsn> are you sure it's not a matter of stripped kernel modules?
Nov 23 12:07:53 <TAsn> :)
Nov 23 12:08:08 <mrmoku> even without the kms stuff scrolling is nice
Nov 23 12:08:15 <mrmoku> TAsn: we do not have those not stripped modules yet ;)
Nov 23 12:08:22 <TAsn> mrmoku, i c.
Nov 23 12:08:41 <TAsn> well it sounds kinda odd there's such a speed boost.
Nov 23 12:08:43 <TAsn> what changed?
Nov 23 12:08:59 <mrmoku> TAsn: maybe something inherited from kernel upstream
Nov 23 12:09:02 <mrmoku> ahh wait
Nov 23 12:09:10 <mrmoku> larsc said something about SD should be faster
Nov 23 12:09:15 <mrmoku> which might explain it
Nov 23 12:09:18 <TAsn> no
Nov 23 12:09:24 <TAsn> it won't explain dialer loading faster
Nov 23 12:09:34 <TAsn> (will explain the system being faster, but nothing more than that.)
Nov 23 12:09:40 <TAsn> mrmoku, I mean, not with this difference
Nov 23 12:09:53 <TAsn> the only thing that happens when opening dialer
Nov 23 12:09:55 <mrmoku> TAsn: try yourself... when you have finished your test ;)
Nov 23 12:10:01 <TAsn> is loading of a very small app
Nov 23 12:10:04 <TAsn> (shr-dialer)
Nov 23 12:10:10 <TAsn> everything else is cached.
Nov 23 12:10:16 <TAsn> s/cached/in ram/
Nov 23 12:10:17 <apt> TAsn meant: everything else is in ram.
Nov 23 12:10:33 <TAsn> mrmoku, I don't question the results, I'm just wondering for the cause :P
Nov 23 12:10:45 <TAsn> anyhow, sd being faster is awesome doesn't matter how you look at it.
Nov 23 12:10:47 <TAsn> mrmoku, oh actually
Nov 23 12:10:50 <mrmoku> TAsn: yeah, no idea. But I was quite amazed :)
Nov 23 12:10:52 <TAsn> since we don't cache dialer
Nov 23 12:10:59 <TAsn> maybe it also loads theme
Nov 23 12:11:14 <TAsn> which might explain the speed boost :)
Nov 23 12:11:25 <TAsn> anyhow, cool.
Nov 23 12:11:32 <TAsn> I just hope it'll get sane already.
Nov 23 12:11:35 <TAsn> ciao.
Nov 23 12:11:36 <mrmoku> TAsn: btw. the only breakage I had (after fixing syfs paths in ogsmd) was alsa
Nov 23 12:11:43 <TAsn> won't be back until after my test.
Nov 23 12:11:53 <mrmoku> TAsn: have fun :P
Nov 23 12:12:00 <TAsn> mrmoku, thanks.
Nov 23 12:12:01 <TAsn> ciao.
Nov 23 12:13:14 <spaetz_> TAsn: we could play with e cache settings too. to avoid SD reading
Nov 23 12:13:28 <spaetz_> sent a mail to shr-devel CC'd to mickey about the /dev/rtc issue
Nov 23 12:13:36 <spaetz_> mickey|zzZZzz: wake up!
Nov 23 12:13:39 <TAsn> spaetz_, (rtc) cool.
Nov 23 12:13:55 <TAsn> spaetz_, (cache) I don't think it's relevant as it's the first time it loads it, isn't it?
Nov 23 12:14:04 <spaetz_> 2st time won't make a difference
Nov 23 12:14:23 <TAsn> spaetz_, oh.
Nov 23 12:14:24 <spaetz_> but there's plenty of tweaks for subsequent calls that could make reopening e.g. message app faster
Nov 23 12:14:31 <spaetz_> at the cost of RAM, obviously
Nov 23 12:14:33 <TAsn> we are going to cache the apps anyone
Nov 23 12:14:36 <TAsn> anyhow*
Nov 23 12:14:42 <TAsn> so no need for e cache
Nov 23 12:14:52 <spaetz_> it might or might not even be necessary if e cache is sufficient
Nov 23 12:14:53 <TAsn> as the windows will already be (mostly) drawn.
Nov 23 12:15:06 <TAsn> spaetz_, it will be
Nov 23 12:15:08 <spaetz_> but making it faster will be cool anyhow :)
Nov 23 12:15:12 <TAsn> as populating from opimd
Nov 23 12:15:17 <TAsn> takes quite some time.
Nov 23 12:15:22 <TAsn> ciao.
Nov 23 12:15:25 <spaetz_> then opimd sucks :)
Nov 23 12:15:31 <spaetz_> it should be the cache
Nov 23 12:15:34 <spaetz_> the *fast* one
Nov 23 12:17:28 <spaetz_> yes, fsodeviced is guilty of exclusively hogging /dev/rtc. just tried to open /dev/rtc readonly from python
Nov 23 12:17:35 <spaetz_> that plainly fails
Nov 23 12:18:03 * spaetz_ files a bug on freesmartphone.org too to make sure it doesn't get forgotten
Nov 23 12:27:56 <spaetz_> and when I kill fsodeviced it says: rtcwake: /dev/rtc0 not enabled for wakeup events
Nov 23 12:27:59 <spaetz_> weird
Nov 23 12:28:16 <spaetz_> which would also explain that the phone doesn't wake up on incoming calls
Nov 23 12:29:30 <BillK> spaetz_: it also affects gps (cant set time), and anything else on that wants timing - critical I think
Nov 23 12:32:22 <spaetz_> BillK: but this points to the issues you have. So hopefully that can be fixed soo again, so you wake up on time again :)
Nov 23 12:32:39 <spaetz_> I basically reacted to your reports as I don't use ffalarms...
Nov 23 12:32:49 <spaetz_> I have a manual alarm clock at home :)
Nov 23 12:33:15 <spaetz_> BillK: right this could affect quite some time issue we still have
Nov 23 12:33:33 <spaetz_> and it's quite puzzling as fsodeviced seems to open the node RDONLY
Nov 23 12:34:27 <BillK> there is also an error on bootup as something tries rtc, and hwclock cant set time on shutdown
Nov 23 12:34:55 <BillK> I got as far as looking at udev rules where its being setup - lotsa changes and they didnt look right
Nov 23 12:35:07 <mrmoku> JaMa|Wrk: still no modules.tar.gz... But no new uImage either..
Nov 23 12:35:12 <BillK> but I had to flash back bfore finding anything concrete
Nov 23 12:36:00 <mrmoku> JaMa|Wrk: retrying with cleaning before now
Nov 23 12:36:23 <JaMa|Wrk> mrmoku: no.. I have fix for it..
Nov 23 12:36:28 <JaMa|Wrk> mrmoku: w8.. 
Nov 23 12:36:52 <JaMa|Wrk> mrmoku: or open kernel.bbclass and find addtask do_deploy, add "before do_build" there
Nov 23 12:41:42 <mrmoku> JaMa|Wrk: I have to wait :)
Nov 23 12:41:49 <mrmoku> lunch time and family is waiting :P
Nov 23 12:41:51 <mrmoku> bbiab
Nov 23 12:59:40 <JaMa|Wrk> mrmoku: pushed and PR bumped
Nov 23 13:21:27 <mrmoku> JaMa|Wrk: thanks
Nov 23 13:29:04 <spaetz_> larsc: /j #oe
Nov 23 13:29:07 <spaetz_> oops
Nov 23 13:29:10 <spaetz_> ignore me :)
Nov 23 13:40:34 <mrmoku> JaMa|Wrk: worked :)
Nov 23 13:44:14 <spaetz_> stripped modules?
Nov 23 13:44:20 <spaetz_> how big is our image now?
Nov 23 13:54:13 <mrmoku> spaetz_: did not rebuild the image
Nov 23 13:54:23 <mrmoku> spaetz_: built the extra kernels (2.6.31 + kms)
Nov 23 13:54:35 <mrmoku> spaetz_: image will come next
Nov 23 13:54:46 <mrmoku> spaetz_: though we might want to fix one or two things first :P
Nov 23 14:04:13 <CIA-86> SHR: 03mok 07libphone-ui-shr * r78897b4330c4 10/src/view/ (message-delete-view.c message-list-view.c): messages: remove message list entries after deletion
Nov 23 14:10:19 <mrmoku> JaMa|Wrk: 2.6.31 gives me a nice kernel panic
Nov 23 14:13:12 <Weiss> mrmoku: with KMS?
Nov 23 14:17:43 <spaetz_> yay for removing sms on deletion :)
Nov 23 14:24:36 <spaetz_> although opimd should just send an "DeletedMessage" signal which should handle that, right?
Nov 23 14:24:39 <mrmoku> Weiss: it gives me too lines
Nov 23 14:24:48 <mrmoku> the first one is VFS not being able to mount
Nov 23 14:25:08 <mrmoku> and the second one glamo switching back to text console due to error
Nov 23 14:25:08 <spaetz_> once opimd sends those signals we might refresh the screen twice then...
Nov 23 14:25:29 <spaetz_> outch
Nov 23 14:25:40 <mrmoku> Weiss: want me to retry for exact text?
Nov 23 14:25:53 <Weiss> mrmoku: which version are you using? yesterday I fixed several problems which prevented X from starting..
Nov 23 14:26:17 <spaetz_> but VFS not able to mount sounds like a pre-X error
Nov 23 14:27:06 <Weiss> mrmoku: is there an actual kernel panic with KMS, or just that X isn't able to start? if the latter, check the Xorg.log\
Nov 23 14:27:31 <mrmoku> Weiss: todays version of 2.6.31+KMS
Nov 23 14:27:45 <mrmoku> Weiss: but it panics because of being unable to mount rootfs
Nov 23 14:27:52 <mrmoku> so I don't think it is your fault ;)
Nov 23 14:27:55 <Weiss> ah, ok :)
Nov 23 14:28:13 <Weiss> not being able to mount rootfs would probably prevent X from starting :)
Nov 23 14:28:19 <mrmoku> probably :P
Nov 23 14:28:24 <spaetz_> I bet it's because mrmoku was buying cheap SD cards again ;-P
Nov 23 14:28:42 <mrmoku> probably.... NOT ;)
Nov 23 14:28:45 <Weiss> your rootfs is on SD?
Nov 23 14:28:47 <mrmoku> yup
Nov 23 14:28:58 <Weiss> I may have broken Glamo-MC
Nov 23 14:28:59 <Weiss> MCI*
Nov 23 14:29:18 <mrmoku> heh, that would explain it then :)
Nov 23 14:29:51 <Weiss> I don't *think* I have though.. does it work if you just change the configuration to enable Glamo-FB and disable DRM? (same kernel source)
Nov 23 14:31:22 <Weiss> but actually I haven't checked..
Nov 23 14:31:26 <mrmoku> Weiss: hmm, not easy to test
Nov 23 14:31:34 <JaMa|Wrk> mrmoku: I'll recheck if there is something changing our oe-defconfig in DRM patches..
Nov 23 14:31:42 <mrmoku> JaMa|Wrk: great, thanks
Nov 23 14:31:52 <JaMa|Wrk> mrmoku: but probably later.. maybe tomorrow :/
Nov 23 14:32:06 <mrmoku> JaMa|Wrk: will try the old KMS one meanwhile :)
Nov 23 14:32:20 <JaMa|Wrk> mrmoku: but same error was when there was MCI driver missing in config..
Nov 23 14:32:28 <JaMa|Wrk> mrmoku: you can try to boot from nand
Nov 23 14:32:42 <JaMa|Wrk> mrmoku: its 50% chance that it will work there :P
Nov 23 14:33:02 <mrmoku> JaMa|Wrk: hehe, enough % to give it a shot :P
Nov 23 14:33:05 <Weiss> actually I think I *did* miss something necessary for MCI to work..
Nov 23 14:33:27 * mrmoku takes away one slice of Weiss's cake ;)
Nov 23 14:33:43 <Weiss> :(
Nov 23 14:33:48 <mrmoku> Weiss: so trying from NAND would be a good test?
Nov 23 14:34:19 <Weiss> yep.. from NAND works fine for me
Nov 23 14:34:31 <Weiss> I don't keep my rootfs on SD, which explains why I didn't notice
Nov 23 14:36:49 <mrmoku> Weiss: ok, will try
Nov 23 14:38:41 <Weiss> actually.. looking at the 2.6.31 MCI code, it doesn't immediately look like it makes the assumption that I needed to fix before..
Nov 23 14:43:26 <CIA-86> SHR: 03mok 07libphone-ui-shr * r72e2e23c1d6e 10/src/view/ (message-delete-view.c message-list-view.c): fix the last commit and write one-hundred times
Nov 23 14:45:04 <spaetz_> JaMa|Wrk: I think I found an issue why the modules_autoload stuff doesn't work
Nov 23 14:45:24 <spaetz_> hehearm-oe-linux-gnueabi-depmod-2.6 -A -b $D -F /home/shr/shr-unstable/tmp/staging/om-gta02-oe-linux-gnueabi/kernel/System.map-2.6.29-rc3 2.6.29-rc3
Nov 23 14:45:32 <spaetz_> oops, slight mispasting, sorrry
Nov 23 14:45:39 <spaetz_> arm-oe-linux-gnueabi-depmod-2.6 
Nov 23 14:45:48 <spaetz_> but we don't have that on the FR
Nov 23 14:46:08 <spaetz_> the only similarly named thing is: arm-oe-linux-gnueabi-cpp :)
Nov 23 14:46:27 <spaetz_> what we do have is: depmod     depmod.26
Nov 23 14:46:56 <spaetz_> ahh, that is called on the host during installation... right?
Nov 23 14:47:09 <spaetz_> how can I debug this
Nov 23 14:47:20 <mrmoku> bbiab
Nov 23 14:48:46 <spaetz_> JaMa|Wrk: and the path is postinst is nonsensical anyway:
Nov 23 14:48:49 <spaetz_> /home/shr/shr-unstable/tmp/staging/om-gta02-oe-linux-gnueabi/kernel/System.map-2.6.29-rc3
Nov 23 14:49:07 <spaetz_> there is not even a /home/shr on this box (or a user with that name)
Nov 23 14:56:43 <spaetz_> ${STAGING_KERNEL_DIR} is nonsensical on this box
Nov 23 14:56:57 <spaetz_> where is that set. and who uses /home/shr here?
Nov 23 14:57:09 * spaetz_ looks for suspects :)
Nov 23 14:57:27 * JaMa|Wrk offers beer for nice navit icon with Display or with Bike
Nov 23 14:58:02 <spaetz_> DOH. it's the package from the buildhost!
Nov 23 14:58:21 <spaetz_> JaMa|Wrk: when is the postinst being executed in an .ipkg file?
Nov 23 14:58:33 <spaetz_> on the host or after installation on the FR ?
Nov 23 14:59:06 <spaetz_> /home/shr/shr-unstable/tmp/staging is the staging location of the buildhost!
Nov 23 14:59:42 <JaMa|Wrk> on host when user installs and on buildhost while doing do_rootfs
Nov 23 15:00:48 <spaetz_> ahh, I see. Makes sense now
Nov 23 15:01:07 <spaetz_> so all it does is a "depmod -a; update-modules" on the FR
Nov 23 15:01:34 <spaetz_> which actually makes sense. But although we have the autoload_module foo it doesn't have anything about modutils in there....
Nov 23 15:14:18 <JaMa|Wrk> spaetz_: you don't have that /etc/modutils/* file in .ipk which is set to autoload_module_module_name?
Nov 23 15:14:48 <mrmoku> Weiss, JaMa|Wrk: hmm... when trying to flash the kernel with dfu-util... I pressed Power before Aux out of habit... and now it booted
Nov 23 15:14:52 <mrmoku> sorry for the noise :P
Nov 23 15:15:12 <spaetz_> JaMa|Wrk: nope
Nov 23 15:15:16 <Weiss> mrmoku: so it's not broken any more?
Nov 23 15:15:39 <mrmoku> Weiss: at least it booted
Nov 23 15:15:40 <mrmoku> X works
Nov 23 15:16:04 <JaMa|Wrk> mrmoku: booted from nand or also from uSD?
Nov 23 15:16:41 <Weiss> mrmoku: that's about as much as you can expect from 2.6.31+KMS at the moment :)
Nov 23 15:18:31 <mrmoku> JaMa|Wrk: from SD
Nov 23 15:18:40 <JaMa|Wrk> ok :)
Nov 23 15:18:49 <mrmoku> JaMa|Wrk: strange thing is I have no modules
Nov 23 15:19:35 <JaMa|Wrk> for 2.6.31?
Nov 23 15:19:53 <JaMa|Wrk> do you need any? :)
Nov 23 15:19:59 * spaetz_ still thinks we should compile GTA02 to include the stuff it needs for the Freerunner in the kernel :)
Nov 23 15:20:35 <mrmoku> JaMa|Wrk: nvm..
Nov 23 15:20:46 <mrmoku> got trapped by the name change of the sound module
Nov 23 15:21:14 <mrmoku> spaetz_: well, you would like 2.6.31 then :)
Nov 23 15:21:49 <mrmoku> JaMa|Wrk: still no working sound though
Nov 23 15:23:01 <spaetz_> sound module name cahnged?
Nov 23 15:23:05 <spaetz_> they are doing that on purpose :-)
Nov 23 15:23:14 <mrmoku> snd_soc_neo1973_wm8753
Nov 23 15:23:18 <mrmoku> :P
Nov 23 15:23:57 <mrmoku> JaMa|Wrk: Koen is giving a hard time with SRCPV :|
Nov 23 15:23:57 <spaetz_> well, it actually might make sense to not include gta02 in a sound kernel module
Nov 23 15:24:03 <spaetz_> he is...
Nov 23 15:24:38 <spaetz_> but then, if it doesn't go in all we have lost is the ability to mix and match local and remote versions of git based pacakges
Nov 23 15:24:44 <spaetz_> we can survive that...
Nov 23 15:25:48 <mrmoku> spaetz_: ?
Nov 23 15:26:26 <mrmoku> spaetz_: we loose upgradeability as long as we use AUTOREV
Nov 23 15:26:39 <spaetz_> the whole shebang is about being able to get synchronous gitrNNN revisions for git based packages
Nov 23 15:26:57 <spaetz_> but AUTOREV worked before even without SCRPV ?
Nov 23 15:27:50 <spaetz_> it's just not consistent across build hosts... right?
Nov 23 15:28:08 <mrmoku> spaetz_: AUTOREV gives different gitr1234+HASH even with SRCREV
Nov 23 15:28:20 <JaMa|Wrk> no we'll win... I think.. look at my proposal about LOCALCOUNT_OVERRIDE by default..
Nov 23 15:28:29 <spaetz_> JaMa|Wrk: it's a close call
Nov 23 15:28:33 <mrmoku> :)
Nov 23 15:28:43 <spaetz_> there are strong opinions about it, I feel the vibrations :)
Nov 23 15:28:44 <JaMa|Wrk> with that enabled nothing will be worse than before
Nov 23 15:29:03 <JaMa|Wrk> and autorev will be better
Nov 23 15:29:21 <spaetz_> JaMa|Wrk: I feel that not everyone agrees with that yet...
Nov 23 15:29:42 <spaetz_> although it might well be true (me is totally lost in that versioning mess)
Nov 23 15:29:47 <spaetz_> I hate git for that
Nov 23 15:30:07 <spaetz_> and I hate git for not providing "git list-rev" on remote repositories...
Nov 23 15:30:23 <JaMa|Wrk> spaetz_: see #oe...
Nov 23 15:30:39 <JaMa|Wrk> spaetz_: now XorA should step in :)
Nov 23 15:30:57 <JaMa|Wrk> spaetz_: and RP has quite a bit influence..
Nov 23 15:31:30 <JaMa|Wrk> spaetz_: nobody believes me ... :/ that with LOCALCOUNT thing it will be at least as good as before.. but they will believe him..
Nov 23 15:32:02 <spaetz_> JaMa|Wrk: probably your detailed mail was a little too detailed, even ;-P
Nov 23 15:32:11 <spaetz_> I have to admit, I got somewhat confused
Nov 23 15:32:12 <JaMa|Wrk> I think that nobody cared about how screwed AUTOREV was.. and now all scream that its a mess
Nov 23 15:32:18 <spaetz_> but that happens easily... :)
Nov 23 15:33:59 <CIA-86> SHR: 03seba.dos1 07shr-settings * r2ea4d9031496 10/shr_settings_modules/shr_profile.py: [profile] fix hoversel
Nov 23 15:34:00 <CIA-86> SHR: 03seba.dos1 07shr-settings * r3f31e0695bfd 10/shr_settings_modules/shr_pim.py: [pim] fix hoversel
Nov 23 15:34:02 <CIA-86> SHR: 03seba.dos1 07shr-settings * r22f2b1c05bcc 10/shr_settings_modules/shr_splash.py: [splash] fix hoversel
Nov 23 15:36:11 <spaetz_> fix hoversels?
Nov 23 15:36:18 <spaetz_> dos1: do they really work now?
Nov 23 15:36:26 <dos1> spaetz_: yup :)
Nov 23 15:36:39 <dos1> well, it wasn't my fault
Nov 23 15:36:42 <spaetz_> ahh, and BTW; I think it would work without that black magic using "partials()"
Nov 23 15:36:45 <spaetz_> dos1: I know
Nov 23 15:36:56 <spaetz_> I've seen the commit that fixes hoversel callbacks
Nov 23 15:37:16 <dos1> but i still had to adjust it to new EFL
Nov 23 15:37:27 <spaetz_> but cool. tahnks
Nov 23 15:37:29 <spaetz_> thanks
Nov 23 15:37:50 * JaMa|Wrk has cookie :)
Nov 23 15:39:39 <JaMa|Wrk> -rw-r--r-- 1 martin users 2661768 lis 23 16:21 ../../tmpdir-dev-shr/deploy/ipk/armv4t/navit-icons_0.1.0+svnr2618-r0.4_armv4t.ipk
Nov 23 15:39:42 <JaMa|Wrk> -rw-r--r-- 1 martin users  476180 lis 23 16:19 ../../tmpdir-dev-shr/deploy/ipk/armv4t/navit_0.1.0+svnr2760-r0.4_armv4t.ipk
Nov 23 15:39:50 <JaMa|Wrk> 2MB saved with every navit svnrev bump
Nov 23 15:40:51 <mrmoku> spaetz_: try 'git ls-remote origin master' in one of our repos
Nov 23 15:41:20 <spaetz_> git ls-remote ?
Nov 23 15:41:25 <mrmoku> yup
Nov 23 15:41:29 <spaetz_> ooh, let me check that :)
Nov 23 15:41:36 <mrmoku> though... that is not sufficient
Nov 23 15:41:46 <mrmoku> we would need git rev-remote-list or something like that
Nov 23 15:42:47 <spaetz_> ok, git ls-remote http://git.shr-project.org/repo/shr-settings.git HEAD is nice already :)
Nov 23 15:43:15 <spaetz_> so at least you don't need to git clone the world in t?rder to check whether sth has changed for AUTOREV'd apps
Nov 23 15:43:41 <spaetz_> but yes git ls-remote-list would even be better..
Nov 23 15:44:07 <Weiss> what would the difference be?
Nov 23 15:44:19 <mrmoku> spaetz_: probably one could even do that via git lowlevel stuff
Nov 23 15:44:29 <spaetz_> Weiss: 1st provides you with the current HAS
Nov 23 15:44:33 <spaetz_> +HASH
Nov 23 15:44:47 <spaetz_> 2nd would provide you with a monotonous increasing revision number
Nov 23 15:45:23 <mrmoku> spaetz_: problem is that won't work with http only repos :|
Nov 23 15:45:27 <spaetz_> that is valid only for the queried repo, of course. This one could be used to create consistent versioning info for packages even when the packages are built on different boxes
Nov 23 15:45:58 <Weiss> spaetz_: but Git doesn't work with monotonic increasing numbers anyway.. how would you get one?
Nov 23 15:46:55 <mrmoku> Weiss: via git-revlist | wc -l :P
Nov 23 15:47:20 <mrmoku> Weiss: similiar to what git describe does
Nov 23 15:47:34 <mrmoku> just count commits from last tag
Nov 23 15:48:17 <mrmoku> spaetz_: git describe-remote is what we need - on could use that directly as PV ;)
Nov 23 15:48:18 <Weiss> ah.. cunning
Nov 23 15:49:18 <Weiss> is git ls-remote not satisfactory for doing AUTOREV though, in preference to cloning the whole thing?
Nov 23 15:50:52 <Weiss> also, can't OE use a shallow clone or something?
Nov 23 15:52:25 <spaetz_> mrmoku: ooh, git-describe. Nifty
Nov 23 15:52:34 <spaetz_> yes that could be used as PV
Nov 23 15:52:53 <spaetz_> git isn't as stupid as I thought :)
Nov 23 15:53:12 <mrmoku> :)
Nov 23 15:53:58 <Weiss> dare I ask what the cause of all the "politics" is?
Nov 23 15:56:29 <Weiss> (I've had my head buried in a text editor this weekend)
Nov 23 15:57:53 <mrmoku> Weiss: the need of one part of the OE community to deal with packages built from git - partly autoreved partly not and to have upgradable package names for those
Nov 23 15:58:25 <mrmoku> and the other part of the OE community that is not useing autoreved packages and refusing to get 'disturbed' :P
Nov 23 15:58:42 <Weiss> ah, I see
Nov 23 15:59:15 <Weiss> but at least there exist technical solutions to avoid killing Git servers?
Nov 23 15:59:24 <Weiss> though I agree that Git killing servers is entirely Git's problem :S
Nov 23 16:00:12 <mrmoku> :)
Nov 23 16:01:16 <mindKMST> Anybody else have a handful of text messages from "50" with a body of "Missing content"?
Nov 23 16:01:29 <Weiss> to run a server with a kernel repository, you either have to limit to a small number of connections or have an insane amount of memory :(
Nov 23 16:32:22 <playya_> result of my nightly build: http://pastebin.com/f28e4f8fd
Nov 23 16:34:49 <Heinervdm> playya_: nothing unusal
Nov 23 16:35:14 <playya_> ok. everything fixed?
Nov 23 16:45:05 <spaetz_> dos1: just checked framworkd source, otimed doesn't use fsodeviced to set time.
Nov 23 16:45:16 <spaetz_> it uses libc's settimeofday directly
Nov 23 16:45:22 <spaetz_> but that should still work
Nov 23 16:45:23 <dos1> strange
Nov 23 16:45:47 <spaetz_> however in order to save the time across reboots yo u need to sync that with the hw clock, I think
Nov 23 16:45:58 <spaetz_> which is what hwclocl usually does on poweroff
Nov 23 16:46:11 <spaetz_> hwclock
Nov 23 16:46:22 <spaetz_> sorry for my typing skills :)
Nov 23 17:01:12 <TAsn> mrmoku|away, wth? <CIA-86> SHR: mok libphone-ui-shr * r72e2e23c1d6e /src/view/ (message-delete-view.c message-list-view.c): fix the last commit and write one-hundred times
Nov 23 17:07:44 <TAsn> dos1, I'm finishing shr-wizard as we speak :P
Nov 23 17:11:52 <dos1> ;)
Nov 23 17:11:59 <dos1> TAsn: did you check if keyboard is available?
Nov 23 17:13:10 <TAsn> haven't got to this stage yet.
Nov 23 17:13:18 <TAsn> though I think there's no reason why it wouldn't be.
Nov 23 17:19:12 <dos1> TAsn: keyboard is provided by illume module
Nov 23 17:20:01 <dos1> which isn't loaded before selecting e profile AFAIK
Nov 23 17:20:15 <soltys> ;)
Nov 23 17:20:15 <TAsn> dos1, are you sure it's not loaded yet?
Nov 23 17:20:40 <dos1> i'm not sure :P
Nov 23 17:20:40 <TAsn> will test soon.
Nov 23 17:20:48 <TAsn> I think you are completely wrong :)
Nov 23 17:20:50 <TAsn> sec though.
Nov 23 17:21:47 <dos1> TAsn: i'm just guessing
Nov 23 17:21:51 <dos1> ;)
Nov 23 17:22:52 <dos1> TAsn: well, even if it's not loaded - maybe loading it manually from wizard page will be possible ;)
Nov 23 17:48:29 <CIA-86> SHR: 03seba.dos1 07shr-wizard * r0ead8e27caa7 10/python/shr-wizard: python: don't switch into next page when old one reported error on saving its state
Nov 23 18:05:57 <mrmoku> TAsn: :P
Nov 23 18:06:10 <mrmoku> TAsn: how was your test?
Nov 23 18:06:29 <TAsn> I don't think I was ready enough to judge for real :P
Nov 23 18:06:40 <TAsn> though I think, probably 95+
Nov 23 18:06:42 <TAsn> :P
Nov 23 18:06:49 <TAsn> (went good)
Nov 23 18:06:58 <[Rui]> TAsn: grats!
Nov 23 18:07:05 <mrmoku> :)
Nov 23 18:07:06 <TAsn> [Rui], hey. :)
Nov 23 18:07:15 <[Rui]> hey!
Nov 23 18:07:19 <[Rui]> TAsn: what was it of?
Nov 23 18:07:22 <TAsn> as promised, [Rui], I'll add your code to libphone-ui-shr hopefully tonight :)
Nov 23 18:07:30 <TAsn> [Rui], database system concepts
Nov 23 18:07:47 <[Rui]> TAsn: I don't know if it's very suitable yet
Nov 23 18:07:58 <TAsn> [Rui], why not?
Nov 23 18:07:59 <[Rui]> TAsn: ah cool
Nov 23 18:08:05 <TAsn> (worst case you'll be able to add more/remove from it)
Nov 23 18:08:18 <TAsn> but ok, I'll wait a day
Nov 23 18:08:27 * [Rui] shrugs... I don't know...
Nov 23 18:08:32 <TAsn> I'll "add" shrstoday first :P
Nov 23 18:08:41 * TAsn is waiting for slyon.
Nov 23 18:08:50 <[Rui]> I need to finish building the tree to test how it looks on the screen
Nov 23 18:13:07 <[Rui]> 220 more tasks to go... gah!
Nov 23 18:13:11 <[Rui]> policykit is borked
Nov 23 18:13:43 <TAsn> :)
Nov 23 18:16:51 <[Rui]> and tmp/ is occupying so much space...
Nov 23 18:17:40 <[Rui]> 11gb
Nov 23 18:19:32 <spaetz> hehe, i wonder what all git downloads use
Nov 23 18:20:42 <[Rui]> spaetz: what occupies the most tmp/work/
Nov 23 18:22:48 <CIA-86> SHR: 03seba.dos1 07shr-settings * r335beaa2bae5 10/shr_settings_modules/shr_gprs.py: [gprs] little changes in layout
Nov 23 18:24:53 <mrmoku> dos1: what is the easiest way to fake a reaalllly looooong message? :P
Nov 23 18:25:04 <dos1> mrmoku: cat on keyboard?
Nov 23 18:25:05 <[Rui]> well, I've added 5GB more
Nov 23 18:25:07 <dos1> ;D
Nov 23 18:25:11 <mrmoku> dos1: :P
Nov 23 18:25:20 <TAsn> mrmoku, you know you can use copy/paste, right?
Nov 23 18:25:26 <mrmoku> dos1: I'm fixing scrolling for long messages.... and have to test
Nov 23 18:25:28 <[Rui]> mrmoku: perl -e 'print "a" x 1024;' will do the trick?
Nov 23 18:25:37 <TAsn> mrmoku, btw, do you also experience the each word on new line bug described in trac?
Nov 23 18:25:42 <TAsn> mrmoku, ohh...
Nov 23 18:25:44 <TAsn> mrmoku, easy
Nov 23 18:25:45 <TAsn> ssh.
Nov 23 18:25:48 <mrmoku> [Rui]: question is what is the most elegant way to stuff that into opimd :)
Nov 23 18:25:55 <TAsn> opimd m Add ....
Nov 23 18:25:59 <TAsn> ...
Nov 23 18:26:39 <mrmoku> installing opimd-utils then.... ok
Nov 23 18:26:58 <TAsn> mrmoku, just opimd-utils-cli
Nov 23 18:26:59 <TAsn> nothing more
Nov 23 18:27:05 <mrmoku> yup
Nov 23 18:27:29 <[Rui]> is packagekit only borked for me?
Nov 23 18:27:38 <TAsn> mrmoku, got any idea why @DATADIR@
Nov 23 18:27:42 <TAsn> isn't translated for me?
Nov 23 18:27:50 <TAsn> (in my .h.in file)
Nov 23 18:28:11 <TAsn> anything special I might be missing?
Nov 23 18:28:45 <mrmoku> TAsn: where?
Nov 23 18:28:54 <mrmoku> libphone-ui?
Nov 23 18:28:59 <mrmoku> or libphone-ui-shr?
Nov 23 18:29:18 <mrmoku> and what is the name of the field? Text?
Nov 23 18:29:40 <TAsn> #define WIZARD_PATH "@DATADIR@/shr-wizard/shr-wizard.py"
Nov 23 18:29:44 <TAsn> in shr-wizard
Nov 23 18:29:48 <TAsn> locations.h.in
Nov 23 18:29:51 <TAsn> (not yet pushed though)
Nov 23 18:30:10 <TAsn> anything I might be missing?
Nov 23 18:30:16 <TAsn> it's there in configure.ac (src/locations.h)
Nov 23 18:30:25 <TAsn> (in AC_OUTPUT)
Nov 23 18:30:55 <mrmoku> AC_SUBST(DATADIR, $datadir)
Nov 23 18:30:56 <mrmoku> ?
Nov 23 18:31:34 <TAsn> fsf.
Nov 23 18:31:35 <TAsn> ffs.
Nov 23 18:31:36 <TAsn> thanks.
Nov 23 18:31:42 <TAsn> forgot that.
Nov 23 18:32:00 <mrmoku> :)
Nov 23 18:32:09 <TAsn> thanks. :P
Nov 23 18:32:11 <mrmoku> TAsn: now tell me... field name is Text? (for opimd-utils-cli)
Nov 23 18:32:17 <mrmoku> or Content?
Nov 23 18:32:24 <TAsn> mrmoku, just query 
Nov 23 18:32:28 <mrmoku> :P
Nov 23 18:32:29 <mrmoku> ok
Nov 23 18:32:35 <TAsn> opim-cli m query 
Nov 23 18:32:40 <TAsn> will show you all you need :)
Nov 23 18:32:52 <TAsn> btw, gj for fixing this :P
Nov 23 18:32:58 <TAsn> don't forget to close the bug when you are done
Nov 23 18:33:01 <mrmoku> Content :)
Nov 23 18:33:13 <TAsn> :P
Nov 23 18:33:18 <mrmoku> sure :)
Nov 23 18:33:26 <TAsn> I can't believe I'm working so hard (not really) for a one time app (shr-wizard)
Nov 23 18:33:26 <TAsn> :P
Nov 23 18:33:28 <mrmoku> TAsn: already fixed the damn reload on delte
Nov 23 18:33:36 <TAsn> :)
Nov 23 18:33:44 <TAsn> should probably not do a full reload
Nov 23 18:33:48 <TAsn> but only remove the correct line
Nov 23 18:34:07 <BluesLee> mrmoku: i cant delete sms and they arrive several times
Nov 23 18:34:37 <TAsn> BluesLee, arrive several times = frameworkd (or opimd) or gsm network bug :)
Nov 23 18:34:47 <TAsn> mostly likely one of the two former
Nov 23 18:35:15 <BluesLee> okay
Nov 23 18:38:54 <TAsn> ok, mrmoku I got a hunch, let's hope it'll work :P
Nov 23 18:39:29 <TAsn> mrmoku, #730, got a clue?
Nov 23 18:39:58 <mrmoku> TAsn: yeah, will fix that too
Nov 23 18:40:05 <TAsn> cool :P
Nov 23 18:42:33 <[Rui]> is there a way to delay building a recipe until it's unavoidable?
Nov 23 18:43:44 <spaetz> more context?
Nov 23 18:43:53 <[Rui]> TAsn: i got a clue
Nov 23 18:44:30 <TAsn> [Rui], no. ;|
Nov 23 18:44:41 <[Rui]> TAsn: where's the code?
Nov 23 18:44:48 <TAsn> mrmoku, done with shr-wizard ;) (kinda)
Nov 23 18:45:01 <TAsn> apparently, the wizard is above everything
Nov 23 18:45:14 <TAsn> so it won't show dos's app
Nov 23 18:45:17 <[Rui]> there's a problem with either elm_entry_line_wrap_set and/or elm_entry_single_line_set
Nov 23 18:45:23 <CIA-86> SHR: 03tom 07shr-wizard * rcd416e31e74f 10/ (4 files in 2 dirs): added shr-wizard.py to /usr/share/shr-wizard
Nov 23 18:45:24 <CIA-86> SHR: 03tom 07shr-wizard * rb15c848a492d 10/ (e_mod_main.h src/src): must have been drunk when I put that .h file there, moved it to src dir
Nov 23 18:45:24 <CIA-86> SHR: 03tom 07shr-wizard * rd05212ff33d8 10/src/ (Makefile.am page_300.c page_900.c): made the page to load almost completely last
Nov 23 18:45:25 <CIA-86> SHR: 03tom 07shr-wizard * r02528c3f615a 10/ (e_wizard.h src/e_mod_main.h src/e_wizard.h src/src): moved the second .h file to src and correct the idiotic rename
Nov 23 18:45:30 <[Rui]> also horizontal weight and alignment may help
Nov 23 18:45:32 <CIA-86> SHR: 03tom 07shr-wizard * r02be693e7c73 10/ (4 files in 2 dirs): fixed the configure.ac and Makefile.am to compile Wrote the relevant part in page_900.c to run the wizard
Nov 23 18:45:33 <CIA-86> SHR: 03tom 07shr-wizard * re0bd878d9044 10/python/shr-wizard.py: Merge branch 'master' of git+ssh://git.shr-project.org/shr-wizard
Nov 23 18:45:36 <CIA-86> SHR: 03tom 07shr-wizard * rcbdf8dbdc926 10/ (configure.ac src/locations.h.in): added the missing AC_SUBST
Nov 23 18:45:38 <TAsn> so I just made it pop at the first second illume launches, from the e wizard 
Nov 23 18:45:39 <CIA-86> SHR: 03tom 07shr-wizard * ra6d94c606eec 10/src/Makefile.am: fixed a missing part in the release hack
Nov 23 18:45:40 <TAsn> so it's ok.
Nov 23 18:45:48 <TAsn> and works only on first boot
Nov 23 18:45:51 <TAsn> and works nicely :)
Nov 23 18:46:15 <TAsn> when we'll have time we should probably write regular e-wizard pages
Nov 23 18:46:29 <TAsn> that are embedded there.
Nov 23 18:46:39 <TAsn> dos1, it doesn't go full screen though :P
Nov 23 18:46:50 <TAsn> mrmoku, sec, I'll mail you a recipe
Nov 23 18:47:16 <dos1> TAsn: well, there is no window manager running on that time...
Nov 23 18:47:28 <TAsn> dos1, I know.
Nov 23 18:47:32 <TAsn> I'm just saying.
Nov 23 18:47:37 <dos1> TAsn: i almost fixed sizing and aligning issues
Nov 23 18:47:38 <TAsn> well, non full screen is also ok.
Nov 23 18:48:12 <TAsn> what do I need to do to make SRCPV  work?
Nov 23 18:48:33 <mrmoku> TAsn: remove BB_GIT_CLONE_FOR_SRCREV from local.conf
Nov 23 18:49:00 <dos1> TAsn: and keyboard works?
Nov 23 18:49:07 <TAsn> dos1, as I said
Nov 23 18:49:12 <TAsn> it only pops when illume is loaded
Nov 23 18:49:26 <TAsn> (that's what I changed it to, as there was no other choice)
Nov 23 18:49:30 <dos1> yup
Nov 23 18:49:32 <TAsn> so, of course :)
Nov 23 18:49:42 <dos1> so why isn't is full screen?
Nov 23 18:49:45 <TAsn> mrmoku, should I update OE fisrt?
Nov 23 18:49:53 <TAsn> dos1, because it's opened before illume is loaded
Nov 23 18:50:00 <dos1> oh
Nov 23 18:50:03 <TAsn> opens when only X is there.
Nov 23 18:50:32 <TAsn> mrmoku, I'm talking about shr-wizard btw, no need to ad it nowhere?
Nov 23 18:50:44 <TAsn> probably autorev or something :)
Nov 23 18:51:40 <TAsn> mrmoku, ok, I'm sending you the recipe I made, you'll probably have to refine it a bit ;)
Nov 23 18:52:15 <TAsn> sent.
Nov 23 18:52:49 <mrmoku> dos1: any progress on the signals?
Nov 23 18:52:54 <CIA-86> SHR: 03seba.dos1 07shr-wizard * r6aadc157a55b 10/python/shr-wizard: python: little redesign, all aligning and spacing issues should be resolved from now
Nov 23 18:52:55 <CIA-86> SHR: 03seba.dos1 07shr-wizard * r6a2976e82d8d 10/ (13 files in 3 dirs): Merge branch 'master' of git+ssh://git@git.shr-project.org/shr-wizard
Nov 23 18:53:15 <TAsn> dos1, sent you my package.
Nov 23 18:53:25 <TAsn> dos1, give it a go. 
Nov 23 18:53:27 <TAsn> if you want.
Nov 23 18:54:12 <TAsn> mrmoku, never tested it though (the ticket) just tested it here with a bit different stuff (SRC_URI + S) and with skip deps
Nov 23 18:54:12 <mrmoku> hmm... I'm obviously too stupid to write edje :P
Nov 23 18:55:42 <mrmoku> TAsn: hmm
Nov 23 18:56:24 <TAsn> dos1, it's decent enough though.
Nov 23 18:57:05 <TAsn> I might even add a page that says "SHR wizard will be launched in a moment + explanation" to the e-wizard module.
Nov 23 19:10:24 <TAsn> btw, shr-wizard: not my prettiest code ever, but works. :P
Nov 23 19:10:41 <TAsn> dos1, don't forget to add the "advanced" page.
Nov 23 19:11:02 <dos1> TAsn: and what do you want in "advanced" page?
Nov 23 19:11:13 <TAsn> opimd backends, duh.
Nov 23 19:11:33 <TAsn> and I alsa want maybe the first page to consist only with text
Nov 23 19:11:51 <TAsn> saying that some of the changes (and explain which) will only work after restart
Nov 23 19:12:02 <TAsn> and that everything can be changed by using the shr-settings app
Nov 23 19:12:06 <TAsn> and etc etc.
Nov 23 19:12:23 * TAsn is going to play a bit of COD4 ;P
Nov 23 19:13:47 <mrmoku> TAsn: fix alsa first ;)
Nov 23 19:14:10 <TAsn> are you talking about volume bars?
Nov 23 19:14:28 <mrmoku> :)
Nov 23 19:14:38 <mrmoku> otherwise I'm used to commit my state file :P
Nov 23 19:14:44 <mrmoku> s/used/forced/
Nov 23 19:14:44 <apt> mrmoku meant: otherwise I'm forced to commit my state file :P
Nov 23 19:15:02 <mrmoku> and dos1 won't like that ;)
Nov 23 19:15:04 <TAsn> :P
Nov 23 19:15:12 <TAsn> oh, saving those
Nov 23 19:15:20 <mrmoku> TAsn: btw. seriously speaking... did you read mail about that?
Nov 23 19:15:38 <TAsn> mrmoku, about what? which mail (what was thes ubject)
Nov 23 19:15:44 <mrmoku> moment
Nov 23 19:15:48 <TAsn> s/s / s/
Nov 23 19:15:49 <TAsn> :)
Nov 23 19:15:50 <apt> TAsn meant: mrmoku, about what? which mail (what wa sthes ubject)
Nov 23 19:15:56 <TAsn> oh shit
Nov 23 19:16:03 <TAsn> I missed the was
Nov 23 19:16:12 <mrmoku> [Shr-User] New SHR-U: audio on calls not reliable
Nov 23 19:16:21 <mrmoku> the last one
Nov 23 19:16:24 <mrmoku> David Garabana
Nov 23 19:16:26 <TAsn> sec.
Nov 23 19:16:35 <TAsn> I read it, but I don't remember
Nov 23 19:16:36 <TAsn> sec
Nov 23 19:16:43 <mrmoku> And can't the same old alsa.state defaults be applied?
Nov 23 19:16:44 <mrmoku> ;)
Nov 23 19:17:19 <TAsn> :)
Nov 23 19:17:32 <TAsn> mrmoku, ask DocScrutinizer if he has anything to say
Nov 23 19:17:36 <TAsn> I don't really care :)
Nov 23 19:18:18 <mrmoku> nah, will just install my state file myself
Nov 23 19:18:24 <mrmoku> until enough people whine :P
Nov 23 19:18:50 <fredrin> :)
Nov 23 19:19:43 <mrmoku> man... as long as I'm positioning widgets absolute all is fine
Nov 23 19:19:58 <mrmoku> as soon as I start to use relN.to_x/y
Nov 23 19:20:00 <mrmoku> I'm lost :|
Nov 23 19:22:25 <TAsn> I'm fixing saving of state :P
Nov 23 19:22:44 <TAsn> though please add the alsa polling to glib!
Nov 23 19:26:20 <mrmoku> TAsn: :) ok
Nov 23 19:29:17 <JaMa|Wrk> mrmoku: can I go to play COD6 for a while please? :)
Nov 23 19:29:52 <JaMa|Wrk> mrmoku: I'll fix gpe-icons and split navit/navit-icons if you promise that I can go after that..
Nov 23 19:30:03 <dos1> why everyone is so crazy on COD for some time? :P
Nov 23 19:34:14 <mrmoku> JaMa: permission granted :P
Nov 23 19:34:32 <mrmoku> dos1: strange thing indeed :)
Nov 23 19:36:45 <spaetz> code! not cod. lazy guys ;-)
Nov 23 19:37:08 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * r66e4f9795e24 10cornucopia/fsodeviced/ (8 files in 5 dirs): fsodeviced: split canberra player out of alsa_audio and prepare for pluggable players
Nov 23 19:37:29 <max_posedon> hi! I want .31)
Nov 23 19:40:45 <mrmoku> max_posedon: me too ;)
Nov 23 19:40:48 <TAsn> mickey|sofa, suggestion: what do you think about adding an fsodeviced dbus method "SaveScenario" that'll save the changes in current scenario? (i.e, if gsmhandset is loaded and someone touched alsa keys, it'll save the new state to gsmhandset)
Nov 23 19:41:00 <TAsn> mrmoku, I finished writing the script :P
Nov 23 19:41:21 <TAsn> now I just need to call it from source
Nov 23 19:41:38 <mrmoku> TAsn: btw. saving is only one part... min/max in sane ranges the other ;)
Nov 23 19:41:49 <mrmoku> probably even more important :)
Nov 23 19:42:13 <mickey|sofa> TAsn: sounds reasonable. I'm currently busy with refactoring alsa_audio (the playing part), will look at that afterwards (not today though)
Nov 23 19:42:17 <TAsn> mrmoku, I know how to do that (min/max) already have everything ready in my head.
Nov 23 19:42:27 <TAsn> mickey|sofa, that's fine with me :P thanks.
Nov 23 19:42:47 <mrmoku> TAsn: 'in your head' is something my neo can't make use of :P
Nov 23 19:42:56 <mickey|sofa> install telepathy ;)
Nov 23 19:43:03 <TAsn> mrmoku, nah, I have most of it implemented and debugged (in my head)
Nov 23 19:43:09 <mrmoku> mickey|sofa: do we have that in our feed? :P
Nov 23 19:43:11 <TAsn> only a matter of copying it to vim
Nov 23 19:43:26 <mrmoku> TAsn: then press copy please :D
Nov 23 19:43:47 <TAsn> paste...
Nov 23 19:45:13 <mrmoku> dos1: looks like opimd-cli does not like adding messages with ) in it ;)
Nov 23 19:45:33 <mrmoku> (and no I don't want you to fix it :)
Nov 23 19:53:50 <JaMa> mrmoku: please ack my last 2 cookies.. (only for SHR now..)
Nov 23 19:54:26 <JaMa> mrmoku: i mean informal ack is enough :)
Nov 23 19:54:41 <JaMa> mrmoku: just say that you don't see anything bad in it
Nov 23 20:00:20 <spaetz_> mickey|sofa: is libcanberra responsible for /dev/rtc blocking?
Nov 23 20:01:37 <mickey|sofa> no
Nov 23 20:01:59 <mickey|sofa> commented on the bug entry
Nov 23 20:02:57 <spaetz_> ahh, haven't checked mail yet. thanks, will look
Nov 23 20:05:47 <spaetz_> mmh, I have no clue what atd-over-fso does, but it makesthat the fr wakes up n an alarm... also hwclock needs access to /dev/rtc and fails currently to set the system time
Nov 23 20:06:15 <TAsn> lol, so hackish :P
Nov 23 20:06:18 <spaetz_> or read (hwclock fails on everything)
Nov 23 20:06:29 <TAsn> (until mickey gets his fsodeviced function ready)
Nov 23 20:07:44 <spaetz_> TAsn: do you think it's smart to have fsodeviced basically block /dev/rtc? what  else might be needing it ?
Nov 23 20:08:21 <TAsn> spaetz_, I already told you what I think
Nov 23 20:08:42 <spaetz_> mmh, right
Nov 23 20:08:48 <TAsn> /dev/rtc0 should not be blocked because we might want to run moko unaware apps 
Nov 23 20:08:49 <TAsn> :)
Nov 23 20:09:05 <spaetz_> i remember now :-)
Nov 23 20:09:37 <mrmoku> JaMa: first one looks ok scripting wise
Nov 23 20:14:53 <TAsn> mrmoku, committed, but not tested
Nov 23 20:14:55 <TAsn> gtg :P
Nov 23 20:14:57 <TAsn> should work
Nov 23 20:15:01 <TAsn> give it a go, please.
Nov 23 20:15:02 <TAsn> :)
Nov 23 20:15:03 <CIA-86> SHR: 03tom 07libphone-ui * r474caa5f9cbf 10/src/ (phoneui-utils-sound.c phoneui-utils-sound.h): should now save changes to volume
Nov 23 20:15:13 <CIA-86> SHR: 03tom 07libphone-ui * r3a6d9493117b 10/data/ (Makefile.am modify_state.sh): added a nice but hackish script to save state files until FSO will add a function
Nov 23 20:15:43 <mrmoku> JaMa: the second one is quite complicated :P
Nov 23 20:15:50 <mrmoku> so far looks fine too though
Nov 23 20:16:02 <TAsn> mrmoku, please let me know if it works so I'll fix it when I'm back
Nov 23 20:16:02 <TAsn> ciao.
Nov 23 20:17:23 <mrmoku> TAsn: yep, first I have to win my edje fight though :|
Nov 23 20:17:33 <TAsn> :)
Nov 23 20:19:36 <zoff99> hi, anybody have any help on my "makekeys" issue when building libx11?
Nov 23 20:19:42 <Weiss> who manages planet.openmoko.org?
Nov 23 20:22:04 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * re560057f7947 10cornucopia/libfsoframework/ (4 files in 2 dirs): libfsoframework: use compile-time path to look for modules; this fixes breakage introduced with bin -> sbin change
Nov 23 20:22:05 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * r9da04ead7958 10cornucopia/ (3 files in 3 dirs): fsodeviced: audio: load player plugin based on player_type setting in config
Nov 23 20:24:27 <JaMa> Weiss: does "pixman-supports-overlapped-blt" say something to you? http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=bdc1442952b8ab1bec976d6aae7afc5a36365495 just curious if its worth trying to use same patch for our xserver.. pixman will be updated with last rebuild..
Nov 23 20:27:10 <fredrin> gah, cant write sms's in shr-u :( 
Nov 23 20:28:23 <Hardy> me too ^^
Nov 23 20:28:42 <Hardy> and wifi hardware dont start
Nov 23 20:28:56 <Hardy> just a advice ^^
Nov 23 20:29:10 <spaetz_> Hardy: turn it on it shr-settings. Does this work?
Nov 23 20:29:20 <Hardy> nope
Nov 23 20:30:11 <Weiss> JaMa: not something I've heard of..
Nov 23 20:32:34 <fredrin> how's the wifi with kernel .31? 
Nov 23 20:35:16 <Hardy> sorry i turnt off anythink.. cause... Its chilling time wohoo ^^
Nov 23 20:35:26 <Hardy> everything 
Nov 23 20:35:53 <JaMa> Weiss: ok.. will try how new pixman works without it and then if the patch apply cleanly  apply that one too
Nov 23 20:41:36 <PaulFertser> fredrin: same shit i think
Nov 23 20:45:02 <spaetz_> dos1: how do I disabl a widget?
Nov 23 20:45:05 <spaetz_> in pyelm?
Nov 23 20:45:18 <spaetz_> I want to show the WiFi toggle initially disabled
Nov 23 20:45:27 <spaetz_> rather than having the layout jump around
Nov 23 20:46:41 <dos1> spaetz_: widget.disabled_set(True)?
Nov 23 20:47:19 <spaetz_> ok, sounds good. thanks
Nov 23 20:47:22 <spaetz_> yep
Nov 23 20:51:10 <CIA-86> SHR: 03mok 07libphone-ui-shr * r9a385c4d4dac 10/ (data/default.edc src/view/message-show-view.c): message-show-view: put the content into a scroller (fixes #567)
Nov 23 20:53:37 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * r6aaee9deea16 10cornucopia/fsodeviced/ (11 files in 8 dirs): fsodeviced: refactor PlayingSound into library, add missing GLIB_CFLAGS and GLIB_LIBS in various Makefile.am
Nov 23 20:55:43 <[Rui]> today I've been trying to use an updated shr-u
Nov 23 20:55:44 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * r1e4d02d17bd3 10cornucopia/fsodeviced/vapi/config.vapi: fsodeviced: add config.vapi
Nov 23 20:55:59 <[Rui]> I was receiving calls but only as if someone was just letting it ring once
Nov 23 20:56:12 <dos1> [Rui]: yup. but only when resuming from suspend
Nov 23 20:56:28 <dos1> [Rui]: i'll try to debug it soon
Nov 23 20:56:41 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * r9a4607d943d0 10cornucopia/fsodeviced/vapi/config.vapi: 
Nov 23 20:56:41 <CIA-86> freesmartphone.org: Revert "fsodeviced: add config.vapi"
Nov 23 20:56:41 <CIA-86> freesmartphone.org: This reverts commit 1e4d02d17bd3900cd0061c958cd8e7e42a18fe49.
Nov 23 20:56:42 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * rac62aa5921e1 10cornucopia/libfsoframework/vapi/config.vapi: libfsoframework: add config.vapi
Nov 23 21:04:16 <[Rui]> dos1: ok, thanks! :)
Nov 23 21:05:14 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * r78800ac3d41b 10cornucopia/fsodeviced/src/plugins/alsa_audio/plugin.vala: fsodeviced: alsa_audio: fix crash when no scenarious can be found
Nov 23 21:09:41 <JaMa> blindcoder: recipes added to feed, thanks for your contribution!
Nov 23 21:10:59 <spaetz_> dos1: actually toggle.disabled_set(True) seems to work, but it is still enabled and can be switched...
Nov 23 21:11:47 <mrmoku> spaetz_: you have an updated shr-u?
Nov 23 21:12:46 <dos1> spaetz_: only with gry theme - it doesn't have support for disabled elements yet
Nov 23 21:12:50 <spaetz_> yes
Nov 23 21:12:54 <dos1> spaetz_: try with default on niebiee, it should work
Nov 23 21:13:34 <[Rui]> any hope about PackageKit? It's breaking the tree!
Nov 23 21:13:53 <mrmoku> spaetz_: does writing sms work for you?
Nov 23 21:16:31 * Weiss growls at X documentation which doesn't say which header all the different declarations are in
Nov 23 21:21:35 <spaetz_> dos1: ahh ok. good to know. Ißll try with another theme then
Nov 23 21:21:52 <spaetz_> mrmoku: havenßt tried to send sms yet, let me check
Nov 23 21:22:41 <dos1> [Rui]: why?
Nov 23 21:23:00 <spaetz_> mrmoku: doh, messages app seems to crash as soon as I click "New message"
Nov 23 21:23:08 <mrmoku> yup
Nov 23 21:23:09 <mrmoku> :(
Nov 23 21:23:27 <JaMa> mrmoku: can you run task-shr-feed build?
Nov 23 21:23:55 <mrmoku> JaMa: ok
Nov 23 21:24:03 <Heinervdm> spaetz_: and no message on crash...
Nov 23 21:24:55 <Hardy> yeah
Nov 23 21:25:37 <spaetz_> Heinervdm: nope
Nov 23 21:25:50 <spaetz_> strace doesn't look useful either
Nov 23 21:26:22 <[Rui]> dos1: I can't build anything because it breaks on something apparently related to gettext
Nov 23 21:26:34 <spaetz_> ok, won't do disabled widgets as long as our default theme doesn't support them...
Nov 23 21:26:38 <dos1> strange, it works here
Nov 23 21:26:59 <[Rui]> /opt/openmoko/shr-unstable/tmp/work/armv4t-oe-linux-gnueabi/policykit-0.9-r5/PolicyKit-0.9/configure: line 16499: syntax error near unexpected token `0.36.0'
Nov 23 21:26:59 <[Rui]> /opt/openmoko/shr-unstable/tmp/work/armv4t-oe-linux-gnueabi/policykit-0.9-r5/PolicyKit-0.9/configure: line 16499: `IT_PROG_INTLTOOL(0.36.0)'
Nov 23 21:27:40 <dos1> [Rui]: PolicyKit != PackageKit
Nov 23 21:27:48 <dos1> why for you need PolicyKit?
Nov 23 21:29:12 <spaetz_> especially as long as we run as root :)
Nov 23 21:33:01 <spaetz_> mrmoku: any idea what we are going to do with /dev/rtc?
Nov 23 21:34:03 <spaetz_> mickeyl commented in the fso trac ticket that fsodeviced will basically need to open /dev/rtc0 (blocking it for all others)
Nov 23 21:34:29 <spaetz_> so atd-over-fso and hwclock and whatever wants o sue /dev/rtc0 will error out.
Nov 23 21:34:49 <spaetz_> I have no idea what we can do to improve that situation
Nov 23 21:35:29 <spaetz_> next to rewriting atd-over-fso to make use of fsodeviced API (with whatever it needs to do...)
Nov 23 21:35:37 <mrmoku> spaetz_: no idea
Nov 23 21:35:59 <spaetz_> and I have no clue which other apps might want to use it...
Nov 23 21:37:31 <mrmoku> and I have no clue why the damn thing segfaults on new sms now :(
Nov 23 21:38:48 <spaetz_> sigh. receiving sms used to work just nicely 2 days ago,,,
Nov 23 21:42:24 <[Rui]> dos1: yeah, I swapped the name
Nov 23 21:42:42 <[Rui]> dos1: how the hell should I know :) I just tried bitbake -c build elmdentica :)
Nov 23 21:43:08 <[Rui]> I suppose something it depends requires on sth it depends on sth it depends...
Nov 23 21:43:59 <Heinervdm> [Rui]: create a depence.dot and check
Nov 23 21:44:36 <[Rui]> Heinervdm: erms... sorry, a what?
Nov 23 21:45:52 <Heinervdm> [Rui]: bitbake -g elmdentica
Nov 23 21:45:53 <spaetz_> [Rui]: bitbake -g shr-lite-image
Nov 23 21:45:59 <spaetz_> or whatever you want to build
Nov 23 21:46:02 <[Rui]> ok
Nov 23 21:46:06 <spaetz_> and then:
Nov 23 21:46:48 <spaetz_> grep '> "packagenamewhateverhere"' depends.dot
Nov 23 21:47:05 <spaetz_> which will show you all packages that DEPEND on packagenamewhateverhere
Nov 23 21:47:34 <[Rui]> oh...
Nov 23 21:49:06 <[Rui]> gconf, for instance
Nov 23 21:49:23 * mrmoku is going to sleep about it
Nov 23 21:49:26 <mrmoku> JaMa: feed is building
Nov 23 21:49:43 <mrmoku> forgot to add && bitbake package-index and sync though
Nov 23 21:49:59 <mrmoku> maybe dos1 can do that when he's still around when it finished
Nov 23 21:50:34 <mrmoku> gnight all
Nov 23 21:50:44 <qkall> hiya i'm having an issue installing shr to my moko... i'm a total newb... i am trying to use neo tool but when i boot the phone up it has a string of errors
Nov 23 21:50:46 <[Rui]> mrmoku|away: good night
Nov 23 21:51:24 <[Rui]> qkall: may I suggest you get an µ-sdhc card ?
Nov 23 21:51:53 <qkall> come again? i have a micro sdhc...
Nov 23 21:51:59 <qkall> several actually...
Nov 23 21:52:50 <[Rui]> qkall: good! can we move the talk to #openmoko so we don't make much noice about 1st steps in here?
Nov 23 21:53:29 <qkall> okidoki
Nov 23 21:55:27 <JaMa> mrmoku|away: nite and thanks
Nov 23 21:58:11 <raph_ael> hi
Nov 23 22:00:15 <raph_ael> just wanted to report some bugs to the last shr-unstable
Nov 23 22:03:32 <spaetz_> I'm off for today too.
Nov 23 22:03:45 <spaetz_> raph_ael: do so here or over at our trac...
Nov 23 22:04:15 <raph_ael> well : wireless says it's connected, but it's not, and never connects, and power management settings are never saved else than backlight
Nov 23 22:04:26 <raph_ael> spaetz_: ok thanks :)
Nov 23 22:06:44 <spaetz_> raph_ael: nope they are not yet saved. New fsodeviced doesn do that at the moment
Nov 23 22:06:57 <spaetz_> wireless, you mean mokonnect?
Nov 23 22:07:12 <spaetz_> or turning wireless on via shr-settings...?
Nov 23 22:07:39 <raph_ael> mokonnect
Nov 23 22:08:08 <raph_ael> and strangely, sometimes shr-settings says wireless interface is up and mokonnect says it's not
Nov 23 22:09:06 <raph_ael> i think i'll wait a bit till i switch to the new unstable :)
Nov 23 22:10:57 <JaMa> this one is known?
Nov 23 22:10:58 <JaMa>  * Package libelementary-ver-pre-svn-04-0 wants to install file /usr/lib/libelementary-ver-pre-svn-04.so.0
Nov 23 22:11:02 <JaMa>         But that file is already provided by package  * elementary
Nov 23 22:11:04 <JaMa>  * Package libelementary-ver-pre-svn-04-0 wants to install file /usr/lib/libelementary-ver-pre-svn-04.so.0.5.1
Nov 23 22:11:07 <JaMa>         But that file is already provided by package  * elementary
Nov 23 22:12:04 <spaetz_> raph_ael: there have been some changes and mokonnect is not yet adapted, I believe...
Nov 23 22:12:36 <spaetz_> JaMa: heh. Don't think so. Anyway bed time
Nov 23 22:20:24 * Weiss wonders about (say) an SMS application which uses an "old-style" numeric keypad, possibly predictive
Nov 23 22:23:30 <[Rui]> raster: hiya!
Nov 23 22:23:40 <raster> [Rui]: hoi!
Nov 23 22:25:26 <JaMa> spaetzzZ: do I need "elementary"? :)
Nov 23 22:26:08 <spaetzzZ> no clue, i guess so.
Nov 23 22:26:37 <JaMa> spaetzzZ: ok thanks, nite
Nov 23 22:26:38 * spaetzzZ continues to sleep :-)
Nov 23 22:27:00 <raph_ael> spaetzzZ: good night
Nov 23 22:27:11 <spaetzzZ> night
Nov 23 22:27:56 <JaMa> Weiss: :) not sure how usable it would be to touch one button 3 times without "click" feel.. but maybe vibration or something like that can work as click feedback
Nov 23 22:28:07 <JaMa> Weiss: but I'll stay with qwerty
Nov 23 22:28:45 <Weiss> JaMa: I'm just pondering... qwerty seems to be a poor fit for the hardware..
Nov 23 22:29:19 <Weiss> vibration for tap could be nice..
Nov 23 22:29:37 <spaetzzZ> JaMa, vibration click would be nice in our numpads anyway
Nov 23 22:29:46 <spaetzzZ> eg sim  pin
Nov 23 22:30:41 <Hardy> would be realy nice
Nov 23 22:31:16 <JaMa> Weiss: yes.. that's why I plan to take my old sharp spitz with hw qwerty along with neo.. just for cases when I need to send sms :)
Nov 23 22:31:29 <Hardy> loool
Nov 23 22:31:41 <spaetzzZ> Weiss, poor fit i agree, especially in portrait mode
Nov 23 22:32:10 <Hardy> spaetzzZ: wouldnt you sleep? xD
Nov 23 22:32:34 <Weiss> the keyboard is currently the #1 cause of people laughing at my FR..
Nov 23 22:32:38 <Weiss> actually I think it's the only one
Nov 23 22:33:11 <spaetzzZ> Hardy,  yes :-)
Nov 23 22:33:12 <Hardy> Weiss: which keyboard?
Nov 23 22:33:27 <Hardy> spaetzzZ: ^^
Nov 23 22:33:39 <Weiss> Hardy: the default Illume one ("default" or "terminal")
Nov 23 22:34:21 <Hardy> yeah, thats a creapy one ^^
Nov 23 22:34:39 <Hardy> i made myself a german one, works pretty good
Nov 23 22:35:09 * Wonka made a german matchbox-keyboard layout
Nov 23 22:35:31 <Hardy> O_o
Nov 23 22:35:36 <Wonka> and I installed matchbox-keyboard for use with illume in both SHR and debian
Nov 23 22:35:50 <Hardy> Wonka: matchbox-keyboard? 
Nov 23 22:36:01 <Wonka> I wanted the third level (AltGr)
Nov 23 22:36:02 <Hardy> whats a matchbox-keyboard?
Nov 23 22:36:03 <Wonka> Hardy: yes.
Nov 23 22:36:08 <Wonka> moment
Nov 23 22:37:17 <JaMa> Installing elementary (2:0.0.0+svnr43437-r5.4) to root...
Nov 23 22:37:17 <JaMa> Downloading http://jama.home.net/org.openembedded.shr/ipk/armv4t/elementary_0.0.0+svnr43437-r5.4_armv4t.ipk
Nov 23 22:37:20 <JaMa> package elementary suggests installing elementary-tests
Nov 23 22:37:22 <JaMa> Configuring elementary
Nov 23 22:37:25 <JaMa> SHR root@gojama /boot $ opkg files libelementary-ver-pre-svn-04-0
Nov 23 22:37:25 <JaMa> Package libelementary-ver-pre-svn-04-0 (2:0.0.0+svnr43898-r5.4) is installed on root and has the following files:
Nov 23 22:37:29 <JaMa> nothing..
Nov 23 22:37:44 <Wonka> Hardy: http://wiki.openmoko.org/wiki/Switching_Keyboards#Matchbox_keyboard
Nov 23 22:38:36 <JaMa> spaetzzZ: maybe this? http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=51d8c69272483d1749587ba589f038e81718afc3
Nov 23 22:39:04 <JaMa> spaetzzZ: if ${PN} is changed later to libelementary-ver-pre-svn-04-0
Nov 23 22:41:19 <spaetzzZ> mmh, don´t think so. btw does the remooval of elm-themes look riight in that commit?
Nov 23 22:41:28 <Hardy> Wonka: thx, i watching over it
Nov 23 22:42:11 <spaetzzZ> but could be. svn upstream also  often changes those numbers, i beliieve
Nov 23 22:42:12 <JaMa> spaetzzZ: hmm not sure.. I noticed that its not 2 times elementary-tests only after your question :)
Nov 23 22:44:25 <Wonka> Hardy: looks like this: http://chaos.in-kiel.de/~w/openmoko/matchbox-keyboard-de.png
Nov 23 22:44:26 <Hardy> Wonka: ah looks good, cause it dont waste that place like the illume keyboard with this useless dictionary shit 
Nov 23 22:44:50 <Wonka> Hardy: http://chaos.in-kiel.de/~w/openmoko/keyboard.xml
Nov 23 22:45:54 <Hardy> but its not realy fingerfriendly i see
Nov 23 22:46:40 <Wonka> you need pointy fingernails or a stylus, yes.
Nov 23 22:46:49 <Wonka> but it's got all the keys.
Nov 23 22:47:06 <Wonka> and all the Umlauts with AltGr, and stuff.
Nov 23 22:47:46 <Wonka> I also quite like the arrangement of the cursor keys, pgup/pgdn, home/end
Nov 23 22:47:54 <Hardy> true, can u change between other layouts?
Nov 23 22:48:29 <Wonka> only by restarting, I think
Nov 23 22:49:04 <Wonka> iff there's a possibility to change layouts on the fly, I don't know it
Nov 23 22:49:43 <Hardy> hmmh i read of it, i will search for it tomorrow
Nov 23 22:50:29 <Hardy> but now i do what spaetzzZ always wanted to do ^^
Nov 23 22:50:43 <Wonka> aaaand now for something completely different...
Nov 23 22:51:17 <spaetzzZ> hehe, night Hardy 
Nov 23 22:51:34 <spaetzzZ> i am now really off too
Nov 23 22:51:43 <Wonka> current SHR unstable does not build here because http://sources.openembedded.org//matchbox-panel-2_svn.o-hand.com_.repos.matchbox.trunk_2098_.tar.gz 404s
Nov 23 22:52:07 <Hardy> hehe, yeah good nicht spaetzzZ, good night an thanks Wonka
Nov 23 22:52:16 <Hardy> -c +g
Nov 23 22:53:39 <[Rui]> Hardy: you have to not have used matchbox keyboard for a while in order to complain about raster's keyboard
Nov 23 22:53:47 <[Rui]> Hardy: matchbox keyboard fscking sucks
Nov 23 22:54:05 <Wonka> also, http://www.shr-project.org/trac/wiki/Building%20SHR seems to be outdated...
Nov 23 22:55:10 <Wonka> running "git pull" in shr-unstable dir results in an error message that . and none of the parent dirs was a git repo
Nov 23 22:56:04 <Wonka> "make shr-update" in top dir does not know that target...
Nov 23 22:56:10 <Wonka> only "make update" works
Nov 23 22:57:28 <Wonka> by the way, is there anyone maintaining zhone any longer, at least the GPS satellite and GSM base station bar graph stuff?
Nov 23 22:58:18 <mickeyl> Wonka: I'm going to touch zhone again soon, yes
Nov 23 22:58:23 <Wonka> cool
Nov 23 22:58:49 <Wonka> I have done some more patches for the GPS stuff there
Nov 23 22:59:06 <mickeyl> awesome
Nov 23 22:59:33 <Wonka> like adding DGPS status and adding NESW to the satellite graph
Nov 23 23:00:01 <Wonka> (and flipping that one - south was on the top)
Nov 23 23:00:22 <Wonka> need to make a diff and put it somewhere
Nov 23 23:00:27 <mickeyl> yeah, please do that 
Nov 23 23:00:43 <mickeyl> either send to the smartphones-userland or attach to a ticket on trac
Nov 23 23:00:47 <mickeyl> both is fine
Nov 23 23:01:52 <Wonka> SHR trac or which one?
Nov 23 23:02:37 <Wonka> ah, trac.freesmartphone.org I think
Nov 23 23:02:58 <mickeyl> yep
Nov 23 23:21:40 <TAsn> mrmoku|away, just tested it
Nov 23 23:21:42 <TAsn> it works :P
Nov 23 23:21:44 <TAsn> you can commit. :)
Nov 23 23:21:47 <TAsn> *build
Nov 23 23:21:55 <TAsn> (libphone-ui making alsa state permanent)
Nov 23 23:38:29 <[Rui]> TAsn: lucky you, policykit doesn't build here :|
Nov 23 23:38:36 <TAsn> :)
Nov 23 23:40:12 <[Rui]> it seems either the recipe is borked or the source
Nov 23 23:42:45 <Wonka> mickeyl: two tickets created.
Nov 23 23:43:37 <mickeyl> great, thanks a lot
Nov 23 23:43:46 <Wonka> np
Nov 23 23:43:57 <Wonka> too little time to do more :/
Nov 23 23:45:16 <CIA-86> freesmartphone.org: 03mickey 07mickey/experimental * r7a17900ba9dd 10cornucopia/fsodeviced/ (6 files in 5 dirs): fsodeviced: create experimental player_alsa plugin that just delegates playing a sound to aplay
Nov 23 23:46:18 <CIA-86> freesmartphone.org: 03mickey 07cornucopia * r3498c9cc2817 10/libfsoframework/configure.ac: libfsoframework: fix configure.ac output for module dir
Nov 23 23:47:01 <mickeyl> mrmoku|away: spaetzzZ: whenever you're in experimentation mood, please test the new player_alsa plugin
Nov 23 23:47:19 <mickeyl> should get rid of the necessity to nice fsodeviced
Nov 23 23:55:44 <Wonka> good night everyone
Nov 24 00:03:00 <[Rui]> rms@roque:/opt/openmoko/shr-unstable/openembedded/recipes/policykit$ git diff policykit_0.9.bb
Nov 24 00:03:00 <[Rui]> diff --git a/recipes/policykit/policykit_0.9.bb b/recipes/policykit/policykit_0.9.bb
Nov 24 00:03:00 <[Rui]> index 2a31701..7fbd686 100644
Nov 24 00:03:00 <[Rui]> --- a/recipes/policykit/policykit_0.9.bb
Nov 24 00:03:00 <[Rui]> +++ b/recipes/policykit/policykit_0.9.bb
Nov 24 00:03:01 <[Rui]> @@ -1,5 +1,5 @@
Nov 24 00:03:04 <[Rui]>  HOMEPAGE = "http://www.packagekit.org/"
Nov 24 00:03:05 <[Rui]> -DEPENDS = "libpam expat dbus-glib"
Nov 24 00:03:09 <[Rui]> +DEPENDS = "gettext libpam expat dbus-glib"
Nov 24 00:03:11 <[Rui]>  
Nov 24 00:03:13 <[Rui]>  PR = "r5"
Nov 24 00:03:15 <[Rui]>  
Nov 24 00:03:17 <[Rui]> this seems to have helped...
Nov 24 00:03:19 <[Rui]> at least it's progressing
Nov 24 00:06:12 <CIA-86> freesmartphone.org: 03mickey 07cornucopia * rc3db644e2835 10/fsodeviced/src/plugins/player_alsa/plugin.vala: fsodeviced: player_alsa: handle loop and length attributes
Nov 24 00:06:19 <mickey|zzZZzz> n8
Nov 24 00:06:41 <[Rui]> night ye all as well...
Nov 24 00:46:10 <CIA-86> SHR: 03tom 07libphone-ui * r4c6c4fa47f47 10/src/phoneui-utils-sound.c: Added complete support for speaker_min and speaker_max (and microphone_min and microphone_max)
Nov 24 00:46:21 <CIA-86> SHR: 03tom 07libphone-ui * r7dbbf3277e67 10/src/ (phoneui-utils-sound.c phoneui-utils-sound.h): added phoneui_utils_sound_volume_raw_set (also had with with raw_get).
Nov 24 00:46:21 <CIA-86> SHR: 03tom 07libphone-ui * r7aa3b89c6f04 10/src/phoneui-utils-sound.c: added support for infrastructue for support for user defined min and max values for alsa controls
Nov 24 00:47:48 <CIA-86> SHR: 03tom 07libphone-ui * ra3e69f9cfde3 10/data/libphoneui.conf: changed the default config file to start the volume from 90 (better calibration) should maybe make it lower
Nov 24 00:48:58 <TAsn> mrmoku|away, Here ya go, did what I promised, the volume settings are now saved and you can calibrate using speaker_min, speaker_max, microphone_min and microphone_max :)
Nov 24 00:54:04 <TAsn> mrmoku|away, here ya go, build and let me know :P
Nov 24 00:54:10 <CIA-86> SHR: 03tom 07libphone-ui * r5dc3069ae645 10/data/libphoneui.conf: added a bit of documentation to the config file
Nov 24 01:10:20 <DocScrutinizer-8> Wonka: heh, I noticed maemo (N810) and samsung omnia route66 sat pos displays also are mirrored somehow (one of them). Dunno which one is the right one, but obviously this oopsy is a luring one
Nov 24 01:15:08 <CIA-86> freesmartphone.org: 03mickey 07cornucopia * r862097a79578 10/fsodeviced/src/plugins/kernel26_rtc/plugin.vala: 
Nov 24 01:15:08 <CIA-86> freesmartphone.org: fsodeviced: kernel26_rtc: be more cooperative with /dev/rtc0
Nov 24 01:15:08 <CIA-86> freesmartphone.org: This module will now only hold /dev/rtc0 while it is a) doing any operation
Nov 24 01:15:08 <CIA-86> freesmartphone.org: (which is very short), or b) waiting for a pending alarm (in which case
Nov 24 01:15:09 <CIA-86> freesmartphone.org: we do not want someone else to remove or change it behind our back anyways).
Nov 24 01:15:11 <CIA-86> freesmartphone.org: This should improve FSO #492 to a certain extent. Please open another ticket,
Nov 24 01:15:13 <CIA-86> freesmartphone.org: if you are missing something in the RTC DBus API.
**** ENDING LOGGING AT Tue Nov 24 03:00:00 2009