**** BEGIN LOGGING AT Tue Sep 24 02:59:59 2013
Sep 24 07:50:28 <ant_work> bluelightning: gm
Sep 24 07:56:22 <bluelightning> morning ant_work
Sep 24 07:56:54 <ant_work> bluelightning: playing improperly with sstate and tasks I think I'm hitting some unforeseen corner-cases ;)
Sep 24 08:00:56 <ant_work> but I smell a bug somewhere: yesterday again a >> was executed for a second MACHINE w/out rebuilding the do_populate_sysroot sstate
Sep 24 08:01:09 <ant_work> so the inputs should have changed
Sep 24 08:01:38 <ant_work> and it's bizarre the second build could find the file to append to
Sep 24 08:02:25 <ant_work> so, it happened with kexecboot-cfg which is normal target package
Sep 24 08:02:43 <ant_work> but again with klcc-cross which inherits cross.bbclass and its redefinitions
Sep 24 08:02:48 <ant_work> strange
Sep 24 08:03:44 <ant_work> my idea was to purposedly invalidate the sstate cache
Sep 24 08:04:05 <bluelightning> well clearly whatever you have done hasn't added the dependency in the right place
Sep 24 08:04:10 <bluelightning> what is a >> ?
Sep 24 08:04:31 <ant_work> so echoing "# Headers for: ${STAGING_DIR_HOST}" >> klcc/klcc
Sep 24 08:04:36 <ant_work> err
Sep 24 08:04:43 <ant_work> so echoing "# Headers for: ${MACHINE}" >> klcc/klcc
Sep 24 08:05:04 <ant_work> it did append for poodle then for spitz :/
Sep 24 08:05:13 <ant_work> 2 lines
Sep 24 08:05:23 <bluelightning> why are you appending and not just creating?
Sep 24 08:05:55 <ant_work> I have tried also creating and installing a target.txt file
Sep 24 08:06:31 <ant_work> I have to invalidate the tasks before sstate do_populate_sysroot
Sep 24 08:07:14 <ant_work> I guess that the barrier here is, the package is not machine specific
Sep 24 08:09:02 <ant_work> finally, cross.bbclass redefines
Sep 24 08:09:04 <ant_work> do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}/${STAGING_DIR_NATIVE}/"
Sep 24 08:09:04 <ant_work> do_populate_sysroot[stamp-extra-info] = ""
Sep 24 08:10:00 <ant_work> well, I've tried with violence to add STAGING_DIR_TARGET but I get a message that my sstate is messed up
Sep 24 08:10:43 <ant_work> also I've tried to add do_populate_sysroot[stamp-extra-info] ="${MACHINE}"
Sep 24 08:10:47 <ant_work> no effects
Sep 24 08:14:16 <bluelightning> sorry, I wish I knew how to help, but this is not an area I am familiar with
Sep 24 08:14:54 <ant_work> I know I'm on a border case...
Sep 24 08:15:07 <ant_work> tehre is one more thing I can try:
Sep 24 08:17:20 <ant_work> instead of staging the klibc's ARCH headers in STAGING_DIR_TARGET I could try to put them under STAGING_DIR_HOST, under i686/lib/armvX-linux-gnueabi/klibc
Sep 24 08:17:37 <ant_work> per ARCH
Sep 24 08:17:58 <ant_work> or under /opt even
Sep 24 08:18:11 <ant_work> somewhere but not in target sysroot
Sep 24 08:18:57 <ant_work> this would solve the rot issue of klcc prefixes containing MACHINE
Sep 24 08:23:36 <ant_work> well, I found out you had similar doubts long ago ;)
Sep 24 08:23:37 <ant_work> http://lists.openembedded.org/pipermail/openembedded-core/2011-August/047339.html
Sep 24 08:27:00 <ant_work> ah, I think it's this
Sep 24 08:27:02 <ant_work> http://lists.openembedded.org/pipermail/openembedded-core/2012-October/070027.html
Sep 24 08:27:25 <ant_work> This means we do less work where there are multiple machines using the same
Sep 24 08:27:25 <ant_work> core package architecture and we can start to clean up the sstate duplicate files
Sep 24 08:27:25 <ant_work> whitelist.
Sep 24 08:30:55 <ant_work> this is the wall
**** ENDING LOGGING AT Wed Sep 25 02:59:59 2013