alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
kevinrowland has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
Schlumpf has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
rob_w has joined #yocto
rfuentess has joined #yocto
mvlad has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 265 seconds]
<Schlumpf>
good morning
<rfuentess>
morning
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
prabhakarlad has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<qschulz>
o/
goliath has joined #yocto
KurtKiefer[m] has quit [Quit: You have been kicked for being idle]
PascalBach[m] has joined #yocto
polprog has joined #yocto
ptsneves has joined #yocto
<polprog>
hi, i hav a custom layer, and arecipe called device-tree:meta-xilinx-core , and i want to append to it with a bbappend
<polprog>
but I can't get the bbappend path right
<ptsneves>
Hey all. Has anybody ever used chroot inside a yocto task?
<qschulz>
polprog: I would avoid anything that isn't a dash, lower-case letter or number in a recipe name (underscore is for separating the recipe name from its version)
manuel1985 has joined #yocto
<polprog>
qschulz: this is my log, the layer name is meta-xilinx-core
<qschulz>
polprog: and also the path to the device-tree recipe in meta-xilinx-core
<qschulz>
polprog: ok, so your bbappend should be named device-tree.bbappend I think, because the recipe in meta-xilinx-core does not have a version in its filename (not best praxctice)
<polprog>
the bbfile is in components/yocto/layers/meta-xilinx/meta-xilinx-core/recipes-bsp/device-tree
<polprog>
i tried with that name too, same resutls
<polprog>
oh, no, the warning is gone
<qschulz>
I was running out of ideas :)
<polprog>
allright, let me build it and see if this fixed my main problem
<qschulz>
polprog: what do you want to do in this bbappend?
<polprog>
I have a DTS file that i need to change. and not only that, there is another layer (part of, let's call it the "bsp") that adds extra parameters that i dont want there.
<polprog>
i need to compleyely replace a devicetree entry for an ethernet controller
<polprog>
my new dt node has less parameters than the old one, so i end up with a dt note that has mostly new parameters, but there are two old ones that the dtc did not change
<polprog>
namely, i need to get rid of "xlnx,ptp-enet-clock = <0x4f790d8>;"
<polprog>
(this is the only difference for this controller between the old Arch Linux dt that works, and the new Petlainux dt that does not work)
<polprog>
s/Petla/Petal/
hcg has joined #yocto
starblue has quit [Ping timeout: 264 seconds]
<polprog>
Hm, so my dtsi file is not included at all,the bbappend is listed in bitbake-layers show-appends device-tree, how can i troubleshoot that?
starblue has joined #yocto
<qschulz>
polprog: go into the device-tree WORKDIR and until you get what you want in the packages-split directory, iterate
<qschulz>
polprog: you can "disassemble" .dtb with dtc btw, dtc -I dtb -O dts my.dtb
<qschulz>
should help you check if the changes you made were taken or not
<polprog>
thats hwo i check if its working ;) how do i find the WORKDIR for that target (?)
<polprog>
i see the workdir but there is no packages-split directory, only temp, with a bunch of files with autogenerated python
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 252 seconds]
<qschulz>
polprog: you probably have rm_work in your INHERIT which removes the directories after a build
<qschulz>
polprog: I suggest to -c cleansstate device-tree and then bitbake -c install devbice-tree (or -c package, install installs in image directory, package to package-split IIRC)
rber|res has quit [Ping timeout: 246 seconds]
rber|res has joined #yocto
mckoan is now known as mckoan|away
alessioigor has joined #yocto
<polprog>
qschulz: allright, i ran -c package device-tree and the only devicetree file i have in packages-split//device-tree/boot/devicetree/system-top.dtb
<polprog>
and that already has the extra parameters inside it
<qschulz>
polprog: so, very likely that your changes aren't applied, or on the wrong file, I don't know
<qschulz>
polprog: check the source files in the WORKDIR are actually the ones you expected?
<polprog>
there arent any source files in WORKDIR, I only see the dtb files in package/ and packages-split/
rber|res has quit [Ping timeout: 264 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
thomasd13 has quit [Ping timeout: 264 seconds]
<qschulz>
polprog: -c cleansstate device-tree and then -c configure or compile or patch
<qschulz>
polprog: actually, add RM_WORK_EXCLUDE += "device-tree" to your local.conf, then -c cleansstate device-tree and do whatever you want afterwards and the files should still be there
<polprog>
ok, so my eth-fix.dtsi is not listed in the final dts.pp file
<rburton>
So it finally happened: adding meta-chromium to a build breaks meta-arm because there are two different and incompatible versions of GN being used. Of course GN doesn't make releases, so this is exactly as designed.
rob_w has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
arlort[m] has joined #yocto
<LetoThe2nd>
yo dudX
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
seninha has joined #yocto
bunk has quit [Quit: leaving]
<ptsneves>
rburton: gn is a disaster to any distro that has projects using it.
<rburton>
yes
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ecdhe has quit [Ping timeout: 244 seconds]
ecdhe has joined #yocto
seninha has quit [Quit: Leaving]
<neverpanic>
It's a google project. Sometimes those feel like they're not meant to work for you, only for them.
<rburton>
sometimes? that's the clear intention
<rburton>
what do you mean your source distro doesn't embed the correct gn binary to use?
<neverpanic>
Just build it in a container, or download this precompiled gn binary from $url, it's fine.
<neverpanic>
:(
<ptsneves>
neverpanic: then why stop there and have yocto at all :D
<rfuentess>
Hi! continuing with my study for getting a debugging image. I'm trying to understand the lifetime for environment variables like `SYSTEMD_AUTO_ENABLE`
<rfuentess>
for our debugging image we want to change some services "default" setting in their respective recipe.
<qschulz>
rfuentess: can only be done from the recipes themselves or from a configruation file
<qschulz>
rfuentess: that's what I was afraid of yesterday
<rfuentess>
qschulz: I was starting to believe it :P
<qschulz>
you really want a debug distro I think
<rfuentess>
I was playing with weak default operators but not luck. So, if I want to have this behavior is better to run POST process command ?
xmn has joined #yocto
<qschulz>
rfuentess: recipe data is local to the recipe
<qschulz>
and image recipes are recipes
<qschulz>
you cannot change a value from a package recipe from another recipe
<rfuentess>
ohhh
<qschulz>
cannot change a variable*
<rfuentess>
then things like `export SYSTEMD_AUTO_ENABLE_<package>` is something very bad to do ?
<qschulz>
it's something that does not work
<rfuentess>
ahhh
<qschulz>
SYSTEMD_AUTO_ENABLE_pn-<package> from a distro or machine or local configuration file should work though
odra_ has quit [Quit: Leaving]
<qschulz>
note where it is added and that you need pn- in front of the package name
<qschulz>
you could also have in your recipe: SYSTEMD_AUTO_ENABLE:debug-distro = "false" and SYSTEMD_AUTO_ENABLE = "true"
<qschulz>
it'll be false when building the debug-distro but not otherwise
Schlumpf has quit [Quit: Client closed]
MichaelNazzareno has joined #yocto
<vvn>
hi! when trying to compile linux-ti-staging with do_configure:append () { oe_runmake -C ${S} O=${B} allmodconfig }, ti-sgx-ddk-km fails with osfunc.c:130:2: error: #error "A preemptible Linux kernel is required when using workqueues", is that expected? Cc: denix
<MichaelNazzareno>
Hello, I'm building some weston image and I would like to have gtk4 in in. Anyone has a reference image to build and include gtk4 that is in meta-gnome in meta-openembedded. I did not find documentaiton
<rfuentess>
qschulz: thanks. I was not sure about their lifetime. Not sure why, I thought it was like a python variable
jmiehe has joined #yocto
<rfuentess>
qschulz: one question about their lifetime. What happens when a recipe start with `require <recipeA.bb>` I'm assuming that on those case we are sharing whatever was defined at receiptA
<qschulz>
rfuentess: I believe this creates two contexts
<qschulz>
depending on how the variables are set in recipeA you could potentially have different values for the same variable in recipeA and recipeB
<qschulz>
A simple example would be to save the current date inside a variable
<qschulz>
I believe recipeA and recipeB will have a different value because they are parsed at different times
<qschulz>
when you use includes/requires/inherits AFAIK the content of those files are included verbatim wherevever they are included
<qschulz>
called the "flattening" (maybe only in my head though, don't remember for sure)
<qschulz>
once it's flattened, it's parsed
<qschulz>
well more or less
<rburton>
rfuentess: require is just literal text inclusion.
<qschulz>
s/parsed/evluated/
<qschulz>
except for the := operator, which triggers an evaluation of the variable directly at parsing time
<rburton>
ie if foo.bb does require bar.bb, then PN is foo not bar.
<qschulz>
rburton: except if you set PN in recipeA?
<rburton>
yeah don't complicate things, i'm assuming default PN value
<rfuentess>
rburton: Ok, then it will be a huge recipe that will contain all the lines of receiptA and then those of the receipt calling it. Correct?
<rburton>
where the recipe says 'require', the parser just pulls in the file it specifies
<rburton>
its exactly like #include in C
<rfuentess>
rburton: thanks
<RP>
rburton: why doesn't our compiler work for R/M cores?
<khem>
gcc-runtime issues I guess, you need right libgcc and crt
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
leon-anavi has joined #yocto
kscherer has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<rburton>
RP: mainly as the TF-M code really assumes you're using the binary compiler and not doing so is hard word :). i've been meaning to do a multiconfig setup which sets up a machine with A and M cores, so the A is 64-bit linux and the M is 32-bit/newlib/tfm
leon-anavi has quit [Quit: Leaving]
<RP>
rburton, khem: multiconfig should handle the compiler libs I'd hope!
florian_kc has joined #yocto
hcg has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
prabhakarlad95 has quit [Quit: Client closed]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<rburton>
yeah, exactly
rfuentess has quit [Remote host closed the connection]
GNUmoon has quit [Read error: Connection reset by peer]
GNUmoon2 has joined #yocto
odra has joined #yocto
prabhakarlad has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 246 seconds]
alessioigor has quit [Quit: alessioigor]
goliath has quit [Quit: SIGSEGV]
mhaller has joined #yocto
<khem>
Right high time to have a template for such a setup in meta-arm IMO
manuel1985 has quit [Ping timeout: 264 seconds]
<rburton>
indeed
amitk has quit [Quit: leaving]
amitk has joined #yocto
amitk has quit [Ping timeout: 265 seconds]
dtometzki has quit [Ping timeout: 265 seconds]
zkrx has quit []
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
dtometzki has joined #yocto
mcfrisk has quit [Remote host closed the connection]
dtometzki has quit [Ping timeout: 265 seconds]
ecdhe has quit [Ping timeout: 268 seconds]
ecdhe has joined #yocto
odra_ has joined #yocto
goliath has joined #yocto
odra has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
kevinrowland has joined #yocto
vermaete has joined #yocto
zkrx has joined #yocto
<vermaete>
is LABELS_LIVE in poky/meta/classes-recipe/image-live.bbclass used.
<vermaete>
The labels itself, I can see in the GRUB booted from the USB stick. So: kind of "yes, they are".
<vermaete>
But the variable 'LABELS_LIVE' isn't used in any recipe.
dtometzki has joined #yocto
PhoenixMage has quit [Ping timeout: 264 seconds]
PhoenixMage has joined #yocto
vermaete has quit [Ping timeout: 252 seconds]
PhoenixMage has quit [Ping timeout: 265 seconds]
PhoenixMage has joined #yocto
<sotaoverride>
how can I figure out which package/recipe might provide libturbojpeg.so.0?
PhoenixMage has quit [Ping timeout: 265 seconds]
<sotaoverride>
or nevermind, found it
PhoenixMage has joined #yocto
sakoman has quit [Quit: Leaving.]
<kevinrowland>
I've seen some chatter about this on the mailing list but no good solution: I'm trying to build the eSDK and hitting "ERROR: Task pseudo-native.do_fetch attempted to execute unexpectedly". I took the hash for this task from locked-sigs.inc (from the eSDK build directory) and found a matching entry in the "main" sstate-cache/ directory, so this task
<kevinrowland>
should have been pulled from the cache. Is the do_fetch task not fetched during the setscene phase? Any pointers for debugging further?
<sotaoverride>
I cant figure out how to cater to this runtime dependency on - libcrypto.so.1.0.2(OPENSSL_1.0.2d)(64bit). I know for a fact I only have recipes for openssl_1.0.2u.bb and openssl_1.1.1q.bb
<sotaoverride>
a binary that I include in my iamge somhow figures out it needs libcrypto.so.1.0.2, and hints at OPENSSL_1.0.2d... I need help figuring this out
<sotaoverride>
guess adding RDEPENDS_${PN} += "libcrypto" takes care of it..
zkrx has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davidinux has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
zkrx has quit []
sakoman has joined #yocto
<sotaoverride>
ok, im just left with figuring out what package provides libopencv_imgcodecs.so. Please suggest a neat trick to figure this out..
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
<jsbronder>
sotaoverride: take a look at oe-pkgdata-util
<sotaoverride>
thanks jsbonder: should prolly make a sticky note for it since I tend to forget about it all the time
Tokamak has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
<rburton>
sotaoverride: are you packaging a prebuilt binary?
<sotaoverride>
rburton: yeah
<sotaoverride>
i figured what package libopencv_imacodes was in
<sotaoverride>
now im dealing with provides gstreamer1.0-plugins-bad-audiomixer
<sotaoverride>
rburton: yocto wasnt picking up all the shared libraries for the binary itself..
<sotaoverride>
but specifying some rdepends helped
<sotaoverride>
not sure if its ok to add stuff like RDEPENDS_${PN} += "glib-2.0"
<sotaoverride>
but it got this to build..
odra_ has quit [Ping timeout: 260 seconds]
<sotaoverride>
oh, and I see gstreamer1.0-plugins-base-audiomixer
<sotaoverride>
so I guess Ill just use that
zkrx has joined #yocto
sotaoverride has quit [Read error: Connection reset by peer]
sotaoverride has joined #yocto
mhaller has quit [Remote host closed the connection]
zkrx has quit [Ping timeout: 246 seconds]
<rburton>
sotaoverride: the easy way is to add those to DEPENDS and then bitbake will definitely be able to pick up the right rdepends
zkrx has joined #yocto
Vonter has quit [Ping timeout: 265 seconds]
adityapurohit has joined #yocto
<adityapurohit>
Hi folks, does anyone have experience using the repo:// fetcher in yocto? I see documentation in yocto saying its supported but not a lot of information on how it exactly works
kscherer has quit [Quit: Konversation terminated!]
<adityapurohit>
Couple of questions that I had: Do you need to have the repo tool included in HOSTTOOLS for the fetcher to work? How do I specify the protocol to be "git" as well as "ssh" ?
<rburton>
adityapurohit: use of repo: means it depends on repo-native automatically
<rburton>
and the protocol= parameter can be used to set the underlying protocol, defaults to git:
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
adityapurohit has quit [Quit: Client closed]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
adityapurohit has joined #yocto
adityapurohit has quit [Client Quit]
<mischief>
khem: "khem | mischief: RUSTFLAGS='-C target-feature=+crt-static'" yes, i tried that actually. but the result was not static. did you have success with it recently?
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
mvlad has quit [Remote host closed the connection]