**** BEGIN LOGGING AT Tue Oct 12 02:59:57 2010
Oct 12 05:26:15 <creeper_> moin
Oct 12 05:27:30 <JaMa> moin
Oct 12 05:52:10 <mrmoku> moin
Oct 12 05:52:32 <mrmoku> playya: thanks for your introspection diff
Oct 12 06:46:24 <JaMa> mickey|office: here is one cornucopia patch for you http://patchwork.dev.bearstech.com/patch/788/ - I have no idea if it's right way
Oct 12 06:47:49 <Heinervdm> in some files there are multiple --vapidir
Oct 12 06:47:51 <JaMa> mrmoku: does that diff work for you?
Oct 12 06:48:29 <mickey|office> JaMa: what's that supposed to fix?
Oct 12 06:48:39 <JaMa> Heinervdm: in some of them, there were multiple even before (so I guess it's possible)..
Oct 12 06:48:49 <Heinervdm> ok
Oct 12 06:48:58 <JaMa> mickey|office: I don't know, just seen it in our patchwork..
Oct 12 06:49:19 <mickey|office> JaMa: hmm, ok, i don't see the benefit, to be honest.
Oct 12 06:49:21 <JaMa> and the author afaik is not here (only on shr ML)
Oct 12 06:49:58 <mickey|office> ok, i'll ask there
Oct 12 06:50:05 <JaMa> thx
Oct 12 06:50:20 <Heinervdm> As i understand it's that one can install to another prefix and use vapi's from there
Oct 12 06:50:39 <mickey|office> done
Oct 12 06:51:11 <mickey|office> hmm, for multiple installations of vala?
Oct 12 06:51:17 <mickey|office> in that case you better use XDG_DATA_DIRS
Oct 12 06:51:28 <mickey|office> vala looks there
Oct 12 06:51:36 <Heinervdm> no idea, lets wait for his answer
Oct 12 06:51:39 <mickey|office> yep
Oct 12 07:08:55 <mrmoku> JaMa: did not try it yet
Oct 12 07:10:07 <JaMa> mrmoku: even gir still doesn't build for me (executing armv4t binary instead native one)
Oct 12 07:14:03 <mickey|office> gir needs a couple of patches
Oct 12 07:14:16 <mickey|office> earlier this year Graeme Gregory tried to add it
Oct 12 07:14:26 <mickey|office> the repository contains some stuff that may help
Oct 12 07:14:33 <JaMa> mrmoku: and also breaks gobject-introspection-native build (because it's calling g-ir-scanner before staging it.. /OE/tmpdir-shr/sysroots/x86_64-linux/usr/bin/g-ir-scanner: No such file or directory)
Oct 12 07:14:36 <mickey|office> it's gone now, so you have to find out the exact version
Oct 12 07:14:59 <JaMa> mickey|office: playya sent few patches to oe ML
Oct 12 07:16:46 <mickey|office> ok, perhaps they contain the same things
Oct 12 07:17:07 <JaMa> and http://www.xora.org.uk/cgi-bin/cgit.cgi/openembedded/commit/?h=xora/autoconf-2.65&id=5b638e96b67aadc574778abde32518b56fe48316
Oct 12 07:59:10 <daniele_athome> morning
Oct 12 08:01:48 <JaMa> moin
Oct 12 08:42:23 <zub> Guten Morgen
Oct 12 08:42:45 <mrmoku`> zub: :) 
Oct 12 08:44:57 <zub> I'm learning ;)
Oct 12 09:03:06 <daniele_athome> morning mrmoku` 
Oct 12 09:03:12 <daniele_athome> and zub too
Oct 12 09:10:34 <mrmoku`> daniele_athome: morning
Oct 12 09:14:17 <creeper_> is there a solution for the keyboard getting ever bigger with every switch of layout on shr-u? or am i the only one with that problem?
Oct 12 09:18:51 <Heinervdm> creeper_: i tried to reproduce this, and i don't have this problem
Oct 12 09:23:18 <zub> daniele_athome: morgen
Oct 12 09:23:34 <zub> creeper_: I've seen it
Oct 12 09:23:59 <vanous> creeper_: same issue here, interesting
Oct 12 09:24:05 <zub> but can't say more than that :(
Oct 12 09:28:54 <zub> btw. does GPRS work for you in unstable?
Oct 12 09:29:08 <creeper_> Heinervdm: well, it's hardly noticable after switching to full keyboard only once. i can see it a bit as the "c" of ctrl is already missing then. but cycling through 5-10 times and they keyboard is unusable
Oct 12 09:29:32 <creeper_> zub: last time i tried it did not crash e any more but it also did not connect
Oct 12 09:29:44 <creeper_> zub: i have not tested since, but there were also no updates related to it
Oct 12 09:30:09 <zub> for me it completely borks GSM... I see PIN request dialog again, enter pin, but never connect untill reboot
Oct 12 09:30:34 <creeper_> zub: ah, right. was not crashing e, it was crashing the gsm
Oct 12 09:30:48 <zub> didn't find anything useful in logs, but I wasn't looking deep enough
Oct 12 09:30:49 <creeper_> zub: but with latest updates it did not do that any more
Oct 12 09:30:56 <zub> hm
Oct 12 09:30:59 <creeper_> still no gprs though
Oct 12 09:31:19 <creeper_> but i will give it another try on my way to lunch. bad reception in my office
Oct 12 11:23:41 <creeper_> zub: tried it again just now with current shr-u and gsm still crashes apparently
Oct 12 11:24:58 <zub> do you see anything relevant in logs?
Oct 12 11:34:45 <JaMa> creeper_: current or from tests?
Oct 12 11:35:15 <papa-piet> some vala-guys here?
Oct 12 11:35:18 <creeper_> JaMa: "normal" current shr-u
Oct 12 11:35:30 <zub> JaMa: yeah, "normal" shr-u
Oct 12 11:36:01 <JaMa> ah :/
Oct 12 11:37:38 <creeper_> JaMa: is it supposed to work in the tests version?
Oct 12 11:37:43 <creeper_> JaMa: i did not dare try that so far :P
Oct 12 11:43:37 <JaMa> no tests version is known to be broken
Oct 12 11:44:08 <JaMa> but only gprs was known to be broken in "normal" version
Oct 12 11:53:20 <creeper_> JaMa: yes, i was talking about gprs. it crashes the whole gsm subsystem when trying to connect
Oct 12 11:53:32 <creeper_> JaMa: gsm itself worked as far as i know
Oct 12 11:54:18 <JaMa> creeper_: there is fix for that in cornucopia repo alredy
Oct 12 11:54:49 <JaMa> it's even build in tests version, but cannot sync to normal feeds until all other issues are resolved..
Oct 12 11:58:25 <JaMa> creeper_: http://git.freesmartphone.org/?p=cornucopia.git;a=commit;h=0c5585cbc3b7747d3cf15ce6689e89784366efd7 , you can try to install libfsobasics package from tests dir without deps.. but be carefull and be ready to undo it
Oct 12 11:58:42 <JaMa> maybe worse things will happen..
Oct 12 12:00:38 <creeper_> JaMa: it's ok. i will wait until it's resolved. i can use shr-t for gprs for now
Oct 12 12:07:57 <playya> JaMa, mrmoku` i stop wotking on the gir thingy. the current problem is that ldd is called on a shell script
Oct 12 12:19:18 <mrmoku`> playya: ok
Oct 12 12:19:56 <playya> i even read the code, if the typelibs are platformindependent
Oct 12 12:20:16 <playya> but no :(
Oct 12 12:22:05 <playya> and gobject-introspection pulls a lot of packages into the image
Oct 12 12:27:28 <papa-piet> playya, are you also working on palm modem?
Oct 12 12:27:54 <papa-piet> s/palm/palmpre quallcamm/
Oct 12 12:28:34 <papa-piet> playya, or framework?
Oct 12 12:30:16 <playya> morphis is mainly working on the modem
Oct 12 12:30:51 <playya> but if the tslib plugin schould work now, i'll start working on the modem
Oct 12 12:33:50 <papa-piet> playya, okay
Oct 12 12:34:00 <papa-piet> mickey|office, ping
Oct 12 12:35:03 <papa-piet> playya, i'm trying to build shr for pre and will test
Oct 12 12:35:19 <playya> you'll need some patches
Oct 12 12:35:36 <mrmoku> playya: do we need gobject-introspection for gdbus ?
Oct 12 12:35:39 <playya> like disabling introspection for all packages
Oct 12 12:35:58 <playya> good question. let me check
Oct 12 12:46:45 <playya> mrmoku, i think we don't need it. the typelibs for glib are generated in gobject-introspection
Oct 12 12:54:05 <playya> mrmoku, btw. i think my python-pygobject 2.26 works. just removed the patches from .20, disabled introspection and updated the hashes
Oct 12 12:55:25 <GNUtoo|laptop> hi, on om-gta02 the issues were fixed?
Oct 12 12:59:39 <GNUtoo|laptop> ok timeout, opkg upgrading
Oct 12 13:00:15 <creeper_> GNUtoo|laptop: which issues exatctly? i'm sure there are plenty left :P
Oct 12 13:00:29 <GNUtoo|laptop> ahh wait a sec
Oct 12 13:00:36 <GNUtoo|laptop> the images are at:
Oct 12 13:00:38 <GNUtoo|laptop> http://build.shr-project.org/tests/shr-unstable
Oct 12 13:00:43 <GNUtoo|laptop> so not standard location
Oct 12 13:00:52 <GNUtoo|laptop> so should be ok to opkg upgrade on old images
Oct 12 13:02:08 <GNUtoo|laptop> btw
Oct 12 13:02:33 <GNUtoo|laptop> I'm thinking of something like that since a long time:
Oct 12 13:02:46 <GNUtoo|laptop> there is the zhone program for phone
Oct 12 13:02:53 <GNUtoo|laptop> it can use framebuffer
Oct 12 13:02:57 <GNUtoo|laptop> and is pretty simple
Oct 12 13:03:01 <GNUtoo|laptop> s/zhone/zhone2
Oct 12 13:03:08 <GNUtoo|laptop> I was thinking about the same thing for voip
Oct 12 13:04:02 <GNUtoo|laptop> how can I do that
Oct 12 13:04:10 <GNUtoo|laptop> is efl the way to go?
Oct 12 13:04:15 <GNUtoo|laptop> can it be done in gtk?
Oct 12 13:04:31 <GNUtoo|laptop> what about the programming language? python or C/vala?
Oct 12 13:04:51 <GNUtoo|laptop> because I bet not having X is much more simple
Oct 12 13:06:16 <mrmoku> GNUtoo|laptop: question is which sip stack to use
Oct 12 13:06:36 <mrmoku> playya: ok, great... will try that tonight
Oct 12 13:06:59 <GNUtoo|laptop> mrmoku, that's easy
Oct 12 13:06:59 <mrmoku> GNUtoo|laptop: I very much like sflphone... still needs some packaging work though
Oct 12 13:07:09 <GNUtoo|laptop> I'm thinking about linphonec
Oct 12 13:07:29 <mrmoku> hmm
Oct 12 13:07:42 <GNUtoo|laptop> for instance it would be really easy to do it in pygtk
Oct 12 13:07:49 <mrmoku> GNUtoo|laptop: maybe take a look at sflphone.org and tell me what you think? :)
Oct 12 13:07:51 <GNUtoo|laptop> but it would need X etc...
Oct 12 13:07:54 <GNUtoo|laptop> so not user-proof
Oct 12 13:08:35 <GNUtoo|laptop> yes it's so great
Oct 12 13:08:40 <GNUtoo|laptop> how to use it?
Oct 12 13:08:48 <mrmoku> dbus
Oct 12 13:09:13 <mrmoku> it is nicely separated into a daemon doing the sip stuff
Oct 12 13:09:21 <mrmoku> and the gui... (which we don't want)
Oct 12 13:09:32 <mrmoku> and the daemon is exclusively operated via dbus
Oct 12 13:09:42 <mrmoku> would fit sooo nice into fso land :
Oct 12 13:09:43 <mrmoku> )
Oct 12 13:09:48 <GNUtoo|laptop> indeed
Oct 12 13:09:55 <GNUtoo|laptop> mickey|office, knows about slphone?
Oct 12 13:10:21 <GNUtoo|laptop> *slfphone
Oct 12 13:10:41 <mrmoku> dunno
Oct 12 13:10:53 <mrmoku> I think I nominated it once some time ago
Oct 12 13:11:00 <GNUtoo|laptop> yes
Oct 12 13:12:02 <GNUtoo|laptop> is vala+efl easy?
Oct 12 13:12:29 <GNUtoo|laptop> or is it in an undocumented state like python efl bindings
Oct 12 13:12:35 <GNUtoo|laptop> s/efl/elmentary
Oct 12 13:12:58 <mrmoku> guess there is no documentation apart from the examples that come with it
Oct 12 13:13:11 <GNUtoo|laptop> hmmm
Oct 12 13:13:30 <GNUtoo|laptop> can gtk easily run as framebuffer app?
Oct 12 13:14:31 <GNUtoo|laptop> I mean
Oct 12 13:14:43 <GNUtoo|laptop> the zhone2 app could run as framebuffer or as X
Oct 12 13:14:47 <GNUtoo|laptop> without recompilation
Oct 12 13:14:50 <GNUtoo|laptop> which was so nice
Oct 12 13:22:40 <playya> after a little bit of thinking: we need a gobject-introspection cross package with a lot of patches
Oct 12 13:27:31 <mrmoku> playya: that sounds like no fun :/
Oct 12 13:27:43 <playya> yes 
Oct 12 13:28:26 <playya> a lot of endianess voodoo and get struct sizes from the target compiler
Oct 12 13:32:01 <mrmoku> heh, ouch
Oct 12 13:32:31 <playya> and endianess voodoo on structs
Oct 12 13:33:08 <mrmoku> would running that thing in qemu for arm be in alternative approach?
Oct 12 13:33:12 <playya> they're using bitfields
Oct 12 13:33:27 <playya> yes
Oct 12 13:33:57 <mrmoku> that might be the better way then... do it like locales in (e)glibc
Oct 12 13:34:58 <playya> but glibc is lowlovel and typelibs are highlevel
Oct 12 13:35:18 <playya> sou you need to run python in qemu
Oct 12 13:35:56 <mrmoku> hmm
Oct 12 13:36:09 <playya> the new elementary calendar is nice
Oct 12 13:36:51 <playya> at least the scanner is written in python
Oct 12 13:40:13 <playya> mrmoku, do you think it's an option to use upstart until fsoboot is finished/usable?
Oct 12 13:40:25 <mrmoku> or systemd ;)
Oct 12 13:40:52 <playya> i don't think that it's faster in our case
Oct 12 13:41:37 <playya> we don't have a lot of daemons which need to be started on demand without dbus autostart
Oct 12 13:41:43 <mrmoku> playya: maybe we should just join forces to make fsoboot usable
Oct 12 13:42:12 <playya> yes
Oct 12 13:45:02 <playya> but not highest priority. sms,call,.. for n900 and palm pre is more important
Oct 12 13:45:47 <mrmoku> I won't be able to help much on that part (apart from testing)... so I might just take a look at fsoboot again
Oct 12 13:50:06 <GNUtoo|laptop> hmmm I have that for om-gta02 : http://pastebin.com/4LQ4sB4q
Oct 12 13:50:23 <GNUtoo|laptop> from work/x86_64-linux/python-native-2.6.5-ml12.1/temp/log.do_install.29205
Oct 12 13:50:29 <GNUtoo|laptop> I'll git pull
Oct 12 13:51:11 <mrmoku> GNUtoo|laptop: heh, never seen that
Oct 12 13:51:20 <GNUtoo|laptop> ok
Oct 12 13:52:37 <playya> i don't know if it's overengineering, but libmodulo might be helpful for fsoboot
Oct 12 13:53:21 <playya> s/helpful/useful/
Oct 12 13:53:21 <apt> playya meant: i don't know if it's overengineering, but libmodulo might be useful for fsoboot
Oct 12 13:53:26 <playya> brb. shower
Oct 12 14:13:19 <CIA-102> freesmartphone.org: 03Frederik.Sdun 07vala-terminal * r5a998183d758 10/configure.ac: new way to detec vala
Oct 12 14:13:36 <playya> mrmoku, vala-terminal needs a new SRCREV
Oct 12 14:14:29 <mrmoku> playya: ok
Oct 12 14:33:15 <playya__> looks like zhone2, too 
Oct 12 14:40:35 <Mirv> am I missing any relevant kernel branch here: http://wiki.debian.org/DebianOnFreeRunner#KernelBranchesinAutumn2010 ?
Oct 12 14:48:06 <JaMa> GNUtoo|laptop: seen that.. rebuild from scratch helped.. it's somehow related to ncurses and 2/4 byte encoding detection in configure script
Oct 12 14:48:22 <GNUtoo|laptop> ah ok
Oct 12 14:48:31 <GNUtoo|laptop> JaMa, what if I rebuild ncurses
Oct 12 14:48:33 <JaMa> when did you remove tmp for lats time?
Oct 12 14:48:33 <GNUtoo|laptop> or something else
Oct 12 14:48:39 <GNUtoo|laptop> long time ago
Oct 12 14:48:47 <GNUtoo|laptop> let me look
Oct 12 14:48:49 <JaMa> GNUtoo|laptop: I've tried to rebuild about 5 recipes and it was still the same..
Oct 12 14:48:57 <GNUtoo|laptop> ok
Oct 12 14:48:58 <JaMa> GNUtoo|laptop: until I gave up and rebuilt from scratch..
Oct 12 14:49:03 <GNUtoo|laptop> I'll rebuild from scratch then
Oct 12 14:49:09 <JaMa> maybe you'll be more lucky
Oct 12 14:49:10 <GNUtoo|laptop> but If I had knew it before....
Oct 12 14:49:17 <GNUtoo|laptop> s/had//
Oct 12 14:49:17 <apt> GNUtoo|laptop meant: but If I  knew it before....
Oct 12 14:49:19 <JaMa> GNUtoo|laptop: not best time for rebuild as gir issues will hit you.. :/
Oct 12 14:49:52 <GNUtoo|laptop> 2010-07-26
Oct 12 14:51:00 <JaMa> that's older then those ncurses changes
Oct 12 14:51:13 <GNUtoo|laptop> ok
Oct 12 14:51:29 <GNUtoo|laptop> anyway I already removed it
Oct 12 14:52:49 <JaMa> ok.. I have currently 19 unbuildable recipes (but mostly because libtool-2.4 http://paste.pocoo.org/show/274510/)
Oct 12 14:54:21 <playya__> GNUtoo|laptop, JaMa, that's my current diff to disable introspection: http://pastebin.com/1WmukW1m
Oct 12 14:54:49 <GNUtoo|laptop> ok
Oct 12 14:55:09 <GNUtoo|laptop> what about PR bumps?
Oct 12 14:55:53 <JaMa> playya__: why did you disable it also in native builds?
Oct 12 14:56:14 <playya__> because i wnat to remove it completely in my build
Oct 12 15:00:02 <playya> maybe ther're packages with autodetection and without a disable switch
Oct 12 17:04:56 <CIA-102> freesmartphone.org: 03Frederik.Sdun 07cornucopia * r20578bda0018 10/fsogsmd/src/plugins/modem_qualcomm_palm/phonebook.vala: modem_qualcomm_palm: make repr() public
Oct 12 17:08:32 <GNUtoo|laptop> playya, | configure: error: Python headers not found in gobject-introspection-0.9.10-r0
Oct 12 17:08:39 <GNUtoo|laptop> from armv4t
Oct 12 17:09:09 <playya__> GNUtoo|laptop, to you have any dependency to gir?
Oct 12 17:09:27 <playya__> maybe one recipe is missing in my diff
Oct 12 17:09:32 <GNUtoo|laptop> playya, I run the stock oe.dev
Oct 12 17:09:42 <GNUtoo|laptop> I'll pull again
Oct 12 17:10:09 <playya__> grep -n gobject-introspection recipes/*/* 2>/dev/null
Oct 12 17:10:20 <playya__> i didn't push it
Oct 12 17:10:33 <GNUtoo|laptop> ok
Oct 12 17:10:45 <GNUtoo|laptop> so what should I do? wait?
Oct 12 17:13:42 <playya__> grep for dependencies
Oct 12 17:13:55 <playya__> in the OE dir: grep -n gobject-introspection recipes/*/* 2>/dev/null
Oct 12 17:14:05 <GNUtoo|laptop> ok
Oct 12 17:19:57 <playya__> if it still shows some dependecies, remove them
Oct 12 17:21:55 <JaMa> GNUtoo|laptop: I guess that's from libgee
Oct 12 17:22:35 <JaMa> GNUtoo|laptop: mickey work arrounded it to depend only gir-native from libgee-native, but later khem made it depending again :/
Oct 12 17:23:11 <GNUtoo|laptop> 1sec I'll pastebin the result
Oct 12 17:23:47 <GNUtoo|laptop> http://pastebin.com/6EC1XScs
Oct 12 17:25:58 <playya__> ok. seems to be missing in my diff
Oct 12 17:27:03 <JaMa> playya__: no it's in your diff.. 
Oct 12 17:27:13 <playya__> ok
Oct 12 18:25:20 <playya_> anyone has a patch for ffalarms?
Oct 12 19:04:09 <playya__> strange error: ERROR: [Errno 36] File name too long: '/home/playya/pre/shr-image/tmp/stamps/palmpre-oe-linux-gnueabi/frameworkd-config-shr-0.9.5.9+gitr0+cfc0a5c3def2dc2556c86f3dad182181124de006-0+41871d1c920b5db024d9a7d54d03fdab0494b8a2-r11.do_package_write_ipk'
Oct 12 19:10:00 <playya__> limit should be 255 and the path is only 208 chars long
Oct 12 19:10:03 <Q-Master> 8)
Oct 12 19:11:03 <Q-Master> JaMa: rebuild also locale bases or else eglibc-locale-* are not able to upgrade
Oct 12 19:11:24 <JaMa> Q-Master: ?
Oct 12 19:13:16 <Q-Master> JaMa: I can't upgrade to eglibc-locale-ru - 2.12-r12.5+svnr11306.5 - 2.12-r14.5+svnr11306.5 because it is lacking virtual-locale-ru somewhy
Oct 12 19:13:37 <JaMa> Q-Master: from tests feed?
Oct 12 19:13:46 <JaMa> Q-Master: because in tests feed it should be fixed
Oct 12 19:14:16 <Q-Master> JaMa: nop. from unstable one
Oct 12 19:14:19 <JaMa> http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=64538f2527fc86aa2be1b3d07d5ece813e6017da
Oct 12 19:14:48 <JaMa> then you have to wait till tests feeds are synced
Oct 12 19:14:59 <playya__> shouldn't i be possible to use SRCPV here instead of the long git revisions?
Oct 12 19:15:19 <JaMa> playya__: it's SRCPV..
Oct 12 19:15:49 <JaMa> playya__: but from 2 git repos (because 2 are in SRC_URI) see recipe and SRCREV_FORMAT
Oct 12 19:18:16 <playya__> i meant the "number of commits in branch" var
Oct 12 19:20:50 <JaMa> that's LOCALCOUNT and it's "number of commits in branch" only when BB_GIT_CLONE_FOR_SRCREV = "1" which is not the case for SHR (for last year or so)
Oct 12 19:21:38 <playya__> ok
Oct 12 19:21:56 <JaMa> that's why you have 0 there 
Oct 12 19:22:17 <playya__> any ideas how to get an comparable version without this monster of a filename?
Oct 12 19:23:58 <JaMa> merge SHR changes to config in frameworkd repo and use it as only git source (which means to kill frameworkd-config-shr_git.bb and use default instead)
Oct 12 19:25:32 <tim_abell> so, on the subject of maintenance of shr-t I'm thinking that the ideal solution is to have patches applied in our version of the oe repo that will correct any errors / security issues that arise. manpower issues aside does that sound ok?
Oct 12 19:26:14 <tim_abell> what I'm trying to do is get the aims written down clearly in the wiki and then attempt to follow them
Oct 12 19:26:26 <tim_abell> reach for the stars kind of thing
Oct 12 19:27:26 <JaMa> what you man by "our version of the oe repo"? shr-testing branches like current shr/testing2010 ?
Oct 12 19:27:33 <JaMa> s/man/mean/
Oct 12 19:27:33 <apt> JaMa meant: what you mean by "our version of the oe repo"? shr-testing branches like current shr/testing2010 ?
Oct 12 19:27:38 <tim_abell> i saw there was some shr-style activity recently but wasn't entirely sure what the objectives where and how it was done. It would be handy if someone could enlighten me
Oct 12 19:27:49 <tim_abell> JaMa, the one that the images are build from
Oct 12 19:28:12 <tim_abell> though it would be possible for shr-t to have a completely distinctly hosted git repo for oe
Oct 12 19:28:29 <tim_abell> there's so many things i'm trying to get my head round
Oct 12 19:29:02 <JaMa> what's advantage of distinctly hosted git repo? except that oe.git doesn't allow per branch permissions 
Oct 12 19:29:18 <tim_abell> i think you've pretty much nailed it there
Oct 12 19:29:21 <tim_abell> that's about it
Oct 12 19:29:36 <tim_abell> and to allow shr-t to not have to bother the oe people
Oct 12 19:29:44 <tim_abell> at least in terms of commit access
Oct 12 19:30:25 <tim_abell> it could be run more as a downstream project
Oct 12 19:30:32 <tim_abell> though i'm open either way
Oct 12 19:33:47 <tim_abell> I'm a little vague on the relationship between oe and shr at the moment
Oct 12 19:39:37 <tim_abell> I've seen http://trac.shr-project.org/trac/wiki/SHR_Architecture but I'm thinking more in terms of the relationship of upstream/downstream, people, hosting etc
Oct 12 19:40:48 <nschle85> JaMa: hello, i am not able to build a shr image, see: http://www.shr-project.org/trac/ticket/1212 can you reproduce my problem ?
Oct 12 19:41:10 <JaMa> nschle85: yes it's known
Oct 12 19:41:49 <nschle85> JaMa: is there a workaround ? i googled and found not so good news
Oct 12 19:42:28 <JaMa> yes read todays log and use playya's diff
Oct 12 20:05:17 <nschle85> JaMa: ok another problem: http://norman-schleicher.de/hudson/job/shr-unstable-image-clean-build/44/console  which package provides the python headers ? 
Oct 12 20:07:58 <JaMa> nschle85: python-native, but non-native gir is just broken
Oct 12 20:08:44 <JaMa> nschle85: there are 2 threads about gir and you can find more info about gir in logs from last few days here
Oct 12 20:09:03 <JaMa> s/about gir/about gir in oe-devel ML/
Oct 12 20:09:04 <apt> JaMa meant: nschle85: there are 2 threads about gir in oe-devel ML and you can find more info about gir in logs from last few days here
Oct 12 20:27:29 <tim_abell> ahhr, brain overload
Oct 12 20:28:34 * tim_abell is scanning ubuntu's processes for hint on how to run shr-t
Oct 12 21:03:20 * tim_abell has burnt out
Oct 12 21:03:30 <tim_abell> http://www.shr-project.org/trac/wiki/ShrMaintainerHowTo updated with latest musings
Oct 12 21:03:48 <tim_abell> laters
Oct 12 21:08:16 * JaMa trying to make distutils behave with new libtool and also burnt out a bit after 4 unsuccessfull hours :/
Oct 12 21:46:45 <JaMa|Zzzz> ahh! python recipes are building again! :)
Oct 12 21:46:52 <JaMa|Zzzz> gnight
**** ENDING LOGGING AT Wed Oct 13 02:59:57 2010