**** BEGIN LOGGING AT Fri Jan 29 02:59:56 2010
**** BEGIN LOGGING AT Fri Jan 29 04:33:46 2010
Jan 29 05:50:37 <leslielg> hello
Jan 29 05:53:04 <leslielg> i have just git pull my oe, and found qt 4.6.1 bb file appears, but i failed at qt4-tools-native_4.6.1.bb do_compile
Jan 29 05:54:42 <leslielg> anybody build qt 4.6.1 correctly?
Jan 29 06:23:37 <JaMa> leslielg: failed for me to.. some crosscompile patch didn't apply
Jan 29 09:13:00 <ynezz> JaMa: SRC_PV=45693 for efl builds here
Jan 29 09:16:55 <ynezz> JaMa: do I need to check something specific?
Jan 29 09:16:57 <JaMa> ynezz: have you tried it on device?
Jan 29 09:17:30 <JaMa> ynezz: last breakage was segfault all over python-e* packages in runtime semi randomly..
Jan 29 09:17:44 <JaMa> ynezz: so I cannot say what should be checked first :/
Jan 29 09:20:12 <JaMa> ynezz: and seems that http://trac.enlightenment.org/e/changeset/45697 is needed for 45693
Jan 29 09:20:35 <leslielg> Hi, qt embedded 4.6.0 application doesnot recorgnize caps lock key, my kbd is usb keyboard, should i export something to environment?
Jan 29 09:20:47 <ynezz> JaMa: ah :)
Jan 29 09:20:47 <mckoan> good morning
Jan 29 09:21:37 <JaMa> ynezz: IIRC koen reenabled gl in evas so it could be a problem to break it so soon..
Jan 29 09:43:31 <raster> JaMa: as such gle-s is working
Jan 29 09:43:54 <JaMa> raster: in 45697 or 45693 too?
Jan 29 10:46:39 <hrw> morning
Jan 29 10:49:55 <mckoan> hrw: gm
Jan 29 10:55:59 <RP> morning all
Jan 29 10:58:41 <zecke> hey
Jan 29 11:12:31 <leslielg> hi zecke, have you tried building qt embedded 4.6.1? 
Jan 29 12:08:59 <eFfeM> anyone an idea for this one: svn: Unrecognized URL scheme for 'http://opkg.googlecode.com/svn/trunk'
Jan 29 12:08:59 <eFfeM> I am building from dev head
Jan 29 12:09:58 <zecke> eFfeM: which svn binary are you using?
Jan 29 12:10:15 <zecke> eFfeM: your svn was built without NEON support, I had this once on a older ubuntu
Jan 29 12:13:29 <eFfeM> zecke: this is indeed ubuntu
Jan 29 12:13:45 <eFfeM> i have 1.6.6
Jan 29 12:13:57 <eFfeM> from the hardy feed
Jan 29 12:14:55 <zecke> eFfeM: it is not something like svn-native?
Jan 29 12:15:07 <zecke> eFfeM: it only was broken for a short while in development
Jan 29 12:18:02 <eFfeM> should oe have a svn-native ?
Jan 29 12:18:36 <zecke> eFfeM: no idea, I'm just asking you to do a `which svn`
Jan 29 12:18:45 <zecke> eFfeM: and the same from a bitbake devshell :)
Jan 29 12:20:40 <eFfeM> native  is /usr/local/bin/svn building devshell but didn't see a recipe for it
Jan 29 12:21:52 <zecke> eFfeM: and you have one /usr/bin/svn too?
Jan 29 12:22:29 <eFfeM> yes, 1.4.6 guess that tells something
Jan 29 12:22:41 <eFfeM> should have done whereis svn
Jan 29 12:22:48 <zecke> ;)
Jan 29 12:22:51 <zecke> I rest my case.
Jan 29 12:23:10 <eFfeM> you said which, not whereis :-)
Jan 29 12:25:58 <eFfeM> how long should I wait before committing the kernel.bbclass patch I posted? May I assume no news = good news ?
Jan 29 12:33:24 <eFfeM> zecke: actually it was the 1.6.6 version in /usr/local/bin that was broken, the 1.4.6 in /usr/bin is ok 
Jan 29 12:34:42 <woglinde> effem no news == nobody wachted into it
Jan 29 12:36:35 <eFfeM> woglinde: feared that, then again people were very quick to let me know that I posted a wrong patch :-)
Jan 29 12:38:37 <zecke> eFfeM: well, which tells you the first one.. and if it is not /usr/bin/svn, one knows it is wrong :)
Jan 29 12:40:56 <eFfeM> zecke, i tested both of them the one in /usr/local/bin was first in path and indeed wrong
Jan 29 13:52:59 <RP> Does anyone know what the problems with newer autoconfs and OE are?
Jan 29 13:57:22 <woglinde> hm?
Jan 29 13:57:30 <woglinde> which autoconf?
Jan 29 14:03:20 <RP> woglinde: 2.63 or 2.65
Jan 29 14:03:35 <RP> woglinde: I disabled 2.63 in poky, I don't remember why :/
Jan 29 14:09:44 <woglinde> hm
Jan 29 14:39:11 <kergoth> morning
Jan 29 14:41:13 <RP> hi kergoth 
Jan 29 14:45:29 <woglinde> hi kergoth
Jan 29 14:45:35 <kergoth> hey guys
Jan 29 14:45:37 * kergoth yawns
Jan 29 14:46:26 <woglinde> whats up?
Jan 29 14:46:47 <kergoth> trying to wake up, you? :)
Jan 29 14:47:03 <GNUtoo> mmm I tried various things that I will mention in next line but I still have that:ERROR: Multiple .bb files are due to be built which each provide virtual/xserver (.../xserver-kdrive_1.4.2.bb .../xserver-xorg_1.7.1.bb).
Jan 29 14:47:25 <RP> GNUtoo: bitbake world?
Jan 29 14:47:34 <GNUtoo> PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive" in my image
Jan 29 14:47:44 <GNUtoo> and XSERVER = "xserver-kdrive-fbdev" also in my image
Jan 29 14:47:57 <RP> GNUtoo: Are you pulling in some xorg-xf86 stuff somewhere?
Jan 29 14:48:06 <kergoth> bitbake -g, see what's pulling in the xorg one
Jan 29 14:48:10 <GNUtoo> RP, no bitbakeing my image wich is based on micro-base-image
Jan 29 14:48:14 <GNUtoo> kergoth, good idea
Jan 29 14:48:46 <woglinde> micro uses sane-xorg-foo-src stuff
Jan 29 14:48:54 <GNUtoo> ah ok
Jan 29 14:48:56 <hrw> GNUtoo: and what in machine config?
Jan 29 14:49:06 <kergoth> can also be good to use bitbake -e to be *absolutely* certain of the values of the variables, since a machine .conf can override you if they forgot to use ?=
Jan 29 14:49:06 <GNUtoo> hrw, bug
Jan 29 14:49:09 <kergoth> hrw: :)
Jan 29 14:49:48 <GNUtoo> what overides? buf.conf or my_image.bb ?
Jan 29 14:50:52 <GNUtoo> ok
Jan 29 14:51:02 <GNUtoo> I'll use bitbake -i
Jan 29 14:53:53 <kgilmer> bitbake -e is very powerful
Jan 29 14:54:00 <GNUtoo> ok
Jan 29 14:54:25 <kgilmer> the eclipse tools basically only use 'bitbake -e'
Jan 29 14:56:41 <GNUtoo> mmm bitbake -e and bitbake -i seem to give different results
Jan 29 14:57:50 <GNUtoo> I'll add the necessary ? then
Jan 29 15:02:16 <GNUtoo> btw I bet kdrive uses less ram no?
Jan 29 15:02:38 <woglinde> hm is kdrive maintained anymore?
Jan 29 15:02:43 <broonie> No.
Jan 29 15:02:47 <GNUtoo> I don't think so
Jan 29 15:02:56 <broonie> Or alternatively, well volunteered!
Jan 29 15:03:25 <GNUtoo> I'm trying to see if things can work with 32M of ram+oe
Jan 29 15:03:57 <pb_> yeah, you probably do want kdrive on a 32MB machine
Jan 29 15:04:19 <pb_> it isn't really maintained anymore, but it should still work fine in simple configurations.
Jan 29 15:06:17 <GNUtoo> ok
Jan 29 15:06:21 <GNUtoo> thanks a lot
Jan 29 15:09:01 <hrw> ~curse bitbake parser for +=
Jan 29 15:09:02 <ibot> May you be reincarnated as a Windows XP administrator, bitbake parser for += !
Jan 29 15:09:37 <hrw> VAR_machine += "something" # you just broke
Jan 29 15:09:53 <GNUtoo> ?
Jan 29 15:10:00 <GNUtoo> ah ok
Jan 29 15:10:19 <GNUtoo> missing spaces...
Jan 29 15:11:16 <hrw> GNUtoo: no, _append require spaces. += adds them
Jan 29 15:11:29 <GNUtoo> ok
Jan 29 15:12:03 <GNUtoo> anyway I always add spaces to be shure
Jan 29 15:12:25 * kergoth hates it when people do that, always tempted to NACK their patches when they wrap in unnecessary spaces :)
Jan 29 15:12:40 <GNUtoo> mmm
Jan 29 15:12:41 <kergoth> heh, always good to remember that VAR_machine += "something" appends "something" to VAR_machine, which was likely empty before, so it overrides the original, and VAR is now just "something"
Jan 29 15:13:00 * kergoth thinks its a confusing behavior, but isn't sure how best to resolve it
Jan 29 15:14:10 <hrw> yep
Jan 29 15:24:27 * hrw -> off
Jan 29 15:29:23 <pb_> mickey|office: do you have any idea how hard it would be to make recipes for older versions of python?
Jan 29 15:29:33 <GNUtoo> that is strange: "xserver-kdrive.do_package_write_ipk" -> "xserver-xorg.do_package"
Jan 29 15:30:03 <pb_> one of my customers seems to want 2.3.3 and I suspect they will balk if I try to give them 2.6.1 or 2.6.2.
Jan 29 15:34:34 <mickey|office> pb_: shouldn't be too hard, try resurrecting 2.3.x from the mtn database and start w/ that
Jan 29 15:37:06 <pb_> mickey|office: okay, cool, thanks
Jan 29 15:37:34 <pb_> I will try offering them 2.6.x to start with and see what happens.
Jan 29 15:38:23 <kergoth> pb_: looks like 07f796a9dde275d91e980cc6fe5c4fd98b005bae removed 2.3.4, so around there should be a good starting point
Jan 29 15:38:32 <pb_> kergoth: excellent, thanks
Jan 29 15:38:36 <kergoth> np.
Jan 29 15:38:38 * kergoth hugs git
Jan 29 15:47:40 <mickey|office> pb_: i wouldn't know why they should not be using 2.6 instead of 2.3. I can't recall any incompatible changes during the 2.x series. Chances that 2.3 programs work without any trouble in 2.6 are pretty high
Jan 29 15:49:57 <kergoth> customers aren't always sane :)
Jan 29 15:51:20 <GNUtoo> require sane-customers.inc won't work I bet
Jan 29 15:51:44 <pb_> GNUtoo: indeed, same problem that we had with kergoth-sanity.inc
Jan 29 15:51:58 <GNUtoo> ok lol
Jan 29 15:51:58 <kergoth> :)
Jan 29 15:52:29 <pb_> mickey|office: righto, thanks
Jan 29 15:57:52 <PaulePanter> Hi guys. Could some please commit this trivial patch. http://patchwork.openembedded.org/patch/1440/
Jan 29 15:59:19 <PaulePanter> Please use http://patchwork.openembedded.org/patch/1440/raw/ to get the patch to apply with `git am`.
Jan 29 16:02:32 <pb_> done
Jan 29 16:09:06 <PaulePanter> pb_: Thanks. (I did `pwclient update -s applied -c 82c0ca871667f6ded7dee09e9308615d16053252 1440` to update the state in Patchwork.)
Jan 29 16:16:51 <kergoth> hmm
Jan 29 16:19:04 <kergoth> http://kergoth.pastey.net/132197 .. heh
Jan 29 16:20:00 * kergoth wonders whats up with the eglibc rprovides
Jan 29 16:21:02 <PaulePanter> I trying to keep VDR in shape in OE. The recipe which got committed with the help of you guys is for the development version 1.7.10, which got superseded by 1.7.11 some weeks ago. My question is, if I should replace the recipe 1.7.10 with the one for 1.7.11 or just add a new one.
Jan 29 16:21:50 <PaulePanter> I favor replacing it because it is a development version and since VDR has not been in OE for a long time, there are probably not much users yet.
Jan 29 16:22:00 <PaulePanter> So it would not hurt that much.
Jan 29 16:23:26 <kergoth> weird, i think recipe_sanity is on crack wrt PV.. what the hell is happening there
Jan 29 17:47:07 <florian> re
Jan 29 18:10:44 <khem> kergoth: eglibc pretends to be glibc
Jan 29 18:11:06 <khem> kergoth: some packages demand glibc in package names
Jan 29 18:11:07 <kergoth> ah
Jan 29 18:11:19 <khem> ideally there should be a virtual package
Jan 29 18:11:29 <khem> which should be depended upon
Jan 29 18:11:38 <khem> but that will be wholesome change
Jan 29 18:12:16 * kergoth nods
Jan 29 19:07:37 <Crofton|work> anyone know why git won't seem to install in an image?
Jan 29 19:08:00 <khem> git ?
Jan 29 19:08:24 <khem> you mean target package for git ?
Jan 29 19:09:14 <khem> IMAGE_INSTALL_append_pn-native-sdk-image = "git"
Jan 29 19:09:26 <khem> to your local.conf if thats the case
Jan 29 19:10:10 <Crofton|work> I have it in a sdk I am creating
Jan 29 19:10:19 <Crofton|work> but it does not make it into the image
Jan 29 19:18:55 <Crofton> the control file in the task lists git
Jan 29 19:19:05 <Crofton> and it seems like opkg will install it from the feeds
Jan 29 19:29:28 <woglinde> lol
Jan 29 19:29:36 <woglinde> fjuitsu has ipad
Jan 29 19:56:00 <khem> I have a stationary pad here which is called ipad :)
Jan 29 20:09:16 <kergoth> hmm, share/gdb/auto-load/lib/libgobject-2.0.so.0.2200.4-gdb.py isn't packaged. i wonder if we should automatically package ${datadir}/gdb/auto-load into a ${PN}-gdb package if it exists, or even just shove it into the -dbg package, since they're used for debugging
Jan 29 20:13:05 <khem> I think it should go into -dbg 
Jan 29 20:14:00 <kergoth> yeah, i htink so too. i didn't think about it until i was half way through typing that
Jan 29 20:14:01 <kergoth> hehe
Jan 29 20:22:15 <GNUtoo> woglinde, ibad?
Jan 29 20:22:35 <GNUtoo> woglinde, touchbook seem nice,specially with 512M of ram
Jan 29 20:22:42 <GNUtoo> maybe I'll buy one
Jan 29 20:22:56 <kergoth> seem like a good alternative to netbooks for that particular market
Jan 29 20:26:53 <woglinde> yeah
Jan 29 20:27:01 <woglinde> my company has ordered one
Jan 29 20:27:09 <woglinde> should arrive soon in our offuce
Jan 29 20:27:12 <woglinde> args office
Jan 29 20:29:15 <khem> woglinde: how much is price in eu
Jan 29 20:30:15 <woglinde> hm dont know
Jan 29 20:38:04 <woglinde> jo laibsch
Jan 29 20:38:36 <woglinde> laibsch waere nicht das touchbook was fuer dich anstatt eeepc?
Jan 29 20:38:40 <woglinde> args
Jan 29 20:38:47 <woglinde> sorry
Jan 29 20:38:56 <Laibsch> somebody already suggested the touchbook
Jan 29 20:39:01 <Laibsch> I'm not so sure
Jan 29 20:39:37 <Laibsch> I'm still within the "think about it"-14 day period for the 1005p
Jan 29 20:51:19 <kergoth> hmm, cp: cannot stat `/home/clarson/oe/projects/sync/files/pam.d/*': No such file or directory
Jan 29 20:59:21 <GNUtoo> ok
Jan 29 21:03:00 <eFfeM-Home> we lost CIA due to the +R ?
Jan 29 21:12:25 <kergoth> hmm, given bitbake's summary of the failed tasks now, i wonder if itd be worthwhile to think about making the -k behavior default at some point
Jan 29 21:12:30 <kergoth> do as much as possible..
Jan 29 21:15:52 <khem> kergoth: -k could be evil sometimes if tasks duplicate work
Jan 29 21:16:17 <kergoth> -k is different from -a
Jan 29 21:16:37 <kergoth> -a tries alternate providers, -k just runs the tasks it would run anyway, rather than aborting at the first failure it encounters
Jan 29 21:16:42 <kergoth> so it gets closer to what you requested in one pass
Jan 29 21:54:21 * kergoth adds the -k thing and an idea on fetch/unpack/patch to the list
Jan 29 22:29:27 <kergoth> anyone have the scoop on bluez-dtl1-workaround?
Jan 29 22:35:58 <pb__> kergoth: it's a sop for some brokenness in dtl1_cs bluetooth cards, which (used to) go wrong when the machine was suspended
Jan 29 22:36:16 <kergoth> ah.  do you know if its still necessary?
Jan 29 22:36:36 <pb__> no idea.  this was with 2.4.something kernels back in 2004 or so.
Jan 29 22:36:44 <pb__> I suspect probably not.
Jan 29 22:36:45 <kergoth> sheesh, okay
Jan 29 22:37:01 <pb__> I doubt there are many dtl1_cs cards left in the wild anyway.  they were never very good.
Jan 29 22:37:18 * kergoth hadn't copied it over to mvl6, but apparently its getting pulled in somehow, breaking the build
Jan 29 22:38:07 <kergoth> collections/foundation/classes/kernel.bbclass:249:DEPENDS_kernel-module-dtl1-cs = "bluez-dtl1-workaround"
Jan 29 22:38:07 <kergoth> collections/foundation/classes/kernel.bbclass:250:RDEPENDS_kernel-module-dtl1-cs = "bluez-dtl1-workaround"
Jan 29 22:38:13 <kergoth> heh,t he first one there is completely useless
Jan 29 22:38:26 <kergoth> looks like task-base pulls it in too?
Jan 29 22:38:30 * kergoth scratches head
Jan 29 22:46:51 <pb__> weird
Jan 29 22:47:09 <pb__> yeah, I guess that first DEPENDS is some relic from the days before RDEPENDS used to imply DEPENDS
Jan 29 22:47:22 <pb__> still find those in the tree from time to time
Jan 29 22:48:53 <kergoth> heh, true.  still, DEPENDS_<pkg>?  did that -ever- work? :) DEPENDS i could see
Jan 29 22:48:54 <kergoth> ah well
Jan 29 22:49:03 <kergoth> as you say, no shortage of remnants
Jan 29 22:50:21 <pb__> oh, heh, I didn't notice it was DEPENDS_foo.  no, I don't think that ever worked.
Jan 29 22:50:40 <pb__> kernel-module-xx doesn't even exist until after package splitting has run, and DEPENDS is history way before that point
Jan 29 22:51:19 * pb__ downs a lemsip and heads off to bed
Jan 29 22:51:20 <pb__> night all
Jan 29 22:51:21 <kergoth> night
**** ENDING LOGGING AT Sat Jan 30 02:59:57 2010