vladest has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nothing has joined #yocto
goliath has joined #yocto
<nothing>
How can I check if a recipe can be buildable or not on musl systems?
<nothing>
They say that writing TCLIBC = "musl" in local.conf will be enough, but I get errors from poky's runqueue and process scripts.
sayo9394 has quit [Remote host closed the connection]
sayo9394 has joined #yocto
khem has quit []
khem has joined #yocto
vladest has joined #yocto
Daanct12 has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<nothing>
morning
rfuentess has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.1.1]
Kubu_work has joined #yocto
Daanct12 has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
Nonkel has joined #yocto
<Nonkel>
jclsn: After a long new build, i got the same error. Package 'systemd-journal-remote' has no installation candidate
florian_kc has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mvlad has joined #yocto
florian_kc has quit [Ping timeout: 258 seconds]
sayo9394 has quit [Remote host closed the connection]
sayo9394 has joined #yocto
alberto_pianon has joined #yocto
Guest97 has joined #yocto
Guest97 is now known as Rich_1234
leon-anavi has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
<alberto_pianon>
Hi, I'm trying to add sstate cache support to my unpack tracer bbclass, following the manual. Since I didn't need to have separate sstate-inputdirs and outputdirs, I tried to use sstate-plaindirs. The manual says
<alberto_pianon>
> In cases where sstate-inputdirs and sstate-outputdirs would be the same,
<alberto_pianon>
> you can use sstate-plaindirs. For example, to preserve the ${PKGD} and
<alberto_pianon>
> ${PKGDEST} output from the do_package task, use the following:
<alberto_pianon>
However I noticed that in this case sstate.bbclass always deletes and recreates sstate-plaindirs, also when the artifacts stored in those dirs are not cached yet. The results is that artifacts get deleted and sstate.bbclass caches an empty dir. It seems that the code that deletes artifacts is here:
<jclsn>
I add the public key to EXTRA_OEMAKE in the optee-os recipe and then sign the TAs using the offline method
<dvergatal>
ahhh when I was compiling op-tee by hand i just changed the
<dvergatal>
public_key.pem
<dvergatal>
and it was working
<jclsn>
Which path?
<jclsn>
There are like five copies of it
<dvergatal>
one sec i need to find it
<mcfrisk>
dvergatal: there may be multiple recipes which need to be adapted and compiled: optee-os, optee-os-tadevkit, optee-client, optee-test. I think some improvements to custom key handling could be done. Would be nice if you could contribute them..
<dvergatal>
mcfrisk: ah generally I need time for that but yeah I can do that
<mcfrisk>
dvergatal: a bbappend with custom key to optee-os recipe may not help with ta-devkit etc. upstream optee instructions are good and will work.
<dvergatal>
jclsn: when I was using op-tee 3.6.11
<jclsn>
dvergatal: Tried copying my key there, but it said "this key cannot be used for siging. please use offline signing of tas"
<dvergatal>
sorry 3.6.0 - 3.11.0
<dvergatal>
ok so it has probably changed from that time...
<jclsn>
I used the public key. Maybe it is the private key needed here. You still need to compile the public key into optee though
<dvergatal>
jclsn: but as I have written the link for you it must be the private key
<dvergatal>
it is even in the file
<dvergatal>
these header + footer RSA PRIVATE KEY
<jclsn>
Yeah the private key. I still need to sign the oemcrypto TA outside this recipe though.
<jclsn>
Well, I will try. What else can I do
<dvergatal>
jclsn: one sec
<dvergatal>
jclsn: ok I'm back what I wanted to propose you is to compile optee by hand and change that file but question is what arm board you are using because it also differs between tham how to load by hand this optee bin file
<jclsn>
imx8
<dvergatal>
aahhh nxp than
<jclsn>
The thing is: Everything is working well with the default keys. I can play DRM content and everything
<dvergatal>
yeah sure
<jclsn>
As soon as I compile in my set of keys, it doesn't work anymore and I am doing everything according to the guide. Why would this differ between different boards?
<dvergatal>
what I meant between different boards is that each arm producer has different sets of loading tee in tz
<dvergatal>
i was working with rockchip and believe me it really differs
<dvergatal>
ok let my find my manual for compilling optee by hand
frieder has joined #yocto
<jclsn>
They should all load the .ta files, shouldn
<jclsn>
they?
<dvergatal>
.ta are trusted applications
<dvergatal>
tee is trusted execution environment
<jclsn>
I was also wondering if you should be able to exchange the .ta files without having to recompile optee
<dvergatal>
which is in example optee-os
<jclsn>
Yeah, but there are three trusted applicaitons shipped with optee-os
<dvergatal>
jclsn: you need to recompile os when you change the key and re-sing .ta's
<jclsn>
Sure
<dvergatal>
just one sec i need my manual
<jclsn>
According to the guide you need to 1. Compile the public key into optee-os, 2. Sign the stripped.elf files using the private keys and stitch everything together as .ta
<dvergatal>
jclsn: maybe you can check in your recipe for optee what PLATFORM parameter is set to?
<jclsn>
imx8mq
radanter has quit [Remote host closed the connection]
<dvergatal>
ok so than grab optee-os from github
<dvergatal>
and compile it by hand with this command make CFG_ARM64_core=y CFG_TEE_BENCHMARK=n CFG_TEE_CORE_LOG_LEVEL=2 CROSS_COMPILE=aarch64-linux-gnu- CROSS_COMPILE_core=aarch64-linux-gnu- CROSS_COMPILE_ta_arm32=arm-linux-gnueabihf- CROSS_COMPILE_ta_arm64=aarch64-linux-gnu- O=out/arm PLATFORM=imx8mq
<jclsn>
I can't. We already have a lot of modifications in our branch
<jclsn>
I can try to compile that manually though
<dvergatal>
by modifications you mean in your branch you mean your own optee?
<dvergatal>
i'm sorry stupid keyboard...
<jclsn>
Yes, Linaro patched the shit out of it
<dvergatal>
ok so use your own branch
<dvergatal>
still with the same command
<dvergatal>
it should produce you tee.elf with signed *.ta's
<dvergatal>
with the private key I have already mentiond you need to change
<jclsn>
Will try thx
<nothing>
Do we need m5sum and sha256sum in the recipe at the same time? Isn't only one of them enough?
<JaMa>
nothing: only sha256sum is enough
<nothing>
JaMa why sha256sum, why not md5?
<nothing>
more secure than md5, Is that why?
<neverpanic>
MD5 collisions are cheap, and a recipe that only specifies MD5 could be used in a man-in-the-middle attack to make your build systems execute arbitrary code.
<KanjiMonster>
md5 is broken, and suspectible to collision attacks
<nothing>
One more question, I asked earlier but there was no one here because it was early.
<nothing>
How can I check if a recipe can be buildable or not on musl systems?
<nothing>
They say that writing TCLIBC = "musl" in local.conf will be enough, but I get errors from poky's runqueue and process scripts.
<rburton>
then its not buildable
<rburton>
everything in core is buildable with musl, or explicitly can't; be built. if you set TCLIBC=musl and bitbake yourrecipe and that breaks, you've found the problem
<nothing>
also get an error when I run different recipes. I think, I'm doing something wrong. I'll keep digging a little bit more.
<rburton>
what's the error?
<nothing>
why is pastebin banned in a country? let me install vpn :D
<Rich_1234>
easier than learning utf-8, just ban countries
frieder has quit [Ping timeout: 260 seconds]
<jclsn>
dvergatal: Ha, got it! Just exchanging the default_ta.pem worked. I think the problem was that I signed optee-os and oemcrypto in both recipes. Since oemcrypto pulls optee-os as dependency is should already have the correct private key
<dvergatal>
jclsn: your welcome
<nothing>
rburton added TCLIBC = "musl" to local.conf and tried to build recipe and got this error -> pastebin.com/t11ebwhn
<dvergatal>
jclsn: as I said that was all I was doing changing this file
sayo9394 has quit [Remote host closed the connection]
sayo9394 has joined #yocto
<rburton>
nothing: well that's unrelated to musl and will likely break if you remove it too. are you running git master or bitbake, or have you been editing bitbake?
Guest295 has joined #yocto
frieder has joined #yocto
<nothing>
rburton working on poky and oe master-next branch and i haven't edited anything.
starblue has quit [Ping timeout: 255 seconds]
<rburton>
well, using master-next might be your mistake
<rburton>
never use master-next, that's the staging area. you might have found a broken commit. use master if you need to stay on the bleeding edge.
<nothing>
rburton thanks
starblue has joined #yocto
<rburton>
RP: did you know "runqueue: Refactor StaleSetSceneTasks event out of build_scenequeue_data" is broken? see the pastebin by nothing above
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
<nothing>
There is a company that wants to do yocto related work. They are looking for people who can deal with the project. Is there a somewhere to advertise?
<ray-san>
hi guys, i try to build chromium with a amd graphics card into my yocto image, and when i try to start chromium, i get following warning: "failed to load driver: radeonsi". the amd/radeon stuff is enabled in my kernel config. can anybody help me out what i'm missing?
<fenrig>
which task in yocto is generating the manifest for the image? I couldnt find it with -c listtasks
<rburton>
ray-san: mesa drivers, probably
<rburton>
fenrig: the image task generates the manifest
<ray-san>
@rburton: i'm installing the mesa package actually, it is a dependency of chromium, but it seems like it gets built without radeon support
<rburton>
ray-san: it has a lot of packageconfigs to control what drivers get built
<ray-san>
i added following line to my local.conf: "PACKAGECONFIG_pn-mesa:append = 'radeonsi'", is that the right way to do it? sorry i'm relatively new to this yocto stuff :)
egueli-AV has joined #yocto
egueli-AV has quit [Remote host closed the connection]
<rburton>
yes but " radeonsi", you need leading whitespace
tgamblin has quit [Ping timeout: 240 seconds]
<ray-san>
seems like nothing gets rebuild if i do a "bitbake mesa"
egueli has joined #yocto
egueli-AV has joined #yocto
egueli has left #yocto [#yocto]
<rburton>
you probably meant PACKAGECONFIG:pn-mesa unless you're using an old release
<ray-san>
i try it, i'm on kirkstone
<ray-san>
"PACKAGECONFIG:pn-mesa = ' radeonsi'"
<ray-san>
this way?
frieder has quit [Ping timeout: 260 seconds]
<rburton>
PACKAGECONFIG:pn-mesa:append = "..."
<ray-san>
ah ok, got it
<rburton>
but looking at the recipe you want r600 not radeonsi
<ray-san>
sure? according to lspci my GPU is "VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge"
<ray-san>
and according to the log of chromium i am missing following file: /usr/lib/dri/radeonsi_dri.so
<rburton>
yes, because i'm reading the recipe
<ray-san>
ok
<rburton>
there is no "radeonsi" PACKAGECONFIG
<rburton>
but there is a r600 PACKAGECONFIG which enabled the radeonsi gallium driver
<ray-san>
ah ok....now i try to build the image, and i get an error, that for chromium there is stuff missing: "Nothing PROVIDES 'virtual/libgles2'"
<ray-san>
i guess the append doesn't really append, this libgles2 stuff seems also to be part of mesa
<rburton>
did you do " r600" with a space at the beginning?
<ray-san>
ok, now the rpm mesa-megadriver contains a file named "r600_dri.so" but still no "radeonsi_dri.so", which chromium complained :P
<jclsn>
dvergatal: Seems like the manually signed oemcrypto is the issue. Really weird
<rburton>
ray-san: all i can suggest is poking at the recipe. maybe there's an option missing.
<ray-san>
ok, thanks for your help
<jclsn>
I can sign the .ta files from optee-os offline as described in the documentation, but for oemcrypto it doesn't work.
xmn has joined #yocto
<dvergatal>
jclsn: never used oemcrypto
fenrig has quit [Ping timeout: 250 seconds]
Daanct12 has quit [Quit: WeeChat 4.1.1]
<jclsn>
Anyone else maybe?
Shaun has quit [Server closed connection]
Shaun has joined #yocto
RP has quit [Ping timeout: 246 seconds]
frieder has quit [Ping timeout: 255 seconds]
frieder has joined #yocto
<ray-san>
rburton: i appended also "PACKAGECONFIG:append:pn-mesa = ' gallium-llvm'" to my local.conf, and the missing file was built. thanks for your help, got a little bit smarter today :)
RP has joined #yocto
pretec has joined #yocto
frieder has quit [Ping timeout: 255 seconds]
ardo has quit [Server closed connection]
ardo has joined #yocto
sayo9394 has quit [Remote host closed the connection]
sayo9394 has joined #yocto
Xagen has joined #yocto
|Xagen has joined #yocto
frieder has joined #yocto
sakman has joined #yocto
Xagen has quit [Ping timeout: 260 seconds]
xmn has quit [Quit: ZZZzzz…]
sakman_ has joined #yocto
sakman has quit [Ping timeout: 260 seconds]
xmn has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has quit [Quit: SIGSEGV]
vladest has quit [Remote host closed the connection]
<ray-san>
nice, i finally rebuild most of the stuff and the chromium warning is gone
tortoise has quit [Server closed connection]
tortoise has joined #yocto
pretec has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
yudjinn has joined #yocto
<yudjinn>
hello, whats the best way to find what recipe is including another?
ray-san has quit [Remote host closed the connection]
<Rich_1234>
you can go to https://layers.openembedded.org and just look at the recipe and it will show the dependencies it has, but to go all the way down there is probably a log file or bitbake command for that
prabhakarlad has quit [Ping timeout: 250 seconds]
frieder has quit [Remote host closed the connection]
<yudjinn>
these are custom recipes, so not something available in the index. I want to find out what is requiring a specific package because I'd like to remove it
<yudjinn>
hm, that does look promising but I think Im hitting something weird. the dotfile I generate has things like gcc and boost in it, but `oe-depends-dot task-depends.dot -w -k gcc` or `boost` both return that the key doesnt exist; what defines these keys?
alessioigor has joined #yocto
<rburton>
oh the dotfile probably changed since then. try gcc:do_compile
<rburton>
the tool is dumb and looks for exact key names
<yudjinn>
lol `busybox.do_compile` is because of `do_install`... which keeps chaining lol
<yudjinn>
just oging to have to follow the chain up I suppose
<rburton>
it used to elide obvious changes, maybe something needs updating
<yudjinn>
oh, it doesnt even show why. just chains up to the `do_package_qa` then that next step shows that its just wanted by the core-image. but that image doesnt define it as a dependency
justache has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 255 seconds]
justache has joined #yocto
<pvogelaar>
Hi all,
<pvogelaar>
I am doing secure boot and signed firmware on my image, which works fine. The keys and certificates that are used for that are provided in a separate directory within the build directory (the init-build-env script pulls them from a server or generates them). However if I change the keys the recipes are not getting rebuild but they are used from the
<pvogelaar>
sstate cache. Is it possible to add dependencies to external files? Or what would be the proper way to do this? Handle the pulling and/or generation all in a recipe file?
<pvogelaar>
Hi all,
<pvogelaar>
I am doing secure boot and signed firmware on my image, which works fine. The keys and certificates that are used for that are provided in a separate directory within the build directory (the init-build-env script pulls them from a server or generates them). However if I change the keys the recipes are not getting rebuild but they are used from the
<pvogelaar>
sstate cache. Is it possible to add dependencies to external files? Or what would be the proper way to do this? Handle the pulling and/or generation all in a recipe file?
<pvogelaar>
Thanks for your help
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
Maxxed has joined #yocto
justache is now known as justThanks
Guest97 has joined #yocto
Guest97 is now known as Rich_1234
goliath has joined #yocto
jmd has joined #yocto
rfuentess has quit [Remote host closed the connection]
Minvera has joined #yocto
mckoan is now known as mckoan|away
ptsneves has quit [Ping timeout: 255 seconds]
sakman_ is now known as sakman
amitk has joined #yocto
<rburton>
pvogelaar: "fetching and tracking changes to external files" is exactly what SRC_URI is for
<rburton>
i'd use that instead of custom stuff in your init-build-env script
<rburton>
and meta-arm 4.3 is released, thanks jonmason
<rburton>
🎉
ferry has joined #yocto
ferry has quit [Client Quit]
<nothing>
rburton jonmason congrats 🎉
<pvogelaar>
thanks rburton
geoffhp has joined #yocto
yudjinn has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
dash_hope has joined #yocto
alessioigor has quit [Quit: alessioigor]
sayo9394 has quit [Remote host closed the connection]
alessioigor has joined #yocto
sayo9394 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
dash_hope has quit [Quit: Client closed]
Haxxa has joined #yocto
jmd has quit [Remote host closed the connection]
<nothing>
good night everyone!
nothing has quit [Quit: Client closed]
florian_kc has joined #yocto
ptsneves has joined #yocto
Nonkel has quit [Ping timeout: 250 seconds]
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
jmd has joined #yocto
prabhakarlad has joined #yocto
rcw has joined #yocto
jmd has quit [Remote host closed the connection]
Nonkel has joined #yocto
prabhakarlad has quit [Quit: Client closed]
jmd has joined #yocto
flom84 has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
goliath has joined #yocto
jmd has quit [Remote host closed the connection]
Nonkel has quit [Ping timeout: 250 seconds]
davidinux has quit [Quit: WeeChat 3.5]
davidinux has joined #yocto
sayo9394 has quit [Remote host closed the connection]
sayo9394 has joined #yocto
<jclsn>
khem: Any news about the btop merge? I also couldn't boot the image on the Pi Zero using musl unfortunately
egueli-AV has quit [Read error: Connection reset by peer]
egueli-AV has joined #yocto
yudjinn has joined #yocto
alessioigor has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 252 seconds]
mvlad has quit [Remote host closed the connection]
flom84 has quit [Ping timeout: 255 seconds]
ptsneves has quit [Quit: ptsneves]
rsalveti has quit [Quit: Connection closed for inactivity]
<khem>
jclsn: I am expecting you to address the review comments and send v2
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
Vonter has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #yocto
Vonter has joined #yocto
sayo9394_ has joined #yocto
sakman has quit [Ping timeout: 255 seconds]
sayo9394 has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
Minvera has quit [Read error: Connection reset by peer]