<eduter16>
Hello. I am stuck when running my Yocto build using poky distro and targeting a phytec machine.
<eduter16>
The parsing error stated below claims the tee-supplicant.sh file cannot be found... however when I looked into my "sources" directory (where I checked out all the repos specified in my manifest), I can see that tee-suplicant.sh is there... even more confusing... in the error message under "The following paths were searched:", the path containing
<eduter16>
the tee-supplicant.sh was searched into!
<eduter16>
The recipe optee-client_4.4.0.bb is being referenced from within "meta-phytec" dynamic layers.
<eduter16>
Parsing recipes...ERROR: /build/yocto/sources/poky/../meta-phytec/dynamic-layers/meta-arm/recipes-security/optee/optee-client_4.4.0.bb: Unable to get checksum for optee-client SRC_URI entry tee-supplicant.sh: file could not be found
<eduter16>
The following paths were searched:
<eduter16>
....
<eduter16>
PATH to the actual tee-supplicant.sh shell script in my yocto built sytem: ~/projects/sources/meta-arm/meta-arm/recipes-security/optee/optee-client/tee-supplicant.sh
<rburton>
eduter16: looks like your using meta-arm master? is that intentional?
<rburton>
(will go and see why that break)
<eduter16>
rburton I am referencing the latest commit revision under scarthgap branch in my manifest:
<eduter16>
rburton Not a yocto expert... not completely sure about the dynamic-layer (I need to do some reading on that I know xD), but yes you are correct, meta-phytec is the vendor of my hardware... and the optee-client recipe is referenced from there... In my manifest I am using tag revision "refs/tags/BSP-Yocto-NXP-i.MX8MM-PD25.1.0" for meta-phytec... it
<eduter16>
is the latest I assumed in sync with "scarthgap"... maybe I am wrong...
<rburton>
eduter16: meta-arm doesn't have optee 4.4 yet (patches on the list, so will be there today) but the path clearly says meta-arm so you'll need to figure out what's going on. if it comes from meta-phytec then contact their support to report the bug.
<eduter16>
rburton got you. Thanks a lot. I may fetch an older version of meta-phytec which does not require optee 4.4. Nevertheless, thanks for letting me know that meta-arm may get optee 4.4 soon.
<eduter16>
rburton as always thanks for the time.
<eduter16>
rburton by the way... sorry for not seeing this... I thought meta-arm is including "optee 4.4", because I saw it includes: "optee-os_4.%".... this name does not match even optee-client name... but I saw the percentatge and just assumed it applied to any 4.x version... i will read very very carefully the error messages next time.
<eduter16>
rburton still newbie...
<eduter16>
rburton maybe a dummy question... is there a public url link for me to be able to follow on which patches are waiting "to-be-merged" into meta-arm repo, for example?
<eduter16>
mcfrisk thanks for the info mcfrisk (y)
eduter16 has quit [Quit: Client closed]
eduter16 has joined #yocto
<kanavin>
I find it peculiar how many people aren't willing to disclose their identity, and make anonymous email accounts specifically for the purpose of asking yocto questions
<kanavin>
just answered two such emails in a row on yocto list
<kanavin>
as if saying who they are would be a liability, which is kinda sad
<kanavin>
'my next employer will do a google search on me, so I better sanitize my online activity'
Zosma has quit [Ping timeout: 260 seconds]
<eduter16>
kanavin I am more than happy to state my name and ask a question about Yocto, the worst can happen is I make a fool of myself... regardless of my experience with Yocto. I am definetely not ready to make contributions, but I would like to one day. I do no see why stating my name can go against me... should not be the opposite? Showing will to learn
<eduter16>
and be active in the yocto community should be perceived positively is not it?
<eduter16>
kanavin I know you are just speaking in general :-) I never sent you an email, I was just sharing my opinion :-)
<kanavin>
eduter16, this was about mailing lists. IRC etiquette is different.
<kanavin>
but in general, I like to know who am I talking to.
<eduter16>
kanavin probably another naive question from my side... why should be different between mailing lists and IRC?
<eduter16>
kanavin I have not done it yet but I will at some point subscribe to some mailing lists... to try to stay aware of what is going on.
<kanavin>
eduter16, IRC identities evolved differently than email identities. Email has been for a long time tied to real names, e.g. if you are using a university or company account.
<eduter16>
kanavin ok (y)
<kanavin>
IRC is coming from various prior chat facilities that use unix usernames, and the tradition is that people are free to choose them and be creative.
<kanavin>
I am not creative at all :D
enok has quit [Quit: enok]
<eduter16>
kanavin it is nice having the freedom to join in a chat without being forced to register or giving too much personal info. Not very creative either I am using my name and surname hehe
<eduter16>
@kanaving
enok has joined #yocto
<eduter16>
kanavin regardless of that freedom... I personally prefer not been anonymous hehe
<kanavin>
eduter16, the discussion about anonymity vs identity checks on the internet is never ending, and broad. There are significant pluses and minuses to both, sometimes it's a matter of life and death.
<kanavin>
it's just that I personally like to know who am I talking to, why are they involved in yocto, what their company does, etc. Instead of just a disposable nickname.
Guest28 has joined #yocto
<eduter16>
kanavin I see your point.. I was working once for a company where we could not see the product in a production environment... and in the long term it is a bit sad not being able to see the stuff working in real application scenarios.
mckoan|away is now known as mckoan
<eduter16>
kanavin me I am working with controllers for refrigerators, and being the new guy having to maintain and evolve the current yocto build system
<Guest28>
hello, is this a good place to ask for advice for Yocto 5.0 to 5.1 migration issues? E.g. I've checked the release notes and I would like to see some examples. Thank you in advance :]
<kanavin>
Guest28, it's a good place if you have specific questions or issues.
<kanavin>
asking for a tailor-made tutorial is probably not as good an idea
<Guest28>
thank you, kanavin. Yes. I have kernel patches, based on SRC_URI += "...", and then references to ${S} and ${WORKDIR}, and now many things are broken
<Guest28>
I tried the:
<Guest28>
S = "${WORKDIR}/sources"
<Guest28>
UNPACKDIR = "${S}"
<Guest28>
suggestion, but still, a mess
<kanavin>
Guest28, it's hard to give help without seeing the recipe and the failure, exactly
<kanavin>
and I mean the original failure prior to any guess-tweaks
<Guest28>
e.g.
<Guest28>
ERROR: linux-imx-6.12.3+git-r0 do_kernel_metadata: A KBUILD_DEFCONFIG 'imx_v8_defconfig' was specified, but not present in the source tree (/home/adv/adv-release-bsp/tmp/yocto/build_imx-linux-styhead-adv-dev_rom5722-db2510_6G/tmp/work/rom5722_db2510-poky-linux/linux-imx/6.12.3+git/sources/arch/arm64/configs/)
<Guest28>
ERROR: linux-imx-6.12.3+git-r0 do_kernel_metadata: Execution of '/home/adv/adv-release-bsp/tmp/yocto/build_imx-linux-styhead-adv-dev_rom5722-db2510_6G/tmp/work/rom5722_db2510-poky-linux/linux-imx/6.12.3+git/temp/run.do_kernel_metadata.45852' failed with exit code 1
<Guest28>
ERROR: Logfile of failure stored in: /home/adv/adv-release-bsp/tmp/yocto/build_imx-linux-styhead-adv-dev_rom5722-db2510_6G/tmp/work/rom5722_db2510-poky-linux/linux-imx/6.12.3+git/temp/log.do_kernel_metadata.45852
<Guest28>
ERROR: Task (/home/adv/adv-release-bsp/tmp/yocto/sources/meta-imx/meta-imx-bsp/recipes-kernel/linux/linux-imx_6.12.bb:do_kernel_metadata) failed with exit code '1'
enok has quit [Quit: enok]
enok71 has joined #yocto
<kanavin>
that is not related to UNPACKDIR
enok71 has quit [Client Quit]
enok has joined #yocto
<Guest28>
yes, correct. Once fixed the unpackdir, that's another issue, I was not sure if was related to that or not
<Guest28>
it is like the 'sources' is missing
<kanavin>
Guest28, it helps to have a working build in a different directory so that you have a working reference point you can look into
<Guest28>
thank you, I'll try that
<kanavin>
e.g. presumably in your previous build the error did not occur, which means the file which is now absent was not absent
<kanavin>
then you can start asking questions: at which point in commit history it disappeared and why
<Guest28>
thanks
<kanavin>
or, where exactly using that file is being prescribed and why
<kanavin>
etc.
goliath has joined #yocto
raghavgururajan has quit [Remote host closed the connection]
sfo has quit [Remote host closed the connection]
tostr has quit [Remote host closed the connection]
tleb has quit [Remote host closed the connection]
jonesv has quit [Remote host closed the connection]
enok has quit [Ping timeout: 260 seconds]
tostr has joined #yocto
sfo has joined #yocto
tleb has joined #yocto
raghavgururajan has joined #yocto
jonesv has joined #yocto
ablu has quit [Ping timeout: 245 seconds]
ablu has joined #yocto
starblue has quit [Quit: WeeChat 3.8]
DvorkinDmitry has joined #yocto
<DvorkinDmitry>
trying DKMS inside the yocto board, getting a lot of: "Error: selected processor does not support `dmb ish' in Thumb mode". make modules_prepare is done previously. What may be wrong?
bhstalel has joined #yocto
<bhstalel>
Anyone worked with SELinux without coreutils ? it heavily depend on it and I don't want GPLv3 packages in my image.
Daanct12 has quit [Ping timeout: 252 seconds]
bradfa_ has joined #yocto
salahaldeen__ has joined #yocto
OnkelUll_ has joined #yocto
mario-goulart has joined #yocto
philipl_ has joined #yocto
philipl_ has joined #yocto
philipl_ has quit [Remote host closed the connection]
mario-goulart has quit [Remote host closed the connection]
<khem>
I could see that | make[1]: *** [Makefile:868: installed-modules.scm] Segmentation fault (core dumped)
<gmorell>
or upset
<gmorell>
at life
<khem>
was coming from uim-module-manager which was built by uim-native
<RP>
khem: host os dependent maybe?
<rburton>
bhstalel: well if you find that coreutils isn't actually needed and busybox's versions are featureful enough then you can send patches to remove the deps. of course its quite possible that the deps are actually needed and busybox doesn't work.
<bhstalel>
rburton If coreutils is required, then how can I use selinux with a GPLv3-free distro ?
<rburton>
bhstalel: as above, there's an all-new reimplementation of coreutils in rust which is MIT. you could try that.
leon-anavi has quit [Quit: Leaving]
<rburton>
you're fighting the intended behaviour, of course. if selinux depends on coreutils that is gpl3 then that's how it is.
<rburton>
alternatives would be change the tools to not need coreutils, or add the missing features to busybox.
<khem>
RP:yeah and then it was being reused from sstate on subsequent builds which all failed and then got rebuilt on a different host and now it works - such problems are rare but they do happen
<khem>
uutils is almost compatible with coreutils I think some 95% tests pass, but its the 5% that will sink your boat
<bhstalel>
rburton I am going to check what utilities selinux needs and enable them from other sources
nzingile has joined #yocto
<khem>
canonical's effort will make things better certainly, even if they restract it from next LTS in 2026.04
<bhstalel>
I will start with analyzing what coreutils tools selinux needs, and search for them in "busybox" or any other non-gpl3 alternative, I hope I find them all.
<khem>
yeah its certainly doable, just know that it will need some work
<mischief>
has anyone tried to build rpi pico/rp2350 firmware within yocto?
<khem>
mischief:interesting, I have not done pico specifically, but we do have baremetal SDKs capability with a little effort we can
<khem>
in MCU world though, SDK+OS is one package and users add apps on top and make it all using SDK so it might be the known model which attracts the pico-sdk approach
<khem>
I think yocto will provide for the processes they will need to ship the product but then they cook their own
jero- has quit [Ping timeout: 246 seconds]
<mischief>
right, so we have a recipe using this pico-sdk thingy which produces /lib/firmware/pico.fw etc, loaded at runtime
prabhakalad has quit [Remote host closed the connection]
prabhakalad has joined #yocto
<khem>
mischief:some layers e.g. meta-freescale build freertos like an app using a recipe now that may not be how freertos developer might want to do things but product release folks will like that
<mischief>
khem: does that layer use multilib or otherwise build its own compiler? or use some binary toolchain?
eduter16 has joined #yocto
druppy has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
nzingile has quit [Ping timeout: 244 seconds]
nzingile has joined #yocto
OnkelUll_ is now known as OnkelUlla
<tgamblin>
Who manages the Yocto pretalx website? avocadosand or maybe Crofton?
<Crofton>
Um For the latest thing? I may have privs
<Crofton>
mostl LetoThe2nd
<Crofton>
but what do you need?
<tgamblin>
Crofton: will DM
<Crofton>
All fixed!
druppy has quit [Quit: druppy]
druppy has joined #yocto
jmiehe has joined #yocto
jsbronder has quit [Quit: WeeChat 4.1.2]
florian has quit [Killed (NickServ (GHOST command used by florian_kc!~florian@2a02:3100:42f5:c100:16f3:6b79:a269:8aa8))]
florian_kc is now known as florian
florian_kc has joined #yocto
bhstalel has quit [Ping timeout: 240 seconds]
jsbronder has joined #yocto
<khem>
mischief: IIRC it uses a precompiled baremetal toolchain
<khem>
it would have been possible to use the standard yocto toolchain with -ffreestanding option but maybe no one tried that
<DvorkinDmitry>
trying DKMS inside the yocto board, getting a lot of: "Error: selected processor does not support `dmb ish' in Thumb mode". make modules_prepare is done previously. What may be wrong?
jero- has quit [Remote host closed the connection]
jero- has joined #yocto
<eduter16>
Hi kanavin I hope you do not mind me to address you again. If you think that is not ok I will then text you in the open chat.
<eduter16>
It is about the issue from meta-phytec... I have been researching more and it seems like there is another issue (which was not a problem for kirkstone):
<eduter16>
Parsing recipes...ERROR: /build/yocto/sources/meta-phytec/dynamic-layers/fsl-bsp-release/recipes-bsp/imx-mkimage/imx-boot-phytec_1.0.bb: Unable to get checksum for imx-boot-phytec SRC_URI entry 0001-iMX8M-soc.mak-use-native-mkimage-from-sysroot.patch: file could not be found
<eduter16>
I found out that "meta-imx" is renamed to "fsl-bsp-release" due to legacy purposes (BBCOLLECTIONS in the layer.conf). And I can see that the 0001-iMX8M-soc.mak-use-native-mkimage-from-sysroot.patch exists under "sources/meta-imx/meta-imx-bsp/recipes-bsp/imx-mkimage/files/0001-iMX8M-soc.mak-use-native-mkimage-from-sysroot.patch" in my yocto build...
<eduter16>
why it cannot then find it??
jmiehe has quit [Quit: jmiehe]
<eduter16>
why I get this issue for scarthgap?
<eduter16>
I think the imx-boot-phytec_1.0.bb recipe is legit... that is why it is included under the dynamic-layers directory for "meta-phytec" layer. Am i badly wrong here?
Guest62 has joined #yocto
<Guest62>
Does anyone here have experience creating a simple .bb file that needs to decompress two local files (.tgz) and place them in the appropriate place in the filesystem? My initial attempt based on examples is close, but not quite working as expected.
cyxae has quit [Quit: cyxae]
enok71 has joined #yocto
enok has quit [Ping timeout: 260 seconds]
enok71 is now known as enok
<rburton>
Guest62: pastebin what you have and someone can help. it should just mostly be SRC_URI of the two tarballs, then a do_install to move the files.
Xogium has quit [Remote host closed the connection]
Xogium has joined #yocto
jero- has quit [Ping timeout: 268 seconds]
Guest67 has joined #yocto
<Guest67>
I'd like to trigger bitbake builds from local CI (gitea, which is modeled after github)
<Guest67>
I'm testing little builds and noticed the behavior of "actions" checkoutv4 is to clone the repo from scratch.
florian has quit [Ping timeout: 265 seconds]
Habbie has quit [Ping timeout: 248 seconds]
<Guest67>
I'd prefer the build server to keep its state between builds and only "git pull" the latest updates to the branch before kicking off bitbake -- much like my own local workflow.
<Guest67>
I'm looking at github actions and don't see a way to make it persist build state between builds (which is, admittedly normally not wanted.)
<Guest67>
afk but lurking
Guest67 has quit [Quit: Client closed]
druppy has quit [Ping timeout: 268 seconds]
Guest57 has joined #yocto
nzingile has quit [Ping timeout: 244 seconds]
RP has quit [Quit: Exiting]
RP has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
Guest62 has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
Guest57 has quit [Ping timeout: 240 seconds]
Net147 has quit [Ping timeout: 244 seconds]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
jero has joined #yocto
<khem>
ah Guest67 left, he could have used yoe GH action yaml files