LetoThe2nd changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Community: https://www.yoctoproject.org/community | IRC logs: http://irc.yoctoproject.org/irc/ | Having difficulty on the list, with someone on the list or on IRC, contact Yocto Project Community Manager Letothe2nd | CoC: https://www.yoctoproject.org/community/code-of-conduct
roussinm has quit [Quit: WeeChat 3.8]
Daanct12 has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
khazakar has quit [Quit: Connection closed for inactivity]
prabhakarlad has quit [Quit: Client closed]
Vonter has quit [Ping timeout: 246 seconds]
starblue has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
starblue has joined #yocto
amitk has joined #yocto
GNUmoon has quit [Read error: Connection reset by peer]
GNUmoon has joined #yocto
Starfoxxes has joined #yocto
lthadeus has joined #yocto
kpo has quit [Ping timeout: 268 seconds]
amitk has quit [Remote host closed the connection]
amitk has joined #yocto
alimon has quit [Ping timeout: 252 seconds]
alimon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
xmn has quit [Ping timeout: 255 seconds]
tgamblin_ has joined #yocto
tgamblin_ has quit [Remote host closed the connection]
tgamblin has quit [Ping timeout: 276 seconds]
tgamblin_ has joined #yocto
tgamblin_ has quit [Ping timeout: 245 seconds]
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
Chaser has joined #yocto
mason has left #yocto [#yocto]
Minvera has quit [Ping timeout: 252 seconds]
alperak has joined #yocto
alessioigor has joined #yocto
alimon has quit [Ping timeout: 255 seconds]
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
rob_w has joined #yocto
alimon has joined #yocto
alimon has quit [Ping timeout: 252 seconds]
linfax has joined #yocto
alimon has joined #yocto
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
Chaser has quit [Quit: Chaser]
mckoan|away is now known as mckoan
<mckoan> good morning
lthadeus has quit [Ping timeout: 268 seconds]
lthadeus has joined #yocto
tgamblin has joined #yocto
Kubu_work has joined #yocto
vladest has quit [Ping timeout: 246 seconds]
lthadeus has quit [Remote host closed the connection]
lthadeus has joined #yocto
Chaser has joined #yocto
kpo has joined #yocto
vladest has joined #yocto
lthadeus has quit [Ping timeout: 245 seconds]
mvlad has joined #yocto
<brabander> Is it safe to have multiple concurrent bitbake instances use & update the same SSTATE? So I can have multiple CI build nodes update this SSTATE which is then used as SSTATE_MIRROR by developers?
leon-anavi has joined #yocto
radanter has joined #yocto
lthadeus has joined #yocto
<yocton> brabander: I'd say yes, That is exactly what does the Yocto CI (the autobuilder)
destmaster has joined #yocto
<svuorela> win 62
<destmaster> Hi, I'm stuck with my new intel i9 14900l PC. The bitbake fails to build. Every time with different recipes. Googling a bit... seems that the problem seems related to high number of parallel builds. My CPU has 24 cores. Someone have encounteres this kind of issue?
Marmottus1 has quit [Quit: The Lounge - https://thelounge.chat]
Marmottus11 has joined #yocto
<LetoThe2nd> destmaster: how much ram?
prabhakar has quit [Quit: Connection closed]
prabhakarlad has joined #yocto
prabhakar has joined #yocto
<destmaster> LetoThe2nd 64GB
<LetoThe2nd> destmaster: might be borderline, especially if other things are running too. have you tried setting BB_NUMBER_THREADS = "16" or so?
<destmaster> I've set BB_NUMBER_THREADS to 24
<LetoThe2nd> destmaster: PARALLEL_MAKE too?
<destmaster> LetoThe2nd yes
<LetoThe2nd> destmaster: to?
<destmaster> LetoThe2nd I've tried (just now) with  PARALLEL_MAKE="-j 16" and BB_NUMBER_THREADS="16"
<LetoThe2nd> destmaster: well good luck then.
<destmaster> LetoThe2nd: same result
<destmaster> compilation errors
<LetoThe2nd> destmaster: then you have to be more precise, e.g. provide relevant error messages. please use a pastebin.
JaMa has quit [Ping timeout: 268 seconds]
<destmaster> LetoThe2nd: t and delete your pa
<destmaster> LetoThe2nd: the compilation errors happen every time on different package
<LetoThe2nd> destmaster: lra.c:(.text+0x1d2b): undefined reference to `insn_extract(rtx_insn*)' definitely doesn't sound like a cpu/ram issue.
vladest has quit [Remote host closed the connection]
<LetoThe2nd> pure guesswork: remove your custom distro and try with poky.
<destmaster> LetoThe2nd: ok, I will try. thanks
destmaster has quit [Quit: Client closed]
JaMa has joined #yocto
<rburton> yeah, pristine poke from a stable branch, fresh build dir.
<LetoThe2nd> rburton: pristine poke <§
<rburton> erm, poky :)
* LetoThe2nd promises to poke you pristinely at FOSDEM
<rburton> you tease!
* LetoThe2nd wink wink
Dane86 has joined #yocto
<Dane86> Does anybody know how to append to the PACKAGE_INSTALL of an INITRAMFS_IMAGE, from the main image ("core") image recipe?
<rburton> from an image recipe? you can't
<rburton> variables in a recipe are stuck in the recipe
<rburton> technically, the data store is populated with global/distro/local conf files, and then copy-on-write cloned for each recipe. so you can't set a variable in one recipe to affect another.
<rburton> what if you were building two images that wanted the initramfs built differently? what would bitbake build?
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
<Dane86> But the INITRAMFS_IMAGE is getting built from / as-part-of the main recipe?
<Dane86> Would the solution be to rather clone and then modify the recipe of the INITRAMFS_IMAGE?
<LetoThe2nd> Dane86: creating a custom image is one of the basic steps, initramfs are no different there.
<Dane86> Can't say I understand but just going to hack at the initramfs image recipe source for now rather than trying to append to it from the main image recipe :-).
<rburton> Dane86: yes absolutely the right thing to do is make your own initramfs recipe
<Dane86> rburton: thanks! :-)
<rburton> a recipe builds a thing. if that thing needs to change but you need multiple of them at once then write multiple recipes.
<rburton> also the core images are examples and if you're in production and not writing your own, you're doing it wrong
<rburton> (though i just posted a proper minimal initramfs recipe that might actually be useful in production because it does just one thing)
<Dane86> I do have my own image, thanks. Trying to get meta-updater (ostree) going though and struggling with it not linking the 'var' directory. Read in the ostree docs at https://ostreedev.github.io/ostree/adapting-existing/#booting-and-initramfs-technology that this only works if systemd + dracut are enabled. Seemed to manage to get systemd enabled in
<Dane86> the initramfs by adding VIRTUAL-RUNTIME_init_manager = "systemd" to the main image recipe and was trying to get dracut added via the main image recipe as well, but have reverted to just hacking at the initramfs image recipe for now.
<LetoThe2nd> Dane86: one of the joys of ostree is that it needs all that stuff in place, exactly (initramfs, and a working system) before it actually can act. one of the reasons why i'm not overly fond of it - but i am heavily biased, of course ;-)
alperak has quit [Quit: Client closed]
alperak has joined #yocto
<Dane86> It doesn't really seem to work "out of the box" so well (at least not with the meta-updater layer). I don't really want to go with full image A/B option though, so seems like ostree is definitely the way to go (?).
<LetoThe2nd> Dane86: effectively you're building two distributions. the initramfs/bootstrap thing, and the real one.
<LetoThe2nd> Dane86: well let me know when you're ready for A/B, or a more flexible approach in general ;-)
<Dane86> What other options are there?
<rburton> brace for sales pitch
<Dane86> :-D
starblue has quit [Ping timeout: 256 seconds]
<LetoThe2nd> Dane86: sales pitch i 20, lunch firs :-)
<LetoThe2nd> *in
<Dane86> :')
<LetoThe2nd> hey i'm the most honest sales-pitching guy you'll ever meet, that is guaranteed.
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
<Dane86> ostree "sounds" great - if you just need to update one file of a few bytes or kb (which is likely to be most of the time) then it's really low overhead, but if you do need to add/change something big then it's possible
starblue has joined #yocto
vladest has joined #yocto
<LetoThe2nd> Dane86: sales pitch ahead: if you just want to update a file directory without the full shbang, then Menders Update Modules got you already covered. And just recently I have put together a small layer that allows you to install it without any integration, just as a systemd service :)
<LetoThe2nd> Dane86: no full system/rootfs update functionality then of course, but super easy to get started, plus manageable.
<LetoThe2nd> (like I said, I'm biased)
<Dane86> OK thanks I thought Mender was full A/B only
<LetoThe2nd> Dane86: nope. it can do A/B if you do the integration dance. without it, the Update Modules can handle basically whatever flow and kind of data you want. Specifically dropping a single file or directory somewhere are readymade things.
<LetoThe2nd> :-)
<Dane86> Thanks that wasn't in the textbook :-D
<LetoThe2nd> last mention - the single file flow is even directly accessible through the web dashboard. upload file, give path to put it, profit.
* LetoThe2nd bows "Thanks everybody for listening, this was brought to you by a Mender employee" (silent now in public)
<Dane86> :')
<Dane86> Thanks I'll look into it!
<Dane86> Just looking for a reliable long-term firmware update solution
vladest has quit [Remote host closed the connection]
ederibaucourt has quit [Ping timeout: 256 seconds]
vladest has joined #yocto
tnovotny has joined #yocto
ederibaucourt has joined #yocto
LocutusOfBorg has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
<ablu> The good news is that A/B updates start to become fairly trivial with recent systemd integration :)
pretec has joined #yocto
prabhakarlad has quit [Quit: Client closed]
xmn has joined #yocto
lthadeus has quit [Ping timeout: 268 seconds]
lthadeus has joined #yocto
jetm- has joined #yocto
jetm- is now known as jetm
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.1.2]
khazakar has joined #yocto
<LetoThe2nd> ablu: systemd is not the problem, never has been. switching and rollback on the romloader and bootloader level is.
<ablu> LetoThe2nd: Yeah, but sd_boot solves a great deal of that IMHO.
<ablu> Ah, romloader and bootloader level rollback...
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
<LetoThe2nd> ablu: once you have UEFI, then things get easier. systemd-boot just lives off that. but in reality, way too many systems are still purely u-boot. and there again, systemd doesn't help, none of its tools. its also not them that make things better. it is standardization, like UEFI and SystemReady ES
<LetoThe2nd> don't get me wrong, I like systemd. but its definitely not them doing the hard work here.
* ablu admits to live in a UEFI world.
<ablu> Still systemd / uapi group provides the missing standard on the user-space side.
<LetoThe2nd> ablu: now if they actually would start caring about embedded people...
<ablu> LetoThe2nd Isn't all the new image-based stuff more useful to embedded than regular distros? There are still some implementation gaps here for sure. But the concepts are there.
<LetoThe2nd> ablu: thats a common argument, but i'm not sold on it at the moment.
* ablu will probably post a RFC patch to build images with systemd-repart soon
<rburton> RP: just replied to "[PATCH 1/9] nativesdk: ensure features don't get backfilled" and your opinion would be welcome
<RP> Why do we set meta/classes-recipe/ptest-cargo.bbclass: d.setVarFlag('do_install_ptest_cargo', 'umask', '022')
<RP> meta/classes-recipe/ptest.bbclass: d.setVarFlag('do_install_ptest_base', 'umask', '022')
<rburton> good questions
lexano has joined #yocto
<rburton> the ptest one is probably because that class is _ville_ and does bare cp and force-chowns
<RP> rburton: replied with an opinion :)
<RP> one even related to the question asked :)
<rburton> i wonder if i'll like it
<rburton> RP: can i disable pgo in buildtools until it works again?
<rburton> (to unblock my gtkdoc series)
<rburton> or is the nativesdk machine feature thing a blocker on that
LocutusOfBorg has joined #yocto
Dane86 has quit [Quit: Client closed]
alperak has quit [Quit: Client closed]
alperak has joined #yocto
lthadeus has quit [Ping timeout: 268 seconds]
<RP> rburton: I guess. Can you at least file a bug
<RP> rburton: I just worry this means nobody will look at it
<rburton> i asked for that didn't i
<rburton> what issue in particular :) no pgo in nativesdk python?
<rburton> FWIW
<rburton> $ bitbake-getvar -r nativesdk-python3 MACHINE_FEATURES
<rburton> MACHINE_FEATURES=" qemu-usermode"
<rburton> SDK_MACHINE_FEATURES ?="" in bitbkae.conf. MACHINE_FEATURES=SDK_MACHINE_FEATURES in nativesdk. SDK_MACHINE_FEATURES += qemu-usremode in machine-sdk/x86-64.conf
<rburton> ah alex says the upcoming 3.12 disables PGO entirely because it got rewritten
<rburton> i'll file bugs and update the AB helper _now_, then see what I can do with nativesdk -fu
<rburton> and see if my friendly colleague who is basically fulltime upstream on python for arm can have a look at making the PGO stuff cross-friendly
<RP> rburton: sounds good thanks
Estrella has joined #yocto
Estrella has quit [Client Quit]
Minvera has joined #yocto
joekale has joined #yocto
Estrella has joined #yocto
lthadeus has joined #yocto
lthadeus has quit [Remote host closed the connection]
<kanavin> rburton, RP: I corrected myself
sotaoverride is now known as Guest9632
Guest374 is now known as sotaoverride
jclsn has joined #yocto
<rburton> i think i have fixes for all of the issues
<rburton> kanavin: how close are you to posting the 3.12 upgrade? i have a change to the 3.11 recipe... (its only minor and easily absorbed)
<LetoThe2nd> rburton: i just misread that as "I have fleas for all the issues."
<rburton> LetoThe2nd: those too <scratch scratch>
<rburton> wmills__: it just sits on Loading here so I'd guess "no"
jmd has joined #yocto
<yocton> kanavin: rburton: FYI I just pointed a (junior) coworker who has a bit of free time to your mail about the python 3.12 upgrade. (Sadly, I can't promise she will have time to complete any fix but there is hope!)
<rburton> i have pgo enabled again
<rburton> will post and sent alex rebasing hugs
LocutusOfBorg has quit [Changing host]
LocutusOfBorg has joined #yocto
Xagen has joined #yocto
<JPEW> wmills__: There is a bug open to fix the website
<JPEW> ^^ the reproducible one
<wmills__> JPEW: Ok thanks
<yudjinn> hey, hitting an issue with the latest of poky:kirkstone where cpio wont build; I dont have any bbappends hitting this, either:
<yudjinn> ```stdout: Applying patch 0001-Wrong-CRC-with-ASCII-CRC-for-large-files.patch patching file src/copyout.c Hunk #1 FAILED at 34. 1 out of 1 hunk FAILED -- rejects in file src/copyout.c Patch 0001-Wrong-CRC-with-ASCII-CRC-for-large-files.patch does not apply (enforce with -f)```
<rburton> yudjinn: delete tmp just to rule out some really weird corruption
<rburton> oh that's not latest kirkstone: that patch was removed in july (727f301e4888c8f59cfc2d8768d02bb52ce23784)
<yudjinn> eadd5efcb3a7a78e9b89be935ac1649dc33cbad6 Dec 5, still there
alberto_pianon has joined #yocto
<vmeson> unassigned devtool bug for anyone interested: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15318
* landgraf avoids autobuilder bugs, they're difficult to reproduce usualy :(
<yudjinn> rburton: omg, it was an append from meta-swupdate that I missed; you're totally right
<rburton> bitbake-layers show-appends is useful here
<vmeson> unassigned gzip ptest bug for anyone interested: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15320 -- add logs or record logs on next hit.
<yudjinn> completely forgot about show-appends, I'll have to commit that to memory
<alberto_pianon> Hi! Is there a backwards-compatible way of adding a python library from a bblayer without using addpylib? What was the best practice to do that before addpylib directive was added?
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
amitk_ has joined #yocto
khazakar has quit [Quit: Connection closed for inactivity]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sakoman has quit [Ping timeout: 276 seconds]
<vmeson> landgraf: yes, they can but but we've gotten into the current situation of it taking days or a week to get a greem autobuilder run to to the large number of such problems.
sakoman has joined #yocto
amitk_ has quit [Quit: leaving]
mbulut has joined #yocto
rob_w has quit [Read error: Connection reset by peer]
<landgraf> vmeson: gzip bug taken. will take a look how to improve output at least
Kubu_work has quit [Quit: Leaving.]
<vmeson> landgraf: thank you very much! Good luck. Feel free to chat/ask about it here if you need help.
tnovotny has quit [Quit: Leaving]
alessioigor has quit [Ping timeout: 264 seconds]
dmoseley has joined #yocto
dmoseley has quit [Client Quit]
dmoseley has joined #yocto
<alberto_pianon> solved! I used the same logic that has been removed in this patch https://git.openembedded.org/openembedded-core/commit/?id=1f56155e91da2030ee0a5e93037c62e1349ba89f
<alberto_pianon> I still wonder if there is a more elegant way to do it...
ray-san has quit [Ping timeout: 256 seconds]
<JPEW> alberto_pianon: OE_IMPORTS is the way. My plan (that I haven't done yet) is to add a noop addpylib to older versions of OE that we support and have both addpylib and OE_IMPORTS in our layers that have to work with multiple versions
<alberto_pianon> JPEW: yes, but if I use OE_IMPORTS, it does not work on nanbield, while I use addpylib, in kirkstone I get an error, and IIUC there is no way to put addpylib in a conditional statement. I would like to avoid to have two versions of the same bblayer just because of this
<rburton> kanavin: did you remove the do-not-compile-pyc-in-parallel patch to py? its been fixed a while (https://github.com/python/cpython/issues/87664)
<alberto_pianon> JPEW: sorry, I've just realized that that was exacltly what you were saying :)
vladest has quit [Quit: vladest]
<alberto_pianon> JPEW: BTW, until the noop addpylib is added to older versions of OE, I'm afraid I need to use a hacky solution
<alberto_pianon> JPEW: thanks!
zhmylove has joined #yocto
pretec has quit [Quit: Leaving]
<Saur_Home32> alberto_pianon: The way I solved that problem is that I have a separate layer where I do all adaptations to make our platform (which is currently based on Nanbield) to work with, e.g., master. That layer typically has a bunch of BBMASKs to drop bbappends that are no longer needed with the newer versions of recipes in master, or extra bbappends to
<Saur_Home32> add updated patches.
<Saur_Home32> alberto_pianon: And the fact is that you can use addpylib (in that adaptation layer) to add modules from another layer, e.g.: addpylib ${LAYERDIR}/../meta-mylayer/lib foomodule
jmiehe has joined #yocto
vladest has joined #yocto
sakoman has quit [Ping timeout: 276 seconds]
<rburton> 0: python3-3.11.5-r0 do_compile - 17m42s (pid 1911421)
<rburton> PGO sucks
khazakar has joined #yocto
<rburton> RP: posted the pgo fix for buildtools. i'll run it through the AB now to check it doesn't explode
<RP> rburton: great, thanks!
mckoan is now known as mckoan|away
sakoman has joined #yocto
alperak has quit [Quit: Client closed]
vvn has quit [Ping timeout: 245 seconds]
vvn has joined #yocto
alberto_pianon has quit [Quit: Client closed]
<kanavin> rburton, I'm not any closer since I posted the 3.12 update status email to oe-devel some days ago. Still 27 meta-oe recipes in need of fixing, and no visible help from others.
<kanavin> rburton, sadly that's just one of several issues with the parallel pyc compile - this was fixed, ownership races weren't (I suspect python does something that overlaps with do_package)
<kanavin> rburton, I removed the patch, but it was replaced with a make option so it's still serial
leon-anavi has quit [Quit: Leaving]
linfax has quit [Ping timeout: 256 seconds]
sakoman has quit [Ping timeout: 276 seconds]
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
sakoman has joined #yocto
prabhakarlad has joined #yocto
<khem> rburton: do we have the build tree of those two rust compilers somewhere handy on AB
jmiehe has quit [Quit: jmiehe]
prabhakarlad has quit [Quit: Client closed]
amitk has quit [Ping timeout: 268 seconds]
Chaser has quit [Quit: Chaser]
mbulut_ has joined #yocto
mbulut has quit [Ping timeout: 245 seconds]
radanter has quit [Remote host closed the connection]
mbulut__ has joined #yocto
mbulut_ has quit [Ping timeout: 245 seconds]
zhmylove has quit [Remote host closed the connection]
vladest has quit [Quit: vladest]
mbulut__ has quit [Remote host closed the connection]
mbulut has joined #yocto
mbulut has quit [Quit: Leaving]
vladest has joined #yocto
prabhakarlad has joined #yocto
<rburton> probably not
xmn has quit [Read error: Connection reset by peer]
jmd has quit [Remote host closed the connection]
agrue has joined #yocto
agrue has quit [Ping timeout: 268 seconds]
agrue has joined #yocto
xmn has joined #yocto
agrue_ has joined #yocto
agrue_ has quit [Client Quit]
xmn has quit [Read error: Connection reset by peer]
agrue_ has joined #yocto
agrue has quit [Ping timeout: 276 seconds]
<khem> hmm ok, it will be good to see if we can, I dont want to build rust locally
<khem> :)
agrue has joined #yocto
agrue_ has quit [Ping timeout: 268 seconds]
Haxxa has quit [Ping timeout: 256 seconds]
Haxxa has joined #yocto
Haxxa has quit [Read error: Connection reset by peer]
Haxxa has joined #yocto
agrue has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
agrue has joined #yocto
Haxxa has quit [Ping timeout: 255 seconds]
mvlad has quit [Remote host closed the connection]
agrue has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
agrue has joined #yocto
Haxxa has joined #yocto
prabhakarlad has quit [Ping timeout: 250 seconds]
agrue has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
agrue has joined #yocto
agrue has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
agrue has joined #yocto
neofutur has quit [Ping timeout: 252 seconds]
joekale has quit [Ping timeout: 268 seconds]
agrue_ has joined #yocto
agrue has quit [Ping timeout: 268 seconds]
neofutur_ has joined #yocto