<vmeson>
jwinarsk: nice. If you can narrow things down to a bug in llvm and create a bugzilla.yoctoproject.org, then someone might take a look. riscv isn't quite officially supported by YP but some vendors (like WR ! ) are supporting boards...
* vmeson
calls it a day
wak has joined #yocto
* marex
is reminded to always rerun -c package_qa ( thanks khem )
florian has joined #yocto
lexano has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 240 seconds]
<jwinarsk>
vmeson: Well I think I'll end up solving it within the week, so no worries. Was just looking for anyone who was familiar with the issues.
nerdboy has quit [Ping timeout: 255 seconds]
Daanct12 has joined #yocto
nerdboy has joined #yocto
pedrowiski has quit [Changing host]
pedrowiski has joined #yocto
simonew has quit [Ping timeout: 255 seconds]
aardo has quit [Ping timeout: 256 seconds]
<khem>
vvn: you can try `bitbake-layers show-appends libcamera`
ardo has joined #yocto
<Zapados>
This is basic, but my brain is getting fried. :) bblayers.conf is generated by kas. Don't you want you MOST specific things at the bottom of bblayers.conf usually? But when you do an includes in kas, it appears to toss it at the TOP....
davidinux has quit [Ping timeout: 272 seconds]
davidinux has joined #yocto
pedrowiski has left #yocto [Leaving]
chep` has joined #yocto
chep has quit [Ping timeout: 240 seconds]
chep` is now known as chep
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #yocto
<vvn>
Zapados: I'm certainly not gonna help here but... I wouldn't recommend kas at all. It discourages you from mastering OE and BitBake, for actually not a lot of value once you know the tools.
<vvn>
khem: unfortunately bitbake-layers errors out the same way (it requires a working setup)
<vvn>
khem: found why. It's because I'm trying to compile my image for a BSP supporting kirkstone, and back then the recipe was libcamera.bb, not libcamera_0.1.0.bb so the libcamera_%.bbappend don't find the recipe.
<vvn>
khem: I fixed it with BBMASK += "${@"libcamera_.*\.bbappend" if d.getVar("LAYERSERIES_COMPAT_openembedded-layer") == "kirkstone" else ""}"
* vvn
can't look himself in the mirror anymore
<vvn>
khem: surprisingly this fix doesn't work with LAYERSERIES_COMPAT_multimedia-layer, it has to be LAYERSERIES_COMPAT_openembedded-layer.
<vvn>
My bad it does work with: BBMASK += "${@"libcamera_.*\.bbappend" if d.getVar("LAYERSERIES_COMPAT_multimedia-layer") == "kirkstone" else ""}"
<vvn>
I really believe that this is a bad practice to not keep the previous compatible release when there is no reason to not support them.
<vvn>
unless there's a breakage, layers (especially general layers such as meta-openembedded ones) should append the LAYERSERIES_COMPAT and not replace it.
dankm has joined #yocto
<vvn>
It makes layers assembling around a bump quite annoying
ablu has quit [Ping timeout: 268 seconds]
ablu has joined #yocto
xmn_ has quit [Quit: xmn_]
enok71 has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
alperak has quit [Quit: Connection closed for inactivity]
jmd has joined #yocto
alessioigor has joined #yocto
mulk has quit [Ping timeout: 246 seconds]
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
mulk has joined #yocto
xmn has quit [Ping timeout: 264 seconds]
nerdboy_ has joined #yocto
nerdboy has quit [Ping timeout: 252 seconds]
enok71 has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
kleist7 has joined #yocto
kleist7 has left #yocto [#yocto]
arielmrmx has quit [Ping timeout: 246 seconds]
arielmrmx has joined #yocto
linfax has joined #yocto
Saur75 has quit [Quit: Client closed]
Saur75 has joined #yocto
ray-san has joined #yocto
mulk has quit [Ping timeout: 256 seconds]
mulk has joined #yocto
frieder has joined #yocto
fray has quit [Ping timeout: 255 seconds]
rfuentess has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
vladest has quit [Ping timeout: 252 seconds]
_lore_ has joined #yocto
fray has joined #yocto
Saur75 has quit [Quit: Client closed]
Saur75 has joined #yocto
Zapados has quit [Quit: Client closed]
<LetoThe2nd>
yo dudX
jmd has quit [Remote host closed the connection]
vladest has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
florian has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.2.1]
prabhakalad has quit [Remote host closed the connection]
prabhakalad has joined #yocto
jmd has joined #yocto
Daanct12 has joined #yocto
Guest41 has joined #yocto
<Guest41>
morning
<Guest41>
was wondering if there is a way to build python3 in yocto but not te native part
<Guest41>
explanation: I had to use the python3_8.5 recipe in kirkstone and the build of the native cannot find the flit_core module
<rburton>
Guest41: building python3 won't require flit
<rburton>
python3 just depends on python3-native which is part of the same recipe. you'll want to preferred-version both python3 and python3-native.
<rburton>
A better question is "why on earth am i trying to use an older version of python, this is madness"
<Guest41>
rburton: for a whl file (pytorch)
<rburton>
pytorch only has a wheel for py3.8? despite 3.8 being almost 5 years old?
<Guest41>
rburton: have to add the python3_native to the local.conf
<Guest41>
rburton: I know this is the whl produced by the sdkmanager installed pytorch which is compatible with their CUDA/CUDnn
<rburton>
nvidia?
<rburton>
if you're using nvidia jetson stuff then https://github.com/OE4T/meta-tegra is definitely worth looking at, if you're not already
<Tyaku>
Hello, I have a lot of "coreutils" software in /usr/bin, but someone is missing: "timeout". Did someone know if we have something specific to do to enable it ?
florian_kc has joined #yocto
<Tyaku>
Did we have to install a special package like coreutils-timeout or something like this ?
<Tyaku>
Oh my god, the problem is because I have two version of coreutils in my yocto >_<, the coreutils from meta-gplv2 is too old and does not provite "timeout". I'm going to set prefered version to the poky one
<RP>
meta-gplv2 is not recommended
Guest41 has quit [Quit: Client closed]
<Tyaku>
preferred version 8.32 of coreutils not available (for item coreutils)
<Tyaku>
what a hell, I see it in the poky repo
ptsneves has joined #yocto
<mcfrisk_>
Tyaku: if you mark license incompatible, then certain recipes may get replaced from other layers. same with layer priorities. there are reasons why your build doesn't use coreutils from poky, but those are in your build setup, e.g. coming from meta-gplv2 which is not recommended to be used.
ptsneves has quit [Ping timeout: 255 seconds]
<Tyaku>
PREFERRED_VERSION_coreutils ?= "8.32" has no effect
<Tyaku>
I understand, but currently I don't know the impact of removing it.
<Tyaku>
This layer was comming from renesas BSP
<LetoThe2nd>
RP: "not recommended"... 🤣🤣🤣🤣🤣
<Tyaku>
Removing it, gives me instant error:
<Tyaku>
ERROR: No recipes in default available for: /mnt/project/git/OTODO/hub-mz-rzg2ul/build-hub-mz/../sources/meta-renesas/meta-rz-common/recipes-extend/bash/bash_3.2.57.bbappend
<Tyaku>
Well :/
JaMa has quit [Quit: reboot]
<Tyaku>
I'm going to keep it right now, and try to find why the coreutils from poky is not "seen"
<RP>
Tyaku: it is trying to append the bash version from meta-gplv2. That is another really old piece of software we'd not recommend
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<Tyaku>
So at this point, I'm going to bypass the problem. Old time ago I found a bash implementation of timeout, I'm going to search it again, if it's working/compatible licence i will use it ...
<mcfrisk_>
Tyaku: SW stack can be compiled without GPLv3 and without meta-gplv2 but that requires some care and hacking. There are products out there which do that. They don't include bash on target for example. You can BBMASK it away if BSP or other layers depend on it but you don't really need it.
<kanavin>
do you need timeout in actual products, or just for development purposes?
<rburton>
yeah, absolutely fine to have an internal build that uses gpl3 for the extra tools
<Tyaku>
kanavin, we need timeout in production, we use it in many places, for exemple do to an action with timeout. For exemple to wait for a socket or something.
<Tyaku>
We have a prod and dev image, the dev image include GPLv3 stuffs like rsyslog, gdb etc
<Tyaku>
But on PROD image we don't want it.
<Tyaku>
so thanks, I'm going to check if I find the timeout implementation in bash.
<kanavin>
gplv3 working as intended here
<kanavin>
either you fulfil its obligations that preserve essential freedoms or you run into issues trying to ship a product
<mcfrisk_>
maybe also in upstream busybox and from poky
<Tyaku>
maybe, but as this is part of busybox I don't know now how difficult it is to use it. There are some priorities between coreutils / busybox as I know
<mcfrisk_>
busybox has coreutils/timeout.c by default. make it work and problem solved.
<rburton>
just enable it in busybox if we don't already (if we don't, we should)
<rburton>
if your coreutils isn't shipping timeout then there's no priority problems
<Tyaku>
Yep my current coreutils is not providing timeout
<Tyaku>
ERROR: Nothing RPROVIDES 'timeout'
<rburton>
it wouldn't ship a pacakge called timeout
<rburton>
the initial timeout added back in 2008 or whatever was gpl3 so you definitely don't have it
mvlad has joined #yocto
speeder has joined #yocto
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #yocto
enok71 has joined #yocto
speeder_ has joined #yocto
<Ad0>
is there any recipe I can override or something to set a system wide env var?
speeder has quit [Ping timeout: 255 seconds]
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
<rburton>
make your own, drop something into /etc/profile.d/
lexano has joined #yocto
plat51 has quit [Quit: Client closed]
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
goliath has quit [Quit: SIGSEGV]
sev99 has joined #yocto
tleb has quit [Write error: Connection reset by peer]
jonesv has quit [Write error: Connection reset by peer]
raghavgururajan has quit [Write error: Connection reset by peer]
tleb has joined #yocto
raghavgururajan has joined #yocto
jonesv has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.2.1]
<landgraf>
bitbake in AWS codebuild env (executed as user, not root) tries to access /root/.netrc and fails with permission denied. what can be the reason?
<Ad0>
thanks rburton . should I put it in some other recipe dir or my own ?
<Ad0>
hardest part about yocto is to figure out where stuff belongs
<roussinm>
For application developers that are using the SDK from yocto, how do you run your unit tests? through QEMU or you have an additional native environment?
paw has joined #yocto
<moto-timo>
Before I worked on Yocto Project, we ran our MCU unit tests with minGW.
<moto-timo>
In this way, our application code was tested before we ever even received hardware (with some very great success stories)
<roussinm>
with mingw? What was your test runner? GoogleTests ?
<moto-timo>
But probably the siemens folks can better answer what they are doing in the new ide enablement.
<moto-timo>
Well, we used CPPUnit test, but that was again on MCU class chips, not Linux.
<roussinm>
ok, it's a lot different probably.
<rburton>
Ad0: your change, your recipe, your layer
<Ad0>
thanks
<rburton>
Ad0: ideally oe-core is modified: upgrading to a new release when you've changed oe-core is hard
<roussinm>
We have about ~15 dependencies to the project, and keeping those dependencies in sync with yocto might be a problem, so we thought of running unit test through qemu.
<moto-timo>
Ad0: yeah, keep your changes to "oe-core" in a separate layer. Maybe even a dedicated layer.
<rburton>
roussinm: ptest + qemu + testimage ftw
sev99 has quit [Quit: Client closed]
<Ad0>
yeah I have my own layer with my own recipe
<moto-timo>
roussinm: then you probably want to use ptest and the newish "per image ptest" enablement. You can see the additions in meta-perl, meta-python, meta-oe and some more recent ones for how that can be done. It uses BBCLASSEXTEND in a special way to build for instance core-image-minimal + your package + your package ptests.
<roussinm>
moto-timo: the units test that I want to run are specific to an application from an image, and they are developped by the application team, they don't have any yocto setup on their side. They are not ptests.
enok71 has joined #yocto
<roussinm>
rburton: testimage + qemu, maybe we can probably just combine both for us. We can have our device environment + test environment, inside one image. This is much easier to handle for the app team.
<moto-timo>
roussinm: e.g. core-image-ptest-python3-cryptography or meta-python-image-ptest-python3-pytoml
<roussinm>
I think the workflow for the app team would looks like this preferably: write test/code, deploy to qemu run test with ctest/cmake + run application with new feature. It would be annoying to swap environments.
<moto-timo>
that was sort of what extensible SDK (eSDK) was trying to solve, but whether it works for your team is a deeper question
<roussinm>
Hm, we have never tried the eSDK.
<moto-timo>
what is your application stack written in? is it C/C++ code or NodeJS or?
<roussinm>
C++
<roussinm>
+ Qt.
<moto-timo>
what is your target hardware? Arm?
<roussinm>
x86, funny enough. zen2 amd.
<moto-timo>
what host OS are most of your application developers running? Linux or Windows or?
thomas_34 has joined #yocto
<roussinm>
It's a mix, Windows with WSL, and others are using Linux.
<thomas_34>
Hi, a short question regarding overrides: Is it possible to "combine" overrides? For example myVariable:foo:bar = "test". Will "myVariable" be only set to test, if "foo" AND "bar" show up in OVERRIDES ?
<moto-timo>
sadly I have very little WSL2 experience, so my advice there is a bit weak.
<moto-timo>
thomas_34: meta-tegra chains some overrides, depends on what you are trying to do
<moto-timo>
roussinm: I think a carefully crafted qemux86-64 testimage will probably work well for you, but minGW certainly could work as well for the Windows folks.
<thomas_34>
moto-timo, I have different machine configurations and image definitions. I control both with overrides. I would like to configure different u-boot-configs for a combination of machine and image definitions.
<moto-timo>
roussinm: I haven't done a lot of application development in several years, so I need to revisit this workflow enablement (you are not alone)
<thomas_34>
But thanks, ill search a bit in meta-tegra
<roussinm>
moto-timo: Windows dev, they use the yocto sdk through wsl so that works well. The "problem" with the sdk is that the target sysroot cannot run on the machine you build it, which makes sens, but prevents running test with gtest. Maybe eSDK is the answer for this...
<moto-timo>
thomas_34: you can also have a "common" override that is just a placeholder for the behavior that you want and each machine can "inherit" that override... Matt had some secureboot and disk encryption overrides for that, might have been in his tegra-test-distro layer.
<moto-timo>
I start to forget after two years ;)
sev99 has joined #yocto
<rburton>
Today I learnt that the vscode plugin for yocto just merged vim support
<moto-timo>
Henry and I were on the same team and worked on that video together.
<moto-timo>
vim key mappings make an IDE much less annoying for us old school devs.
Tyaku has quit [Ping timeout: 260 seconds]
Tyaku has joined #yocto
<neverpanic>
A qemu-static binary combined with a binfmt entry is a nice way to make the architecture difference transparent to users to the point where you can essentially compile and run locally as if there was no arch difference.
<roussinm>
qemu-usermode ?
<thomas_34>
moto-timo, yeahh okay... I didnt understood your idea, but I will see
<neverpanic>
Combine that with some mount namespace magic, and you'll get essentially transparent cross-compilation, especially if your target device is x86_64 (and your devs are also running x86_64).
<neverpanic>
I know we did that approach years ago at $carcompany. It did take a bit of fiddling with how Yocto builds and SDK, though.
amitk has joined #yocto
Zapados has joined #yocto
goliath has joined #yocto
<rburton>
neverpanic: stop it you've giving me PTSD flashbacks to scratchbox
Saur75 has quit [Quit: Client closed]
Saur75 has joined #yocto
enok71 has quit [Ping timeout: 260 seconds]
Zaid has quit [Quit: Client closed]
<gmorell>
OM
joekale_ has joined #yocto
joekale has quit [Ping timeout: 264 seconds]
sakman has joined #yocto
thomas_34 has quit [Ping timeout: 250 seconds]
ctraven has joined #yocto
sotaoverride has quit [Killed (lithium.libera.chat (Nickname regained by services))]
ctraven is now known as sotaoverride
sotaover1ide has joined #yocto
Zapados has quit [Quit: Client closed]
ray-san has quit [Ping timeout: 256 seconds]
jmd has joined #yocto
rfuentess has quit [Remote host closed the connection]
Tyaku has quit [Quit: Lost terminal]
geoffhp has joined #yocto
vladest has quit [Ping timeout: 246 seconds]
vladest has joined #yocto
zhmylove has quit [Remote host closed the connection]
enok71 has joined #yocto
<jdiez>
hi, i'm trying to emulate an additional serial device on the qemu-system-aarch64 `virt` machine. It only has one serial port by default, so I added `qemuparams="-device pci-serial,..."`. lspci -k inside the VM shows the serial device, but no driver is bound. It shows up as a "Serial controller: Red Hat, Inc. QEMU PCI 16550A Adapter (rev 01)", which should be supported by the `serial_8250` driver - which is included in linux-yocto.
vladest has quit [Quit: vladest]
<jdiez>
What am I missing?
Saur75 has quit [Quit: Client closed]
Saur75 has joined #yocto
vladest has joined #yocto
<RP>
| Your perl and your Config.pm seem to have different ideas about the| architecture they are running on.| Perl thinks: [x86_64-linux]| Config says: [arm-linux]
zpfvo has quit [Quit: Leaving.]
joekale_ has quit [Ping timeout: 268 seconds]
joekale has joined #yocto
vladest has quit [Quit: vladest]
florian_kc has quit [Ping timeout: 260 seconds]
florian has quit [Quit: Ex-Chat]
Zapados has joined #yocto
<Zapados>
If you wanted to re-order layers in kas with repos, would you just copy-paste the repo?
<Zapados>
For example, you wanted meta-dodo from my-repo, then meta-yaya from that-repo, then meta-zzz form my-repo.
<JaMa>
you mean to reorder it in BBLAYERS variable?
<khem>
vvn: if we keep appending to LAYERSERIES_COMPAT then we are claiming that we are testing this branch of a given layer with all the releases we are mentioning in LAYERSERIES_COMPAT, which meta-openembedded layers do not do, we usually test with the given release series
<rburton>
Zapados: are you doing some very clever things with overlaying for the layer order to be that important?
<rburton>
(s/clever/fragile/)
<Zapados>
JaMa it looks like directly writing BBLAYERS in a kas YML is a no-no. kas wants to manage BBLAYERS for you.
<Zapados>
rburton I'm not sure...working with some organically grown (messy) stuff, and found when I dropped the BBLAYERS I'm getting all kinds of fun errors to work through, that I think were masked with the BBLAYERS "override" in one of the YMLs.
sev99 has quit [Quit: Client closed]
Zapados has quit [Quit: Client closed]
<jdiez>
(spoiler: SERIAL_8250 was not enabled in the kernel build. d'oh.)
<JaMa>
Zapados: yes if I read it correctly it sorts the layers alphabetically which is *ehm*
florian_kc has joined #yocto
jclsn has quit [Quit: WeeChat 4.2.1]
jclsn has joined #yocto
Zapados has joined #yocto
jclsn has quit [Quit: WeeChat 4.2.1]
simond47220 has joined #yocto
rfried8 has joined #yocto
mdp_ has joined #yocto
marka has joined #yocto
pbsds9 has joined #yocto
dankm_ has joined #yocto
pidge_ has joined #yocto
Lihis_ has joined #yocto
dmoseley_ has joined #yocto
jclsn has joined #yocto
paw has quit [Ping timeout: 256 seconds]
mdp has quit [Ping timeout: 260 seconds]
TundraMan has quit [Ping timeout: 260 seconds]
Saur has quit [Ping timeout: 260 seconds]
mdp_ is now known as mdp
sotaover1ide has quit [Ping timeout: 264 seconds]
Omax has quit [Ping timeout: 264 seconds]
marex has quit [Ping timeout: 264 seconds]
bq has quit [Ping timeout: 264 seconds]
dmoseley has quit [Read error: Connection reset by peer]
dankm has quit [Ping timeout: 260 seconds]
pidge has quit [Ping timeout: 260 seconds]
pbsds has quit [Ping timeout: 260 seconds]
rfried has quit [Ping timeout: 260 seconds]
simond4722 has quit [Ping timeout: 260 seconds]
Lihis has quit [Ping timeout: 260 seconds]
nsbdfl_ has quit [Ping timeout: 260 seconds]
lucaceresoli has quit [Ping timeout: 260 seconds]
pbsds9 is now known as pbsds
rfried8 is now known as rfried
simond47220 is now known as simond4722
Lihis_ is now known as Lihis
bq has joined #yocto
nsbdfl_ has joined #yocto
marex has joined #yocto
Omax has joined #yocto
sotaover1ide has joined #yocto
Saur has joined #yocto
lucaceresoli has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
GNUmoon has quit [Remote host closed the connection]
<rburton>
TOP TIP: don't effectively write do_compile[cleandirs] = "${WORKDIR}"
<Saur>
rburton: What could possibly go wrong with that? ;)
<rburton>
it gets very confusing
<Saur>
rburton: At least you didn't try: do_compile[cleandirs] = "${HOME}"
<rburton>
lol
<rburton>
so I just did a thing
<rburton>
_so_ close
<rburton>
ERROR: python3-torch-2.1.1-r0 do_package_qa: QA Issue: /usr/lib/python3.12/site-packages/torch/lib/libtorch_cpu.so contained in package python3-torch requires libomp-4b8320f3.so(OMP_1.0)(64bit), but no providers found in RDEPENDS:python3-torch? [file-rdeps]
<JaMa>
send it to someone with automatically triggered CI using own workers..
<JaMa>
and add more ../ until workers stop responding
<JaMa>
we have secrets which only jenkins builders can have access to, but all developers have rights to anonymously trigger build with review which will upload them to dropbox
vladest has joined #yocto
starblue has quit [Ping timeout: 255 seconds]
<moto-timo>
Just add a task that will trigger when Jenkins has an OOM. It will happen soon enough.
<moto-timo>
"Jenkins: we will run out of memory sometime this week!"
starblue has joined #yocto
Starfoxxes has joined #yocto
xmn has quit [Quit: ZZZzzz…]
<Zapados>
Noob question - why does BBLAYERS order and BBFILE_PRIORITY matter? Is it that BBLAYERS only matters if both layers have the same BBFILE_PRIORITY?
vladest has quit [Quit: vladest]
ptsneves has joined #yocto
<rburton>
Zapados: not a noob question and some of the finer details are gnarly and very historical. we tried deleting most of this complication recently but found some edge cases. bblayers order controls something like bbclass search order iirc. there's a big thread on oe-arch from last month if you want to read :)
ptsneves has quit [Read error: Connection reset by peer]
ptsneves has joined #yocto
<rburton>
(this is the problem with having code that is old enough to drink)
sev99 has joined #yocto
vladest has joined #yocto
<Zapados>
rburton hmm, thanks!
sakman has quit [Remote host closed the connection]
<Zapados>
rburton, I'm also noticing that the order of repos in kas YMLs don't translate to BBLAYERS order...what gives!? :)
mvlad has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
alessioigor has quit [Ping timeout: 252 seconds]
khem has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
sotaoverride is now known as Guest6893
Guest6893 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
sotaover1ide is now known as sotaoverride
ctraven has joined #yocto
<JaMa>
Zapados: yes, that's what the sorted() does in the code I've shared
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #yocto
<Zapados>
JaMa I missed that. Wait...even chunks under bblayers_conf_header are sorted. This means there is no way to organize the layers, and then layer the YMLs.
mischief has quit [Quit: WeeChat 4.1.1]
<moto-timo>
at least for local_conf_header I use different named sections, knowing that the same name will be replaced with another (chained or included) yaml `testimage: |` will get replaced if I define it again in a subsequent file.
lexano has quit [Ping timeout: 240 seconds]
<Zapados>
moto-timo, yes, I like the replacement functionality. The issue is, say you have 1 layer that's like some base image...then you want to put some dev. tools on top of that. And maybe it has some special bbappends or something. There isn't a way to make sure that dev. tools layer is at the top of the BBLAYERS list.
<moto-timo>
kas build base.yml:dev.yml:test.yml
<moto-timo>
ah, you mean you need to prepend BBLAYERS
<Zapados>
moto-timo yes. Is that example the same as doing header: includes?
<moto-timo>
I don't know the answer off the top of my head, but I might be able to play around and figure it out. Otherwise, ask on the kas mailing list.
amitk_ has quit [Ping timeout: 252 seconds]
dankm_ has quit [Read error: Connection reset by peer]