<LetoThe2nd>
howdy! after playing a fair bit with bitbake-setup over the weekend, I have two preliminary findings which might or might not be accurate, still tinkering.
<LetoThe2nd>
first: bb-setup with a hot sstate cache seems to be a LOT faster than a comparable kas setup with hot sstate cache. judging from my pipeline, it is about 35s vs. 150s.
<Guest93>
| /yocto_new/openembedded-core/build/tmp/work/x86_64-linux/mesa-native/25.2.5/recipe-sysroot-native/usr/include/llvm/ADT/DenseMapInfo.h:17:10: fatal error: 'cassert' file not found
<Guest93>
| Unable to generate bindings: clang diagnosed error: /yocto_new/openembedded-core/build/tmp/work/x86_64-linux/mesa-native/25.2.5/recipe-sysroot-native/usr/include/llvm/ADT/DenseMapInfo.h:17:10: fatal error: 'cassert' file not found
<Guest93>
|
<Guest93>
Can someone please help me out?
<rburton>
you're probably missing libstdc++ on the host
<walter>
I built core-image-weston master yesterday on a brand new Fedora 43, everything worked like a charm.
<walter>
I have a question about Yocto Project Virtual Summit now that the CfP has ended. When do we get the list of presentations? I registered and I'm curious what I'm going to see there.
<throos>
similar issue with bitbake-layers: bitbake-layers layerindex-fetch meta-aws -b master, will "Adding layer "meta-aws" (/home/ubuntu/bitbake-builds/poky-master-poky-with-sstate-distro_poky-altcfg-machine_genericarm64/layers/openembedded-core/meta-aws/) to conf/bblayers.conf" -> I would have expect to download it to layers dir? Or doing I'm something wrong? What is the suggested way of adding a layer to bitbake-setup?
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
Guest47 has quit [Quit: Client closed]
Guest47 has joined #yocto
rber|res has joined #yocto
<rber|res>
is bitbake-setup able to use something like PREMIRRORS instead of upstream for the layers it fetches?
<Xogium>
hi people :) is there ocaml support in OE ?
<walter>
Xogium: there doesn't seem to be a recipe for ocaml or opam in layerindex. https://layers.openembedded.org/ -- there's an discontinued recipe to prepare the build system from intel, but that's about it.
<Xogium>
well
<Xogium>
crap
<walter>
Guest93: you're looking at the wrong docs if you are using master branches. check the dropdown from the top and switch to dev. (this might help)
<Xogium>
looks like yocto is out the window before my project even begins lol
<walter>
Xogium: You can always build outside and just install using a simple recipe.
<Guest93>
tried the dev also. doesn't make any difference
<walter>
Guest93: I'm no expert, but one thing to look out for is to make sure you have recent master branches on all layers. I've seen strange errors when using a wrong checkout for a given layer or when using an old bitbake.
jmiehe has joined #yocto
<Guest93>
Every layer is latest in my build, I have verified
<walter>
Make sure you're not on detatched HEAD, I've been bitten by that. and I was thinking that I'm on the latest. :)
<Xogium>
walter: what do you mean build outside and install using a simple recipe ?
<walter>
Xogium: You can always take a build artifact from a CI/CD pipeline and install it from there directly into your image.
ptsneves has quit [Remote host closed the connection]
ptsneves has joined #yocto
<walter>
Xogium: your recipe can be as simple as copying a built binary into /usr/bin of the built root file system.
<Xogium>
oh, in that sense, yeah. I got what you meant now :D
<walter>
the OE build system has some assumption on how dependencies are managed, and it would be tricky to implement properly and have dependencies managed by yocto, but if you build outside and just install, it will just work, no need for complex stuff.
ptsneves has quit [Ping timeout: 240 seconds]
<walter>
ecosystems that relly heavily on package managers are a bit more tricky to fully and properly integrate into OE/Yocto, you have to know what you are doing. You can take a look at the Golang integration, you need something on those lines.
<jmd>
Ruby on Rails is worse!
<Xogium>
yeah I'd have a ton of things to build in order to make even one single binary
<Xogium>
lots of bindings and stuff
<walter>
and the Golang integration takes a easy way out and uses the "vendoring" feature of go modules, to get around managing dependencies.
<Guest93>
dpkg -l | grep libstdc++
<Guest93>
ii libstdc++-11-dev:amd64 11.4.0-1ubuntu1~22.04.2 amd64 GNU Standard C++ Library v3 (development files)
<Guest93>
ii libstdc++-5-dev:amd64 5.5.0-12ubuntu1 amd64 GNU Standard C++ Library v3 (development files)
<Guest93>
ii libstdc++-9-dev:amd64 9.5.0-1ubuntu1~22.04 amd64 GNU Standard C++ Library v3 (development files)
<Guest93>
ii libstdc++6:amd64 12.3.0-1ubuntu1~22.04.2 amd64 GNU Standard C++ Library v3
<rburton>
Xogium: write a recipe, as walter said there's prior already to be "inspired" by
<Guest93>
Do I need any specific version of libstdc++?
<rburton>
Guest93: you need the one that your g++ will use
<Guest93>
how do I find out that?
<Xogium>
I'll need to port not only ocaml as a build time dep but all the other ocaml-* bindings to make my final program on the target work. That promises to be a lot of work indeed
<walter>
Does ocaml have a way to "ship dependencies" in your source code like Golang does? Aka: can you get around using opam by just commiting some stuff into a "vendor" directory?
<Guest93>
rburton why does it need cassert from host? Why it's not provided by yocto native recipes?
<Xogium>
I'm not sure
<walter>
actually, you can always allow network access to the compilation step, so that depdendencies are installed at that time. So, there's many paths to take if you want to integrate ocaml builds into a yocto project. as a noob I can think of quite a few ways to deal with this.
<Xogium>
I believe you can build from source without opam, but opam is very convenient
<rber|res>
@throos: the overrides file can be anywhere e.g. ./bin/bitbake-setup --setting default top-dir-prefix /workdir/build/poky-master-poky-distro_poky-machine_qemux86-64 init --source-overrides /workdir/sources/bitbake-new/bitbake/default-registry/configurations/bitbake-master-next-override.json
<walter>
as I said, you can still stick to opam; recipies can have arbritrary python tasks in them, so you can go crazy with the build system.
<Xogium>
I'll have to try and experiment
<Xogium>
opam would definitely make things easier because it would build all of the required deps
<walter>
I have a suggestion though, don't jump directly into this, try to do some smaller tasks first, to learn the ecosystem, otherwise your lack of knowledge will make it harder to do even the most basic tasks. Learn to patch an existing recipe first, learn to install some text files. then venture into this.
<Xogium>
absolutely
<walter>
I've bitten more than I could chew in the past. (I just recently started with Yocto) and I had to take a step back, learn stuff and then try again.
<Xogium>
oh yeah. I tried a while back to learn on my own, was a complete disaster too :D
<walter>
Yeah, yocto can be brutal in some regards.
<walter>
btw, there's a summit in december, you might wanna check it out.
<walter>
I'm almost finished moving an old buildroot project to Yocto in just a few months of part time work.
<throos>
is there any idea of a common folder name in a layer for the bitbake-setup json files already?
<Xogium>
I think for me what's been the hardest is where to focus my attention. The doc is so extensive you quickly get overwhelmed
<walter>
Xogium: checkout the first paragraph here, it looks like opam can work exactly how the golang build system works in yocto: https://github.com/tarides/opam-monorepo
<Xogium>
ooooh that looks very fancy
<walter>
Xogium: been there a couple of times, what I've learned is that I always need to take a step back and do things in smaller steps.
<Xogium>
I wish I could do that :D I always struggle to divide things into smaller steps
<Mayur>
I want to disable Uboot rescue shell in Uboot. (no one can enter a command) How can i do that? I can see that there are possibilities to dectivate it completely. But in general i want stdout nut want to block stdin.
<Mayur>
Is it possible in yocto? if yes how can i do that?
<Mayur>
Thank you in advance.
jmd has joined #yocto
<walter>
IIRC, you just need to set the timeout to a negative number. Let me check.
<Xogium>
walter: thanks for pointing to opam-monorepo. Unfortunately it won't work out for my use case, because it's only able to build a lock file on a per-project basis, and totally ignores optional deps for whatever insane reason. In my case there's a main project but that main project relies on a ton of bindings that each have their own repository and would each need their lock file and dune project file and...
<Xogium>
Ugh. More hassle than anything from what I' understanding
<walter>
Mayur: There's also `CONFIG_DISABLE_CONSOLE`, which you can add to your defconfig.
<walter>
And you might also want to look at CONFIG_BOOTDELAY=-1
<rburton>
Guest93: that's native code so it uses the host compiler. how would we build a compiler if we didn't rely on a host compiler?
vladest has quit [Quit: vladest]
<walter>
Xogium: You can always play with custom tasks with network access, or `do_build[network] = "1"`, and just add an opam recipe and add it as a native dependency.
<walter>
And you can improve from there, you don't need a "perfect" recipe from the start, just something that works and you can improve uppon.
<Xogium>
yeah seems like opam would be the better deal here, monorepo tries to do too complex and falls flat
florian_kc has quit [Ping timeout: 250 seconds]
<Guest93>
rburton how do I find which libstdc++ version to install to resolve following cassert error:
<Guest93>
| /yocto_new/openembedded-core/build/tmp/work/x86_64-linux/mesa-native/25.2.5/recipe-sysroot-native/usr/include/llvm/ADT/DenseMapInfo.h:17:10: fatal error: 'cassert' file not found
<Guest93>
| Unable to generate bindings: clang diagnosed error: /yocto_new/openembedded-core/build/tmp/work/x86_64-linux/mesa-native/25.2.5/recipe-sysroot-native/usr/include/llvm/ADT/DenseMapInfo.h:17:10: fatal error: 'cassert' file not found
rob_w has joined #yocto
goliath has joined #yocto
<walter>
Xogium: look at something like CHRPATH_BIN, and how it's used in `openembedded-core` by the package.bbclass, or even tar in perform_packagecopy. You can do something like that for a custom opam.bbclass and install everything that way in the right location. It's not the most correct way to do it, but it's a start.
<walter>
And your opam.bbclass could read the depends of a given opam file, and run opam on those. And from the actual bb file, you just inherit opam and add a task before compilation/build
Guest47 has joined #yocto
<Xogium>
mmh I see. I'll try to tweak that when I get better yocto experience
Mayur has quit [Quit: Client closed]
<rber|res>
@throos cool! I am fighting against adding some real hardware to it ;)
<walter>
Check go_list_packages and the install in go_do_compile. Also in OE-core.
vladest has joined #yocto
<Xogium>
walter: thank you :)
druppy has joined #yocto
Guest93 has quit [Quit: Client closed]
Jones42 has quit [Ping timeout: 256 seconds]
Guest47 has quit [Quit: Client closed]
Guest47 has joined #yocto
<walter>
Xogium: can you give me a public repo of an ocaml project that has the requirements? I wanna play with this a bit.
Guest93 has joined #yocto
<Xogium>
walter: oh sure that's entirely public :) check out https://github.com/savonet/liquidsoap -- that's the app I'm trying to figure out how to build in yocto so that it's available on the target at runtime
<walter>
Oh, nice.
<Xogium>
I probably could do diffrently, but I decided to challenge myself and try to run it on a stm32mp135d SoC
<walter>
Wow, you're in for a ride! I've tried to lookup how to do cross compilation on ocaml. You should first master that, before doing anything with Yocto. I'll try and prepare a recipe for simple normal builds, but I won't touch cross compilation, it's a lot to dig into.
<Xogium>
walter: oh my. Maybe I was too ambitious :D
<walter>
So, my initial suggestion to just deploy build artifcats from outside seems to be the way to go, but you still need to learn cross compilation for that to work.
<Xogium>
maybe I should just do a native build, cheating with qemu/binfmt to run armv7h or something
<Xogium>
would be slow on x86, but I'm almost certain that a native build on real armv7h hardware would be even slower :D
druppy has quit [Ping timeout: 264 seconds]
Guest70 has joined #yocto
Guest93 has quit [Ping timeout: 250 seconds]
frieder has quit [Remote host closed the connection]
<rburton>
but yes in general the ethos is to compile from scratch
<rburton>
we install prebuilt syslinux binaries because they are incredibly delicate and changing compiler can break them
Guest47 has joined #yocto
<walter>
Oh, I never new it's just a script. It always seemed too fast to be "just" a script.
<walter>
I see, thanks.
druppy has joined #yocto
yocto_developer has quit [Quit: Client closed]
<walter>
s/new/knew/
<ww-wojtek>
does anyone know how does it get decided whether each postinstall intercept hook runs? in particular the "update_udev_hwdb"
gvmeson is now known as vmeson
<ww-wojtek>
I am basically trying to find why when I add RDEPENDS += "libsdl2-dev" then suddenly my build fails when running the "update_udev_hwdb" hook but then when I remove it, then it seems like update_udev_hwdb never runs, but I can't see anywhere which specifically adds that script and also can't find any info in the Yocto docs about adding postinstall scripts
vladest has quit [Quit: vladest]
florian_kc has joined #yocto
leon-anavi has quit [Quit: Leaving]
druppy has quit [Ping timeout: 250 seconds]
vladest has joined #yocto
<khem>
ww-wojtek: bitbake -g is perhaps helpful in decoding the depchains in both cases and compare
<khem>
something is pulling in udev-hwdb
<walter>
I don't see any "libsdl2-dev" package, OE-core doesn't seem to have it. Where do you get it from?
<khem>
in that, its an output package, not to be confused with recipe name
<walter>
Usually there's a `-stuff` package provided, do `-dev` exist differently?
<walter>
Like so: PACKAGES = "${PN}-static ${PN}"
<khem>
they are automatically added since every package does provide some development headers and libs
<walter>
Oh, ok.
<khem>
see bitbake.conf for more details
dmoseley has joined #yocto
<walter>
Oh, now it makes sense. FILES:${PN}-dev
* tgamblin
just upgraded to Fedora 43, and is running a build to see what breaks
<walter>
tgamblin: it worked like a charm for me.
<walter>
I just tried it yesterday.
<tgamblin>
walter: it's a little surprising, but same here (so far)
<walter>
And I even ventured to try bitbake-setup. it also worked.
<walter>
Why would someone use the `usrmerge` DISTRO_FEATURE? I see lots of patches for making this work. Does moving things help in some way?
Guest47 has quit [Quit: Client closed]
<rburton>
walter: systemd needs it, and the split is mostly historical nonsense. Personally I’d only support usrmerge for simplicity.
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
<walter>
I see. thanks.
<Xogium>
I know the origin of the split usr and why it came about fwiw
eduardootero has joined #yocto
<Xogium>
something to do with not having enough disk space on the machine initially, so they ended up having to stuff /usr on a different hard drive, and having the primary one containing only the binaries needed to get the rest of the system going
<Xogium>
and since then, that stuck for some reason even though we definitely don't lack disk space and haven't for a very long time
<Xogium>
one of these "we do it but we forgot why we even do it" king of things
<Xogium>
*kind of things
<walter>
Nice.
jmd has quit [Remote host closed the connection]
<Xogium>
and to this day there are still people arguing in debian about split/merged usr and those who don't want it merged
<Xogium>
I think systemd 258 or maybe it'll be 259 ? Shoved that support out the window along with sysvinit style scripts support
<landgraf>
is there a class/recipe to install uv venv into the image (at build time)?
<walter>
fedora 42 seems to have symlinks to /usr/x.
<walter>
there doesn't seem to be anything like that in layerindex.
neverpan1c is now known as neverpanic
<walter>
Right now, I can go DISTRO_FEATURES += "monkey", and it's all fine! I would rather see a "no such feature" warning or something on those lines. Would such a QA check make sense to people? Should I add it to my list of things to try and implement?
<khem>
walter: a sanity check would not hurt
<khem>
landgraf:sadly no not yet
<khem>
Xogium: either you systemd or you don't, it has mind of its own, if you like it great if you don't its going to be painful :)
<walter>
Are you trying to say that maybe I should switch to systemd before something requires it?
Kubu_work has quit [Ping timeout: 260 seconds]
eduardootero has quit [Quit: Client closed]
ptsneves has quit [Ping timeout: 255 seconds]
eduardootero has joined #yocto
eduardootero has quit [Client Quit]
ptsneves has joined #yocto
sakoman has quit [Ping timeout: 256 seconds]
ptsneves has quit [Ping timeout: 240 seconds]
<khem>
well, its a choice for init system, we do have sysvinit and busybox-init in Oe-Core as well. and there are others in external layers so you have choice
<khem>
but systemd and sysvinit perhaps are most tested ones
<Xogium>
sure I was not meaning to impose systemd on anyone :D I'm sorry if it sounded like that
<khem>
Xogium: no it did not don't worry :)
<walter>
I didn't mean it like that, I was just wondering if in Yocto, systemd is more tested, I saw things like rauc or swupdate supporting systemd only. and I'm wondering if it has anything to do with the state of systemd vs others in yocto.
<khem>
I have cases where I use systemd and sysvinit ( well thats going away ) and also busybox-init
<khem>
walter: almost all binary distros use systemd as default init system and service manager these days so it gets more testing and swupdate is not limited to yocto alone it supports other systems as well so they have to take wide shot
<walter>
I see.
<khem>
there is a real cost to init system as it sits very deep in techstack, my view is vet one for your usecase and run with it.
sakoman has joined #yocto
<walter>
I went with the default. sysvinit. It works just fine for now. The update system will probably have some weight here.
<khem>
poky-altcfg is a systemd based reference distro in oe-core so you can use it as baseline if you want to use system
<khem>
systemd
<khem>
walter:how are you inducing radxa-firmware-ap6256 into your image ?
<walter>
I've tried `bitbake radxa-firmware-ap6256` so I can ran it through package-index and install it directly.
<khem>
I see, radxa-firmware-ap6256 is not a recipe
<khem>
right ?
<khem>
the recipe is radxa-firmware
<walter>
no, the recipe is a global one, radxa-firmware.
<walter>
yes.
<khem>
right, so you always bitbake <recipe>
<walter>
oh. got it. thanks a lot. I've ran into such things multiple times, and it never made sense to me, but now it's clear what I was doing wrong.
<khem>
recipe is the input ruleset which can build 1 or more than 1 output packages, often one of output package is same name as recipe name but is not always the case
<khem>
recipe is for builttime != what you install at runtime
<Xogium>
honestly, I still wish one on one training for yocto/OE was a thing ^^
<Xogium>
I'm SO bad at trying to learn it
<walter>
I saw that broadcom-bt-firmware has an extra FILES entry for the main package that includes everything.
<khem>
Xogium: :) we all are
<khem>
although I am so much immune that I don't see problems anymore unless someone asks a question :)
<walter>
Xogium: you just need to keep going and you'll figure things out. The community is awesome, you always get someone to help with your problems/questions, but you need patience for that.
<walter>
Xogium: join the summit in december, I've already registered.
<walter>
And if it's not good enough or you have suggestions, please let me know, I can take a look to see what can be done.
<walter>
The same page has a footer link to the yocto-docs git repository.
dgriego has quit [Ping timeout: 246 seconds]
<Xogium>
hmmm. Looks like epub is pretty okayish looking
<Xogium>
took about 12 seconds to open, but it didn't choke on it
<Xogium>
*took
<Xogium>
and the table of content is full of expandable/collapsed items, one item per secion. That's a lot easier already
<Xogium>
section even
dgriego has joined #yocto
<Xogium>
I reckon being able to browse the book without anything choking to death is a pretty good step in the right direction :D
<walter>
There are some strange things in the EPub, since most of us consume the docs via the web and don't always compile to see the output in various formats.
<Xogium>
oh ?
<Xogium>
like what ?
<walter>
Like in the "Use Git to Clone bitbake-setup" sub-section in "Quick Build"
<walter>
it's missing spaces in the sample CLI output.
<walter>
I'm looking into this now so that we can fix it.
<walter>
and the URL text next to the actual anchor link, I'm assuming it's hard to skip, maybe you can jump to the next "]" to skip it.
<Xogium>
actually doesn't get converted into a link for me, so I can't skip it :D
<Xogium>
it looks like markdown to me kinda, with the whole url displayed in between brackets
<Xogium>
but it could be my reader
<Xogium>
I'll try another, hang on
<walter>
no, it's the same in my viewer, it's the EPub.
goliath has quit [Quit: SIGSEGV]
<walter>
Xogium: Are you on Gnome or KDE?
<Xogium>
erm, neither, gave up on linux GUI accessibility about 2 years ago, and for anything GUI related I unfortunately had to go back to windows
<Xogium>
but I use archlinux and a windows vm as my daily driver
<Xogium>
I do the build on the linux side and read doc and edit things on windows side
<Xogium>
not that windows is orders of magnitude better for accessibility, mind... But it's better than linux still is even now
cyxae has quit [Remote host closed the connection]
<walter>
thanks, I'll take a look.
<walter>
have you used the toaster UI for Yocto? or you didn't come accross it?
<Xogium>
I don't think I've ever heard of it
<walter>
It's a web UI. and you get away from that wall of text from bitbake.
<Xogium>
hmm
<walter>
There's a section for it in the mega manual, the 3rd section from the end.
<Xogium>
there any public demo I could try toying with just to poke at the accessibility ?
<Xogium>
or I better use it locally ?
<walter>
locally, it's better. Let me check something. I've never tried it myself.
<walter>
The mega manual is barely usable. my EPub reader is painfully slow when I open it.
<Xogium>
wow I'm surprised :D
<Xogium>
here it's super slow until it opens and the it stabilizes
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<khem>
use EPUBReader extention with chrome :)
Guest47 has joined #yocto
<khem>
or same extention on firefox
Guest47 is now known as Gratien
<Gratien>
Hi, I am trying to generate the sbom using the spdx format.I added
<Gratien>
INHERIT += "create-spdx" in my main .inc that is included by the bb file but nothing happens. What do I miss ? And why sometimes the inherit is in cpas and need a plus sign and sometimes it's in lower case witthout any equal or plus sign ?
<AdrianF>
Gratien: Bitbake creates a context per recipe. Similar to a C compiler where you get something from an include file only if you include it. For example the file referred by kehm is included by all recipes. But setting a variable e.g. in a bb file has only an impact on that particular recipe.
<Gratien>
AdrianF ok, this is important to note. But in this case, I still don't understand where to put this inherit and why sometimes I have "inherit features_check" and sometimes I need a "+=". I can try in my distro.conf file, but this file only contains DISTRO_FEATURES for the moment. Important note : I am not the author of the original yocto config. I
<Gratien>
am trying to modify a configuration done by someone who is not part of the company anymore :-(
sakoman has quit [Ping timeout: 240 seconds]
<khem>
inherit is in recipe scope (.bb .bbappend or recipe .inc ) files INHERIT += "" is for global configuration scope so goes into config files
dr_kokobas has quit [Ping timeout: 260 seconds]
<Gratien>
Ok I added the inherit in the distro config file and it seem to compile a lot of "do_spdx". I guess it's okk now. I will see the result tommorow
<walter>
something is definetly wrong with my EPub viewer (Okular), it doesn't like these generated EPub files, I changed the code to be able to generate one chapter as a standalone manual, and it just froze on 29 pages.
dmoseley has joined #yocto
sakoman has joined #yocto
<Gratien>
Ok it worked! Thanks for the help
<khem>
walter: okular is not one of best for epubs
florian_kc has quit [Ping timeout: 244 seconds]
<khem>
epubs are best for e-readers e.g.
<khem>
if you have one of those kindle, kobo, boox kind of devices
druppy has quit [Ping timeout: 245 seconds]
jmiehe has joined #yocto
florian_kc has joined #yocto
Gratien has quit [Ping timeout: 250 seconds]
zeemate has quit [Ping timeout: 246 seconds]
jmiehe has quit [Quit: jmiehe]
<kilobyte_ch>
Hello, Any good way to pass in git hash and tag as variable from KAS?
alperak has quit [Quit: Connection closed for inactivity]