**** BEGIN LOGGING AT Thu Mar 28 02:59:57 2019
Mar 28 03:22:17 <yocti> New news from stackoverflow: how to generate compile database with bitbake? <https://stackoverflow.com/questions/55389645/how-to-generate-compile-database-with-bitbake>
Mar 28 04:22:27 <yocti> New news from stackoverflow: How to disable certain keyboard keys in yocto <https://stackoverflow.com/questions/55390068/how-to-disable-certain-keyboard-keys-in-yocto>
Mar 28 04:49:09 <khem> rburton: python2 is needed for llvm during build time see https://github.com/kraj/llvm-project/blob/master/llvm/CMakeLists.txt#L670-L684
Mar 28 07:53:05 <yocti> New news from stackoverflow: ERROR: useradd: useradd command did not succeed in Yocto build <https://stackoverflow.com/questions/55392125/error-useradd-useradd-command-did-not-succeed-in-yocto-build>
Mar 28 08:11:11 <mkhoory> so I made a graph of the dependencies for core-image-minimal and now I'm converting the .dot file to ps. It's taken 8.5 minutes and it's still not done. Am I doing it wrong? lol
Mar 28 08:11:50 <mkhoory> I'm new to yocto and I just wanted to get an overall understanding of what went into my image and why
Mar 28 08:12:14 <LetoThe2nd> mkhoory: as we don't know how you're doing it, how could anyone comment? but yes, the .dot files are LARGE. to the point where the usual suspects (xdot, etc) can't display them anymore.
Mar 28 08:16:53 <mkhoory> LetoThe2nd, well, I used bitbake -g core-image-minimal, and that generates a .dot file, and now I'm compiling it to  ps with 'dot -Tps task-depends.dot -o taskdepends.ps
Mar 28 08:17:33 <mkhoory> I guess reading the dot file might be more practical than trying to convert it to a graph :)
Mar 28 08:17:39 <LetoThe2nd> mkhoory: eeeexactly.
Mar 28 08:17:52 <LetoThe2nd> i usually just open it in vim or such
Mar 28 08:18:52 <mkhoory> ah! what I should've done is convert the recipe depends file, not the task!
Mar 28 08:19:06 <mkhoory> it's a lot smaller
Mar 28 08:19:22 <mkhoory> and is really more of the infromation that I'm looking for
Mar 28 08:43:13 <RP> mkhoory: "bitbake core-image-minimal -g -u taskexp" may interest you
Mar 28 08:43:26 <RP> mkhoory: its a gtk UI which lets you explore the dependencies
Mar 28 08:43:44 <RP> very simplistic but might help
Mar 28 08:47:16 <mkhoory> ah interesting, will give it a try
Mar 28 08:56:47 <mkhoory> RP, that gives me task dependencies. Can I get recipe dependencies?
Mar 28 08:58:21 <RP> mkhoory: recipe dependencies get very confusing as the collapsed graph is circular in many cases. The simple answer is no, not really
Mar 28 08:58:43 <RP> mkhoory: we used to offer that data but it just mislead and confused people
Mar 28 09:00:47 <mkhoory> I see
Mar 28 09:01:53 <LetoThe2nd> RP: you mean, confuse them even more? :P
Mar 28 09:06:15 <RP> LetoThe2nd: perhaps ;-)
Mar 28 09:07:11 <RP> mkhoory: you could trivially write a script which just collapses all the dependencies in that dot file and then you'd have the recipe dependencies fwiw. I'm not sure it would be what you actually want though
Mar 28 09:23:24 <yocti> New news from stackoverflow: QML debugging & qmljsdebugger profiling is not working on RPI with Yocto (poky-pyro) <https://stackoverflow.com/questions/46700219/qml-debugging-qmljsdebugger-profiling-is-not-working-on-rpi-with-yocto-poky-p>
Mar 28 09:39:38 <mkhoory> Question: If I have a bunch of custom software I'd like to write for my target, but this software needs to be bundled in with the image, but at the same time, I'd like them to be updateable during runtime.. Is it more suitable to write this software through the SDK, or bundle it in with the image as a layer?
Mar 28 09:40:01 <mkhoory> or am I thinking in a fundamentally incorrect way?
Mar 28 09:43:31 <LetoThe2nd> mkhoory: the latter :)
Mar 28 09:44:09 <mkhoory> as in bundle it with the image as a layer, or am I thinking wrong? :P
Mar 28 09:44:47 <LetoThe2nd> mkhoory: as in "thinking wrong" :-) you write recipes for the software, so they can be bundled into image. AND you enable runtime package management. through the latter, you can then update the applications just almost like on an ordinary distirbution
Mar 28 09:46:35 <mkhoory> I think I understand
Mar 28 09:47:12 <LetoThe2nd> mkhoory: but if your usecase actually is "it has to work basically like debian" (or insert your personal favorite), then you might be better off actually just using that, and save yourself the effort to first understand a tool that might be suited badly, and then beat it into another shape
Mar 28 09:47:48 <mkhoory> Yeah I'm still in the process of figuring out whether Yocto is best suited for my needs
Mar 28 09:47:48 <LetoThe2nd> mkhoory: so it really depends on a lot of variables
Mar 28 09:48:45 <LetoThe2nd> mkhoory: i mean, the beagleboard crowd started with an OE-based distribution back then, and is shipping debian since a couple of years by default for example
Mar 28 09:49:02 <mkhoory> Debian is most likely not what I want.
Mar 28 09:49:29 <LetoThe2nd> mkhoory: because debian suits the majority of users better. and for those who need something different, they can always build poky for their boards.
Mar 28 09:49:49 <mkhoory> What I really want, is a kernel, with any required supporting libraries/software, and my own custom written software (which I havent written yet) that does specific tasks, which I can update after deployment
Mar 28 09:50:12 <mkhoory> I come from an RTOS background, maybe I'm thinking too much in that sense
Mar 28 09:50:49 <LetoThe2nd> mkhoory: debian is just an example. you pointed out yesterday that you don't do series runs but kinda one-off things. that together with maybe not being extremely resource constrained are usually strong arguments against doing the whole distro-from-source shbang like OE does.
Mar 28 09:51:46 <mkhoory> I may actually be very resource constrained though. Hardware hasn't been selected yet
Mar 28 09:51:55 <LetoThe2nd> mkhoory: yes, it might be really useful to let go of the classic RTOS/embedded background
Mar 28 09:52:21 <LetoThe2nd> mkhoory: defined "very resource constrained"
Mar 28 09:54:10 <mkhoory> Like, 16MB EEPROM, and possibly not a lot of RAM either
Mar 28 09:54:28 <LetoThe2nd> mkhoory: and, if its jsut for the development stage, you can always just "update" the target by using scp, assuming a read-write filesystem
Mar 28 09:54:41 <LetoThe2nd> mkhoory: you probably mean 16M flash.
Mar 28 09:54:42 <mkhoory> yeah that was the plan
Mar 28 09:54:56 <mkhoory> LetoThe2nd, possibly, not sure yet
Mar 28 09:55:01 <LetoThe2nd> mkhoory: but in that case you certainly do NOT want package management.
Mar 28 09:55:19 <LetoThe2nd> mkhoory: seriously, i doubt your hardware guys will give you 16M EEPROM memory as ROM memory.
Mar 28 09:55:51 <mkhoory> probably flash then, must've misread
Mar 28 09:56:21 <LetoThe2nd> 16M flash does certainly count as resource constrained, thats true.
Mar 28 09:57:05 <mkhoory> there's a lot of options. We can go for really reliable but expensive flash, or less reliable but cheaper flash, so we're still deciding
Mar 28 09:57:35 <LetoThe2nd> thats the usual
Mar 28 10:01:51 <RP> mkhoory: the big win for Yocto in this case is the ability to totally customise what goes into the image (e.g. poky-tiny uses musl and shows to create more minimal images)
Mar 28 10:02:16 <LetoThe2nd> RP: we've already been through some fun with poky-tiny :)
Mar 28 10:03:38 <LetoThe2nd> reminds me to do the bug report.
Mar 28 10:09:58 <mkhoory> now you know why I'm interested in poky-tiny :P
Mar 28 10:10:57 <LetoThe2nd> mkhoory: oh, i already understood it first time. but there's little use in trying to learn how to sneak if you can't even walk yet, for example.
Mar 28 10:11:08 <LetoThe2nd> hence, start with poky.
Mar 28 10:11:15 <mkhoory> understood
Mar 28 10:12:05 <LetoThe2nd> once you know the in and out, you can totally use poky-tiny as a blueprint for your usecase.
Mar 28 10:13:26 <RP> I do agree that with those resource constraints you don't want package management and probably need an A/B style updater
Mar 28 10:26:22 <mkhoory> ok so what I really need to be doing is reading and doing the examples in the dev manual. There's even a hello world example, which is what I was looking for
Mar 28 10:28:10 <LetoThe2nd> mkhoory: yep.
Mar 28 10:29:19 <LetoThe2nd> mkhoory: one thing to keep in mind though is that the hello world example is good for understanding how the tasks correlate, e.g. compile, install, fetch configure and all that. but its really not a good template for real applications, as it bundles the sources with the recipe
Mar 28 10:29:51 <LetoThe2nd> mkhoory: for any real application, have that in a separate repository or location, and the recipe just refer to it.
Mar 28 10:34:44 <mkhoory> LetoThe2nd, yeah I realize that. What I was really trying to get from the hello world example is how my application would fit in with yocto's build system
Mar 28 10:36:07 <LetoThe2nd> mkhoory: what build system is your application using?
Mar 28 10:36:17 <mkhoory> I haven't written it yet XD
Mar 28 10:36:54 <LetoThe2nd> mkhoory: then which build system are you planning to use :P
Mar 28 10:37:40 <mkhoory> not sure, that's another thing I need to evaluate
Mar 28 10:38:09 <mkhoory> in the past I've used Eclipse's build system, and that wasn't a very good idea but we stuck to it and it was easy
Mar 28 10:38:49 <LetoThe2nd> well, the obvious choices these days are autotools, cmake, meson (if we're talking about anything c(++)-based)
Mar 28 10:38:56 <mkhoory> Some candidates for this project include cmake, waf, or just plain old makefiles
Mar 28 10:39:13 <mkhoory> autotools too, but I always felt that autotools is kinda archaic
Mar 28 10:39:39 <mkhoory> I'll probably end up with cmake tbh
Mar 28 10:40:06 <LetoThe2nd> the three i named have reasonably good support in OE, so if you do those properly then your recipe is hopefully only little more than a license, a source reference, a checksum and the inherit of the buildsystem class
Mar 28 10:41:58 <mkhoory> yeah I figured, based on what I've skimmed from the dev manual
Mar 28 10:43:13 <mkhoory> so basically, if I understand correctly, I'd have 2 git repositories, one for the layer/recipes to be used with yocto, and another for my actual code. The layer/recipes would then pull my actual code repository, configure, build, and package it with the image.
Mar 28 10:44:48 <LetoThe2nd> yep, thats right
Mar 28 10:45:43 <mkhoory> great :D
Mar 28 11:12:37 <RP> JaMa: does x86 have the gold/glibc issue?
Mar 28 11:14:44 <JaMa> RP: I've seen it only on 32bit arm
Mar 28 11:15:59 <JaMa> but we aren't using master anywhere, the only reason why I've noticed was gobject-introspection failing to build (and we don't even use gobject-introspection)
Mar 28 11:22:08 <RP> JaMa: ok. Its something we may need to look in more detail :/
Mar 28 11:31:14 <JaMa> RP: agreed, I've checked with objdump that it wasn't ever built with gold before until that --enable-default-link change, so forcing bfd again was the easiest way to restore old behavior and unblock building images when newer OE
Mar 28 11:42:12 <RP> JaMa: right, fair enough. I'm hoping khem may have a bit more insight...
Mar 28 11:43:43 <JaMa> FWIW: khem's world builds show this issue since christmas, either people don't use gold or 32bit arm it seems
Mar 28 11:44:23 <RP> JaMa: as you know all too well, getting people to pay attention to master failures is hard :(
Mar 28 11:47:14 <RP> JaMa: its a tough one, we have some amazing automation around testing now but it feels like a lonely battle to keep it all working. its sad key issues like that sit unfixed for so long
Mar 28 11:47:18 <JaMa> yes, I wasn't complaining that it wasn't caught or fixed earlier, but ld-is-gold might be less popular now when there is supposedly better linker in llvm (I haven't tried lld yet)
Mar 28 11:48:35 <JaMa> I've flashed some aarch64 image which didn't include this fix and it doesn't seem completely broken in runtime
Mar 28 11:50:22 <JaMa> it would be useful to test some smaller image (which doesn't include gobject-introspection nor any postinsts which need working qemu) on 32bit arm HW to see if it's broken in runtime in the same way as when qemu-arm is trying to use it
Mar 28 11:50:38 <RP> JaMa: I'm not seeing it as a complaint, I guess I'm sharing frustration :)
Mar 28 11:50:58 <RP> JaMa: yes, it would be a useful test
Mar 28 11:51:10 <JaMa> I was trying to do that with hammerhead (android phone), but you cannot really flash core-image-minimal there without serial output
Mar 28 11:51:49 <JaMa> and flashing bigger image with adb etc was blocked by one of the build failures (even with introspection disabled)
Mar 28 11:53:03 <JaMa> or I could take some armv4t (neo freerunner), armv5te (sharp spitz) from drawer, but I fear that glibc issue would be one of the smaller issues with them nowadays :)
Mar 28 11:54:44 <JaMa> hmm I might have serial cable for nexus5 somewhere, will try later today
Mar 28 12:15:56 <RP> armpit: looks like sumo/thud point releases built ok.
Mar 28 12:16:15 <RP> armpit: I'm thinking of enabling x86 ptest for a-full on sumo/thud. The test builds passed
Mar 28 12:16:32 <RP> (https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/113 and https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/112)
Mar 28 12:16:48 * RP should try and add those test results to the release build
Mar 28 12:20:55 <RP> rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/438 is yours I think
Mar 28 12:21:00 <RP> (llvm-native)
Mar 28 12:21:13 <rburton> damn!
Mar 28 12:24:08 <yocti> New news from stackoverflow: Jenkins error: export: -march: bad variable name <https://stackoverflow.com/questions/55397045/jenkins-error-export-march-bad-variable-name>
Mar 28 12:25:46 <rburton> RP: whilst i agree that i touched llvm, i can't explain why thats my fault
Mar 28 12:26:07 <rburton> RP: did you also bump the llvm release?
Mar 28 12:26:36 <rburton> its noticing that host gcc is too old
Mar 28 12:28:07 <rburton> RP: https://github.com/llvm-mirror/llvm/commit/33c30c0b0969655cbd76bcaf94f3f4403bd4d7f6
Mar 28 12:28:35 <rburton> RP: so its kanavin  :)
Mar 28 12:32:46 <rburton> RP: patch incoming
Mar 28 12:34:00 <JaMa> rburton: btw https://github.com/llvm/llvm-project is the right repo for this one IIRC
Mar 28 12:34:18 <rburton> JaMa: yeah that was just the first one that hit in google ;)
Mar 28 12:34:50 <JaMa> ok, I've noticed only because yesterday I've failed to find currently used SRCREV in my local llvm checkout.. :)
Mar 28 12:35:37 <rburton> heh
Mar 28 12:56:07 <RP> rburton: sorry, I saw it was llvm and blamed you :/
Mar 28 12:56:34 * RP had forgotten kanavin had touched it too
Mar 28 12:57:19 <kanavin> RP: anything I need to fix?
Mar 28 12:59:30 <kanavin> nope, rburton sent the fix
Mar 28 13:01:29 <rburton> yeah all sorted, i hope
Mar 28 13:07:23 <RP> kanavin: also https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/448/steps/7/logs/step8b :(
Mar 28 13:08:23 <kanavin> RP: right, this one shouldn't be too diffcult, let me look
Mar 28 13:08:38 <RP> kanavin: indeed, should hopefully be easy
Mar 28 13:09:18 <RP> I guess the test matrix is doing what we need it to do (other than driving me nuts)
Mar 28 13:26:36 <kanavin> RP: I have the fix, but testing it will take a moment. I guess I better be cautious and not send it until mesa completes.
Mar 28 13:26:41 <kanavin> mesa build
Mar 28 13:27:09 <kanavin> takes a moment, first llvm-native, then llvm, then finally mesa
Mar 28 13:29:15 <RP> kanavin: np. I'm just wondering what testing I need to give the new patches on the AB...
Mar 28 13:54:27 <yocti> New news from stackoverflow: How patching works in yocto <https://stackoverflow.com/questions/45584131/how-patching-works-in-yocto>
Mar 28 13:57:10 <rburton> "new", that was from 2017!
Mar 28 14:00:12 <zeddii> :D
Mar 28 14:00:20 <zeddii> everytime I click on one of those, they are old.
Mar 28 14:27:20 <jofr> It says that it was "active" today... Even though I can't see any activity, not even a comment. Whatever that is must be messing with yocti..
Mar 28 14:28:06 <jofr> Ahh, the answer was edited.
Mar 28 14:29:36 <jofr> Seems like yocti needs some more filtering. Or perhaps it's looking at an incorrect date/timestamp in the API.
Mar 28 14:51:43 <RP> https://autobuilder.yocto.io/pub/non-release/20190326-8/testresults/testresult-report.txt
Mar 28 14:52:35 <frsc> Hi, can I somehow set different image types for different image recipes?
Mar 28 14:53:26 <frsc> IMAGE_FSTYPES seems to be global, but I want image_one.bb to use different fstypes than image_two.bb.
Mar 28 14:53:49 <rburton> set that in the image recipe then
Mar 28 14:55:08 <frsc> rburton: Just tried to set IMAGE_FSTYPES="" in my main image, but this also affects the other images.
Mar 28 14:55:45 <frsc> Maybe that's because I'm using the main image to build the other images by depending on them?
Mar 28 15:06:30 <frsc> Ok, it seems to work. I just missed to depend on the image_complete task to actually see the deployment.
Mar 28 15:18:12 * kergoth yawns
Mar 28 15:20:24 <angelo_ts> hello. should create a new recipe. Wouldn't copy from a similar. What is it better ? devtool ? or recipetool ?
Mar 28 15:20:45 <mckoan> angelo_ts: devtool calls recipetool
Mar 28 15:21:14 <angelo_ts> i tried a bit recipetool, but it is complaining things as "NOTE: There are 11 recipes to be removed from sysroot"
Mar 28 15:22:02 <mckoan> angelo_ts: that may depend on what you are doing
Mar 28 15:22:22 <rburton> angelo_ts: that's just a note, ignore it
Mar 28 15:22:35 <rburton> telling you that its fiddling with the sysroot
Mar 28 15:23:12 <angelo_ts> but then it asks ssh key, as it may need to do somehting with git repos
Mar 28 15:23:27 <angelo_ts> so i interrupted
Mar 28 15:24:01 <klemen> Hi everyone
Mar 28 15:24:11 * tlwoerner is very interested in ARMv5 (and ARMv4)
Mar 28 15:24:15 <klemen> I have a problem with building qtbase
Mar 28 15:24:16 <tlwoerner> JaMa: ^^
Mar 28 15:24:25 <klemen> I included the qt5-base layer
Mar 28 15:24:43 <yocti> New news from stackoverflow: how to make bitbake print options of do_configure <https://stackoverflow.com/questions/44541876/how-to-make-bitbake-print-options-of-do-configure>
Mar 28 15:25:14 <klemen> here's my qtbase_%.bbappend:
Mar 28 15:26:15 <klemen> PACKAGECONFIG[gles2] = "-opengl es2 -eglfs,,virtual/libgles2 virtual/egl"
Mar 28 15:26:15 <klemen> PACKAGECONFIG_GL = ""
Mar 28 15:26:17 <klemen> DEPENDS = “virtual/libgles2“
Mar 28 15:26:35 <klemen> and I get this error: https://pastebin.com/bSdG17bz
Mar 28 15:26:46 <klemen> this is from config.log
Mar 28 15:26:49 <klemen> any ideas?
Mar 28 15:27:52 <tlwoerner> klemen: maybe it's because your using an "=" in your DEPENDS bbappend?
Mar 28 15:28:20 <tlwoerner> i.e. you're wiping out the parent recipe's settings and replacing it with just this one DEPENDS instead of adding to it
Mar 28 15:28:31 <klemen> hm, let me try DEPENS_append = " virtual/libgles2"
Mar 28 15:28:33 <klemen> just a second
Mar 28 15:28:43 <tlwoerner> (spell it correctly)
Mar 28 15:29:31 <tlwoerner> also, are you trying to set packageconfigs, or do you think there's an error with the parent recipe's packageconfig?
Mar 28 15:31:44 <klemen> tlwoerner, well.. at this point I'm trying everything. I've been at it for the last 4 hours or so
Mar 28 15:32:43 <klemen> and I keep getting the same error
Mar 28 15:32:59 <klemen> it's as if the usr/include directory was getting populated too late
Mar 28 15:33:12 <klemen> as it keeps telling me that GLES2/gl2.h is missing
Mar 28 15:33:25 <klemen> eventhough it's there
Mar 28 15:33:43 <klemen> here's the full path: /home/klemen/yocto/poky/build/tmp/work/cortexa17hf-neon-vfpv4-poky-linux-gnueabi/qtbase/5.11.3+gitAUTOINC+08de243eaa-r0/recipe-sysroot/usr/include/GLES2
Mar 28 15:33:59 <JaMa> tlwoerner: are you using gold?
Mar 28 15:34:00 <tlwoerner> klemen: that's a new/different error, before it was saying that X11/Xlib.h wasn't found
Mar 28 15:34:17 <tlwoerner> JaMa: i haven't considered it. should i?
Mar 28 15:34:37 <vmeson> rburton: I only see rust in meta-rust: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=rust
Mar 28 15:34:39 <JaMa> tlwoerner: if you want to test if your build is as broken as mine with glibc, then you definitely should :)
Mar 28 15:34:48 <rburton> vmeson: that's good
Mar 28 15:34:56 <rburton> vmeson: maybe it was another language iwas thinkingof
Mar 28 15:35:06 <vmeson> :)  Nim?
Mar 28 15:35:57 <JaMa> tlwoerner: I've tried it on various armv7a and armv7ve and all were affected, x86, aarch64 doesn't seem to be affected
Mar 28 15:36:17 <tlwoerner> klemen: in the chat you said you were going to try _append'ing the gles2 dependency, but you spelled it wrong in the irc, did you spell it right in your test?
Mar 28 15:36:26 <JaMa> well "old" qemuarm armv5te was also affected, so I guess armv4t is as well
Mar 28 15:37:19 <klemen> tlwoerner, yep, in the bbappend it's spelled okay
Mar 28 15:38:22 <klemen> regarding the X11 error, by adding virtual/egl to the DEPENDS_append X11 directory gets added to usr/include, and I still get the error
Mar 28 15:39:41 <klemen> here's the newest log: https://pastebin.com/Y6t9Sycp
Mar 28 15:40:31 <klemen> JaMa, you're the maintainer of meta-qt5, right? :-) would you perhaps know what's up?
Mar 28 15:40:39 <armpit> RP, sorry didn't see your questions. yes lets enable ptest
Mar 28 15:41:05 * armpit has head down getting ready for training next week
Mar 28 15:41:27 <JaMa> klemen: ERROR: Feature 'opengl-desktop' was enabled, but the pre-condition '(config.win32 && !config.winrt && !features.opengles2 && (config.msvc || libs.opengl)) || (!config.watchos && !config.win32 && libs.opengl)' failed.
Mar 28 15:41:45 <JaMa> this is your error, the X11/Xlib.h not found is just from xlib test
Mar 28 15:42:14 <JaMa> use bitbake -e to see what exactly ends in PACKAGECONFIG
Mar 28 15:42:39 <tlwoerner> klemen: can you try "$ bitbake qtbase -e | grep "^PACKAGE"
Mar 28 15:43:35 <JaMa> klemen: if you read the Command line: you can see that you have -no-eglfs and -opengl desktop which you probably didn't plan to with your bbappend
Mar 28 15:43:59 <klemen> JaMa, what would be the correct thing to add in bbappend?
Mar 28 15:44:07 <klemen> to get support for EGLFS?
Mar 28 15:44:32 <JaMa> PACKAGECONFIG += "eglfs"
Mar 28 15:44:54 <JaMa> and PACKAGECONFIG_GL = "gles2"
Mar 28 15:46:23 <klemen> JaMa, okay now I get these two errors:
Mar 28 15:46:28 <klemen> | ERROR: Feature 'opengles2' was enabled, but the pre-condition 'config.win32 || (!config.watchos && !features.opengl-desktop && libs.opengl_es2)' failed.
Mar 28 15:46:28 <klemen> | ERROR: Feature 'eglfs' was enabled, but the pre-condition '!config.android && !config.darwin && !config.win32 && features.egl' failed.
Mar 28 15:46:29 <JaMa> or rather PACKAGECONFIG_append " eglfs" to keep the default value intact (or PACKAGECONFIG_GL = "gles2 eglfs" would work as well), always check with bitbake -e
Mar 28 15:47:24 <JaMa> maybe your BSP doesn't provide usable drm/gles2 implementations?
Mar 28 15:48:15 <JaMa> read what the libs.opengl_es2 and features.egl tests complain about
Mar 28 15:48:57 <klemen> where can I see that?
Mar 28 15:49:20 <JaMa> log.do_configure
Mar 28 15:51:17 <tlwoerner> JaMa: so the test is to _build_ gobject-introspection for armv4/5?
Mar 28 15:51:51 <JaMa> tlwoerner: with ld-is-gold in DISTRO_FEATURES, yes
Mar 28 15:52:23 <JaMa> tlwoerner: but the more interesting part is to build some image (without gobject-introspection or any postinst using qemu which would cause the build to fail) and test it on the device
Mar 28 15:53:09 <JaMa> tlwoerner: because right now I know that ld-2.19.so is causing segfault in qemu-arm when it's built with gold, but I don't know if the same ld-2.19.so works fine on the device or not
Mar 28 15:53:41 <tlwoerner> JaMa: okay. i have an imx233 device that i'm actively working with, let me redo the build with gold and see what happens
Mar 28 15:53:57 <klemen> JaMa, hm
Mar 28 15:53:59 <klemen> > main.cpp:6:12: fatal error: GLES2/gl2.h: No such file or directory
Mar 28 15:54:05 <klemen> https://pastebin.com/b24axW0S
Mar 28 15:54:09 <klemen> but I can see the file is there
Mar 28 15:54:54 <RP> armpit: np, thanks
Mar 28 15:56:35 <JaMa> tlwoerner: thanks!
Mar 28 15:58:09 <JaMa> tlwoerner: please report the findings to the ML, I might drop from IRC for a while
Mar 28 15:58:18 <tlwoerner> JaMa: okay
Mar 28 16:00:08 <klemen> JaMa, what else can I check or do?
Mar 28 16:05:24 <JaMa> klemen: see what your virtual/libgles2 provider installs and where and how to make the test happy about it (e.g. providing pkg-config for gles2 which wasn't found in the pastebin outout)
Mar 28 16:06:02 <klemen> JaMa, okay, thanks for your help! :-)
Mar 28 16:22:24 <JaMa> rburton: I really like your buildhistory diff finds!
Mar 28 16:22:46 <kanavin> gdk=pixbuf is a royal pain
Mar 28 16:32:02 <frsc> In a recipe, how can I assign values based on a variable being empty or not? Is there something in bb.utils?
Mar 28 16:38:07 <angelo_ts> have a simple g++ app, when build by yocto, yocto complains header <stirng> is missing. Why ?
Mar 28 16:38:41 <angelo_ts> since using g++ from the toolchain, not clear why c++ headers shoudl be missing
Mar 28 16:40:54 <kergoth> angelo_ts: not enough information. is your recipe failing to build? post the log
Mar 28 16:41:45 <angelo_ts> kergoth, ok i probably miss to add some makefile variable coming from yocto
Mar 28 16:41:48 <angelo_ts> studying
Mar 28 16:42:11 <kergoth> we're perfectly willing to help, but you'll need to tell us more and show the exact messages youre' getting
Mar 28 16:43:38 <angelo_ts> kergoth, mainly c++ headers are not found
Mar 28 16:43:41 <angelo_ts> https://pastebin.com/64jNKhKh
Mar 28 16:43:47 <kergoth> again, summarizing is not useful
Mar 28 16:44:30 <kergoth> angelo_ts: —sysroot= is being passed twice. the second one is wrong
Mar 28 16:44:39 <kergoth> "--sysroot=/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi"
Mar 28 16:44:41 <angelo_ts> oh, ok
Mar 28 16:44:46 <kergoth> no idea where that's coming from, but it's not what we pass in via CC
Mar 28 16:44:47 <angelo_ts> kergoth, many thanks
Mar 28 16:45:04 <kergoth> obviously that path doesnt' exist, so it can't find anything
Mar 28 16:45:16 <kergoth> you'll have to invesitgate to figure out where that's coming from
Mar 28 16:45:21 <angelo_ts> it comes from my makefile since was working by sdk
Mar 28 16:45:29 <angelo_ts> now i fix it, thanks
Mar 28 16:55:44 <angelo_ts> kergoth, now it builds perfect. Thanks for catching it
Mar 28 16:56:21 <kergoth> np
Mar 28 16:56:30 <kergoth> that's why we need to see log files, not summary :)
Mar 28 16:59:35 <mckoan> angelo_ts: so did you modify the toolchian somehow to cause that error?
Mar 28 17:00:25 <angelo_ts> the original git makefile was containing a wrong sysroot for develop build by sdk. Just removed it.
Mar 28 17:00:53 <rburton> JaMa: the ab does those for us too now. i try to run all patches through it, but lets just say some people get a more intensive review than others
**** ENDING LOGGING AT Fri Mar 29 02:59:57 2019