**** BEGIN LOGGING AT Sun Jul 10 02:59:58 2016 Jul 10 14:13:17 greetings Jul 10 14:14:46 I am working on a project using c++ and a graphics library called opencv. My end product is an embedded system that processes video streams. Is there a recommended GUI library that I should be using? Jul 10 14:15:59 it would be nice if I could develop for the gui on my computer first before going to embedded, it would also be nice to build for something that is compatible from the get go. Jul 10 19:13:07 hi, today I tried to speed up our ci server a bit by copying the sstate directory to the freshly checkout one.. but it does rebuild glibc-initial and as a consequence almost everything.... Jul 10 19:14:04 is there a) some way to get info why bitbake thinks it needs to be rebuild? Jul 10 19:14:20 b) a better way to move sstate instead of copying it? Jul 10 19:44:22 jeroen: you don't need to copy sstate at all, just point at it with SSTATE_MIRRORS Jul 10 19:44:42 and if it's rebuilding, use bitbake -S printdiff to see why, if the info is available Jul 10 19:50:09 kergoth: thanks Jul 10 19:50:27 kergoth: this doesn't work export SSTATE_MIRRORS=/media/data/autobuild/venus-jethro-cortexa8hf/build/sstate-cache/ Jul 10 19:50:42 that's not how SSTATE_MIRRORS works, read the yocto project documentation Jul 10 19:50:49 1. that var is set in local.conf, nto the env Jul 10 19:50:50 kergoth: better to put it in local.conf? Jul 10 19:50:53 2. that's the wrong sytnax for that variable entirely Jul 10 19:53:00 kergoth: should it error if the syntax is incorrect? anyway, trying again.. Jul 10 19:53:23 again, read the docs if you want to use the variable, what you just showed will fail, because the syntax is wrong Jul 10 19:59:18 kergoth: the main sstate will rebuild occasionally so I guess I do want to have a copy.. Jul 10 20:04:50 ? Jul 10 20:05:35 the first thing worth noting is sstate is cumulative. if you aren't clearing it out or wiping it periodically, it'll just keep adding more sstate to the sstate dir. it's completely harmless to share a single sstate dir amongst a ton of product versions, machines, distros, etc Jul 10 20:09:47 kergoth: pfffff I give up for now, can't get this to work, can't get toaster working ..... :( Jul 10 20:16:27 kergoth: I know you trust sstate, I don't, more then I would like cleanall "fixes" things... Jul 10 20:17:33 most likely you're misdiagnosing the problem, and it was the clean, not the sstate removal, that was the factor Jul 10 20:17:47 tons of us runs 10s of builds a day across 4 different yocto releases and never hit such a problem Jul 10 20:17:51 what i would like to have is a (weekly?) rebuild of all, and incremental builds on a copy of its sstate Jul 10 20:18:20 that's a common way to do it, yes Jul 10 20:20:59 kergoth: well as said, I am going to give up for now, the problem is the incremental build rebuilds everything again ... :( **** ENDING LOGGING AT Mon Jul 11 02:59:58 2016