**** BEGIN LOGGING AT Tue May 10 02:59:59 2016 May 10 07:38:00 good morning May 10 13:43:01 heeen: please summarise your doubt May 10 14:36:02 e May 10 23:45:10 smurray: hey - just finished watching your ELC presentation via youtube, thanks; I made a few comments there FYI May 11 00:02:59 bluelightning: thanks for the comments. wrt to debugging sstate issues is there documentation on how to go about doing that? May 11 00:03:11 smurray: there May 11 00:03:34 smurray: there's general documentation about sstate which may cover that, let me have a look May 11 00:04:07 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache May 11 00:04:26 there's a "Tips and tricks" subsection further down that has some debugging info May 11 00:06:09 bluelightning: I'll give it a read. May 11 00:08:48 bluelightning: wrt devtool and the extensible SDK, I definitely need to play with them some more. May 11 00:09:02 ok, no worries May 11 00:09:09 the docs improved further in 2.1 FYI May 11 00:09:38 bluelightning: yeah, I was looking at the devtool docs in 2.1 May 11 00:12:18 bluelightning: I must admit that it's still not obvious to me how I could leverage eSDK in my customer's environment (100s of devs, shared install on NFS, with archiving of previous releases) May 11 00:12:51 it won't work well in the shared NFS scenario, that is true May 11 00:13:37 it could be that we need to adjust the structure a little so that that's possible May 11 00:15:02 bluelightning: they're happy with the regular SDK, so not a big problem. It'd be nice if I could get it installed to the NFS server faster ;) May 11 00:15:57 surely the solution there is do the install on the server itself ;) May 11 00:16:20 otherwise we're just untaring a tarball, I don't think there's much we can do to speed that up May 11 00:20:31 bluelightning: their IT locks things down, complicates life. wrt speed, I was thinking the relocate script took a bunch of time, but I've not double-checked that theory May 11 00:24:17 I'd have to check myself, but I don't think that part takes a huge amount of time, though it may depend on what you have in your SDK of course May 11 00:25:17 btw re the relocation after the fact, that is something we could look to change; i.e. we could leave the relocation script there and re-run it when sourcing the env setup script if the path has changed May 11 00:25:22 brb May 11 02:21:14 We're using bits for auto-relocation of sdk at source-time in meta-mentor. not as clean as i'd like, though, which is why I haven't submitted it to oe-core yet. https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/classes/sdk_auto_relocate.bbclass + https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/recipes-core/meta/nativesdk-sdk-relocate.bb -- the ugliest bit is i didn't feel like invasively reworking May 11 02:21:14 it in the core just then, so right now it hacks at toolchain-shar-relocate.sh (which, incidentally, is some terrible shell scripting) May 11 02:21:16 bluelightning: ^ May 11 02:21:52 kergoth: ok, I'll take a look, thanks May 11 02:22:14 refactoring and submitting is on the radar, just behind other higher priority bits :) May 11 02:25:37 we have an sdk-like construct which is aligned iwth the yocto sdk but distributes in a different way, and that distribution mechanism lacks post-install scripts, so had to work around that to get it relocated, otherwise probably wouldn't have bothered May 11 02:25:38 heh **** ENDING LOGGING AT Wed May 11 02:59:58 2016