**** BEGIN LOGGING AT Thu Oct 20 02:59:59 2016 Oct 20 09:16:29 all my github oe forks are from O.S. Systems Software LTDA Oct 20 09:16:33 Is that right? Oct 20 09:16:45 I cant remeber these forks... did someone change the name? Oct 20 09:21:38 pompomJuice: if you're targetting fsl/imx that should be fine, AFAIK its the company name of otavio Oct 20 09:22:44 Yea I have been dormant on my OE development for a while. Oct 20 09:22:50 These guys are rockstars Oct 20 09:23:04 They really help me get shit done here at my end. Oct 20 09:23:36 koen: are you sure you can build android-tools-native, even with your last patch? it doesn't work for me. Oct 20 09:23:36 fatal error: bsd/string.h: No such file or directory Oct 20 09:23:36 though the files exist in sysroot Oct 20 10:01:23 ndec: doing a build right now to double check Oct 20 11:13:33 maxin: I got opendjk-8 compiled by introducing those oe-core patches. But now I am struggling to compile my java program. The java & javac installed in sysroots are from the boostrappers, and the openjdk-8 ones reside in sysroots/x86_64-linux/usr/lib/jvm/openjdk-8-native. Oct 20 11:13:34 My question is, if I want to write a recipe to compile a java app must I set JAVA_HOME manually then? Because most build systems find java through PATH. Oct 20 11:14:03 When I set my JAVA_HOME to sysroots/x86_64-linux/usr/lib/jvm/openjdk-8-native my programs compile. Oct 20 11:35:10 pompomjuice: great .. generally, build process differs for projects (whether you use ant for build) Oct 20 12:03:03 maxin: I use gradle. I am trying pull levers at the moment. Like setting virtual_java-native=openjdk-8-native amd virtual_javac-native=openjdk-8-native. But in general it seems that if I set JAVA_HOME everything works as expected Oct 20 12:24:09 pompomjuice: have to confess that I haven't used gradle yet :) Oct 20 14:46:52 Hi all, I'm trying to use the devtool script to build one of my project's components from a local source tree rather than pulling from an upstream git repo. I ran "devtool -d -d modify -x enigma2 enigma2.working" to get the local tree, but when I try to build I get breakage like this: http://pastebin.com/75Z07CFw Oct 20 14:47:41 it looks as though bitbake is confused because SRCREV is set in the main enigma2.bb file, but then EXTERNALSRC is overriding the source URI Oct 20 14:47:51 am I doing something wrong here? Oct 20 14:48:22 (btw, I'm building the OpenPLi tree, which is based on oe-core plus a bunch of extra layers) Oct 20 18:00:15 is there a preferred way to make a version of one package depend on a specific version of another package? Oct 20 18:00:28 specifically due to API changes? Oct 20 18:33:06 mattsm: the binary package managers support it, but bitbake does not Oct 20 18:33:31 kergoth: Yea, I noticed RDEPENDS foo but that won't help for the build... Oct 20 18:34:02 does one just make a new package with the version embedded in the name? Or try to sprinkle PREFERRED_VERSION everywhere Oct 20 18:34:26 the former is unlikely to work the way you want, bitbake could easily end up buidlng both versions due to conflicting deps and end up with conflicting files in the sysroot Oct 20 18:35:16 Can you banish the other versions? Oct 20 18:36:56 not sure what you mean. bitgbake only maintains a single sysroot across the entire build for all recipes, nothing is cleaned out except for the case of version updates and provider preference changes Oct 20 18:37:35 if you can avoid the conflict, it's doable. for example, glib-1.2 vs glib-2.0 already separates their include files and whatnot to avoid the conflict. i.e. /usr/include/glib-1.2/ Oct 20 18:37:51 so nothing steps on one anothers toes, either on target or the sysroot, in such a case Oct 20 18:38:07 but if they conflict file wise, there's not much you can do about it other than specifying your preferences so only one version, the version you need, is built Oct 20 18:42:31 i'd love to see depends gain versions so it can abort if you end up with a configuration that isn't buildable Oct 20 18:57:27 rburton: agreed Oct 20 22:04:57 rburton: kergoth: agreed ;) Oct 20 22:05:52 +1 Oct 20 22:14:42 anyone got ideas how to build firmware as part of my regular build process? Oct 20 22:15:19 I have something that happens to work because the MCU is armv6 and my target's compiler can also build it, but ... wouldn't work if I used a x86 target e.g. Oct 20 22:15:27 because compilers don't magically 'match' Oct 20 22:16:16 maybe I'm commiting gross abuse here Oct 20 22:19:34 sounds legit to me Oct 20 22:20:06 Crofton|work: you'd need somehow composite targets Oct 20 22:36:52 the multiconfig functionality is intended to support that kind of thing Oct 20 22:37:19 it's in master / upcoming 2.2, I'm not sure whether all the issues got sorted out Oct 20 22:39:50 bluelightning: interesting Oct 20 22:40:40 multiconfig is functional, but not yet polished Oct 20 22:40:57 here's Richard's commit message where he added it for some background: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=218b81acb682bf0006afeb1a5c7bc4adf0549796 Oct 20 22:41:00 thx guys, will take a look Oct 20 22:42:20 you can always check in the binary, but building the4 entire thing is cool Oct 20 23:34:13 multiconfig is right approach yes, it will cover the baremetal case along with hosted( linux ) targets then you are covered for building MCU apps with baremetal target and build the app side normally Oct 20 23:34:22 and both can be different arches Oct 20 23:52:01 khem: thx **** ENDING LOGGING AT Fri Oct 21 02:59:58 2016