**** BEGIN LOGGING AT Wed Jun 01 02:59:56 2011
Jun 01 08:02:16 <qhe> RP__: ping
Jun 01 08:02:29 <RP__> qhe: pong
Jun 01 08:03:27 <qhe> RP__: I met some issues when trying to add a BBCLASSEXTEND_append in the bitbake.conf
Jun 01 08:03:44 <RP__> qhe: What kind of issues?
Jun 01 08:03:58 <qhe> it's OK at the parsing, but when the task is about to run, a no key error is reported
Jun 01 08:04:32 <qhe> at lib/bb/cache.py line 304: return bb_data[virtual]
Jun 01 08:04:39 <qhe> KeyError: '...'
Jun 01 08:05:35 <RP__> qhe: Its sounds like somehow the virtual part of the filename became '...' which is wrong :/
Jun 01 08:05:41 <qhe> RP__: If the BBCLASSEXTEND is written in the individual recipe, such error won't happen
Jun 01 08:05:56 <qhe> RP__: it's actually lib32, I just omitted it
Jun 01 08:06:14 <qhe> KeyError: 'lib32'
Jun 01 08:06:14 <RP__> qhe: ah, ok
Jun 01 08:06:55 <RP__> qhe: It should work the same as if it were in a recipe. This sounds like a bug in bitbake
Jun 01 08:06:56 <qhe> it happens within rq.execute_runqueue()
Jun 01 08:09:40 <RP__> qhe: I'm trying to reproduce locally
Jun 01 08:10:04 <qhe> RP__: ok, thank you. If you need my back trace or something I can help
Jun 01 08:29:37 <bluelightning> morning all
Jun 01 09:12:12 <RP__> qhe: I have a fix for you - remove the conditional on line 377 of ast.py ("if not onlyfinalise or "default" in onlyfinalise:")
Jun 01 09:12:42 <qhe> RP__: got it, I'll have a try
Jun 01 09:13:09 <qhe> RP__: and have another question
Jun 01 09:13:56 <qhe> do you think it's cleaner if gcc-cross-lib32 is built as well? Though it costs more time, of course
Jun 01 09:46:17 <ant_work> RP__: ping
Jun 01 10:33:41 <RP__> ant_work: pong
Jun 01 10:58:22 <ant_work> RP__: with your arm hat, what to do now that CONFIG_MTD_PARTITIONS is prohibited?
Jun 01 10:59:05 <RP__> ant_work: It being prohibited is the first I've heard of it
Jun 01 10:59:07 <ant_work> http://www.linux-mtd.infradead.org/index.html
Jun 01 10:59:16 <ant_work> btw ?? pls bump mtd-utils
Jun 01 10:59:27 <ant_work> s/??/^^
Jun 01 10:59:35 <RP__> ant_work: btw, pls send a patch ;-)
Jun 01 11:01:08 <RP__> ant_work: Sounds like someone needs to write some patches for the mtd partitions stuff
Jun 01 11:03:47 <ant_work> it's just about the 'mtdparts' cmdline arg if I understand it
Jun 01 11:04:07 <RP__> ant_work: no, if you read the actual email from Artem its about making it on by default
Jun 01 11:04:16 <RP__> ant_work: so not really anything to worry about
Jun 01 11:04:33 <ant_work> ah, ok, still possible to dynamically resize
Jun 01 11:04:38 <ant_work> pheew
Jun 01 11:05:04 <ant_work> do you think we could get rid of the bootloaders and move to devicetree's?
Jun 01 11:05:20 <ant_work> for arm is still WIP though
Jun 01 11:05:32 <RP__> ant_work: you're answering your own question ;-)
Jun 01 11:05:36 <ant_work> he he
Jun 01 11:05:46 <ant_work> I hoped you had some insider knowledge ;)
Jun 01 11:06:03 <RP__> well, there are some good people working on arm device tree stuff
Jun 01 11:06:35 <ant_work> good to know you're still following that stuff
Jun 01 11:07:19 <ant_work> these days I'm fighting agains breakages wich removed some of your code (corgi_kbd et al.)
Jun 01 11:08:28 <RP__> ant_work: I wish I had time to looks after the zaurus devices but I simply don't :(
Jun 01 11:08:42 <RP__> All that code has its purposes :/
Jun 01 11:31:41 <ant_work> RP__: about mtd-utils, bumped
Jun 01 11:32:30 <RP__> ant_work: Perhaps I wasn't clear, please could you send a patch? ;-)
Jun 01 11:32:50 <ant_work> ;)
Jun 01 11:36:16 <ant_work> about this, no-complains makes me think nobody bothers with jffs2 in oe-core nowadays
Jun 01 11:57:02 <RP__> ant_work: People use mmc cards a lot more these days
Jun 01 13:33:04 <thhp> Hey folks, does anyone know whether the "POKYMODE" toolchain selection mechanism is still good for oe-core?
Jun 01 13:56:40 <thhp> Think I just answered my own question... no, it isn't.  Is there a replacement mechanism, does anyone know?
Jun 01 14:53:12 <zenlinux> gm all
Jun 01 16:28:12 <RP__> thhp: It became a generic TCMODE
Jun 01 16:32:24 <thhp> RP__: thanks, I discovered this in defaultsetup.conf a little while earlier
Jun 01 16:32:44 <thhp> RP__: just trying to educate myself about the oe-core approach to distro definition now
Jun 01 18:02:28 <sgw> RP__: ping
Jun 01 18:02:35 <RP__> sgw: pong
Jun 01 18:03:19 <sgw> Would I be correct that a change to something like autoconf, should rebuild the world (or close to it)?
Jun 01 18:07:24 <RP__> sgw: if basichash is turned on
Jun 01 18:07:59 <sgw> Ah, ok which it is not by default, since I just tried and only a limited set build.
Jun 01 18:10:09 <RP__> sgw: correct
Jun 01 19:10:24 <otavio> sgw_away: it seems gnutls doesn't compile anymore
Jun 01 19:11:20 <otavio> sgw_away: it fails with missing reference to dlopen and like
Jun 01 19:45:43 <otavio> sgw_away: I fixed gnutls here; will post the fix soon
Jun 01 19:46:05 <otavio> RP__: since it is a build failure, want me to put it somewhere for you to push it?
Jun 01 20:37:27 <dvhart> anyone seeing python_2.6.6 install failures?
Jun 01 20:37:42 * dvhart thinks it might be kernel 3.0.0-rc1 related...
Jun 01 20:57:24 <sgw> otavio: under what conditions does it fail, I have multiple successful builds
Jun 01 21:03:04 <otavio> sgw: look at the patch I sent to ml; pb and I are discussing about it there
Jun 01 21:26:18 <sgw> otavio: is it possible that you have a site file that sets ac_cv_func_dlopen or ac_cv_dlopen_self?  This problem occurred recently with ppc build and that was the fix.
Jun 01 21:27:11 <otavio> sgw: seems not
**** ENDING LOGGING AT Thu Jun 02 02:59:56 2011