**** BEGIN LOGGING AT Wed Apr 04 02:59:59 2012 Apr 04 10:01:39 03Steffen Sledz  07org.openembedded.dev * rb50fde72d5 10openembedded.git/recipes/docbook-utils/ (docbook-utils-0.6.14/re.patch docbook-utils-native_0.6.14.bb): (log message trimmed) Apr 04 10:01:39 docbook-utils-native: fix syntax problem in jw.in Apr 04 10:01:39 Fix runtime error occurred e.g. with docbook-to-man calls: Apr 04 10:01:39 grep: character class syntax is [[:space:]], not [:space:] Apr 04 10:01:39 grep: character class syntax is [[:space:]], not [:space:] Apr 04 10:01:39 jw: There is no frontend called "/docbook/utils-0.6.14/frontends/docbook". Apr 04 10:01:40 See also: Apr 04 10:24:08 is it expected that 'bitbake -S m4-native' reports a lot of mismatched basehashes? Apr 04 21:26:13 Daft question (I hope) but not something I have encountered before, what is the cleanest way to append a class in oe-core (a'la bbappend)? I need to add a custom kernel mkimage step and I really don't want it touching anything outside of the boards own BSP layer. I can think of a few ways to do it but I guess it is not that uncommon a problem so there must be a prefered way. Apr 04 21:28:41 add the class in your layer Apr 04 21:30:36 khem: that was one of the options but copying over the whole class seemed somewhat 'crude' ;) Apr 04 21:33:09 figure out why you need to append to it.. are you adding functionality that is missing and generally useful? then it should be patched and sent upstream.. are you using it as a starting point and then adding custom functionality? If so, I believe you can add your new class (in your layer) and include / inherit / require the old one.. Apr 04 21:33:23 (or simply copy and modify as necessary).. Apr 04 21:34:03 (I agree it's not optimal.. but that was an implementation decision made when layers and bbappend were introduced.. if you think you have a reason to do it, be sure to ask on the oe-core list...) Apr 04 21:35:30 frey: this is a simple BSP layer for the RaspberryPi and that needs a 32k blob (closed source of course) pre-pended to the kernel uImage to boot it :o, not something that is exactly generic and just itching to upstream ;). Apr 04 21:37:01 u just might need to add a class which does the custom stuff and calls the regular functionality from class on OE-core Apr 04 21:37:11 yup.. what khem said.. Apr 04 21:37:20 frey: just requiring the class was my plan but it was not playing nice unless I copied the existing class into the layer but that may well be me screwing up again. I'll work with what I can get going. Apr 04 21:37:25 that is the best way.. create a new class kernel-pi.bbclass and have it use the the stuff from the main kernel class Apr 04 21:38:01 it might be a simple way to reference the class in any layer, but I don't know it off hand.. ask on the mailing list (bitbake-devel or oe-core) and they should be able to help make it possible.. Apr 04 21:38:09 if it doesn't already work, I'd consider it an excellent enhancement Apr 04 21:38:31 * fray goes on a quick 1 days vacation.. back on Friday! Apr 04 21:38:31 just inherit Apr 04 21:38:38 Yep, that was my plan, I guess I should not need to copy over kernel.bbclass? I'll look into it as it sounds like that is the cleanest way to do it so should be beaten into working ;-) Apr 04 21:38:38 fray: enjoy Apr 04 21:39:07 ya, inherit is what I was thinking Apr 04 21:39:12 thanx, later Apr 04 21:39:26 khem: fray: thanks guys, just the pointers I needs. Apr 04 21:39:29 fray: you pinged me yesterdys Apr 04 21:39:36 frey: enjoy the break Apr 04 21:39:41 is the ping still valid ?:) Apr 04 21:39:43 khem, just to point you to the "armv5e" patch I sent up Apr 04 21:40:00 oh i did not have chance Apr 04 21:40:01 check the oe-core list for it.. basically gcc support -march=armv5e, but gas doesn't.. causing a problem.. Apr 04 21:40:14 the same happens with the epsomethingsomethingsomething Apr 04 21:40:23 oh atmv5e yea Apr 04 21:40:24 also (as you probably know) the MIPS64 tunings don't yet work.. Apr 04 21:40:38 and finally sh3 is broken, gcc is looking for a patch that doesn't exist Apr 04 21:40:43 (that was the whole ping) ;) Apr 04 21:40:43 yeh mips64 is in my interest Apr 04 21:40:51 i might be workin on it soon Apr 04 21:41:12 oh thanks for the info Apr 04 21:41:18 i will try it out Apr 04 21:41:20 the armv5e/ ep... and sh3 were the three things that I think are more immediate.. Apr 04 21:41:26 how did you test sh3 Apr 04 21:41:34 I only checked if it would compile.. Apr 04 21:41:42 there was a previous tuning.. I brought it into the enw world.. Apr 04 21:41:42 hmm ok Apr 04 21:41:45 I created a dummy qemush3 Apr 04 21:41:51 i see Apr 04 21:42:09 i always think that we shoud have some unsupported qemu machnes Apr 04 21:42:10 I built all 122 tunings using that method.... Apr 04 21:42:19 e.f. qemumips64 and qemush3 Apr 04 21:42:22 I have no idea if qemu even support sh.. ;) if it does.. sure! Apr 04 21:42:27 itdoes Apr 04 21:42:34 i made it work in classic oe Apr 04 21:42:38 cool, I'd like another architecutre, even if its an old one Apr 04 21:42:49 * fray liked the dreamcast ;) Apr 04 21:42:50 sparc is a possibility Apr 04 21:42:57 too since qemu supports that Apr 04 21:43:11 well I'm likely going to introduce a patch that kills off sparc though.. it can;t work as currently implemented and nobody has complained.. Apr 04 21:43:18 thats fine Apr 04 21:43:22 I only did sh3/4 because someone mentioned they were having problems with it Apr 04 21:43:32 i was more thinking getting mips64 and sh3/sh4 Apr 04 21:43:40 as a unsupported qemumachines Apr 04 21:43:41 ya.. much more useful then sparc Apr 04 21:43:49 or second class citizens Apr 04 21:44:09 I -really- want mips64 myself.. since that will let us finally play with tri-arch (on non ia) Apr 04 21:44:29 ok, I really have to go now.. later! Apr 04 21:44:44 cu Apr 04 22:12:44 DJWillis: could the custom stuff not be done within the kernel recipe rather than in kernel.bbclass? **** ENDING LOGGING AT Thu Apr 05 02:59:58 2012