ello_ has quit [Read error: Connection reset by peer]
ello has quit [Read error: Connection reset by peer]
ello has joined #yocto
ello_ has joined #yocto
dgriego has quit [Ping timeout: 260 seconds]
dgriego has joined #yocto
dgriego has quit [Ping timeout: 276 seconds]
dgriego has joined #yocto
<tlwoerner>
with the latest update to libgcrypt 1.11.1 for some reason i seem to need LDFLAGS += "-pthread" in order for it to work
<tlwoerner>
anyone else seeing this? i haven't drilled down into it yet
olani has quit [Ping timeout: 276 seconds]
frgo has quit [Remote host closed the connection]
dmoseley has quit [Read error: Connection reset by peer]
dmoseley has joined #yocto
_whitelogger has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
jmd has joined #yocto
savolla has joined #yocto
Guest18 has joined #yocto
<Guest18>
I am working on OTA features for embedded linux. I found swupdate which seems to be a good fit for my project. I want to trial it on a raspberry pi 4B with yocto scarthgap, but I do not have any success.
<Guest18>
All the tutorial and articles seemed to be outdated, or does not use raspberry pi.
<Guest18>
Step by Step walk through on how to use swupdate on Raspberry Pi or any Embedded board for system update
<Guest18>
Updating Embedded Linux Devices: SWUpdate
<Guest18>
I was able to produce a image with this configuration: (in build/conf/local.conf)
<Habbie>
earlier conversation suggests there is a problem, not some intended change
<prabhakalad>
thank you!
<Habbie>
np :)
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<leon-anavi>
I am experiencing the same issue. I will switch to using the GitHub mirror until the issue has been fixed.
ablu has quit [Ping timeout: 248 seconds]
ablu has joined #yocto
<usvi>
in kirkstone I have a debug_image.bb which requires and depends in all ways possible on debug-user.bb. debug-user.bb has stuff in EXTRA_USERS_PARAMS , however, final EXTRA_USERS_PARAMS only contains stuff from debug_image.bb
<usvi>
I am printing the environment
<usvi>
(of course I could print the debug-user environment also, brb)
<usvi>
ok, debug-user environment has it
<usvi>
I have it as IMAGE_INSTALL += " debug-user " . this must be wrong somehow
<RP>
kanavin: It will be a bit more invasive but it might make the change more palatable too. The question is the right way to do it...
rob_w has quit [Remote host closed the connection]
<usvi>
seems to be that I can only put the whole thing in debug_image.bb EXTRA_USERS_PARAMS . too bad, I would have liked to modularize it into bb sub-recipes
<kanavin>
RP, I can prepare and propose some patches, just would want to help with the rust update first
<RP>
kanavin: fair enough, good plan
<RP>
kanavin: I've been pushing back against the INSANE_SKIPs in that upgrade
<tlwoerner>
qschulz: libclc: yea, it looks like simply adding "libclc" to PACKAGECONFIG is helpful
<qschulz>
tlwoerner: mmmm, do the other SoC manage to build mesa? or is it global to the panfrost mesa driver now requiring libclc always?
<qschulz>
if the latter, then we need to fix it in mesa recipe, so that it's pulled in when building panfrost mesa driver
Guest67 has joined #yocto
Guest67 has quit [Client Quit]
MarcWeDLM has quit [Quit: Client closed]
Kubu_work has joined #yocto
<tlwoerner>
qschulz: no idea. i looked at the issue late last night, kicked off a MACHINE=radxa-zero-3e build with that option added on top of your patch, and woke up to find mesa built successfully
<tlwoerner>
i'm now trying it with all the rockchip MACHINEs to see what happens
<qschulz>
tlwoerner: just the ones from different SoCs supported in our mesa bbappend should be enough I believe :)
<qschulz>
except if you're cold and looking to heat your place :)
steelswords94361 has joined #yocto
<tlwoerner>
qschulz: on May 9 someone asked essentially the same question in the #panfrost channel on OFTC wrt libreelec
<tlwoerner>
and it's new in 25.1 (which we're now using in master as of ~May 18)
<qschulz>
tlwoerner: the cost of running cutting edge :D
ederibaucourt has quit [Ping timeout: 245 seconds]
<usvi>
yocton: aHaa! Kirkstone does not contain USERADD_DEPENDS . that explains a lot. I converted extrausers method to useradd and it is working somewhat though, but I need to manually create the home directory in do_install to place a file there
<usvi>
ok I think it is working very satisfactorily now in anycase
<usvi>
thanks
ederibaucourt has joined #yocto
<yocton>
usvi: you're welcome :)
leon-anavi has quit [Quit: Leaving]
josuedhg has joined #yocto
zeemate has quit [Ping timeout: 272 seconds]
tlwoerner_ has joined #yocto
tlwoerner has quit [Ping timeout: 265 seconds]
mbulut has quit [Quit: Leaving]
<khem>
RP: is there a way to control how many qemu instances get launched for core-image-ptest-all using irtual:mcextend
zeemate has joined #yocto
zkrx has quit [Killed (NickServ (GHOST command used by zkrx_))]
zkrx has joined #yocto
GNUmoon has quit [Ping timeout: 264 seconds]
GNUmoon has joined #yocto
jmd has quit [Remote host closed the connection]
berton has quit [Quit: Connection closed for inactivity]
alperak has quit [Quit: Connection closed for inactivity]
<vvn>
hi there -- we cannot use a virtual package as an override, right? such as SRC_URI:append:virtual/kernel = " file://..."
goliath has joined #yocto
<vvn>
I have generic kernel patches that I want to apply to my distro, not for a specific machine kernel only
<RP>
khem: BB_NUMBER_THREADS
<RP>
vvn: you can't use virtuals like that, no
<vvn>
How do I share generic kernel patches for various kernel recipes?
<RP>
vvn: in general a patch won't apply correctly against any kernel version so there hadn't been demand for that
<RP>
I'm not aware of an easy way to do that
<vvn>
bbappends and dynamic-layers in the distro then.
<RP>
vvn: if you know the pn then you can use the pn-XXX overrides
<vvn>
But then, we would expect to bbappend every supported machines kernel with FILESEXTRAPATHS:append:my-distro = " ${THISDIR}/.../common-kernel-files"
<vvn>
RP: or a bench of SRC_URI:append:pn-linux-manufacturerX = " file://${COREBASE}/../<this-layer>/recipes-kernel/linux/files/000x....patch"
<vvn>
s/bench/bunch/
<vvn>
RP: I think OE must expose a ${THISLAYER} variable to simplify distro configurations which exposes distro-wide content (such as project root 'files' folders and such)
cyxae has quit [Quit: cyxae]
frgo has joined #yocto
goliath has quit [Quit: SIGSEGV]
frgo has quit [Ping timeout: 260 seconds]
druppy has quit [Ping timeout: 276 seconds]
frgo has joined #yocto
frgo has quit [Ping timeout: 265 seconds]
<khem>
RP:I only want to control it for qemu but not for rest of builds I guess there is no dedicated knob for that alone