<yates_work>
ok i see. the addtask needs an "after" and a "before" to precisely place it.
belgianguy has quit [Ping timeout: 240 seconds]
dvergatal has joined #yocto
Marian57 has quit [Quit: Client closed]
xmn_ has joined #yocto
xmn has quit [Ping timeout: 246 seconds]
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
<LetoThe2nd>
yo dudX
alessioigor has joined #yocto
lars_ has joined #yocto
<lars_>
Good morning everybody. Is anyone here able to help with a fetcher problem?
rob_w has joined #yocto
pabigot has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<LetoThe2nd>
lars_: well, upon that question, probably nobody will step up. explain the problem in a rough outline, possibly including the error you see, and you will have a much higher chance. plus, its still rather early, just so you are aware.
<lars_>
Thank you, I receive a fetcher error for multiple packages in poky. For git sources the error is 128 no output, and for sources downloaded with wget the error is 4 no output.
<lars_>
When I copy the exact command that bitbake says fails it works fine for me.
<LetoThe2nd>
lars_: a vanilla poky build? did it work before?
<lars_>
I even let it download to the exact same place that bitbake wanted it, to see if I could get past the fetcher error, but it still wants to fetch it even if it is already there.
<lars_>
It worked before
<lars_>
Not vanilla, no. But the recipes it fails on are untouched
<lars_>
I have several images in the same repo and only one of them has this problem
pabigot has joined #yocto
<lars_>
The recipes that fail are right now edk2-firmware-202202-r0, acpica-native-20211217-r0, virglrenderer-native-0.9.1-r0, libsdl2-native-2.0.20-r0
<lars_>
I think these recipes are all unique the image I'm currently building, I don't think they are included in any of the other images in this repo. This image is a qemu image of the same distro as the other images, and these packages seem to be qemu specific
<LetoThe2nd>
lars_: do they share some common location to download from or such?
rusam has joined #yocto
nerdboy has quit [Ping timeout: 245 seconds]
<lars_>
Nope
<lars_>
And the error message says exactly what command it tries to run to download them. When I manually run this exact command, it works every time. But bitbake fails every time
<lars_>
I have seen several people on the internet with the same error, but they got no help
<lars_>
And my internet connection is perfect, I never have dropped connections or anything like that
goliath has joined #yocto
<lars_>
And one of the recipes is actually fetching from Github, so it should definitely not be a real networking issue
rfuentess has joined #yocto
<lars_>
It now seems to have gotten past those somehow after just retrying many times...
mckoan|away is now known as mckoan
<mckoan>
good morning
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
Schlumpf has joined #yocto
zpfvo has joined #yocto
olani_ has quit [Ping timeout: 246 seconds]
olani has quit [Ping timeout: 255 seconds]
varjag has joined #yocto
zpfvo1 has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
old_boy has quit [Quit: Client closed]
frieder has joined #yocto
<lars_>
@LetoThe2nd Hmm, now it reappeared again with the same package, edk2-firmware
<lars_>
In my earlier message I said that it somehow got past those but this was apparently not the case, it just waited a bit longer before attempting them this time.
GillesM has joined #yocto
GillesM has quit [Client Quit]
xmn_ has quit [Quit: ZZZzzz…]
GillesM has joined #yocto
<lars_>
Oh, wow. I restarted my docker container and now it actually worked (no false positive this time, I watched the do_fetch complete for both of the packages). Very weird that my container could somehow be in a state where it was unable to download just these specific packages...
GillesM has quit [Remote host closed the connection]
<qschulz>
ptsneves: ah the quartz64, yeah different SoC :)
<qschulz>
very surprised by how speedy the RK3588 is
<qschulz>
I think the board we work on is the fastest thing I own
caglar has quit [Quit: Leaving]
alessioigor has quit [Quit: alessioigor]
caglar has joined #yocto
alessioigor has joined #yocto
speeder_ has joined #yocto
speeder__ has quit [Ping timeout: 245 seconds]
<qschulz>
which says more on what I own than how fast RK3588 is :D
kpo has quit [Ping timeout: 246 seconds]
mvlad has joined #yocto
manuel1985 has joined #yocto
<ptsneves>
qschulz: ehehe I do not think that at the level of yocto work, the speed of the target matters much. I had extensive work on a continuous integration of an armv5. With tftp for bootloader and kernel and nfs for the rootfs it had cooler development workflow than I have seen in dev boards used for actual fancy products. Hell most of the integration done by the Yocto project is done on qemu :)
speeder__ has joined #yocto
speeder_ has quit [Ping timeout: 258 seconds]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
<qschulz>
ptsneves: tftp is a must when you do automation
caglar has quit [Quit: Leaving]
<qschulz>
though now U-Boot supports some implementation of wget
caglar has joined #yocto
rfuentess has joined #yocto
<ptsneves>
qschulz: oh did not know it supported a part of wget functionality. Does it handle https as well? u-boot the only OS you need
<qschulz>
ptsneves: no https AFAIK, you would need certificate handling
<ptsneves>
qschulz: very sparse doc. If it indeed only supports downloading something over HTTP/TCP it seems a bit confusing to call it wget. I do not think it supports basic authentication nor redirect
speeder__ has quit [Ping timeout: 246 seconds]
<qschulz>
ptsneves: won't comment on U-Boot being confusing :)
<ptsneves>
qschulz: Well the other day somebody complained that Yocto documentation is too big. There is always something :)
<rburton>
yeah he's nicely vocal about the problem
<rburton>
shame nothing changes
zpfvo1 has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
speeder_ has joined #yocto
speeder__ has quit [Ping timeout: 246 seconds]
speeder__ has joined #yocto
Vonter has quit [Ping timeout: 245 seconds]
Guest58 has quit [Quit: Client closed]
caglar has quit [Remote host closed the connection]
speeder_ has quit [Ping timeout: 250 seconds]
caglar has joined #yocto
Vonter has joined #yocto
<RP>
rburton: if they didn't backport so much, people might be more trusting of it :/
AndreRicardo has joined #yocto
<AndreRicardo>
Hello, we have a custom nginx_%.bbappend and now we would like to have a way to send one version of the available-sites if it's dev and another if it's prod. I'm not sure how is the best way to do this as we want both dev and prod images to include the nginx recipe.
<rburton>
write separate recipes to provide the configs
<rburton>
and bbappend nginx to delete files if you need to
Vonter has quit [Ping timeout: 260 seconds]
<AndreRicardo>
the only change is really on one of the sites enabled
<AndreRicardo>
dev has
<AndreRicardo>
server {
<AndreRicardo>
listen 80;
<AndreRicardo>
include /etc/nginx/sites-available/*.conf;
<AndreRicardo>
but could not get DISTRO_VARIANT from the image bb file
<rburton>
why is the image bb relevant?
<AndreRicardo>
because if the build is `bitbake -k prod-image` would like to use prod-image.bb file, if it's `bitbake -k dev-image` would use dev-image.bb
<rburton>
oh so 'distro variant' has nothing to do with distros
<AndreRicardo>
DISTRO_VARIANT is defined in prod-image.bb and dev-image.bb
<rburton>
variables set in recipes _do not_ leak into other recipes
<AndreRicardo>
no, it's for environment like "dev", "uat", "prod"
<rburton>
so do what i said originally: have a recipe for each configuration, your images pull in the one they want
<AndreRicardo>
Yes, I understand that now a little better with the scopes
<AndreRicardo>
so can I have like a base nginx
<rburton>
yes, a common nginx recipe, and then a recipe for each configuration you want
<AndreRicardo>
and have two specific for dev, uat and another just for prod.
speeder__ is now known as speeder
<rburton>
ask youself why would you want to rebuild nginx if you changed the configuration?
<AndreRicardo>
I don't, ideally is just one of the sites-available configs that is changed
<rburton>
exactly
<rburton>
but if your configuration is part of the nginx recipe that's what happens
<AndreRicardo>
I'm still a bit puzzled where these customisations should be. If they should be under meta-our-layer/recipes-httpd/nginx or somewhere else.
<rburton>
your configurations, your layer
<AndreRicardo>
and what would I call my bb file? Right now is nginx_%.bbappend
<rburton>
i'd have a nginx-config-prod.bb which just contains the production configuration files
rob_w has quit [Ping timeout: 246 seconds]
kayterina has quit [Quit: Client closed]
caglar has quit [Ping timeout: 246 seconds]
rob_w has joined #yocto
<manuel1985>
Hi all, is it possible to reference git tags in SRC_URI in kirstone?
<manuel1985>
It seems to no longer work in Kirkstone.
<rburton>
recommended not to anyway
<rburton>
put a sha
<manuel1985>
But I'm not sure I've got the complete picture.
<manuel1985>
Don't want to :(
<manuel1985>
git tag gives me an idea how old the sources are... checksums not so much
<rburton>
until someone moves a tag
rob_w has quit [Client Quit]
<manuel1985>
We don't have that problem with our internal repositories.
<rburton>
_yet_
<manuel1985>
Let's move the discussion back to the possibility of referencing git commits by tags in SRC_URI.
<manuel1985>
ptsneves: When using tag=v${PV} in SRC_URI and SRCREV = "${AUTOREV}" we get "Conflicting revisions (%s from SRCREV and %s from the url) found, please specify one valid value" since Kirkstone. In Dunfell this was doing fine.
<rburton>
i'd say dunfell was broken as they are conflicting
<rburton>
do you want autorev or the tag
<ptsneves>
manuel1985: Is the conflict real?
<manuel1985>
One sec, I'm just discussing something internally. Perhaps we screwed up somewhere.
<rburton>
RP: do you expect to merge the qemu 8.1.0 upgrade soon or should i prep a series of cve backports?
<RP>
rburton: I was hoping to, I was just a bit worried about the meson/python changes
<manuel1985>
I didn't yet hear back from the engineer, so here's my assumption on what happened. Our internal docs say one must specify SRCREV="$AUTOREV" when checking out a branch, and MUST NOT set SRCREV when checking out a tag. Engineer got confused and specified SRCREV="$AUTOREV" when checking out a tag.
tnovotny has quit [Quit: Leaving]
caglar has joined #yocto
GillesM has quit [Remote host closed the connection]
<Saur>
varjag: You probably want to look into create_wrapper. Here is an example from one of our recipes where I install a script and create a wrapper for it that sets a couple of variables based on values from Bitbake: https://pastebin.com/fXyvmmae
<varjag>
ohh interesting
<varjag>
thanks!
<AndreRicardo>
rburton: how can I do so that this nginx-config-prod.bb is run after the nginx_%.bbappend?
<ptsneves>
AndreRicardo: Make nginx-config-prod depend on nginx
speeder_ has joined #yocto
<varjag>
so i foolishly deleted sysroot dir in one of my built recipes… is there a way to repopulate it?
<varjag>
bitbake -f doesn't seem to do the trick
speeder has quit [Ping timeout: 260 seconds]
BrziCo has joined #yocto
<BrziCo>
Hello, I successfully built Yocto image for i.mx8quadmax MEK board. However, currently I need to manually edit fdt_file. Does anyone know how can I automate this in Yocto?
<BrziCo>
I currently need to 'editenv fdt_file' and to enter dtb that i need
xmn has joined #yocto
GillesM has joined #yocto
<varjag>
ok -c cleanall and rebuild helped
<rburton>
AndreRicardo: it doesn't need to. just install both in the image.
<rburton>
RP: yeah, the configure looks for the variables which get set when you pass options
GNUmoon has quit [Remote host closed the connection]
Xagen has joined #yocto
<rburton>
RP: ie --with-foo=fish turns into a variable with_foo=fish, and the configure macro looks for those variable
<rburton>
its horrible :)
GNUmoon has joined #yocto
<AndreRicardo>
Thanks rburton and ptsneves. I've created this nginx-config-prod.bb
<AndreRicardo>
seems to work, at least in the extracted filesystem the modified file is there
speeder_ has quit [Remote host closed the connection]
<rburton>
i'd just use do_install(), no need to :append to an empty task
<mckoan>
BrziCo: what was the problem?
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Vonter has quit [Ping timeout: 258 seconds]
<BrziCo>
mckoan I currently need to manually do 'editenv fdb_file'. I want to automate it
<BrziCo>
I want fdb_file to point to another default dtb file
<BrziCo>
should I use devtool to generate patch?
<BrziCo>
or whats best way
Xagen has joined #yocto
Vonter has joined #yocto
valdemaras has joined #yocto
<RP>
rburton: I figured it was something like that but the commit message/patch is a bit confusing :)
<manuel1985>
ptsneves, when using the git fetchers 'tag=' option without SRCREV=$AUTOREV, we get the following on Kirkstone: redacted-1.1.0-r0 do_fetch: Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch 'v1.1.0' for repo 'gitlab.com/redacted.git' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None)
<varjag>
uh, when my recipe delivers a pre-compiled elf binary *something* changes its ld-linux interpreter on its way to sysroot-destdir
<JaMa>
manuel1985: have you tried what the error message says?
<ptsneves>
manuel1985: have you tried usehead=1?
<manuel1985>
JaMa: We don't want to set the git commit has manually, we just want to use whatever the tag points to.
<manuel1985>
ptsneves, no. Frankly, I don't understand what it does.
<manuel1985>
“usehead”: Enables local git:// URLs to use the current branch HEAD as the revision for use with AUTOREV. The “usehead” parameter implies no branch and only works when the transfer protocol is file://.
<JaMa>
manuel1985: that's not what the message says
<manuel1985>
JaMa: So what does it say?
<JaMa>
(use SRCPV in PV for OE)
<manuel1985>
If I'm not mistaken the SRCPV is the git commit hash...
prabhakarlad has joined #yocto
<manuel1985>
what does "for OE" mean in this context?
<JaMa>
you're mistaken, that's SRCREV not SRCPV
<manuel1985>
Ok will try
<ptsneves>
JaMa: I honestly do not understand the error as well
<ptsneves>
JaMa: What is OE in this context?
<JaMa>
OpenEmbedded
<ptsneves>
(use SRCPV in PV for OE). I did not even understand why OpenEmbedded is relevant here. I guess this is because bitbake is part of oe-core, but damn if I understood that error
<JaMa>
well bitbake can be used by other projects, typical solution for OE project is to add SRCPV to PV to make sure that tag is resolved to sha early enough
mckoan is now known as mckoan|away
Vonter has quit [Ping timeout: 245 seconds]
<ptsneves>
JaMa: For me it is just the overload of acronyms in a simple parentheses. It is code-speak. I get your point though. Would the usehead=1 i suggested not work as well?
<JaMa>
I've never used usehead and wasn't aware of it (I was actually thinking you're making fun of manuel1985 :)), so dunno
<ptsneves>
> Enables local git:// URLs to use the current branch HEAD as the revision for use with AUTOREV. The “usehead” parameter implies no branch and only works when the transfer protocol is file://.
<ptsneves>
oh i guess i answered myself
<mischief>
it seems that using lmsensors pulls in perl somehow. is there a way to avoid that?
<rburton>
the problem is you're installing the top level lmsensors package which pulls in _all_ of the subpackages
<rburton>
install just the bits you need
Vonter has quit [Ping timeout: 248 seconds]
Vonter has joined #yocto
caglar has quit [Remote host closed the connection]
caglar has joined #yocto
<qschulz>
mmm trying to setup automatic builds of yocto layers through gitlab (because we develop on gitlab), but don't understand how people manage sstate-cache?
<RP>
qschulz: we just added a section in the manual on that!
rfuentess has quit [Remote host closed the connection]
<qschulz>
FWIW, we currently do auto builds using webhooks to Jenkins and I eventually plan to have LAVA in the mix
<qschulz>
RP: ah! shame on me for not going through my inbox!
<qschulz>
RP: mmmm are we talking about the same thing though?
<qschulz>
i remember some discussion around how to clean sstate-cache every now and then so we keep the storage size under control
<qschulz>
i'm talking more about how people share the sstate-cache in gitlab ci
<rburton>
qschulz: our CI has gitlab runners with a sstate cache on nfs
<qschulz>
rburton: we've that too
<qschulz>
i'm using a kas container and thus the nfs mount isn't available inside by default
<qschulz>
and I 've read you're supposed to modify the runner config file to add the mountpoints, but that's quite painful
<qschulz>
so was trying to figure out if I got things wrong somewhere or not
<qschulz>
or maybe I should try to not use containers... but it's so convenient :)
<qschulz>
self-hosted gitlab runners and server BTW
<rburton>
our runners run inside docker so they just mount the nfs directory into the container and we set sstate_dir to point at it
<varjag>
who can be messing with my binary on its way to sysroot-uninative
<varjag>
this is really frustrating
<qschulz>
rburton: "they just mount the nfs directory into the container" how?
<rburton>
basically, docker run --mount
<rburton>
(our ci is now k8s so i officially don't know or care anymore)
<qschulz>
rburton: ah so it's not using the `image` key from gitlab-ci.yml I guess?
<qschulz>
because you cannot set volumes in gitlab-ci.yml
<rburton>
sure but the .gitlab-ci.yml isn't the thing that starts the runner
<rburton>
the runners that are connected to our CI have the mounts needed
<mischief>
rburton: thanks, ill check it out
<qschulz>
rburton: ok, so we'd need to modify the runner config file then, thanks!
<qschulz>
rburton: I actually intuitively looked into meta-arm and was puzzled by the absence of volumes :)
Joel40 has joined #yocto
<Joel40>
Moin!
<Joel40>
What does this mean when yocto has found the patch in the bbappend by first picking up the bb itself?
<Joel40>
| error: recipes-kernel/linux/linux-mainline_6.1.9.bb: does not exist in index
<Joel40>
| [ERROR]: Application of .kernel-meta//patches//./0001-usb-support-for-orangepi-zero2.patch failed.
<rburton>
i'd be suspicious of your patch
<Joel40>
In what way exactly? Should I ignore the error?
<rburton>
it looks like 0001-usb-support-for-orangepi1-zero2.patch tries to patch the recipe
<Joel40>
It should be patching the Linux kernel
<rburton>
sure, but check that
<Joel40>
Oh, I see... It's doing it in the wrong directory? How do I check?
<Joel40>
I'm so stupid! Thank you rburton
caglar has quit [Quit: Leaving]
lexano has joined #yocto
goliath has quit [Quit: SIGSEGV]
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<dvergatal>
RP: Have you seen my emails regarding the issue discovered by you? I've been talking to khem regarding this problem and we decided together to force usage of tar-native from recipe if 1.35 is not on the host machine but after my investigations I've discovered that there is this meta/classes/sanity.bbclass with check_tar_version that it checks for version >= 1.28 or stops building
<dvergatal>
RP: khem: so my proposal is instead of implementing new code we should force this sanity check to >= 1.35, what do you think?
<RP>
dvergatal: most distros we support don't have tar 1.35
<dvergatal>
RP: yeah I know
<dvergatal>
so what do you propose?
zpfvo has quit [Quit: Leaving.]
<RP>
dvergatal: I have ideas but they've significant impact. I'm in a meeting atm :(
<dvergatal>
RP: we can discuss them later i'll be today in the vening working
AndreRicardo has quit [Quit: Client closed]
<dvergatal>
evening*
<dvergatal>
1
amitk has joined #yocto
kayterina has quit [Quit: Client closed]
mbulut has quit [Ping timeout: 250 seconds]
<khem>
Do we need tar-native for anything in the early build sequence of yes then where
Joel40 has quit [Ping timeout: 246 seconds]
<dvergatal>
using grep -r tar-native on openembedded-core returned me just 5 results which is package_tar.bbclass, bitbake.conf wic-tools.bb and scripts create.py and create_buildsys.py
<khem>
Yeah they are not in critical build pipeline so your change would force that
<dvergatal>
yeah but wait for RP we will see what are his ideas :)
<kanavin>
dvergatal, it's not a particularly urgent issue, given that feature freeze is now in effect
<dvergatal>
kanavin: no it's not, still we can offcourse wait until most distros will get new tar 1.35, I also need to check khem's issue regarding glibc-2.38 which i suspect is more urgent
florian has quit [Quit: Ex-Chat]
<kanavin>
you probably can eliminate the use of tar from the host (drop it from HOSTOOLS), and replace all occurences with tar-native, but then there needs to be a clear measurement of how it affects build times, e.g. core-image-minimal
<rburton>
how does one unpack tar without using host tar?
<RP>
dvergatal: very roughly, we need to make the code conditional so it either includes xattr or doesn't, then we can make it use xattars in the target codepaths but not the native one. Once we do that, we can force a tar-native dependency on the target codepaths
florian_kc has quit [Ping timeout: 246 seconds]
<RP>
we'd probably need a "tar-replacement-native" in a similar way to the way we have "file-replacement-native"
<dvergatal>
mhm
Thorn_ has joined #yocto
<dvergatal>
RP: I will need to discuss it with you in details
<RP>
dvergatal: I'm out of time for a few hours at least
<dvergatal>
not now
<dvergatal>
maybe tomorrow
valdemaras has quit [Quit: valdemaras]
kpo has joined #yocto
<dvergatal>
RP: I have plenty of other things to do and this sounds like a more stuff to be done
Thorn has quit [Ping timeout: 258 seconds]
tgamblin has quit [Quit: Leaving]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
tgamblin has joined #yocto
<dvergatal>
RP: btw. to be honest I like your solution :D
kpo has quit [Ping timeout: 245 seconds]
Vonter has quit [Ping timeout: 245 seconds]
ptsneves has quit [Ping timeout: 248 seconds]
yannd has quit [Remote host closed the connection]
yannd has joined #yocto
kpo has joined #yocto
valdemaras has joined #yocto
mvlad has quit [Remote host closed the connection]
<RP>
khem: something after 05affd7d0d143d6fa5c6aff0d40c5d9e046f4b0c
<khem>
mischief: bitbake -g <image> and looking at the RHS of -> in resulting dot file reveals a lot about whats getting pulled in
<khem>
and who is asking for it in dep chain
<RP>
khem: I'm using qemuppc-alt as the test so poky-altcfg, i.e. the 6.1 kernel
<khem>
you observed that it was occurring with 6.1 too right ?
<khem>
openssl: Upgrade 3.1.1 -> 3.1.2
gsalazar has quit [Ping timeout: 245 seconds]
<khem>
do we see this with sysvinit too ? there are bunch of systemd related changed in master after that commit so we can eliminate those if it is happening with sysvinit
<khem>
that leaves main kernel 6.4 and glibc 2.38
<khem>
and perhap tar as well since it will be used by tests on targets
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
amitk has quit [Remote host closed the connection]
<RP>
khem: yes, it is with sysvinit too
<RP>
khem: that is why I ruled out systemd
<RP>
khem: It happens with the 6.4 kernel as well. I was just wondering about openssl
<RP>
khem: I've tried some builds of the openssl commit, lets see how they do
alessioigor has quit [Quit: alessioigor]
dgriego has quit [Ping timeout: 255 seconds]
dgriego has joined #yocto
dgriego has quit [Ping timeout: 245 seconds]
<khem>
Cool
xmn has quit [Quit: xmn]
xmn has joined #yocto
Piraty_ is now known as Piraty
dgriego has joined #yocto
dgriego has quit [Read error: Connection reset by peer]
dgriego has joined #yocto
kpo has quit [Ping timeout: 248 seconds]
dgriego has quit [Read error: Connection reset by peer]
<RP>
khem: 90801cd8cb23719031aaaba1578a8446e1824cad fails so it is between there and the commit above
dgriego has joined #yocto
dgriego has quit [Read error: Connection reset by peer]
dgriego has joined #yocto
dgriego has quit [Client Quit]
mbulut has quit [Remote host closed the connection]
mbulut has joined #yocto
dgriego has joined #yocto
dgriego has quit [Ping timeout: 255 seconds]
mbulut has quit [Ping timeout: 255 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dgriego has joined #yocto
dgriego_ has joined #yocto
dgriego has quit [Ping timeout: 246 seconds]
dgriego_ has quit [Read error: Connection reset by peer]
dgriego has joined #yocto
dgriego_ has joined #yocto
dgriego_ has quit [Read error: Connection reset by peer]
dgriego_ has joined #yocto
dgriego has quit [Read error: Connection reset by peer]
dgriego_ has quit [Quit: Computer going to sleep]
<khem>
RP: perhaps it can be bisected now in 4 steps
dgriego has joined #yocto
<khem>
gtk4 is interesting too since its used for webkitgtk
_lore_ has quit [Ping timeout: 245 seconds]
ckayhan1 has joined #yocto
<ckayhan1>
Does anyone have recipe for 'v4l2loopback' ?
kpo has joined #yocto
florian_kc has quit [Ping timeout: 244 seconds]
davidinux has quit [Ping timeout: 248 seconds]
<moto-timo>
@ckayhan1 ` devtool add kernel-module-v4l2loopback --srcbranch main https://github.com/umlaeute/v4l2loopback.git` will get you started... you'll need to figure out the DEPENDS.