**** BEGIN LOGGING AT Tue Sep 17 02:59:58 2013
**** BEGIN LOGGING AT Tue Sep 17 06:12:43 2013
Sep 17 21:32:22 <ant_home> bluelightning, if you happen to know why PACKAGES = "" doesn't stop its child tasks tell me pls
Sep 17 21:32:35 <ant_home> otherwise pls merge the patches on the ML
Sep 17 21:45:36 <bluelightning> ant_home: well all that does is stop it from producing any packages, it won't stop the tasks from executing
Sep 17 21:49:27 <ant_home> it did it before
Sep 17 21:50:02 <ant_home> JaMa's autobuilder has this recent failure on fo_package as well
Sep 17 21:50:17 <ant_home> it's a first iirc
Sep 17 21:51:52 <ant_home> I'm still unbreaking kernel.bbclass after last commit...will dig in the commits in /classes later
Sep 17 21:52:30 <ant_home> anyway, pls listen and say I'm crazy or not...
Sep 17 21:52:47 <ant_home> in oe-core we have per-machine sysroot
Sep 17 21:53:05 <ant_home> the linux-libc-headers are installed in target sysroot
Sep 17 21:53:39 <ant_home> any recipe needing headers would refer to these headers OR even depend on virtual/kernel
Sep 17 21:54:07 <ant_home> so any recipe of such kind becomes machine-specific, peeking in target sysroot
Sep 17 21:54:34 <ant_home> now, klibc needs linux headers itself to build (or a kernel tree)
Sep 17 21:55:00 <ant_home> once built is arch-specific anyway
Sep 17 21:56:43 <ant_home> but during build installs (copy) its extra headers but we trick and use a symlink to the kernel in target sysroot
Sep 17 21:57:27 <ant_home> now, for building third party binaries e.g kexec-tools-klibc it needs all those headers, which are in target sysroot
Sep 17 21:57:44 <ant_home> it  = klcc-cross , the wrapper
Sep 17 21:58:25 <ant_home> my conclusion is that it is impossible to make klcc-cross arch-specific with current oe-core setup
Sep 17 21:58:54 <ant_home> it badly needs PACKAGE_ARCH = "${MACHINE_ARCH}"
Sep 17 21:58:58 <ant_home> unfortunately
Sep 17 21:59:00 <bluelightning> well hang on... linux-libc-headers should not be machine specific
Sep 17 21:59:29 <ant_home> http://cgit.openembedded.org/openembedded/tree/recipes/klibc/klibc.inc?h=org.openembedded.dev&id=8a987fbee587e6a7284aae463aa369ebc3ab7762
Sep 17 21:59:39 <ant_home> ^^ old OE
Sep 17 22:00:00 <ant_home> we had  ${STAGING_DIR}/${MACHINE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/kernel
Sep 17 22:00:50 <ant_home> bluelightning, linux-libc-headers is not machine specific but installs in target sysroot
Sep 17 22:01:31 <ant_home> there isn't any arch-sysroot I'm aware of
Sep 17 22:01:56 <ant_home> well, where toolchain resides but seems odd
Sep 17 22:04:05 * ant_home heads for a beer
Sep 17 22:07:34 <ant_home> bluelightning, finally, there isn't any package..it just needs to be rebuilt for every machine
Sep 17 22:11:47 <ant_home> basically I'd like to exclude the sstate caching
Sep 17 22:14:18 <ant_home> now if you build i.e spitz then clean tmp and build akita you are still using the klcc with hardcoded references to spitz sysroot
Sep 17 22:16:29 <bluelightning> surely then it's a matter of setting PACKAGE_ARCH?
Sep 17 22:16:59 <ant_home> this or excluding the ssstate tasks
Sep 17 22:22:18 <ant_home> setting P_A
Sep 17 22:22:20 <ant_home> arm-oe-linux-gnueabi-klcc
Sep 17 22:22:57 <ant_home>  /oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/bin/poodle-oe-linux-gnueabi $ ls arm-oe-linux-gnueabi-klcc
Sep 17 22:23:21 <ant_home> no, it will create one each machine...
Sep 17 22:26:46 <ant_home> this will be confusing in klibc.bbclass where we set  export CC = "${TARGET_PREFIX}klcc"
Sep 17 22:28:39 <ant_home> hm... maybe rename it as klcc-${MACHINE}
Sep 17 22:29:00 <ant_home> I really feel guilty and ashamed for this recipe :P
Sep 17 22:48:07 <ant_home> thanks for the patience
Sep 17 22:48:09 <ant_home> gn
**** ENDING LOGGING AT Wed Sep 18 03:00:00 2013