**** BEGIN LOGGING AT Tue Sep 24 02:59:59 2019 Sep 24 05:48:26 khem: sorry for the late response. yes, i'm inheriting module. it's a recipe to compile backports. what i observe is that i can either depend on $PN or kernel-module-foo-${KERNEL_VERSION} but not just kernel-module-foo... but i dont know why. Sep 24 06:49:43 good morning Sep 24 06:56:50 New news from stackoverflow: How to configure u-boot for 512 Mb Ram Sep 24 09:00:24 In my custom layer I have created: recipes-support/curl/curl_7.61.0.bbappend, and recipes-support/curl/curl-7.61.0/version.patch. In the .bbappend file I have: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" and SRC_URI = "file://version.patch" Sep 24 09:00:51 But when I try to bitbake curl, it does not search the curl-7.61.0 directory Sep 24 09:01:09 It only tries the subdir "curl". what am I missing? Sep 24 09:01:24 iceaway_: ${THISDIR}/${PN}: this expands to /curl, not /curl-7.61.0 Sep 24 09:01:36 iceaway_: PN is package name, PV is package version Sep 24 09:01:44 ahhhh, so simple. Sep 24 09:01:57 so either rename the directory to curl, or do a ${THISDIR}/${PN}-${PV}: Sep 24 09:02:12 LetoThe2nd: thanks, will do that! Sep 24 09:02:34 iceaway_: have fun! Sep 24 09:26:21 So now it can find my patch, but for some reason I cannot understand, bitbake complains about not finding the file to patch. If I "bitbake -c devshell curl", I can successfully apply the patch with "patch -p1 < version.patch", but it won't work when bitbaking. I have not had this problem with any other patches. Any ideas? Sep 24 09:27:15 New news from stackoverflow: bitbake fails at the simplest recipe **** BEGIN LOGGING AT Tue Sep 24 09:58:30 2019 Sep 24 10:07:39 kroon: I guess so, I have looked at other curl patches that are part of the original recipe, and they use the same directory level. Sep 24 10:10:00 Hi everybody Sep 24 10:10:04 iceaway_, so what is the error you get ? Sep 24 10:12:45 default is p1 Sep 24 10:13:24 kroon: https://pastebin.com/3XBRxhGj Sep 24 10:17:08 iceaway_, huh. with the patch removed from the recipe, can you apply it in a devshell even after a "bitbake -c patch curl" ? Sep 24 10:20:54 kroon: you mean first run "bitbake -c patch curl", and then "bitbake -c devshell curl" and then apply my patch? Sep 24 10:21:11 That works. Sep 24 10:22:02 ok Sep 24 10:23:04 well, I have no other idea other than going through the do_patch logs and double checking Sep 24 10:23:10 Could someone give me a hint what i need to do to install an application on a self definded partition? For example: i have a .wks which defines "part / --source rootfs ect." and a additional application partition like "part /app --source ???" Do i need to write my own source plugin to achieve that? And how do i reference to this partition in my Sep 24 10:23:11 do_install() of my application-recipe then? Sep 24 10:23:22 kroon: thanks for your help anyway :) Sep 24 10:24:15 Domin1k: I have done this while experimenting, and I set up a custom install path in my cmake file. Sep 24 10:28:04 Domin1k: sorry misunderstood what you were asking for. Sep 24 10:28:19 And How would i be able to reference to this potential application partition? Sep 24 10:28:57 Domin1k: I do it like this in my wks file: part / --source rootfs --exclude-path=app/ --ondisk mmcblk --fstype=ext4 --label root Sep 24 10:29:37 part /ANPR --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/app --ondisk mmcblk1 --fstype=ext4 --label app --fixed-size 512 Sep 24 10:30:26 So it will exclude the provided dir from the rootfs partition, and then use that same dir for the data for the second partition. Sep 24 10:31:26 Thank you! I will try that. It looks easier than i thought. Sep 24 10:35:29 hi, on poky master, is there some easy wrapper to execute ptests on core-image-minimal with qemu for the image I just build? I guess CI is doing something automatically for various targets and I'd like to sanity test my patches before submitting. Sep 24 10:38:39 mcfrisk: there's a testimage test case that runs ptests, so just install the ptest packages and run testimage Sep 24 10:39:45 basically, inherit testimage, set TEST_SUITES to 'ping ssh ptest', bitbake image -c testimage Sep 24 10:40:15 oh and add the ptests to the image. either just use the ptest-pkgs image feature, or add the ones you care about explicitly Sep 24 10:43:53 rburton: ptest distro feature and ptest-pkgs on image I already had, will try the rest. Thanks! Sep 24 10:44:26 some ptests are slow, so you might want to swap ptest-pkgs for explicit list Sep 24 10:44:31 ie python3-ptest can take a fair number of minutes Sep 24 10:46:09 rburton: ok, I will check. I remember oe-selftest was taging ages and results were difficult to interpret. I guess core-image-minimal ptest results are stable. Sep 24 10:46:23 RP: re: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 possibly, but I can't promise Sep 24 10:46:25 Bug 13539: enhancement, Undecided, ---, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK Sep 24 10:47:59 mcfrisk: see core-image-sato-ptest-fast for the list of known good and not too slow tests Sep 24 10:50:49 hmm, any ideas why ssh and ptest are not executed on core-image-minimal? "RESULTS - ptest.PtestRunnerTest.test_ptestrunner: SKIPPED (0.00s)" Sep 24 10:51:13 maybe I didn't install ptestrunner correctly.. Sep 24 10:58:47 no ssh server installed? Sep 24 10:58:51 minimal might be a bad idea ;) Sep 24 11:01:00 yea :) but don't want to build xorg so trying anyway Sep 24 11:11:27 Domin1k> be careful, to get a valid IMAGE_ROOTFS in wks file i think it needs to be named *.wks.in Sep 24 11:12:52 kroon: found the error. Really silly, I used SRC_URI = instead of SRC_URI +=. Sep 24 11:13:43 kanavin_: np, we'll fine someone but I thought I'd ask since its becoming one of our more pressing issues Sep 24 11:14:59 iceaway_, ah :-) Sep 24 11:15:43 iceaway_, computers can be unforgiving Sep 24 11:19:50 I't seems to work well. Thanks! Sep 24 11:23:37 khem: thanks for the pointer Sep 24 11:25:46 khem: Hey, regarding mongodb v4.2, I posted a bugged v2 patch, I shouldn't do anything on friday :) Sep 24 11:37:48 hmm testing was taking ages so logged into core-image-minimal in qemu and saw ssh-keygen waiting for entropy for ever :( Sep 24 11:38:04 started rngd manually and tests started executing Sep 24 11:38:10 sigh Sep 24 11:46:30 huh Sep 24 11:53:59 mcfrisk: maybe you need one of those sofwares that help at generating entropy (e.g., haveged)? Sep 24 11:54:17 i have an application that is build with cmake. This cmake-build is calling a postbuild.sh which uses rsync. Within my manual build using the poky-sdk i have no problems with that. But if i try to build it with bitbake the postbuild.sh fails because rsync isn't available. Is there a way to make rsync available within a bitbake evironment? Or do i Sep 24 11:54:18 need to seperate the postbuild from a manual build to bitbake build here? Sep 24 11:55:08 Domin1k: DEPENDS += "rsync-native" Sep 24 11:55:26 mcfrisk: oh, sorry. Now I see you are already using rngd. Sep 24 11:55:38 Domin1k: yet, remember that any form of communication makes the build non-reproductible Sep 24 11:56:03 Domin1k: so if its just about "getting" something, you might be better off extending the fetch stage and manually injecting then later. Sep 24 11:57:23 Thanks. I've tries DEPENDS +="rsync" before but didn't tried appending "-native" Sep 24 11:57:44 New news from stackoverflow: Touchscreen issue with multiple display Sep 24 11:58:03 mcfrisk: qemu should be using the host virtio rng Sep 24 12:00:20 Does the same apply for python3 (DEPENDS += "python3-native")? I would also like to use python3 to encrypt some files with postbuild.sh Sep 24 12:00:38 mcfrisk: maybe missing the kernel modules? or you're not using a qemu machine so that isn't setup? Sep 24 12:01:03 Domin1k: -native means "provide the package at build time to run on the host" Sep 24 12:01:08 so, probably Sep 24 12:03:52 (y) Thanks i'll give it a try Sep 24 12:04:01 rburton: using the default core-image-minimal qemu target machine and image. maybe my 5.1.11 kernel is missing the virtio rng driver.. Sep 24 12:04:29 core-image-minimal - OK - All required tests passed (successes=12, skipped=48, failures=0, errors=0) Sep 24 12:06:54 from execution times this looks odd: RESULTS - ptest.PtestRunnerTest.test_ptestrunner: PASSED (2944.88s) Sep 24 12:10:29 in comparison: RESULTS - python.PythonTest.test_python3: PASSED (0.96s) Sep 24 12:12:16 thats not right... Sep 24 12:12:38 oh, no, thats right Sep 24 12:12:50 that test is super dumb, its not the ptest Sep 24 12:13:05 i did say ptest takes a while Sep 24 12:14:15 python test only tests if python3 runs from what I remember Sep 24 12:14:48 pretty much Sep 24 12:46:01 ouch: ERROR: core-image-minimal-1.0-r0 do_rootfs: Unable to install packages. Command '/home/mcfrisk/src/yocto/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f /home/mcfrisk/src/yocto/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/opkg.conf -t Sep 24 12:46:06 /home/mcfrisk/src/yocto/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/ipktemp/ -o /home/mcfrisk/src/yocto/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version install packagegroup-core-boot packagegroup-core-ssh-openssh run-postinsts' returned -6: Sep 24 12:46:11 free(): double free detected in tcache 2 Sep 24 12:51:04 RP: Hmm, that eSDK failure is unfortunate.... Should we raise a bug at this point? Sep 24 12:52:08 JPEW: probably but its not going to make a material difference... Sep 24 12:55:27 RP: I'll try again. Do you have an example of the failure on the AB? Sep 24 12:57:57 New news from stackoverflow: Uploading custom Yocto image to Jetson Nano (non-devkit) eMMC? Sep 24 13:11:11 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/1060 Sep 24 13:11:24 RP: Thanks Sep 24 13:11:35 JPEW: same failure in that step on all workers :/ Sep 24 13:11:45 (mips, arm, ppc all the same) Sep 24 13:12:30 JPEW: I have a feeling its something to do with bad interaction between locked sigs and hash equiv Sep 24 13:12:59 RP: Ya, that would not suprise me in the slightest. Sep 24 13:13:17 JPEW: I did make one small tweak in -next already Sep 24 13:53:42 on u-boot/raspberry0, where do I append the defconfig of u-boot? Sep 24 13:53:45 I have it in "mylayer/recipes-bsp/u-boot/u-boot_%.bbappend" Sep 24 13:53:47 and file not found Sep 24 13:59:39 kayterina bitbake-layers show-appends Sep 24 14:02:40 yes. Actually the error is "Unable to get checksum for u-boot SRC_URI entry defconfig: file could not be found" Sep 24 14:03:31 we have a 64b machine with multilib and we want to install a firmware in a recipe. The thing is that base_libdir is then /lib64 and not /lib where the kernel expets the firmware to be. Is there a proper way to make it install in /lib? Sep 24 14:04:09 kayterina give full error log Sep 24 14:05:47 * kayterina sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/eoebkEJdZDHVmxcEfwpUiWyJ > Sep 24 14:06:01 i what I get when "bitbake myimage" Sep 24 14:06:03 kayterina: most likely cause is you didnt set FILESEXTRAPATHS_prepend to ensure it can find the defconfig by the bbappend Sep 24 14:06:26 to BPN or PN? Sep 24 14:06:30 I have FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:" Sep 24 14:06:41 as I did in busybox append Sep 24 14:07:30 create "files" folder or what you want and add "FILESEXTRAPATHS_prepend := "${THISDIR}/files"" Sep 24 14:08:03 and of course SRC_URI=" \file://defconfig " Sep 24 14:09:31 halstead: I see ERROR: HTTP Error 500: INTERNAL SERVER ERROR when uploading to errors.yp.org Sep 24 14:09:42 it happens every so often Sep 24 14:17:11 PinkSnake: well...thanks it worked. may I ask why the variable PN didn't extend as I expected? Sep 24 14:17:32 I mean, in linux kernel append is ${PN} Sep 24 14:25:26 kayterina https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#best-practices-to-follow-when-creating-layers ;) Sep 24 14:26:01 ok Sep 24 14:48:08 Yocto doesn’t have a built in function to generate all the license files into a single file? Sep 24 14:49:42 bentech: no, they are into a directory Sep 24 14:51:02 I can see build/deploy/licenses Are there any of a specific recipe? Sep 24 15:02:17 sed will help me Sep 24 15:04:59 bentech: in build/deploy/licenses there is the list of all the licenses involved in your image. They are not directly related to any recipe Sep 24 15:05:30 bentech: They are directly related to every recipe Sep 24 15:05:57 I’ve just found the license.manifest file, which is a good start Sep 24 15:08:25 bentech: good catch Sep 24 15:21:54 rburton: is meta-ros the right place to submit my updated wxwidgets recipe? https://layers.openembedded.org/layerindex/branch/master/layer/meta-ros/ Sep 24 15:22:05 yates: i'd say meta-oe would be a better home Sep 24 15:22:08 its not specific to ros Sep 24 15:22:33 and meta-ros depends on meta-oe, so can delete its own wxwidgets recipe Sep 24 15:22:37 and everyone is a winner Sep 24 15:23:01 ok will do Sep 24 15:31:10 rburton: which sublayer to meta-openembedded should i submit to? Sep 24 15:32:05 yates: meta-oe Sep 24 15:32:07 doh. nm Sep 24 15:32:08 right Sep 24 15:42:29 it was removed from meta-oe long time ago and then restored in meta-ros with its own issues, so make sure that it builds correctly for all tested configurations before re-adding it to meta-oe Sep 24 15:44:31 adelcast: why does the opkg tarball have a tests/libopkg_test binary in? no source, no mention in git. Sep 24 15:45:57 adelcast: if i build a tarball myself its not there either Sep 24 15:46:07 adelcast: was the tarball built with some local changes that were not committed maybe? Sep 24 15:50:43 RP; https://bugzilla.yoctoproject.org/show_bug.cgi?id=13543 Sep 24 15:50:44 Bug 13543: normal, Undecided, ---, richard.purdie, NEW , [warrior] seltest on fadora fails Sep 24 15:51:40 RP; also https://bugzilla.yoctoproject.org/show_bug.cgi?id=13546 Sep 24 15:51:41 Bug 13546: normal, Undecided, ---, ross.burton, NEW , [warrior] oe-selftest on yp-ab-debian10-ty-2 Sep 24 15:55:34 armpit: I recognise 13543 from somewhere Sep 24 15:56:29 is it that its using master of meta-selftest or is that ok Sep 24 15:57:34 armpit: meta-selftest is part of oe-core so that doesn't make sense Sep 24 15:57:56 rburton: ok, i think i did that right... Sep 24 15:58:27 JaMa: where are the "tested configurations" Sep 24 15:58:31 ? Sep 24 16:16:44 ?? Sep 24 16:20:00 yates: at least start with all the architectures with glibc and musl Sep 24 16:20:24 khem's testing should shake that out but bonus points for at least verifying a few architectures and musl builds now Sep 24 17:03:05 armpit: you need http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=464a2fed0be067b0ad703b3474b9e01566bf80d3 to fix those postinst failures on warrior Sep 24 17:12:50 RP: do you have the fix for do_locked_sigs locally? I'm getting that error on master-next. Also, can you grab the AB hash equiv database for me? Sep 24 17:15:50 JPEW: which do_locked_sigs fix? Sep 24 17:16:25 do_locked_sigs:XXXX is not in the unihash cache? Sep 24 17:16:41 JPEW: I stopped seeing that, I was hoping it was fixed by something else :/ Sep 24 17:17:07 Hmm.... OK. Sep 24 17:17:30 RP: I would like to start running ptest on meta-oe job on OE Sep 24 17:17:37 how to go about that ? Sep 24 17:17:40 JPEW: let me just check the status of my branches Sep 24 17:18:04 khem: create an image with the ptests in and then we add it to the autobuilder config? Sep 24 17:19:25 khem: do you remember a qemu linking against libatomic problem? Sep 24 17:19:28 ok so we have these packagegroups which include all packages in a layer so we can just enahance core-image-full-cmdline to include those maybe Sep 24 17:19:45 RP:qemu on host ? Sep 24 17:20:08 khem: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13543 - I have some memory we discussed/fixed this but I can't find how Sep 24 17:20:10 Bug 13543: normal, Undecided, ---, richard.purdie, NEW , [warrior] seltest on fadora fails Sep 24 17:20:22 khem: you are probably thinking of core-image-sato-ptest ? Sep 24 17:20:40 RP: right yes a ptest image Sep 24 17:24:25 JPEW: I added one small fix to -next but my local tree is a mess and out of date so I'm clearing up Sep 24 17:24:55 JPEW: did you have all the fixes in -next bar the last one I added (which just tweaks a selftest) Sep 24 17:25:47 Yes, I had them all. Just rebased, will try again and attempt to track it down. Sep 24 17:28:40 JPEW: I suspect if we stop the general mismatch issue we'd fix some of these others too Sep 24 17:29:15 This was when building the eSDK, before the tests were ran Sep 24 17:29:40 Hmm, it seems to have resolved itself.... I'm not sure thats a good thing though Sep 24 17:29:57 JPEW: that task is tricky as it doesn't always rerun when you want it to Sep 24 17:30:11 JPEW: probably not a good thing :/ Sep 24 17:31:16 RP: I haven't seen libatomic being required on qemu unless some distro is playing with linker stubs Sep 24 17:34:32 hey khem. sorry for my late response yesterday. i can't share the module recipe, but i do inherit module and cml1. Sep 24 17:36:46 mischief: ok Sep 24 17:38:40 i see that the kernel-module-split class is mangling the versions quite a bit, but the documentation doesn't appear to say anything about this, so i am confused still Sep 24 17:38:53 khem: I must be misremembering. Could have sworn we've seen this somewhere :/ Sep 24 17:40:00 for example, this does not work as documented: https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#idm45745056593536 Sep 24 17:43:39 ive probably done something wrong.. here's an example of what happens Sep 24 17:44:45 http://ix.io/1WKj Sep 24 17:45:02 RP: I need to login into these boxes and check Sep 24 17:45:12 or you can see content of /usr/lib/libc.so e.g. Sep 24 17:45:20 these are linker stubs Sep 24 17:45:35 which can add extra libs Sep 24 17:49:02 khem: if i depend on "foo", it works. but if i depend on the virtual package kernel-module-foo, it does not. do you know how i can debug that? Sep 24 17:51:44 i'm getting "cc1plus: warning: include location "/usr/include/dbus-1.0" is unsafe for cross-compilation [-Wpoison-system-directories]" when cross-compiling using the sdk. Sep 24 17:52:18 the makefile for that app uses `pkg-config dbus-1 --cflags` so i guess it's using the system pkg-config Sep 24 17:52:37 is there a cross-compile pkg-config in the sysroot? Sep 24 17:53:23 or is there otherwise a typical way to handle this? Sep 24 17:54:21 khem: i think you were the one that encouraged me to use pkg-config... what say you? Sep 24 17:56:01 use the sysroot pkg-config? (just verified it is there) Sep 24 17:56:46 yates, you might want to have some env variables set aswell Sep 24 17:57:16 yates, like PKG_CONFIG_SYSROOT_DIR Sep 24 17:58:13 yates, which the sdk env. script should setup for you iirc Sep 24 17:58:21 script? Sep 24 17:58:25 what script? Sep 24 17:58:53 * yates searches for an sdk env. script Sep 24 17:59:09 yates, are you using the sdk generated by yocto ? Sep 24 17:59:12 yes Sep 24 17:59:53 you mean the script that installs the sysroot on your build system? Sep 24 18:00:15 yates, unless things have changed, there is a env. script you need to source, at the top where you installed the sdk Sep 24 18:00:45 yates, no, another script Sep 24 18:01:08 kroon: what is the file name? xyz.sh? Sep 24 18:01:27 yates, you did use "bitbake -c populate_sdk " to create the sdk right ? Sep 24 18:01:33 yes Sep 24 18:02:29 see meta/classes/toolchain-scripts.bbclass Sep 24 18:02:35 i dont remember the filename Sep 24 18:02:37 but i built it under ubuntu lts and then copied the /opt/fslc-x11/... over to my fedora box since i do my building/developing on fedora Sep 24 18:02:42 ok Sep 24 18:03:33 you need to run the installer on the host your developing on Sep 24 18:05:26 how does it make such env. variables persistent? does it actually modify your bash.rc or whatnot? Sep 24 18:06:05 they are not persistent, they only affect the shell you source the script from Sep 24 18:06:22 ahh, see, that would be a problem. Sep 24 18:06:28 i do not have yocto install on fedora Sep 24 18:06:36 it does not support fedora Sep 24 18:07:22 you cannot run the sdk installer in fedora ? Sep 24 18:07:27 i've done cross-builds for many other apps but they didn't need pkg-config, so they "work"? Sep 24 18:07:49 s/?/./ Sep 24 18:08:24 ok Sep 24 18:08:31 maybe i can Sep 24 18:29:22 yates: see status e-mails from khem Sep 24 18:29:33 ok Sep 24 18:32:51 did you send them to my garnerundergroundinc.com account? i don't see them. (company virus filter may have blocked). please use yates@ieee.org Sep 24 18:58:39 anyone else have a clue about why kernel-module-foo prefixes dont work? Sep 24 19:26:14 How is it going guys? I have been using the Yocto project at work and I just wanted to drop in and say thank you. Sep 24 20:09:30 yates kroon: yocto supports fedora Sep 24 20:09:46 if you're using a too new fedora for the sanity test, give it a go anyway Sep 24 20:32:30 rburton, right, and I guess there shouldn't be any problems installing an sdk, generated in ubuntu, on a fedora machine ? Sep 24 20:35:28 I have seen older posts online saying it is impossible to call any python functions in yocto from shell functions. Is this still true? Sep 24 20:39:23 diamondman: o/ Sep 24 20:39:46 mischief: Oh hey Nick, how you doing? Sep 24 20:41:40 diamondman, you can use ${@...} in shell functions Sep 24 20:41:45 diamondman: well Sep 24 20:41:54 fighting yocto as well :-) Sep 24 20:47:50 rburton: i think the problem is the old version of yocto: morty. it does not work on a version of fedora within the past 3 years... Sep 24 20:48:09 rburton: "So upgrade". yates: "It's complicated" Sep 24 20:48:48 is there a known problem with the cross-compile version of uname not being available? Sep 24 20:48:52 in the sdk? Sep 24 20:50:48 yates, why would you need a cross-compile uname, to detect the compiler triplet ? Sep 24 20:51:23 it's in wx's wx-config srript. selects whether there is a lib64 or just a lib Sep 24 20:51:27 script Sep 24 20:51:44 aha Sep 24 20:52:57 i would _really_ like to get wx to work cross-platform - speeds up development a bunch Sep 24 20:53:58 sounds like wx-config might need patching. unless there is a .pc you can use instead Sep 24 20:54:33 that would be the right way to do it. Sep 24 21:15:40 rburton: yes, I didn't create the tarball properly via make dist, so there is an extra binary. I have a comment on that on the opkg recipe itself: http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/opkg/opkg_0.4.1.bb Sep 24 21:27:03 if a cross-build is being done, and the build invokes a script, and the script sets up paths as part of its operations (e.g., /usr/lib/xyz), how are those paths supposed to make relative to the sysroot without modifying the script? Sep 24 21:27:31 that is what's happening with the wx-config Sep 24 21:29:13 i.e., it's looking for file /usr/lib/wx/config/gtk3-unicode-3.0, which doesn't exist in the host, but /opt/fslc-x11/2.2.1/sysroots/x86_64-fslcsdk-linux/usr/lib/wx/config/gtk3-unicode-3.0 does Sep 24 21:29:41 ...supposed to be made relative... Sep 24 21:30:33 should i just hack it to refer to the host file(s)? Sep 24 21:30:41 usr/lib64/... ? Sep 24 21:30:53 Sep 24 21:31:05 i have an excellent hacking tool: emacs! Sep 24 21:31:33 adelcast: yeah was wondering the context. will 0.4.2 be built using make dist and we can remove that comment? Sep 24 21:32:07 yep, one time mess-up Sep 24 21:33:13 cool Sep 24 21:34:41 rburton: is there a way to do this, or do you have to modify the script? Sep 24 21:40:53 yates: you'll need to hack the script. i'd go back to arguing with upstream to add a pkgconfig file Sep 24 21:42:13 there's prior art in oe-core of adding pkgconfig files and then writing replacement config scripts that just proxy to pkgconfig :) Sep 24 21:51:28 patented? :) **** ENDING LOGGING AT Wed Sep 25 02:59:57 2019