**** BEGIN LOGGING AT Wed Mar 28 03:00:01 2018 Mar 28 13:14:30 new meta-openembedded remote branch, "stagging/master-next" Mar 28 13:14:32 stagging ? :) Mar 28 13:16:53 hmmm, armpit was having a bad day yesterday :) Mar 28 13:48:43 what a staggering turn of events Mar 28 14:59:44 Crofton|work, go look at the conf contains in https://github.com/MontaVista-OpenSourceTechnology/meta-montavista-cgx.git Mar 28 15:00:12 and tell me what you see is wrong Mar 28 18:26:25 armpit: where do we collect patches from ml for testing Mar 28 18:26:35 it does not seem to be master-next anymore Mar 28 18:27:22 what repo ? Mar 28 18:31:58 * armpit meta-openembedded its stagging/master-next in the contrib repo Mar 28 18:33:40 hello Mar 28 18:36:40 ok Mar 28 18:37:22 did that answer you question? Mar 28 18:39:15 Let's say recipe 2 depends on recipe 1, which has a do_install() component. When recipe 2 is built, how can I get the do_install() in recipe 1 to execute *every time*? Mar 28 18:42:31 pstone: that sounds like a terrible idea Mar 28 18:47:46 this is a circular dependency problem Mar 28 18:47:58 we need to go to court to solve it Mar 28 18:54:02 Why does that sound terrible? The do_install() is quick. All it does is copy out-of-tree kernel module headers into the kernel build staging directory. Mar 28 19:13:15 pstone: I don't think do_install should be staging anything Mar 28 19:13:43 not as in staging for other recipes, that is Mar 28 19:15:09 do_install installs under ${D} and then OE will take care of staging files from there to the sysroot Mar 28 19:15:45 the kernel is a little different than other recipes of course, but you should be able to see other examples of out-of-tree kernel modules for examples Mar 28 19:41:32 Thanks bluelightning. I am doing some reading to try to understand how kernel module stuff is staged. Mar 28 21:15:53 So, the purpose of having a recipe solely for copying the kernel module headers to the kernel staging directory is that we have an application which depends on the kernel module headers. However, we don't want to make the application depend on the kernel modules compiling, or the kernel compiling, for that matter. The kernel modules will be built for a full image. Given that our application does not DEPENDS on the kernel modules, the header Mar 28 21:15:53 files are often removed from the kernel build staging directory, which is where I think they are needed in order for our applicatioon to compile. So, we have a work-around recipe which copies the out-of-tree kernel modules header files to the kernel build staging directory. Given that this is not working, and we don't want our application to DEPENDS on the kernel modules compiling, what would be the proper way to handle this? Mar 28 21:16:46 In all instances where I said "kernel module", I meant "out-of-tree kernel module". Mar 28 21:23:26 I think that our current work-around is not working, because although our application DEPENDS on the recipe to copy over the out-of-tree kernel module headers, the do_install() of the recipe often decides not to run. So, that's why I made the request to force it to run all the time. Currently, we have to recognize when compiling fails due to missing out-of-tree kernel module header, and then we have to clean and build the kernel modules, eve Mar 28 21:23:26 n though we may not want or need the kernel modules. We just need the header files, so that the application will compile. Mar 28 22:11:50 ok, why would I be unable to styart the bitbake server from a jenkins job? Mar 29 00:12:33 if i use "devtool modify " then "devtool build " and the is autotooled, where does the build take place? Mar 29 00:13:04 when building "normally", there is a directory called "build" in the ${WORKDIR}, but it doesn't seem to be used with devtool Mar 29 00:27:01 tlwoerner: it's in the same place as it is normally... it's just that the source isn't there, it's in the workspace Mar 29 00:27:24 tlwoerner: it does create a symlink in the source tree to the workdir so you can find it a bit more easily Mar 29 00:29:55 bluelightning: hmm... i see my problem, i'm making changes to configure.ac and all "devtool build" wants to do is build, not configure -> build Mar 29 00:30:02 is there a "devtool clean" sort of thing? Mar 29 00:30:35 (i don't think this is devtool's fault, i think this package's autofoo isn't complete) Mar 29 00:40:21 tlwoerner: exactly, devtool is doing the right thing here Mar 29 00:40:48 tlwoerner: you can complement it with bitbake -ccleansstate Mar 29 00:41:06 then devtool build should rerun configure Mar 29 00:41:50 I did use it on coreutils recently, and it reran do_configure automatically when I Changed configure.ac **** ENDING LOGGING AT Thu Mar 29 03:00:03 2018