**** BEGIN LOGGING AT Tue Aug 02 02:59:57 2016 Aug 02 08:07:43 good morning Aug 02 11:56:47 is it possible, that recent bitbake (?) master does not make an implicit 'cd ${S}' anymore before running new tasks? Aug 02 11:57:29 s!task!postfunc! Aug 02 11:58:50 ensc|w: yes, and it's $(B) Aug 02 11:58:58 (see the git log) Aug 02 11:59:50 either add [dirs], a cd, or use absolute paths as appropriate Aug 02 12:02:10 mmmh... can cause silent breakage Aug 02 12:04:08 fortunately I am not doing 'rm -rf *' in my postfunc... Aug 02 12:33:51 is there a simple way to remove a 'postfunc'? E.g. I want to do basically 'do_unpack[postfuncs]_remove = "do_qa_unpack"' Aug 02 12:47:00 ensc|w: so silence the qa check? just set S=${WORKDIR} Aug 02 12:49:02 rburton: does not work; B becomes WORKDIR too Aug 02 12:49:12 (which creates a lot of pollution) Aug 02 12:50:32 all the sanity check is checking that the directory you have for S actually exists Aug 02 12:51:00 (note that master only checks if SRC_URI is actually set, to avoid false positives where you have nothing to unpack) Aug 02 12:51:19 I can write 'B := "${S}"' + 'S = "${WORKDIR}"' but I am not sure whether this really works Aug 02 12:51:51 check is broken imo; it should be executed only when SRC_URI contains ann archive file Aug 02 12:52:37 do you basically want a directory to do *stuff* in that isn't WORKDIR, but you're not unpacking anything? Aug 02 12:53:10 (but you also do have a SRC_URI) Aug 02 12:54:32 yes; e.g. https://github.com/sigma-embedded/elito-de.sigma-chemnitz/blob/master/recipes/helloworld/helloworld.bb.sample Aug 02 12:54:51 or https://github.com/sigma-embedded/elito-de.sigma-chemnitz/blob/master/meta/recipes/dtree-pins/mx6-pins.bb (which is a real world project) Aug 02 12:57:26 ensc|w: S=${WORKDIR} B=${WORKDIR}/build" Aug 02 13:00:11 rburton: yes; two line more which are only needed to silence the check Aug 02 13:00:37 well S is then accurate, as that's where the sources are, and B is where you want the build to happen Aug 02 13:01:18 patches welcome to iterate the SRC_URI in the sanity check and look for archives to handle this case Aug 02 17:51:03 otavio: I found the problem I was having yesterday, the dependent package got deinstalled from the original staging root, and reinstalled in the new staging root. the applications using the library still head dangling paths to the old staging dir.. Aug 02 17:51:54 jeroen__: right; the point is you should use different build directories for different distros. Aug 02 17:51:58 so it was not, as I thought, that the task was not executed. instead running a make distclean in the application package makes things work again... Aug 02 17:54:42 no this works fine..... (for me at least) Aug 02 18:37:00 jeroen__: and this is why our autotools class defaults to out of tree builds, and we try to run make clean before configure Aug 02 18:37:14 jeroen__: (because software is really bad at rebuilding) Aug 02 18:46:25 rburton: yes I am basically doing the same now (distclean instead). but software is typically bad at building out of tree as well ;) Aug 02 18:48:21 Hi folk! i'm using systemd in my distro but the system_216.bb install several unused files into my system, someone has some tip to reduce the systemd installation? Aug 02 18:54:50 I have another funny problem for the pet project, I have a bbclass which add 'addtask extract_deb after do_install before do_populate_sysroot do_deploy' Aug 02 18:57:02 and a bbappend which adds 'addtask fix_deb after do_extract_deb before do_populate_sysroot do_package' and install in $D Aug 02 18:57:48 however these file don't make it to the sysroot... but I fail to understand why at the moment.. Aug 02 23:00:20 Poky LTS? Aug 03 01:13:17 * nerdboy does the fork-add-push dance **** ENDING LOGGING AT Wed Aug 03 02:59:58 2016