**** BEGIN LOGGING AT Tue Jun 13 03:00:01 2017 Jun 13 05:35:26 hi all, while trying to bitbake for intel joule fails when compiling gcc 6.3.0, pls refer to partial logs here https://pastebin.com/gbrFtYv0 Jun 13 05:37:49 run.do_compile for the issue is here https://pastebin.com/FTm7C3Pz, any pointers Jun 13 05:52:39 RP: I've seen your yesterday's comment about "bigger problem with your distro_features change" - is that the same that Denys mentioned via email, i.e. expansion errors? Jun 13 06:38:10 pohly: that is one subset of problems, I have a second locally which Saur reminded me about yesterday Jun 13 06:38:26 pohly: I have a fix for the second set (I think) but not the first Jun 13 06:42:20 morning all Jun 13 07:05:59 RP: thanks for super fast morty backport Jun 13 07:14:42 RP: I replied with a patch to the "bitbake.conf: DISTRO_FEATURES as overrides" mail thread. Jun 13 07:16:17 RP: BTW, have you seen my proposed sanity check for conditional include/inherit/required in the discussion with Joshua Watt (in "Yocto Compatible 2.0 support code")? I think it finds a genuine issue in bitbake.conf, where include/require/inherit "conf/target/${TARGET_SYS}.conf" ends up looking for the wrong file. Do you agree that this line is broken? Jun 13 07:19:18 hello, I have a noob question, how do I add meta-python to yocto? I have added meta-openembedded layer (which contains meta-python and is also a dependency for meta-python) and added poky/meta-openembedded/meta-python to bblayers.conf Jun 13 07:19:25 however I get this: Jun 13 07:19:26 ERROR: Layer 'meta-python' depends on layer 'openembedded-layer', but this layer is not enabled in your configuration Jun 13 07:20:13 voltbit: 'openembedded-layer' is meta-oe Jun 13 07:20:59 yes I assumed so Jun 13 07:22:08 an I thought that is included by default Jun 13 07:22:48 voltbit: Nope. Jun 13 07:23:31 oh silly me ofc not works now Jun 13 07:23:33 thx Jun 13 07:50:10 I am getting 'do_package_qa: QA Issue: -dev package contains non-symlink .so' while trying to install a library recipe that should get a .so in the rootfs Jun 13 07:50:15 could anyone help me with that? Jun 13 07:51:33 tlk: you'll need to set FILES_${PN}-dev such that that file is not included Jun 13 07:52:58 could you explain why do I need to do that? Jun 13 07:53:12 right now, AFAIK,there is no -dev version of my package Jun 13 07:57:31 pohly: I was thinking we should remove that line FWIW Jun 13 07:57:42 JaMa: np, that one looked straightforward Jun 13 08:00:59 pohly: "My expectation is that OVERRIDES are part of the base hash" - that isn't correct Jun 13 08:02:15 hi all Jun 13 08:02:48 someone here can explain when do we have to use "+=" or "=" in recipes ? Jun 13 08:03:00 i mean with SRC_URI, FILES Jun 13 08:03:08 or anything else ? Jun 13 08:06:13 i founed it https://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#basic-syntax Jun 13 08:08:11 RP: then we need to consider more carefully whether (or rather, why) changing DISTRO_FEATURES_OVERRIDES works. Jun 13 08:09:21 pohly: "works" meaning what in this context? Jun 13 08:11:33 RP: that I can change DISTRO_FEATURES_OVERRIDES in local.conf and get the expected changes in "bitbake -S none" for a recipe which depends on the df- override. Jun 13 08:11:48 That's the systemd example at the end of my email. Jun 13 08:12:05 pohly: that doesn't rely on OVERRIDES in basehash... Jun 13 08:12:54 Meaning that my test was invalid, or that there is some other mechanism at work which causes the desired effect? Jun 13 08:13:05 pohly: the latter Jun 13 08:13:36 pohly: the basehash in your example stores the value of PACKAGECONFIG Jun 13 08:13:39 I've not analyzed why it works - as long as it does reliably and you understand why it does, that's enough for me ;-} Jun 13 08:14:14 pohly: the computed PACKAGECONFIG changes, the hash changes Jun 13 08:14:40 Does that work for all variables, or only PACKAGECONFIG? Sounds like it should work for all variables. Jun 13 08:15:13 pohly: its complex and depends how the value is calculated. We store the unexpanded value but post override application Jun 13 08:58:00 rburton: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/lib/oeqa/selftest/sstatetests.py?id=85dbd7bf9e4b6eccdbb8102e462dd681240c1c57 - if you have lots of differences all the subprocess calls cripple the system Jun 13 09:05:05 RP: hm Jun 13 09:08:36 rburton: I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=11651 Jun 13 09:08:37 Bug 11651: normal, Undecided, ---, jose.perez.carranza, NEW , test_sstate_noop_samesigs performance when there are differences is dire Jun 13 11:07:18 joshuagl: just saw that you resolved #6212. thanks, probably it was a leftover anyways Jun 13 11:08:01 LetoThe2nd: np, just looking through old bugs trying to clear some out Jun 13 11:41:47 Hi im tring to build a qt application that accepts touchscreen input. When i press the touchscreen evtest and libinput-debug-events connfirm that the touch events are detected. but my qt application is not responting to touch events Jun 13 11:44:51 Hi, has somebody managed to enable the PWM under a BeagleBoneBlack with Yocto? I couldn't find any examples that are working(yet). Jun 13 12:00:14 RP: what's your take on the distro feature overrides status? I've seen your patches around OVERRIDES vardeps, but that alone doesn't fix Denys' issue, does it? Are you working on something besides that I should test, or should I formalize my patch and submit it with a proper commit message for inclusion? Jun 13 12:02:17 pohly: I've been thinking about it. I think I'd much prefer we make this its own bbclass Jun 13 12:02:41 pohly: that in itself should make it get appended late enough in parsing that it solves Denys' issue Jun 13 12:02:59 pohly: the event handler approach has caused us pain before and I don't really want to go there Jun 13 12:04:01 So basically like distrofeaturesoverrides.bbclass in refkit, minus the renaming feature and plus the df- prefix? Jun 13 12:04:33 https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/distrooverrides.bbclass Jun 13 12:04:51 pohly: yes Jun 13 12:05:29 RP: I can prepare something, if you want. Jun 13 12:05:59 pohly: sounds good thanks Jun 13 12:06:30 pohly: in answer to your other part of the question, I found a number of ways changing DISTRO_FEATURES was causing things to rebuild when we wouldn't want them to. That was the intent of my other patchset Jun 13 12:06:58 RP: are there any other known problems left? Jun 13 12:07:23 pohly: not that I'm aware of. I just queued another test build Jun 13 12:12:11 do the autobuilders have swap ? Jun 13 12:12:20 joshuagl maybe ^ Jun 13 12:16:46 trying to figure out why bug 11608 would not appear on them -- webkit does look like it might try to use > 30 GB on its own if build is highly parallel Jun 13 12:16:47 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=11608 normal, Medium+, 2.4 M2, monserratx.sedeno.bustos, IN PROGRESS IMPLEMENTATION , distro-testing: Add ubuntu 17.04 to supported distros Jun 13 12:37:12 hi my QT framework is not touch events from libinput Jun 13 12:55:45 RP: are there ever valid cases where OVERRIDES should be in a signature? Jun 13 12:56:29 I'm going to use OVERRIDES .= "${@ ''.join([':df-' + x for x in sorted(set(d.getVar('DISTRO_FEATURES_OVERRIDES').split()) & set((d.getVar('DISTRO_FEATURES') or '').split())))]) }" Jun 13 12:57:51 And I intend to not add OVERRIDES[vardepsexclude] = "DISTRO_FEATURES_OVERRIDES DISTRO_FEATURES", arguing instead that OVERRIDES itself should be excluded. Jun 13 12:57:54 Does that sound right? Jun 13 13:01:35 pohly: no, not at all Jun 13 13:01:56 Hmm, so I need OVERRIDES[vardepsexclude]? Jun 13 13:01:59 pohly: please use DISTROOVERRIDES since that is what its designed for and OVERRIDES is position dependent Jun 13 13:02:12 pohly: you should not need to touch vardepsexclude Jun 13 13:03:07 I had DISTROOVERRIDES in the refkit class, but then couldn't find a good reason anymore for doing it that way. Jun 13 13:03:43 But if there are reasons, then I can of course also use DISTROOVERRIDES. Jun 13 13:06:36 Out of curiosity, does "position dependent" mean that FOO_bar will be used for ${FOO} instead of FOO_foo when bar comes before foo in OVERRIDES? Jun 13 13:07:36 jku: I believe so, yes Jun 13 13:12:53 joshuagl: so then maybe the ubuntu 17.04 test did not. Otherwise I don't really have ideas how we could defend from using too much memory... I love PARALLEL_MAKE and don't want to start limiting that. of course nightly-world could start setting PARALLEL_MAKE_pn-webkitgtk to a smaller number as a alternative last resort Jun 13 13:13:59 jku: I'm not sure how the ubuntu-17.04 builder is configured, it's a test machine in GDC. I agree disabling or reducing PARALLEL_MAKE for webkit would be bad. Jun 13 13:14:57 the amount of memory it uses did surprise me. I don't even want to imagine a debug build Jun 13 13:15:37 indeed :-/ Jun 13 13:15:48 wait do we acually build webkit as debug too ? Jun 13 13:17:15 no it's always "Release" Jun 13 13:29:05 jku: how much did it use? Jun 13 13:29:49 rburton: in the pathological "-j 44" case the webkitgtk compile task alone was above 30 GB Jun 13 13:29:57 haha Jun 13 13:32:43 "-j 8" still used around 7GB so on the autobuilders (with "-j 16") it's something in between Jun 13 13:33:35 simply download more ram Jun 13 13:34:26 jku: webkitgtk can use like 4gb just for the final ld process, it's nuts Jun 13 13:35:15 ed2: rburton: who wants this one? https://bugzilla.yoctoproject.org/show_bug.cgi?id=11652 (or should it be robert_yang?) Jun 13 13:35:16 Bug 11652: normal, Undecided, ---, paul.eggleton, NEW , mkfs.ext4 changes file/folder permissions when creating image Jun 13 13:35:32 robert_yang has prior in that Jun 13 13:35:42 I asked a friend who's an expert in the field: "if I don't pass -j here when building a debug checkout the entire machine freezes and I have to hard-reboot" Jun 13 13:35:56 rburton: ok, he's the e2fsprogs maintainer as well, will assign to him Jun 13 13:35:57 thx Jun 13 13:42:22 RP, rburton, etc: Is the minimum required host gcc version documented somewhere? I have not been able to find it, and have happily been using an old computer with gcc 4.7 to build Poky. However, I just tried to build the latest and now gdb fails to build since it apparently requires a host compiler that supports C++11 features... Jun 13 13:43:19 and i thought I was old school by having 4.9.2 on my build machine Jun 13 13:43:27 Saur: I happen to know its 4.8 Jun 13 13:43:39 Saur: that is the oldest of anything we test on Jun 13 13:43:46 RP: Is it documented somewhere? Jun 13 13:43:57 and are we checking it in sanity.bbclass? Jun 13 13:44:01 Saur: only in as much as the supprorted distro list Jun 13 13:44:23 we probably ought to explicitly mention it in the QS guide Jun 13 13:44:49 bluelightning: and a min version check in insane.bbclass? Jun 13 13:46:09 Oh well, I guess I'll just revert gdb for now. Won't have time to look at ordering a new computer till after my summer vacation anyway... Jun 13 13:46:14 Saur: interestingly sanity.bbclass does check for 4.5 or older Jun 13 13:46:25 See ;) Jun 13 13:46:39 RP: sanity.bbclass yes - incidentally we have oe.utils.host_gcc_version() that we can simply call when we do add the check Jun 13 13:47:01 Saur: would you be able to come up with a patch to add that? ;) Jun 13 13:48:59 bluelightning: Don't have much experience with neither sanity.bbclass nor insane.bbclass, whichever it is that is relevant in this case... Jun 13 13:49:20 Saur: I do mean sanity.bbclass in this case, my mistake Jun 13 13:51:32 hmm, is this check_gcc_march() stuff definitely not needed for 4.5+ ? Jun 13 14:00:24 bluelightning: I haven't see it trigger in years Jun 13 14:50:54 I am trying to write a recipe for a library that will install a .so file in the rootfs (a OpenSSL engine). It is failing with: "A Issue: -dev package contains non-symlink .so" Jun 13 14:50:57 Could someone help me with that? Jun 13 14:51:43 you're trying to do something that isn't standard. set FILES_${PN} to include ${libdir}/*.so Jun 13 14:52:00 I tried that, but it still complies Jun 13 14:52:13 Also, why is that non-standard? What would be the standard way to do it? Jun 13 14:53:45 tlk: You also need to add: Jun 13 14:53:45 ERROR_QA_remove = "dev-so" Jun 13 14:54:14 tlk: set FILES_${PN}-dev="" to stop it packaging into the -dev package first Jun 13 14:55:02 https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries covers how to package unversioned libraries Jun 13 14:55:25 Saur: you don't need to set ERROR_QA if you get files right Jun 13 14:55:54 rburton: Thanks, that seems to work Jun 13 14:56:01 I will check the link also Jun 13 14:56:39 Hello, I'm trying to use bitbake/openembedded to compile some changes I made to gst-plugin-vpe, however my do_configure is failing. Here is the log: https://pastebin.com/ndPbZPf0 Jun 13 14:56:49 (yes i'm that same idiot from yesterday) Jun 13 14:57:55 are you using externalsrc now? Jun 13 14:58:13 well i guess the first question is: does it work without your changes Jun 13 14:59:30 I'm not, I couldn't get externalsrc to locate any files. And depends, without my changes to the code or bb/bbappend files yes it works, but I've had to change the bb/bbappend files to look at my locally cloned source code after I made changes to it Jun 13 14:59:55 I just want to get to the do_compile stage, once I'm there I can fix my own source code if there's anything wrong Jun 13 15:00:04 please use externalsrc Jun 13 15:01:14 is there a particular reason to use externalsrc over just a bbappend with a different SRC_URI? Jun 13 15:01:23 because its not just that simple? :) Jun 13 15:01:36 rburton: Right, it's only needed if the foo.so happens to be a link... Jun 13 15:02:33 twall: inherit externalsrc, EXTERERNALSRC="/my/source/tree" Jun 13 15:02:57 tried that in local.conf as per the dev manual and it failed. Jun 13 15:03:19 now that you're doing it as the manual says, we can help Jun 13 15:03:25 okay Jun 13 15:03:25 define "failed" Jun 13 15:03:40 actually i think i know where it failed, one sec Jun 13 15:06:36 RP: what do you think: should this new distrooverrides.bbclass be inherited by OE-core by default, or should it be added together with adding to DISTRO_FEATURES_OVERRIDES? Jun 13 15:07:42 pohly: inherited when used? Jun 13 15:07:45 Enabling it by default would ensure that it is there when needed (feature slightly easier to use) and might expose problems earlier (because it is always at least parsed). But the other approach also works and might be preferred by those who do not want to use this feature at all. Jun 13 15:08:52 "inherited when used" is what I have now, but I am a bit undecided. Jun 13 15:09:38 I'm worried that we will miss corner cases again when it isn't part of the normal testing. Jun 13 15:09:38 pohly: we can always change that easily enough later Jun 13 15:09:54 Okay. Jun 13 15:10:10 pohly: what we may need is an example usage in poky Jun 13 15:10:52 I'm not sure whether there is a realistic example in poky. Jun 13 15:12:28 pohly: no :/ Jun 13 15:13:49 rburton: okay, I fixed the simple error I had in externalsrc (I had "file:///" instead of just the path name) and I managed to get it to do_install Jun 13 15:14:13 ah the class should handle that okay really Jun 13 15:14:32 it couldn't find the directory if I had it in Jun 13 15:14:34 * twall shrugs Jun 13 15:14:45 i mean, it doesn't but it should Jun 13 15:14:55 fair enough Jun 13 15:17:08 rburton: any feedback on http://lists.openembedded.org/pipermail/openembedded-core/2017-May/137309.html ? Jun 13 15:18:16 JaMa: looks like it shoudl just be closed instead of flushed Jun 13 15:18:29 sorry i missed that patch Jun 13 15:19:13 ah its a temporary file so will disappear Jun 13 15:19:18 yeah flush i guess Jun 13 15:20:16 fun to debug this, because it wasn't empty every time I've looked *after* the build :) Jun 13 15:20:52 and the output also had expected contents which oe-pkgdata-util was able to read Jun 13 15:21:58 JaMa: yeah i bet! sorry about that... Jun 13 15:22:22 your patch is in mut ow Jun 13 15:23:42 rburton: thanks Jun 13 15:24:42 there are 4 more with unknown status, should I resend them? Jun 13 15:24:45 a915cbb3a4 python-3.5: add runtime dependency from python3-compression on python3-misc Jun 13 15:24:48 60fb5676ea sstate-sysroot-cruft.sh: Extend the whitelist Jun 13 15:24:51 95ba7f0983 Revert "mesa: Contain configure search for llvm" Jun 13 15:24:53 0b3ac745b2 v86d,qemuboot-x86.inc: use KERNEL_MODULE_AUTOLOAD+KERNEL_MODULE_PROBECONF for uvesafb instead of fbsetup init script Jun 13 15:35:33 JaMa: re compression, bz2 and lzma sound like compressiony things to me: move them too Jun 13 15:36:38 JaMa: the lastest sstate-sysroot-cruft patch claims to be already applied Jun 13 15:36:38 denix: So, quick thing. Now that bitbake appears to enter the plugin directory and configure correctly, I think it's somehow misreading the makefile. it's stating that there's nothing to compile but there definitely should be. it gets to do_install and fails, since it cannot find an 'install' target, even if there's one present Jun 13 15:38:17 JaMa: re the mesa one, talk to khem. he was of the opinion that his patch was an improvement and if it breaks then reverting isn't the solution Jun 13 15:49:17 Hi guys, I've been trying to link up LLVM to another package, but I'm getting this error: https://gist.github.com/kratsg/10cf7835a83d4f17ad93173c8655c8e9 using CMake. How do I resolve this? I've been stuck for a few months now and I can't get anyone on the mailing list to respond. Jun 13 16:39:13 So, quick thing. Now that bitbake appears to enter the plugin directory and configure correctly, I think it's somehow misreading the makefile. it's stating that there's nothing to compile but there definitely should be. it gets to do_install and fails, since it cannot find an 'install' target, even if there's one present Jun 13 16:40:34 twall: thats not really bitbake/yocto, but the build system itself Jun 13 16:41:07 maybe the makefile doesn't handle out-of-tree builds? Jun 13 16:46:16 that's kinda what I'm figuring now. Out-of-tree build is a possibility, I hadn't thought of it. I know that this library gets compiled/built as part of the meta-arago layer from a git repo, and is installed to the default bitbake build location. Since I'm not adding any new files, just editing them, I'm using the same makefile. Jun 13 16:51:41 rburton: so essentially i think the makefile allows for out of tree builds, yet there may be something in here that's preventing me from doing so. perhaps configure was run incorrectly? Jun 13 16:52:43 twall: maybe. unless you share logs its hard to help Jun 13 16:53:44 oh! I guess i hit ctrl v instead of shift ctrl v. Here's the log: https://pastebin.com/eSLtq1sD Jun 13 16:54:06 it's not exaclty the most helpful. I'm going through the do_compile now Jun 13 16:54:12 and the do_configure Jun 13 16:54:28 re Jun 13 16:54:30 its going to be breaking in configure Jun 13 16:54:53 that makes more sense. it's not returning errors, just configuring incorrectly. Jun 13 16:55:32 twall: what did I miss? Jun 13 16:55:55 twall: that error usually means that make is being ran in the wrong directory Jun 13 16:56:35 denix: I managed to bitbake to find my cloned gst-plugins-vpe, but as rburton just stated, it appears that make is running in the wrong directory. Jun 13 16:58:14 going through the do_configure it appears that it's trying to find the config.log for unrecognized options in the wrong directory. So that's a clue. Jun 13 16:58:46 configure just threw a note saying that it couldn't find config.log, so it didn't pop up in bitbake Jun 13 16:59:08 do_configure output: https://pastebin.com/8q2E1kyg Jun 13 16:59:29 twall: it uses autotools-brokensep, so it expects to run everything in ${S}, not ${B} Jun 13 16:59:37 AH Jun 13 17:09:57 twall: your changes make it look for config.log in $WORK/gstreamer1.0-plugins-vpe/git-r2.14/gstreamer1.0-plugins-vpe-git/config.log Jun 13 17:10:32 twall: in reality, that file is in $WORK/gstreamer1.0-plugins-vpe/git-r2.14/git/config.log Jun 13 17:11:17 twall: see what changes your ${S}/${B} Jun 13 17:13:14 twall: bitbake gstreamer1.0-plugins-vpe -e | grep '^[SB]=' Jun 13 17:15:38 twall: Ok, externalsrc.bbclass does that when you don't set EXTERNALSRC_BUILD variable Jun 13 17:22:47 Ah, that would be it then. I didn't set that. Jun 13 17:22:53 uno momento Jun 13 17:26:58 denix: That's it! Now I'm getting regular old compilation errors like I should be, joyous day! Jun 13 17:27:47 thank you and rburton for helping me out (again) Jun 13 17:28:04 twall: :) imagine that - being happy about compilation errors... :) Jun 13 17:28:13 twall: you are welcome Jun 13 17:28:18 never thought I'd live to see the day haha Jun 13 17:28:37 honestly I'd rather get code errors than muddle with configuration endlessly Jun 13 17:53:17 denix: i wonder how externalsrc could detect that Jun 13 18:11:16 rburton: maybe check if brokensep class in in use and set EXTERNALSRC_BUILD accordingly? Jun 13 18:13:33 denix: i'm wondering if it should inspect S/B before altering them, curious how the forced B change actually works Jun 13 18:13:39 i'll speak to bl tomorrow Jun 13 18:14:18 Hey rburton or denix, are either of you using poky for your build? Jun 13 18:14:25 yes Jun 13 18:14:30 but i'm also going now Jun 13 18:14:49 Oh, okay. Jun 13 18:14:54 poky barely touches the configuration over the defaults fwiw Jun 13 18:14:59 aderbique: not primary distro for me, but I use it too Jun 13 18:15:18 Is anyone having build errors? The binutils repository seems to be offline or something. Jun 13 18:15:57 is there a reason we don't deploy the vfat partition for the raspberry-pi? Jun 13 18:18:24 if there are any rpi folks here, is there a better irc channel? Jun 13 18:18:24 aderbique: seems fine here - git clone git://sourceware.org/git/binutils-gdb.git Jun 13 18:21:50 @denix This is true.. but when my build runs, I get this output. This is the last bit of the output.Keeps saying that my connection is refused :( https://paste.ofcode.org/NNvUGKyD6dy7pNvaWAnYGv Jun 13 18:23:02 aderbique: are you behind a firewall? do you need to set up a proxy to access git? Jun 13 18:25:52 I am behind a firewall.. I'll have to look into a proxy for that. What's weird is the yocto build was working fine last week when I last tried. Do you think there it's worth cloning the pocky directory and trying everything over again? Jun 13 18:26:04 Also, thanks for the help :) Jun 13 18:27:30 aderbique: this might help - https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy Jun 13 18:29:54 denix: That's perfect! Thank you!! Jun 13 19:23:08 rburton, RP: whats your thoughts on gcc7 patches Jun 13 19:26:58 Hi guys, I've been trying to link up LLVM to another package, but I'm getting this error: https://gist.github.com/kratsg/10cf7835a83d4f17ad93173c8655c8e9 using CMake. How do I resolve this? I've been stuck for a few months now and I can't get anyone on the mailing list to respond. Jun 13 19:28:19 khem: need to run it through the ab again, i'll do that now with the ovmf update Jun 13 19:32:32 khem: fired on autobuilder.yocto.io Jun 13 19:36:14 rburton: https://autobuilder.yocto.io/builders/nightly/builds/361 Jun 13 19:36:17 is that the one Jun 13 19:37:06 yeah Jun 13 19:37:14 i find watching it in tgrid more useful Jun 13 19:37:19 * rburton off Jun 13 19:38:54 kratsg: use http://git.yoctoproject.org/cgit/cgit.cgi/meta-amd/tree/common/recipes-core/llvm for llvm rercipe see if this helps Jun 13 19:39:09 rburton: waterfall is also nice Jun 13 21:27:33 Hello - I have a Python app, with a config file that's a module called settings.py. Contents of settings.py is "settings = {'variable':'generated','by':'wic'}". Is there an easy way to generate that file in the wks? Jun 13 21:31:30 @khem tried the recipe, still the same error. I suspect I need to point the CMake at the right directory somehow. Jun 13 21:31:49 khem: * Jun 13 21:34:53 kratsg: it seems your package has to fix cmake files Jun 13 21:35:49 I mean, I *somewhat* find that hard to believe as it's a relatively large package (ROOT analysis framework, https://root.cern.ch/) Jun 13 21:36:39 kratsg: I have relatively newer llvm recipes in meta-clang you can try that Jun 13 21:36:54 someone in community has used llvm from it to link his packages Jun 13 21:37:22 although its a static compiler layer, I have added the patches to build llvm as shared lib Jun 13 21:37:41 I mean, so the other issue is that ROOT ships with a built-in LLVM if needed. Jun 13 21:38:10 If I use that, I end up with a different error about libatomic: https://gist.github.com/kratsg/027c92d0b020a594c9669a04f1457ed0 Jun 13 21:39:14 It's sorta confusing, because I think it's referring to the bitbake's gcc, rather than the host machine's gcc (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) Jun 13 21:56:26 I don't know how to solve this, as it seems to indicate gcc is too old somewhere, but I can't figure out where. Jun 13 22:55:20 yeah libatomic is a separate package and atomic support in gcc depends on version and arch Jun 13 22:55:29 you can depend on libatomic_ops **** ENDING LOGGING AT Wed Jun 14 03:00:02 2017