**** BEGIN LOGGING AT Sun Oct 30 02:59:56 2011
Oct 30 08:20:41 <CIA-5> SHR: 03Martin.Jansa 07shr-chroot * r784020ca3ba7 10/ (116 files in 17 dirs): system upgrade
Oct 30 08:39:25 <JaMa> lindi-: bq27000 seems to work fine on .39 [ 3330.465000] bq27000-battery bq27000-battery.0: support ver. 1.2.0 enabled
Oct 30 09:05:37 <mrmoku> GNUtoo: I'm trying to understand the softkey code now
Oct 30 09:21:03 <abmuesal> Hi. freesmartphone.org wiki said, palm pre kernel mainline kernel port is too hard. can some give me a general summary, please? 
Oct 30 10:00:01 <lindi-> JaMa: can you give me the exact config?
Oct 30 10:05:42 <mrmoku> GNUtoo: [   65.791137] et8ek8 3-003e: can't load firmware et8ek8-0002.bin
Oct 30 10:05:58 <mrmoku> GNUtoo: that one is because fsodeviced is not yet started probably?
Oct 30 10:06:11 <mrmoku> at least I can see no firmware request in the fsodeviced log
Oct 30 10:07:49 <mrmoku> TAsn: I'm having fun reading the e17 release thread :-P
Oct 30 10:17:53 <mrmoku> hi GNUtoo
Oct 30 10:19:21 <GNUtoo> hi
Oct 30 10:19:37 <mrmoku> GNUtoo: could you try to find out (in kernel config) why et8ek8 is loaded that early?
Oct 30 10:20:21 <GNUtoo> I think it's rather fsodeviced that doesn't start early
Oct 30 10:20:27 <GNUtoo> how early is it loaded?
Oct 30 10:20:52 <mrmoku> GNUtoo: I just added a comment to the ticket... tried moving fsodeviced to start as early as possible (directly after dbus) but that did not help
Oct 30 10:21:21 <GNUtoo> ok
Oct 30 10:22:07 <mrmoku> 2011-10-26T15:09:00.524688Z [DEBUG] fsodeviced : Registered 2 backtrace handler
Oct 30 10:22:28 <mrmoku> Oct 26 16:09:01 nokia900 user.err kernel: [   65.791107] et8ek8 3-003e: can't load firmware et8ek8-0002.bin
Oct 30 10:22:40 <mrmoku> hmm
Oct 30 10:23:14 <GNUtoo> how did you succeed to keep the date?
Oct 30 10:23:29 <mrmoku> ?
Oct 30 10:23:43 <GNUtoo> the date is always wrong on my n900
Oct 30 10:24:01 <mrmoku> well... 26th is not actually correct either :P
Oct 30 10:24:15 <GNUtoo> ok
Oct 30 10:24:23 <GNUtoo> we are 30 october
Oct 30 10:24:27 <GNUtoo> but it's close
Oct 30 10:24:27 <mrmoku> yup
Oct 30 10:24:37 <GNUtoo> for me it's like 1970
Oct 30 10:24:41 <GNUtoo> anyway
Oct 30 10:24:55 <GNUtoo> we could remove the camera from autoload?
Oct 30 10:25:17 <mrmoku> Oct 26 16:09:01 nokia900 user.info kernel: [    4.867034] omap3isp omap3isp: Revision 2.0 found
Oct 30 10:25:20 <mrmoku> Oct 26 16:09:01 nokia900 user.info kernel: [    4.872619] omap-iommu omap-iommu.0: isp: version 1.1
Oct 30 10:25:27 <mrmoku> those two are the ones before
Oct 30 10:26:07 <mrmoku> GNUtoo: omap3isp is in /etc/modules
Oct 30 10:26:15 <GNUtoo> indeed
Oct 30 10:26:17 <mrmoku> trying to disable that to see if it helps
Oct 30 10:26:26 <GNUtoo> but I really wonder what to do here
Oct 30 10:26:44 <GNUtoo> can we load dbus the earliest possible
Oct 30 10:26:48 <GNUtoo> and then load fsodeviced
Oct 30 10:26:48 <mrmoku> yeah, that's a principle problem
Oct 30 10:27:01 <mrmoku> fsodeviced must be running _before_ any modules are getting loaded
Oct 30 10:27:13 <GNUtoo> else we'll have to use mdev and stop using it as soon as fsodeviced starts
Oct 30 10:27:24 <mrmoku> indeed... disabling omap3isp did the trick
Oct 30 10:27:26 <mrmoku> it boots fast now
Oct 30 10:29:13 <mrmoku> GNUtoo: hmm... if I load omap3_isp after it is started I get the following:
Oct 30 10:29:16 <mrmoku> [   93.707214] et8ek8 3-003e: Invalid value on entry 0 0xcc
Oct 30 10:29:19 <mrmoku> [   93.707244] et8ek8 3-003e: invalid register list et8ek8-0002.bin, no POWERON mode found
Oct 30 10:29:29 <GNUtoo> hmmm
Oct 30 10:29:50 <GNUtoo> do you have the correct firmware?
Oct 30 10:29:54 <GNUtoo> like the one from meego
Oct 30 10:29:57 <GNUtoo> and not maemo
Oct 30 10:34:45 <GNUtoo> mrmoku, note that in shr-unstable the order was right and it worked
Oct 30 10:37:37 <GNUtoo> rahhhh it does the shr_elm_softkey bug
Oct 30 10:39:27 <GNUtoo> for me it seem to work
Oct 30 10:39:32 <GNUtoo> let me find an usb cable
Oct 30 10:39:40 <GNUtoo> rmmod omap3-isp
Oct 30 10:39:45 <GNUtoo> modprobe omap3-isp 
Oct 30 10:39:47 <GNUtoo> seem to work
Oct 30 10:44:23 <GNUtoo> mrmoku, http://pastie.org/2782190
Oct 30 10:46:40 <mrmoku> GNUtoo: hmm... you have a different firmware then?
Oct 30 10:46:53 <mrmoku> yeah
Oct 30 10:47:00 <mrmoku> mine is from maemo IIRC
Oct 30 10:47:10 <GNUtoo> the one from maemo doesn't work
Oct 30 10:47:44 <mrmoku> GNUtoo: JaMa wanted to try out systemd 
Oct 30 10:47:58 <mrmoku> that would change everything regarding boot ordering :P
Oct 30 10:48:36 <mrmoku> hmm... let me see if dbus and fsodeviced can start still a bit earlier
Oct 30 10:49:37 <mrmoku> S04modutils.sh
Oct 30 10:49:40 <mrmoku> runs very early
Oct 30 10:50:50 <GNUtoo> then let's put modutils after that 
Oct 30 10:50:56 <GNUtoo> howver....
Oct 30 10:51:04 <GNUtoo> ah no sorry
Oct 30 10:51:08 <mrmoku> dunno if that is good
Oct 30 10:51:15 <mrmoku> modules might be needed for something
Oct 30 10:51:17 <mrmoku> (in theory)
Oct 30 10:51:26 <GNUtoo> there is no issue puting modutils after since g_ether is loaded alone by a script
Oct 30 10:54:57 <mrmoku> GNUtoo: are the meego modules somewhere to download?
Oct 30 10:55:03 <mrmoku> or do I have to extract them from some image?
Oct 30 10:55:09 <GNUtoo> you mean firmware
Oct 30 10:55:10 <GNUtoo> yes
Oct 30 10:55:16 <mrmoku> err... yes firmware :)
Oct 30 10:55:44 <GNUtoo> http://build.meego.com/project/packages?project=devel%3Adevices%3An900
Oct 30 10:56:05 <mrmoku> thx
Oct 30 10:56:30 <mrmoku> ok, moving modutils.sh to S40, dbus-1 to S39 and fsodeviced to S40 works
Oct 30 10:56:36 <GNUtoo> so http://api.meego.com/public/source/devel:devices:n900/n900-camera-firmware/n900-camera-firmware_0.0.26.tar.bz2?rev=699978ddaee84ef3261a7629a3450707&
Oct 30 10:56:54 <GNUtoo> ok
Oct 30 12:29:59 <mrmoku> TAsn: I'm giving e another try :-)
Oct 30 12:49:55 <GNUtoo> JaMa, hi, how does gprof works with oe?
Oct 30 13:03:46 <GNUtoo> JaMa, I needed picocom for testing serial on nexus S, so I fixed the recipe but not the patches headers....can I push to shr and fix later?
Oct 30 13:23:18 <mrmoku> GNUtoo: I always have to build packages that need gprof manually
Oct 30 13:53:05 <JaMa> GNUtoo: no idea about gprof and yes you can push and fix later
Oct 30 13:53:20 <JaMa> GNUtoo: I just wont include it in next pull request
Oct 30 13:53:40 <JaMa> mrmoku: my images are already using systemd
Oct 30 13:54:04 <JaMa> mrmoku: if you want to try you can use jansa/test branches.. but it's not very usable (I have to work on it a bit more today)
Oct 30 13:57:06 <JaMa> lindi-: http://build.shr-project.org/tests/jama/kernel-nodrm/config.2.6.39
Oct 30 13:57:26 <JaMa> just moved platform-battery and bq27000-battery to modules
Oct 30 13:57:39 <JaMa> and added autoload for bq27000
Oct 30 13:57:53 <lindi-> JaMa: aha, great
Oct 30 13:58:54 <lindi-> JaMa: I addded debug symbols here to be able to use systemtap
Oct 30 14:00:20 <mrmoku> JaMa: cool :-)
Oct 30 14:08:35 <lindi-> JaMa: I still don't understand how that alsa DAPM stuff is supposed to work
Oct 30 14:11:04 <JaMa> neither do I, sorry
Oct 30 14:26:00 <GNUtoo> ok thanks a lot
Oct 30 14:26:39 <GNUtoo> JaMa, why did you moved bq27000 + platform battery as modules?
Oct 30 14:26:58 <GNUtoo> will autodetection of battery still work on om-gta02?
Oct 30 14:27:05 <GNUtoo> I've a bl5c clone
Oct 30 14:28:11 <GNUtoo> btw: E_DBus.h: no such file or directory while building elmentary
Oct 30 14:28:19 <GNUtoo> I'll try to cleansstate it and to rebuild
Oct 30 14:28:28 <JaMa> cleansstate worked for me
Oct 30 14:28:35 <JaMa> seen it only once 
Oct 30 14:28:39 <GNUtoo> lindi-, about DAPM look into the kernel docs
Oct 30 14:28:46 <GNUtoo> ok
Oct 30 14:28:47 <JaMa> and bq wasn't enabled at all in .39
Oct 30 14:29:09 <JaMa> and platform was as module before, so I've added both as modules and set autoload for bq
Oct 30 14:29:36 <GNUtoo> JaMa, ok, but what to do if I have both batteries
Oct 30 14:30:23 <JaMa> load platform-battery as with .37 and older
Oct 30 14:30:43 <GNUtoo> ah with 39 it's automatic?
Oct 30 14:32:31 <JaMa> bq is automatic, platform should be installed by default (from machine rrecommens)
Oct 30 14:33:44 <JaMa> iirc shr-settings have button to modprobe platform? 
Oct 30 14:34:04 <GNUtoo> really?
Oct 30 14:40:56 <GNUtoo> mrmoku, can you push the init scripts reordering?
Oct 30 14:43:19 <mrmoku> GNUtoo: have to look first where and how to do it
Oct 30 14:43:24 <mrmoku> GNUtoo: for fsodeviced it's easy
Oct 30 14:43:30 <mrmoku> for dbus maybe not
Oct 30 14:44:01 <mrmoku> and I'm still not sure that is theoretically correct
Oct 30 14:44:20 <mrmoku> JaMa: what do you think?
Oct 30 14:45:17 <JaMa> I didn't read the exact problem, but imho it's better to spend that time with adding .service file for systemd instead
Oct 30 14:45:48 <JaMa> systemd should be able to start it sooner with best possible order and as much in parallel as possible
Oct 30 14:45:49 <mrmoku> :)
Oct 30 14:46:11 <GNUtoo> ok 
Oct 30 14:46:13 <mrmoku> the problem is modules being loaded before fsodeviced is started... as the latter one serves as firmware loader
Oct 30 14:46:21 <GNUtoo> usually it's in the recipe itself
Oct 30 14:46:34 <GNUtoo> there is something for linking init script to rc*
Oct 30 14:46:40 <mrmoku> yeah, I know
Oct 30 14:47:02 <GNUtoo> ok
Oct 30 14:47:05 <mrmoku> for dbus I don't feel like changing it in oe-core though
Oct 30 14:47:13 <mrmoku> don't think that will cause a lot of joy ;)
Oct 30 14:47:33 <JaMa> mrmoku: ah I see and I agree the timeout for firmware loading while loading modules is stupid, but still lets fix it with systemd ;)
Oct 30 14:47:44 <mrmoku> JaMa: want me to help with it?
Oct 30 14:47:57 * mrmoku has systemd running on his laptop since some weeks
Oct 30 14:47:59 <GNUtoo> last time I tried systemd I had lots of issues
Oct 30 14:48:08 <GNUtoo> I hope it's fixed now
Oct 30 14:48:18 <JaMa> great, I'll push my branches and you can test it from there
Oct 30 14:48:23 <mrmoku> ok
Oct 30 14:48:23 <GNUtoo> it was last summer at work
Oct 30 14:48:39 <JaMa> GNUtoo: systemd is working pretty good for angstrom nowadays
Oct 30 14:48:44 <GNUtoo> ok nice
Oct 30 14:48:50 <mrmoku> GNUtoo: works fine on my laptop too
Oct 30 14:49:01 <JaMa> GNUtoo: see koen's presentation about booting userspace in 1 sec from ELCE
Oct 30 14:49:07 <GNUtoo> wow
Oct 30 14:49:11 <GNUtoo> let me look if I've that
Oct 30 14:51:26 <GNUtoo> which elce?
Oct 30 14:51:34 <JaMa> 2011
Oct 30 14:51:40 <JaMa> the presentation was this Friday
Oct 30 14:52:03 <GNUtoo> because it's not there: http://free-electrons.com/blog/elc-2011-videos/
Oct 30 14:52:04 <GNUtoo> ah ok
Oct 30 14:52:07 <mrmoku> JaMa: koen likes black a lot ? :P
Oct 30 14:52:19 <mrmoku> GNUtoo: http://elinux.org/ELCE_2011_Presentations
Oct 30 14:52:22 <JaMa> mrmoku: like me :)
Oct 30 14:52:22 <GNUtoo> ok
Oct 30 14:52:23 <mrmoku> there is a pdf linked there
Oct 30 14:52:30 <JaMa> mrmoku: oe-core/meta-oe jansa/test
Oct 30 14:52:38 <JaMa> but don't use python-2.7 yet
Oct 30 14:52:46 <JaMa> and meta-smartphone jama branch
Oct 30 14:53:02 * JaMa finishing build for qemu to test it there first
Oct 30 14:54:11 <mrmoku> JaMa: the sys_accept4 part is interesting
Oct 30 14:56:29 <JaMa> yes amazing speedup
Oct 30 14:56:59 <JaMa> btw there is new elsa xdm replacement already with .service file
Oct 30 14:57:08 <JaMa> so I plan to use it instead of xserver-nodm-init
Oct 30 14:57:17 <JaMa> because it has also autologin config option
Oct 30 14:57:48 <mrmoku> JaMa: hehe... I installed elsa on my laptop today 
Oct 30 14:58:02 <mrmoku> did have no luck with using it yet though
Oct 30 14:59:04 <GNUtoo> ok I finished reading the pdf
Oct 30 14:59:09 <JaMa> cedric showed it to me on ELCE and it looked nice
Oct 30 14:59:45 <JaMa> but for our scenario (without switching users) the most interesting part was that he said it's actually faster then xinit
Oct 30 15:01:07 <mrmoku> ok :)
Oct 30 15:12:10 <GNUtoo> JaMa, I talked with nschle85 
Oct 30 15:12:21 <GNUtoo> and he told me you already tried the 3.0 kernel for the n900
Oct 30 15:12:32 <GNUtoo> 1)what is lacking
Oct 30 15:12:38 <GNUtoo> 2)did you try the camera branch 
Oct 30 15:12:52 <GNUtoo> the camera branch has the same commits than the 3.0 branch and camera on top of it
Oct 30 15:15:28 <GNUtoo> mrmoku, will you finish the fsoaudiod plugin for gsm sound
Oct 30 15:15:29 <GNUtoo> ?
Oct 30 15:15:35 <GNUtoo> and what should I work on right now
Oct 30 15:15:36 <GNUtoo> ?
Oct 30 15:15:54 <GNUtoo> I could work on nexus S mainlining
Oct 30 15:15:57 <GNUtoo> or n900 work
Oct 30 15:16:00 <GNUtoo> or om-gta02 work
Oct 30 15:16:12 <GNUtoo> there is also some work to do on the htc devices
Oct 30 15:16:25 <GNUtoo> but I guess no one uses the dream anymore
Oct 30 15:18:55 <JaMa> well those 3.x branches are not very recent :/ so I have tried it and when it panicked I have tried something else and later returned to default kernel to do some other work
Oct 30 15:19:16 <JaMa> you can check nokia-upgrade branch in meta-smartphone
Oct 30 15:19:51 <GNUtoo> ok
Oct 30 15:20:26 <GNUtoo> that's very bad
Oct 30 15:20:44 <GNUtoo> that means that there is no more upstreaming work for n900?
Oct 30 15:39:14 <PaulFertser> lindi-: an offtopic question: how should i better motivate Debian stable folks to make a patch for compat-wireless to be compilable for their latest stable kernel?
Oct 30 15:49:10 <GNUtoo> PaulFertser, where's the compilation failure?
Oct 30 15:50:51 <PaulFertser> GNUtoo: http://forums.debian.net/viewtopic.php?f=10&t=70450
Oct 30 15:51:42 <PaulFertser> GNUtoo: it's due to Debian backporting some stuff that's backported by compat-wireless too.
Oct 30 15:51:52 <GNUtoo> yes I know
Oct 30 15:52:05 <GNUtoo> at GNU/Linux day I had to cope with that
Oct 30 15:52:20 <GNUtoo> I fixed by commenting the compat wireless redefinition
Oct 30 15:53:29 <lindi-> PaulFertser: not sure if stable can be fixed due to something like that :/
Oct 30 15:56:10 <PaulFertser> lindi-: not stable, but i mean i want to motivate somebody to add a special-case to compat-wireless.
Oct 30 15:58:06 <lindi-> PaulFertser: ah
Oct 30 15:59:33 <PaulFertser> lindi-: compat-wireless maintainer agrees to accept a patch, but since neither he nor me doesn't use debian stable there's no patch yet.
Oct 30 16:02:08 <GNUtoo> I don't use debian so it would be a little bit hard to do it for me
Oct 30 16:02:15 <GNUtoo> I use trisquel
Oct 30 16:15:22 <JaMa> hmm emtooth2 fails here | error: Package `elm' not found in specified Vala API directories or GObject-Introspection GIR directories
Oct 30 16:15:30 <JaMa> but libeflvala was already upgraded
Oct 30 16:17:56 <GNUtoo> [Rui], hi
Oct 30 16:18:13 <[Rui]> GNUtoo: hi, shr-core seems a bit more unstable than unstable was :)
Oct 30 16:18:23 <GNUtoo> yes but still will you fix?
Oct 30 16:18:34 <GNUtoo> because it's unbereable
Oct 30 16:18:45 <GNUtoo> I've to killall -9 shr_elm_softkey
Oct 30 16:18:47 <[Rui]> GNUtoo: funny thing: hasn't happened to me but for the few first times
Oct 30 16:18:49 <GNUtoo> and then to restart it
Oct 30 16:18:51 <GNUtoo> very often
Oct 30 16:19:00 <GNUtoo> I've even started to trace the bug
Oct 30 16:19:02 <[Rui]> but another thing happened last night
Oct 30 16:19:08 <GNUtoo> basically it uses 100% CPU
Oct 30 16:19:09 <[Rui]> "close" wasn't closing
Oct 30 16:19:14 <GNUtoo> yes possible
Oct 30 16:19:24 <GNUtoo> that does it on certain apps
Oct 30 16:19:59 <GNUtoo> but that's secondary
Oct 30 16:20:21 <GNUtoo> it's really frustrating and unusable because of this shr_elm_softkey bug
Oct 30 16:20:32 <GNUtoo> basically I think it uses 100% CPU 
Oct 30 16:20:38 <GNUtoo> which makes it not display  
Oct 30 16:20:50 <GNUtoo> withing gdb when I stop it
Oct 30 16:20:55 <GNUtoo> like ctrl + c
Oct 30 16:20:59 <GNUtoo> and I can bt etc...
Oct 30 16:21:04 <GNUtoo> it does the bug
Oct 30 16:21:08 <GNUtoo> but when I do c
Oct 30 16:21:16 <GNUtoo> it continue and the bug isn't there anymore
Oct 30 16:21:29 <GNUtoo> so I think we should profile it
Oct 30 16:21:35 <GNUtoo> because it uses 100% CPU
Oct 30 16:21:43 <GNUtoo> and cannot be displayed because of that
Oct 30 16:23:20 <pespin> JaMa, emtooth2 fails'
Oct 30 16:23:42 <GNUtoo> pespin, JaMa just reported that
Oct 30 16:24:28 <pespin> uhmm it built right here afair
Oct 30 16:24:30 <pespin> I'll check
Oct 30 16:24:57 <GNUtoo> [Rui], if you need help I'm here
Oct 30 16:25:09 <GNUtoo> but please let's fix it, else I abandon SHR+FSO
Oct 30 16:29:14 <GNUtoo> [Rui], I've even gdbserver + gdb setup
Oct 30 16:29:25 <GNUtoo> altough om-gta02 is off since I'm at home
Oct 30 16:29:34 <GNUtoo> but I can power it on and help you to debug that
Oct 30 16:29:36 <[Rui]> ok
Oct 30 16:30:15 <[Rui]> I'm also trying to fix my tablet, because the pointer seems to have gone crazy (hope it's just something fixable with software config)
Oct 30 16:30:57 <GNUtoo> let's fix the shr_elm_softkey first
Oct 30 16:31:03 <GNUtoo> else fso+shr will die
Oct 30 16:32:06 <[Rui]> GNUtoo: well, now that you put it that way...
Oct 30 16:32:25 <GNUtoo> the problem is that I use the gta02 as everyday phone
Oct 30 16:32:31 <GNUtoo> maybe I shouldn't?
Oct 30 16:33:52 <[Rui]> eek
Oct 30 16:34:03 <[Rui]> my dev disk just threatned to die on me
Oct 30 16:34:11 <GNUtoo> ouch
Oct 30 16:34:30 <GNUtoo> else I've everything installed for gdb here but maybe we need gprof
Oct 30 16:35:12 <pespin> ah ok, now fails
Oct 30 16:35:22 <pespin> I didn't clean emtooth2 correctly while rebuilding
Oct 30 16:36:13 <[Rui]> well, it started making a lot of noise, so I unplugged the power from it, and now it seems to be ok
Oct 30 16:39:41 <pespin> JaMa, please, use rev 162 in OE for emtooth2, it should be fixed now ;)
Oct 30 16:39:57 <JaMa> pespin: ok
Oct 30 16:42:42 <[Rui]> there were some changes on the softpanel
Oct 30 16:42:57 <GNUtoo> ok
Oct 30 16:43:45 <CIA-5> SHR: 03Martin.Jansa 07meta-smartphone * ra8420c0fa5c4 10/ (5 files in 5 dirs): meta-smartphone: linux.inc: change KEEP_OABI default to disabled
Oct 30 16:43:46 <[Rui]> seem pretty inocuous, though, some EFL api change adjustments that mrmoku did.
Oct 30 16:43:55 <CIA-5> SHR: 03Martin.Jansa 07meta-smartphone * r639a2e313e3f 10/meta-shr/recipes-shr/3rdparty/emtooth2_svn.bb: emtooth2: bump SRCREV
Oct 30 16:43:55 <CIA-5> SHR: 03Martin.Jansa 07meta-smartphone * rc89771832b50 10/meta-openmoko/ (3 files in 3 dirs): meta-openmoko: linux-2.6.39: enable BQ27x00 module and platform battery as module
Oct 30 16:47:34 <lindi-> PaulFertser: so you are looking for somebody who has debian and could test such a patch?
Oct 30 16:49:44 <PaulFertser> lindi-: no, i'm looking for somebody, who is using Debian stable with the stock kernel and willing to write a patch himself.
Oct 30 16:49:49 <PaulFertser> :)
Oct 30 16:50:01 <lindi-> PaulFertser: ok :)
Oct 30 16:54:54 <GNUtoo> [Rui], do you have any idea? should I try to gprof the shr_elm_softkey binary?
Oct 30 16:57:44 <mrmoku> [Rui]: I've been reading the softkey code today... and comparing it with the one of the example in PROTO
Oct 30 16:58:22 <[Rui]> I'm trying to do two things, right now, 1) understand how to build a local thing in shr-chroot/shr-core
Oct 30 16:58:31 <mrmoku> one difference is handling of multiple roots + zones
Oct 30 16:58:32 <[Rui]> and 2) trying to get my gta02 to ping
Oct 30 16:58:42 <GNUtoo> [Rui], you need the dbus fix
Oct 30 16:58:57 <mrmoku> [Rui]: local building is easy
Oct 30 16:58:58 <GNUtoo> [Rui], do you see usb0?
Oct 30 16:59:17 <[Rui]> there is an usb0 with 192.168.7.2
Oct 30 16:59:25 <GNUtoo> ok
Oct 30 16:59:33 <GNUtoo> ifconfig usb0 192.168.7.1
Oct 30 16:59:35 <[Rui]> new local ip address?
Oct 30 16:59:38 <GNUtoo> yes
Oct 30 16:59:41 <GNUtoo> from yocto
Oct 30 16:59:44 <[Rui]> no longer the other one?
Oct 30 16:59:47 <GNUtoo> no
Oct 30 17:00:05 <[Rui]> then I need to change my network manager connection :)
Oct 30 17:00:16 <GNUtoo> check if you have an usb0
Oct 30 17:00:26 <GNUtoo> on your laptop/workstation
Oct 30 17:00:48 <[Rui]> it becomes eth1 in my laptop
Oct 30 17:01:30 <GNUtoo> ok
Oct 30 17:01:36 <GNUtoo> then you don't have the dbus issue
Oct 30 17:01:56 <[Rui]> huh? Received disconnect from 192.168.7.2: 2: Too many authentication failures for root
Oct 30 17:02:21 <GNUtoo> set a password
Oct 30 17:02:29 <[Rui]> I did
Oct 30 17:02:30 <GNUtoo> passwd in vala-terminal
Oct 30 17:02:31 <GNUtoo> ok
Oct 30 17:03:23 <[Rui]> samething with a new password
Oct 30 17:03:41 <GNUtoo> grrr
Oct 30 17:03:45 <GNUtoo> hmmm
Oct 30 17:04:06 <GNUtoo> ifconfig eth1?
Oct 30 17:04:15 <GNUtoo> because maybe you're trtying to ssh into your laptiop
Oct 30 17:04:46 <[Rui]> hms, doesn't generate a logevent viewable with logread
Oct 30 17:04:55 <[Rui]> no, laptop is 7.1, moko is 7.2
Oct 30 17:05:37 <GNUtoo> then netcat
Oct 30 17:06:10 <GNUtoo> nc -l 1234 -e /bin/ash # on openmoko
Oct 30 17:06:31 <[Rui]> good idea
Oct 30 17:06:31 <GNUtoo> nc 192.168.7.2 1234 #on your laptop
Oct 30 17:06:45 <GNUtoo> but beware if you ctrl+c it quits netcat
Oct 30 17:07:12 <GNUtoo> else there is also telnetd
Oct 30 17:07:19 <[Rui]> however moko's nc doesn't do that :(
Oct 30 17:07:38 <GNUtoo> ah?
Oct 30 17:07:40 <GNUtoo> let me try
Oct 30 17:07:57 <[Rui]> I can do a reverse shell, though, nc ip port | /bin/ash
Oct 30 17:08:15 <GNUtoo> ok
Oct 30 17:11:12 <GNUtoo> maybe just reboot the gta02
Oct 30 17:12:05 <GNUtoo> and after try /usr/bin/sshd -p23
Oct 30 17:12:14 <GNUtoo> ssh root@192.168.7.2 -p23
Oct 30 17:12:26 <GNUtoo> don't forget to set the ip of your laptop tough
Oct 30 17:13:00 <[Rui]> ok nice, I can type on my terminal and see the results in moko's screen :)
Oct 30 17:13:09 <GNUtoo> yes
Oct 30 17:13:17 <GNUtoo> ok
Oct 30 17:15:23 <GNUtoo> /usr/sbin/sshd -d -p24
Oct 30 17:16:15 <[Rui]> better than that, I was able to cat my key, so now ssh works
Oct 30 17:16:23 <GNUtoo> ok
Oct 30 17:16:25 <GNUtoo> nice
Oct 30 17:16:37 <GNUtoo> then what's the next step?
Oct 30 17:17:22 <[Rui]> ok, only happens after the dropped window list
Oct 30 17:17:39 <GNUtoo> what do you mean exactly?
Oct 30 17:17:44 <GNUtoo> you want a screenshot?
Oct 30 17:17:47 <GNUtoo> like in the bugreport?
Oct 30 17:17:54 <[Rui]> but it enters a nice state, I can't even cancel it or send it to the background
Oct 30 17:18:12 <mrmoku> [Rui]: yeah, that's what I think too... the drop down list kills it
Oct 30 17:18:15 <GNUtoo> I don't understand the context
Oct 30 17:18:18 <GNUtoo> ah ok
Oct 30 17:18:23 <GNUtoo> you're talking about in-code
Oct 30 17:18:36 <mrmoku> GNUtoo: no, the list of open windows
Oct 30 17:18:42 <mrmoku> when you press the down arrow
Oct 30 17:18:48 <mrmoku> after that it happens to me
Oct 30 17:18:55 <[Rui]> funny thing, I couldn't ctrl-c or ctrl-z it
Oct 30 17:18:55 <mrmoku> not if I only switch left and right between windows
Oct 30 17:18:59 <GNUtoo> ah indeed
Oct 30 17:19:03 <GNUtoo> I didn't notice
Oct 30 17:19:32 <[Rui]> mrmoku: as for the difference towards e17's softkey, yeah, I'm not taking in account multiple roots
Oct 30 17:19:55 <[Rui]> when does that happen? multiple screens or multiple virtual screens?
Oct 30 17:20:40 <mrmoku> [Rui]: I have no idea whatever... just noticed the difference :-)
Oct 30 17:20:51 * mrmoku does not even know what a zone actually is
Oct 30 17:21:04 <[Rui]> mrmoku: yeah, same feeling I had then :)
Oct 30 17:21:10 <[Rui]> which is why I simplified it a bit
Oct 30 17:22:24 <[Rui]> let's try to strace it
Oct 30 17:23:41 <GNUtoo> I've gdb that I can setup if you want
Oct 30 17:24:13 <[Rui]> uh... this is a first
Oct 30 17:24:24 <[Rui]> there isn't even any output of syscalls
Oct 30 17:24:31 <[Rui]> like it's doing a while(1);
Oct 30 17:26:38 <[Rui]> easy local builds
Oct 30 17:26:40 <[Rui]> howto :)
Oct 30 17:26:51 <[Rui]> with this new chroot environment.
Oct 30 17:27:49 <[Rui]> well, I probably can just do "mount -o bind" to the git directory to somewhere
Oct 30 17:28:36 <CIA-5> freesmartphone.org: 03morphis 07cornucopia * r1c0dd7aabb30 10/fsogsmd/src/plugins/modem_samsung/ (Makefile.am channel.vala mediators_sim.vala): 
Oct 30 17:28:36 <CIA-5> freesmartphone.org: fsogsmd: modem_samsung: adjust for recent changes to libsamsung-ipc API
Oct 30 17:28:36 <CIA-5> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Oct 30 17:29:35 <mrmoku> [Rui]: indeed... mount -o bind is your friend
Oct 30 17:29:53 <[Rui]> something like this?
Oct 30 17:29:53 <mrmoku> sudo mount -t nfs4 gonzales:src OE/source
Oct 30 17:29:55 <mrmoku> sudo sh shr-chroot.sh
Oct 30 17:29:57 <[Rui]> INHERIT_append_pn-shr-e-gadgets = "srctree gitpkgv"
Oct 30 17:29:57 <[Rui]> SRCREV_pn-shr-e-gadgets = "${GITSHA}"
Oct 30 17:29:57 <[Rui]> S_pn-shr-e-gadgets = "/git/${PN}"
Oct 30 17:29:58 <mrmoku> sudo umount OE/source
Oct 30 17:30:03 <mrmoku> that's what I'm doing
Oct 30 17:31:08 <GNUtoo|laptop> http://www.pastie.org/2783662
Oct 30 17:31:14 <GNUtoo|laptop> it's blocked at the last line
Oct 30 17:31:31 <[Rui]> bitbake: error: no such option: -i
Oct 30 17:31:51 <GNUtoo|laptop> let's see what 11 is
Oct 30 17:32:15 <GNUtoo|laptop> lrwx------    1 root     root            64 Oct 28 20:21 11 -> socket:[2515]
Oct 30 17:32:30 <GNUtoo|laptop> [Rui], I think -i has been removed
Oct 30 17:32:51 <[Rui]> I had forgotten to load setup-env anyway
Oct 30 17:32:56 <GNUtoo> ok
Oct 30 17:32:59 <[Rui]> hms... .the instructions should reflect that.
Oct 30 17:33:42 <mrmoku> bbl
Oct 30 17:33:55 <GNUtoo|laptop> root@om-gta02:/proc/407/fd# netstat |  grep 2515
Oct 30 17:33:55 <GNUtoo|laptop> unix  3      [ ]         STREAM     CONNECTED       2515
Oct 30 17:34:01 <GNUtoo|laptop> hmmm
Oct 30 17:34:13 <GNUtoo|laptop> I don't know how to identify the socket after that
Oct 30 17:34:14 <[Rui]> how can I avoid parsing the recipies?
Oct 30 17:34:20 <GNUtoo|laptop> [Rui], -b
Oct 30 17:42:23 <[Rui]> damn, my laptop froze
Oct 30 17:43:27 <morphis> GarthPS: ping
Oct 30 17:44:52 <morphis> GarthPS: http://amethyst.openembedded.net/~morphis/uImage-2.6.24+gitr1+4ed85bdd7b091e40800a95e99afa22f32250c107-r0-palmpre-20111022072950.bin
Oct 30 17:44:58 <morphis> GarthPS: äh sorry
Oct 30 17:45:17 <morphis> GarthPS: damn it I builded the wrong kernel
Oct 30 17:47:27 <[Rui]> well, now I remember, it's better to point to a make dist'ed tar ball than using a git dir directly :)
Oct 30 18:04:27 <CIA-5> freesmartphone.org: 03morphis 07cornucopia * r5ef7a933129a 10/fsogsmd/src/plugins/lowlevel_samsung_crespo/plugin.vala: 
Oct 30 18:04:27 <CIA-5> freesmartphone.org: fsogsmd: lowlevel_samsung_crespo: adjust for latest changed to libsamsung-ipc
Oct 30 18:04:27 <CIA-5> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Oct 30 18:08:02 <[Rui]> GNUtoo: somehow, I can't build with a local recipe
Oct 30 18:08:11 <[Rui]> some recursion errors :(
Oct 30 18:08:16 <GNUtoo> hmmm I must compile shr_elm_softkey with -O0
Oct 30 18:08:25 <GNUtoo|laptop> what are the errors
Oct 30 18:08:44 <GNUtoo|laptop> personally I've <optimized out>
Oct 30 18:08:47 <GNUtoo|laptop> as values
Oct 30 18:08:54 <GNUtoo|laptop> so that's not good for debugging
Oct 30 18:08:58 <GarthPS> morphis: hi. what is it ? but sorry I have to go. 
Oct 30 18:09:23 <GNUtoo> let me rty something
Oct 30 18:10:15 <[Rui]> http://pastebin.com/tzKYZHk9
Oct 30 18:11:12 <GNUtoo> can you do that instead of using srcpv:
Oct 30 18:11:19 <GNUtoo> build shr_elm_softkey
Oct 30 18:11:27 <GNUtoo> then since it copies its git
Oct 30 18:11:34 <GNUtoo> just run temp/run.do.compile
Oct 30 18:11:59 <GNUtoo> because here it complains about srcpv
Oct 30 18:12:05 <GNUtoo> or maybe remove srcpv
Oct 30 18:12:20 <GNUtoo> I think it's not in oe-core anymore but I'm not sure
Oct 30 18:12:25 <GNUtoo> JaMa, would know
Oct 30 18:13:28 <[Rui]> anyway, I gotta continue this later.
Oct 30 18:13:38 <[Rui]> bbl
Oct 30 18:14:00 <GNUtoo> ok when?
Oct 30 18:14:21 <GNUtoo> I didn't eat either because that bug is very very very important for me
Oct 30 18:15:44 <GNUtoo> [Rui], wait a sec
Oct 30 18:15:53 <GNUtoo|laptop> 370		if( !(num && windows)) return;
Oct 30 18:16:02 <GNUtoo|laptop> window is $5 = (Ecore_X_Window *) 0x0
Oct 30 18:16:04 <GNUtoo|laptop> 0x0
Oct 30 18:16:07 <GNUtoo|laptop> is it normal
Oct 30 18:16:08 <GNUtoo|laptop> ?
Oct 30 18:16:59 <GNUtoo|laptop> same for many evas objects
Oct 30 18:18:21 <[Rui]> GNUtoo: sorry, but I have baby stuff to do :( I have to review the code, but I can't easily explain an infinite loop without some bug in ecore_x
Oct 30 18:18:32 <GNUtoo> ok
Oct 30 18:18:41 <GNUtoo> when will you be back?
Oct 30 18:18:46 <GNUtoo> I've gdb
Oct 30 18:18:52 <GNUtoo> but I don't understand e code well
Oct 30 18:19:12 <[Rui]> now with dinner preparation, baby bath and putting to bed, in about 3 to 4 hours, depends on how well things go.
Oct 30 18:19:14 <GNUtoo> I would do all the possible from my part to get that bug fixed
Oct 30 18:19:15 <GNUtoo> ok
Oct 30 18:19:28 <GNUtoo> then I'll try to stay awake
Oct 30 18:19:49 <[Rui]> GNUtoo: ok. even if you are not here, we will repeat this again tomorrow or tuesday (holiday in Portugal, so I got all day minus family dues)
Oct 30 18:19:59 <GNUtoo> hollidays here too
Oct 30 18:20:06 <GNUtoo> THANKS  A LOT!!!!
Oct 30 18:20:08 <[Rui]> GNUtoo: I'd rather you slept well so you have a good monday :)
Oct 30 18:20:19 <GNUtoo> ok
Oct 30 18:20:27 <GNUtoo> indeed when I don't sleep I get nervous
Oct 30 18:20:30 <[Rui]> GNUtoo: I can trigger the bug too, so hopefully I won't need you to stay awake
Oct 30 18:20:36 <GNUtoo> ok
Oct 30 18:20:40 <GNUtoo> but I've gdb
Oct 30 18:21:15 <GNUtoo> I'll eat then
Oct 30 18:21:20 <[Rui]> yeah, but I'm not much of a gdb expert, but if you can send me stack trace pasties it would be good.
Oct 30 18:21:20 <GNUtoo> thanks a lot for trying to fix
Oct 30 18:21:36 <GNUtoo> just tell me what variables you want to know the content of
Oct 30 18:21:47 <[Rui]> GNUtoo: I'm only sorry it's only me and my wife to take care of the baby, which takes a whole lot of our time and energy :|
Oct 30 18:21:57 <[Rui]> ok
Oct 30 18:21:57 <GNUtoo> ok
Oct 30 18:22:00 <[Rui]> bbl
Oct 30 18:22:04 <GNUtoo> maybe I'll send you a mail then
Oct 30 18:22:07 <GNUtoo> with gdb traces
Oct 30 18:23:40 <GNUtoo> I'll eat
Oct 30 18:32:15 <PaulFertser> Eating gdb traces? Mmmm, tasty!
Oct 30 18:32:17 <PaulFertser> ;)
Oct 30 19:21:35 <DocScrutinizer> ~burp*
Oct 30 19:32:23 <GNUtoo> pespin, hi
Oct 30 19:32:30 <pespin> GNUtoo, hi
Oct 30 19:34:04 <GNUtoo|laptop> pespin, I'm trying to debug shr_elm_softkey
Oct 30 19:34:18 <GNUtoo|laptop> [Rui], was there but he'll be back too late
Oct 30 19:34:25 <pespin> how is it going?
Oct 30 19:34:30 <GNUtoo|laptop> want to join and help me?
Oct 30 19:34:31 <pespin> I won't be abel o help you today I'm sorry
Oct 30 19:34:36 <GNUtoo|laptop> ok
Oct 30 19:34:36 <GNUtoo|laptop> np
Oct 30 19:34:44 <GNUtoo|laptop> because I don't know efl in C
Oct 30 19:34:46 <pespin> maybe tomorrow i ahve some time :)
Oct 30 19:34:54 <GNUtoo|laptop> I only know edje 
Oct 30 19:34:57 <GNUtoo|laptop> ok
Oct 30 19:35:03 <pespin> the code is in shr git right?
Oct 30 19:35:26 <GNUtoo|laptop> commenting      evas_object_smart_callback_add(list, "selected", on_win_select, NULL); makes it not crash but remove the window selection functionality
Oct 30 19:35:27 <GNUtoo|laptop> yes
Oct 30 19:35:37 <GNUtoo|laptop> shr-e-gadgets
Oct 30 19:36:05 <pespin> GNUtoo, (code line) yeah makes sense
Oct 30 19:37:07 <pespin> GNUtoo, you could try removing the "app list" functionality and try if it doesn't takes 100% cpu then (as in removing callback from central button)
Oct 30 19:37:19 <GNUtoo> ok
Oct 30 19:37:34 <GNUtoo> what's app list exactly?
Oct 30 19:37:51 <pespin> GNUtoo, if you press the central button afair, a list appears
Oct 30 19:38:00 <GNUtoo> ah, not a good idea
Oct 30 19:38:02 <pespin> with all the apps currently open
Oct 30 19:38:03 <GNUtoo> it's not the list itself
Oct 30 19:38:21 <GNUtoo> it's when you click on a list component that it takes 100%
Oct 30 19:38:26 <GNUtoo> CPU
Oct 30 19:38:33 <pespin> ah ok, so you arrived there already
Oct 30 19:38:34 <pespin> ok
Oct 30 19:38:40 <pespin> I have to go now tought, I'll be afk
Oct 30 19:38:53 <pespin> hope I can help you tomorrow if you didn't catch the problem
Oct 30 19:39:17 <GNUtoo> ok
Oct 30 19:42:06 <GNUtoo> ok I know how to workarround now
Oct 30 19:42:11 <GNUtoo> I've a working thing
Oct 30 19:42:18 <GNUtoo> but I've no idea if it's correct or not
Oct 30 19:42:35 <GNUtoo|laptop> 	//	evas_object_del(tasklist_win);
Oct 30 19:42:36 <GNUtoo|laptop> 	//	winlist_free_if_not_null();
Oct 30 19:42:41 <GNUtoo|laptop> that makes it work again
Oct 30 19:42:47 <GNUtoo|laptop> in on_win_selected
Oct 30 19:43:40 <GNUtoo|laptop> does somebody knows e enough?
Oct 30 19:43:45 <GNUtoo|laptop> pespin, are you still there?
Oct 30 19:43:59 <GNUtoo|laptop> maybe JaMa or mrmoku knows a bit efl?
Oct 30 19:44:07 <GNUtoo|laptop> s/knows/know/
Oct 30 19:44:07 <apt> GNUtoo|laptop meant: maybe JaMa or mrmoku know a bit efl?
Oct 30 19:44:24 <GNUtoo|laptop> what should I do?
Oct 30 19:44:26 <GNUtoo|laptop> commit?
Oct 30 19:44:29 <GNUtoo|laptop> try something?
Oct 30 19:46:48 <GNUtoo> memory seem mostly constent according to htop
Oct 30 19:46:55 <GNUtoo> 7.3%
Oct 30 19:47:02 <CIA-5> freesmartphone.org: 03morphis 07cornucopia * rd07512621d44 10/fsogsmd/src/plugins/modem_samsung/channel.vala: 
Oct 30 19:47:02 <CIA-5> freesmartphone.org: fsogsmd: modem_samsung: supply read/write delegates in the correct order for libsamsung-ipc
Oct 30 19:47:02 <CIA-5> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Oct 30 19:54:13 <GNUtoo> [Rui], when you come back look at my fix
Oct 30 19:54:30 <CIA-5> freesmartphone.org: 03morphis 07cornucopia * rabdb08ee0f62 10/fsogsmd/conf/herring/fsogsmd.conf: 
Oct 30 19:54:30 <CIA-5> freesmartphone.org: fsogsmd: herring configuration: set samsung_ipc as pdp handler
Oct 30 19:54:30 <CIA-5> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Oct 30 19:57:10 <mrmoku> GNUtoo|laptop: hmm... interesting
Oct 30 19:57:52 <GNUtoo> yes indeed it works with my fix
Oct 30 19:58:10 <GNUtoo> I've no idea of the collateral issues that could result of it tough
Oct 30 19:58:36 <GNUtoo> I've not even tested which one of both is strictly necessary
Oct 30 19:58:50 <GNUtoo> or both
Oct 30 19:59:04 <mrmoku> other than not being able to switch applications via the list?
Oct 30 19:59:10 <GNUtoo> no
Oct 30 19:59:13 <GNUtoo> it works perfectly
Oct 30 19:59:18 <GNUtoo> I can switch apps
Oct 30 19:59:20 <GNUtoo> etc...
Oct 30 19:59:21 <GNUtoo> it works
Oct 30 19:59:28 <GNUtoo> and I see no memory increase usage
Oct 30 19:59:31 <GNUtoo> the fix is this one:
Oct 30 19:59:44 <GNUtoo> <GNUtoo|laptop>  // evas_object_del(tasklist_win);
Oct 30 19:59:44 <GNUtoo> <GNUtoo|laptop>  // winlist_free_if_not_null();
Oct 30 20:00:03 <GNUtoo> in the on_win_select callback
Oct 30 20:00:04 <mrmoku> GNUtoo|laptop: hmmm... interesting
Oct 30 20:00:14 <mrmoku> I wonder how that ever worked correctly ;)
Oct 30 20:00:22 <GNUtoo> ah?
Oct 30 20:00:47 <GNUtoo> I've only tested both comments together
Oct 30 20:00:54 <GNUtoo> should I test them alone separately?
Oct 30 20:01:24 <GNUtoo> ah it's recompiling efl 
Oct 30 20:01:30 <GNUtoo> I launched a build sorry
Oct 30 20:01:55 <mrmoku> GNUtoo|laptop: //paste.pocoo.org/show/500574/
Oct 30 20:01:59 <mrmoku> would be my proposal
Oct 30 20:02:02 <GNUtoo> anyway if a fix is made, don't forget to credit the people looking for the bug in the commit message
Oct 30 20:02:18 <mrmoku> hmm... or does evas_object_del do the NULL?
Oct 30 20:02:25 <CIA-5> SHR: 03morphis 07meta-smartphone * r911a07b56087 10/meta-shr/recipes-connectivity/connman/ (connman/connman connman_0.77.bbappend): meta-shr: connman: ignore ifb0/ifb1 devices for configuration too and bump PR
Oct 30 20:02:28 <mrmoku> maybe it once did?
Oct 30 20:02:36 <CIA-5> SHR: 03morphis 07meta-smartphone * rd56667bed3bb 10/meta-fso/recipes-freesmartphone/freesmartphone/cornucopia.inc: meta-fso: cornucopia: bump SRCREV
Oct 30 20:02:36 <CIA-5> SHR: 03morphis 07meta-smartphone * rc3c0e162537a 10/meta-fso/recipes-freesmartphone/freesmartphone/libsamsung-ipc_git.bb: meta-fso: libsamsung-ipc: bump SRCREV
Oct 30 20:02:45 <GNUtoo> hmmm
Oct 30 20:02:48 <GNUtoo> no idea
Oct 30 20:02:52 <GNUtoo> I don't know evas
Oct 30 20:03:02 <GNUtoo> I only assisted to an evas presentation
Oct 30 20:03:07 <GNUtoo> oops
Oct 30 20:03:11 <GNUtoo> I only assisted to an edje presentation
Oct 30 20:07:53 <mrmoku> GNUtoo|laptop: I checked evas_object_del documentation
Oct 30 20:08:09 <mrmoku> that clearly does not NULL it and AIUI never did
Oct 30 20:08:24 <mrmoku> so you could try my patch :)
Oct 30 20:08:37 <mrmoku> or I could commit it... I'm quite sure in anyway that is a correct thing to do
Oct 30 20:09:52 <CIA-5> SHR: 03mok 07shr-e-gadgets * rf21862225506 10/src/softkey_quickpanel/main.c: softkey_quickpanel: NULL the tasklist pointer after evas_object_del
Oct 30 20:10:07 <mrmoku> GNUtoo|laptop: good find :)
Oct 30 20:10:31 <GNUtoo> ok
Oct 30 20:10:40 <GNUtoo> thanks
Oct 30 20:12:07 <GNUtoo> altough you forget to credit people helping in the bug research
Oct 30 20:12:14 <GNUtoo> for instance kernel people do thiws
Oct 30 20:12:15 <GNUtoo> *this
Oct 30 20:12:25 <mrmoku> hmm... right you are
Oct 30 20:13:12 <mrmoku> I just thought about giving you a rev to build... not about a good commit :/
Oct 30 20:13:15 <mrmoku> sorry for that
Oct 30 20:13:19 <GNUtoo> np
Oct 30 20:13:56 <GNUtoo> the most important is to fix the bug
Oct 30 20:14:12 <GNUtoo> because else I become mad, break devices and quit
Oct 30 20:14:21 <GNUtoo> *quit shr+fso
Oct 30 20:15:28 <GNUtoo> the problem is quite simple, I need a phone, and other phones than gta02 are not ready or not free enough
Oct 30 20:16:30 <GNUtoo> the other problem: I planed work a bit on gta02 and fso phones and then do something else(work on gta02 baseband) but I cannot do that anymore
Oct 30 20:16:40 <GNUtoo> s/anymore/
Oct 30 20:16:59 <GNUtoo> you cannot get gsm test licenses in italy....
Oct 30 20:17:46 <GNUtoo> so I've to finish the studies as soon as possible and change country
Oct 30 20:18:35 <TAsn> mrmoku, yay :)
Oct 30 20:18:50 <GNUtoo> the plan was to continue the port of nuttx and then to port osmocombb to nuttx
Oct 30 20:39:55 <GNUtoo|laptop> mrmoku, I bumped the rev locally, I'll try your fix
Oct 30 20:46:18 <TAsn> mrmoku, I told you, I use detourious (or whatever the name is)
Oct 30 20:46:27 <TAsn> mrmoku, and engage + comp
Oct 30 20:46:35 <TAsn> mrmoku, other than that, super-stock.
Oct 30 20:46:41 <TAsn> mrmoku, keeping myself up to date though.
Oct 30 20:50:37 <mrmoku> TAsn: how do you get a good clock into engage?
Oct 30 20:51:01 <mrmoku> and systray is flakey there too
Oct 30 20:51:07 <mrmoku> icons not drawn always correctly
Oct 30 20:51:39 <TAsn> mrmoku, no idea what you are talking about systray
Oct 30 20:51:46 <TAsn> engage: just add a gadget there, should work, I think.
Oct 30 20:51:50 <TAsn> I use both a shelf and engage
Oct 30 20:51:56 <mrmoku> yeah... I get my nm-applet in there
Oct 30 20:52:08 <mrmoku> but not as nice as in the ibar or whatever that is
Oct 30 20:52:16 <mrmoku> the icon is not always drawn correctly
Oct 30 20:52:31 <mrmoku> but the bigger problem is the clock
Oct 30 20:52:46 <mrmoku> I need a clock :)
Oct 30 20:53:45 <TAsn> can't you put the default clock?
Oct 30 20:53:50 <GNUtoo|laptop> task-x11-servers fails
Oct 30 20:54:13 <mrmoku> TAsn: I can put both clocks... t_clock and the other one
Oct 30 20:54:20 <mrmoku> but they're almost not readable :P
Oct 30 20:54:24 <mrmoku> too small for my old eyes
Oct 30 20:54:30 <GNUtoo|laptop> ExpansionError: Failure expanding variable SUMMARY, expression was ${SUMMARY} - Debugging files which triggered exception Exception: variable SUMMARY references itself!
Oct 30 20:54:31 <GNUtoo|laptop> hmmm
Oct 30 20:54:32 <TAsn> mrmoku, scale the interface up
Oct 30 20:54:38 <TAsn> or override their icon size
Oct 30 20:54:39 <GNUtoo|laptop> it didn't happen on armv7
Oct 30 20:54:50 <TAsn> mrmoku, btw, default clock (set as digital)
Oct 30 20:54:53 <TAsn> is freaking huge
Oct 30 20:55:05 <mrmoku> TAsn: ahh... I might have selected the wrong scaling on first start
Oct 30 20:55:06 <mrmoku> hmm
Oct 30 20:55:19 <mrmoku> GNUtoo|laptop: never seen that
Oct 30 20:55:39 <TAsn> mrmoku, really though, default clock is HUGE.
Oct 30 20:57:06 <mrmoku> but not within engage for me
Oct 30 20:58:02 <TAsn> possibly, no idea.
Oct 30 21:01:15 <lindi-> GNUtoo|laptop: I think I figured out the alsa issue with help from a friend :)
Oct 30 21:03:02 <GNUtoo> oh nice!!!!
Oct 30 21:03:12 <mrmoku> GNUtoo: works?
Oct 30 21:03:20 <GNUtoo> no I was telling nice for lindi- 
Oct 30 21:03:25 <mrmoku> ahh, ok :P
Oct 30 21:03:27 <GNUtoo> mrmoku, I cannot compile it
Oct 30 21:03:35 <GNUtoo> I'm stufk with the error I told befoer
Oct 30 21:11:45 <GNUtoo> mrmoku, I cleansstate and retry
Oct 30 21:15:43 <GNUtoo> mrmoku, doing shr-lite-image
Oct 30 21:16:34 <mrmoku> TAsn: http://build.shr-project.org/tests/mrmoku/shot.jpg
Oct 30 21:16:37 <mrmoku> GNUtoo: ok
Oct 30 21:17:28 <TAsn> wtf is this ugly gray? :P
Oct 30 21:17:29 <mrmoku> TAsn: see the one in engage is quite small :-P
Oct 30 21:17:30 <GNUtoo> mrmoku, an enlightenment terminal?
Oct 30 21:17:34 <TAsn> mrmoku, tiny :|
Oct 30 21:17:50 <TAsn> mrmoku, ahh, maybe engage only supports square gadgets or something?
Oct 30 21:17:53 <TAsn> duno ;\
Oct 30 21:18:22 <mrmoku> ok :/
Oct 30 21:18:30 <mrmoku> GNUtoo: my laptop... switching to e
Oct 30 21:18:47 <GNUtoo> ok
Oct 30 21:24:13 <GNUtoo> mrmoku, opkg updating and opkg upgrading
Oct 30 21:37:04 <GNUtoo> mrmoku, I'm not sure it got updated
Oct 30 21:37:12 <GNUtoo> mrmoku, but it doesn't fix it
Oct 30 21:37:34 <mrmoku> hmm
Oct 30 21:37:50 <mrmoku> opkg remove -force-depends and reinstall it to be sure?
Oct 30 21:38:18 <GNUtoo> ok
Oct 30 21:38:45 <mrmoku> TAsn: does one have to NULL a pointer after evas_object_del ?
Oct 30 21:38:57 <GNUtoo> it got updated
Oct 30 21:39:09 <GNUtoo|laptop> shr-e-gadgets - 0.0.0+gitr3+f21862225506b1fb998a74122662868f912e62e0-r12 - shr-e-gadgets version 0.0.0+gitr3+f21862225506b1fb998a74122662868f912e62e0-r12
Oct 30 21:39:30 <GNUtoo|laptop> and I lost the battery indicator
Oct 30 21:39:44 <mrmoku> huh?
Oct 30 21:39:45 <TAsn> mrmoku, probably.
Oct 30 21:39:48 <TAsn> mrmoku, it's freed
Oct 30 21:39:50 <GNUtoo|laptop> so my fix is better I guess
Oct 30 21:39:50 <TAsn> it shouldn't be used
Oct 30 21:39:55 <mrmoku> ok
Oct 30 21:40:00 <mrmoku> GNUtoo|laptop: what is your fix?
Oct 30 21:40:06 <GNUtoo|laptop> for battery indicator I mean that:
Oct 30 21:40:20 <GNUtoo|laptop> root@om-gta02:~# apm
Oct 30 21:40:20 <GNUtoo|laptop> -1% - ac
Oct 30 21:40:30 <GNUtoo|laptop> commenting stuff
Oct 30 21:40:36 <GNUtoo|laptop> It has to be tested more tough
Oct 30 21:40:36 <mrmoku> ok, that's a different story though
Oct 30 21:40:42 <mrmoku> diff?
Oct 30 21:40:51 <mrmoku> brb
Oct 30 21:41:00 <GNUtoo|laptop> GNUtoo|laptop>  // evas_object_del(tasklist_win);
Oct 30 21:41:01 <GNUtoo|laptop> <GNUtoo|laptop>  // winlist_free_if_not_null();
Oct 30 21:41:22 <GNUtoo|laptop> I don't know which one of both is the right one tough
Oct 30 21:41:25 <GNUtoo|laptop> I can look
Oct 30 21:41:31 <GNUtoo|laptop> if you tell me to look
Oct 30 21:42:30 <[Rui]> back
Oct 30 21:42:59 <GNUtoo|laptop> [Rui], I got a fix:
Oct 30 21:43:12 <[Rui]> hey!
Oct 30 21:43:18 <[Rui]> that's good!
Oct 30 21:43:23 <GNUtoo|laptop> [Rui], commenting theses 2 lines fixes it:
Oct 30 21:43:24 <GNUtoo|laptop> evas_object_del(tasklist_win);
Oct 30 21:43:30 <GNUtoo|laptop> winlist_free_if_not_null();
Oct 30 21:43:33 <GNUtoo|laptop> in that function
Oct 30 21:43:41 <GNUtoo|laptop> on_win_select
Oct 30 21:43:45 <[Rui]> hms...
Oct 30 21:43:48 <GNUtoo|laptop> do you know why?
Oct 30 21:43:53 <GNUtoo|laptop> mrmoku, tried a fix but failed
Oct 30 21:43:55 <[Rui]> let me look at the code
Oct 30 21:43:56 <GNUtoo|laptop> my fix is better
Oct 30 21:44:13 <GNUtoo|laptop> I've not tested which one of thoses 2 is the problem
Oct 30 21:44:13 <[Rui]> loosing that evas_object_del could mean a memory leak
Oct 30 21:44:25 <GNUtoo|laptop> so I'll try with it
Oct 30 21:44:28 <GNUtoo|laptop> let me try
Oct 30 21:45:23 <[Rui]> hms...
Oct 30 21:45:37 <[Rui]> I'd say the window with the list of windows would not go away
Oct 30 21:46:13 <GNUtoo|laptop> hmmm
Oct 30 21:46:32 <GNUtoo|laptop> evas_object_del uncommented creates the bug again
Oct 30 21:46:39 <GNUtoo|laptop> I've looked at memory consumation
Oct 30 21:46:42 <GNUtoo|laptop> it seem constant
Oct 30 21:46:48 <GNUtoo|laptop> (with my fix)
Oct 30 21:47:50 <[Rui]> did the window go away?
Oct 30 21:47:51 <GNUtoo|laptop> the countrary still works
Oct 30 21:47:57 <GNUtoo|laptop> window go away?
Oct 30 21:48:03 <GNUtoo|laptop> it works like before with my fix
Oct 30 21:48:09 <[Rui]> the window with the list of windows
Oct 30 21:48:10 <GNUtoo|laptop> the new fix is commenting only that tough:
Oct 30 21:48:14 <GNUtoo|laptop> yes of course
Oct 30 21:48:20 <[Rui]> wird
Oct 30 21:48:20 <GNUtoo|laptop> evas_object_del(tasklist_win);
Oct 30 21:48:33 <GNUtoo|laptop> that is the problem( evas_object_del(tasklist_win); )
Oct 30 21:48:46 <GNUtoo|laptop> commenting that makes the whole thing work
Oct 30 21:49:07 <[Rui]> great. cut it by all means.
Oct 30 21:49:17 <GNUtoo|laptop> what do you mean
Oct 30 21:49:22 <GNUtoo|laptop> I comment and push?
Oct 30 21:49:40 <[Rui]> yeah, comment with a WTF???? on it.
Oct 30 21:49:43 <[Rui]> :)
Oct 30 21:50:05 <[Rui]> must be some unintended consequence
Oct 30 21:50:37 <GNUtoo|laptop> should I revert mrmoku's patch?
Oct 30 21:51:07 <GNUtoo|laptop> http://git.shr-project.org/git/?p=shr-e-gadgets.git;a=blobdiff;f=src/softkey_quickpanel/main.c;h=2d681a9c4bc0d961a2c8bf2b3e6e8f62570fb11c;hp=6942bfa5de2e06ae046e282831dc319c7d3fea7e;hb=f21862225506b1fb998a74122662868f912e62e0;hpb=8859f44ae662f1b15896b8f5bf42eab9839d18e6
Oct 30 21:52:20 <GNUtoo|laptop> ^^^ mrmoku's patch
Oct 30 21:53:48 <GNUtoo|laptop> [Rui], should I revert mrmoku's patch?
Oct 30 21:54:01 <GNUtoo|laptop> because or it's useless or it could create unintended issues
Oct 30 21:55:33 <GNUtoo|laptop> mrmoku, I don't have access to the repo
Oct 30 21:55:37 <[Rui]> what I fear is that removing evas_object_del(tasklist_win); will cause a memory leak, but *maybe* it won't.
Oct 30 21:55:56 <GNUtoo|laptop> [Rui], I've looked and it seem not to cause one
Oct 30 21:55:57 <[Rui]> mrmoku's change doesn't harm :)
Oct 30 21:56:01 <GNUtoo|laptop> ok
Oct 30 21:56:01 <GNUtoo|laptop> nice
Oct 30 21:56:13 <GNUtoo|laptop> mrmoku, could you give me access or push a commit for me
Oct 30 21:56:25 <GNUtoo|laptop> altough please do credit me that time
Oct 30 21:56:39 <[Rui]> I can commit :)
Oct 30 21:57:24 <[Rui]> but I think I can't give access :|
Oct 30 21:57:41 <GNUtoo|laptop> just credit me in the commit message for the bug search
Oct 30 21:57:45 <[Rui]> of course
Oct 30 21:58:20 <GNUtoo|laptop> thanks
Oct 30 21:58:42 <mrmoku> GNUtoo|laptop: you have access
Oct 30 21:58:56 <GNUtoo|laptop> now yes
Oct 30 21:58:57 <GNUtoo|laptop> thanks
Oct 30 21:59:04 <[Rui]> then commit
Oct 30 21:59:16 <[Rui]> I was still trying to understand why that del would be a problem :)
Oct 30 21:59:46 <[Rui]> while letting my ice cream dessert slowly melt
Oct 30 22:02:24 <DocScrutinizer> :-D
Oct 30 22:05:38 <Yoram> Does anyone know what times (if at all) can I fond Morfix here ?
Oct 30 22:07:18 <DocScrutinizer> ~seen morfix
Oct 30 22:07:25 <apt> i haven't seen 'morfix', DocScrutinizer
Oct 30 22:07:29 <DocScrutinizer> ~seen morphis
Oct 30 22:07:29 <apt> morphis <~morphis@dslb-088-070-132-204.pools.arcor-ip.net> was last seen on IRC in channel #openmoko-cdevel, 4h 22m 10s ago, saying: 'GarthPS: damn it I builded the wrong kernel'.
Oct 30 22:08:49 <CIA-5> SHR: 03GNUtoo 07shr-e-gadgets * rf305f276fd22 10/src/softkey_quickpanel/main.c: softkey_quickpanel: Fix SHR bug #1490
Oct 30 22:09:06 <GNUtoo|laptop> Yoram, you mean morphis?
Oct 30 22:09:21 <GNUtoo|laptop> he was there not so long ago
Oct 30 22:17:36 <[Rui]> did mrmoku's patch *fix* the crash?
Oct 30 22:17:46 <CIA-5> SHR: 03GNUtoo 07meta-smartphone * ra17b856a9c00 10/meta-samsung/conf/machine/crespo.conf: meta-samsung: crespo: add SERIAL_CONSOLE
Oct 30 22:17:51 <CIA-5> SHR: 03GNUtoo 07meta-smartphone * r4339434e7bd7 10/meta-shr/recipes-shr/shr/shr-e-gadgets_git.bb: meta-shr: shr-e-gadgets: fix SHR bug #1490
Oct 30 22:18:01 <CIA-5> SHR: 03GNUtoo 07meta-smartphone * r80f67dce6264 10/meta-shr/recipes-shr/3rdparty/intone_svn.bb: meta-shr: intone: fix LICENSE and add LIC_FILES_CHKSUM
Oct 30 22:18:10 <GNUtoo|laptop> [Rui], mrmoku's patch alone didn't fix the crash
Oct 30 22:18:17 <GNUtoo|laptop> my patch alone did
Oct 30 22:18:31 <GNUtoo|laptop> now I'll build a new rootfs and reflash
Oct 30 22:18:56 <[Rui]> I believe I was told evas_object_del zeroed the pointer
Oct 30 22:19:20 <[Rui]> maybe I was told wrong :(
Oct 30 22:19:27 <[Rui]> or I understood wrong
Oct 30 22:19:42 <GNUtoo|laptop> or maybe mrmoku's patch is useless but not harmfull
Oct 30 22:19:48 <GNUtoo|laptop> so let's keep his patch
Oct 30 22:20:03 <[Rui]> it probably crashed when creating the window list, not when deleting it?
Oct 30 22:20:47 <GNUtoo|laptop> I don't know enough to tell, I just tracked the bug and found a workarround for it
Oct 30 22:20:52 <[Rui]> it probably crashed here: 374         if(tasklist_win) evas_object_del(tasklist_win);
Oct 30 22:21:21 <GNUtoo|laptop> no
Oct 30 22:21:27 <GNUtoo|laptop> it crashed when deleting it
Oct 30 22:21:31 <GNUtoo|laptop> that part was fine
Oct 30 22:21:38 <[Rui]> Yes, I have a *delete* there :)
Oct 30 22:21:44 <GNUtoo|laptop> ah ok
Oct 30 22:21:47 <[Rui]> the other delete doesn't make sense for crashing
Oct 30 22:21:50 <[Rui]> this one *could*
Oct 30 22:21:55 <GNUtoo|laptop> ok
Oct 30 22:22:01 <[Rui]> if at that moment tasklist_win is now a pointer to garbage
Oct 30 22:22:27 <GNUtoo|laptop> I'll try without 
Oct 30 22:22:57 <GNUtoo|laptop> I've booting issues after installing bq27200 tough
Oct 30 22:23:10 <GNUtoo|laptop> I guess I need to reflash
Oct 30 22:23:14 <[Rui]> but if it was so, mrmoku's patch should have been enough to correct as well.
Oct 30 22:23:20 <GNUtoo> ok
Oct 30 22:23:26 <GNUtoo> it was not
Oct 30 22:23:29 <GNUtoo> I tested his patch
Oct 30 22:31:27 <Yoram> I ment Morphis, yes, thanks for the answer and sorry for the mistake
Oct 30 22:33:00 <GNUtoo> np
Oct 30 22:33:31 <mrmoku> [Rui]: I just checked evas source... it does *not* NULL it
Oct 30 22:38:07 <[Rui]> mrmoku: yeah, was checking it as well
Oct 30 22:38:35 <[Rui]> but I'm almost 100% sure it crashes there, at that line 374 if
Oct 30 22:38:50 <[Rui]> thing is: why did it not crash *before*?
Oct 30 22:39:11 <[Rui]> I wonder if by the time of shr-unstable's efl something *did* cause it to be NULLed?
Oct 30 22:40:11 <mrmoku> [Rui]: I think that depends into what garbage it points at the time
Oct 30 22:40:32 <[Rui]> mrmoku: yeah, but it's 100% consistent now, while it was as well before :)
Oct 30 22:40:34 <mrmoku> evas_object_del does it's smart check to see if it is a correct evas pointer if I understood correctly
Oct 30 22:40:39 <[Rui]> ie, always crash now, didn't before
Oct 30 22:40:56 <mrmoku> yeah
Oct 30 22:41:07 <mrmoku> probably the real bug is still somewhere else :)
Oct 30 22:43:06 <[Rui]> mrmoku: I'm inclined to the "unintended consequences" theory
Oct 30 22:43:18 <[Rui]> <Sachiel> maybe 1.0 had a bug that got fixed and now you are noticing it
Oct 30 22:44:02 <mrmoku> yeah, I'm on that thinking too
Oct 30 22:44:17 <mrmoku> something got *fixed* somewhere in EFL exposing the bug now
Oct 30 22:44:20 <mrmoku> and not before
Oct 30 22:44:27 <[Rui]> just because it's so consistent
Oct 30 22:44:37 <[Rui]> mrmoku: btw, speaking of bugs
Oct 30 22:45:43 <[Rui]> mrmoku: http://pastebin.com/tzKYZHk9
Oct 30 22:46:38 <[Rui]> that's with a bb -b myshrgadgets.bb which is the same as the one on shr-core but pointing to a tar.gz rather than a git repo
Oct 30 22:46:56 <mrmoku> [Rui]: what does ecore_x_netwm_client_active_request do?
Oct 30 22:47:58 <mrmoku> [Rui]: you can't do that... have to remove SRCPV then
Oct 30 22:48:07 <mrmoku> as SRCPV is for VCS
Oct 30 22:48:09 <mrmoku> like git
Oct 30 22:48:09 <[Rui]> there's no SRCPV there.
Oct 30 22:48:14 <[Rui]> I think
Oct 30 22:48:19 <[Rui]> yeah, only SRCREV
Oct 30 22:48:23 <mrmoku> ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception RuntimeError: maximum recursion depth exceeded
Oct 30 22:48:38 <mrmoku> yeah... SRCREV too
Oct 30 22:48:48 <mrmoku> the tar has no rev :)
Oct 30 22:49:18 <[Rui]> ok
Oct 30 22:49:58 <[Rui]> but I have that with SRCREV commented out too
Oct 30 22:50:39 <mrmoku> [Rui]: hmm... the local build thing did not work for you?
Oct 30 22:51:07 <[Rui]> mrmoku: it's too dirty, infects the local repo directory with the compilation garbage
Oct 30 22:51:28 <mrmoku> [Rui]: git clean -d -f is your friend ;)
Oct 30 22:51:37 <[Rui]> It's "uncleeeeeeaaaan" (think Diamanda Galas on Plague Mess)
Oct 30 22:52:22 <[Rui]> mrmoku: yeah, but it's a lot nicer to make dist-gzip ; mv .. ... then bb from a file as if it was a release (I usually find all sorts of bugs like that)
Oct 30 22:53:25 <mrmoku> [Rui]: ok... and you have a PV set in your bb?
Oct 30 22:53:35 <GNUtoo> mrmoku, for the dbus fix what should I do?
Oct 30 22:53:40 <GNUtoo> bitbake -c cleansstate dbus
Oct 30 22:53:41 <[Rui]> damn, it's there, /"$#&%"$#"#
Oct 30 22:53:43 <GNUtoo> and rebuild it?
Oct 30 22:53:50 <mrmoku> GNUtoo: yup, that should do it
Oct 30 22:53:53 <GNUtoo> ok
Oct 30 22:54:19 <[Rui]> yeah, I have, it has a ${SRCPV} in it, but I thought not defining it (just using it) would amount to being equal to ""
Oct 30 22:54:46 <mrmoku> :)
Oct 30 22:55:07 <[Rui]> just by having the variable present it then expects more stuff to happen?
Oct 30 22:55:12 <mrmoku> deepest python magic going on there :P
Oct 30 22:56:48 <[Rui]> o. m. g.
Oct 30 22:59:24 <GNUtoo> do you need help?
Oct 30 22:59:43 <GNUtoo> btw what should I reinstall on target with reguards to dbus?
Oct 30 22:59:58 <GNUtoo> or I'll look on workdir to know which package it made
Oct 30 23:02:29 <GNUtoo> did you do inherit gitsomething
Oct 30 23:02:42 <GNUtoo> like inherit gitrev
Oct 30 23:04:04 <[Rui]> GNUtoo: me?
Oct 30 23:04:10 <[Rui]> I copied the recipe and changed it
Oct 30 23:04:23 <GNUtoo> yes
Oct 30 23:04:29 <GNUtoo> gitrev is for git
Oct 30 23:04:37 <GNUtoo> can you show me again your recipe?
Oct 30 23:05:41 <[Rui]> GNUtoo: http://pastebin.com/P3bbrsNQ
Oct 30 23:05:51 <[Rui]> it's not expanding the tar ball
Oct 30 23:06:24 <[Rui]> at least the ${S} seems empty
Oct 30 23:06:54 <GNUtoo> I'll try, give me one minute
Oct 30 23:08:08 <[Rui]> ERROR: Function 'shr-e-gadgets: LIC_FILES_CHKSUM points to an invalid file: /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/shr-e-gadgets-0.1-r12/shr-e-gadgets-0.1/shr-e-gadgets/COPYING' failed
Oct 30 23:08:28 <GNUtoo> ok let me try
Oct 30 23:09:41 <[Rui]> GNUtoo: there's a bug here: file://${S}/${PN}COPYING missing /, should be file://${S}/COPYING but it doesn't matter, as the result's the same
Oct 30 23:09:52 <[Rui]> the tar ball isn'texpanded
Oct 30 23:11:06 <[Rui]> this is the correct one: http://pastebin.com/KJrEJumv
Oct 30 23:11:14 <GNUtoo> and where can I find the tarball?
Oct 30 23:11:32 <[Rui]> you can make dist-gzip in the shr-e-gadgets git dir
Oct 30 23:11:59 <GNUtoo> ok
Oct 30 23:14:40 <GNUtoo> what's your filename of the recipe?
Oct 30 23:15:27 <[Rui]> mkdir /myrecipes, cp ... /myrecipes/shr-e-gadgets_git.bb
Oct 30 23:15:27 <GNUtoo> shr-e-gadget.bb?
Oct 30 23:15:30 <GNUtoo> ok
Oct 30 23:15:37 <GNUtoo> ahh git....
Oct 30 23:15:43 <GNUtoo> maybe that's your problem
Oct 30 23:15:48 <GNUtoo> try without _git
Oct 30 23:15:57 <[Rui]> huh?
Oct 30 23:16:23 <[Rui]> no change
Oct 30 23:16:27 <GNUtoo> ok 
Oct 30 23:16:30 <[Rui]> gladly, though
Oct 30 23:16:33 <GNUtoo> let me setup the whole thing
Oct 30 23:20:09 <mrmoku> [Rui]: so... what is that ecore_x_netwm_client_active_request for?
Oct 30 23:20:13 * mrmoku thinks that's the one
Oct 30 23:20:23 <[Rui]> mrmoku: sorry, can't remember
Oct 30 23:20:58 <mrmoku> my theory is that evas deletes the attached x window and that request goes boom
Oct 30 23:22:26 <GNUtoo> ok I've setup a meta-local
Oct 30 23:22:28 <GNUtoo> let's see
Oct 30 23:22:32 <GNUtoo> I'm used to that stuff
Oct 30 23:22:44 <GNUtoo> I worked for a company where I had to do stuff like that
Oct 30 23:23:44 * mrmoku is going to bed meanwhile
Oct 30 23:23:49 <mrmoku> gnight and have fun :-)
Oct 30 23:23:51 <GNUtoo> ok
Oct 30 23:25:12 <GNUtoo> [Rui], do_configure fails
Oct 30 23:25:23 <GNUtoo|laptop> | configure.ac:16: error: possibly undefined macro: AC_C___ATTRIBUTE__
Oct 30 23:26:11 <[Rui]> GNUtoo: mine didn't get to that: + echo 'NOTE: nothing to configure'
Oct 30 23:26:28 <[Rui]> all the tests for the presence of "configure" failed
Oct 30 23:26:41 <GNUtoo> [Rui], I modified it a bit
Oct 30 23:26:50 <GNUtoo> I'll send you a tarball
Oct 30 23:30:41 <GNUtoo> [Rui], are you good in autotools?
Oct 30 23:31:02 <[Rui]> not on the black magic parts
Oct 30 23:32:39 <GNUtoo> on enlightenment part
Oct 30 23:33:16 <GNUtoo|laptop> EFL_WITH_BIN doesn't get expanded
Oct 30 23:33:41 <GNUtoo> I'll remove 
Oct 30 23:36:54 <GNUtoo> or rather comment with dnl
Oct 30 23:37:32 <GNUtoo> now it starts compiling
Oct 30 23:38:27 <GNUtoo> my comment created an error
Oct 30 23:38:37 <GNUtoo> let me fix it
Oct 30 23:41:08 <GNUtoo> maybe there is an easier way
Oct 30 23:41:32 <GNUtoo> basically it didn't find edje_cc
Oct 30 23:41:40 <GNUtoo> because I commented that in configure.ac:
Oct 30 23:41:57 <GNUtoo|laptop> EFL_WITH_BIN([edje], [edje-cc], [edje_cc])
Oct 30 23:47:00 <GNUtoo> [Rui], do you want a tarball now?
Oct 30 23:50:33 <[Rui]> ok
Oct 30 23:53:24 <GNUtoo> ok was for yes?
Oct 30 23:58:31 <GNUtoo> [Rui], ok was for yes?
Oct 30 23:58:38 <[Rui]> yes :)
Oct 30 23:58:41 <GNUtoo> ok
Oct 31 00:00:55 <GNUtoo|laptop> http://gnutoo.homelinux.org/downloads/people/rui/meta-local.tar.bz2
Oct 31 00:04:09 <GNUtoo|laptop> to build add it to your repos list
Oct 31 00:04:12 <GNUtoo|laptop> and do that:
Oct 31 00:04:14 <GNUtoo|laptop> bitbake shr-e-gadgets-0.1-r0
Oct 31 00:07:25 <[Rui]> you mean BBLAYERs?
Oct 31 00:07:29 <GNUtoo> yes
Oct 31 00:07:33 <GNUtoo> bblayers.conf
Oct 31 00:07:47 <GNUtoo> I'm trying to pass edje_cc to autotools
Oct 31 00:07:56 <GNUtoo> if I succeed I think it should work
Oct 31 00:10:24 <[Rui]> GNUtoo: what are you doing awaken? go to bed! :)
Oct 31 00:10:32 <GNUtoo> ok
Oct 31 00:12:22 <[Rui]> GNUtoo: did you succeed? :)
Oct 31 00:12:59 <[Rui]> I can in my conf.local do $BBLAYERS += "path" right?
Oct 31 00:13:06 <GNUtoo> no idea
Oct 31 00:13:12 <GNUtoo> I just put that to bblayer.conf
Oct 31 00:13:43 <[Rui]> ok
Oct 31 00:15:20 <GNUtoo> ah it passed it but it fails after it
Oct 31 00:15:30 <GNUtoo|laptop> change to EXTRA_OEMAKE = "EDJE_CC=${STAGING_BINDIR_NATIVE}/edje_cc"
Oct 31 00:16:56 <GNUtoo> ohhh
Oct 31 00:16:59 <GNUtoo> it fails on the rest
Oct 31 00:17:06 <GNUtoo> shr_elm_softkey built
Oct 31 00:17:52 <GNUtoo> [Rui], as soon as you've set it up I go to bed
Oct 31 00:17:57 <[Rui]> setting it up
Oct 31 00:18:18 <[Rui]> change what? 
Oct 31 00:18:27 <[Rui]> I have to add that to the recipe or someplace else?
Oct 31 00:18:31 <GNUtoo> EXTRA)_OECONF
Oct 31 00:18:34 <GNUtoo> oops
Oct 31 00:18:37 <GNUtoo> EXTRA_OECONF
Oct 31 00:18:44 <GNUtoo> I can resend a tarball if you want
Oct 31 00:18:52 <[Rui]> no need :)
Oct 31 00:19:06 <GNUtoo> see meta-smartphone
Oct 31 00:19:18 <GNUtoo> put it in the same dir
Oct 31 00:20:56 <[Rui]> meta-smartphone/meta-local ?
Oct 31 00:20:58 <GNUtoo> then tomorrow you'll ask JaMa for a better fix to get that autotools thing right
Oct 31 00:20:59 <GNUtoo> no
Oct 31 00:21:04 <GNUtoo> same dir means
Oct 31 00:21:07 <GNUtoo> ls:
Oct 31 00:21:20 <GNUtoo> meta-smartphone meta-openembedded etc... and meta-local
Oct 31 00:21:26 <[Rui]> ok, it's what I did
Oct 31 00:21:53 <[Rui]> parsing recipes
Oct 31 00:21:55 <GNUtoo> then just pastebin me your bblayers.conf
Oct 31 00:21:56 <GNUtoo> ok
Oct 31 00:22:05 <JaMa> what doesn't work on --with-edje-cc= ?
Oct 31 00:22:26 <GNUtoo> JaMa, I did nasty things
Oct 31 00:22:58 <GNUtoo> | configure.ac:16: error: possibly undefined macro: AC_C___ATTRIBUTE__
Oct 31 00:23:07 <GNUtoo> and EFL_WITH_BIN([edje], [edje-cc], [edje_cc])
Oct 31 00:23:12 <GNUtoo> were making problem in a recipe
Oct 31 00:23:23 <GNUtoo> so I commented them with dnl or removed them
Oct 31 00:23:31 <JaMa> was edje-native already built?
Oct 31 00:23:35 <GNUtoo> yes
Oct 31 00:23:59 <GNUtoo|laptop> [Rui], pastebin your recipe
Oct 31 00:24:34 <[Rui]> wait computer almost froze
Oct 31 00:24:44 <[Rui]> ERROR: Nothing PROVIDES 'shr-e-gadgets-0.1-r0'
Oct 31 00:24:45 <GNUtoo|laptop> JaMa, btw I've all batteries that don't work anymore on om-gta02
Oct 31 00:24:49 <GNUtoo|laptop> the gauge says 0
Oct 31 00:25:04 <GNUtoo|laptop> [Rui], pastebin bblayer.conf
Oct 31 00:25:34 <[Rui]> I tried adding BBLAYERS += "${TOPDIR}/meta-local" to local.conf
Oct 31 00:25:39 <[Rui]> seems like it didn't work
Oct 31 00:25:39 <GNUtoo|laptop> [Rui], mkdir meta-local
Oct 31 00:25:42 <GNUtoo|laptop> cd meta-local
Oct 31 00:25:55 <GNUtoo|laptop> tar xjpf /path/to/meta-local.tar.bz2
Oct 31 00:25:56 <JaMa> GNUtoo|laptop: because of bq driver?
Oct 31 00:26:31 <GNUtoo|laptop> both bq batteries and bl5c says 0
Oct 31 00:26:36 <GNUtoo|laptop> and they are charged
Oct 31 00:26:39 <GNUtoo|laptop> so I guess so
Oct 31 00:26:55 <[Rui]> anyone knows how to calibrate a touchscreen using evdev?
Oct 31 00:27:09 <JaMa> and what if you try platform-battery driver?
Oct 31 00:27:19 <JaMa> [Rui]: xinput-calibrator-once.sh
Oct 31 00:27:39 <GNUtoo|laptop> none are loaded automatically
Oct 31 00:27:44 <GNUtoo|laptop> not bq and not platform
Oct 31 00:27:56 <JaMa> [Rui]: and remove /etc/pointercal.xinput if you want to recalibrate from scratch
Oct 31 00:28:13 <[Rui]> jake42_: that's on gta02 or it's generic?
Oct 31 00:28:13 <GNUtoo|laptop> did I miss the cleansstate of something?
Oct 31 00:28:24 <[Rui]> JaMa: that was for you (stupid xchat)
Oct 31 00:28:28 <GNUtoo|laptop> [Rui], on all
Oct 31 00:28:43 <JaMa> [Rui]: generic for SHR
Oct 31 00:29:23 <JaMa> GNUtoo|laptop: are those 2 modules installed?
Oct 31 00:29:39 <GNUtoo|laptop> no
Oct 31 00:30:27 <[Rui]> JaMa: not on shr :) generic evdev!
Oct 31 00:30:52 <JaMa> GNUtoo|laptop: then rebuild task-base and reinstall task-machine-base
Oct 31 00:30:55 <[Rui]> ERROR: Cannot proceed with manual patch resolution - 'screen -D -m -t "$TERMWINDOWTITLE" $SHELLCMDS' not found. Check TERMCMDRUN variable.
Oct 31 00:31:00 <GNUtoo|laptop> ok thanks a lot
Oct 31 00:31:34 <[Rui]> hy does it have screen options in local.conf :)
Oct 31 00:31:48 <JaMa> [Rui]: xinput-calibrator is generic
Oct 31 00:32:10 <JaMa> [Rui]: -once.sh is only in newer versions and depends on distribution if it does install that
Oct 31 00:32:21 <JaMa> because it's in contrib or something
Oct 31 00:32:33 <[Rui]> JaMa: ok. but I don't know where it comes from
Oct 31 00:32:39 <GNUtoo|laptop> [Rui], make a pwd and a find of meta-local
Oct 31 00:33:09 <[Rui]> urgh, commenting out TERMfu results in even worse
Oct 31 00:33:35 <[Rui]> OE om-gta02@shr ~/shr-core $ find  meta-local/ -type f
Oct 31 00:33:35 <[Rui]> meta-local/recipes/shr-e-gadgets/shr-e-gadgets-0.1.tar.gz
Oct 31 00:33:35 <[Rui]> meta-local/recipes/shr-e-gadgets/configure.patch
Oct 31 00:33:35 <[Rui]> meta-local/recipes/shr-e-gadgets_0.1.bb
Oct 31 00:33:35 <[Rui]> meta-local/conf/layer.conf
Oct 31 00:34:04 <[Rui]> JaMa: doesn't appear to be present in fedora
Oct 31 00:34:30 <GNUtoo|laptop> and did you point to meta-local?
Oct 31 00:34:35 <GNUtoo|laptop> in bblayers.conf
Oct 31 00:34:44 <[Rui]> yes
Oct 31 00:34:57 <JaMa> [Rui]: http://www.freedesktop.org/wiki/Software/xinput_calibrator
Oct 31 00:35:01 <[Rui]> I hadn't before, but now I did, so it found the recipe (note: += in local.conf doesn't work)
Oct 31 00:35:12 <[Rui]> however now it breaks with TERMCMDRUN
Oct 31 00:35:26 <GNUtoo|laptop> ok
Oct 31 00:35:50 <GNUtoo|laptop> then you'll also need JaMa's help for fixing the autotools problem I had
Oct 31 00:36:01 <GNUtoo|laptop> remove the configure.patch 
Oct 31 00:36:11 <GNUtoo|laptop> beware with multiline comments
Oct 31 00:36:14 <GNUtoo|laptop> if you do:
Oct 31 00:36:19 <GNUtoo|laptop> # foo \
Oct 31 00:36:25 <GNUtoo|laptop> the \ will create an issue
Oct 31 00:36:55 <[Rui]> GNUtoo|laptop: what was your problem? that _C__ thing?
Oct 31 00:37:05 <GNUtoo|laptop> yes
Oct 31 00:37:08 <GNUtoo|laptop> and edje_cc also
Oct 31 00:37:36 <GNUtoo|laptop> <GNUtoo|laptop> | configure.ac:16: error: possibly undefined macro: AC_C___ATTRIBUTE__
Oct 31 00:37:37 <CIA-5> SHR: 03Martin.Jansa 07shr-chroot * rc4714ff58716 10/ (553 files in 55 dirs): add qemu, sudo, add runqemu-if* to sudoers.d
Oct 31 00:37:38 <GNUtoo|laptop> and:
Oct 31 00:37:41 <GNUtoo|laptop> <GNUtoo|laptop> EFL_WITH_BIN([edje], [edje-cc], [edje_cc])
Oct 31 00:38:11 <[Rui]> argh, I gotta go :(
Oct 31 00:38:32 <[Rui]> GNUtoo|laptop: don't know about you, but I have a meeting in 9 hours |
Oct 31 00:38:37 <[Rui]> damn
Oct 31 00:38:49 <GNUtoo|laptop> [Rui], ok
Oct 31 00:39:03 <[Rui]> at least thanks to GNUtoo|laptop that nasty bug was fixed.
Oct 31 00:39:04 * JaMa in 7
Oct 31 00:39:24 <[Rui]> so for me it was 2 in three targets for this night
Oct 31 00:39:29 * GNUtoo|laptop has a "bridge" until tuesday
Oct 31 00:39:41 <[Rui]> GNUtoo|laptop: you bastard! :)
Oct 31 00:39:47 <[Rui]> GNUtoo|laptop: we also use that term
Oct 31 00:40:09 <GNUtoo|laptop> tuesday included
Oct 31 00:40:24 <GNUtoo|laptop> note that I helped fix the bug
Oct 31 00:40:34 <[Rui]> GNUtoo|laptop: I think you fixed it :)
Oct 31 00:40:36 <[Rui]> afaict
Oct 31 00:40:41 <[Rui]> gotta go
Oct 31 00:40:53 <GNUtoo|laptop> (I told that for the <[Rui]> GNUtoo|laptop: you bastard! :) )
Oct 31 00:40:57 <GNUtoo|laptop> ok bye
Oct 31 00:40:59 <JaMa> gnight
Oct 31 00:41:17 <[Rui]> still have a bottle of milk and antibiotic to give my baby before going to bed, hope he finds it so conforting he falls down asleep immediately or I'm in a world of trouble :
Oct 31 00:41:40 <[Rui]> GNUtoo|laptop: I just envy your bridge :)
Oct 31 00:41:47 <GNUtoo|laptop> ok
Oct 31 00:42:12 <[Rui]> GNUtoo|laptop: if we had it (tania and I) lilbernie would go to his school anyways so we'd be able to recover from his week of ear issues
Oct 31 00:42:22 <GNUtoo|laptop> ok
Oct 31 00:42:39 <GNUtoo|laptop> anyway I used my bridge to do stuff with FSO+SHR
Oct 31 00:43:16 <[Rui]> GNUtoo|laptop: they're talking about moving mid-week holidays to mondays and fridays in order to avoid bridges.
Oct 31 00:43:34 <GNUtoo|laptop> ah ok ouch
Oct 31 00:43:35 <[Rui]> but here the only people who give bridges are the state
Oct 31 00:43:43 <GNUtoo|laptop> ok
Oct 31 00:43:48 <[Rui]> so if they complain so much, all they have to do is simply NOT GIVE THEM :)
Oct 31 00:44:29 <[Rui]> I just think it's a smokescreen, so people talk about that and not the gazillion other bad stuff they're doing while *not* fixing our financial issues while pretending to do so at Troika level.
Oct 31 00:44:43 <GNUtoo|laptop> indeed
Oct 31 00:45:48 <[Rui]> and here I let myself be distracted... c ya (for good, now) :)
Oct 31 00:46:11 <GNUtoo|laptop> ok bye
Oct 31 02:45:31 <GNUtoo> JaMa, hi
Oct 31 02:45:38 <GNUtoo> some issues with battery
Oct 31 02:45:58 <GNUtoo> 1) when I plug the charger or an usb cable  it freeze the device
Oct 31 02:46:14 <GNUtoo> 2) how to make the new udev go into the images
Oct 31 02:46:38 <GNUtoo> 3)maybe I've battery gauges issues too
Oct 31 02:46:42 <GNUtoo> not sure
Oct 31 02:46:51 <GNUtoo> anyway I'll push a revert of mrmoku's patch
Oct 31 02:47:26 <GNUtoo> and damn moskitoes
Oct 31 02:53:50 <CIA-5> SHR: 03GNUtoo 07shr-e-gadgets * r84733340680e 10/src/softkey_quickpanel/main.c: Revert "softkey_quickpanel: NULL the tasklist pointer after evas_object_del"
Oct 31 02:58:50 <CIA-5> SHR: 03GNUtoo 07meta-smartphone * rac7fa4951802 10/meta-shr/recipes-shr/shr/shr-e-gadgets_git.bb: meta-shr: shr-e-gadgets: fix tasklist window proliferation
**** ENDING LOGGING AT Mon Oct 31 02:59:56 2011