<tomzy_0[m]>
<ecdhe> "Are sumo-era builds not supporte..." <- I think you can go back and use kas-docker (now known as kas-container, but older release) if this is an option for you, e.g. v 2.0 https://github.com/siemens/kas/blob/2.0/kas-docker or older
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 264 seconds]
alessioigor has joined #yocto
Thorn has quit [Ping timeout: 240 seconds]
rob_w has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest98 has joined #yocto
PobodysNerfect has joined #yocto
PobodysNerfect has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
davidinux has joined #yocto
pbergin has quit [Ping timeout: 246 seconds]
frieder has joined #yocto
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
rfuentess has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<Guest98>
morning
PobodysNerfect has joined #yocto
Thorn has joined #yocto
<Guest98>
Hi everyone, i have a question mark in my mind about 2 topic. First one about combining the 2 different Yocto Project to under a single project. Second one, how a recipe is designed in a project with more than 1 machine.
<Guest98>
Let's say i have 2 machines. One of them is RPI4 and the other is Coral Dev Board. I have Yocto build, which is in separate repos for these.
<Guest98>
The meta-layers I use:
<Guest98>
RPi4: "meta-raspberrypi", "meta-openembedded", "poky", "meta-mylayer" are all dunfell version.
<Guest98>
Coral Dev Board : "meta-freescale", "meta-freescale-3rdparty", "meta-freescale-distro", "meta-openembedded", "poky", "meta-mylayer" are all zeus version.
<Guest98>
1) If I want to combine them in one project, how should i do this? Does it make sense to combine two different versions into one project?
<Guest98>
2) Let's say i have a recipe called "test.bb" and it contains separate configurations for both IMX(Coral Dev Board) and RPI4. Is it more logical to separating it as "test_imx.bb" and "test_rpi.bb" or is it reasonable to set up a structure like the one below in "test.bb"? The SRC, do_configure, do_install, do_compile functions used by RPI and IMX
<Guest98>
are different.
<Guest98>
if(machine==RPI4)
<Guest98>
{
<Guest98>
do_configure()
<Guest98>
do_compile()
<Guest98>
do_install()
<Guest98>
}
<Guest98>
else if(machine==CoralDevBoard)
<Guest98>
{
<Guest98>
do_configure()
<Guest98>
do_compile()
leon-anavi has joined #yocto
<mckoan>
Guest98: please DO NOT post code here, use pastebin
<mckoan>
Guest98: the term project is misleading in this case. What does it mean?
<mckoan>
Guest98: a reposhould be associated to a meta layer, not to a 'project'
<mckoan>
Guest98: however I'd keep the two Yocto directories separate, one for RPI and one for Coral-IMX
<mckoan>
Guest98: about the recipe, the answer is the usual: depends :-D
<mckoan>
Guest98: if is a BSP related recipe I'd keep it different as "test_imx.bb" and "test_rpi.bb", if is software and something shareable I'd put everything in a singe one if it makes sense
<frosteyes1>
Guest98: Your should properly target something like 3 layers. A pure software / distro layer. A custom BSP layer for your RPi machine and a Custom BSP layer for your Coral Dev board.
<frosteyes1>
Your custom RPi4 bsp layer depend on meta-raspberrypi, and your Custom Coral BSP layer, depend on meta-freescale, etc...
<frosteyes1>
And your bsp layers should be able to work with core-image-minimal etc. So they don't depend on your meta-mylayer, but is allowed to have bbappend in a dynamic layer..
Guest98 has quit [Quit: Client closed]
alejandr1 has quit [Read error: Connection reset by peer]
<mcfrisk>
Has anyone else seen issues with tar and pigz in latest master branch? On aarch64 I'm sometimes seeing corrupt tar files after pigz compression
Guest98 has joined #yocto
alejandr1 has joined #yocto
<LetoThe2nd>
yo dudX
<mckoan>
LetoThe2nd: hey
<RP>
mcfrisk: not on the autobuilder
<mcfrisk>
RP: good to know. I'm seeing issues on target when creating large tar files to tmpfs and then extracting fails with "crc32 mismatch". I don't see any changes to pigz, zlib, glibc, or even gcc between poky a94ca827c2066b22c and 2942c7f2c16e5b. There are kernel changes and issue is only seen on some boards, sigh.
gsalazar has joined #yocto
Guest98 has quit [Quit: Client closed]
<RP>
mcfrisk: the last time I saw something like that it was a bug in the minicache handling in the kernel on a pxa processor :(
<mcfrisk>
RP: yea, could be something similar this time too. I suspect the kernel update from 6.1.20 to 6.1.25. I'll try to bisect..
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
bps has joined #yocto
bps has joined #yocto
camus1 is now known as camus
Thorn has quit [Ping timeout: 240 seconds]
PobodysNerfect_ has joined #yocto
PobodysNerfect has quit [Ping timeout: 268 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
pbergin has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
Guest98 has joined #yocto
camus has quit [Quit: camus]
camus has joined #yocto
camus has quit [Client Quit]
camus has joined #yocto
camus has quit [Client Quit]
camus has joined #yocto
davidinux has joined #yocto
Thorn has joined #yocto
florian has joined #yocto
<rburton>
khem: thanks for the cpio patch :) hooray timezones, i can moan about something and then stop working, come back and a patch is merged :)
ptsneves has joined #yocto
shoragan has quit [Remote host closed the connection]
shoragan has joined #yocto
<LetoThe2nd>
rburton: I thought you we busy doing dog walking to your new fav cafe anyways?
<rburton>
how do you know i'm not there now?
<rburton>
(i'm not, but it's a good day for it)
<LetoThe2nd>
rburton: as a general rule, I don't know anything.
<Guest98>
Hi everyone, I asked a question today. After asking, my internet connection was gone and i dropped from the chat. I didn't see the replies. I'm asking the question again, sorry.
<Guest98>
I have a question mark in my mind about 2 topic. First one about combining the 2 different Yocto Project to under a single project. Second one, how a recipe is designed in a project with more than 1 machine.
<Guest98>
Let's say i have 2 machines. One of them is RPI4 and the other is Coral Dev Board. I have Yocto build, which is in separate repos for these.
<Guest98>
The meta-layers I use:
<Guest98>
RPI4: "meta-raspberrypi", "meta-openembedded", "poky", "meta-mylayer"(Common with CoralDevBoard) are all dunfell version.
<Guest98>
Coral Dev Board : "meta-freescale", "meta-freescale-3rdparty", "meta-freescale-distro", "meta-openembedded", "poky", "meta-mylayer"(Common with RPI4) are all zeus version.
<Guest98>
1) If I want to combine them in one project, how should i do this? Does it make sense to combine two different versions into one project?
<Guest98>
2) Let's say i have a recipe called "test.bb" and it contains separate configurations for both IMX(Coral Dev Board) and RPI4. Is it more logical to separating it as "test_imx.bb" and "test_rpi.bb" or is it reasonable to set up a structure like the one below in "test.bb"? The SRC, do_configure, do_install, do_compile functions used by RPI and IMX
<Guest98>
are different.
<Guest98>
pastebin.com/Ytj5mk7w
<Guest98>
If i try to build "test.bb" for two 2 machines, what type of problem can i encounter? For example, what happens if one more machine is added?
<rburton>
if you want a recipe to be machine-specific that's fine (the kernel is, for example), just set PACKAGE_ARCH.
<rburton>
its your choice how to structure this really. if the recipes are 99% identical but ship slightly different files then you can set PACKAGE_ARCH and have a single recipe
<rburton>
if the machine differences are so vast that you're reimplementing do_compile then write two recipes (foo-rpi, foo-coral, etc), set them as compatible with the specific machine, have them RPROVIDE a name like foo, and then you can just say IMAGE_INSTALL+=foo and everything just works
<LetoThe2nd>
or have your configuration mechanism accept a target platform, which you can just pass in as EXTRA_OECONF:append = " --machine=${MACHINE" for example
<LetoThe2nd>
(add the missing "}" please)
florian_kc has joined #yocto
d-s-e has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
transrights[m] has left #yocto [#yocto]
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
<Guest98>
rburton LetoThe2nd Thank you. How can i combine 2 different version Yocto projects? I wrote the layers included in the projects above. Can you give any ideas or suggestions regarding this?
<LetoThe2nd>
Guest98: you need to be much more precise as of what a "version" means for you.
<Guest98>
im talking about yocto project releases version. i use zeus for imx, dunfell for rpi. i want to combine them.
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
<Guest98>
LetoThe2nd If you answered my question, i didn't see it. I dropped from chat again. I don't understand why this happens.
<LetoThe2nd>
Guest98: ah. that is usually not directly possible, it means having two separate branches.
kscherer has joined #yocto
Minvera has joined #yocto
Guest98 has quit [Client Quit]
<tomzy_0[m]>
Guest98: I would say it is rather not possible but definitely not recommended. You would end with e.g. 2 versions of the same recipe so probably any bbappends would not apply. I would suggest to keep them separate.
<tomzy_0[m]>
But also interested what LetoThe2nd got to say
<LetoThe2nd>
tomzy_0[m]: in a real life situation you will just end up with so many parse errors that it is factually not possible, except for trivial projects
<LetoThe2nd>
thats at least my experience, and its definitely not recommended.
<tomzy_0[m]>
yeap, so two separate projects
Guest98 has joined #yocto
<LetoThe2nd>
you'll usually have two branches. or better, bump the zeus one to dunfell.
suwako[m] has left #yocto [#yocto]
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
<Guest98>
LetoThe2nd thank you.
<LetoThe2nd>
Guest98: have fun!
florian_kc has quit [Ping timeout: 246 seconds]
Thorn has quit [Quit: Easy as 3.14159265358979323846...]
<d-s-e>
Is there a non-GPLv3 alternative to stdbuf from coreutils available?
embetrix has joined #yocto
<embetrix>
Hi, does yocto support builds for cortex-M7 ? I enabled in my machine conf : require conf/machine/include/arm/armv7m/tune-cortexm7.inc and set TCLIBC = "musl" but the build breaks for several components : libffi & openssl
mckoan is now known as mckoan|away
<LetoThe2nd>
embetrix: it is not an officially tested and supported target.
<rburton>
embetrix: did you see my reply to your mail?
<embetrix>
rburton no I didn't get any mail
<rburton>
are you ayoub.zaki@googlemail.com or is that just a huge coincidence
<embetrix>
/home/zaki/Projects/meta-stm32f7x/build/tmp/work/stm32f769_disco-poky-linux-musleabi/stm32f7x-initramfs-image/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version install busybox' returned 1:
<embetrix>
* Solver encountered 1 problem(s):
<embetrix>
* Problem 1/1:
<embetrix>
* - conflicting requests
<embetrix>
* - nothing provides update-alternatives-opkg needed by busybox-1.35.0-r0.cortexm7
<embetrix>
*
<embetrix>
* Solution 1:
<embetrix>
* - do not ask to install a package providing busybox
<embetrix>
* opkg_finalize_intercepts: Failed to open dir /home/zaki/Projects/meta-stm32f7x/build/tmp/work/stm32f769_disco-poky-linux-musleabi/stm32f7x-initramfs-image/1.0-r0/temp/ipktemp//opkg-CGAv04/opkg-intercept-rSF6KM: No such file or directory.
<embetrix>
* rm_r: Failed to open dir /home/zaki/Projects/meta-stm32f7x/build/tmp/work/stm32f769_disco-poky-linux-musleabi/stm32f7x-initramfs-image/1.0-r0/temp/ipktemp//opkg-CGAv04/opkg-intercept-rSF6KM: No such file or directory.
<embetrix>
* rm_r: Failed to open dir /home/zaki/Projects/meta-stm32f7x/build/tmp/work/stm32f769_disco-poky-linux-musleabi/stm32f7x-initramfs-image/1.0-r0/temp/ipktemp//opkg-CGAv04: No such file or directory.
<embetrix>
ERROR: Logfile of failure stored in: /home/zaki/Projects/meta-stm32f7x/build/tmp/work/stm32f769_disco-poky-linux-musleabi/stm32f7x-initramfs-image/1.0-r0/temp/log.do_rootfs.2128536
<embetrix>
ERROR: Task (/home/zaki/Projects/meta-stm32f7x/build/../recipes-core/images/stm32f7x-initramfs-image.bb:do_rootfs) failed with exit code '1'
<embetrix>
NOTE: Tasks Summary: Attempted 1178 tasks of which 1168 didn't need to be rerun and 1 failed.
rob_w has quit [Quit: Leaving]
<rburton>
oh right it depends on it to ensure its built for image time
<rburton>
but that's workaroundable
<rburton>
ok revert that
<rburton>
what branch are you using? the packageconfig on opkg-utils should have nuked the python dependencies
ptsneves has quit [Ping timeout: 264 seconds]
<embetrix>
kirkstone
<rburton>
brute force: remove python from PACKAGECONFIG = "python update-alternatives" in opkg-utils_0.5.0.bb
<embetrix>
Thanks that did it :-)
prabhakarlad has quit [Quit: Client closed]
<embetrix>
I will create a bbappend for that in my layer
<embetrix>
rburton : thanks for your support
thomasd13 has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
bps has quit [Ping timeout: 256 seconds]
embetrix has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
<dv_>
suppose that there's something wrong in a BSP layer, a regression that causes serious performance problems, and some git commit introduced this (that is, an older version had no such problems). the logical choice is to use git bisect to pinpoint what exact commit in the BSP layer caused the regression.
<dv_>
however, during bisect, the git head might go back. this can then lead to errors because bitbake sees that the versions of some recipes were reverted to older ones.
zpfvo has quit [Quit: Leaving.]
<dv_>
are there suggestions, best practices etc. for how to do a bisect in OE layers?
<dv_>
other than to wipe the entire build directory
<yocton>
At minimum you can disable the QA error about the version going backward
<dv_>
but if a version goes backwards, can this cause problems in the sstate cache for example? some stale states etc.?
<yocton>
Each version has a different sstate cache element
embetrix has joined #yocto
embetrix has quit [Client Quit]
<yocton>
I used to have a project with a recipe going forward and back for some reason. Never had a problem with sstate (it even help by speeding up build in both old/new version)
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
ptsneves has joined #yocto
ptsneves has quit [Ping timeout: 246 seconds]
<rburton>
dv_: disable the version check as yocton said, but otherwise you can reuse a build tree, definitely reuse sstate
<rburton>
i've often done bisects on builds with git, just let bitbake clean up tmp as it needs to
<dv_>
would `ERROR_QA:remove = "version-going-backwards"` in `local.conf` do it?
<rburton>
yes
<rburton>
also you need to run the bisect at the top of the git tree you're bisecting, but once you've init'd the build tree with recent releases you can cd anywhere and bitbake knows where the build is
<yolo>
is there a 'global' repo or some index that I can search all possible recipes, for example I am looking for possible klib recipe before I write one from scratch, but could not find it: https://github.com/attractivechaos/klib
<wkawka>
Hi, can I add somehow do_install:append only to specific package?
<wkawka>
I have included php in my imafe and i want to add couple of lines within do install, but only for php-fpm package, php-native keeps failing because of this lines..
rvignesh has joined #yocto
alessioigor has quit [Quit: alessioigor]
rvignesh has left #yocto [#yocto]
<JaMa>
wkawka: that question doesn't make much sense, you can use do_install:append:class-target to do something only in target build, but there is only one do_install and various files are then packaged into specific packages based on FILES variables
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
Guest39 has joined #yocto
<Guest39>
Hi All, I am trying to build kirkstone on a centos7 VM and hitting an issue with dbus. The error message says "ERROR: dbus: useradd command did not succeed." so I tried running bitbake dbus and it gives the same error. I tried `BBDEBUG=1 bitbake dbus` command and i dont know what I am looking at. Can some one help me ? I only know basic knowledge
<Guest39>
about yocto
PobodysNerfect_ has quit [Quit: Gone to sleep. ZZZzzz…]