reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
fray has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 248 seconds]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
sgw has joined #yocto
Articulus has joined #yocto
rber__ has quit [Ping timeout: 248 seconds]
rber|res has joined #yocto
Notgnoshi has joined #yocto
mbulut has joined #yocto
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
goliath has joined #yocto
amitk has joined #yocto
BenBE has quit [Ping timeout: 260 seconds]
rfuentess has joined #yocto
eminboydak has joined #yocto
ray-san3 has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
Guest48 has joined #yocto
BenBE has joined #yocto
xmn has joined #yocto
mvlad has joined #yocto
<Guest48>
Hi Everyone, just wanted to ask that from a packagegroup if i want to remove a single packageso that it doesn't get built in the final image is this the correct way to do it ?
<Guest48>
i am trying to do add this from local.conf as i dont want to remove it permanently and just want rootfs to be created once without the package
prabhakalad has quit [Quit: Konversation terminated!]
nerdboy has quit [Ping timeout: 258 seconds]
prabhakalad has joined #yocto
xmn_ has joined #yocto
Guest48 has quit [Ping timeout: 256 seconds]
<eminboydak>
Hello, I am using Yocto to create the rootfs and the kernel provided by the board manufacturer. Wi-Fi works on the default Debian rootfs but not on the rootfs I created with Yocto. I reached out to the company about this issue, and they provided me with a kernel module file named "bcmdhd.ko" and instructed me to enable the module in Yocto. I want
<eminboydak>
to enable the "bcmdhd" module in Yocto, but I can't find the proper solution. Is there anyone here who knows how to do this?
xmn has quit [Ping timeout: 260 seconds]
rynofinn____ has quit [Ping timeout: 260 seconds]
rynofinn____ has joined #yocto
armpit has quit [Ping timeout: 260 seconds]
madisox_ has quit [Ping timeout: 260 seconds]
madisox_ has joined #yocto
armpit has joined #yocto
stgloor has joined #yocto
zpfvo has joined #yocto
CosmicPenguin has quit [Ping timeout: 260 seconds]
LetoThe2nd has quit [Ping timeout: 260 seconds]
Crofton has quit [Ping timeout: 260 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
khimaros has quit [Ping timeout: 260 seconds]
NishanthMenon has quit [Ping timeout: 260 seconds]
stgl has quit [Ping timeout: 260 seconds]
stgloor is now known as stgl
LetoThe2nd has joined #yocto
khimaros has joined #yocto
NishanthMenon has joined #yocto
Crofton has joined #yocto
CosmicPenguin has joined #yocto
xmn_ has quit [Ping timeout: 252 seconds]
Kubu_work has joined #yocto
wmills__ has joined #yocto
kanavin has quit [Remote host closed the connection]
wmills_ has quit [Ping timeout: 245 seconds]
Thorn has quit [Quit: If at first you don't succeed, skydiving is not for you.]
leon-anavi has joined #yocto
frieder has joined #yocto
kanavin has joined #yocto
olani has joined #yocto
viric has joined #yocto
<viric>
Hello
<viric>
Why the devshell has to start inside a terminal emulator?
<viric>
Cannot it just be a child shell in the same terminal?
<abelloni>
I guess you can use the OE_TERMINAL variable
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 264 seconds]
eminboydak has quit [Ping timeout: 256 seconds]
florian has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
deribaucourt has joined #yocto
ederibaucourt has quit [Ping timeout: 252 seconds]
<kanavin>
viric, it probably can, I suppose you can study the code that starts it and propose improvements
<viric>
abelloni: I think OE_TERMINAL doesn't support any case without a new emulator
<viric>
kanavin: ok, I'll have a look.
<viric>
to me it was so evident that the easiest would be no emulator that I thought maybe I was missing something obvious
<kanavin>
viric, I suspect the issue is that the devshell has to run under pseudo (fake root environment which is a LD_PRELOAD hack)
<kanavin>
but how that ends up needing a new terminal, I don't know
<viric>
I think that the problem is that "bitbake" keeps on printing a progress bar in the normal terminal
<viric>
and then it would print over the devshell
<viric>
the fake root environment thing has nothing to do with a new terminal or not.
<viric>
when one uses a devshell, for a cmake project, "mkdir b; cd b; cmake .." fails.
<viric>
What else do I have to prepare, between devshell + the call to cmake?
<kanavin>
viric, I suppose do_configure?
<kanavin>
it's possible there are cmake-specific tweaks in do_configure, and devshell+bare cmake won't run them
<viric>
hm but that will use the build directory from tmp/work, not any I want, right?
<kanavin>
I mean, there are no promises that it will work. Only that you're getting an environemnt that replicates what the tasks are executed in, but the tasks may need to do additional things before invoking the underlying build system
Haxxa has joined #yocto
<viric>
and how can I call do_configure from the devshell?
<kanavin>
viric, and tbh, you'll be better served by devtool modify from the looks of it
<viric>
I'm using also devtool modify
<viric>
but I wanted the build env
<kanavin>
viric, run temp/run.do_configure
<viric>
so if I used devtool modify, I should not be using devshell to build?
<kanavin>
no, you just run bitbake as usual
<viric>
oh but that's very slow
<kanavin>
why?
<kanavin>
it will run incremental builds from workspace
<viric>
it takes 1min to run bitbake, loading cache, init tasks,
<viric>
it's the bitbake python thing that takes ages
<viric>
1 minute is ages, compared to 1 second of a compile error by just calling "make", I mean
<kanavin>
then you can use devshell without devtool
<viric>
exactly. Then I have to find how to make cmake find the sysroot
Shaun has quit [Ping timeout: 252 seconds]
<kanavin>
you can run task scripts from temp/
<kanavin>
run.do_configure, run.do_compile etc
<viric>
yes, now that you said I remember it
<viric>
but those are very hardcoded to the output paths & config options there set.
<kanavin>
yeah. but you should really look into why bitbake is slow for you. it shouldn't take a whole minute
<viric>
I only need cmake to find the sysroot, nothing else. I'll try to figure it out from the configure script
<viric>
Attempted 2212 tasks of which 2205 didn't need to be rerun
<kanavin>
you don't have to use devtool build, 'bitbake recipe' is fine
<viric>
I guess it's the same thing. I mean it took 2 minutes
<kanavin>
that is excessive
<viric>
I'm using the cache, so I'm already skipping the "parsing recipes" time
<kanavin>
but we've tweaked a few things in bitbake master that improve task handling times. Maybe you're hitting those issues. What layers are enabled in your setup other than meta/?
<RP>
viric: the challenge with tasks is that multiple tasks can happen at once. For that reason any shell task needs to be via a terminal multiplexer
<RP>
viric: BB_SERVER_TIMEOUT = "300" may help with reload time
ptsneves has joined #yocto
<viric>
RP: I tried that and it didn't seem a big improvement. Let me try.
Jones42 has joined #yocto
<kanavin>
viric, can you check if it is still slow in a plain poky environment (no other layers)?
<kanavin>
pick any cmake-based recipe in oe-core
<viric>
I was distracted but I'm checking it now
<viric>
'time bitbake recipe', twice in a row, with the server timeout 300, 1m22s each
<viric>
would bitbake say anything about succesfully connecting to a server?
<viric>
bitbake-cookerdaemon.log reports about clients connected.
<viric>
I don't see any advantage with the 'server' being alive
ptsneves has quit [Ping timeout: 252 seconds]
<RP>
viric: it would depend on what was using the time, as I said, it may have helped. I'm not entirely sure why your situation is so slow :/
<viric>
of 1m30s, 1m05s are "Initialising tasks"
<viric>
1 second Loading cache, 3 seconds Parsing recipes
<RP>
lots of layers and a complex dependency chain?
<viric>
It's 6076 tasks, none had to be rerun. Maybe it's ok for that amount of tasks?
<viric>
3325 bb files, 4947 targets
<viric>
I have always seen these times so I don't have other expectations
<RP>
I guess it depends on the machine you're running it on too. It is hard to say what is expected :/
<viric>
Xeon E-2276 2.8GHz (but peaks at ~4GHz with that turbo thing)
<viric>
E-2276M sorry
<viric>
It sounded like you expected 3 seconds
<RP>
viric: I've have thought 30s rather than more like 90
<viric>
ah, 30s vs 90s may be that you have a faster cpu
<viric>
or less tasks
<viric>
I picked the -DCMAKE_TOOLCHAIN_FILE=.. line from the do_configure and that seems enough
enok has joined #yocto
eminboydak has joined #yocto
enok has quit [Ping timeout: 248 seconds]
Shaun has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
pvogelaar has joined #yocto
Din has joined #yocto
Din has quit [Client Quit]
zpfvo has joined #yocto
ehussain has joined #yocto
Starfoxxes has joined #yocto
adrianp has joined #yocto
jstephan_ has quit [Remote host closed the connection]
<adrianp>
hello, in ubuntu there is /usr/share/docs/<package-name>/copyright
<adrianp>
how can i obtain this copyright on yocto built deb package?
<jdiez>
how do I tell bitbake to build the RDEPENDS packages in addition to its DEPENDs?
Jones42 has quit [Ping timeout: 260 seconds]
<jdiez>
i.e. I want to put these packages in an index: a DEPENDS on a-build-dep, a RDEPENDS on b; `bitbake a` results in `a` and `a-build-dep` being built
florian_kc has joined #yocto
<jdiez>
... but I also need `b` to be built so it can be downloaded on the target later
florian_kc has quit [Client Quit]
<jdiez>
maybe `bitbake -c world a`?
florian has joined #yocto
<KanjiMonster>
jdiez: bitbake --runall=do_package_write_ipk a
leon-anavi has quit [Quit: Leaving]
tgamblin_ is now known as tgamblin
goliath has joined #yocto
jmd` has joined #yocto
jmd` has quit [Remote host closed the connection]
<vvn>
If I want to create a image for my build host (x86-64) that I can use with Docker, should I write a custom image recipe which inherits container-host?
<vvn>
I'm not sure how host containers are supposed to be created with meta-virtualization
jmd` has joined #yocto
rfuentess has quit [Remote host closed the connection]
Kubu_work has quit [Quit: Leaving.]
zpfvo has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
<vvn>
Also is there a mechanism to set the preferred network manager? i.e. systemd-networkd, connman or networkmanager?
<flom84>
for connman or networkmanager, there are recipes in yocto that you can install and configure as you see fit
<flom84>
i dont recall if there is a "virtual" network manager variable that you can set with your preferred manager...therefore its just installing and configuring one of them
BhsTalel has joined #yocto
<vvn>
yep that was my point, I think setting PREFERRED_PROVIDER_virtual/networkmanager would make sense (even though they are not technically different implementation of the same API)
<vvn>
I'm confused whether it is a container image intended for embedding into an embedded system, or if it is an host container image, or if it actually doesn't matter
<flom84>
containers can run anywhere...host, target
<flom84>
i dont think it matters here
<vvn>
I'm looking for a complete example for an host container, as I know it requires more config to set the machine (qemux86-64 I presume) as well as PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" I guess
florian has quit [Ping timeout: 244 seconds]
<zeddii>
vvn. There's no support for host containers. I actually have a feature about that, which I work on periodically, but with architecture mismatches, and kernel versions, etc, it is not easy to do generally
<vvn>
zeddii: I understand, it might not be fully portable, but it should be fairly easy to achieve and run on a relatively similar host, isn't it?
<zeddii>
sure. anything is possible, but I can't do half-support, it needs to be complete.
<zeddii>
and not for a particular container runtime, etc, etc.
<vvn>
I understand that, it makes sense
<zeddii>
the same way that we don't have every recipe as a -native variant.
<vvn>
In the meantime, how can I test/contribute that?
<zeddii>
it would be done in meta-virt, and really, there's no simple way to contribute that. it is very involved. and it is something that I've got bits and pieces done already.
<vvn>
(hum that makes me think that having the ability to build images with a -native suffix, e.g. core-image-base-native looks quite intuitive)
<zeddii>
but it is coupled to some cross-container install parts that I need to complete for the upcoming release.
<vvn>
I see
<vvn>
do you have an upstream reference for the required pieces that I can try?
<vvn>
the closest I guess would be a multiconfig setting MACHINE, PREFERRED_PROVIDER_virtual/kernel and the IMAGE_FSTYPES
<zeddii>
my WIP stuff is scattered across about 4 development machines. not until I get the cross container bits pushed to meta-virt is the oci container creation flexible enough to even try a -native OCI container.
<vvn>
are you recommending to not even try this?
<zeddii>
I mean, you can just build an OCI container from meta-virt that matches your host architecture. Head into deploy, jump into it with runc and you'll have some parts work for sure.
<zeddii>
but there's all sorts of host configuration, networking issues, security tweaks, different container runtimes, and integration with something that looks like "runqemu" to get the feature fully working. Which is the parts that I'm working on once summer ends and I'm back full time.
<vvn>
I have to valid usecases for this, one is providing a light image for hardware-agnostic application stacks (so that one can run with docker on a laptop instead rather than needed a development board) and the second is providing a development environment for each middleware application, x86-64 being one of them (so that these apps can optionally cross-compile in their own CI pipelines before
<vvn>
triggering a whole yocto build)
<vvn>
s/to/two/
BhsTalel has quit [Quit: Client closed]
<flom84>
for CI pipeline...should you use yocto SDK? curious why you need an yocto image to be used for others to do develop
<vvn>
the sdk is the default option for it indeed
florian has joined #yocto
<vvn>
zeddii: thanks I will try that. I am still confused by the container-host.bbclass. Am I supposed to use that?
<jdiez>
vvn: i also want to build container images as a base for application development. I've tried the container classes in meta-virtualization with mixed success. in theory, the only thing that is different when building a rootfs for a container is that you don't need the kernel/bootloader - and you want an extra build step where you take the rootfs and turn it into an OCI image
<zeddii>
that's for a target image running as a container-host.
<jdiez>
not necessarily
<zeddii>
jdiez, I'
<zeddii>
I wasn't answering your question
<jdiez>
oh sorry
<zeddii>
but if you had "mixed success" but have never mentioned it on meta-virt ...
<jdiez>
i'm assuming the mixed success is due to me doing something wrong, that's why I haven't mentioned anywhere
<jdiez>
KanjiMonster: that worked, thanks a lot!
goliath has quit [Quit: SIGSEGV]
<vvn>
zeddii: just to make sure I understand and don't mix the terminology here, container-host refers to what I want to implement, i.e. a container image runnable on the build host (well, "x86-64"), correct?
<jdiez>
vvn: container-host is for running container images on a target
flom84 has quit [Quit: Leaving]
<vvn>
haaa I see, it makes more sense
<vvn>
similar to systemd-container in order to add support for nspawn and such
jmd` has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
Starfoxxes has quit [Remote host closed the connection]
florian has joined #yocto
<vvn>
actually can systemd-networkd resides beside networkmanager, or they will conflict? (if systemd-networkd is disabled)
mbulut has joined #yocto
olani- has joined #yocto
vthor_ has quit [Remote host closed the connection]
vthor_ has joined #yocto
flom84 has quit [Quit: Leaving]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
BenBE has quit [Ping timeout: 258 seconds]
flom84 has joined #yocto
flom84 has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
<khem>
they can live together
<khem>
e.g. you can use nm to take care of wifi connection and networkd to manage ethernet
<Ch^W>
What is the procedure for dealing with autobuilder failures due to missing modules? Is that something that can be added to the autobuilder?
<khem>
missing modules ? you mean python, perl ?
<khem>
usually, these are provided by some recipe so adding the relevant recipe/package to deps/rdeps of failing recipe is the way to go
<Ch^W>
khem: No, we pushed a serial (RS-232) testing bbclass patch to OE-Core that needs to use pexepct. The autobuilder does not seem to have pexepect installed, so the build broke when it tried to load the module.
<gmorell>
looking at making a package out of a rust library that supports workspaces, but cargo-bitbake has a Lot of opinions. Is there a better way, or would I have to patch it to support worksapces
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
mbulut has quit [Ping timeout: 260 seconds]
<khem>
Ch^W:that should be part of HOSTTOOLS I believe then or made part of distro pre-requisites or perhaps bbclass should add a dependency on expect-native
<Ch^W>
khem: Oh, as in DEPENDS += "expect-native"?
<Ch^W>
I thought about that, but testing happens after the build, so I was sort of scratching my head as to where something like that would actually go.
<khem>
see meta/lib/oeqa/selftest/cases/glibc.py
<khem>
I think you need to install python3-pexpect
<khem>
gmorell: cargo-bitbake is a wrapper around cargo nothing more. What do you expect out of the this
<gmorell>
I meant the the ol bitbake update_crates, regardless they do the same thing but don't parse the toml correctly with the upgraded workspace decls
goliath has quit [Quit: SIGSEGV]
<Ch^W>
khem: Ah, nice thanks. I wish I had thought to grep for that. Cheers.
brrm has quit [Ping timeout: 248 seconds]
florian has quit [Ping timeout: 248 seconds]
mk3890 has quit [Remote host closed the connection]
olani- has quit [Ping timeout: 258 seconds]
cabazon76 has joined #yocto
<cabazon76>
Hey, I have a custom license file, LICENSE.my. How do I add it to meta-my layer? I read about SPDXLICENSEMAP variable but I'm not sure whether I can use that variable within meta-my layer