**** BEGIN LOGGING AT Fri Feb 16 03:00:01 2018 Feb 16 09:41:52 Does anyone know whether the opendreambox folks are using oe-core these days or did they just "run" with oe-classic and continue based on that? Feb 16 09:49:40 hello all, I have one problem which I need to solve. I need to run one task for all the native and cross recipes. For that I create a new class and add a new task in it ad inherit all the recipes from it. the proble is this task need a package which needs to be build natively. So when I create a native recipe for that pakage and add dependency of to that recipe from the class it gives me a circular dependency problem. how can I solve this Feb 16 10:13:32 mickeyl: they use oe-core Feb 16 10:13:49 excellent, thanks Feb 16 10:14:17 mickeyl: but it seems like they have their own fork, heavily customized and somewhat outdated Feb 16 10:14:40 Noor: what does the task do? Feb 16 10:16:41 kergoth: there is a license scanning tool which we have to build and use for all the recipes. That task basically run that scan tool which will be built via another recipe Feb 16 10:17:07 but we cannot create its native recipe Feb 16 10:17:32 if we add INHERIT of the new class in any conf file Feb 16 10:18:16 Noor: are you basically reinventing meta-fossology or such? Feb 16 10:18:28 Noor: not sure why you need to run it for native recipes. those won't go into product images. Feb 16 10:19:37 Noor: if the legal department insists, and who we are to argue with them, generally there is no solution. you need to install the license scanning tool on the host and whitelist it. Feb 16 10:19:45 kanavin: depending on the interpretation of gplv3 it can be necessary. Feb 16 10:20:44 LetoThe2nd: let me look at meta-fossology Feb 16 10:20:55 LetoThe2nd: I'm curious about the interpretation Feb 16 10:21:51 kanavin: it requires you to hand out scripts and tools that are needed to actually install the image. so *if* you would need some specific preprocessing that happens in the native space, it might be needed. Feb 16 10:22:39 LetoThe2nd: yeah, but only if the image has gplv3 components Feb 16 10:22:49 kanavin: if somebody wants GPLV3 even on the native side so we have to run it on native recipes too Feb 16 10:23:09 kanavin: thats why i explicitly said interpretation of gplv3 :) Feb 16 10:24:11 LetoThe2nd: Noor: I'd say it is a gross misinterpretation. GPL licenses, even v3 ones do not restrict the use of gplv3 software in any way whatsoever. The terms kick in only if you distribute it. Feb 16 10:24:16 LetoThe2nd: do you have meta-fossology link I am not able to find it out Feb 16 10:24:27 but again who am I to argue with lawyers Feb 16 10:24:36 kanavin: absolutely true Feb 16 10:25:21 kanavin: LetoThe2nd: secondly legal want full review of native and cross packages Feb 16 10:26:07 Noor: legal are over-reacting imo. I'm not sure you can even exclude gplv3 from the native side anymore. Feb 16 10:26:13 just to see there isn't any problematic license in the the packages which are being used and distributed Feb 16 10:27:05 kanavin: its not only GPLV3 its jsut they want to view licenses used on native packages as well Feb 16 10:27:25 kanavin: yeah. libstdc++ FTW Feb 16 10:28:16 Noor: toganlabs do such a thing, see http://layers.openembedded.org/layerindex/branch/master/layer/meta-license-tools/ Feb 16 10:28:47 LetoThe2nd: thanks Feb 16 10:30:10 the first line of README "This layer needs fossup and a working fossology instance." :) Feb 16 10:30:45 so this gives me answer to my original question that the work that I was trying to do is not possible Feb 16 10:30:50 thanks guys Feb 16 10:31:09 huh? Feb 16 10:31:39 you said you want to do license scanning. you never stated that it must be build directory contained. Feb 16 10:32:20 Noor: that makes some kind of sense, but you do need to stress the point that native packages are not being distributed with the product, and therefore terms that come with distribution do not apply. Only terms that govern the use, and in OSS world that is pretty much unrestricted. Feb 16 10:32:54 sure Feb 16 10:34:31 just one thing came to my mind. this just for my knowledge can we like override INHERIT command using a python function. Say if we have INHERIT ABC in config file can we create a python function to remove it or kill it in a recipe Feb 16 10:34:38 is it possible Feb 16 10:35:11 I could see a problem if, for instance, some -native tool comes with terms that only allow hobbyist and non-commercial use, but this just isn't in any regular license. Feb 16 16:11:24 * armpit is seeing a bunch of " suspicious values 'initd-functions-dev' in RRECOMMENDS [multilib]" Feb 16 16:12:20 * armpit seems like a regression in core Feb 16 16:15:41 * armpit maybe cdcebd81c872cb7386c658998e27cf24e1d0447c Feb 16 16:27:53 * armpit wow why are we not seeing that more **** ENDING LOGGING AT Sat Feb 17 03:00:00 2018