**** BEGIN LOGGING AT Tue Jun 04 03:00:19 2019
Jun 04 04:34:25 <yocti> New news from stackoverflow: "File format not recognized" when building Petalinux app <https://stackoverflow.com/questions/53765087/file-format-not-recognized-when-building-petalinux-app>
**** BEGIN LOGGING AT Wed Jun 05 03:21:04 2019
Jun 05 06:11:46 <alessioigor> good morning
Jun 05 06:11:48 <alessioigor> Could you point me to the relevant documentation for install and use mingw32 based SDK, please?
Jun 05 08:14:27 <luckywho> Hi Guys, i'm facing some issue with python in oe.
Jun 05 08:17:56 <luckywho> Missing Python modules on target
Jun 05 09:40:18 <litb> hello folks
Jun 05 09:40:40 <litb> can the sstate-cach be relocated to outside the build/, once it has been populated?
Jun 05 09:57:48 <LetoThe2nd> litb: nope
Jun 05 09:58:44 <LetoThe2nd> litb: there might be evil magic with links etc, but i'd expect a lot of breakage. hence, just "no"
Jun 05 09:58:57 <LetoThe2nd> luckywho: can you please be more specific?
Jun 05 10:07:26 <luckywho> LetoThe2nd, I'm using python 2.7.13 in openembedded core. Target, /usr/lib/python2.7/ i have limited library modules. In target i don't have specific reason why many modules such subprocess, string, textwrap and manymore are not their in target. I'm missing many modules.
Jun 05 10:09:18 <luckywho> http://cgit.openembedded.org/openembedded-core/log/meta/recipes-devtools/python?h=rocko
Jun 05 10:09:42 <LetoThe2nd> luckywho: python is split into a lot of smaller packages for space efficiency reasons. so, install the modules you need specifically. find some inspiratoin here: http://cgit.openembedded.org/meta-openembedded/tree/meta-python/recipes-core/packagegroups/packagegroup-meta-python.bb?h=master
Jun 05 10:16:54 <luckywho> LetoThe2nd: Thanks for your help. BUt i don't have meta-python folder. I can see meta & meta-poky folder.  http://cgit.openembedded.org/openembedded-core/log/meta/recipes-devtools/python?h=rocko
Jun 05 10:18:12 <LetoThe2nd> luckywho: same reasoning applies. please see: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python?h=rocko
Jun 05 10:20:24 <LetoThe2nd> more specifically, see http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python-2.7-manifest.inc?h=rocko
Jun 05 10:20:48 <litb> LetoThe2nd, thanks
Jun 05 11:04:53 <rburton> litb: sstate-cache can be moves, yes
Jun 05 11:05:31 <rburton> luckywho: if you want all of py then add python-modules to the image
Jun 05 11:05:50 <rburton> in fact, just python should be sufficient with a recent release.
Jun 05 11:06:20 <luckywho> rburton: How?
Jun 05 11:06:49 <rburton> add python to IMAGE_INSTALL for the image you're building
Jun 05 11:13:08 <luckywho> rburton: Will it be local.conf file. I'm noob in yocto.
Jun 05 11:13:39 <rburton> luckywho: you can do that, but ideally if you want a custom image, make a custom image.  copy and edit the image file that you're building already.
Jun 05 11:18:44 <litb> rburton, so is LetoThe2nd wrong that I can't move  it?
Jun 05 11:18:51 <rburton> yes, sstate can easily be moved
Jun 05 11:19:13 <rburton> you can't move tmp/ inside the build directory, but you can just delete that and rebuild from sstate in seconds
Jun 05 11:23:04 <luckywho> rburton: In poky/build/conf/local.conf, IMAGE_INSTALL += "python". Is that correct?
Jun 05 11:24:57 <LetoThe2nd> rburton: ah nice. thanks for the correction. messe dup tmp and sstate then, me.
Jun 05 11:25:23 <rburton> luckywho: if you're going to do it in local.conf then IMAGE_INSTALL_append = " python" is probably safer as i've no idea what image you're using.  this is in the manual, btw.
Jun 05 11:49:30 <litb> rburton, should I trust you or LetoThe2nd
Jun 05 11:49:43 <rburton> litb: me, obviously :)
Jun 05 11:50:45 <litb> rburton, i see, you seem to have 40 repositories on github. sounds trustworthy
Jun 05 11:51:15 <RP> litb: rburton is right, you can move sstate
Jun 05 11:51:49 <RP> litb: I wrote large chunks of sstate code if that helps ;-)
Jun 05 11:57:52 <litb> thanks folks.  you saved me so much time!
Jun 05 12:39:04 <yocti> New news from stackoverflow: Yocto ERROR: Function failed: SYSTEMD_SERVICE_package value myservice.service does not exist <https://stackoverflow.com/questions/56460650/yocto-error-function-failed-systemd-service-package-value-myservice-service-do>
Jun 05 14:11:31 <lpapp> hi, why does HOST_ARCH not make it into my makefile if I use make -e in my do_compile?
Jun 05 14:11:51 <lpapp> if I do make HOST_ARCH=$(HOST_ARCH) ... then it makes it into the Makefile.
Jun 05 14:17:48 <qschulz> look into oe_runmake
Jun 05 14:18:33 <qschulz> it takes EXTRA_OEMAKE variable and put it as argument of make in oe_runmake_call
Jun 05 14:18:47 <qschulz> I guess HOST_ARCH is put into this variable?
Jun 05 14:19:50 <qschulz> if you're only wanting to pass some more variables to make, just do an EXTRA_OEMAKE += "jqlrvrg" and leave do_compile without modifications
Jun 05 14:20:05 <lpapp> that is a real shame.
Jun 05 14:20:19 <lpapp> I thought make -e will make all the bitbake environment variables directly accessible
Jun 05 14:20:34 <lpapp> so my only option is FOO=${FOO} then to make it directly accessible
Jun 05 14:21:03 <lpapp> but then I am puzzled entirely how other environment variables like compilation flags, etc, make it into our build system. It is a complete mystery...
Jun 05 14:21:18 <lpapp> I think it would make no sense to wrap it all from environment into EXTRA_OEMAKE...
Jun 05 14:21:36 <lpapp> since no build system wants to build openembedded specific variables into their build system... that would be nightmare.
Jun 05 14:21:42 <lpapp> so I find it hard to believe it.
Jun 05 14:23:33 <qschulz> yes, you need EXTRA_OEMAKE += "FOO=${FOO}" to pass FOO to your makefile
Jun 05 14:24:13 <lpapp> our do_compile is: "make -e LD="${CCLD}" CCACHE=0 foo"
Jun 05 14:24:33 <qschulz> foo is your target I guess?
Jun 05 14:24:37 <lpapp> yeah
Jun 05 14:24:47 <lpapp> also, why does Yocto set HOST_ARCH as arm
Jun 05 14:24:53 <lpapp> but ARCH to arm in the SDK
Jun 05 14:24:57 <lpapp> should they not be consistent
Jun 05 14:25:10 <lpapp> so any project using yocto or the sdk to build, they can rely on one variable, not multiple
Jun 05 14:25:41 <qschulz> oe_runmake foo and you add your "flags" to EXTRA_OEMAKE
Jun 05 14:25:50 <lpapp> qschulz: if I have to do that, I would rather do make ... FOO=$(FOO)
Jun 05 14:25:55 <lpapp> than an extra line
Jun 05 14:26:05 <qschulz> I'd not
Jun 05 14:26:26 <qschulz> you depends on LDFLAGS, CFLAGS, etc...
Jun 05 14:26:32 <qschulz> ag my bad
Jun 05 14:27:01 <qschulz> I guess you should be able to do oe_runmake -e -e LD="${CCLD}" CCACHE=0 foo
Jun 05 14:27:07 <qschulz> oe_runmake, not make
Jun 05 14:27:33 <qschulz> (and only one -e, bad copy-pasting)
Jun 05 14:27:56 <qschulz> if you use make, you loose everything that is in EXTRA_OEMAKE
Jun 05 14:28:14 <lpapp> why is TARGET_ARCH not set
Jun 05 14:28:31 <lpapp> it should be according to manual if HOST_ARCH is set, but bitbake -e foo | grep ^TARGET_ARCH shows it empty
Jun 05 14:28:58 <kuzulis> Hi guys. Why when I try to add the RDEPENDS_${PN} = "... \gstreamer1.0-plugins-ugly-meta" to my packagegroup, then the bitbake say that nothing provides this package? But as I can see in /sources/poky/meta/recipes-multimedia/gstreamer/ thnen I see that the gstreamer1.0-plugins-ugly_1.10.4.bb is present..
Jun 05 14:28:59 <qschulz> some variables are resolved later
Jun 05 14:29:54 <lpapp> kuzulis: I do not know. But there is a meta difference
Jun 05 14:30:14 <qschulz> Is there a ${PN}-meta in gstreamer1.0-plugins-ugly_1.10.4.bb?
Jun 05 14:30:18 <lpapp> qschulz: bitbake -e foo | grep ^EXTRA_OEMAKE -> returns empty
Jun 05 14:30:46 <lpapp> qschulz: should I use HOST_ARCH or TARGET_ARCH
Jun 05 14:30:52 <lpapp> furthermore, why not ARCH like in the SDK?
Jun 05 14:30:56 <lpapp> why inconsistency
Jun 05 14:31:54 <kuzulis> qschulz: No, there no any 'meta' mention.
Jun 05 14:32:31 <qschulz> lpapp: look into the workdir of your recipe, you have a temp directory. In there, you have run.do_something and log.do_something. Former is what is run, latter is the log of what is run. It might help you later anyway
Jun 05 14:33:34 <kuzulis> qschulz: But, when I add 'gstreamer1.0-plugins-bad-meta' to my RDEPENDS_${PN} then it does work, even if gstreamer1.0-plugins-bad_1.10.4.bb has not any 'meta' mention
Jun 05 14:33:49 <qschulz> lpapp: Host for host, target for target. Depends on what you're building. Native? Host most likely. For your DUT? Target most likely.
Jun 05 14:34:20 <qschulz> I'm no Yocto developer honestly so just giving my 2cts
Jun 05 14:34:31 <lpapp> qschulz: what is DUT?
Jun 05 14:34:40 <qschulz> device under test
Jun 05 14:34:44 <qschulz> or your target if you prefer
Jun 05 14:34:57 <lpapp> yeah, building within Yocto for arm
Jun 05 14:35:05 <lpapp> in an Intel vm
Jun 05 14:36:07 <lpapp> qschulz: do we really need -e with oe_runmake and explicit var maps
Jun 05 14:37:33 <lpapp> well
Jun 05 14:37:35 <lpapp> lpapp@yocto-build-32:~/Projects/polatis/Yocto/src/build$ bitbake -c cleanall
Jun 05 14:37:35 <lpapp> ERROR: Only one copy of bitbake should be run against a build directory
Jun 05 14:37:35 <lpapp> lpapp@yocto-build-32:~/Projects/polatis/Yocto/src/build$ killall bitbake
Jun 05 14:37:35 <lpapp> bitbake: no process found
Jun 05 14:37:37 <lpapp> lpapp@yocto-build-32:~/Projects/polatis/Yocto/src/build$
Jun 05 14:37:43 <lpapp> how is this possible :)
Jun 05 14:38:45 <qschulz> bitbake.lock
Jun 05 14:38:52 <lpapp> hmm
Jun 05 14:39:29 <lpapp> so why is ARCH not defaulting to TARGET_ARCH
Jun 05 14:39:42 <lpapp> so that build systems can rely on the ARCH variable both in and outside Yocto
Jun 05 14:39:53 <qschulz> Yocto is a build system
Jun 05 14:40:59 <lpapp> ikr
Jun 05 14:41:04 <qschulz> so I don't quite understand what you're trying to say
Jun 05 14:41:56 <qschulz> AH, I guess you want to be able to use the same makefile without too much magic and use ARCH since it's what's used most of the time
Jun 05 14:42:39 <lpapp> yeah
Jun 05 14:42:53 <lpapp> I guess ARCH="${TARGET_ARCH}" is uncool for everyone included
Jun 05 14:42:57 <qschulz> I'd have a look at the kernel recipes, since I remember compiling it with make ARCH= and I'm not sure it actually supports TARGET_ARCH
Jun 05 14:43:10 <qschulz> so there needs to be something in the kernel recipe
Jun 05 14:43:19 <qschulz> (might be in the kernel.bbclass also)
Jun 05 14:43:30 <lpapp> by the way, TARGET_ARCH does not work for me
Jun 05 14:43:31 <qschulz> (beware, it's a pretty huge and complex recipe/class)
Jun 05 14:43:32 <lpapp> HOST_ARCH does
Jun 05 14:43:37 <lpapp> it looks like TARGET_ARCH is not set, why?
Jun 05 14:44:45 <lpapp> oh, sorry, I was wrong
Jun 05 14:45:14 <lpapp> we also run make strip in the do_compile target after make
Jun 05 14:45:29 <lpapp> is there a way to do it automatically with oe_runmake?
Jun 05 14:45:47 <lpapp>     oe_runmake ARCH="${TARGET_ARCH}" LD="${CCLD}" CCACHE=0 target
Jun 05 14:45:47 <lpapp>     oe_runmake strip
Jun 05 14:45:50 <lpapp> these two in one line?
Jun 05 14:46:06 <rburton> no because make will run both in parallel
Jun 05 14:46:11 <lpapp> target strip maybe
Jun 05 14:46:29 <rburton> (this is a make question, not yocto)
Jun 05 14:46:46 <lpapp> probably true
Jun 05 14:47:05 <lpapp> make target will not strip though
Jun 05 14:49:12 <qschulz> lpapp: why do you want it in one line?
Jun 05 15:05:26 <lpapp> qschulz: avoid the word make twice
Jun 05 15:05:41 <lpapp> or oe_runmake for that matter
Jun 05 15:09:26 <yocti> New news from stackoverflow: How to fix "undefined reference to symbol 'vxCannyEdgeDetectorNode'" error compiling openvx on yocto <https://stackoverflow.com/questions/56463256/how-to-fix-undefined-reference-to-symbol-vxcannyedgedetectornode-error-compi>
Jun 05 15:16:55 <armpit> behanw, did you get the updated slide dec?
Jun 05 16:00:27 <JPEW> RP: I'm seeing some weird reproducibility problems related to RDEPENDS..... it looks like RDEPENDS get pulled into the RSS, but not consistently (or reproducibly)
Jun 05 16:01:11 <JPEW> For example, in one run acl finds"echo" from the host, and in another its from the RSS
Jun 05 16:03:24 <RP> JPEW: this sounds like investigation is needed. I'm not entirely surprised :/
Jun 05 16:09:34 <yocti> New news from stackoverflow: Set new user permissions in Yocto recipe <https://stackoverflow.com/questions/56463788/set-new-user-permissions-in-yocto-recipe>
Jun 05 16:14:00 <RP> JPEW: oh, I might be able to explain that
Jun 05 16:14:40 <RP> JPEW: RSS is populated "as needed" so if do_package has a dependency it would only get added at do_package time. It might not be there at do_compile time
Jun 05 16:15:09 <RP> JPEW: I talked about how we have recipe specific sysroots and not task specific sysroots in the original pull request for the work
Jun 05 16:42:10 <JPEW> RP: Does that mean if a recipe is rebuilt the RSS might have different contents left over from the last run?
Jun 05 16:44:23 <RP> JPEW: yes
Jun 05 16:44:54 <RP> JPEW: well the tasks are meant to to use anything they don't explicitly depend upon
Jun 05 16:45:00 <RP> not to use
Jun 05 16:45:32 <RP> JPEW: reality is there is some potential window there and it was a known problem with the design of RSS. I don't know how we could avoid it really
Jun 05 16:46:05 <RP> task specific sysroots would be insane and really hard to make work and we can't know all the task dependencies at do_configure time (some are circular too)
Jun 05 16:47:25 <RP> (also changing the compiler paths between configure and compile turned out to be near impossible to make workable)
Jun 05 17:09:44 <yocti> New news from stackoverflow: Unable to Upgrade A Recipe for a Meta-Layer in Yocto Krogoth <https://stackoverflow.com/questions/56465052/unable-to-upgrade-a-recipe-for-a-meta-layer-in-yocto-krogoth>
Jun 05 18:14:45 <litb> hello folks
Jun 05 18:15:24 <litb> is there a workflow for creating a distribution installer? I.e let's assume you have created your image, and now you want an installer for that firmware, that boots up when customers want to upgrade to that firmware
Jun 05 18:15:38 <litb> is there a framework for that, that can be used with yocto?
Jun 05 18:29:13 <RP> litb: it tends to be very usecase specific. I know people have done it, not sure there is a standard framework though
Jun 05 18:51:17 * RP should probably mention https://autobuilder.yocto.io/pub/non-release/ now its providing more useful info in the index
Jun 05 19:07:24 <JPEW> Is that only successful builds?
Jun 05 19:08:22 <RP> JPEW: no, any build on the AB that generated testresults
Jun 05 19:08:39 <JPEW> nice
Jun 05 19:08:57 <RP> oh, it also now has https://autobuilder.yocto.io/pub/non-release/20190605-1/testresults/qemuarm64-ptest-fast/ *.log
Jun 05 19:09:04 <RP> i.e. all ptest logs are extracted magically
Jun 05 19:11:09 <RP> JPEW: your code in action :)
Jun 05 19:11:23 <RP> lets me close a few more bugs :)
Jun 05 19:12:33 <JPEW> Good.... I opened one about the RSS + reproducibility
Jun 05 19:12:55 <JPEW> Not sure what to do about it right now, need to have a think
Jun 05 19:18:10 <RP> JPEW: I'm not sure its a huge issue, we likely just need to force a few config values i.e. sort is just sort, no path
Jun 05 19:18:42 <RP> maybe hack the actual macro
Jun 05 19:18:49 <JPEW> RP: Ya thats fair; do you think that should just be done automatically for several of the hosttools?
Jun 05 19:19:26 <RP> JPEW: possibly. I know I already did it for sed, bash/sh and maybe some others
Jun 05 19:20:21 <JPEW> Hmm, would that fix it though? If we set SED="sed" it would still actually use the sed from sysroot-native, since it comes before hosttools in PATH.
Jun 05 19:21:43 <JPEW> I guess it would make the makescripts consistent and the build outputs would be consistent as long as the two seds acted the same
Jun 05 19:38:07 <RP> JPEW: perhaps we should just enforce coreutils not to overlap with HOSTTOOLS?
Jun 05 19:38:13 <RP> (coreutils-native that is)
Jun 05 19:38:29 <RP> JPEW: we do already assume that the HOSTTOOLS behave the same really
Jun 05 19:39:21 <JPEW> As in modify the coreutils-native recipe to not install anything that happens to be in HOSTTOOLS (e.g. echo, sort, etc.)?
Jun 05 20:12:55 <m1ster_r0b0t> Good evening everyone!
Jun 05 20:15:29 <m1ster_r0b0t> one question: has libelf-dev been patched out of elfutils?
Jun 05 20:28:18 <rburton> m1ster_r0b0t: nope
Jun 05 20:34:43 <m1ster_r0b0t> so how can i install it to an image? just add recipes-devtools/elfutils/elfutils_0.176.bb?
Jun 05 20:59:30 <rburton> elfutils-dev
Jun 05 21:04:40 <m1ster_r0b0t> is it inside elfutils? i just get a  elfutils RPROVIDES elfutils-dev
Jun 05 21:19:42 <rburton> m1ster_r0b0t: elfutils-dev:
Jun 05 21:19:42 <rburton> 	/usr/include/dwarf.h
Jun 05 21:19:44 <rburton> 	/usr/include/elfutils/elf-knowledge.h
Jun 05 21:19:44 <rburton> ..
Jun 05 21:19:57 <rburton> the elfutils recipe builds an elfutils-dev package
Jun 05 21:50:45 <m1ster_r0b0t> thx!
**** ENDING LOGGING AT Thu Jun 06 02:59:57 2019