seninha has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
thomasd13 has joined #yocto
alessioigor has joined #yocto
sveinse has quit [Ping timeout: 250 seconds]
shoragan has quit [Ping timeout: 246 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Vonter has quit [Ping timeout: 264 seconds]
shoragan has joined #yocto
Vonter has joined #yocto
<mcfrisk>
hi, is there a nice way to get a qemu-system-aarch64 out of yocto build to use it for running an image?
<mcfrisk>
I can use qemu-system-native inside devshell, or install it to an SDK but those seem a bit tricky to automate running the image
Schlumpf has joined #yocto
Vonter has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
mckoan|away is now known as mckoan
alessioigor has joined #yocto
starblue has quit [*.net *.split]
Saur has quit [*.net *.split]
alicef has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
vvn has quit [*.net *.split]
chep has quit [*.net *.split]
Estrella___ has quit [*.net *.split]
yann has quit [*.net *.split]
mrnuke has quit [*.net *.split]
PhoenixMage has quit [*.net *.split]
Ebeneezer_Smooge has quit [*.net *.split]
Ram-Z has quit [*.net *.split]
Emantor has quit [*.net *.split]
Bardon has quit [*.net *.split]
alex88 has quit [*.net *.split]
grma has quit [*.net *.split]
Ch^W has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
zwelch has quit [*.net *.split]
Estrella has quit [*.net *.split]
bantu has quit [*.net *.split]
mrnuke has joined #yocto
zwelch has joined #yocto
starblue has joined #yocto
tlwoerner has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
alicef has joined #yocto
Estrella has joined #yocto
Bardon has joined #yocto
Ram-Z has joined #yocto
chep has joined #yocto
bantu has joined #yocto
SSmoogen has joined #yocto
Emantor has joined #yocto
alex88 has joined #yocto
vvn has joined #yocto
Estrella__ has joined #yocto
Ch^W has joined #yocto
tangofoxtrot has joined #yocto
PhoenixMage has joined #yocto
odra_ has joined #yocto
Saur has joined #yocto
<mcfrisk>
oh looks like work/x86_64-linux/qemu-helper-native is in the default qemu machine output, and works with poky/scripts/runqemu
zpfvo has joined #yocto
alex_b has joined #yocto
eggman has quit [Read error: Connection reset by peer]
xmn has quit [Ping timeout: 264 seconds]
abu has joined #yocto
abu has quit [Client Quit]
vm has joined #yocto
vm has quit [Client Quit]
vm1 has joined #yocto
eggman has joined #yocto
<dacav>
Hi. Question about deploy.bbclass, that I see used by some colleagues. If my recipe {Y} DEPENDS on {X} or {X}-native, it should have the artefacts produced by {X} into the sysroot. Using `deploy`, on the other hand, is said to beuseful "only when a recipe needs to read a file already deployed by a dependency". Is `deploy` intended as a way to share data without polluting the sysroot perhaps?
yann has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
prabhakarlad has joined #yocto
<vm1>
dacav: what do you mean 'way to share data'?
paowz_ has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<ykrons>
Hi all
Vonter has joined #yocto
rfried has joined #yocto
<ykrons>
I have a .bbappend that mainly add a script to SRC_URI and then copy it with cp into ${D} during the do_install_append. My problem is that when I'm changing the content of the script the resulting package is not updated. I'm working with a "devtool modify <myrecipe>". Don't know if it can have an impact.
<ykrons>
I have checked the sigdata content and I have a checksum associated with my script so I have expected that any change to the script content will be detected.
MrFrank has quit [Read error: Connection reset by peer]
<ykrons>
Did someone know if it is linked to devtool usage, bad bbappend or other potential issues? Thanks
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<vm1>
dacav: if by data you mean all those files from do_install of the recipes in DEPENDS, and files moved to DEPLOY_DIR_IMAGE by deploy.bbclass, my understanding is that use of DEPLOY_DIR_IMAGE to access data from other recipes is not appropriate, there is no guarantee the files would be deployed by the time do_configure starts. Is it good to "pollute"
<vm1>
DEPLOY_DIR_IMAGE with files which are not intented for deployment?
vm1 has quit [Quit: Client closed]
vm1 has joined #yocto
<qschulz>
dacav: the sysroot is meant for things that make sense on a root filesystem, shared libraries, headers, binaries, etc...
zpfvo has quit [Ping timeout: 268 seconds]
goliath has joined #yocto
<qschulz>
dacav: a good example of when this does not necessarily make sense is for example for U-Boot, the Linux kernel, firmware for cortex-M0 side-processors, etc..
<LetoThe2nd>
yo dudX
<qschulz>
they are still necessary though
mvlad has joined #yocto
zhmylove has joined #yocto
zpfvo has joined #yocto
MrFrank has joined #yocto
grma has joined #yocto
<dacav>
vm1: by 'shared data' I mean any artifacts. Binaries and configuration files that would go under the regular hier(7) seem to be well suited for the sysroot. As qschulz seems to be on the same page about, it looks to me that DEPLOYDIR / DEPLOY_DIR_IMAGE are meant for stuff that must be available through the dependency graph, without being in the sysroot.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Schlumpf has quit [Ping timeout: 244 seconds]
kanavin has quit [Quit: Leaving]
<qschulz>
ykrons: I do think that you cannot change local files from your layers when you have the recipe used in devtool
<qschulz>
ykrons: you would need to re-modify your recipe with devtool
<qschulz>
because devtool does not trigger a re-fetch of recipe sources since it's using externalsrc directly under the hood
<vm1>
dacav: there is a danger that the artifacts are connected to certain versions of packets, I think it is better not to use DEPLOY_DIR_IMAGE to share artifacts
<qschulz>
vm1: that is correct, you absolutely need to manually specify a dependcy in recipe Y task using the deployed artifacts on do_deploy:recipeX
<qschulz>
dacav: ^
Vonter has quit [Ping timeout: 268 seconds]
<vm1>
we've used DEPENDS and STAGING_DIR_HOST
<qschulz>
if you need the deployed artifacts from recipe X in recipe Y do_compile: in recipe Y: do_compile[depends] += "do_deploy:recipeX" (IIRC, probably worth checking)
kanavin has joined #yocto
<qschulz>
vm1: using the sysroot for sharing the trusted-firmware-a needed for compiling u-boot for example is not that great
<qschulz>
because tf-a has nothing to do in the sysroot
<qschulz>
has no reason to be in the sysroot*
alessioigor has quit [Quit: alessioigor]
<ykrons>
qschulz: thanks for clarifications!
<vm1>
qschulz: how to guarantee that the binaries would be deployed by the time recipe is about to access them? DEPENDS doesn't give warranty binaries are deployed
<inisider>
hello. what can i do in situation when I have 2 recipes which produce the same libraries ( in my case it is /usr/lib/libz.so )? How can I tell Yocto to use library from recipe that I want? Right it is using the libraries from poky's recipe. I tried to remove zlib directly using CORE_IMAGE_INSTALL_remove="zlib" but I am not sure that it helps
<qschulz>
inisider: if you recipe is entirely replacing whatever the zlib recipe produces, you can specify in your own recipe that it PROVIDES zlib and then set PREFERRED_PROVIDER_zlib = "your-recipe"
<qschulz>
but the latter variable needs to be set in a configuration file (distro, machine,)
<neverpanic>
If your recipe is shipping its own private copy of libz.so, you should move it into a separate directory, adjust your binaries' rpaths to find it, and set PRIVATE_LIBS = "libz.so"
<dacav>
vm1, qschulz: I don't think I get this entirely. If I declare a dependency (Y depends on X), why can't I assume that the recipe of X populated DEPLOY_DIR_IMAGE? Also, is yocto even allowing multiple versions of the same packages? (well, unless I have two recipes with distinct names providing different versions, but that's ugly and probably wrong)
<dacav>
ah sorry, I didn't see the rest of the discussion.
zpfvo has joined #yocto
<inisider>
qschulz: I tried to use PREFERRED_PROVIDER_zlib="zlib-ng" but it looks like it is still continue to use zlib from poky. At least md5sum is different and I don't see all the files from {WORKDIR}/zlib-ng/.../image/
paowz has quit [Ping timeout: 268 seconds]
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
<dacav>
thank you all for the clarification, I think I get it now :)
Vonter has joined #yocto
<qschulz>
dacav: DEPENDS under the hood is something like: do_populate_sysroot[depends] += "recipeSDEPENDS:do_prepare-_ecipe_sysroot"
<qschulz>
nothing else, it's just a nicer way for users to set dependencies
paowz has joined #yocto
<qschulz>
but it is a depoendency of one task on another recipe's
<qschulz>
and deploy is typically NOT run before do_prepare_recipe_sysroot, so you cannot rely on do_deploy to run before do_populate_sysroot/do_compoile/whatever is executed
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<qschulz>
inisider: if something explicitly RDEPENDS on a package from the original zlib package, that's going to be an issue I think
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<inisider>
qschulz: it looks like that. i think that a lot of packages have dependce of zlib.
<dacav>
qschulz: excellent. I think I've read something about a deployment step that should allow bitbake to publish artifacts on the platform (e.g. via sftp). Is that what the deploy.bbclass actually is about, or is that a completely different thing? We don't use such workflow (not sure if we will ever)
goliath has quit [Quit: SIGSEGV]
lysxjz has joined #yocto
<dacav>
The fact that the dependency must be stated explicitly, lets me think that the artifacts sharing is not the intended use of deploy.
lysxjz has quit [Client Quit]
MrFrank has quit [Read error: Connection reset by peer]
<qschulz>
dacav: deploy is for putting stuff into tmp/deploy directory
nemik has quit [Ping timeout: 268 seconds]
<qschulz>
it is a way to share artifacts between recipes without going through the sysroot mechanism, which does not make sense for athings that aren't supposed to be in the rootfs
nemik has joined #yocto
<qschulz>
how you publish artifacts to your users or whatever is not specific to Yocto, I don't think we have anything for this, nor is a task for Yocto/Bitbake?
<dacav>
it is not related with the deploy.bbclass.
<kayterina[m]>
Hello, what does it means that workdir won't exist in a build from sstate? I want to reference files from a DEPEND, is this path "${RECIPE_SYSROOT}${localstatedir}/" better than this "${WORKDIR}/recipe-sysroot/var/"? The way I see it in bitbake.conf, RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"
<rburton>
if recipe A DEPENDS on B, but B is pulled from sstate, then it's workdir *will not exist*
<rburton>
if you want to look at your own sysroot then use RECIPE_SYSROOT
MrFrank has joined #yocto
<rburton>
putting files into the sysroot is the one true way to share content between recipes. Normally /usr/include and /usr/lib and pretty much evertyhing that is shared but you can extend that per-recipe
yann has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<kayterina[m]>
How can I force B to be pulled from sstate to see this in test?
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
<rburton>
bitbake A, rm tmp, bitbake A -C unpack
<rburton>
-Cunpack will force A to rebuild, but its dependencies will be pulled in from sstate
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<kayterina[m]>
OK, so after this, recipe A has inside its recipe-sysroot the files from B, but recipe B has no workdir
<rburton>
right
<inisider>
qschulz: could you please explain to me what it means by unique depenecies and is it possible to overcome this issue? https://pastebin.com/Gn4st6Pe
<kayterina[m]>
how could someone reference B's workdir from recipe A since workdir is local to the recipe?
<neverpanic>
You shouldn't do this at all
<neverpanic>
If you need files from B in recipe A, install them in sysroot or some other shared location.
<kayterina[m]>
I understand. But hypothetically, someone could have a path like "$workdir/../recipeB/ ?
<kayterina[m]>
Yes, I suppose someone could do that, no question here.
<neverpanic>
You could, and it would work the first time, but not for the second build when sstate caching is used, and you'll get a hard to debug build failure.
<neverpanic>
So don't.
<LetoThe2nd>
kayterina[m]: hypothetically, you could look at what the kernel does. and practically, no, the path won't work reliably. the correct route is, as pointed out numerous times by now, to package up the things you want to share.
<kayterina[m]>
If recipe A DEPENDS on B and wants to use files from the metadata is sysroot still the way to go?
<LetoThe2nd>
kayterina[m]: "files from the metadata"
<LetoThe2nd>
please elaborate.
<kayterina[m]>
files from recipeA/files the ones I usually include with "file://" in the SRC_URI
<LetoThe2nd>
kayterina[m]: so if two recipes actually need it - why not put it into a separate recipe that both can depend upon? it can even be a -native one to avoid the danger of shipping it accidentially.
<neverpanic>
I you want a file specified in recipe B's SRC_URI to be usable in recipe A, either package it in B (e.g. by copying it to ${D} during the build), or what LetoThe2nd says.
<zhmylove>
kayterina[m]: optionally you can prepend to FILESEXTRAPATHS of recipeA and use files from recipeB
zpfvo has quit [Ping timeout: 268 seconds]
goliath has joined #yocto
alessioigor has joined #yocto
Schlumpf has joined #yocto
<kayterina[m]>
I would even put it in a .bbappend because the recipe just concats the files but it has to be seperate recipe. I will go with sysroots.
<LetoThe2nd>
where could a dependency chain on u-boot be hidden in core-image-minimal? it obviously does not show up in IMAGE_INSTALL
<LetoThe2nd>
rburton: ya the PREFERRED_PROVIDER also looks good
inisider has quit [Remote host closed the connection]
vm1 has quit [Quit: Client closed]
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
cambrian_invader has quit [Ping timeout: 255 seconds]
Schlumpf has quit [Quit: Client closed]
Schiller has joined #yocto
cambrian_invader has joined #yocto
<Schiller>
In the Autobuilder2 Repository i see that the notifier logic is not developed yet. Is there still some way to add set reporters to specific builds or is it at the moment not possible? Do i have to adjust the scripts?
seninha has joined #yocto
Net147 has quit [Quit: Quit]
Payam has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
prabhakarlad has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alex_b has quit [Quit: Client closed]
Payam has quit [Ping timeout: 268 seconds]
d-s-e has joined #yocto
Payam has joined #yocto
Payam has quit [Read error: Connection reset by peer]
zpfvo has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
zpfvo has joined #yocto
jmiehe has joined #yocto
goliath has quit [Quit: SIGSEGV]
vm1 has joined #yocto
vm1 has quit [Client Quit]
xmn has joined #yocto
Vonter has quit [Ping timeout: 248 seconds]
sakoman has joined #yocto
<kayterina[m]>
When would a recipe override $base_prefix in bitbake? For my very specific needs, the difference between using ${RECIPE_SYSROOT}${localstatedir} and ${RECIPE_SYSROOT}$/var
<ernstp>
found a nice way to integrate a Yocto SDK and VS Code cmake tools. there's a property called environmentSetupScript that was a bit hard to find
<ernstp>
So you can write "environmentSetupScript" : "/opt/yoctosdk/environment-setup-cortexa9hf-neon-poky-linux-gnueabi" in ~/.local/share/CMakeTools/cmake-tools-kits.json
zpfvo has quit [Ping timeout: 264 seconds]
yann has joined #yocto
SSmoogen is now known as Ebeneezer_Smooge
DennisE has joined #yocto
leon-anavi has quit [Remote host closed the connection]
inisider has joined #yocto
hpsy[m] has joined #yocto
zpfvo has joined #yocto
leon-anavi has joined #yocto
kscherer has joined #yocto
thomasd13 has quit [Ping timeout: 268 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<DennisE>
Hello :) Its me again, sorry for bothering you frequently.
<DennisE>
How do I show the git submodules to cmake ? I tried EXTERNALSRC but that doesnt work.
zpfvo has quit [Ping timeout: 252 seconds]
d-s-e has quit [Ping timeout: 244 seconds]
prabhakarlad has joined #yocto
<qschulz>
DennisE: i would try to find the cmake option to disable building the unit tests, pretty sure you don't need them :)
<gchamp>
DennisE: I'm not answering your question directory but an option to avoid the issue is to not build the tests during the yocto build using something like EXTRA_OECMAKE += "BUILD_TESTING=off"
zpfvo has joined #yocto
<qschulz>
DennisE: maybe you also want to inherit pkg-config class if it's used by the project to find the dependencies (which you'll have to explicit in the DEPENDS of the reciep0
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
zpfvo has joined #yocto
goliath has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
inisider has quit [Remote host closed the connection]