**** BEGIN LOGGING AT Tue Sep 24 02:59:59 2019
Sep 24 05:48:26 <mischief> 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 <mckoan> good morning
Sep 24 06:56:50 <yocti> New news from stackoverflow: How to configure u-boot for 512 Mb Ram <https://stackoverflow.com/questions/58074380/how-to-configure-u-boot-for-512-mb-ram>
Sep 24 09:00:24 <iceaway_> 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 <iceaway_> But when I try to bitbake curl, it does not search the curl-7.61.0 directory
Sep 24 09:01:09 <iceaway_> It only tries the subdir "curl". what am I missing?
Sep 24 09:01:24 <LetoThe2nd> iceaway_: ${THISDIR}/${PN}: this expands to /curl, not /curl-7.61.0
Sep 24 09:01:36 <LetoThe2nd> iceaway_: PN is package name, PV is package version
Sep 24 09:01:44 <iceaway_> ahhhh, so simple.
Sep 24 09:01:57 <LetoThe2nd> so either rename the directory to curl, or do a ${THISDIR}/${PN}-${PV}:
Sep 24 09:02:12 <iceaway_> LetoThe2nd: thanks, will do that!
Sep 24 09:02:34 <LetoThe2nd> iceaway_: have fun!
Sep 24 09:26:21 <iceaway_> 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 <yocti> New news from stackoverflow: bitbake fails at the simplest recipe <https://stackoverflow.com/questions/50015145/bitbake-fails-at-the-simplest-recipe>
**** BEGIN LOGGING AT Tue Sep 24 09:58:30 2019
Sep 24 10:07:39 <iceaway_> 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 <Domin1k> Hi everybody
Sep 24 10:10:04 <kroon> iceaway_, so what is the error you get ?
Sep 24 10:12:45 <rburton> default is p1
Sep 24 10:13:24 <iceaway_> kroon: https://pastebin.com/3XBRxhGj
Sep 24 10:17:08 <kroon> 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 <iceaway_> 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 <iceaway_> That works.
Sep 24 10:22:02 <kroon> ok
Sep 24 10:23:04 <kroon> well, I have no other idea other than going through the do_patch logs and double checking
Sep 24 10:23:10 <Domin1k> 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 <Domin1k> do_install() of my application-recipe then?
Sep 24 10:23:22 <iceaway_> kroon: thanks for your help anyway :)
Sep 24 10:24:15 <iceaway_> Domin1k: I have done this while experimenting, and I set up a custom install path in my cmake file.
Sep 24 10:28:04 <iceaway_> Domin1k: sorry misunderstood what you were asking for.
Sep 24 10:28:19 <Domin1k> And How would i be able to reference to this potential application partition?
Sep 24 10:28:57 <iceaway_> 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 <iceaway_> part /ANPR  --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/app --ondisk mmcblk1 --fstype=ext4 --label app --fixed-size 512
Sep 24 10:30:26 <iceaway_> 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 <Domin1k> Thank you! I will try that. It looks easier than i thought.
Sep 24 10:35:29 <mcfrisk> 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 <rburton> mcfrisk: there's a testimage test case that runs ptests, so just install the ptest packages and run testimage
Sep 24 10:39:45 <rburton> basically, inherit testimage, set TEST_SUITES to 'ping ssh ptest', bitbake image -c testimage
Sep 24 10:40:15 <rburton> 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 <mcfrisk> rburton: ptest distro feature and ptest-pkgs on image I already had, will try the rest. Thanks!
Sep 24 10:44:26 <rburton> some ptests are slow, so you might want to swap ptest-pkgs for explicit list
Sep 24 10:44:31 <rburton> ie python3-ptest can take a fair number of minutes
Sep 24 10:46:09 <mcfrisk> 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 <kanavin_> RP: re: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 possibly, but I can't promise
Sep 24 10:46:25 <yocti> Bug 13539: enhancement, Undecided, ---, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK
Sep 24 10:47:59 <rburton> mcfrisk: see core-image-sato-ptest-fast for the list of known good and not too slow tests
Sep 24 10:50:49 <mcfrisk> 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 <mcfrisk> maybe I didn't install ptestrunner correctly..
Sep 24 10:58:47 <rburton> no ssh server installed?
Sep 24 10:58:51 <rburton> minimal might be a bad idea ;)
Sep 24 11:01:00 <mcfrisk> yea :) but don't want to build xorg so trying anyway
Sep 24 11:11:27 <nayfe> 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 <iceaway_> kroon: found the error. Really silly, I used SRC_URI = instead of SRC_URI +=.
Sep 24 11:13:43 <RP> 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 <kroon> iceaway_, ah :-)
Sep 24 11:15:43 <kroon> iceaway_, computers can be unforgiving
Sep 24 11:19:50 <Domin1k> I't seems to work well. Thanks!
Sep 24 11:23:37 <radsquirrel> khem: thanks for the pointer
Sep 24 11:25:46 <nayfe> khem: Hey, regarding mongodb v4.2, I posted a bugged v2 patch, I shouldn't do anything on friday :)
Sep 24 11:37:48 <mcfrisk> 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 <mcfrisk> started rngd manually and tests started executing
Sep 24 11:38:10 <mcfrisk> sigh
Sep 24 11:46:30 <rburton> huh
Sep 24 11:53:59 <mario-goulart> mcfrisk: maybe you need one of those sofwares that help at generating entropy (e.g., haveged)?
Sep 24 11:54:17 <Domin1k> 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 <Domin1k> need to seperate the postbuild from a manual build to bitbake build here?
Sep 24 11:55:08 <LetoThe2nd> Domin1k: DEPENDS += "rsync-native"
Sep 24 11:55:26 <mario-goulart> mcfrisk: oh, sorry.  Now I see you are already using rngd.
Sep 24 11:55:38 <LetoThe2nd> Domin1k: yet, remember that any form of communication makes the build non-reproductible
Sep 24 11:56:03 <LetoThe2nd> 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 <Domin1k> Thanks. I've tries DEPENDS +="rsync" before but didn't tried appending "-native"
Sep 24 11:57:44 <yocti> New news from stackoverflow: Touchscreen issue with multiple display <https://stackoverflow.com/questions/58079313/touchscreen-issue-with-multiple-display>
Sep 24 11:58:03 <rburton> mcfrisk: qemu should be using the host virtio rng
Sep 24 12:00:20 <Domin1k> 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 <rburton> mcfrisk: maybe missing the kernel modules?  or you're not using a qemu machine so that isn't setup?
Sep 24 12:01:03 <LetoThe2nd> Domin1k: -native means "provide the package at build time to run on the host"
Sep 24 12:01:08 <LetoThe2nd> so, probably
Sep 24 12:03:52 <Domin1k>  (y) Thanks i'll give it a try
Sep 24 12:04:01 <mcfrisk> 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 <mcfrisk> core-image-minimal - OK - All required tests passed (successes=12, skipped=48, failures=0, errors=0)
Sep 24 12:06:54 <mcfrisk> from execution times this looks odd: RESULTS - ptest.PtestRunnerTest.test_ptestrunner: PASSED (2944.88s)
Sep 24 12:10:29 <mcfrisk> in comparison: RESULTS - python.PythonTest.test_python3: PASSED (0.96s)
Sep 24 12:12:16 <rburton> thats not right...
Sep 24 12:12:38 <rburton> oh, no, thats right
Sep 24 12:12:50 <rburton> that test is super dumb, its not the ptest
Sep 24 12:13:05 <rburton> i did say ptest takes a while
Sep 24 12:14:15 <kanavin_> python test only tests if python3 runs from what I remember
Sep 24 12:14:48 <rburton> pretty much
Sep 24 12:46:01 <mcfrisk> 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 <mcfrisk> /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 <mcfrisk> free(): double free detected in tcache 2
Sep 24 12:51:04 <JPEW> RP: Hmm, that eSDK failure is unfortunate.... Should we raise a bug at this point?
Sep 24 12:52:08 <RP> JPEW: probably but its not going to make a material difference...
Sep 24 12:55:27 <JPEW> RP: I'll try again. Do you have an example of the failure on the AB?
Sep 24 12:57:57 <yocti> New news from stackoverflow: Uploading custom Yocto image to Jetson Nano (non-devkit) eMMC? <https://stackoverflow.com/questions/58080403/uploading-custom-yocto-image-to-jetson-nano-non-devkit-emmc>
Sep 24 13:11:11 <RP> JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/1060
Sep 24 13:11:24 <JPEW> RP: Thanks
Sep 24 13:11:35 <RP> JPEW: same failure in that step on all workers :/
Sep 24 13:11:45 <RP> (mips, arm, ppc all the same)
Sep 24 13:12:30 <RP> JPEW: I have a feeling its something to do with bad interaction between locked sigs and hash equiv
Sep 24 13:12:59 <JPEW> RP: Ya, that would not suprise me in the slightest.
Sep 24 13:13:17 <RP> JPEW: I did make one small tweak in -next already
Sep 24 13:53:42 <kayterina> on u-boot/raspberry0, where do I append the defconfig of u-boot?
Sep 24 13:53:45 <kayterina> I have it in "mylayer/recipes-bsp/u-boot/u-boot_%.bbappend"
Sep 24 13:53:47 <kayterina> and file not found
Sep 24 13:59:39 <PinkSnake> kayterina bitbake-layers show-appends
Sep 24 14:02:40 <kayterina> 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 <qschulz> 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 <PinkSnake> 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 <kayterina> i what I get when "bitbake myimage"
Sep 24 14:06:03 <kergoth> 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 <kayterina> to BPN or PN?
Sep 24 14:06:30 <kayterina> I have FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
Sep 24 14:06:41 <kayterina> as I did in busybox append
Sep 24 14:07:30 <PinkSnake> create "files" folder or what you want and add "FILESEXTRAPATHS_prepend := "${THISDIR}/files""
Sep 24 14:08:03 <PinkSnake> and of course SRC_URI=" \file://defconfig "
Sep 24 14:09:31 <khem> halstead: I see ERROR: HTTP Error 500: INTERNAL SERVER ERROR when uploading to errors.yp.org
Sep 24 14:09:42 <khem> it happens every so often
Sep 24 14:17:11 <kayterina> PinkSnake: well...thanks it worked. may I ask why the variable PN didn't extend as I expected?
Sep 24 14:17:32 <kayterina> I mean, in linux kernel append is ${PN}
Sep 24 14:25:26 <PinkSnake> kayterina https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#best-practices-to-follow-when-creating-layers ;)
Sep 24 14:26:01 <kayterina> ok
Sep 24 14:48:08 <bentech> Yocto doesn’t have a built in function to generate all the license files into a single file?
Sep 24 14:49:42 <mckoan> bentech: no, they are into a directory
Sep 24 14:51:02 <bentech> I can see build/deploy/licenses Are there any of a specific recipe?
Sep 24 15:02:17 <bentech> sed will help me
Sep 24 15:04:59 <mckoan> 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 <mckoan> bentech: They are directly related to every recipe
Sep 24 15:05:57 <bentech> I’ve just found the license.manifest file, which is a good start
Sep 24 15:08:25 <mckoan> bentech: good catch
Sep 24 15:21:54 <yates> 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 <rburton> yates: i'd say meta-oe would be a better home
Sep 24 15:22:08 <rburton> its not specific to ros
Sep 24 15:22:33 <rburton> and meta-ros depends on meta-oe, so can delete its own wxwidgets recipe
Sep 24 15:22:37 <rburton> and everyone is a winner
Sep 24 15:23:01 <yates> ok will do
Sep 24 15:31:10 <yates> rburton: which sublayer to meta-openembedded should i submit to?
Sep 24 15:32:05 <rburton> yates: meta-oe
Sep 24 15:32:07 <yates> doh. nm
Sep 24 15:32:08 <yates> right
Sep 24 15:42:29 <JaMa> 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 <rburton> adelcast: why does the opkg tarball have a tests/libopkg_test binary in? no source, no mention in git.
Sep 24 15:45:57 <rburton> adelcast: if i build a tarball myself its not there either
Sep 24 15:46:07 <rburton> adelcast: was the tarball built with some local changes that were not committed maybe?
Sep 24 15:50:43 <armpit> RP; https://bugzilla.yoctoproject.org/show_bug.cgi?id=13543
Sep 24 15:50:44 <yocti> Bug 13543: normal, Undecided, ---, richard.purdie, NEW , [warrior] seltest on fadora fails
Sep 24 15:51:40 <armpit> RP; also https://bugzilla.yoctoproject.org/show_bug.cgi?id=13546
Sep 24 15:51:41 <yocti> Bug 13546: normal, Undecided, ---, ross.burton, NEW , [warrior] oe-selftest  on yp-ab-debian10-ty-2
Sep 24 15:55:34 <RP> armpit: I recognise 13543 from somewhere
Sep 24 15:56:29 <armpit> is it that its using master of meta-selftest or is that ok
Sep 24 15:57:34 <RP> armpit: meta-selftest is part of oe-core so that doesn't make sense
Sep 24 15:57:56 <yates> rburton: ok, i think i did that right...
Sep 24 15:58:27 <yates> JaMa: where are the "tested configurations"
Sep 24 15:58:31 <yates> ?
Sep 24 16:16:44 <yates> ??
Sep 24 16:20:00 <rburton> yates: at least start with all the architectures with glibc and musl
Sep 24 16:20:24 <rburton> 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 <RP> 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 <JPEW> 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 <RP> JPEW: which do_locked_sigs fix?
Sep 24 17:16:25 <JPEW> do_locked_sigs:XXXX is not in the unihash cache?
Sep 24 17:16:41 <RP> JPEW: I stopped seeing that, I was hoping it was fixed by something else :/
Sep 24 17:17:07 <JPEW> Hmm.... OK.
Sep 24 17:17:30 <khem> RP: I would like to start running ptest on meta-oe job on OE
Sep 24 17:17:37 <khem> how to go about that ?
Sep 24 17:17:40 <RP> JPEW: let me just check the status of my branches
Sep 24 17:18:04 <RP> khem:  create an image with the ptests in and then we add it to the autobuilder config?
Sep 24 17:19:25 <RP> khem: do you remember a qemu linking against libatomic problem?
Sep 24 17:19:28 <khem> 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 <khem> RP:qemu on host ?
Sep 24 17:20:08 <RP> 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 <yocti> Bug 13543: normal, Undecided, ---, richard.purdie, NEW , [warrior] seltest on fadora fails
Sep 24 17:20:22 <RP> khem: you are probably thinking of core-image-sato-ptest ?
Sep 24 17:20:40 <khem> RP: right yes a ptest image
Sep 24 17:24:25 <RP> 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 <RP> 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 <JPEW> Yes, I had them all. Just rebased, will try again and attempt to track it down.
Sep 24 17:28:40 <RP> JPEW: I suspect if we stop the general mismatch issue we'd fix some of these others too
Sep 24 17:29:15 <JPEW> This was when building the eSDK, before the tests were ran
Sep 24 17:29:40 <JPEW> Hmm, it seems to have resolved itself.... I'm not sure thats a good thing though
Sep 24 17:29:57 <RP> JPEW: that task is tricky  as it doesn't always rerun when you want it to
Sep 24 17:30:11 <RP> JPEW: probably not a good thing :/
Sep 24 17:31:16 <khem> RP: I haven't seen libatomic being required on qemu unless some distro is playing with linker stubs
Sep 24 17:34:32 <mischief> 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 <khem> mischief: ok
Sep 24 17:38:40 <mischief> 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 <RP> khem: I must be misremembering. Could have sworn we've seen this somewhere :/
Sep 24 17:40:00 <mischief> 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 <mischief> ive probably done something wrong.. here's an example of what happens
Sep 24 17:44:45 <mischief> http://ix.io/1WKj
Sep 24 17:45:02 <khem> RP: I need to login into these boxes and check
Sep 24 17:45:12 <khem> or you can see content of /usr/lib/libc.so e.g.
Sep 24 17:45:20 <khem> these are linker stubs
Sep 24 17:45:35 <khem> which can add extra libs
Sep 24 17:49:02 <mischief> 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 <yates> 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 <yates> 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 <yates> is there a cross-compile pkg-config in the sysroot?
Sep 24 17:53:23 <yates> or is there otherwise a typical way to handle this?
Sep 24 17:54:21 <yates> khem: i think you were the one that encouraged me to use pkg-config... what say you?
Sep 24 17:56:01 <yates> use the sysroot pkg-config? (just verified it is there)
Sep 24 17:56:46 <kroon> yates, you might want to have some env variables set aswell
Sep 24 17:57:16 <kroon> yates, like PKG_CONFIG_SYSROOT_DIR
Sep 24 17:58:13 <kroon> yates, which the sdk env. script should setup for you iirc
Sep 24 17:58:21 <yates> script?
Sep 24 17:58:25 <yates> what script?
Sep 24 17:58:53 * yates searches for an sdk env. script
Sep 24 17:59:09 <kroon> yates, are you using the sdk generated by yocto ?
Sep 24 17:59:12 <yates> yes
Sep 24 17:59:53 <yates> you mean the script that installs the sysroot on your build system?
Sep 24 18:00:15 <kroon> 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 <kroon> yates, no, another script
Sep 24 18:01:08 <yates> kroon: what is the file name? xyz.sh?
Sep 24 18:01:27 <kroon> yates, you did use "bitbake -c populate_sdk <recipe>" to create the sdk right ?
Sep 24 18:01:33 <yates> yes
Sep 24 18:02:29 <kroon> see meta/classes/toolchain-scripts.bbclass
Sep 24 18:02:35 <kroon> i dont remember the filename
Sep 24 18:02:37 <yates> 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 <yates> ok
Sep 24 18:03:33 <kroon> you need to run the installer on the host your developing on
Sep 24 18:05:26 <yates> how does it make such env. variables persistent? does it actually modify your bash.rc or whatnot?
Sep 24 18:06:05 <kroon> they are not persistent, they only affect the shell you source the script from
Sep 24 18:06:22 <yates> ahh, see, that would be a problem.
Sep 24 18:06:28 <yates> i do not have yocto install on fedora
Sep 24 18:06:36 <yates> it does not support fedora
Sep 24 18:07:22 <kroon> you cannot run the sdk installer in fedora ?
Sep 24 18:07:27 <yates> i've done cross-builds for many other apps but they didn't need pkg-config, so they "work"?
Sep 24 18:07:49 <yates> s/?/./
Sep 24 18:08:24 <yates> ok
Sep 24 18:08:31 <yates> maybe i can
Sep 24 18:29:22 <JaMa> yates: see status e-mails from khem
Sep 24 18:29:33 <yates> ok
Sep 24 18:32:51 <yates> 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 <mischief> anyone else have a clue about why kernel-module-foo prefixes dont work?
Sep 24 19:26:14 <tesaddict> 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 <rburton> yates kroon: yocto supports fedora
Sep 24 20:09:46 <rburton> if you're using a too new fedora for the sanity test, give it a go anyway
Sep 24 20:32:30 <kroon> 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 <diamondman> 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 <mischief> diamondman: o/
Sep 24 20:39:46 <diamondman> mischief: Oh hey Nick, how you doing?
Sep 24 20:41:40 <kroon> diamondman, you can use ${@...} in shell functions
Sep 24 20:41:45 <mischief> diamondman: well
Sep 24 20:41:54 <mischief> fighting yocto as well :-)
Sep 24 20:47:50 <yates> 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 <yates> rburton: "So upgrade". yates: "It's complicated"
Sep 24 20:48:48 <yates> is there a known problem with the cross-compile version of uname not being available?
Sep 24 20:48:52 <yates> in the sdk?
Sep 24 20:50:48 <kroon> yates, why would you need a cross-compile uname, to detect the compiler triplet ?
Sep 24 20:51:23 <yates> it's in wx's wx-config srript. selects whether there is a lib64 or just a lib
Sep 24 20:51:27 <yates> script
Sep 24 20:51:44 <kroon> aha
Sep 24 20:52:57 <yates> i would _really_ like to get wx to work cross-platform - speeds up development a bunch
Sep 24 20:53:58 <kroon> sounds like wx-config might need patching. unless there is a .pc you can use instead
Sep 24 20:54:33 <yates> that would be the right way to do it.
Sep 24 21:15:40 <adelcast> 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 <yates> 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 <yates> that is what's happening with the wx-config
Sep 24 21:29:13 <yates> 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 <yates> ...supposed to be made relative...
Sep 24 21:30:33 <yates> should i just hack it to refer to the host file(s)?
Sep 24 21:30:41 <yates> usr/lib64/... ?
Sep 24 21:30:53 <yates> <hack, hack>
Sep 24 21:31:05 <yates> i have an excellent hacking tool: emacs!
Sep 24 21:31:33 <rburton> 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 <adelcast> yep, one time mess-up
Sep 24 21:33:13 <rburton> cool
Sep 24 21:34:41 <yates> rburton: is there a way to do this, or do you have to modify the script?
Sep 24 21:40:53 <rburton> 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 <rburton> 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 <yates> patented? :)
**** ENDING LOGGING AT Wed Sep 25 02:59:57 2019